Skip to content

core/types: add block-level access list structures with encoding/decoding #31948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Jul 11, 2025

Conversation

jwasinger
Copy link
Contributor

@jwasinger jwasinger commented Jun 2, 2025

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.

@jwasinger jwasinger closed this Jun 2, 2025
@jwasinger jwasinger reopened this Jun 3, 2025
@jwasinger jwasinger changed the title core/types: add SSZ codec for BAL types from EIP 7928 core/types: add SSZ encoders/decoders for BAL types from EIP 7928 Jun 3, 2025
@jwasinger jwasinger changed the title core/types: add SSZ encoders/decoders for BAL types from EIP 7928 core/types: add block-level access list structures with encoding/decoding Jul 2, 2025
@jwasinger jwasinger marked this pull request as ready for review July 7, 2025 06:12
@jwasinger jwasinger requested a review from rjl493456442 as a code owner July 7, 2025 06:12
@jwasinger
Copy link
Contributor Author

I'm going to add RLP encoding/decoding to this so that we can evaluate the BALs produced by RLP vs SSZ.

// accountAccess contains post-block account state for mutations as well as
// all storage keys that were read during execution.
type accountAccess struct {
StorageWrites storageWrites `json:"storageWrites,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The EIP calls them storage_changes

StorageReads [][32]byte `ssz-max:"300000"`
BalanceChanges []encodingBalanceChange `ssz-max:"300000"`
NonceChanges []encodingAccountNonce `ssz-max:"300000"`
Code []encodingCodeChange `ssz-max:"1"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also needs to have a max of 30_000 according to spec (maybe the spec should be updated here)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can it? I thought with the way selfdestruct is specced now, you can update the contract multiple times in initcode

Copy link
Member

@MariusVanDerWijden MariusVanDerWijden Jul 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you would only store the code after the tx was executed, so yeah you're right

if err := dec.DecodeRLP(rlp.NewStream(bytes.NewReader(buf.Bytes()), 10000000)); err != nil {
t.Fatalf("decoding failed: %v\n", err)
}
if dec.Hash() != b.Hash() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only checks the rlp encoding/decoding, we should also test the ssz

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should add a fuzzer, especially for the conversion from BAL to BAL_Encoding and back

Copy link
Contributor Author

@jwasinger jwasinger Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

return res
}

func (e *encodingBlockAccessList) prettyPrint() string {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should probably be moved? or not be the encodingBlockAccessList type

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -0,0 +1,227 @@
package types
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

header

@@ -0,0 +1,361 @@
package types
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

header

@@ -0,0 +1,92 @@
package types
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

header

@jwasinger
Copy link
Contributor Author

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.

@jwasinger
Copy link
Contributor Author

Started prototyping BAL execution. I think that there's going to be quite a few changes to this PR as a result.

@jwasinger jwasinger marked this pull request as draft July 9, 2025 13:10
@jwasinger jwasinger marked this pull request as ready for review July 11, 2025 08:19
@rjl493456442 rjl493456442 added this to the 1.16.2 milestone Jul 11, 2025
@rjl493456442 rjl493456442 merged commit 1ef3bca into ethereum:master Jul 11, 2025
3 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants