I believe it can be. This opcode gives block builders a direct way to change the outcome of the transaction. Once the transaction is included (with the wrong outcome from the user’s perspective), it is no longer in the mempool and cannot be included in a subsequent block. Therefore any case where a block builder could benefit from censoring a transaction, would be affected by this opcode.
I don’t think we’re ever going to fully eliminate MEV (but that’s a bit beyond the scope of this thread I guess). However, we should be careful when introducing new vectors. I think it’ll be quite challenging to use TXNUM in a contract without introducing undesired MEV vectors.
Plenty. As I explained above, if the execution flow depends in any way on TXNUM, the block builder can control that branch of the execution flow. If it can lead to a revert, or to some operation happing or not happening, then there’s a censorship vector.
Frontrunners typically can’t censor other transactions, only get in front of them and affect the price. But they couldn’t for example, prevent your vote in a governance proposal from being counted. In the example you used in the EIP, a block builder could invalidate a vote that happens in the same block by moving it around. That’s something they wouldn’t be able to do without this opcode.
The same goes for any contract where an action would depend on TXNUM. Suppose a contract uses commit/reveal to protect users against frontrunning. Currently it’s immune to MEV. A concrete example is ENS, where you commit your domain registration before revealing the name. Currently there’s no way to prevent the registration. If a block builder doesn’t include it, the next one will, or the one after that. Now suppose ENS used TXNUM anywhere in the transaction that finalizes the registration. An mev-boost builder will pay the next builder to include it in a position that causes it to fail. They only do it once, since the transaction reverts and the user needs to resubmit it. Keep watching the mempool, invalidate any such transaction at the cost of a single transaction. It would effectively censor the registration.
Suppose a rollup would use TXNUM in its L1 batching contract. A builder can similarly prevent finalization of the entire rollup chain by including it in the wrong position. It makes things quite brittle.
What are some use cases that can only be implemented with TXNUM and wouldn’t be vulnerable to such attacks?
The only use case I could think of, is one that benefits MEV searchers: require the block proposer to include their transaction early in the block and be able to verify it. But I’m sure that’s not what you have in mind.
Why would it matter if it’s relative to the entire history or just this block? The code will still make decisions based on its relative position in the current block (or else it could just use block.number). Once the code makes decisions based on that, it’s likely to become vulnerable to such manipulations.