The curious case of BLOCKHASH and Stateless Ethereum

https://ethresear.ch/t/the-curious-case-of-blockhash-and-stateless-ethereum/7304

@axic wrote:

TLDR: It would be useful to consider EIP-210 (or a variant of it) for Stateless Ethereum.

The BLOCKHASH opcode can be used to query the hash of the past 256 blocks. Blocks and block hashes are not part of the state trie, but are only referenced by blocks, and therefore are “implied state”. An Ethereum block contains, among others, two fields: parentHash and the stateRoot. The parentHash is the hash of the previous block.

One of the goals of Stateless Ethereum is that verification of a block should be a pure operation. It should not imply access to some data or state not already provided via the block. To aid this, including the canonical hash of the block witness is also proposed.

In order to fulfil this goal of purity, since the block hashes are not part of the state, they would need to be encoded in the witness.

“But hey, stateless nodes will have access to block headers!” will be the reader’s first intuition. I consider that not as pure as having everything codified via the block.

There are multiple ways to accomplish this:

  1. The block witness specification can be amended to also include every block header until the oldest one referenced in block (worst case all 256 block headers). This could be quite large in size.

  2. Include a list of historical block hashes in the block header. EVM already exposes other block header fields. While this doesn’t place block headers into the “Ethereum state”, it still accomplishes the same goal. For inspiration have a look at Eth2.0 historical roots.

  3. Luckily we can also look back at an earlier proposal for Ethereum, EIP-210, which suggested placing block hashes in the state in the form of a special contract. There are two benefits this provides: 1) no need for a special encoding in the witness, since the storage locations of the contract are included; 2) potentially no need to encode as many block hashes. It also has the potential, similar to “historical roots” above, to more easily include hashes older than the past 256 blocks.

Relationship to Eth 2 Phase 1.5

Enforcing this purity could also prove beneficial for Phase 1.5 to reduce the complexity for those validators, which are not Eth1-validators.

Thanking Sina Mahmoodi for valuable feedback.

Posts: 1

Participants: 1

Read full topic