Skip to content

Commit

Permalink
Update EIP-4762: fix some syntax issues
Browse files Browse the repository at this point in the history 
Merged by EIP-Bot.
  • Loading branch information
@gballet
gballet authored Jan 25, 2024
1 parent 79c36db commit 96f0b77
Showing 1 changed file with 47 additions and 55 deletions.
102 changes: 47 additions & 55 deletions EIPS/eip-4762.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,20 @@ The introduction of Verkle trees into Ethereum requires fundamental changes and

## Specification

### Helper functions

```python
def get_storage_slot_tree_keys(storage_key: int) -> [int, int]:
if storage_key < (CODE_OFFSET - HEADER_STORAGE_OFFSET):
pos = HEADER_STORAGE_OFFSET + storage_key
else:
pos = MAIN_STORAGE_OFFSET + storage_key
return (
pos // 256,
pos % 256
)
```

### Access events

We define access events as follows. When an access event takes place, the accessed data is saved to the Verkle tree (even if it was not modified). An access event is of the form`(address, sub_key, leaf_key)`, determining what data is being accessed.
Expand Down Expand Up @@ -76,19 +90,7 @@ If the `EXTCODEHASH` opcode is called targeting some address, process an access
(address, tree_key, sub_key)
```

Where tree_key and sub_key are computed as follows:

```python
def get_storage_slot_tree_keys(storage_key: int) -> [int, int]:
if storage_key < (CODE_OFFSET - HEADER_STORAGE_OFFSET):
pos = HEADER_STORAGE_OFFSET + storage_key
else:
pos = MAIN_STORAGE_OFFSET + storage_key
return (
pos // 256,
pos % 256
)
```
Where `tree_key` and `sub_key` are computed as `tree_key, sub_key = get_storage_slot_tree_keys(address, key)`

#### Access events for code

Expand All @@ -98,17 +100,17 @@ In the conditions below, “chunk chunk_id is accessed” is understood to mean
(address, (chunk_id + 128) // 256, (chunk_id + 128) % 256)
```

