docs(yellow-paper): DA metering #5565

just-mitch · 2024-04-03T20:57:13Z

Please read contributing guidelines and remove this line.

just-mitch · 2024-04-03T20:57:28Z

docs(yellow-paper): DA metering #5565 👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @just-mitch and the rest of your teammates on Graphite

spalladino · 2024-04-04T17:34:28Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+```
+
+:::warning Fees are not enforced 
+It is not enforced by the protocol that the `transaction_fee` is actually paid. It is up to the sequencer to enforce this.


I know this is an old decision, but I still feel uneasy about it. Can we have non-enforced fees and 1559 at the same time? Could this lead to sequencers having differentiated payment channels that break standardization? Could this lead to bypassing paying fees to actors that are not strictly the sequencer?

I am uneasy about it as well.

I think my ideal case is that we do enforce them. Tradeoff is that this necessitates every transaction to have a public component to call teardown. This way, "inclusion fee" becomes the tip to the sequencer, and the other parts of transaction fee are burned. The primary departure here being that the tip to the sequencer is flat, not scaling with any particular gas used. But I don't think that is necessarily a problem.

If we keep it such that purely private transactions can be included, there will necessarily be a way to pay actors via back channels: why else would sequencers include pure private transactions? Block rewards? No MEV opportunity as they are pure private.

Edit: after discussion @spalladino suggests we don't burn da gas

Can we remind ourselves to talk about this topic on the call tomorrow? Sounds like a pretty important decision to get comfortable with - especially if you're uneasy about it Mitch, having written lots of this proposal :)

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

spalladino · 2024-04-04T17:52:30Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+    + private_kernel_public_inputs.end.gas_used.da_gas_used
+
+kernel_public_inputs.end.compute_gas_used :=
+    private_kernel_public_inputs.end.compute_gas_used


Why does the private kernel report compute gas used? I'd expect compute gas to be zero for all private functions.

Yes, agreed, it should be zero for private functions. I left it to reuse the GasUsed struct.

spalladino · 2024-04-04T18:35:50Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+Sequencers are paid in `$AZT` **on L1**.
+
+After a block has been published/verified, the sequencer is paid the sum of the `inclusion_fee`s in the block for all transactions with a non-zero `transaction_fee`.


Why only the inclusion_fee and not the rest?

Open conversation on what to pay the sequencer

spalladino · 2024-04-04T18:36:25Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+`fee_per_da_gas` and `fee_per_compute_gas` are not included in the published data per transaction because they are included in the block header.
+
+`transaction_fee` reflects the amount of `$AZT` that **was paid** for the transaction.


Does this need to be included? Can't it be computed from the other fields?

If it is zero, we know it was not paid. True, the amount can be computed from the other fields though.

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

spalladino · 2024-04-04T18:39:57Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+It will be the same for the `compute_gas_used`.
+
+### Out of gas


Can we add a section on what happens during a revert in a public function? I'd expect that the compute gas consumed so far is left as-is, but the DA gas for revertible is cleared out, since reverted side-effects don't go on-chain, right?

In app logic:
if we run out of compute gas:

the compute gas charged is the compute_gas_limit

the da gas charged is non_revertible.da_gas_used
if we run out of da gas:

the compute gas charged is non_revertible.compute_gas_used + revertible.compute_gas_used (up to point of oog)

the da gas charged is non_revertible.da_gas_used
if any other exception is thrown:

the compute gas charged is non_revertible.compute_gas_used + revertible.compute_gas_used (up to point of exception)

the da gas charged is non_revertible.da_gas_used

PhilWindle · 2024-04-08T11:16:29Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+These include: 
+
+- verification of transaction's private kernel proof
+- verification of nullifiers


Can this not be a per-nullifier quantity of l2 (or compute) gas?

You're right. I was only considering the transaction nullifier. We could absolutely add a component of the l2_gas_used that scales off the number of nullifiers emitted.

(Not a response to Phil, but a reaction to this bullet point): The cost of verifying nullifiers will depend on the number of nonzero nullifiers being inserted, so arguably does depend on the transaction.

iAmMichaelConnor · 2024-04-09T09:58:53Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+- We publish full transaction effects for each transaction
+
+:::warning
+Are these assumptions still valid?


Not sure if the final one "We publish full transaction effects for each transaction" is completely decided. I think there's still uncertainty around whether Aztec will publish the intents (or inputs) of transactions to L1/DA, or whether Aztec will publish state diffs (the outputs) of transactions to L1/DA.
I think it depends on the sequencer selection and preconfirmation designs, and on analysis of the amount of data that would need to be broadcast in each case, and on the auditability of history in a state-diff version of a chain.

We must support pure private transactions

By "pure private transactions", do we mean "a final kernel private proof with no enqueued public function calls"?

iAmMichaelConnor

Exceptional write-up! Thanks Mitch and team! There's so much to think about here, it's a very difficult subject indeed.
I've added comments in places. I confess I was skim-reading towards the end, so I might return to this later after a break to read the end in more depth.

iAmMichaelConnor · 2024-04-09T10:03:36Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+- "DA gas" -> "storage gas", as it covers state growth on L2 and publishing to DA
+- "L2 gas" -> "compute gas", as it covers computation on L2 and proving of public VM circuits
+- "L1 gas" -> "cross-chain gas", as it covers the cost of l2-to-l1 messages 
+


I think the suggested names could lead to confusion, and lots of verbal conversations where people misunderstand the gas being talked about.
E.g. "storage gas" is ambiguous to me because stuff also gets stored on L1.
E.g. "compute gas" is ambiguous because stuff also gets computed on L1.
E.g. "cross-chain gas" is ambiguous, because the DA layer will also be a chain, and because it's only for gas in one direction.

I'll read on, though. Maybe the names will grow on me as I read.

iAmMichaelConnor · 2024-04-09T10:24:52Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+# Kernel state diagram
+
+The state diagram is as follows:


I'd suggest making the data a different shape/colour from the circuits.

iAmMichaelConnor · 2024-04-09T10:27:17Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+# The Aztec token
+
+:::warning
+This token will not be called the Aztec token in the final implementation. It, and the symbol `$AZT`, are placeholders.


I still want to call it $JUICE

iAmMichaelConnor · 2024-04-09T10:34:41Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+These include: 
+
+- verification of transaction's private kernel proof
+- verification of nullifiers


(Not a response to Phil, but a reaction to this bullet point): The cost of verifying nullifiers will depend on the number of nonzero nullifiers being inserted, so arguably does depend on the transaction.

iAmMichaelConnor · 2024-04-09T10:41:40Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+- verification of nullifiers
+- proving the rollup circuits
+- verification of the root rollup proof on L1
+


There might be some items missing from this list: https://yp-aztec.netlify.app/docs/transactions/validity

iAmMichaelConnor · 2024-04-09T13:59:22Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+                note_hash_gas +
+                nullifier_gas +
+                l2_to_l1_message_gas +
+                public_data_writes_gas +


What about the compute costs associated with inserting this data into the data trees?

Note hashes tree

Nullifier tree

Archive tree

Public Data tree (might be covered by the vm's gas metering)

Also, the costs of inserting into the note hash tree are less than inserting into an indexed merkle tree. And the costs to include logs will be accompanied by a big cost to re-hash all of the logs on the DA layer (or on L1... not sure). And will L2_to_L1 messages make use of the DA layer? I thought they're published directly to L1? Perhaps there's an L2_to_L1 cost associated with creating the merkle root that then gets put on L1? Or is that root computed on L1 via a frontier tree? Lasse will remember the details.
All that is to say: the formulae for computing these various gas amounts might need to account for more.

What about the costs imposed on all other nodes (that aren't the sequencer creating this block)? I.e. the costs to pay the network to update their nodes' world state dbs and storing this information? (Or, rather than paying everyone (which obviously doesn't happen), it's more paying to outcompete anyone else who wants their tx to be included by the scarce resources of the network). This kind of cost feels very similar to why we pay for ethereum txs.

Should the cost of a new public data write cost more than overwriting an existing public data leaf?

Great points about adding data to the trees and their varying costs. I think we could add scalars to the computations below to compensate differently based on the work required for different insertions e.g.:

note_hash_gas = da_gas_per_field * (number of notes) * a nullifier_gas = da_gas_per_field * (number of nullifiers) * b

I think doing something like that is predicated on being quite sure that the relative costs of insertions will be what we presently think they are

iAmMichaelConnor · 2024-04-09T14:29:44Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+Note: it does not know by inspecting the enqueued call itself if the `pay_fee` function will be called, unless it has explicitly inspected/whitelisted the function ahead of time.
+
+However, it will know that if `pay_fee` is called, then message sender is the one that will pay the fee, and thus must have a balance greater than:


then message sender is the one that will pay the fee

This might not be a reliable indicator for whose balance will be paying the fee. The msg_sender of a private->public call could be a randomised value, to give the user privacy over which contract is making the call from private-land. The actual msg.sender that pays the fee could be some public contract that is enqueued, right? Or perhaps pay_fee might be invoked via a transfer_from call?
I might not be making sense, because I've forgotten how this part works.

Presently the pay_fee function deducts the balance of context.msg_sender. Maybe this is not correct.

iAmMichaelConnor · 2024-04-09T14:30:46Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+- `max_fee_per_l2_gas`
+- `teardown_l2_gas`
+- `l1_gas_limit`
+- `max_fee_per_l1_gas`


I'd suggest separating out these gas prices from the gas limits (or renaming the GasLimits struct)

iAmMichaelConnor · 2024-04-09T14:36:12Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+### Global gas limits
+
+The mechanics above imply that there will be a single global gas limit (for each gas dimension) for all enqueued public calls. However, users will still be able to specify individual gas limits for each *nested* call within an enqueued public call.


users will still be able to specify individual gas limits for each nested call within an enqueued public call

How do they do this? Are there parameters that are baked into the "call" opcodes of the avm? By "users" do you mean the smart contract developer who designs how the nested call is called (and therefore how much gas to send to it)?

Wait, so if I have a tx with two enqueued public function calls A1 and B1:

I specify a global gas limit of 100 for all enqueued public function calls.

But then we're saying I can specify individual gas limits for each nested function call? Is it the caller of the function who can specify these, or the smart contract developer?

So if A1 calls A1 and B1 calls B2, and I (or the functions A1 & B1?) can somehow specify gas limits of:

A1: 50 gas, but it uses 20 gas.

A2: 25 gas, but it uses 20 gas.

B1: 50 gas, but it uses 20 gas.

B2: 30 gas, but it uses 20 gas.

Would my tx succeed or fail?

I understand your example working as:

A1 starts with 100 gas, nobody can give this a gas limit different from the global tx limit.

A1 calls A2 and the developer specifies a limit of 25 gas. If it tries to use more it will revert and can be caught by A1, consuming only 25 of A1's limit (the 100 limit it started with).

A1 itself uses 20 gas. So, in your example, both A1 and A2 use 20 each, 40 total.

B1 now has an effective limit of 60, again neither the developer or the user can set this themselves

B1 calls B2 with a limit of 30, They both use 20 gas which does not breach any limit.

80 gas used in total.

iAmMichaelConnor · 2024-04-09T14:44:54Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+Thus, the user is charged the full `l2_gas_limit`.
+
+However, we drop the DA and L1 gas used associated with app logic, i.e.:


Is this because it would be unfair to charge these costs to the user, because these costs will never be borne by the sequencer/l1/da?

Yes. I think it's more correct to say we drop all DA and L1 gas used values for revertible side-effects. This includes anything from private execution.

PhilWindle · 2024-04-10T08:42:24Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+:::warning
+Are these assumptions still valid?
+:::


I think at this stage all these assumptions are valid

PhilWindle · 2024-04-10T08:47:43Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+The fees per unit gas are set by the protocol, and are not part of the user's transaction.
+
+The fees are:


I'm not really sure about this. This feels very 1559-ish, which I think it is far from certain that we plan to do.

PhilWindle · 2024-04-10T09:01:02Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+However, it will know that if `pay_fee` is called, then message sender is the one that will pay the fee, and thus must have a balance greater than:
+```
+msg_sender.balance >= max_fee_per_da_gas * (da_gas_limit + teardown_da_gas)


