Discussion thread for Add EIP: TXINDEX precompile by Marchhill · Pull Request #8981 · ethereum/EIPs · GitHub
This EIP proposes to add a new precompile that returns the index of the transaction being executed within the current block.
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.
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.
3 Likes
Could this be a precompile/system contract instead of an opcode?
I’d like to reverse the tide of consensus specific opcode entering into the EVM.
1 Like
Sure it could be, do you think this would make implementation less complex?
I’m not too sure what you mean by consensus specific as the tx index only depends on the execution payload.
1 Like
My concern is less about introspection and more about adding features in L1 that future L2s may not need, to keep the EVM as “modular” as possible.
Adding opcodes that reflect Ethereum’s specific consensus algorithm create baggage that other “ethereum equivalent” L2s have to manage. Some are obvious, such as how to handle blobs in a L2 that doesn’t have sub-blobs: return zeros and otherwise handle the block like there were no blobs.
What we are doing with the beacon block root I think is the better way forward: surface it in the contracts instead of altering the VM when a new consensus feature is exposed. L2s that don’t have a beacon block root don’t then have to alter the EVM to remove or alter an opcode.
1 Like
That’s a good point, will change to a precompile 
1 Like