Skip to content

Update EIP-2935: Final system contract address #9287

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
eth-bot merged 2 commits into from
Jan 30, 2025
Merged

Update EIP-2935: Final system contract address #9287

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
26d16a7
update eip-2935 system contract address
pk910 Jan 29, 2025
2856fce
update transaction hash
pk910 Jan 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions EIPS/eip-2935.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ A side benefit of this approach could be that it allows building/validating proo
| `BLOCKHASH_SERVE_WINDOW` | `256` |
| `HISTORY_SERVE_WINDOW` | `8191` |
| `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` |
| `HISTORY_STORAGE_ADDRESS` | `0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC` |
| `HISTORY_STORAGE_ADDRESS` | `0x0000F90827F1C53a10cb7A02335B175320002935` |

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).

Expand Down Expand Up @@ -142,14 +142,14 @@ A special synthetic address is generated by working backwards from the desired d
"input": "0x60538060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604657602036036042575f35600143038111604257611fff81430311604257611fff9006545f5260205ff35b5f5ffd5b5f35611fff60014303065500",
"v": "0x1b",
"r": "0x539",
"s": "0xbaefe09f0109759",
"hash": "0x8c7bd2d3713a0b2bb693463d2a78c4d612ac47dd38ecb74f8996a4b6fc96f03c"
"s": "0xaa12693182426612186309f02cfe8a80a0000",
"hash": "0x67139a552b0d3fffc30c0fa7d0c20d42144138c8fe07fc5691f09c1cce632e15"
}
```

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

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).
The sender of the transaction can be calculated as `0x3462413Af4609098e1E27A490f554f260213D685`. The address of the first contract deployed from the account is `rlp([sender, 0])` which equals `0x0000F90827F1C53a10cb7A02335B175320002935`. 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).


Some activation scenarios:
Expand Down
Loading