Skip to content

Commit 4c94526

Browse files
lightclientlightclient
authored
Update EIP-2935: bring up to date with sys contract impl
Merged by EIP-Bot.
1 parent 6b5c7cf commit 4c94526

File tree

1 file changed

+34
-59
lines changed

1 file changed

+34
-59
lines changed

‎EIPS/eip-2935.md

Lines changed: 34 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -26,10 +26,10 @@ A side benefit of this approach could be that it allows building/validating proo
2626

2727
| Parameter | Value |
2828
| - | - |
29-
| `BLOCKHASH_SERVE_WINDOW` | `256` |
30-
| `HISTORY_SERVE_WINDOW` | `8192` |
31-
| `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` |
32-
| `HISTORY_STORAGE_ADDRESS` | `0x0aae40965e6800cd9b1f4b05ff21581047e3f91e`|
29+
| `BLOCKHASH_SERVE_WINDOW` | `256` |
30+
| `HISTORY_SERVE_WINDOW` | `8191` |
31+
| `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` |
32+
| `HISTORY_STORAGE_ADDRESS` | `0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC` |
3333

3434
This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length. Note that `HISTORY_SERVE_WINDOW` > `BLOCKHASH_SERVE_WINDOW` (which remains unchanged).
3535

@@ -60,8 +60,8 @@ The history contract has two operations: `get` and `set`. The `set` operation is
6060
It is used from the EVM for looking up block hashes.
6161

6262
* Callers provide the block number they are querying in a big-endian encoding.
63-
* If calldata is bigger than 2^64-1, revert.
64-
* For any output outside the range of [block.number-`HISTORY_SERVE_WINDOW`, block.number-1] return 0.
63+
* If calldata is not 32 bytes, revert.
64+
* For any request outside the range of [block.number-`HISTORY_SERVE_WINDOW`, block.number-1], revert.
6565

6666
#### `set`
6767

@@ -73,89 +73,58 @@ It is used from the EVM for looking up block hashes.
7373
Exact evm assembly that can be used for the history contract:
7474

7575
```
76-
// if system call then jump to the set operation
76+
// https://github.com/lightclient/sys-asm/blob/f1c13e285b6aeef2b19793995e00861bf0f32c9a/src/execution_hash/main.eas
7777
caller
7878
push20 0xfffffffffffffffffffffffffffffffffffffffe
7979
eq
80-
push1 0x57
80+
push1 0x46
81+
jumpi
82+
push1 0x20
83+
calldatasize
84+
sub
85+
push1 0x42
8186
jumpi
82-
83-
// check if input > 8 byte value and revert if this isn't the case
84-
// the check is performed by comparing the biggest 8 byte number with
85-
// the call data, which is a right-padded 32 byte number.
86-
push8 0xffffffffffffffff
8787
push0
8888
calldataload
89-
gt
90-
push1 0x53
91-
jumpi
92-
93-
// check if input > blocknumber-1 then return 0
94-
push1 0x1
89+
push1 0x01
9590
number
9691
sub
97-
push0
98-
calldataload
92+
dup2
9993
gt
100-
push1 0x4b
94+
push1 0x42
10195
jumpi
102-
103-
// check if blocknumber > input + 8192 then return 0, no overflow expected for input of < max 8 byte value
104-
push0
105-
calldataload
106-
push2 0x2000
107-
add
96+
push2 0x1fff
97+
dup2
10898
number
99+
sub
109100
gt
110-
push1 0x4b
101+
push1 0x42
111102
jumpi
112-
113-
// mod 8192 and sload
114103
push2 0x1fff
115-
push0
116-
calldataload
117-
and
104+
swap1
105+
mod
118106
sload
119-
120-
// load into mem and return 32 bytes
121-
push0
122-
mstore
123-
push1 0x20
124-
push0
125-
return
126-
127-
// 0x4b: return 0
128-
jumpdest
129-
push0
130107
push0
131108
mstore
132109
push1 0x20
133110
push0
134111
return
135-
136-
// 0x53: revert
137112
jumpdest
138113
push0
139114
push0
140115
revert
141-
142-
// 0x57: set op - sstore the input to number-1 mod 8192
143116
jumpdest
144117
push0
145118
calldataload
146119
push2 0x1fff
147-
push1 0x1
120+
push1 0x01
148121
number
149122
sub
150-
and
123+
mod
151124
sstore
152-
153125
stop
154126
```
155127

