chore!: update base gas values by LeilaWang · Pull Request #20569 · AztecProtocol/aztec-packages

LeilaWang · 2026-02-16T21:49:40Z

Use the gas per ms of the AVM to measure the base L2 gas values.

iAmMichaelConnor

Thanks so much for doing this, Leila.

I've added a couple of suggestions for comments.

You'll see I have lots of questions about the methodology, but much of that can be clarified later in a script that enables someone to recreate all of these numbers (as we've just discussed on slack together).

I have some doubts here and there, but having these numbers is better than 0's for alpha. We can iron out the doubts in time for the next release later in the year.

iAmMichaelConnor · 2026-02-16T22:10:31Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+pub global MANA_PER_MS: u32 = 9083;
+// The conversion rate from L1 gas to L2 gas is set to 1000.
+pub global L1_TO_L2_GAS_CONVERSION_RATE: u32 = 1000;
+// Some values are measured per checkpoint or per epoch and are distributed across all txs, assuming 1 TPS, which


Please could you explain why the choice of 1000?

This is arbitrary 😅 But this makes the L1 cost take up only 0.01 of the total fixed l2 gas. Should we increase it?

I reckon we delete it.
I asked Claude for a refresher on fees, and specifically how the user is charged for their share of L1 gas if they only pay in L2 gas. Essentially, the user has to pay a minimum fee_per_gas, and it is this minimum fee_per_gas (gas price) which kind of covers the L1 component of the user's cost, instead of L1 gas metering.

Claude:

The minimum mana fee is deterministic and oracle-derived

The rollup contract computes a single deterministic fee per mana for each block. The sequencer has no discretion —
it's enforced as an exact equality on L1:

// ProposeLib.sol
require(_args.header.gasFees.feePerL2Gas == _args.manaMinFee, ...);

Not >=, but ==. The block's fee is exactly what the formula produces.

Two snapshots feed into it

The formula in FeeLib.getManaMinFeeComponentsAt() uses two oracle values:

L1 gas prices — a lagged snapshot of block.basefee and blob base fee (2-5 slots stale)

ETH/FeeJuice exchange rate (ethPerFeeAsset) — converts the ETH-denominated cost into Fee Juice terms

The computation is:

costInEth = (300K * L1_baseFee + 3 * 131K * L1_blobFee) / manaTarget [sequencer]
+ (1M * L1_baseFee / epochDuration) / manaTarget + param [prover]

totalInEth = costInEth * congestionMultiplier(excessMana)

feePerMana = totalInEth / ethPerFeeAsset [convert to Fee Juice]

The user's position

The user sets maxFeesPerGas when creating their tx. Their tx is only included in a block where:

block.feePerMana <= user.maxFeesPerGas

If the oracle-derived minimum exceeds the user's max, the tx sits in the mempool until either:

L1 fees drop, or

The exchange rate shifts

Once included, the user pays at least gasUsed * block.feePerMana. They can pay slightly more via priority fees, but
never more than their maxFeesPerGas.

So to answer directly

Yes — the user is forced to pay a minimum mana fee that is mechanically derived from two snapshots: the L1 gas price
snapshot and the ETH/FeeJuice exchange rate snapshot. Both are slightly stale. The user's only lever is to set
maxFeesPerGas high enough to be included, or wait for conditions to change.

iAmMichaelConnor · 2026-02-16T22:12:27Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+// -----------
+// The following values were calculated by running tests to benchmark AVM simulation and proving time
+// (avm_opcode_spam.test.ts) and determining the average gas per second. Then, we ran the tx validation benchmark
+// (tx_validation.test.ts) and multiplied the validation time by the average gas per second to estimate gas costs.


I couldn't find this file. I found a tx_validator_bench.test.ts?

Oooops yes that's the one!

iAmMichaelConnor · 2026-02-16T22:15:11Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+// TODO: We need a test suite to formalize and validate these measurements.
+//
+// The fixed L2 gas consists of:
+// - Tx validation (common checks for both private-only and public txs): 9.86ms


Does this include proof verification, checking fee juice balance, duplicate nullifier checks, contract class log hashing? I'm surprised it's this quick. I'd have expected longer.
Also, shouldn't duplicate nullifier checks be dependent on the number of nullifiers; and contract class log hashing be dependent on the size of the contract class log?

Edit: I can see the contract class log hashing is separate, below.

That includes proof verification and checking fee juice balance.
You are right, checking duplicate nullifiers should be priced per nullifier. I left it as 0 as I thought it was negligible (< 0.25ms). But multiplying by the big mana per ms will actually result in thousands of gas. Will add it!

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

iAmMichaelConnor · 2026-02-16T22:26:30Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+// === L2 gas for side effects from private-only txs ===
+// The Gas for batch insert note hashes is included in the fixed L2 gas.
 pub global L2_GAS_PER_NOTE_HASH: u32 = 0;
+// The Gas for batch insert nullifiers is included in the fixed L2 gas.


Suggested change

