Skip to content

Commit

Permalink
Update the eip to store in ring buffer instead of serial storage and …
Browse files Browse the repository at this point in the history 
…add eip 158 handling strategy
  • Loading branch information
@g11tech
g11tech committed Mar 12, 2024
1 parent 941d3be commit 5d4a85a
Showing 1 changed file with 29 additions and 26 deletions.
55 changes: 29 additions & 26 deletions EIPS/eip-2935.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,43 +12,44 @@ created: 2020-09-03

## Abstract

Store historical block hashes in a contract, and modify the `BLOCKHASH (0x40)` opcode to read this contract.
Store last 256 historical block hashes in a contract, and modify the `BLOCKHASH (0x40)` opcode to read and serve from this contract storage.

## Motivation

There is increasingly a desire to remove the need for most clients to store history older than some relatively short duration (often between 1 week and 1 year) to save disk space. This requires some form of layer-2 network to help clients access historical information. These protocols can be made much simpler if blocks contained a quick Merkle path to historical blocks.
Currently BLOCKHASH opcode accesses history to resolve hash of the block number in EVM. However a more stateless client friendly way is to maintain and serve these hashes from state.

Additional secondary motivations include:
Although this is possible even in Merkle trie state, but Verkle trie state further allows bundling the BLOCKHASH witnesses (along with other witnesses) in an efficient manner making it worthwhile to have these in state.

* The protocol can be used to make more secure efficient light clients with flyclient-like technology (while the "optimal" flyclient protocol is fairly complex, large security gains over the status quo (trusted "canonical hash trees") can be made cheaply)
* Improving cleanness of the protocol, as the BLOCKHASH opcode would then access state and not history.
A side benefit of this approach could be that it allows building/validating proofs related to last 256 ancestors directly against the current state.

## Specification

| Parameter | Value |
| - | - |
| `FORK_TIMESTAMP` | TBD |
| `HISTORY_STORAGE_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe`|
| `MIN_HISTORY_SERVE_WINDOW` | `256` |
| `MAX_HISTORY_SERVE_WINDOW` | `2**256` |
| `HISTORY_SERVE_WINDOW` | `256` |

This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length.


At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the history in the following way:

```python
def process_block_hash_history(block :Block, state: State):
if block.timestamp >= FORK_TIMESTAMP:
state.insert_slot(HISTORY_STORAGE_ADDRESS, block.number-1, block.parent.hash)
state.insert_slot(HISTORY_STORAGE_ADDRESS, block.number-1 % HISTORY_SERVE_WINDOW , block.parent.hash)

# If this is the first fork block, add the parent's direct 255 ancestors as well
if block.parent.timestamp < FORK_TIMESTAMP:
ancestor = block.parent
for i in range(MIN_HISTORY_SERVE_WINDOW - 1):
for i in range(HISTORY_SERVE_WINDOW - 1):
# stop at genesis block
if ancestor.number == 0:
break

ancestor = ancestor.parent
state.insert_slot(HISTORY_STORAGE_ADDRESS, ancestor.number, ancestor.hash)
state.insert_slot(HISTORY_STORAGE_ADDRESS, ancestor.number % HISTORY_SERVE_WINDOW, ancestor.hash)
```

