# EPF - Week 2 This week, my work primarily focused on understanding the Ethereum roadmap and completing Vitalik's research on Ethereum links that I listed last week. ## Summary of Ethereum roadmap (Part 1) Ethereum research is a lot to keep track of, but everything ultimately weaves into one overarching goal – scale computation without sacrificing decentralized validation. ### 1. The merge: better proof of stake Goal: Have an ideal, simple, robust and decentralized proof-of-stake consensus ![Screenshot 2024-06-23 at 00.33.28](https://hackmd.io/_uploads/BkAUZRVU0.png) Secret leader election -> EIP-7441: Upgrade block proposer election to Whisk - > Allow elected block proposers to remain private until block publishing, to prevent DoS attacks single-slot finality （might not be proposed in recent years, but will after Verkle tree and Danksharding） - From 12.6 minutues to 12 seconds; Currently, it takes about 15 minutes for an Ethereum block to finalize. The introduction of SSF aims to make the block validation process more efficient. Under the SSF mechanism, blocks can be proposed and finalized in the same slot, significantly decreasing the time it takes to finalize a block. - Main problem: too many signatures to check and aggregation. - Possible solutions: Few validators (MaxEB)/few active validators / Way fewer validators (8192) + distributed validators tech https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989 Better signature aggregation scheme ![image](https://hackmd.io/_uploads/Sk7IZ04LR.png) ### 2. The surge: more data (availability) for roll-ups Goal: 100,000 transactions per second and beyond (on rollups) ![Screenshot 2024-06-23 at 00.35.04](https://hackmd.io/_uploads/rJ1kfCN8R.png) The problem: how to scale? - >The solution: sharding ( there were many problems to solve to actually get secure specifications for sharding, as well as a lot of questions to answer when it comes to cross-shard communication, backwards compatibility with existing contracts, etc. ) - > the other solution: rollups -> The rollup-centric roadmap -> With rollups in mind, the plan now becomes that Layer 1 will scale data (which is easier to do) and Layer 2 will convert this scalable data into scalable execution. -> Danksharding (While it is a massive simplification of the original data sharding plans, danksharding is still fairly complex and will take some time to ship, while rollup crucially need more data, like yesterday. ) - > Proto-Danksharding EIP-4844 (Proto-Danksharding) -> Blob data -> to reduce the gas fee and improve the roll-ups Currently, transactions in Rollups are published in CALLDATA, which is a very high-cost method because the data in CALLDATA needs to be processed by all Ethereum nodes and exists permanently on the chain. With the new transaction format "blob-carrying transactions" introduced in EIP-4884, we can transfer data to new temporary "binary large objects" for storage. Since binary large objects are not permanent storage, they are relatively cheaper. ![image](https://hackmd.io/_uploads/r1TjZANUA.png) Optimistic Rollup scheme -> Fraud proof -> a data validity verification method In the process of Layer 2 synchronizing data to the Ethereum main network, if someone thinks that the synchronized data is incorrect (that is, there is fraud), they can issue a challenge during the challenge period, and then use Layer 1 smart contract to calculate and determine who the fraud is , and then impose penalties. Data Availability Sampling -> polynomial commitment scheme (KZG commitment) ### 3. The scourge: less MEV (Miner Extractable Value) downsides Goal: mitigate centralization concerns in the Ethereum PoS design, particularly around MEV and liquid staking / pooling ![Screenshot 2024-06-23 at 00.35.43](https://hackmd.io/_uploads/HJ9AWCVLR.png) #### MEV track: Extra-proptocol MEV markets - > Proposer-builder Separation (PBS) PBS splits the block-building and block-proposal tasks among different validators. For each slot, block builders create blocks and present them to the block proposer, who can then choose the most profitable block without seeing its contents. The proposer also has to pay a fee to the block builder before sending the block to its peers. This arrangement prevents transaction censorship, establishes a fairer consensus mechanism, and facilitates the Danksharding upgrade. - Enshrined PBS spec — Coming up with a foolproof ePBS design is no easy task. Here are several proposed designs: - [A viable path to ePBS](https://security.larksuite.com/link/safety?target=https%3A%2F%2Fethresear.ch%2Ft%2Fwhy-enshrine-proposer-builder-separation-a-viable-path-to-epbs%2F15710&scene=ccm&logParams=%7B%22location%22%3A%22ccm_docs%22%7D&lang=en-US) - [Payload timeliness committee](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054) - [Single-Slot PBS using attesters as distributed availability oracle](https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877) - Inclusion lists – Let proposers put restrictions on block builders, namely to force them to include transactions - [“No free lunch” inclusion list design](https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389) - [Inclusion list notes](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) - [Research into constraining builders without burdening proposers](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808) - Explore execution tickets — A new design for explicitly separating the two duties from validators: attesting to blocks and proposing new blocks (formely known as Attester-Proposer Separation) - [ethresear.ch post](https://https://ethresear.ch/t/execution-tickets/17944) #### Staking economics / experience track - Raise max effective balance – Enable the consolidation of large stakers into a single validator, drastically lowering the number of attestations to reduce bandwidth load on the beacon chain - [ethresear.ch post](https://ethresear.ch/t/increase-the-max-effective-balance-a-modest-proposal/15801) - Improve node operator usability — See other items like Verkle trees and SNARKs that make validator clients much more light weight, but also UX improvements are welcome in here too (e.g. make running a node a simple install-and-run experience) - Reducing minimum balance — 32 ETH is a big deterrant for solo staking, reducing it is becoming more and more of a security - The [Paths to SSF](https://notes.ethereum.org/@vbuterin/single_slot_finality) document highlights several potential staking designs where the 32 ETH minimum is reduced or outright removed - Explore solutions to liquid staking centralization — Mitigating centralization concerns around big liquid staking pools controlling - [Liquid staking maximalism design by Dankrad](https://notes.ethereum.org/@dankrad/r1xAbQXm2) - [Musings about enshrining liquid staking or making decentralized liquid staking much safer](https://vitalik.eth.limo/general/2023/09/30/enshrinement.html) ## Next week: Ethereum roadmap (Part 2) - Finish the following content: the Verge, the Purge and the Splurge. - Try to find the topic to work on.