perf(e2e): overlap and batch e2e setup transactions#24569
Open
spalladino wants to merge 2 commits into
Open
Conversation
The BananaFPC deploy, SponsoredFPC registration, and Alice's banana mints each depend only on the BananaCoin deployed during FeesTest.setup, so the fees suites now run them concurrently instead of paying one production slot per step. Likewise the cross-chain harness deploys the L2 token and its bridge concurrently: the bridge takes the token address as a constructor arg, but that address is deterministic before the deploy tx mines, and the bridge constructor does not call into the token.
applyFundAliceWithBananas sent Alice's private and public banana mints back-to-back, paying one production slot each. The two mints touch disjoint balances, so they are now sent concurrently and share a slot. Each mint keeps its own tx:mint span, so the overlap shows up as busyMs < totalMs in the timing data.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #24564; retarget to
merge-train/spartan-v5after it merges.Overlaps the serial setup-tx chains in the fees and cross-chain e2e harnesses so independent setup transactions share production slots instead of paying one slot each. Part of the round-4 e2e speedup effort.
Commits
FeesTest.setupdeploys BananaCoin, the BananaFPC deploy, the SponsoredFPC registration (a PXE registration, no L2 tx), and Alice's banana mints each depend only on the token, so the fees suites (account_init,gas_estimation,private_payments) now run them under aPromise.all. The cross-chain harness (deployAndInitializeTokenAndBridgeContracts) deploys the L2 token and its bridge concurrently: the bridge takes the token address as a constructor arg, but that address is deterministic before the deploy tx mines (the deploy is now constructed with an explicitdeployer, same address derivation as the previous send-time lock), and the bridge constructor only stores it without calling into the token.applyFundAliceWithBananassent the private and public mints back-to-back (measured 100% serial:tx:mintbusyMs == totalMs == 23.9s on the base). They touch disjoint balances, so they are now sent concurrently. Each mint keeps its owntx:mintspan, so the overlap shows up directly as busyMs < totalMs.Dependency analysis
Promise.all.{token, portal}in its own storage and never calls the token, so the bridge deploy does not need the token to be mined first.BANANA_COIN_SALT/BANANA_FPC_SALT+deployer: aliceare untouched, and the genesis-funded-address assertion inapplyFPCSetupstill runs (and passed locally).Same-sender concurrency
Concurrent
.send()calls from the same sender through the same TestWallet are safe: the PXE serializessimulateTx/proveTxthrough aSerialQueue(#putInJobQueue), so simulations never interleave and only the block-inclusion waits overlap. The setup txs pay fees from Alice's public fee-juice balance (PREEXISTING_FEE_JUICE) with random tx nonces, so there are no nullifier or note conflicts between the concurrent txs. Verified locally with fullPromise.allof the send+wait calls; no NO_WAIT fallback or cross-sender split was needed.Skipped: batching token class+instance publication (planned commit 2)
Not applicable on this base:
DeployMethod.request()already merges class publication, instance publication, and the constructor call into a single execution payload sent as one tx (getPublicationExecutionPayload+getInitializationExecutionPayload→ a singlewallet.sendTx). Measured locally,deploy:tokenis a single ~12s (1 slot) occurrence, not two txs in separate blocks; the ~24s occurrences in the CI span data are inclusion latency at CI cadence, not a second tx. There is nothing to batch.Local verification (12s slots; CI runs 24s slots so absolute savings roughly double there)
account_init, spans on): 5/5 passed; beforeAll 83.5s =setup:auth-registry32.0s +deploy:token12.0s +tx:mint23.9s (busyMs == totalMs, fully serial) +deploy:fpc11.8s.account_init, spans on): 5/5 passed; beforeAll 72.2s (−11.3s);tx:mintbusyMs 24.0s < totalMs 36.0s (the overlap proof),deploy:fpcfully overlapped with the mint window. The serial token→mints→FPC tail compressed from 47.7s to ~36s; the remaining 32s is the auth-registry publish that perf(e2e): seed standard contracts at genesis #24568 removes.gas_estimation: 3/3 passed; ideal overlap shape —tx:mintbusyMs 11.8s vs totalMs 23.3s (both mints shared one slot),deploy:fpc23.7s fully inside the mint window; beforeAll 71.6s.private_payments: 8/8 passed;tx:mintbusyMs 24.1s vs totalMs 36.0s; beforeAll 104.9s (includes the epoch-proving wait).token_bridge(exercises the cross-chain harness overlap): 7/7 passed;deploy:token12.1s anddeploy:bridge23.7s ran concurrently (union ≈ 23.7s). CI baseline for the same suite paid 24.1s + 24.0s fully serial (≈48s), so the overlap saves ~24s per harness creation at CI cadence.l2_to_l1(cross-chain path without the token bridge): 6/6 passed, regression check on the untouched path.Expected effect
~2–4 min/run across the fees and cross-chain suite family once #24568 lands (which removes the auth-registry cost): roughly 2 slots saved per fees shard (mint pair + FPC overlap) and 1 slot per cross-chain harness creation. The
tx:mintbusyMs < totalMs gap is the direct proof metric; measured CI numbers to be appended after the fix-phase run.