Skip to content

Update EIP-7793: Change precompiles to opcodes #9651

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

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Update EIP-7793: Change precompiles to opcodes #9651

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1b83056
convert back to opcode
Marchhill Apr 16, 2025
f3faf97
change name to SLOTNUM, fix table formatting
Marchhill Apr 16, 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
30 changes: 17 additions & 13 deletions EIPS/eip-7793.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
eip: 7793
title: TXINDEX precompile
description: Precompile to get index of transaction within block
title: TXINDEX opcode
description: Opcode to get index of transaction within block
author: Marc Harvey-Hill (@Marchhill), Ahmad Bitar (@smartprogrammer93)
discussions-to: https://ethereum-magicians.org/t/eip-7793-txindex-precompile/21513
status: Draft
Expand All @@ -12,37 +12,41 @@ created: 2024-10-17

## Abstract

This EIP proposes to add a new precompile that returns the index of the transaction being executed within the current block.
This EIP proposes to add a new opcode that returns the index of the transaction being executed within the current block.

## Motivation

The new 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, and following the ordering rules. If these rules are not enshrined as block validity conditions then they can be enforced by a smart contract.
The new opcode 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, and following the ordering rules. If these rules are not enshrined as block validity conditions then they can be enforced by a smart contract.

This proposal enables smart contract solutions to check their own transaction index, so they can enforce inclusion at the correct index. These out-of-protocol solutions could be used for experimentation until a design appropriate for enshrinement is agreed upon.

## Specification

If `block.timestamp >= TBD` a new precompiled contract `TXINDEX` shall be created at address `TBD`.
A new opcode `TXINDEX` shall be created at `TBD`. It shall return one stack element.

`TXINDEX` returns as output the transaction index as a 4 byte uint in big endian encoding.
### Output

#### Stack

| Stack | Value |
| ---------- | -------- |
| `top - 0` | `Index` |

`Index` is a 4 byte uint in big endian encoding.

### Gas Cost

The gas cost for `TXINDEX` is a fixed fee of `2`
The gas cost for `TXINDEX` is a fixed fee of `2`.

## 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.
The opcode is priced to match similar opcodes in the `W_base` set.

### ZK-VM proving

The TXINDEX precompile should not increase the complexity of proving EVM execution, as it is similar to existing opcodes such as GAS. If a whole block is proven then no additional inputs to the circuit are required to prove transaction indices, as they can be inferred from the transaction ordering. If a transaction is proved individually then the index must be provided as an input to the circuit, along with the remaining gas for GAS, and more for other introspective opcodes.
The TXINDEX opcode should not increase the complexity of proving EVM execution, as it is similar to existing opcodes such as GAS. If a whole block is proven then no additional inputs to the circuit are required to prove transaction indices, as they can be inferred from the transaction ordering. If a transaction is proved individually then the index must be provided as an input to the circuit, along with the remaining gas for GAS, and more for other introspective opcodes.

## Backwards Compatibility

Expand Down
30 changes: 17 additions & 13 deletions EIPS/eip-7843.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
eip: 7843
title: SLOT precompile
description: Precompile to get the current slot number
title: SLOTNUM opcode
description: Opcode 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
Expand All @@ -12,25 +12,33 @@ created: 2024-12-06

## Abstract

This EIP proposes to add a new precompile that returns the corresponding slot number for the current block.
This EIP proposes to add a new opcode 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.
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 by an opcode.

### 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.
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 opcode.

## Specification

If `block.timestamp >= TBD` a new precompiled contract `SLOT` shall be created at address `TBD`.
A new opcode `SLOTNUM` shall be created at `TBD`. It shall return one stack element.

`SLOT` returns as output the current slot number as an 8-byte uint64 in big-endian encoding.
### Output

#### Stack

| Stack | Value |
| ---------- | ------------- |
| `top - 0` | `SlotNumber` |

`SlotNumber` is an 8 byte uint in big endian encoding.

### Gas Cost

The gas cost for `SLOT` is a fixed fee of `2`.
The gas cost for `SLOTNUM` is a fixed fee of `2`.

### RPC changes

Expand All @@ -55,11 +63,7 @@ Consensus layer clients **may** implement the following new RPC endpoints to con

### 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.
The opcode is priced to match similar opcodes in the `W_base` set.

### Calculation in consensus layer

Expand Down
Loading