// The Gas for batch insert nullifiers is included in the fixed L2 gas.

// The Gas for batch insert note hashes is included in the fixed L2 gas.

// The rollup always inserts a fixed-size subtree of nullifiers for each tx (even if there are no nullifiers to insert).

iAmMichaelConnor · 2026-02-16T22:28:24Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+// The time for validating duplicate nullifiers is negligible.
 pub global L2_GAS_PER_NULLIFIER: u32 = 0;


This surprises me (that the cost of validating duplicate nullifiers is negligible), because this is cited as a zcash scaling problem. Maybe the number of nullifiers in the test db wasn't large enough to trigger a slowdown. In a year, there could be 2GB of nullifiers (if all 64 are used every tx, which is of course unrealistic). Still... a DB of the order of GBs really should be used to test duplicate lookup times.

iAmMichaelConnor · 2026-02-16T22:29:47Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+// Gas for writing message on L1: 24011 L1 gas for inserting epoch out hash root to the outbox.
+// Assuming 1 l2-to-l1 message per checkpoint.
+pub global L2_GAS_PER_L2_TO_L1_MSG: u32 = 750 * L1_TO_L2_GAS_CONVERSION_RATE;


Where does 750 come from?

24011 / 32. 32 is the number of checkpoints per epoch.
Should we assume there will be more l2-to-l1 message per checkpoint/epoch?

I think we can observe alpha and change it later :)

iAmMichaelConnor · 2026-02-16T22:50:23Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+//   - parity-base: 22084ms * 4
+//   - parity-root: 22825ms
+//   - tx-merge: 11892ms * 70
+//   - first-block-root: 17914ms


Suggested change

// - first-block-root: 17914ms

// - first-block-root: 17914ms

// - This slightly over-estimates the cost, because subsequent block-root circuits don't have the overhead

// of verifying parity-root circuits (and other checks that only happen in the first-block-root).

iAmMichaelConnor · 2026-02-16T22:51:10Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+//   - parity-root: 22825ms
+//   - tx-merge: 11892ms * 70
+//   - first-block-root: 17914ms
+//   - checkpoint-root-single-block: 54345ms


Is this similar in cost to the other checkpoint roots? I think it is.

The other checkpoint root (for 2 blocks) is more expensive. But I picked these circuits to measure as if there's only 1 block per checkpoint. I will check if it's similar in cost if there are 2 blocks per checkpoint.

It's 687ms less if we have 2 blocks per checkpoint.

Lovely, that difference sounds broadly negligible, so probably fine to leave as it is? Wdyt?

(Although might be worth writing a comment to explain so, if you're still adding extra comments)

iAmMichaelConnor · 2026-02-17T00:03:12Z

noir-projects/noir-protocol-circuits/crates/types/src/constants.nr

+// - Cost on L1 (assuming 1tps):
+//   - Propose a checkpoint: 325171 L1 gas -> 4517 per tx
+//   - Prove an epoch: 885319 L1 gas -> 384 per tx
+pub global FIXED_L2_GAS: u32 = 44374 * MANA_PER_MS + (4517 + 384) * L1_TO_L2_GAS_CONVERSION_RATE;


See big claudey comment. I think we can kill the L1 component (i.e. the + (4517 + 384) * L1_TO_L2_GAS_CONVERSION_RATE; addend

iAmMichaelConnor · 2026-02-17T16:40:43Z

I don't know how to undo my approval, but we're still discussing this and have doubts

LeilaWang added 2 commits February 16, 2026 15:21

Define DA_GAS_PER_FIELD

d727b87

Update base gas values.

711a317

LeilaWang requested review from IlyasRidhuan, fcarreiro and jeanmon as code owners February 16, 2026 21:49

LeilaWang removed request for IlyasRidhuan, fcarreiro and jeanmon February 16, 2026 21:49

Fix.

6a4d02c

iAmMichaelConnor approved these changes Feb 16, 2026

View reviewed changes

iAmMichaelConnor reviewed Feb 17, 2026

View reviewed changes

LeilaWang added 7 commits February 17, 2026 00:41

Address comments.

8e866e7

Fix.

12e280b

Lower mana per ms.

19d87bb

Fix kernelless gas meter.

1a48d79

Revert changes.

1847c95

Update bins.

8612e61

Fix test.

1d6a0af

LeilaWang closed this Feb 23, 2026

	// The Gas for batch insert nullifiers is included in the fixed L2 gas.
	// The Gas for batch insert note hashes is included in the fixed L2 gas.
	// The rollup always inserts a fixed-size subtree of nullifiers for each tx (even if there are no nullifiers to insert).

		// The time for validating duplicate nullifiers is negligible.
		pub global L2_GAS_PER_NULLIFIER: u32 = 0;

Comments

Conversation

LeilaWang commented Feb 16, 2026

Uh oh!

iAmMichaelConnor left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iAmMichaelConnor commented Feb 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

iAmMichaelConnor left a comment •

edited

Loading