Learnings from Devcon VI: Ethereum is Failing Forwards
Galaxy Research’s Christine Kim attends the 6th annual Devcon conference, Ethereum’s largest gathering of developers and ecosystem builders. She explains in this note the main themes of discussion at the conference and why Ethereum is failing forwards.
“Without failure, there is no achievement.” – John C. Maxwell
After three years of postponement due to a global pandemic, the 6th annual Ethereum developer conference, Devcon VI, was hosted by the Ethereum Foundation (EF) in Bogotá, Colombia. The return of Devcon coupled with the successful activation of Ethereum’s Merge upgrade one month prior to the event created a giddy atmosphere of celebration and cheer among conference attendees. Also contributing to the celebratory mood of the conference were the colorful displays of Latin American culture that bookended the conference and highlighted the importance of bridging the Ethereum community around the world.
Devcon’s intentional focus on pushing forward adoption of Ethereum to “the next billion developers,” as emphasized by Aya Miyaguchi, Executive Director of the Ethereum Foundation (EF), during the opening ceremonies of the conference was echoed by several other presenters this year. During talks about the applications of zero-knowledge (ZK) technology, account abstraction, maximal extractable value (MEV), and more, presenters frequently asked and hypothesized about what types of infrastructure and mechanisms are needed to take Ethereum to the next level and achieve widespread adoption. Broadly speaking, many agreed Ethereum needs stronger qualities of censorship resistance and scalability. Without these qualities, many argued, Ethereum cannot achieve its vision of becoming the world computer.
Despite the many achievements of Ethereum over the past three years in terms of protocol-level upgrades and community building, Ethereum developers grappled with the network’s lack of censorship resistance and scalability today. Developers were not shy about speaking on Ethereum’s failures primarily because they were also highly convicted that with each upgrade, the network continues to inch forwards, not backwards, in its grand pursuit of building a secure, scalable, and decentralized general-purpose blockchain.
As of Friday, October 14, more than 50% of Ethereum blocks are produced by censoring relays.
As background, relays are the infrastructure providers on Ethereum that enable validators to earn maximal extractable value (MEV) through third-party block builders. The separation of builders from validators who propose and finalize blocks on Ethereum was intended to help distribute MEV profits more equally among validators. This design called Proposer Builder Separation (PBS) was largely spearheaded and architected by the research and development team known as Flashbots. Since implementing the initial technology for PBS on Ethereum, Flashbots has faced criticism for operating a relay and builder that complies with U.S. sanctions and excludes transactions interacting with the Tornado Cash smart contract.
The S.U.A.V.E Project
Co-founder of Flashbots Phil Daian addressed concerns on Friday about the growing number of censored blocks on Ethereum because of the Flashbots relay and builder, speaking candidly about the need for increased competition to reduce Ethereum’s reliance on Flashbots products. Daian also shared that the Flashbots team would start to develop and design a new encrypted mempool for Ethereum with properties of censorship resistance and decentralization built-in from the start. Details around the implementation of this project, codenamed Single Unifying Auction for Value Expression (SUAVE), were not shared during the presentation. Daian explained the early code specifications for SUAVE will be open sourced on GitHub in a few weeks, but without more detail, it is difficult to evaluate the efficacy or practicality of the SUAVE project at this time.
Block Value Comparison
Terence Tsao of Prysmatic Labs spoke on multiple occasions throughout different panels and presentations at Devcon VI about the need for prioritizing censorship resistance in Ethereum’s next protocol upgrade dubbed Shanghai. He proposed on Twitter an addition to the Engine API, which is the interface between the Consensus Layer (CL) client and Execution Layer client (EL) of an Ethereum node, that would evaluate the profitability of an externally built block versus a locally built one. Such a mechanism would ensure that the cost of censoring behavior by builders is transparent and easily rejected by profit-motivated validators if a censored block is less profitable than an uncensored one. However, given that the relay and builder with the highest returns are operated by Flashbots, it is unclear how this solution would improve Ethereum’s censorship resistant qualities in practice. While such a mechanism would symbolically reinforce the fact validators are not censoring for the sake of undermining Ethereum’s censorship resistant qualities, it would not meaningfully change the current dynamics of censoring behavior on-chain.
Inclusion Lists and UASFs
Other discussions around enforcing censorship-resistance on Ethereum in the short-term included the implementation of transaction inclusion lists and user activated soft forks (UASFs). Inclusion lists refer to a list of transactions that a validator can require builders to include into their block. For example, instead of leaving the block building entirely up to the builder, a validator could fill 10% of block space with the top paying transactions they see locally from Ethereum’s uncensored mempool. There are number of outstanding questions around inclusion lists, however, including how to prevent transactions in the inclusion list from colliding with the transaction bundles included by a builder, where to enforce inclusion of a list within a block, and whether builders would even build a non-compliant block if that became a requirement. Based on discussions at Devcon VI around inclusion lists, it would seem there is not much confidence in the efficacy of inclusion lists for enforcing censorship resistance on-chain.
Similarly, user activated soft forks to slash censoring validators, while effective in practice, would require a significant amount of social coordination that remains unlikely based on competing views by major Ethereum stakeholders—there is likely to be wide disparity regarding what constitutes an unacceptable level of censoring activity on-chain. While sentiment around protecting Ethereum’s censorship resistant qualities on-chain was widely and strongly shared among Devcon VI attendees, no clear solution or roadmap emerged from the conference to combat the real ways in which Ethereum’s censorship resistance is already being undermined.
Beyond censorship resistance, developers at Devcon VI discussed the roadmap for improving Ethereum’s scalability at length.
Layer-1 Protocol Development
During the Ethereum Magicians workshop,Ethereum core developers gave a debrief on learnings from the Merge upgrade and their aspirations for the next major upgrade on the roadmap, Shanghai. Most developers at the workshop agreed that staked ETH withdrawals for the Shanghai should be prioritized but it was not as clear whether developers would also prioritize Ethereum Improvement Proposal (EIP) 4844 for the same upgrade given that the implementation of EIP 4844 is comparatively more complex and research heavy. EIP 4844 is a code change designed to improve the scalability of Ethereum by introducing a new transaction type to the network that would be optimized for settling batched transactions from Layer-2 rollups.
An alternative approach to improving Ethereum scalability in the short-term through rollups is EIP 4488 which reduces the gas cost of calldata on the network by 5x. Calldata is an operation that is frequently relied upon by Layer-2 rollups when posting transaction data to Layer-1 Ethereum. Though EIP 4488 is simpler to implement than EIP 4844, most developers are currently looking into preparing EIP 4844 for Shanghai as it would pave the way for full data sharding on Ethereum, also sometimes called “danksharding.” Over the long-term, the community intends to scale Ethereum through danksharding and Layer-2 but, in the interim, the general sentiment among developers is to prioritize an early version of danksharding in Ethereum either for Shanghai or the subsequent upgrade.
Layer-2 Protocol Development
As Ethereum core protocol development becomes increasingly focused on scalability and supporting Layer-2 rollups, L2 protocol development is becoming increasingly guided by a winner-take-all mentality. Rather than Layer-2 projects sharing ideas and working together collaboratively to advance the best technologies for rollups, each Layer-2 project is in fierce competition with the other for users, adoption, and legitimacy. In part, this is why there was controversy over the acquisition of Prysmatic Labs, a major Ethereum core development team, by Offchain Labs, the development team behind a leading Layer-2 project known as Arbitrum. For more insight about the acquisition, read this Galaxy Research newsletter.
Competition among for-profit, venture-backed companies, each of whom is building their own optimistic or zero-knowledge (ZK) rollup is not conducive for knowledge-sharing in the Layer-2 space, including the exploration of specific ideas like a multi-prover system. A multi-prover system refers to a rollup that generates both fraud and validity proofs in parallel to combine the programmability of optimistic rollups with the security guarantees of ZK rollups. Competition among L2s is also not conducive for honest reflection about the short comings of rollups in general on Ethereum. As seen between projects working on a zkEVM, more time is spent tearing down the achievements of their competitors and announcing product launches faster than other competitors than honest reflection about a project’s capabilities and shortcomings. This makes it difficult from the perspective of decentralized application (dapp) developers and end-users to separate fact from fiction and meaningful innovation from marketing.
There are many benefits from the competitive and for-profit nature of Layer-2 protocol development such as increased funding, interest, and faster innovation. However, the drawbacks are important to note given that Ethereum’s scalability depends more than ever on rollups. Who wins the rollup game and whether an entrenched set of players will be conducive with the values of Ethereum’s base layer are important questions developers are asking in earnest now.
My main takeaway from Devcon VI is that Ethereum is failing forwards. Without a doubt, discussions around censorship resistance and scalability on Ethereum are sobering considering the current realities about how Ethereum operates today. However, these discussions are far from taboo within the Ethereum community. Active discussion, debate, and contributions to improving these qualities about Ethereum are encouraged and that is most encouraging to see. Even though talking about hard problems often makes the Ethereum community an easy target for criticism and ridicule, it also makes the Ethereum community the most likely to attract the best problem-solvers in the world. A culture of openness, inclusivity, and insatiable drive to see positive change in the world is what makes Ethereum, Ethereum and why every challenge, misstep, and roadblock in Ethereum’s journey has never been fatal to the project. In the words of John C. Maxwell, “No great success was ever achieved without failure.”