zkEVM Projects Tracking Issue

## 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](https://github.com/paradigmxyz/reth/issues/20365#issuecomment-3664196323) 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

#### - Related Issues/PRs