Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: introduce max_block_number (#5251)
Part of #4761. This adds a new validity condition to transactions called `max_block_number`, causing them to fail if the current block is larger than a requested max block. This can be used to construct proofs that are only valid if included before a certain block (which is exactly how SharedMutableStorage/SlowJoe/SlowUpdatesTree2.0 works). --- I made `max_block_number` an `Option<u32>` both to not have to include a initial value equal to the largest block, and also to avoid issues that arise from abuse of `std::unsafe::zeroed`. Many parts of the stack assume a (mostly) zeroed transaction is a valid one, but a `max_block_number` value of 0 is not useful. With `Option`, a zeroed value means no max block number was requested (`is_none()` returns true), and this entire issue is avoided. This property is initially set to `is_none()`, meaning there's no max block number constraint. The `PrivateContext` now has a `request_max_block_number` function that can be used to add constraints. Each time a lower max block number is seen it replaces the current one. The private kernel aggregates these across private calls and ends up with the smallest one. This value is stored in a new struct called `RollupValidationRequests`, an extension from @LeilaWang's work in AztecProtocol/aztec-packages#5236. These are validation requests accumulated during private and public execution that are forwarded to the rollup for it to check. Currently we only have `max_block_number`, but there may be more. Note that we currently have a slight duplication in the public kernal tail public inputs, but this is expected to be sorted out very soon as this struct is refactored. --- Note that in the end to end tests we're only testing that the sequencer drops the transaction, but not that the base rollup rejects this transaction (this is only tested in the rollup circuit unit tests). Testing this would require bypassing the sequencer tx validation logic and manually building a block, but this is a fairly involved endeavor and one that our infrastructure does not currently easily support. I'm still looking into a way to add this test.
- Loading branch information