I'm a bit confused. Earlier it said:

A transaction fee is the maximum amount of $AZT that a user can be charged for a transaction.

transaction_fee = fee_per_da_gas * da_gas_used + fee_per_l2_gas * l2_gas_used + fee_per_l1_gas * l1_gas_used + inclusion_fee

But this suggests that the balance (and the fee paid) are based on max_fee_per_*_gas. I think this last part is correct, I'm not really sure of the purpose of the fee_per_*_gas values.

Yes, the transaction_fee is the true/final amount, and this computation represents the maximal that the user could be charged, so the sequencer can run this computation ahead of time to see if it is possible for the sender to even pay the max they have suggested.

PhilWindle · 2024-04-10T09:19:53Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+
+### All other reverts in App Logic
+
+These follow the same logic as OutOfDAGas reverts in app logic.


Presumably not for OutOfL2Gas? If a nested call uses all of it's e.g. 100 L2 gas, that amount is still added to the accumulated gas used of it's caller?

PhilWindle · 2024-04-10T09:24:00Z

yellow-paper/docs/gas-and-fees/gas-metering-and-fees.md

+Is there a more clean way to ensure the fee is paid other than this very specific boolean?
+How does the VM know that the `pay_fee` function has been called?
+Would we rather the VM return function calls that were made, and have the kernel check for the `pay_fee` function?
+How do we convince the kernel that the machine state provided in the public inputs is correct?


