# Typed Transactions ## Relevant EIPs * [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718): Typed Transactions * [EIP-2972](https://eips.ethereum.org/EIPS/eip-2972): Wrapped Legacy Transactions * [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976): eth/##: Typed Transactions over Gossip * [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930): Optional access lists * [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Fee market change for ETH 1.0 chain * [EIP-2711](https://eips.ethereum.org/EIPS/eip-2711): Sponsored, expiring and batch transactions. ## What Has No Objections * Typed transactions are desirable. * 2718 is a good way to achieve typede transactions. * 2930 should be a typed transaction. * 1559 should be a typed transaction. * 2930 should go into Berlin. * 2718 should go into Berlrin. * It would be nice to have a single way of processing transactions across the codebase. ## Micah's Preference *As the author of this document, I am recording my preferred path to Berlin here* * All transactions are SSZ serialized both for hashing, transport, and merklization. * Legacy transactions are included in blocks and sent over the wire in SSZ format, but for the purpose of signing they are first re-encoded as `rlp(keccak256(tx))` to maintain signature compatability. * We solve the problem of transient dual-hashing in the clients * simplest solution is to just provide a bad UX around the fork block * better solution is to store both hashes (legacy and new) in memory for about a week around the fork block so users can lookup transactions that were submitted prior to the fork but mined after the fork **Caveat** All SSZ libraries need to implement Unions (not currently the case since it isn't used for beacon chain) for this to work well! ## Path of Least Resistance *The author of this document believes this solution is least likely to get negative pushback from core devs* * Legacy Transactions are Typed Transactions with type of `0xf8 || 0xf9 || 0xfa`. * Legacy Transaction IDs (hashes) continue to be generated as they are today (`keccak256(rlp(transaction))`). * We assert that Legacy Transaction support will be dropped in 2 years. * All new transaction types (e.g., 2930, 1559, etc.) are SSZ serialized. * All new transaction IDs (hashes) are SSZ merkle roots. * Merklization and transport continues to use RLP lists, since we cannot define an SSZ container that is backward compatible with legacy transactions of type `0xf8` to `0xfa` ## Problems ### Legacy Transactions **Legacy Transaction**: A transaction that uses the signing process and transaction structure from the yellow paper, with or without EIP-155. **Problem**: We cannot immediately drop support for legacy transactions because tooling across the ecosystem only knows how to sign legacy transactions. **Potential Solution**: Wrapped legacy transactions. This allows us to make everything a typed transaction, and get rid of some of the EIP-155 complexity currently present in wrapped transactions. **Problem**: Wrapped legacy transactions have a dual hash problem (see [Hashing](#TransactionReceipt-Hashing) below). **Potential Solution**: An RLP encoded legacy transaction can only (realistically) have 3 leading bytes (0xf8, 0xf9, 0xfa). We could assert that with the introduction of 2718 there are 3 new types of transaction -- 0xfa, 0xf9, 0xfa -- and the mechanism for decoding the payload would be something like `rlp_decode([0xfa, ...payload])` which is in contrast to `rlp_decode(payload)` or `ssz_decode(payload)`. This way, all of the code could more or less pretend that legacy transactionts are typed transactions. ### SSZ **SSZ Serialization**: A new serialization format that would replace RLP. **SSZ Merkleization**: A mechanism for turning an SSZ Serialized payload into a merkle tree that can be done recursively such that you can get merkle proofs from the tree root (e.g., head block hash) down to any child (e.g., the log of a particular transaction receipt from 3 million blocks ago) There seems to be weak consensus that SSZ is desired long term for Ethereum and it brings some great features around proofs if we can get to a place where the entire block uses SSZ all the way down. There already exist a bunch of SSZ libraries for many languages due to its usage in ETH2 and the beacon chain. **Problem**: If we plan to move to all SSZ blocks at some point, anything we add that isn't SSZ is tech debt. **Problem**: Integrating SSZ into clients will take time, and we would like to release Berlin sooner rather than later. ### Transaction/Receipt Hashing We need a unique identifier for transactions in `transactions_root` and we need a UID for receipts in `receipts_root`. We also use these same UIDs for gossip to identify what each peer needs before sending data. These UIDs should be generatable from the transaction/receipt (e.g., a hash). Currently we do `keccak256(rlp(transaction))` and `keccak256(rlp(receipt))` to achieve this, but SSZ merkleization would also achieve this. **Problem**: If we want the UID generation process for all transactions to be the same, and the UID generation process for all receipts to be the same after the fork block, then legacy transactions will have a different UID before and after the fork block. This means that if someone submits a transaction to a node before the fork block, it will have a different UID before and after the fork block. Also, gossip gets weird around the fork block as the fork block propogates and clients are in a mixed state of whether they are using new or old UIDs. **Potential Solution**: Clients internally index transactions within 7 days (arbitrary) of the fork block by both UIDs so users can lookup by either. This adds notable complexity to clients, but it is complexity that can be deleted later. **Problem**: Tooling that calculates transaction hashes itself must be updated. **Potential Solution**: Legacy transactions are hashed the old way, new transaction types use a new UID generation process. **Problem**: We have to deal with multiple mechanisms of UID generation until such time as we can deprecate legacy transactions. --- ## Proposed Long Term Target Sometimes it helps to imagine a future we desire, and then figure out the best path for getting there. There are significant benefits in terms of light clients and proofs if we can get to an all SSZ block. We also benefit from notable simplification of the various client codebases if we no longer have to support/propogate legacy transactions. Gossip over things like UDP (with limited packet size) also benefits if we can do SSZ merklization of transactions and receipts as a partial payload can be proven to be part of the larger whole payload. As a thought experiment, if we were to switch over to fully SSZ merklized blocks in the fork after Berlin, how much pain would we be taking on by choosing any of the paths outlined above? * Would we be causing ourselves significant difficulty by choosing to keep legacy transactions unwrapped in Berlrin? * Would we be causing ourselves significant difficulty by choosing to use `keccak256(rlp(transaction))` as the UID generation mechanism for transactions and similarly for receipts? * Would we be causing ourselves significant difficulty by introducing new transaction types that are RLP encoded internally, knowing that in the next fork we'll just have to drop support for that transaction and re-introduce it with a new format?