* At each step of EVM execution, if and only if PC < len(code), chunk PC // CHUNK_SIZE (where PC is the current program counter) of the callee is accessed. In particular, note the following corner cases:
* The destination of a `JUMP` (or positively evaluated JUMPI) is considered to be accessed, even if the destination is not a jumpdest or is inside pushdata
* The destination of a `JUMPI` is not considered to be accessed if the jump conditional is false.
* At each step of EVM execution, if and only if `PC < len(code)`, chunk `PC // CHUNK_SIZE` (where `PC` is the current program counter) of the callee is accessed. In particular, note the following corner cases:
* The destination of a `JUMP` (or positively evaluated `JUMPI`) is considered to be accessed, even if the destination is not a jumpdest or is inside pushdata
* The destination of a `JUMPI` is not considered to be accessed if the jump conditional is `false`.
* The destination of a jump is not considered to be accessed if the execution gets to the jump opcode but does not have enough gas to pay for the gas cost of executing the `JUMP` opcode (including chunk access cost if the `JUMP` is the first opcode in a not-yet-accessed chunk)
* The destination of a jump is not considered to be accessed if it is beyond the code (`destination >= len(code)`)
* The destination of a jump is not considered to be accessed if it is beyond the code (`destination >= len(code)`)
* If code stops execution by walking past the end of the code, `PC = len(code)` is not considered to be accessed
* If the current step of EVM execution is a `PUSH{n}`, all chunks `(PC // CHUNK_SIZE) <= chunk_index <= ((PC + n) // CHUNK_SIZE)`` of the callee are accessed.
* If a nonzero-read-size `CODECOPY` or `EXTCODECOPY` read bytes `x...y` inclusive, all chunks ``(x // CHUNK_SIZE) <= chunk_index <= (min(y, code_size - 1) // CHUNK_SIZE)`` of the accessed contract are accessed.
* Example 1: for a `CODECOPY` with start position 100, read size 50, `code_size = 200`, `x = 100` and `y = 149`
* Example 2: for a `CODECOPY` with start position 600, read size 0, no chunks are accessed
* Example 3: for a `CODECOPY` with start position 1500, read size 2000, `code_size = 3100`, `x = 1500` and `y = 3099`
* If the current step of EVM execution is a `PUSH{n}`, all chunks `(PC // CHUNK_SIZE) <= chunk_index <= ((PC + n) // CHUNK_SIZE)` of the callee are accessed.
* If a nonzero-read-size `CODECOPY` or `EXTCODECOPY` read bytes `x...y` inclusive, all chunks `(x // CHUNK_SIZE) <= chunk_index <= (min(y, code_size - 1) // CHUNK_SIZE)` of the accessed contract are accessed.
* Example 1: for a `CODECOPY` with start position 100, read size 50, `code_size = 200`, `x = 100` and `y = 149`
* Example 2: for a `CODECOPY` with start position 600, read size 0, no chunks are accessed
* Example 3: for a `CODECOPY` with start position 1500, read size 2000, `code_size = 3100`, `x = 1500` and `y = 3099`
* `CODESIZE`, `EXTCODESIZE` and `EXTCODEHASH` do NOT access any chunks.
When a contract is created, access chunks `0 ... (len(code)+30)//31`

Expand All @@ -118,7 +120,7 @@ We define **write events** as follows. Note that when a write takes place, an ac

#### Write events for account headers

When a nonzero-balance-sending CALL or SELFDESTRUCT with a given sender and recipient takes place, process these write events:
When a nonzero-balance-sending `CALL` or `SELFDESTRUCT` with a given sender and recipient takes place, process these write events:

```
(sender, 0, BALANCE_LEAF_KEY)
Expand Down Expand Up @@ -150,29 +152,17 @@ When a contract is created, process these write events:

#### Write events for storage

SSTORE opcodes with a given `address` and `key` process a write event of the form
`SSTORE` opcodes with a given `address` and `key` process a write event of the form

```
(address, tree_key, sub_key)
```

Where `tree_key` and `sub_key` are computed as follows:

```python
def get_storage_slot_tree_keys(storage_key: int) -> [int, int]:
if storage_key < (CODE_OFFSET - HEADER_STORAGE_OFFSET):
pos = HEADER_STORAGE_OFFSET + storage_key
else:
pos = MAIN_STORAGE_OFFSET + storage_key
return (
pos // 256,
pos % 256
)
```
Where `tree_key` and `sub_key` are computed as `tree_key, sub_key = get_storage_slot_tree_keys(address, key)`

#### Write events for code

When a contract is created, make write events:
When a contract is created, process the write events:

```python
(
Expand All @@ -187,6 +177,7 @@ For `i` in `0 ... (len(code)+30)//31`.
### Transactions

#### Access events

For a transaction, make these access events:

```
Expand Down Expand Up @@ -220,7 +211,7 @@ if `value` is non-zero:
Remove the following gas costs:

* Increased gas cost of `CALL` if it is nonzero-value-sending
* EIP-2200 `SSTORE` gas costs except for the `SLOAD_GAS`
* [EIP-2200](./eip-2200.md) `SSTORE` gas costs except for the `SLOAD_GAS`
* 200 per byte contract code cost

Reduce gas cost:
Expand All @@ -229,36 +220,36 @@ Reduce gas cost:

|Constant |Value|
|-|-|
|WITNESS_BRANCH_COST |1900|
|WITNESS_CHUNK_COST |200|
|SUBTREE_EDIT_COST |3000|
|CHUNK_EDIT_COST |500|
|CHUNK_FILL_COST |6200|
|`WITNESS_BRANCH_COST` |1900|
|`WITNESS_CHUNK_COST` |200|
|`SUBTREE_EDIT_COST` |3000|
|`CHUNK_EDIT_COST` |500|
|`CHUNK_FILL_COST` |6200|

When executing a transaction, maintain four sets:

* `accessed_subtrees: Set[Tuple[address, int]]`
* `accessed_leaves: Set[Tuple[address, int, int]]`
* `edited_subtrees`: `Set[Tuple[address, int]]`
* `edited_leaves`: `Set[Tuple[address, int, int]]`
* `edited_subtrees: Set[Tuple[address, int]]`
* `edited_leaves: Set[Tuple[address, int, int]]`


When an **access** event of `(address, sub_key, leaf_key)` occurs, perform the following checks:

* If ``(address, sub_key)`` is not in accessed_subtrees, charge WITNESS_BRANCH_COST gas and add that tuple to accessed_subtrees.
* If `leaf_key` is not `None` and ``(address, sub_key, leaf_key)`` is not in `accessed_leaves`, charge `WITNESS_CHUNK_COST` gas and add it to `accessed_leaves`
* If `(address, sub_key)` is not in `accessed_subtrees`, charge `WITNESS_BRANCH_COST` gas and add that tuple to `accessed_subtrees`.
* If `leaf_key` is not `None` and `(address, sub_key, leaf_key)` is not in `accessed_leaves`, charge `WITNESS_CHUNK_COST` gas and add it to `accessed_leaves`

When a **write** event of `(address, sub_key, leaf_key)` occurs, perform the following checks:

* If (address, sub_key) is not in edited_subtrees, charge `SUBTREE_EDIT_COST` gas and add that tuple to edited_subtrees.
* If leaf_key is not None and `(address, sub_key, leaf_key)` is not in `edited_leaves`, charge `CHUNK_EDIT_COST` gas and add it to `edited_leaves`
* Additionally, if there was no value stored at `(address, sub_key, leaf_key)` (ie. the state held None at that position), charge `CHUNK_FILL_COST`
* If `(address, sub_key)` is not in `edited_subtrees`, charge `SUBTREE_EDIT_COST` gas and add that tuple to `edited_subtrees`.
* If `leaf_key` is not `None` and `(address, sub_key, leaf_key)` is not in `edited_leaves`, charge `CHUNK_EDIT_COST` gas and add it to `edited_leaves`
* Additionally, if there was no value stored at `(address, sub_key, leaf_key)` (ie. the state held `None` at that position), charge `CHUNK_FILL_COST`

Note that tree keys can no longer be emptied: only the values `0...2**256-1` can be written to a tree key, and 0 is distinct from None. Once a tree key is changed from `None` to not-`None`, it can never go back to `None`.
Note that tree keys can no longer be emptied: only the values `0...2**256-1` can be written to a tree key, and 0 is distinct from `None`. Once a tree key is changed from `None` to not-`None`, it can never go back to `None`.

### Replacement for access lists

We replace EIP 2930 access lists with an SSZ structure of the form:
We replace [EIP-2930](./eip-2930.md) access lists with an SSZ structure of the form:

```python
class AccessList(Container):
Expand Down Expand Up @@ -289,7 +280,7 @@ Gains from the latter two properties have not yet been analyzed, but are likely

The precise specification of when access events take place, which makes up most of the complexity of the gas repricing, is necessary to clearly specify when data needs to be saved to the period 1 tree.

## Backward Compatibility
## Backwards Compatibility

This EIP requires a hard fork, since it modifies consensus rules.

Expand All @@ -299,7 +290,8 @@ The main backwards-compatibility-breaking changes is the gas costs for code chun

This EIP will mean that certain operations, mostly reading and writing several elements in the same suffix tree, become cheaper. If clients retain the same database structure as they have now, this would result in a DOS vector.

So some adaptation of the database is required in order to make this work.
So some adaptation of the database is required in order to make this work:

* In all possible futures, it is important to logically separate the commitment scheme from data storage. In particular, no traversal of the commitment scheme tree should be necessary to find any given state element
* In order to make accesses to the same stem cheap as required for this EIP, the best way is probably to store each stem in the same location in the database. Basically the 256 leaves of 32 bytes each would be stored in an 8kB BLOB. The overhead of reading/writing this BLOB is small because most of the cost of disk access is seeking and not the amount transferred.

Expand Down

0 comments on commit 96f0b77

Please sign in to comment.