# The Path to 2929 [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929): Gas cost increases for state access opcodes [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930): Optional access lists [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718): Typed Transaction Envelope [EIP-2976](https://eips.ethereum.org/EIPS/eip-2976): eth/##: Typed Transactions over Gossip [EIP-2972](https://eips.ethereum.org/EIPS/eip-2972): Wrapped Legacy Transactions ## Mission 1. Get 2929 into Berlin 2. Launch Berlin ## Option 10 EIP-2929 only ### Pros * Incredibly simple * No introduction of SSZ * No changes to transaction hashes * No changes to transaction processing * No changes to block headers * No changes to devp2p * No technical debt *added* ### Cons * There may exist contracts that will be unable to execute within the block gas limit due to increases in gas costs * There may exist contracts that have broken economics due to a sudden extreme increase in gas used * No technical debt removed * No progress toward SSZ blocks * No progress toward typed transactions ## Option 20 EIP-2929 + EIP-2930 ### Pros * No introduction of SSZ * No changes to transaction hashes * Minimal changes to block headers (transaction tree and receipt tree changes required) * Minimal changes to devp2p (new transaction type needs to be accepted) ### Cons * Without 2718, 2930 will share a first byte with legacy transactions, and discrimination will need to happen on the number of items in the list. This discrimination cannot happen until after the transaction is RLP decoded * Technical debt introduced if we introduce 2718 in a later hard fork as we'll now have 3 types of legacy transactions, with two different discriminants ## Option 30 EIP-2929 + EIP-2930 + EIP-2718, no SSZ ### Pros * No introduction of SSZ * No changes to transaction hashes * Minimal changes to block headers * Minimal changes to devp2p (new tx type) * Transaction type discrimination is not terribly dirty: (switch on first byte, then on `v`) ### Cons * Transaction type discrimination is a bit dirty * Introduces technical debt. We'll eventually (before The Merge) want to convert all 2718 transactions to SSZ and we are introducing *more* transactions types that are going to have to go through a transition process or be deprecated ## Option 35 EIP-2929 + EIP-2930 + EIP-2718 + EIP-2972, No SSZ ### Pros * No introduction of SSZ * TBD ### Cons * TBD ## Option 40 EIP-2929 + EIP-2930 + EIP-2718 + SSZ ### Pros * No changes to transaction hashes * 2930 transactions are ready to go for The Merge * Good initial progress toward SSZ blocks (SSZ library now in all ETH1 clients) ### Cons * Clients will need to integrate SSZ before Berlin * Legacy transactions remaining in legacy format introduces complexity in the decoding process * Block header changes are a bit more involved due to new hashing algorithm for 2930 transactions * Devp2p changes are a bit more involved due to new hashing algorithm for 2930 transactions ## Option 50 EIP-2929 + EIP-2930 + EIP-2718 + EIP-2972 + SSZ ### Pros * Transaction root and receipt root can also become SSZ * We are fully prepped for SSZ blocks * We can start to benefit from SSZ recursive proofs * Very little technical debt added (edge conversion of RLP transactions to SSZ transactions) * Some technical debt reduction (EIP-155) ### Cons * SSZ must be integrated * SSZ libraries need Union support (specced out and simple, but not implemented yet in most libraries) * devp2p changes are a bit more involved due to new hashing algorithm * Gossip around the fork block becomes weird with legacy transaction hashes * Legacy transaction hashes change, and we have to deal with that around the fork block * There may be tooling out there that breaks when legacy transaction hashing algorithm changes ## FAQ ### Why are options factors of 10 Because I suspect we will introduce new options that lie somewhere in the middle, and I like integers.