# 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.
Last changed by  
 
Micah Zoltu
516

Read more

Tornado Cash Community Build

TL;DR ipfs://bafybeiguelxw5aanwnhvaea5vjhknmcdmwvujne36wgabnkmcbt3563toa If you don't yet have an IPFS enabled browser then you can use one of the following instead (not recommended): https://bafybeiguelxw5aanwnhvaea5vjhknmcdmwvujne36wgabnkmcbt3563toa.ipfs.tornadocash.is https://bafybeiguelxw5aanwnhvaea5vjhknmcdmwvujne36wgabnkmcbt3563toa.ipfs.cf-ipfs.com How To: IPFS Enabled Browser Brave

2/8/2025
BLS In Ethereum

Situation Overview Every Ethereum client will need to integrate BLS prior to The Merge Ethereum's Proof of Stake system uses BLS, and when The Merge happens every Ethereum client that wants to move over to PoS will need to have a BLS implementation that is used on the critical path to consensus. (TODO: check with experts for details) Ethereum client teams do not have in-house BLS/cryptography expertise The current Ethereum clients (Geth, Nethermind, OpenEthereum, etc.) do not have in-house cryptographers who are able to rapidly respond to any BLS related consensus failures that may pop up in production. This creates a problem because production consensus failures require very rapid response and it may not be possible to rapidly find the right people to debug and fix any production BLS bugs. There are a number of use cases where BLS would add significant value to Ethereum prior to The Merge

2/5/2021
Typed Transactions

Relevant EIPs EIP-2718: Typed Transactions EIP-2972: Wrapped Legacy Transactions EIP-2976: eth/##: Typed Transactions over Gossip EIP-2930: Optional access lists EIP-1559: Fee market change for ETH 1.0 chain EIP-2711: Sponsored, expiring and batch transactions. What Has No Objections

11/22/2020
Read more from Micah Zoltu
Published on HackMD