I think we should come up with a way of enshrining pay_fee. Say, in the base rollup for example. All it does is subtract an amount of the gas token from a balance. I think it would significantly simplify things.

If we did this in the base rollup then it can be used for paying for private only transactions and we wouldn't need to prove a VM and kernel iteration for it.

Does this sound sensible to you @iAmMichaelConnor

@just-mitch

Adds gas limits, max fee per gas, actual fee per gas, and gas used to circuit structs. These structs are not populated for now, they are just defined. Also updates the corresponding definitions in the yellow paper. Follows the spec outlined by @just-mitch in #5565 but for the following changes: - `GasLimits` is renamed to `GasSettings` (following @iAmMichaelConnor suggestion) - Info for each dimension in `GasSettings` (da/l1/l2) is bundled into a `DimensionGasSettings` struct - `GasSettings` in `PrivateKernelPublicInputs` is stored inside the `ConstantData` struct - Bundled each `fee_per_xx_gas` field in `GlobalVariables` into a `GasFees` struct - Did not yet add the `pending_header` in `CombinedConstantData`

just-mitch changed the title ~~yellow paper changes to document changes for DA metering~~ docs: yellow paper changes to document changes for DA metering Apr 3, 2024

just-mitch changed the title ~~docs: yellow paper changes to document changes for DA metering~~ docs(yellow-paper): DA metering Apr 3, 2024