156-
Corresponding bytecode:
157-
`0x3373fffffffffffffffffffffffffffffffffffffffe1460575767ffffffffffffffff5f3511605357600143035f3511604b575f35612000014311604b57611fff5f3516545f5260205ff35b5f5f5260205ff35b5f5ffd5b5f35611fff60014303165500`
158-
159128
#### Deployment
160129

161130
A special synthetic address is generated by working backwards from the desired deployment transaction:
@@ -170,17 +139,17 @@ A special synthetic address is generated by working backwards from the desired d
170139
"maxPriorityFeePerGas": null,
171140
"maxFeePerGas": null,
172141
"value": "0x0",
173-
"input": "0x60648060095f395ff33373fffffffffffffffffffffffffffffffffffffffe1460575767ffffffffffffffff5f3511605357600143035f3511604b575f35612000014311604b57611fff5f3516545f5260205ff35b5f5f5260205ff35b5f5ffd5b5f35611fff60014303165500",
142+
"input": "0x60538060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604657602036036042575f35600143038111604257611fff81430311604257611fff9006545f5260205ff35b5f5ffd5b5f35611fff60014303065500",
174143
"v": "0x1b",
175144
"r": "0x539",
176-
"s": "0x1b9b6eb1f0",
177-
"hash": "0x3c769a03d6e2212f1d26ab59ba797dce0900df29ffd23c1dd391fd6b217973ad",
145+
"s": "0xbaefe09f0109759",
146+
"hash": "0x8c7bd2d3713a0b2bb693463d2a78c4d612ac47dd38ecb74f8996a4b6fc96f03c"
178147
}
179148
```
180149

181150
Note, the input in the transaction has a simple constructor prefixing the desired runtime code.
182151

183-
The sender of the transaction can be calculated as `0xe473f7e92ba2490e9fcbbe8bb9c3be3adbb74efc`. The address of the first contract deployed from the account is `rlp([sender, 0])` which equals `0x0aae40965e6800cd9b1f4b05ff21581047e3f91e`. This is how `HISTORY_STORAGE_ADDRESS` is determined. Although this style of contract creation is not tied to any specific initcode like create2 is, the synthetic address is cryptographically bound to the input data of the transaction (e.g. the initcode).
152+
The sender of the transaction can be calculated as `0xE9f0662359Bb2c8111840eFFD73B9AFA77CbDE10`. The address of the first contract deployed from the account is `rlp([sender, 0])` which equals `0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC`. This is how `HISTORY_STORAGE_ADDRESS` is determined. Although this style of contract creation is not tied to any specific initcode like create2 is, the synthetic address is cryptographically bound to the input data of the transaction (e.g. the initcode).
184153

185154

186155
Some activation scenarios:
@@ -233,6 +202,12 @@ def process_block_hash_history(block: Block, state: State):
233202

234203
The first option is recommended until the Verkle fork, to stay consistent with [EIP-4788](./eip-4788.md) and to issues for misconfigured networks where this EIP is activated but history contract hasn't been deployed. The recommendation may be reconsidered at the Verkle fork if filtering the system contract code chunks is deemed too complex.
235204

205+
### Size of ring buffers
206+
207+
The ring buffer data structure is sized to hold 8191 hashes. In other system contracts a prime ring buffer size is chosen in because using a prime as the modulus ensures that no value is overwritten until the entire ring buffer has been saturated and thereafter, each value will be updated once per iteration, regardless of if some slot are missing or the slot time changes. However, in this EIP the block number is the value in the modulo operation and it only ever increases by 1 each iteration. Which means we can be confident that the ring buffer will always remain saturated.
208+
209+
For consistency with other system contracts, we have decided to retain the buffer size of 8191. Given the current mainnet values, 8191 roots provides about a day of coverage. This also gives users plenty of time to make a transaction with a verification against a specific hash and get the transaction included on-chain.
210+
236211
## Backwards Compatibility
237212

238213
This EIP introduces backwards incompatible changes to the block validation rule set. But neither of these changes break anything related to current user activity and experience.

0 commit comments

Comments
 (0)