core/types: add block-level access list structures with encoding/decoding#31948
core/types: add block-level access list structures with encoding/decoding#31948rjl493456442 merged 14 commits intoethereum:masterfrom
Conversation
jwasinger
changed the title
jwasinger
changed the title
|
I'm going to add RLP encoding/decoding to this so that we can evaluate the BALs produced by RLP vs SSZ. |
There was a problem hiding this comment.
The EIP calls them storage_changes
There was a problem hiding this comment.
Also needs to have a max of 30_000 according to spec (maybe the spec should be updated here)
There was a problem hiding this comment.
I think this is probably a typo in the spec (I will PR a change to the EIP). The max should be 1: after selfdestruct removal, the code of an account can only change once (we don't include delegations in the BAL because they can be determined statically by looking at the block txs).
There was a problem hiding this comment.
Can it? I thought with the way selfdestruct is specced now, you can update the contract multiple times in initcode
There was a problem hiding this comment.
I guess you would only store the code after the tx was executed, so yeah you're right
There was a problem hiding this comment.
This only checks the rlp encoding/decoding, we should also test the ssz
There was a problem hiding this comment.
I think we should add a fuzzer, especially for the conversion from BAL to BAL_Encoding and back
There was a problem hiding this comment.
The RLP format of the access list is the SSZ-encoded access list wrapped into RLP bytes (that's how it would be encoded into the block body). So encoding/decoding the RLP performs SSZ encoding/decoding under the hood.
There was a problem hiding this comment.
this should probably be moved? or not be the encodingBlockAccessList type
There was a problem hiding this comment.
It's called by BlockAccess.PrettyPrint: I convert to the encoding format before printing so that the output of PrettyPrint is consistent, instead of random iteration order over maps in the BlockAccessList.
|
I added generated RLP encoders/decoders. I'm thinking that it doesn't make sense to merge this PR until we determine which serialization format to move forward with. I will do some analysis, generating BALs from a large historical block range with both RLP and SSZ, and we can compare the results. |
|
Started prototyping BAL execution. I think that there's going to be quite a few changes to this PR as a result. |
core/types/bal: polish
… to BlockAccessList
…ode the BALs directly)
…ding (ethereum#31948) This adds the SSZ types from the [EIP-7928](https://eips.ethereum.org/EIPS/eip-7928) and also adds encoder/decoder generation using https://github.com/ferranbt/fastssz. The fastssz dependency is updated because the generation will not work properly with the master branch version due to a bug in fastssz. --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
…ding (ethereum#31948) This adds the SSZ types from the [EIP-7928](https://eips.ethereum.org/EIPS/eip-7928) and also adds encoder/decoder generation using https://github.com/ferranbt/fastssz. The fastssz dependency is updated because the generation will not work properly with the master branch version due to a bug in fastssz. --------- Co-authored-by: Gary Rong <garyrong0905@gmail.com>
3 participants
This adds the SSZ types from the EIP-7928 and also adds encoder/decoder generation using https://github.com/ferranbt/fastssz.
The fastssz dependency is updated because the generation will not work properly with the master branch version due to a bug in fastssz.