zktrie part1: change storage proof from per step to per block #102
Conversation
…ll be reconstructed in prover side
lispc
changed the title
lispc
changed the title
lispc
changed the title
I don't think it would break roller's code because nothing in roller would touch the SMT proof fields, which would be purged from blockResult after this PR. We can simply remove the "proof" fields which is defined in AccountProofWrapper/StorageProofWrapper@eth.rs in roller and the code still works. |
|
@HAOYUatHZ will do a bit refactor here. So don't merge now. |
lispc
changed the title
core/vm/logger_trace.go
Outdated
| CALL: {traceToAddressCode, traceLastNAddressCode(1), traceCallerProof, traceLastNAddressProof(1)}, | ||
| CALLCODE: {traceToAddressCode, traceLastNAddressCode(1), traceCallerProof, traceLastNAddressProof(1)}, |
There was a problem hiding this comment.
what's the different between traceLastNAddressProof(1) and doing it in CaptureEnter? If they are the same can we remove traceLastNAddressProof here?
then change ExtraData comments in core/types/l2trace.go to
CALL | CALLCODE: [caller contract address’s account state,
callee contract address’s account state (before called)]
There was a problem hiding this comment.
The data created by traceLastNAddressProof is left for background compatible. I think we should use the account data captured in CaptureEnter, since the balance of called account may be updated and it would only be captured here.
* rename GetStateData to GetLiveStateObject * revert EvmTxTraces type * rename GetLiveStateObject to GetLiveStateAccount * fix typo * some renamings * format codes * fix typo * fix typos * format codes some reverts some renamings some renamings format codes * update comments update comments * update comments update comments update comments * update comments update comments update comments * rename * rename * update * update comments
Step-wise proof will be reconstructed in prover side.
Core design: when storage related opcodes are traced(eg: sstore, create2..), no storage proof are generated then, only "storage diff" are recorded. Later when sealing a block, the miner traverse all the "recorded accessed storage", and make proofs of them for the state before this block. So for every storage slot, there will be only one proof for it, corresponding to state before the block execution.
we add some methods to StateDb for this purpose. StateDb writes to trie only when a block is sealing, while during execution inside block, it only keeps pending writes in its inner buffer. So when we are making proofs, we can access state trie before this block, since the pending changes are not committed yet.