Update EIP-7843: calculate slot in CL, improve motivation

Merged by EIP-Bot.

EIPS/eip-7843.md

@@ -1,7 +1,7 @@
 ---
 eip: 7843
 title: SLOT precompile
-description: Precompile to get the current slot
+description: Precompile to get the current slot number
 author: Marc Harvey-Hill (@Marchhill)
 discussions-to: https://ethereum-magicians.org/t/eip-7843-slot-precompile/22234
 status: Draft
@@ -12,15 +12,15 @@ created: 2024-12-06
 
 ## Abstract
 
-This EIP proposes to add a new precompile that returns the corresponding slot for the current block.
+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 number to be calculated by the execution layer and exposed in a precompile.
+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.
 
-### Encrypted Mempools
+### Example application: Encrypted Mempools
 
-This precompile aims to improve support for encrypted mempools. 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.
+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
 
@@ -30,7 +30,26 @@ If `block.timestamp >= TBD` a new precompiled contract `SLOT` shall be created a
 
 ### Gas Cost
 
-The gas cost for `SLOT` is a fixed fee of `2`
+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.
+
+#### newPayload change
+
+The `engine_newPayload` endpoint shall include a new parameter `slot_number` 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
 
@@ -42,6 +61,10 @@ The precompile is priced to match similar opcodes in the `W_base` set.
 
 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.
+
 ## Backwards Compatibility
 
 No backward compatibility issues found.