Skip to content

Conversation

jwasinger
Copy link
Contributor

This pulls a few changes out from the larger BAL branch #32263:

  • StateDB is modified to return the modified state as well as accessed state from Finalise if it has been explicitly enabled with StateDB.EnableStateDiffRecording.
  • An interface exposing all StateDB functionality required for fully executing blocks is introduced in state.BlockProcessingDB (tentative name). Block state processor/validator, consensus engines have been modified to take a BlockProcessingDB in place of StateDB.
  • AccessListCreationDB (tentative name) is introduced which implements BlockProcessingDB. It wraps access to an inner BlockProcessingDB instance and is responsible for intercepting state reads/mutations returned from Finalise and using these to construct a block access list.
    • The aim here is to introducef the minimal amount of changes necessary to StateDB itself in order to construct BALs, and keep the concept of block-access-lists opaque to the StateDB.
  • Amsterdam fork configuration boilerplate has been added.
  • Block-access-lists are constructed and embedded into block bodies that are fully executed as part of block import when --experimentalbal is specified. The use-case for this is that I self-validate the BAL-generation and verification in the other larger BAL branch by executing the entire blockchain test spec.

TODOs

  • construct BALs in the miner if we are post-Amsterdam.

// Block Access List flags

ExperimentalBALFlag = &cli.BoolFlag{
Name: "experimentalbal",
Copy link
Member

Choose a reason for hiding this comment

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

--experimental.bal ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sgtm

// a block. It is an amalgamation of state access/modification functionality
// utilized by EVM execution and other functionality needed in block execution
// (e.g. state root calculation).
type BlockProcessingDB interface {
Copy link
Member

Choose a reason for hiding this comment

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

Most of the methods here are the same as vm.StateDB, can we somehow combine these interfaces? So that we don't need to change 2 places if anything changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, but we will have to move the interface up to the core package.

Originally, I tried to define BlockProcessingDB as being composed of vm.StateDB. However, that creates a cyclical import between core/vm and core/state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants