EIP-7843: SLOT precompile
Precompile to get the current slot number
| Authors | Marc Harvey-Hill (@Marchhill) |
|---|---|
| Created | 2024-12-06 |
| Discussion Link | https://ethereum-magicians.org/t/eip-7843-slot-precompile/22234 |
Table of Contents
Abstract
This EIP proposes to add a new precompile that returns the corresponding slot number for the current block.
Motivation
It is currently possible to calculate the slot number from the block timestamp. However, this requires hardcoding the chain slot length into a smart contract. This would require the contract code to be changed in the event of a future change to slot length. A better approach is for the slot length to be abstracted away from applications, and instead the slot number can be calculated in the consensus layer client and exposed in a precompile.
Example application: Encrypted Mempools
An example of a smart contract that needs the slot number is a validation contract for an encrypted mempool. In order to be secure, the validity of encrypted mempool transactions should be tied to the inclusion of all transactions by a proposer in the correct slot. This rule can be enforced by a smart contract using this precompile.
Specification
If block.timestamp >= TBD a new precompiled contract SLOT shall be created at address TBD.
SLOT returns as output the current slot number as an 8-byte uint64 in big-endian encoding.
Gas Cost
The gas cost for SLOT is a fixed fee of 2.
RPC changes
The slot number is calculated in the consensus layer and passed to the execution layer through the engine API.
Header extension
The header encoding shall be extended to include a slot_number field of type uint64.
PayloadAttributes change
The engine API’s PayloadAttributes object shall be extended to include a slot_number field of type uint64.
New JSON-RPC endpoints
Consensus layer clients may implement the following new RPC endpoints to convert between slot numbers and their corresponding timestamps.
eth_getSlotNumberFromTimestamp: uint64 -> uint64
eth_getTimestampFromSlotNumber: uint64 -> uint64
Rationale
Gas Price
The precompile is priced to match similar opcodes in the W_base set.
Precompile
Making the feature a precompile rather than an opcode gives L2s flexibility to decide whether to implement it.
Calculation in consensus layer
The slot number could alternatively be calculated in the execution layer using the timestamp, but it is more appropriate to calculate values pertaining to the beacon chain in the consensus layer. Additionally this avoids code duplication, as the slot number is already calculated in the consensus layer.
ZK-VM proving
The SLOT precompile should not increase the complexity of proving EVM execution, as it is similar to existing opcodes such as TIMESTAMP. The slot number is included in the block header rather than as a new_payload parameter, ensuring that the block is self-contained for proving; no extra inputs to the circuit are required.
Backwards Compatibility
No backward compatibility issues found.
Test Cases
N/A
Security Considerations
None.
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Marc Harvey-Hill (@Marchhill), "EIP-7843: SLOT precompile [DRAFT]," Ethereum Improvement Proposals, no. 7843, December 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7843.