We should collect some benchmarks about the current protocol.
We should generate this table programmatically. The crypto team have done this nicely; take inspiration from there.
Please add to the table directly, if you can think of more :)
| Category |
Name |
Units |
Value |
Comment |
Justification |
| Bandwidth |
Proof size |
KB |
|
A row for each core protocol circuit. |
Helps assess bandwidth requirements for sequencers & provers. |
| Bandwidth |
Public inputs size |
KB |
|
A row for each core protocol circuit. |
Helps assess bandwidth requirements for sequencers & provers. |
| Bandwidth |
Private inputs size |
KB |
|
A row for each core protocol circuit. |
Provers will either need to derive the private inputs, or be given them. This will affect whether they're stateless or stateful. |
| Cost |
L1 calldata per rollup |
KB & Gas & $ |
|
A row for several sizes of rollup (# txs). Rows testing various scenarios (because tx sizes will vary) |
Useful for estimating the benefits of EIP-4844. |
| Cost |
L1 execution cost per rollup |
Gas & $ |
|
A row for several sizes of rollup (# txs). Rows testing various scenarios (because tx sizes will vary) |
Interesting. |
| Time |
Time to simulate a rollup (ignoring proper proofs) |
s |
|
A row for several sizes of rollup (# txs). The amount of RAM used, and the specs of the machine used is important. |
Helps estimate fixed rollup times (regardless of cryptography). Helps identify need for optimisation. |
| Time |
Time to trial-decrypt a rollup |
s |
|
A row for several sizes of rollup (# txs). The amount of RAM used, and the specs of the machine used is important. Rows for doing this in wasm needed. |
Helps with articulating the need for scaing solutions |
| Time |
Time to trial-decrypt the private data tree's history |
s |
|
Rows for sizes (# leaves) |
Helps identify the need for optmisation |
| Time |
Time for a public node to process a newly-submitted rollup |
s |
|
A row for several sizes of rollup (# txs). The amount of RAM used, and the specs of the machine used is important. |
Helps identify the need for optmisation |
| Time |
Time for a public node to sync to the entire network history |
s |
|
Rows for several 'sizes' of blockchain history. |
Helps identify the need for optmisation |
| Storage |
Storage requirements for a public node |
GB |
|
Use the proper tree sizes |
Helps assess hardware requirements |
| Storage |
Storage requirements for a private note |
GB |
|
Different scenarios, for various numbers of owned notes |
Helps assess user hardware requirements |
Combine with the cryptography metrics being pulled-together by Cody.
* "Core protocol" = any circuit which is not a Noir smart contract circuit.
### Tasks
- [ ] https://github.com/AztecProtocol/aztec-packages/issues/2506
We should collect some benchmarks about the current protocol.
We should generate this table programmatically. The crypto team have done this nicely; take inspiration from there.
Please add to the table directly, if you can think of more :)
Combine with the cryptography metrics being pulled-together by Cody.
* "Core protocol" = any circuit which is not a Noir smart contract circuit.