# Rollup-Centric Roadmap (2024 version) (mike+stokes version) (From The Vault) <img src=https://storage.googleapis.com/ethereum-hackmd/upload_f49fd8af897c1b09ee2f672f53ccb853.png width=99%> <br> <sub>**^*[memetic source material](https://www.youtube.com/watch?v=sRxrwjOtIag)... also the acronym at the end pokes fun at [atwtmvtvftv](https://www.urbandictionary.com/define.php?term=atwtmvtvftv) and over-acronymization generally (which both authors are prone to themselves :-)***</sub> $\cdot$ *by [mike](https://twitter.com/mikeneuder) + [stokes](https://twitter.com/ralexstokes) – thursday. february 15, 2024.* $\cdot$ **tl;dr;** – *It has been over three years since Vitalik put pen-to-paper voicing ["a rollup-centric ethereum roadmap."](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) While there have been immense changes in the interim, the vision expressed aged like fine wine as the Ethereum community continued down this path. The launch of the beacon chain, the merge, withdrawals, and the imminent proto-danksharding fork embody the engineering, research, and coordination excellence of the individuals and teams contributing to the protocol. As 2024 sets in, however, there is more noise than ever. We feel it is worth reviving the "rollup-centric roadmap" with an updated worldview; modern problems may necessitate novel solutions.* *Rather than starting with the **problems** and evaluating which is most pressing or concerning, we propound using the **values** as a starting point. While this may seem dogmatic and disconnected from reality, we believe it's useful and helps answer the question of "<u>what are the right problems to solve?</u>" We employ a "past, present, future" structure to provide a holistic view of the evolution of the protocol. [Section 1](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#Section-1-%E2%80%94-A-Brief-History-of-Ethereum) (past) sets out a summary of recent Ethereum history. [Section 2](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#Section-2-%E2%80%94-Ethereum-in-2024-a-vibe-check) (present) highlights the key issues of today. Sections [3](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#Section-3-%E2%80%94-What-is-Ethereum-exceptional-at) & [4](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#Section-4-%E2%80%94-What-is-Ethereum-not-trying-to-do) pause the timeline to focus on <u>what Ethereum does well</u> (§3) and critically <u>what Ethereum is not trying to do</u> (§4). This multi-sectional interlude lays the foundation for the proposed forward-looking plan presented in [Section 5](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#Section-5-%E2%80%94-Looking-forward) (future), which we subdivide into the immediate-term (Prague/Electra fork in 2024 [[§5.1](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#%C2%A751-%E2%80%93-To-PragueElectra-targeting-end-of-year-2024)]) and the medium-term (3-4 years into the future [[§5.2](https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv#%C2%A752-%E2%80%93-And-beyond-%E2%80%9Cmedium-term%E2%80%9D-approx-3-4-years)]).* *Lastly, we would like to emphasize that this article represents the opinions of the authors alone; the ideas expressed in no way represent the "official" views of the EF (even mentioning this feels presumptuous, but to err on the side of caution, we do). Sections 1-4 aim for objectivity as we set the stage for the more subjective ideas verbalized in Section 5.* $\cdot$ ## Section 1 — A Brief History of Ethereum <img src=https://storage.googleapis.com/ethereum-hackmd/upload_c3410e4750eab380fdedb845ae01c2e5.png width=30%> <sub>**^would read that**</sub> Before looking forward, let's take stock of Ethereum as it [exists today](https://www.youtube.com/watch?v=PWT3ys6x1lI) and how we got here. In the 3.5 years since Vitalik's October 2020 classic, "[*A rollup-centric ethereum roadmap*](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)," a lot has changed. Using the protocol upgrades as "mile-markers" of progress, we focus on the "main point" of each consensus upgrade. For the exhaustive list of execution layer upgrades and each fork's EIPs, see the [ethereum history](https://ethereum.org/history) page. - **[December 1, 2020]** – *Beacon chain genesis* - A mere 35 seconds into the year's final month, we had our first beacon chain block (we probably should have aligned slot times to $0,12,24,36,48$ rather than $11,23,35,47,59$ ([slide 41](https://docs.google.com/presentation/d/1LkxHrXjQyRh2i75R13yjndc_aUp9oXTAdAw538XfJhk/edit#slide=id.g29a7470c685_0_747)) but alas). - See the [announcement post](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21). - **[October 27, 2021]** – *Altair* - This fork entailed updating validator incentives and adding light client support. It also served as a "test fork" for the consensus layer to prepare for the merge. - See the [consensus spec](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair) and [annotated spec](https://github.com/ethereum/annotated-spec/blob/master/altair/beacon-chain.md). - **[September 15, 2022]** – *Bellatrix / Paris* - "The merge." Ethereum is now fully proof-of-stake. - See the [consensus spec](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix), [annotated spec](https://github.com/ethereum/annotated-spec/blob/master/merge/beacon-chain.md), and [execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md). - **[April 12, 2023]** – *Capella / Shanghai* - "Withdrawals." A small fork to close the loop on the proof-of-stake mechanism. - See the [consensus spec](https://github.com/ethereum/consensus-specs/tree/dev/specs/capella), [annotated spec](https://github.com/ethereum/annotated-spec/blob/master/capella/beacon-chain.md), and [execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md). - **[March 13, 2024 (scheduled)]** – *Deneb / Cancun* - "Proto-danksharding (EIP-4844)". The upgrade shipping data sharding. - See the [consensus spec](https://github.com/ethereum/consensus-specs/tree/dev/specs/deneb) and [execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md). At this zoomed-out granularity, the rationale for the upgrade path is clear. - From December 2020 through April 2023 (~2.5 years), the core devs and researchers executed the **proof-of-stake marathon™**. It's still astounding the level of engineering, research, coordination, and collaboration that went into the merge, and the fact that it went as smoothly as it did is a testament to the community's technical excellence. - From the beginning of 2023 until today (1 year), the focus of the community has shifted to shipping proto-danksharding ([EIP-4844](https://www.eip4844.com/)). "Dencun" represents the first significant step towards scaling Ethereum by reducing data costs for L2s. While this upgrade proved complex, the end is in sight – the date of the mainnet fork is [March 13, 2024](https://twitter.com/TimBeiko/status/1755597708520501672). The strategy enacted through these hard forks has been clear, focused, and congruent with the rollup-centric roadmap. [Tim Beiko](https://twitter.com/timbeiko/) uses the metaphor of each fork being like a "music festival artist list." While many performers (EIPs) get bundled into one event, a headliner defines the fork. The headliners thus far have been "beacon genesis," "validator incentives," "the merge," "withdrawals," and "proto-danksharding." **Even with the benefit of hindsight \<insert "hindsight is 2020" joke\>, we wouldn't change the focus of any hard fork thus far.** ## Section 2 — Ethereum in 2024, a vibe check <img src=https://storage.googleapis.com/ethereum-hackmd/upload_3fccbb4e0f4275ecaf858d09b58ec8f7.png width=70%> <sub>**^is anyone excited for the new ["Wicked"](https://en.wikipedia.org/wiki/Wicked_(2024_film)) movie?** </sub> Ok ... enough back-slappy, self-congratulatory retrospecting. Let's take a critical look at present-day Ethereum. As Dorothy points out in the image above, "we aren't in 2020 anymore"; modern problems call for honest reflection. While the ecosystem grows and professionalizes, many topics vie for attention and action. The resulting cacophony makes it hard to tell what matters and why. We distill many lines of discussion into three [central pillars](https://www.gdargaud.net/Climbing/Freney.html): scaling, MEV[^1], & staking (roughly correlating with the "Surge," "Scourge," & "Merge" on Vitalik's [roadmap](https://twitter.com/VitalikButerin/status/1741190491578810445/)). Completeness notwithstanding, we highlight a few pivotal questions associated with each theme. [^1]: We use "MEV" to broadly capture the externalities associated with the execution protocol: MEV, censorship, timing games, etc. Again, Vitalik's "Scourge" is the correct mental model, but we use "MEV" as a catchall because of its familiarity. 1. ***Scaling*** – <u>*How should Ethereum continue scaling?*</u> - *How should Ethereum think about scaling DA given the proliferation of [alternative](https://docs.availproject.org/) [DA](https://docs.celestia.org/) [sources](https://docs.eigenlayer.xyz/eigenda/overview/)?* - *Should Ethereum even try to scale execution as we pursue the data-sharding roadmap?* - *Should Ethereum have a [clear story](https://www.youtube.com/watch?v=MnsjUZo7RRI) about handling cross-chain liquidity fragmentation and L2 composibility enabled by the L1?* 3. ***MEV*** – <u>*How should Ethereum respond to MEV?*</u> - *Is the current status of [builder centralization](https://www.relayscan.io/) acceptable?* - *How can Ethereum preserve strong [censorship resistance](https://censorship.pics/) properties in a power-law distibuted block production world?* - *How should Ethereum respond to the dependency on `mev-boost` and the recent issues surrounding out-of-protocol software ([prysm bug](https://arbitrum.notion.site/17-relayers-are-failing-with-the-prysm-client-post-Capella-Shanghai-2023-04-12-mainnet-0ef5ccd795e54ae4894fa695f1a3e70b), [low-carb crusador](https://collective.flashbots.net/t/disclosure-mitigation-of-block-equivocation-strategy-with-early-getpayload-calls-for-proposers/1705), [bloXroute optimistic failure](https://gist.github.com/benhenryhunter/5f63ad6b5d68452192e9965925b9878e))?* - *Should Ethereum respond to the advent of [timing games](https://p2p.org/economy/unlock-p2p-orgs-mev-enhancement-feature/) on mainnet?* 5. ***Staking*** – <u>*How should Ethereum staking evolve?*</u> - *How opinionated should Ethereum be about reducing stake [centralization](https://notes.ethereum.org/@djrtwo/risks-of-lsd)?* - *Should Ethereum actively consider [enshrining](https://vitalik.eth.limo/general/2023/09/30/enshrinement.html) some LST features?* - *What are the medium-term risks of Coinbase and other centralized exchanges amassing significant amounts of Ethereum stake (especially considering the [custodians](https://www.coindesk.com/business/2023/11/27/coinbase-is-dominating-a-key-bitcoin-etf-service-can-anyone-else-join-the-race/) of the Bitcoin ETF will likely translate to the ETH and staked ETH ETF filings)?* - *How do we preserve the solo stakers at all costs, given they are already a [relatively small portion](https://blog.rated.network/blog/solo-stakers) of the network?* - *How can the [risks of restaking](https://vitalik.eth.limo/general/2023/05/21/dont_overload.html) be adequately addressed?* While this wall of questions feels scary, we can't let it lead to [analysis paralysis](https://en.wikipedia.org/wiki/Analysis_paralysis). The subsequent sections aim to reframe the discussion around the protocol goals (§3) and non-goals (§4). ## Section 3 — What is Ethereum exceptional at? Pausing our timeline in the present, let's look at Ethereum's exceptionalism®. Because of all these exogenous pressures, clarity over Ethereum priorities is scarce. Instead of top-down reasoning about which risks are \*most risky\*, we propose a bottom-up recentering on what Ethereum is and what makes it unique ✨. 1. ***Decentralization, Censorship Resistance, Credible Neutrality, Permissionlessness, Trustlessness.*** - <u>These descriptors are the root of Ethereum values.</u> Each has a slightly different meaning (which we won't quibble about), but they all tap into the same energy that embodies the ethos of the protocol. They are the "it-factor." - <u>Decentralization is a means to providing censorship resistance.</u> Without decentralization, a party or syndicate can exert influence over the blockchain, and with that power, it's a matter of time before it's taken advantage of. - <u>Censorship resistance is a means to providing credible neutrality.</u> By definition, a system must treat all individuals equally to be [credibly neutral](https://nakamoto.com/credible-neutrality/). - <u>Censorship resistance is a means to remaining permissionless.</u> Permissionlessness covers the use of the blockchain (as a transaction signer), the ability to deploy applications (as a developer), and the feasibility of interacting with the blockchain without any trusted third party (as a validator) – each is critical. - <u>Solo stakers[^2] make Ethereum decentralized.</u> Every decision in Ethereum's design must consider the solo staker. Without solo stakers, there is no meaningful decentralization. - <u>Censorship resistance manifests in black swan moments.</u> It doesn't feel relevant until it is the only property that matters. For example, in Canada, protecting your private property rights didn't feel urgent until they were [abrubtly taken away](https://www.youtube.com/watch?v=pDQkyqxhqPc&t=996s) in 2022. 2. ***The community.*** - <u>Decentralized governance.</u> Ethereum is and aims to continue being much bigger than any single entity. The [open source ethos](https://trent.mirror.xyz/GDDRqetgglGR5IYK1uTXxLalwIH6pBF9nulmY9zarUw) applies across the stack from the client software, the protocol specification, the research, the events, the coordination, etc. - <u>Client diversity.</u> Ethereum has a thriving [multi-client](https://clientdiversity.org/) ecosystem. [Technical benefits](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) aside, client diversity creates a broad set of developers intimately familiar with the protocol and contributing their valuable energy, skills, and perspective towards improving it. - <u>Ethereum is welcoming and kind.</u> The "people" (often referred to as the Layer 0) are the Essential Ingredient. With regular conferences around the globe, thousands of interpersonal relationships, and general \~good vibes\~, Ethereum has long been the "digital home" for new crypto participants. 3. ***Ether the asset.*** - <u>Distribution.</u> While we believe proof-of-stake is the correct consensus algorithm + Sybil protection for Ethereum, it's undeniable that having seven years of proof-of-work was a great token distribution mechanism. - <u>[Lindy](https://en.wikipedia.org/wiki/Lindy_effect).</u> By simply existing for a long time, the Ethereum network has demonstrated its antifragility, which creates trust in the network token and its value proposition. - <u>Utility.</u> We embrace the analogy that likens bitcoin to digital gold and ether to digital oil. After all, ether is the **gas token** of the Ethereum network. - <u>Money-ness.</u> Unlike its analog counterpart (extending the oil analogy), ether also has monetary properties (collateral asset in DeFi, unit of account for digital goods & economic security, medium of exchange across the ecosystem) that extend its value and endow it with a "monetary premium." Ether's candidacy as the "[commodity money](https://en.wikipedia.org/wiki/Commodity_money) of the internet" remains strong. - <u>Value as a necessary condition for security.</u> A core tenet of the "[ultra sound money](https://ultrasound.money/)" thesis is that the security of the network depends on the value of ether the asset; we hold this to be true. If Ethereum aims to be the settlement layer for trillions of dollars of economic bandwidth, the token that denominates the security of those [settlement assurances](https://medium.com/@nic__carter/its-the-settlement-assurances-stupid-5dcd1c3f4e41) must be valuable. - <u>Network effects.</u> Liquidity, existing apps & developers, the EVM, rapidly increasing L2 adoption, etc, all contribute to the strong network effects of ether the asset and the Ethereum ecosystem as a whole. The above is neither exhaustive nor prescriptive. These points highlight the [elements](https://en.wikipedia.org/wiki/Euclid%27s_Elements) of Ethereum differentiation. This enumeration is especially relevant as we now turn our attention to the "non-goals" of the protocol. In our estimation, focusing on the following would be "missing the forest for the trees," even if doing so would have short-term benefits. [^2]: We use "solo stakers" to broadly categorize the long tail of Ethereum validators that participate in consensus. In the future, what this participation looks like could change, but what remains is that there are individuals in many different jurisdictions participating. The counterfactual of, "all staking/validating/consensus participation is handled by professional operators in a small geographic region", leaves the protocol exposed to outside pressures. ## Section 4 — What is Ethereum not trying to do? "There you go again with the proselytizing adulation." If this is your current attitude, then this section is for you. In contrast to what Ethereum is good at, we also seek to identify explicit non-goals (in our view) of the Ethereum network. 1. <u>Provide the most hospitable L1 execution.</u> - This is a critical starting point, as the rollup-centric roadmap \*explicitly\* aims to push user activity to the L2s. **By sharding data and not execution, Ethereum took an opinionated stance that L1 execution will likely remain expensive and not intended for everyday transactions.** - ***Example of resulting tension –*** While app layer developers complain about long slot times and high fees, the fact remains that the Ethereum L1 doesn't intend to be a place for applications. Designing Ethereum to be the "best DA & settlement layer for L2s" might directly contradict the wishes of L1 app developers. For example, decreasing slot times (purely hypothetical) would dramatically improve the UX of L1 transactions at a detriment to the solo staking community; this doesn't seem like a tradeoff worth making. - ***However –*** This doesn't mean Ethereum should actively make L1 execution worse. Because the L1 still provides the [forced transaction execution](https://docs.arbitrum.io/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job) backstop for L2s, it is important to ensure that it is still somewhat reasonable to transact on the L1. Discussions around [gas limit increases](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567) could help here. 3. <u>Provide the cheapest DA layer.</u> - This is important as alternative DA layers alongside the "modular" blockchain narratives continue gaining momentum. **Alternative DA layers do not use any magic technology that is not available to Ethereum. Instead, they don't aim to establish and nurture a solo-staking ecosystem.** - ***Example of resulting tension –*** It follows that Ethereum will not aim to scale byte-for-byte at the same rate as these networks because Ethereum is unwilling to compromise on keeping bandwidth (and compute) requirements reasonable for solo stakers. - ***However –*** Ethereum aims to continue being the "Manhattan" of block + blob space. Scaling blob space "fast enough" to maintain high utility without compromising security is vital. Ethereum benefits from already occupying the [catbird seat](https://en.wikipedia.org/wiki/Catbird_seat); the network effects of existing liquidity, composability, applications, and L2s are extremely potent. **Ethereum DA should continue to provide the best value in terms of price-per-security for rollups.** 4. <u>Operate like a startup.</u> - As mentioned above, Ethereum has Real Decentralized Governance. With multiple consensus and execution clients, app developers, infrastructure providers, app layer service providers, researchers, educators, etc., many people with "skin in the game" and potentially conflicting interests have a say in the protocol's future. **Ethereum governance cannot and should not try to mimic the operational efficiency of a company/startup with a clear organizational hierarchy and centralized decision-making.** - ***Example of resulting tension –*** Network upgrades are a massive undertaking. Many outsiders lament the latency between upgrades, the lack of specific timelines, and the ACD process generally, but the ship is working as intended! Recall §1. - ***However –*** Ethereum should still try to be effective and efficient as permitted within the decentralized governance regime. While the protocol must solidify eventually (protocols in practice are slow to change – see IPv4/IPv6), there are still clear improvements that steward the network's long-term viability. **Ethereum should avoid premature ossification due to politicization and continue executing the roadmap items.** \*steps off the soapbox.\* While we believe the previous section is not contentious (plugging ears to avoid screaming), we permit that it leans into more Subjective Territory; the subsequent section enters the full-blown Opinion Zone. But it's necessary. With limited resources, hard decisions about the future of Ethereum are mandatory. We present our humble perspective on the Prague/Electra fork (§5.1) and the medium-term (§5.2). (getting lots of use of "§" lol). ## Section 5 — Looking forward <img src=https://storage.googleapis.com/ethereum-hackmd/upload_ac608fd78014027cb5c8b3e3ab089bbb.png width=65%> <sub>**^ woke up feeling bullish**</sub> If you are still here, thanks for sticking with us. We finally feel equipped to tackle the "looking forward" question. That's what roadmaps are all about, right? This treatise of sorts for the rollup-centric roadmap with today's understanding aims to frame the future of Ethereum based on the previously stated: - **Acknowledgement** of the historical perspective **outlined in §1**. - **Awareness** of the modern realities of Ethereum **presented in §2**. - **Alignment** with what makes Ethereum special **highlighted in §3**. - **Acquiescence** of what Ethereum is not trying to accomplish **expressed in §4**. Until this point, we have been objective and focused on the facts. Conversely, putting forward opinions on how Ethereum should move forward falls squarely in the domain of subjectivity. What follows is the authors' opinion and is thus colored by their biases – caveat emptor. Nevertheless, we believe it is better to try voicing our views while remaining open to being convinced of other perspectives; "strong opinions, loosely held." Since the endgame has been discussed [at length](https://twitter.com/TrustlessState/status/1756044986796134776), we partition our forward-lookingness into two shorter time horizons. First, we outline a hypothetical Prague/Electra hard fork (conditioned on an EOY 2024 target, which seems to be the rough consensus). Second, we look into the "medium-term" future, which we define as the next 3-4 years. Within each subsection, we split the vision into the three aforementioned tracks: **scaling, MEV, and staking**. ### §5.1 – To Prague/Electra (targeting end-of-year 2024) Inspired by [reth](https://www.paradigm.xyz/2024/01/ethereum-2024), [prysm](https://medium.com/offchainlabs/prysm-electra-upgrade-f827c20d0fd2), and [sigma prime](https://hackmd.io/@dapplion/lighthouse_pectra) releasing their view of the Prague/Electra fork, we share what an ideal (from our POV) end-of-year fork would contain. - **Scaling track** – *"Continue scaling Ethereum, keeping it as the 'Manhattan' of block and blob space."* - Increase blob count based on mainnet 4844 data analysis, perhaps along with a `CALLDATA` cost [adjustment](https://ethresear.ch/t/on-increasing-the-block-gas-limit/18567). Begin implementing [PeerDAS](https://ethereum-magicians.org/t/eip-7594-peerdas-peer-data-availability-sampling/18215), without bottlenecking the Prague/Electra fork on it[^3]. - **MEV track** – *"Take a first step towards addressing MEV centralization risks in the protocol by enshrining inclusions lists."* - See [EIP-7547](https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474) and [related work](https://gist.github.com/michaelneuder/ba32e608c75d48719a7ecba29ec3d64b). - **Staking track** – *"Improve staking UX and begin investing development resources towards Verkle trees & statelessness."* - Adding EL-triggered exits ([EIP-7002](https://ethereum-magicians.org/t/eip-7002-execution-layer-triggerable-exits/14195)) and following through on the [commitment to verkle](https://github.com/ethereum/EIPs/pull/8159) for the Osaka hardfork. [^3]: An undermentioned fact around PeerDAS is that it needn't be rolled out in each client during a specific hard fork beyond every client implementing the interface. Once everyone "speaks" PeerDAS, the clients can safely differ on which blobs they choose to download. A client that downloads all blobs would be a de facto "super node". See [Francesco's document](https://ethresear.ch/t/from-4844-to-danksharding-a-path-to-scaling-ethereum-da/18046) for more on PeerDAS. Zooming out a bit (but not [all the way](https://www.youtube.com/watch?v=y2ak_oBeC-I)), the 3-4-year window gives us more room to contextualize the broader themes. ### §5.2 – And beyond ("medium-term" $\approx$ 3-4 years) - **Scaling track** – *"Scale Ethereum DA by 3x each of the next four years."* - This ambitious goal articulated by [Ansgar](https://twitter.com/adietrichs) is far from a foregone conclusion but provides a mental model for how Ethereum could reasonably commit to scaling in the medium term. The following enables a $81\times$ increase in data throughput over these four years... - *2023 (approximately)* – $3 \times$ by adding EIP-4844 - *2024* – $3 \times$ by increasing blob count & gas modifications - *2025* – $3\times$ by adding PeerDAS - *2026* – $3\times$ by adding full Danksharding - This will allow Ethereum DA to maintain its competitiveness in terms of price-per-byte-per-security. Keeping the "blue chip" general purpose rollups on Ethereum DA is imperative because the Ethereum scaling roadmap depends on the existence of rollups that \*do not compromise\* on security. - **MEV track** – *"Conduct R&D to determine the long-term protocol solution to MEV."* - With [ePBS](https://notes.ethereum.org/@mikeneuder/infinite-buffet), [execution tickets](https://ethresear.ch/t/execution-tickets/17944), [based preconfirmations](https://ethresear.ch/t/based-preconfirmations/17353), [mev-burn](https://ethresear.ch/t/mev-burn-a-simple-design/15590), [encrypted mempools](https://joncharbonneau.substack.com/p/encrypted-mempools), [timing games](https://ethresear.ch/t/timing-games-implications-and-possible-mitigations/17612), [multiplicity for censorship resistance](https://efdn.notion.site/ROP-9-Multiplicity-gadgets-for-censorship-resistance-7def9d354f8a4ed5a0722f4eb04ca73b), etc..., there are many unanswered questions for how the protocol should respond to MEV. - We think that within the medium-term time frame, a concerted effort should go towards researching and implementing the endgame protocol features in response to MEV. - **Staking track** – *"Protect the Ethereum solo-staker as we iterate on proof-of-stake."* - Implement [verkle trees](https://ethereum.org/roadmap/verkle-trees) and [`MAX_EFFECTIVE_BALANCE`](https://gist.github.com/michaelneuder/cafabcfcfcccc45e44ab9d6b1c7b4e1d). These two upgrades have broad support, benefit solo stakers, and will ideally ship ASAP. - Decide on the [path toward](https://notes.ethereum.org/@vbuterin/single_slot_finality) [single-slot finality](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920). The route depends on the decisions made around the target number of [Ethereum validators](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989) and the modifications to the issuance (see Anders' recent work [[1](https://notes.ethereum.org/@anderselowsson/MinimumViableIssuance),[2](https://notes.ethereum.org/@anderselowsson/HyUIqjo_6)]). - Respond to significant uncertainties resulting from stake centralization, the impact of restaking, and LSTs + LRTs (potentially the most important task). To close, Ethereum is defined by the community. So much has changed since 2020, but the people remain. Beyond any of the technical directions highlighted above, putting "alignment," politics, and zero-sum thinking aside while striving to continue being the most open and welcoming community is critical to the success of [The Project](https://twitter.com/ralexstokes/status/1604933277894447104). thanks for reading 📖🤓 <!-- thrilled to share a modern rendition of the "rollup-centric roadmap." @ralexstokes and i offer a values-driven view of Ethereum. with an eye on the past and an honest assessment of the present, we look forward to the next hard fork and beyond. 🛣️🗺️🚙➪ https://notes.ethereum.org/@mikeneuder/rcr2vmsvftv these ideas were shaped through countless interactions with the individuals (far too many to list, but you know who you are) that make up the Ethereum and broader crypto communities, which drives home one of the main points: it's all about the people. https://twitter.com/ralexstokes/status/1604933277894447104 -->