perf(e2e): seed BananaFPC fee juice at genesis instead of bridging (#24564)

## What / why

PR 2 of the round-4 e2e speedup effort. The fees-family suites pay a
`setup:bridge` span (~48s ≈ 4 production slots per process) in
`FeesTest.applyFPCSetup`, bridging fee juice from L1 to the BananaFPC
via the gas portal (`bridgeFromL1ToL2` = prepare-on-L1 + advance 2
blocks + a claim tx). That funding is pure setup plumbing — the fees
tests snapshot the FPC's gas balance and assert deltas, they don't
assert on the bridge itself.

Fee-juice balances are just public-data leaves at
`computeFeePayerBalanceLeafSlot(address)`, which `getGenesisValues`
(`world-state/src/testing.ts`) already prefills for genesis-funded
accounts — the same mechanism that funds the initial accounts and
(already, on this base) the sponsored FPC. This PR seeds the BananaFPC's
fee juice at genesis instead of bridging it during setup.

Note: the plan's premise that `fundSponsoredFPC: true` bridges was stale
— the sponsored FPC has been genesis-funded since #19532 (setup pushes
its deterministic address into the genesis-funded list). The remaining
`setup:bridge` cost in the fees family is the BananaFPC bridge, which
this PR removes.

## Mechanism

- The BananaFPC address depends on the BananaCoin address and the FPC
admin (the first setup account), and the accounts are generated *inside*
`setup()` with random secrets — so the FPC address can't be precomputed
by the test before genesis. Fixed deploy salts are added for BananaCoin
and BananaFPC so both addresses become deterministic once the admin is
known, and a `computeExtraGenesisFundedAddresses(defaultAccounts)` hook
on `SetupOptions` runs after the accounts are generated and before
genesis values are computed. `FeesTest` uses it to derive the BananaFPC
address from the first account and add it to the genesis-funded list.
- The returned address flows through the existing initial-accounts path
(`addressesToFund` → `getGenesisValues`), so it is funded with the same
fee juice as an initial account (`10^22`) and automatically included in
the L1 `FeeJuicePortal` `feeJuicePortalInitialBalance` (`fundingNeeded`)
accounting — the portal's locked L1 balance stays consistent with total
L2 fee-juice supply, exactly as for every other genesis-funded balance.
- `applyFPCSetup` deploys the FPC with the fixed salt and asserts the
deployed address equals the seeded one, so any drift in the
deterministic deploy params surfaces as a clear error instead of a
downstream "insufficient fee payer balance". The `bridgeFromL1ToL2` call
is removed.
- The `setup:bridge` span wrapper is kept in place for the bridging that
remains, so its disappearance from the fees setup hooks is the measured
proof.

## Scope decisions (site by site)

