AztecProtocol
refactor(gas): inbox optimisations, delayed validation
The busy mans inbox optimisations, altering the design to use a snapshotted hash-chain that can be used to derive ranges of the in_hash value for block production.
Alters the time of fetching from propose to proof submission and cut costs using the snapshots.
Does create a new edge case for provers, where no snapshots have been greated including the full section they need, but addressed by changes on the prover node.
- #15898
👈 (View in Graphite) next
This stack of pull requests is managed by Graphite. Learn more about stacking.
More importantly, I don't understand how it actually reduces costs? It seems like it mainly moves costs from the sequencer to the user? If that is the case, so be it, but clarity would be good there, especially since we're seeing an increase in the benchmark with non-empty blocks.
Costs in the benchmark looks like they did increase, because the previous benchmark was updated before the setup had non-empty blocks, so the enbox write was a 0 write, the actual is higher but you won't see it alone here. It reduces from the sequencers because it does not need to read at propose. And the hash chain reduces the number of storage reads needed. The current cost is still fairly high because it needs to check against the inHashes but that is what can be moved into the circuits.
Separate to that. As discussed, holding off these because we don't actually need it for ignition because we can entirely skip the inbox there.