Introduce trace processing for multiple storage tries #157
Conversation
github-actions
bot
added
the
crate: trace_decoder
frisitano
force-pushed
the
trace-processing
branch
from
43c2ff7
to
b042dff
Compare
github-actions
bot
added
the
crate: evm_arithmetization
…xPolygonZero#197) * First rough plan on trait structure * Now conditionally uses evm types at compile time - Created type aliases for all `evm_arithmetization` types that we need to swap out depending on whether or not we are compiling for `mpt` or `smt`. * Removed the default feature of "mpt" - Realized that there is no clean way to disable a default feature when it absolutely needs to be disabled (eg. when "smt" is enabled). - Also added a compile time check to enforce that one of these features is enabled. * Renamed `processed_block_trace.rs` --> `processed_block_trace_mpt.rs` - Prep for `mpt`/`smt` logic feature gating. * SQUASH!! Rough draft of SMT & continuation support - Still need to remove feature gating stuff. * Removed feature gating for MPT/SMT - Realized that we can link again both versions of the library at once without conditional compilation. * A bit more cleanup * Hack to avoid jemalloc failure * Requested changes for PR 0xPolygonZero#197 * Fixed all clippy errors
* Fix access lists pointers * Update evm_arithmetization/src/cpu/kernel/asm/core/access_lists.asm Co-authored-by: Robin Salen <[email protected]> * Address reviews --------- Co-authored-by: Robin Salen <[email protected]>
* feat: add a few usability functions to the interface * fix: fix clippy issue * feat: add usize to nibbles * docs: update changelog.md --------- Co-authored-by: Vladimir Trifonov <[email protected]> Co-authored-by: Ben <[email protected]>
github-actions
bot
removed
the
crate: evm_arithmetization
|
Hey @frisitano, #197 has been removed from Also (cc @muursh @cpubot), we don't have a priority integration queue at the zkEVM project level (yet?), but I'd suggest waiting slightly before merging #31 into
Any objection / suggestion? |
|
So, to confirm my understanding of the path for the alloy/ethers path you're suggesting:
This makes sense, given that (as far as I understand) eth-tx-proof has an unclear lifespan/was prototype-y Nod from @cpubot was that there's a lot of duplicate code between |
|
Sure thing. I'll see to it in the morning. |
|
@0xaatif Yes that's correct. I'm sorry that you actually did implement it on |
|
@Nashtare I've been working on this today but I'm running into some issues in regards to proof generation. From what I can see the transaction traces and trie data looks correct however the transaction kernel always fails on post transaction checks relating to trie modification and consistency checks. This is the Maybe we can cross reference against some traces produced by jerigon to see if there is any discrepancies. I may be missing something obvious but a second set of eyes would be appreciated. |
|
Hey @frisitano, any specific changes since last time? AFAIR, we had almost a 100% success rate with your native tracer. Or would it be coming from latest |
|
Here are two traces to compare. I think txns are processed in reverse order (first one in |
|
On the zero-bin side, in - for tx_hash in &block.transactions {
+ for tx_hash in block.transactions.iter().rev() {This will make part of the block provable. For block 19240705, I got 8 txns proven, with a Kernel Panic on the 9th one. Still investigating. |
|
This is replaced by #246 |
|
Closing as per #157 (comment). |
Work in progress