- **`FeesTest.applyFPCSetup` BananaFPC funding** → moved to genesis.
Used by `account_init`, `private_payments.parallel`, `failures`,
`gas_estimation.parallel`. This is the only funding that moved.
- **`FeesTest.mintAndBridgeFeeJuice`** (bridges to an arbitrary
recipient) → kept. It fires in `account_init` test bodies that test the
bridge/claim flow ("pays natively in the Fee Juice after Alice bridges
funds") — real behavior under test.
- **`account_init` `FeeJuicePaymentMethodWithClaim` /
`prepareTokensOnL1`** → kept. Tests the atomic claim-in-deploy flow.
- **Sponsored FPC** → already genesis-funded via `fundSponsoredFPC:
true` on this base; no change.
- **`cross_chain_messaging_test`** (`fundSponsoredFPC: true`) → already
genesis-funded; its own cross-chain bridging harness is the behavior
under test, kept.
- **`bench/client_flows_benchmark`** bridges to its BananaFPC → out of
scope (benchmark harness, not in the fees e2e timing family), kept.
- Production/sandbox funding paths (cli, `aztec sandbox`) → untouched.
The new hook defaults to unset; only the e2e fixtures opt in.

## Expected effect

~48s × the number of fees processes that ran the FPC bridge in setup
(account_init, private_payments, failures, gas_estimation). No C++, no
new config, no change to production genesis roots.

## Local verification

- `single-node/fees/account_init -t 'pays privately through an FPC'`
passes; the span leaderboard for the run shows **zero `setup:bridge`**
occurrences (was ~48s), while `deploy:fpc`/`deploy:token` remain. The
FPC-paying test asserts the FPC's gas balance decreases by the fee, so
the genesis funding is exercised end to end, and the deployed-address
assertion held.
- `single-node/fees/account_init -t 'after Alice bridges funds'` passes
with `setup:bridge` present in the test body, confirming the retained
bridge/claim harness still works.

## Measured impact

The `setup:bridge` span is eliminated across the run: 17 occurrences
totalling 646.4s of bridge
setup time in the baseline drop to zero in the PR run. The 13 fees-hook
bridges (~48s each) are the
bulk of it.

- Fees beforeHooks per shard: `private_payments.parallel` −51.1s (×8
shards),
`gas_estimation.parallel` −48.1s (×3), `failures` −47.8s, `account_init`
−47.8s — each matching the
  ~48s (4-slot) bridge cost.
- `setup:bridge` busyMs removed per suite: account_init 48.1s, failures
48.2s, gas_estimation ×3 =
144.6s, private_payments ×8 = 384.7s (13 fees-hook bridges ≈ 625.5s),
plus the ~5s sponsored-FPC
  bridges on `amm` and `storage_proof`.
- Total beforeHooks reduction over the suites present in both runs:
−907.4s summed across shards
(wall-clock benefit is smaller, since the fees shards run in parallel).
- One suite moved the wrong way within noise: `fee_juice_payments`
+11.0s. It keeps its real
bridging/claim txs (no `setup:bridge` span removed), so this is
run-to-run variance, not a
  regression from this change.

Baseline CI run 1783374468714213 (merge-base e1711d3, full). PR CI
run 1783375878950264
(x-fast — the comparison is per-suite over the suites present in both
runs).

Fixes A-1405

(cherry picked from commit 1321e98)

Author: spalladino

yarn-project/end-to-end/src/fixtures/setup.ts

@@ -220,6 +220,14 @@ export type SetupOptions<TDeployExtraL1ContractsReturnType = unknown> = {
   zkPassportArgs?: ZKPassportArgs;
   /** Whether to fund the sponsored FPC in genesis (defaults to false). */
   fundSponsoredFPC?: boolean;
+  /**
+   * Compute extra addresses to fund at genesis from the accounts setup just generated (passed as the
+   * argument). Runs after the default accounts are created and before genesis values are computed, so a
+   * test can genesis-fund a contract whose address derives from a default account (e.g. an FPC whose
+   * admin is the first account) instead of bridging fee juice to it during setup. Each returned address
+   * is funded with the same fee juice as an initial account and included in the L1 portal `fundingNeeded`.
+   */
+  computeExtraGenesisFundedAddresses?: (defaultAccounts: InitialAccountData[]) => Promise<AztecAddress[]>;
   /** L1 contracts deployment arguments. */
   l1ContractsArgs?: Partial<DeployAztecL1ContractsArgs>;
   /** Wallet minimum fee padding multiplier */
@@ -458,6 +466,12 @@ async function setupInner<TDeployExtraL1ContractsReturnType = unknown>(
       const sponsoredFPCAddress = await getSponsoredFPCAddress();
       addressesToFund.push(sponsoredFPCAddress);
     }
+
+    // Fund any extra addresses whose value depends on the just-generated accounts (e.g. an FPC admin'd
+    // by a default account), so a test can genesis-fund them instead of bridging fee juice during setup.
+    if (opts.computeExtraGenesisFundedAddresses) {
+      addressesToFund.push(...(await opts.computeExtraGenesisFundedAddresses(defaultAccounts)));
+    }
     logger.trace('Generated test accounts to fund at genesis');
 
     const genesisTimestamp = BigInt(Math.floor(Date.now() / 1000));

yarn-project/end-to-end/src/single-node/fees/fees_test.ts

@@ -1,4 +1,5 @@
 import type { AztecAddress } from '@aztec/aztec.js/addresses';
+import { Fr } from '@aztec/aztec.js/fields';
 import { createLogger } from '@aztec/aztec.js/log';
 import type { AztecNode } from '@aztec/aztec.js/node';
 import { CheatCodes, getTokenAllowedSetupFunctions } from '@aztec/aztec/testing';
@@ -17,6 +18,7 @@ import { TokenContract as BananaCoin } from '@aztec/noir-contracts.js/Token';
 import { CounterContract } from '@aztec/noir-test-contracts.js/Counter';
 import { ProtocolContractAddress } from '@aztec/protocol-contracts';
 import { getCanonicalFeeJuice } from '@aztec/protocol-contracts/fee-juice';
+import { getContractInstanceFromInstantiationParams } from '@aztec/stdlib/contract';
 import { Gas, GasSettings } from '@aztec/stdlib/gas';
 import type { AztecNodeAdmin } from '@aztec/stdlib/interfaces/client';
 
@@ -34,13 +36,41 @@ import {
 import { TestWallet } from '../../test-wallet/test_wallet.js';
 import { SingleNodeTestContext, type SingleNodeTestOpts } from '../single_node_test_context.js';
 
+// Fixed deploy salts so BananaCoin and its BananaFPC land at deterministic addresses given the FPC
+// admin. This lets the BananaFPC's fee-juice balance be seeded at genesis (see `FeesTest.setup`)
+// instead of bridged from L1 during setup — the address must be known before genesis is computed.
+const BANANA_COIN_SALT = new Fr(0xba4a4a);
+const BANANA_FPC_SALT = new Fr(0xfacade);
+
+const BANANA_COIN_CONSTRUCTOR_ARGS = ['BC', 'BC', 18n] as const;
+
+/**
+ * Computes the deterministic BananaCoin and BananaFPC instances for the given admin/deployer, matching
+ * what {@link FeesTest.applyDeployBananaToken} and {@link FeesTest.applyFPCSetup} deploy with the fixed
+ * salts above. Used both to seed the BananaFPC's fee juice at genesis and to assert the deployed
+ * addresses match the seeded one.
+ */
+async function computeBananaContractAddresses(admin: AztecAddress) {
+  const bananaCoin = await getContractInstanceFromInstantiationParams(BananaCoin.artifact, {
+    salt: BANANA_COIN_SALT,
+    constructorArgs: [admin, ...BANANA_COIN_CONSTRUCTOR_ARGS],
+    deployer: admin,
+  });
+  const bananaFPC = await getContractInstanceFromInstantiationParams(FPCContract.artifact, {
+    salt: BANANA_FPC_SALT,
+    constructorArgs: [bananaCoin.address, admin],
+    deployer: admin,
+  });
+  return { bananaCoinAddress: bananaCoin.address, bananaFPCAddress: bananaFPC.address };
+}
+
 /**
  * Test fixture for testing fees. Provides the following setup steps:
  * InitialAccounts: Initializes 3 Schnorr account contracts.
  * PublicDeployAccounts: Deploys the accounts publicly.
  * DeployFeeJuice: Deploys the Fee Juice contract.
- * FPCSetup: Deploys BananaCoin and FPC contracts, and bridges gas from L1.
- * SponsoredFPCSetup: Deploys Sponsored FPC contract, and bridges gas from L1.
+ * FPCSetup: Deploys BananaCoin and FPC contracts; the FPC's fee juice is seeded at genesis.
+ * SponsoredFPCSetup: Registers the Sponsored FPC contract, whose fee juice is seeded at genesis.
  * FundAlice: Mints private and public bananas to Alice.
  * SetupSubscription: Deploys a counter contract and a subscription contract, and mints Fee Juice to the subscription contract.
  *
@@ -116,6 +146,11 @@ export class FeesTest extends SingleNodeTestContext {
       ...this.setupOptions,
       ...opts,
       fundSponsoredFPC: true,
+      // Seed the BananaFPC's fee juice at genesis instead of bridging it from L1 in applyFPCSetup. The
+      // FPC admin is the first account, so its address is deterministic once the accounts are generated.
+      computeExtraGenesisFundedAddresses: async defaultAccounts => [
+        (await computeBananaContractAddresses(defaultAccounts[0].address)).bananaFPCAddress,
+      ],
       l1ContractsArgs: { ...this.setupOptions },
       txPublicSetupAllowListExtend: [...(this.setupOptions.txPublicSetupAllowListExtend ?? []), ...tokenAllowList],
     });
@@ -247,7 +282,10 @@ export class FeesTest extends SingleNodeTestContext {
     this.logger.info('Applying deploy banana token setup');
 
     const { contract: bananaCoin } = await testSpan('deploy:token', () =>
-      BananaCoin.deploy(this.wallet, this.aliceAddress, 'BC', 'BC', 18n).send({
+      BananaCoin.deploy(this.wallet, this.aliceAddress, ...BANANA_COIN_CONSTRUCTOR_ARGS, {
+        salt: BANANA_COIN_SALT,
+        deployer: this.aliceAddress,
+      }).send({
         from: this.aliceAddress,
       }),
     );
@@ -270,15 +308,26 @@ export class FeesTest extends SingleNodeTestContext {
 
     const bananaCoin = this.bananaCoin;
     const { contract: bananaFPC } = await testSpan('deploy:fpc', () =>
-      FPCContract.deploy(this.wallet, bananaCoin.address, this.fpcAdmin).send({
+      FPCContract.deploy(this.wallet, bananaCoin.address, this.fpcAdmin, {
+        salt: BANANA_FPC_SALT,
+        deployer: this.aliceAddress,
+      }).send({
         from: this.aliceAddress,
       }),
     );
 
     this.logger.info(`BananaPay deployed at ${bananaFPC.address}`);
 
-    // bridgeFromL1ToL2 carries its own setup:bridge span.
-    await this.feeJuiceBridgeTestHarness.bridgeFromL1ToL2(bananaFPC.address, this.aliceAddress);
+    // The BananaFPC's fee juice is seeded at genesis (see FeesTest.setup) rather than bridged here.
+    // Assert the deploy landed at the seeded address so a params drift surfaces as a clear error rather
+    // than a downstream "insufficient fee payer balance".
+    const { bananaFPCAddress } = await computeBananaContractAddresses(this.aliceAddress);
+    if (!bananaFPC.address.equals(bananaFPCAddress)) {
+      throw new Error(
+        `Deployed BananaFPC address ${bananaFPC.address} does not match the genesis-funded address ` +
+          `${bananaFPCAddress}; the deterministic deploy params drifted from the genesis funding computation.`,
+      );
+    }
 
     this.bananaFPC = bananaFPC;