A coordinated safe space for OP stack chain's EIP-2718 transaction types

[piersy]

This is a discussion to help coordinate an approach for managing the EIP-2718 transaction type space such that conflicts in transaction types between Ethereum, Optimism and OP Stack chains are minimized.

cLabs is currently looking into how they can transition the existing Celo L1 to be an L2 built on the Op Stack.

We noticed that the op stack adds an extra transaction type, the deposit transaction with type value 0x7e (126). It seems likely (based on EIP-2718 ) that Optimism will work backward from there for extra transaction types, so the next transaction would have type 125.

On the celo chain we started adding new types at 124 and are working backwards, currently we have extra transactions with types 123 & 124.

If op were to add 2 more new transactions we'd end up with a clash at type 124. So it would be great if we could co-ordinate a "safe" space for Op stack based chains to use for their own custom transaction types so that we don't run into any clashes.

An initial suggestion would be to assume that Ethereum would continue to work up from 3 and that Optimism would continue to work down from 126 so Op Stack chains could start in the middle at 64 and work outwards (e.g. 65, 63, 66, 62 ... etc). Alternatively a safe range could be defined, but it might be difficult to guarantee the safety of the range, so still could make sense to start in the middle and work outward.

[tynes]

Hey @piersy! Thanks for opening a conversation here.

Do you mind sharing some more information about these transaction types?

A few thoughts:

• Adding a new transaction type will break a lot of the associated tooling. For example, foundry will not be able to simulate transactions if it hits an unknown transaction type during execution. It took a lot of work to get one transaction type supported by the wider ecosystem and it was a painful process. Luckily, its not a transaction type that is signed by end users so we didn't need to worry about getting support for it in wallets (or hardware wallets). I highly recommend looking for ways to reduce adding a transaction type, especially if its something that wallets will need to support. It could be worthwhile to investigate if separated payment tx type or delegate tx type could help with your use case and we can try to get L1 on board with them. But if adding the tx types is best for you and you are aware of the consequences, definitely go for it.
• Its certainly possible that you could push forward the AA ecosystem and save a lot of effort getting ecosystem support for new tx types. Is the AA system still too young? There are certainly a lot of teams that would be excited to help you out with their solutions.
• There is prior art of Mantle creating a meta tx transaction type
• Have you considered the idea of adding "subtypes"? It would be certainly easy to say that a single type is claimed for experimentation and its meant to be subtyped in different ways. This breaks us out of the scarcity of the 1 byte type paradigm.
• I do think its completely fair to add a safe range to enable innovation. I would be in favor of adding the safe range in the middle like you suggest but would love to get more feedback from other people building on OP Stack as well before finalizing this. Not sure if we have the ability to claim that L1 won't be able to take those types but it would create a range for OP Stack chains to innovate freely.
• I think its incredibly unlikely for the OP Stack to add a new transaction type in the short term that L1 isn't adopting. It may be possible that we add new transaction types in the future after we reach escape velocity as a collective but its really unclear and so many things can change. Its so much work to get a new tx type supported by the ecosystem, the odds are stacked against a single team getting support in all of the tooling where as with L1 support, you get everything for free.

Curious to hear what you think

[piersy]

Hi @tynes, thanks for sharing your thoughts!

These transaction types are transactions that allow users of the celo chain to pay for gas in currencies other than the base token.

We have two transaction types that support this. They have types (124) and (123). Most importantly they add a field feeCurrency that allows users to specify the currency they wish to use to pay gas, 123 is a replacement for 124 so 124 is scheduled for deprecation. We are also planning to add support for a new transaction type (122) in the near future.

We are aware of the difficulty in garnering support for extra transactions in associated tooling, however the ability to pay gas in non native currencies was a feature that celo launched with and will need to be maintained in the move to the Op Stack. It seems to me that one of the main ways that L2's can differentiate themselves would be through the addition of new transaction types, the explosion of L2s coupled with the EIP-2718 typed transactions and the fact that some tooling (such as viem) is starting add support for additional features from non-eth chains makes me think that we'll see usage of custom transaction types accelerating as we move forward.

We'll have to think more about the possibility of using AA, it would be a large undertaking but definitely has potential. The subtypes idea is interesting, we hadn't considered that!

Thanks for the heads up on the near term plan regarding new OP Stack transaction types!

We would also love to hear the perspectives of other teams building on the Op Stack.

[tynes]

Hey @piersy thanks for the follow up

I don't see any particular problems with some transaction types being reserved for you. It would be an even easier yes if you used a subtyping scheme, then you can add an arbitrary number of types without needing to ask for additional coordination :) Can you clearly state which version bytes you would like? If you are deprecating a type, then is there a need to reserve that one? You haven't gone to mainnet yet correct?

I highly recommend checking out coinbase smart wallet - the 4337 infrastructure is getting good and it should be possible to allow arbitrary feeCurrency through a paymaster. A demo of the ux can be found here h/t @wilsoncusack. The UX here is magical and you could certainly join the party when it comes to making it better. But obviously choose whatever path you think is best for your users :)

[karlb]

Related to this, we should also watch https://github.com/ethereum/EIPs/pull/9020/files