Build blocks using Reth 1.1.0 #115
Conversation
|
@hashcashier @SchmErik iiuc v1.81 toolchain should now be ready to use! |
| @@ -95,6 +95,7 @@ impl<DB: DatabaseRef + Recoverable> DatabaseRef for Wrapper<DB> { | |||
|
|
|||
| impl<DB: DatabaseCommit + Recoverable> DatabaseCommit for Wrapper<DB> { | |||
| fn commit(&mut self, changes: HashMap<Address, Account>) { | |||
| dbg!("COMMIT!"); | |||
There was a problem hiding this comment.
I believe that should be removed.
| // resolve storage orphans | ||
| if let Some((trie, _)) = storage_tries.get_mut(&account_proof.address) { | ||
| for storage_proof in account_proof.storage_proof { | ||
| // let proof_nodes = parse_proof(&storage_proof.proof)?; |
There was a problem hiding this comment.
There is still quite a bit of commented code, this should be removed
| @@ -151,6 +153,48 @@ impl<N: Network, R: CoreDriver, P: PreflightDriver<R, N>> PreflightDB<N, R, P> { | |||
| apply_changeset(&mut self.inner, state_changeset) | |||
| } | |||
|
|
|||
| pub fn sanity_check(&mut self, state_changeset: StateChangeset) -> anyhow::Result<()> { | |||
| mpt_from_proof(&proof_nodes).context("invalid storage_proof")?; | ||
| let proof_nodes = parse_proof(&storage_proof.proof) | ||
| .context("extend_proof_tries/parse storage proof")?; | ||
| mpt_from_proof(&proof_nodes).context(format!( |
| Ok(vec.into_iter().collect()) | ||
| } | ||
| } | ||
|
|
||
| pub mod opt_ordered_map { |
There was a problem hiding this comment.
This is never used, ordered_map + default is used instead
|
|
||
| fn chain_spec(chain: &NamedChain) -> Option<Arc<Self::ChainSpec>> { | ||
| match chain { | ||
| NamedChain::Mainnet => Some(MAINNET.clone()), |
There was a problem hiding this comment.
We do not support all possible forks. I know for a fact that the pre Byzantine validation is not correct in Reth: Back then, the TxReceipt still contained intermediate state hashes which was left out in Reth for performance reasons https://github.com/paradigmxyz/reth/blob/e3702cfc87449294da061f02a571a23061b8ab50/crates/ethereum/consensus/src/validation.rs#L31
So we must exclude at least everything before Byzantine.
There was a problem hiding this comment.
What about possible future forks that are (or will be with newer reth versions) only partially supported? Do they also need to be explicitly excluded?
There was a problem hiding this comment.
I assume the submodule was removed to prevent Cargo from always checking out the huge tests.
However, then the ef-tests should be adapted to include a script or documentation that checks out the EF tests in the correct version
| @@ -1,6 +1,10 @@ | |||
| [workspace] | |||
| resolver = "2" | |||
| members = ["guests", "host", "lib", "primitives", "testing/ef-tests"] | |||
| members = [ | |||
There was a problem hiding this comment.
The ef-tests have been removed here. Thus, they have not been adapted to the new reth version and will not compile.
| - uses: risc0/cargo-install@v1 | ||
| with: | ||
| crate: cargo-binstall | ||
| - run: cargo binstall -y --force cargo-risczero@$RISC0_VERSION | ||
| - run: cargo risczero install --version $RISC0_TOOLCHAIN_VERSION | ||
| - run: cargo test --workspace --all-targets -F ef-tests,debug-guest-build |
There was a problem hiding this comment.
We should absolutely not disable the ef-tests. Even when we are now using reth they contain crucial testcases that we must also pass.
| } | ||
|
|
||
| #[derive(Default)] | ||
| pub struct Wrapper<T: Recoverable> { |
There was a problem hiding this comment.
An alternative to "abusing" the drop to get the Database back is to move the DB in and out similar to https://github.com/risc0/risc0-ethereum/blob/73eebd4efb283c7f99748d45fc730a53ee2edf5c/steel/src/contract.rs#L211
However, this should probably not also be in this PR.
This PR migrates
zethfrom directly usingrevmto usingrethfor building blocks. This allows zeth to support all forks supported byreth. The changes are an overhaul of many of zeth's internal components and project structure. Notably, because of Cargo's feature unification, and reth's dependence on feature flags for enabling/disabling OP functionality, two separate zeth binaries are now necessary.The project has been restructured into the following crates:
zeth-coreLibrary for defining and using the sparse MPT to statelessly build a block using reth.zeth-core-ethereumSpecialization of the core library for Ethereum blocks.zeth-core-optimismSpecialization of the core library for Optimism blocks.zeth-preflightLibrary for populating the data required to statelessly build a block usingzeth-core.zeth-preflight-ethereumSpecialization of the preflight library for Ethereum RPCs.zeth-preflight-optimismSpecialization of the preflight library for Optimism RPCs.zeth-guests-reth-ethereumA binary for running the stateless block building process for Ethereum blocks.zeth-guests-reth-optimismA binary for running the stateless block building process for Optimism blocks.zeth-guestsLibrary for exporting the compiled rv32im bytecode ofzeth-guests-reth.zethA library for running a CLI to use the RISC Zero zkVM to generate/verify proofs for the stateless block building process.zeth-ethereumA binary using thezethcrate for Ethereum blocks.zeth-optimismA binary using thezethcrate for Optimism blocks.zeth-benchmarkA binary for benchmarking proving performance for randomly sampled blocks.Functionality changes:
Note: v1.81 of the toolchain is required:
Note: Separate binaries must be built individually
Issues affected:
reth 1.0matiching or compatible depenancies #110