just-mitch force-pushed the docs-da-metering branch from 2725685 to a61f646 Compare April 4, 2024 15:45

just-mitch marked this pull request as ready for review April 4, 2024 15:46

spalladino reviewed Apr 4, 2024

View reviewed changes

just-mitch force-pushed the docs-da-metering branch 2 times, most recently from b3de270 to 27cec22 Compare April 5, 2024 15:09

yellow paper changes to document changes for DA metering

c4d4e04

just-mitch force-pushed the docs-da-metering branch from 27cec22 to c4d4e04 Compare April 5, 2024 18:56

PhilWindle reviewed Apr 8, 2024

View reviewed changes

iAmMichaelConnor reviewed Apr 9, 2024

View reviewed changes

PhilWindle reviewed Apr 10, 2024

View reviewed changes

spalladino mentioned this pull request Apr 10, 2024

feat: Update circuits structs with gas info #5677

Merged

just-mitch closed this Apr 26, 2024

ludamad deleted the docs-da-metering branch August 22, 2024 15:25


		Sequencers are paid in `$AZT` on L1.

		After a block has been published/verified, the sequencer is paid the sum of the `inclusion_fee`s in the block for all transactions with a non-zero `transaction_fee`.


		`fee_per_da_gas` and `fee_per_compute_gas` are not included in the published data per transaction because they are included in the block header.

		`transaction_fee` reflects the amount of `$AZT` that was paid for the transaction.


		It will be the same for the `compute_gas_used`.

		### Out of gas


		Note: it does not know by inspecting the enqueued call itself if the `pay_fee` function will be called, unless it has explicitly inspected/whitelisted the function ahead of time.

		However, it will know that if `pay_fee` is called, then message sender is the one that will pay the fee, and thus must have a balance greater than:


		### Global gas limits

		The mechanics above imply that there will be a single global gas limit (for each gas dimension) for all enqueued public calls. However, users will still be able to specify individual gas limits for each nested call within an enqueued public call.


		Thus, the user is charged the full `l2_gas_limit`.

		However, we drop the DA and L1 gas used associated with app logic, i.e.:


		The fees per unit gas are set by the protocol, and are not part of the user's transaction.

		The fees are:


		### All other reverts in App Logic

		These follow the same logic as OutOfDAGas reverts in app logic.

docs(yellow-paper): DA metering #5565

docs(yellow-paper): DA metering #5565

Conversation

just-mitch commented Apr 3, 2024

just-mitch commented Apr 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iAmMichaelConnor left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhilWindle Apr 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhilWindle Apr 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PhilWindle Apr 10, 2024 •

edited

Loading

PhilWindle Apr 10, 2024 •

edited

Loading