diff --git a/README.md b/README.md index 3c08cf8ed4..a5c10da9fe 100644 --- a/README.md +++ b/README.md @@ -286,14 +286,15 @@ At a high level, the following new parts are added to the node: | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | | 0 | Users can deposit Eth in the L1 (Ethereum) and receive the corresponding funds on the L2. | ✅ | | 1 | The network supports basic L2 functionality, allowing users to deposit and withdraw funds to join and exit the network, while also interacting with the network as they do normally on the Ethereum network (deploying contracts, sending transactions, etc). | ✅ | -| 2 | The block execution is proven with a RISC-V zkVM and the proof is verified by the Verifier L1 contract. | 🏗️ | -| 3 | The network now commits to state diffs instead of the full state, lowering the commit transactions costs. These diffs are also submitted in compressed form, further reducing costs. It also supports EIP 4844 for L1 commit transactions, which means state diffs are sent as blob sidecars instead of calldata. | ❌ | -| 4 | The L2 supports native account abstraction following EIP 7702, allowing for custom transaction validation logic and paymaster flows. | ❌ | -| 5 | Support multiple L2s sharing the same bridge contract on L1 for seamless interoperability. | ❌ | -| 6 | The L2 can also be deployed using a custom native token, meaning that a certain ERC20 can be the common currency that's used for paying network fees. | ❌ | -| 7 | The L2 has added security mechanisms in place, running on Trusted Execution Environments and Multi Prover setup where multiple guarantees (Execution on TEEs, zkVMs/proving systems) are required for settlement on the L1. This better protects against possible security bugs on implementations. | ❌ | -| 8 | The network can be run as a Based Rollup, meaning sequencing is done by the Ethereum Validator set; transactions are sent to a private mempool and L1 Validators that opt into the L2 sequencing propose blocks for the L2 on every L1 block. | ❌ | -| 9 | The L2 can be initialized in Validium Mode, meaning the Data Availability layer is no longer the L1, but rather a DA layer of the user's choice. | ❌ | +| 2 | The block execution is proven with a RISC-V zkVM and the proof is verified by the Verifier L1 contract. | ✅ | +| 3 | The network now commits to state diffs instead of the full state, lowering the commit transactions costs. These diffs are also submitted in compressed form, further reducing costs. It also supports EIP 4844 for L1 commit transactions, which means state diffs are sent as blob sidecars instead of calldata. | 🏗️ | +| 4 | Use our own EVM implementation | 🏗️ | +| 5 | The L2 supports native account abstraction following EIP 7702, allowing for custom transaction validation logic and paymaster flows. | ❌ | +| 6 | Support multiple L2s sharing the same bridge contract on L1 for seamless interoperability. | ❌ | +| 7 | The L2 can also be deployed using a custom native token, meaning that a certain ERC20 can be the common currency that's used for paying network fees. | ❌ | +| 8 | The L2 has added security mechanisms in place, running on Trusted Execution Environments and Multi Prover setup where multiple guarantees (Execution on TEEs, zkVMs/proving systems) are required for settlement on the L1. This better protects against possible security bugs on implementations. | ❌ | +| 9 | The network can be run as a Based Rollup, meaning sequencing is done by the Ethereum Validator set; transactions are sent to a private mempool and L1 Validators that opt into the L2 sequencing propose blocks for the L2 on every L1 block. | ❌ | +| 10 | The L2 can be initialized in Validium Mode, meaning the Data Availability layer is no longer the L1, but rather a DA layer of the user's choice. | ❌ | ### Milestone 0 @@ -331,8 +332,8 @@ The L2's block execution is proven with a RISC-V zkVM and the proof is verified | Task Description | Status | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | | On the EVM, return all storage touched during block execution to pass to the prover as a witness | ✅ | -| Make the `onChainproposer` L1 contract verify the SNARK proof on the `verify` function. | 🏗️ | -| Add a `proverClient` binary that asks the sequencer for witness data to prove, generates proofs of execution and submits proofs to the `proverServer` component (see below) | 🏗️ | +| Make the `onChainproposer` L1 contract verify the SNARK proof on the `verify` function. | ✅ | +| Add a `proverClient` binary that asks the sequencer for witness data to prove, generates proofs of execution and submits proofs to the `proverServer` component (see below) | ✅ | | Add a `proverServer` component that feeds the `proverClient` with block witness data to be proven and delivers proofs to the `proposer` to send the L1 transaction for block verification | ✅ | ### Milestone 3: State diffs + Data compression + EIP 4844 (Blobs) @@ -345,13 +346,27 @@ It also supports EIP 4844 for L1 commit transactions, which means state diffs ar | Task Description | Status | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ | -| The sequencer sends state diffs to the prover instead of full transaction data. | ❌ | +| The sequencer sends state diffs to the prover instead of full transaction data. | ✅ | | On the prover, prove the state diffs compression | ❌ | -| On the `proposer`, send the state diffs through a blob in a EIP 4844 transaction. | ❌ | +| On the `proposer`, send the state diffs through a blob in a EIP 4844 transaction. | ✅ | | Adapt the prover to prove a KZG commitment to the state diff and use the point evaluation precompile to show that the blob sent to the L1 is indeed the correct one through a proof of equivalence protocol | ❌ | | Add a command to the CLI to reconstructing the full L2 state from all the blob data on the L1. | ❌ | -### Milestone 4: Account Abstraction +### Milestone 4: Own EVM Implementation + +Finish our own EVM implementation (`levm`) to be able to add custom behaviour to the network (like account abstraction below). + +#### Status + +| Task Description | Status | +| ---------------------------------------------------- | ------ | +| Implement all opcodes | ✅ | +| Pass all execution (non-precompile) EF tests | 🏗️ | +| Implement all precompiles | 🏗️ | +| Pass all execution EF tests | 🏗️ | +| Full Ethereum Rust Integration (pass all Hive tests) | 🏗️ | + +### Milestone 5: Account Abstraction The L2 supports native account abstraction following EIP 7702, allowing for custom transaction validation logic and paymaster flows. @@ -362,7 +377,7 @@ The L2 supports native account abstraction following EIP 7702, allowing for cust | Add support for `SET_CODE_TX_TYPE` transactions (i.e. implement EIP 7702). | ❌ | | Add examples of WebAuthn signing and paymaster flows using EIP 7702 | ❌ | -### Milestone 5: L2s interoperability +### Milestone 6: L2s interoperability Support multiple L2s sharing the same bridge contract on L1 for seamless interoperability. @@ -375,7 +390,7 @@ Support multiple L2s sharing the same bridge contract on L1 for seamless interop TODO: Expand on tasks about proper interoperability between chains (seamlessly bridging between chains, etc). -### Milestone 6: Custom Native token +### Milestone 7: Custom Native token The L2 can also be deployed using a custom native token, meaning that a certain ERC20 can be the common currency that's used for paying network fees. @@ -387,7 +402,7 @@ The L2 can also be deployed using a custom native token, meaning that a certain | On the `commonBridge`, for custom native token deposits, `msg.value` should always be zero, and the amount of the native token to mint should be a new `valueToMintOnL2` argument. The amount should be deducted from the caller thorugh a `transferFrom`. | ❌ | | On the CLI, add support for custom native token deposits and withdrawals | ❌ | -### Milestone 7: Security (TEEs and Multi Prover support) +### Milestone 8: Security (TEEs and Multi Prover support) The L2 has added security mechanisms in place, running on Trusted Execution Environments and Multi Prover setup where multiple guarantees (Execution on TEEs, zkVMs/proving systems) are required for settlement on the L1. This better protects against possible security bugs on implementations. @@ -399,7 +414,7 @@ The L2 has added security mechanisms in place, running on Trusted Execution Envi | Support verifying multiple different zkVM executions on the `onChainProposer` L1 contract. | ❌ | | Support running the operator on a TEE environment | ❌ | -### Milestone 8: Based Contestable Rollup +### Milestone 9: Based Contestable Rollup The network can be run as a Based Rollup, meaning sequencing is done by the Ethereum Validator set; transactions are sent to a private mempool and L1 Validators that opt into the L2 sequencing propose blocks for the L2 on every L1 block. @@ -411,7 +426,7 @@ The network can be run as a Based Rollup, meaning sequencing is done by the Ethe TODO: Expand on this. -### Milestone 9: Validium +### Milestone 10: Validium The L2 can be initialized in Validium Mode, meaning the Data Availability layer is no longer the L1, but rather a DA layer of the user's choice.