Note that if this is the fork block, then it persists the additional requisite history that could be needed while resolving `BLOCKHASH` opcode for all of the `MIN_HISTORY_SERVE_WINDOW` ancestors (up until genesis).
Expand All @@ -58,44 +59,46 @@ For resolving the `BLOCKHASH` opcode this fork onwards (`block.timestamp >= FORK
```python
def resolve_blockhash(block: Block, state: State, arg: uint64):
# check the wrap around range
if arg >= block.number or arg < max(block.number - MAX_HISTORY_SERVE_WINDOW, 0)
if arg >= block.number or arg < max(block.number - HISTORY_SERVE_WINDOW, 0)
return 0

return state.load_slot(HISTORY_STORAGE_ADDRESS, arg)
return state.load_slot(HISTORY_STORAGE_ADDRESS, arg % HISTORY_SERVE_WINDOW)
```

Note that the above logic allows access deeper than `MIN_HISTORY_SERVE_WINDOW` if it exists all the way upto `MAX_HISTORY_SERVE_WINDOW`.

Edge cases:
Some activation scenarios:

* For the fork to be activated at genesis, no history is written to the genesis state, and at the start of block `1`, genesis hash will be written as a normal operation to slot `0`.
* for activation at block `1`, only genesis hash will be written at slot `0` as there is no additional history that needs to be persisted.
* for activation at block `32`, block `31`'s hash will be written to slot `31` and additonal history for `0..30`'s hashes will be persisted, so all in all `0..31`'s hashes.
* for activation at block `1000`, block `744-999`'s hashes will be presisted in the slot and `BLOCKHASH` for `733` or less would resolve to `0` as only `MIN_HISTORY_SERVE_WINDOW` is persisted.
* for activation at block `1000`, block `744-999`'s hashes will be presisted in the slot and `BLOCKHASH` for `733` or less would resolve to `0` as only `HISTORY_SERVE_WINDOW` can be served.

### [EIP-158](./eip-158.md) exception
### [EIP-158](./eip-158.md) handling

This address is currently exempt from [EIP-158](./eip-158.md) cleanup in Kaustinen Verkle Testnet but there are two ways this could be addressed before this EIP is adopted by ACD:
This address is currently exempt from [EIP-158](./eip-158.md) cleanup in Kaustinen Verkle Testnet but we plan to address this in the following way:

* Update the nonce to 1 in the fork block, or
* Deploy a contract à la [EIP-4788](./eip-4788.md) with `BLOCKHASH` opcode delegating call to this contract with appropriate args.

While the second option looks more elegant, it has a higher complexity as well as gas consumption considerations.
* Deploy a contract à la [EIP-4788](./eip-4788.md) which just supports `get` method to resolve the BLOCKHASH as per the logic defined above (and use the generated address as the BLOCKHASH contract address).
* While the clients are expected to directly read from state (or maintain and server from memory) to resolve BLOCKHASH opcode, this contract's `get` could be invoked by transaction (via contract or otherwise) leading to a normal contract execution (and gas consumption) as per the semantics of the contract call.

## Rationale

Very similar ideas were proposed before in [EIP-210](./eip-210.md) et al. This EIP is a simplification, removing two sources of needless complexity:

1. Having a tree-like structure with multiple layers as opposed to a single list
2. Writing the EIP in EVM code
3. Serial unbounded storage of hashes for a deep access to the history

However after weighing pros and cons, we decided to go with just a limited ring buffer to only serve the requiste `HISTORY_SERVE_WINDOW` as [EIP 4788](./eip04788) and beacon state accumulators allow (albit a bit more complex) proof against any ancestor since merge.

Check failure on line 90 in EIPS/eip-2935.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

proposals must be referenced with the form `EIP-N` (not `EIPN` or `EIP N`) 

error[markdown-re-eip-dash]: proposals must be referenced with the form `EIP-N` (not `EIPN` or `EIP N`)
  --> EIPS/eip-2935.md
   |
90 | However after weighing pros and cons, we decided to go with just a limited ring buffer to only serve the requiste `HISTORY_SERVE_WINDOW` as [EIP 4788](./eip04788) and beacon state accumulators allow (albit a bit more complex) proof against any ancestor since merge.
   |
   = info: the pattern in question: `(?i)eip[\s]*[0-9]+`
   = help: see https://ethereum.github.io/eipw/markdown-re-eip-dash/

Second concern was how to best transition the BLOCKHASH resolution logic post fork by:

The former was intended to save space. Since then, however, storage usage has increased massively, to the point where even eg. 5 million new storage slots are fairly negligible compared to existing usage. The latter was intended as a first step toward "writing the Ethereum protocol in EVM" as much as possible, but this goal has since been de-facto abandoned.
1. Either waiting for `HISTORY_SERVE_WINDOW` blocks for the entire relevant history to persist
2. Storing of all last `HISTORY_SERVE_WINDOW` block hashes on the fork block.

Storing of all last `MIN_HISTORY_SERVE_WINDOW` block hashes alleviates the need to detect fork activation height to transition to the new logic in backward compatible manner as the entire requisite history will be available from the first block of the fork itself. The cost of doing so is marginal considering the `MIN_HISTORY_SERVE_WINDOW` being small.
We chose to go with later as it alleviates the need to detect fork activation height to transition to the new logic in backward compatible manner as the entire requisite history will be available from the first block of the fork itself. The cost of doing so is marginal considering the `HISTORY_SERVE_WINDOW` being small.

## Backwards Compatibility

The range of `BLOCKHASH` is increased by this opcode, but behavior within the previous `MIN_HISTORY_SERVE_WINDOW`-block range remains unchanged.
The behavior of `BLOCKHASH` opcode remains same and doesn't affect backward compatability with the contracts deployed or the gas consumption costs as the resolution of the opcode is handled "directly" by the clients

## Test Cases

Expand All @@ -108,7 +111,7 @@ TBD

## Security Considerations

Adding ~2.5 million storage slots per year bloats the state somewhat but not much relative to the hundreds of millions of existing state objects.
Having contracts (system or otherwise) with hot update paths (branches) poses a risk of "branch" poisioning attracks where one could sprinkle trivial amounts of eth around these hot paths (branches). But it has been deemed that cost of attack would escalate significantly to cause any meaningful slow down of state root updates.

## Copyright

Expand Down

0 comments on commit 5d4a85a

Please sign in to comment.