You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Zero zkEVM already supports RLP encoding to support vanilla MPTs for Txn / Receipt tries without this being a real bottleneck, it'd be best to remain consistent and reuse the regular MPT format for these 2 tries as well for the type2.
The text was updated successfully, but these errors were encountered:
The implementations of tx/receipt encoding are the same in both cdk-erigon and type1 erigon. If we are talking about zero tracer, do you mean to change the encoding in both places?
If we are talking about the trie roots of txns and receipts in the block header, I believe they are calculated the same way as type 1.
As discussed with @Nashtare , the tx hash function in question was ComputeL2TxHash.
This function affects:
L2 block info tree
Datastream
zkevm_* rpc
1 will be disabled in Normalcy HF, 2 is agnostic to zero prover, and 3 won't be used by zero prover. Therefore, this is a non-issue once #1374 is merged.
Zero zkEVM already supports RLP encoding to support vanilla MPTs for Txn / Receipt tries without this being a real bottleneck, it'd be best to remain consistent and reuse the regular MPT format for these 2 tries as well for the type2.
The text was updated successfully, but these errors were encountered: