Skip to content
Merged
Changes from all commits
Commits
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
62 changes: 44 additions & 18 deletions EIPS/eip-8272.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,8 @@ This specification extends [EIP-8141](./eip-8141.md). Terms not defined here, in

| Name | Value |
| --- | ---: |
| `RECENT_ROOT_ADDRESS` | `0x0000000000000000000000000000000000008272` |
| `RECENT_ROOT_CODE` | `TBD` |
| `RECENT_ROOT_ADDRESS` | `0x8272D9679689Ea2f307140CdF9002D27dC00Ffff` |
| `RECENT_ROOT_CODE` | see [Bytecode](#bytecode) |
| `RECENT_ROOT_LENGTH` | `8192` |
| `RECENT_ROOT_USABLE_WINDOW` | `8191` |
| `MAX_RECENT_ROOT_REFERENCES` | `16` |
Expand Down Expand Up @@ -103,7 +103,7 @@ Each root source uses at most `RECENT_ROOT_LENGTH` storage keys. The global stor

### Recent root contract

At activation, clients MUST create or update the account at `RECENT_ROOT_ADDRESS` as specified in [Activation](#activation).
The recent root contract is an ordinary contract deployed at `RECENT_ROOT_ADDRESS` (see [Deployment](#deployment)). It is not installed by the protocol at activation.

Calls with nonzero value MUST revert. Calldata selects one of two operations by length.

Expand Down Expand Up @@ -195,6 +195,41 @@ The validation operation MUST read the current slot with `SLOTNUM`, MUST NOT cal

All calls use ordinary EVM execution and gas accounting.

#### Bytecode

`RECENT_ROOT_CODE` is the following runtime code.

```
0x346100ba57366040146100c05736604836066100ba5780156100ba5761048081116100ba574b60005b602081013560c01c828110156100ba5780830361200011156100ba577f8f42481679c8e6fefa040974b3c905e0ce3f2e464ba93acdb074a41181617efc60005260488260203760686000207fbdc897da2177d260ff5f4be5d4b2aad43f89c3347a305b584fa5a2546d053daa60005290611fff1660c01b60405260486000205414156100ba5760480182811061002857005b60006000fd5b33600052602060006020376034600c20807f8f42481679c8e6fefa040974b3c905e0ce3f2e464ba93acdb074a41181617efc6040524b606852606052602060206088376068604020817fbdc897da2177d260ff5f4be5d4b2aad43f89c3347a305b584fa5a2546d053daa60a852611fff4b1660d05260c852604860a8205500
```

#### Deployment

The recent root contract is deployed like any other smart contract. A special synthetic address is generated by working backwards from the desired deployment transaction:

```json
{
"type": "0x0",
"nonce": "0x0",
"to": null,
"gas": "0x13d620",
"gasPrice": "0xe8d4a51000",
"maxPriorityFeePerGas": null,
"maxFeePerGas": null,
"value": "0x0",
"input": "0x61014080600a5f395ff3346100ba57366040146100c05736604836066100ba5780156100ba5761048081116100ba574b60005b602081013560c01c828110156100ba5780830361200011156100ba577f8f42481679c8e6fefa040974b3c905e0ce3f2e464ba93acdb074a41181617efc60005260488260203760686000207fbdc897da2177d260ff5f4be5d4b2aad43f89c3347a305b584fa5a2546d053daa60005290611fff1660c01b60405260486000205414156100ba5760480182811061002857005b60006000fd5b33600052602060006020376034600c20807f8f42481679c8e6fefa040974b3c905e0ce3f2e464ba93acdb074a41181617efc6040524b606852606052602060206088376068604020817fbdc897da2177d260ff5f4be5d4b2aad43f89c3347a305b584fa5a2546d053daa60a852611fff4b1660d05260c852604860a8205500",
"v": "0x1b",
"r": "0x539",
"s": "0xfadf66b1e192785c",
"hash": "0x56c2adbbfa3ba5dfe47adf48828f6c581134e39e14c3b80e06214de5e5875272"
}
```

```
Sender: 0x14bf16d4c9842bf1EbF396e553477C66EB0a8A82
Address: 0x8272D9679689Ea2f307140CdF9002D27dC00Ffff
```

### Recent root verifier frame

A **recent root verifier frame** is a frame with all of the following properties:
Expand Down Expand Up @@ -269,15 +304,7 @@ When any recorded dependency may have changed, clients MUST recheck the complete

This EIP MUST activate at or after EIP-8141 and EIP-7843.

For the first block in which this EIP is active, clients MUST initialize `RECENT_ROOT_ADDRESS` against the parent state before executing any transaction.

If `RECENT_ROOT_ADDRESS` does not exist, clients MUST create it with balance 0, nonce 1, code `RECENT_ROOT_CODE`, and empty storage.

If `RECENT_ROOT_ADDRESS` already exists with empty code and empty storage, clients MUST set its code to `RECENT_ROOT_CODE`, set its nonce to `max(existing_nonce, 1)`, preserve its balance, and leave storage empty.

The fork configuration MUST choose a `RECENT_ROOT_ADDRESS` with empty code and empty storage in the parent state of the first active block. If this condition is false, the first active block is invalid.

For all other blocks, clients MUST NOT run this initialization. Clients MUST handle reorganizations across activation by applying or undoing this transition according to the canonical chain.
Activation makes no state change. Until the deployment transaction is included, `RECENT_ROOT_ADDRESS` has empty code, so a recent root verifier frame runs EIP-8141's default code in `VERIFY` mode. Its `flags` are `0`, so the default code reverts and the frame fails.

## Rationale

Expand Down Expand Up @@ -325,9 +352,9 @@ No creation transaction is required. A root source is created when a source addr

This EIP does not change the EIP-8141 transaction payload or signature hash and does not modify other transaction types.

The account at `RECENT_ROOT_ADDRESS` must have empty code and storage before activation. Calls to that address change behavior after activation because `RECENT_ROOT_CODE` is installed there.
`RECENT_ROOT_ADDRESS` is derived from the deployment transaction, so no account holds code or storage there before the deployment.

References to slots before activation are not satisfiable because recent root storage is empty at activation.
References to slots before the deployment are not satisfiable because recent root storage is empty until then.

## Test Cases

Expand All @@ -353,10 +380,9 @@ Implementations should cover at least the following cases. Rejection from the pu
| Signature verification cost plus all validation prefix execution limits, including `recent_root_verify`, exceeds `MAX_VERIFY_GAS` by one | ordinary execution if sufficiently funded | reject |
| Direct evaluation instead of EVM execution | identical frame receipt, gas use, and warm access sets | same admission result |
| Root removed by a reorganization | revert after revalidation | evict |
| Activation installs `RECENT_ROOT_CODE` with empty storage | subsequent writes and validation use `RECENT_ROOT_CODE` | revalidate; reject until every referenced entry exists |
| Activation finds empty code and storage with an existing balance and nonce | preserve balance and set nonce to `max(existing_nonce, 1)` | revalidate |
| Activation finds nonempty code or storage | first active block is invalid | not applicable |
| A later block follows successful activation | do not rerun initialization or clear storage | retain and revalidate normally |
| Recent root verifier frame before the recent root deployment transaction | default code reverts | reject |
| Recent root deployment transaction included | code at `RECENT_ROOT_ADDRESS` equals `RECENT_ROOT_CODE`, storage empty | revalidate; reject until every referenced entry exists |
| Reorganization removes the recent root deployment transaction | default code reverts | evict |
| Reorganization crosses back before activation | this EIP is inactive | evict |

The case with sixteen tuples must include the cold target account access charged at frame entry by EIP-8141, not only the contract's internal execution.
Expand Down
Loading