zkEVM Projects Tracking Issue #2183
Description
Project 1: State tracker
This project enables the execution specs to output an object that lets us know what state has been touched during block processing.
Milestone 1: Create the state tracker API and
- Why
Creating the external API allows other components to start being built in parallel, since the internals are not important for those components (BALs and stateless)
- Related Issues/PRs
Milestone 2: Execution Witness building
- Why
Specifying how this object is built allows different clients to be used fungibly. Currently, we are in a situation where clients implement it differently, see here for example.
- Related Issues/PRs
Milestone 3: Spec release with blocks that contain the execution specs
- Why
Having an early spec release allows ELs to start following the specification and raising possible discrepancies.
- Related Issues/PRs
Project 2: Stateless execution
Once the ExecutionWitness can be created, we should have enough information to validate blocks statelessly(without a database).
This project enables the execution specs to test stateless execution and add more test vectors solely for the stateless execution.
Milestone 1: Modify stateless transition function to not explicitly rely on a database.
- Why
This doesn't change the behaviour of the specs, it solely prepares it for stateless execution by removing codepaths that were dependent on there being a database.
- Related Issues/PRs
Milestone 2: Integrate the ExecutionWitness such that blocks can be validated statelessly.
- Why
As Mario noted in our call, this closes the feedback loop from project 1, where the execution specs is also using the ExecutionWitness that it created to validate blocks.
- Related Issues/PRs
Milestone 3: Modify specs to test both the stateful validation path and the stateless path
- Why
This further closes the feedback loop by finding issues/discrepancies between the "normal" execution path and the stateless one. We expect existing clients will have a similar setup.
- Related Issues/PRs
Milestone 4: Spec release allowing clients to test stateful and stateless execution
- Why
On top of being able to cross check between stateful and stateless, once zkEVM is enabled and we are relying on it, this would be the default way to do testing.
- Related Issues/PRs
Milestone 5: Add new test vectors that are specifically for stateless execution.
- Why
Currently the test vectors in the execution specs are geared towards stateful execution. There would be no adversarial test vectors concerning an invalid/malformed ExecutionWitness