@shemnon cheers Danno that’s really helpful
This sounds useful, and I’m wondering if this EIP could come in handy for other mechanisms like ERC-4337 bundlers and the Ultra Tx proposal.
But as the EIP says:
If these rules are not enshrined as block validity conditions then they can be enforced by a smart contract.
Programmatically reverting can still be costly, and there’s no way to ensure that a transaction is top of the block. So for this use case to be practical, you might also need other mechanisms like inclusion lists and revert protection.
You have convinced me ser, system contract makes more sense you are right.
I shared a research post here that applies the TXINDEX precompile to an encrypted mempool design. Hopefully this can clarify why this precompile is useful for encrypted mempools.
1 Like
I’ve made a couple of changes to this EIP which you can see here.
First I changed back to an opcode (also for EIP-7843 SLOTNUM). @shemnon suggested to change to a precompile originally, but the feedback I’ve got from client teams is that they would prefer not to add new precompiles. Additionally, I’ve got feedback that it’s not a big problem for L2s to remove opcodes. One other advantage is that there is less gas overhead as an opcode.
The bigger change is going from TXINDEX to ASSERTTXINDEX. This is based on feedback from @LukaszRozmej and @wjmelements around parallel block building. This change means that you can statically determine what the expected transaction index is, meaning that you can’t impose complex, dynamic constraints on block building.
Also I will be talking about this EIP and EIP-7843 on PEEPanEIP podcast at 18:30 UTC tomorrow (15th May). If you are interested or have any questions please join!
3 Likes