As a professional translator, I am sitting here in Kenya writing this article on the final day of the Ethereum Developers Interoperability, where we have made significant progress in implementing and addressing the technical details of upcoming important Ethereum improvements, most notably PeerDAS, Verkle Trees transition, and decentralized storage of historical records under EIP 4444. From my own perspective, the development speed of Ethereum and our ability to deliver large and impactful features is continuously growing, which can greatly improve the experience of node operators and (L1 and L2) users.
The Ethereum client teams collaborated to deliver the Pectra devnet
With the enhanced technical capabilities, an important question that needs to be raised is whether we are moving towards the right goals. A recent series of frustrated tweets by Peter Szilagyi, a long-time Geth core developer, has prompted us to contemplate this question. These concerns are valid and have been voiced by many members of the Ethereum community. I have personally shared these concerns multiple times. However, I don’t believe the situation is as hopeless as Peter’s tweets may imply. On the contrary, many issues have already been addressed through ongoing protocol improvements, and many others can be resolved through realistic adjustments to the current roadmap.
To understand what this means in practice, let’s review the three examples provided by Peter one by one. These issues are of widespread concern within the community, and it is crucial to address them.
MEV and Builder Dependence
In the past, Ethereum blocks were created by miners using relatively simple algorithms. Users would send transactions to the public P2P network, often referred to as the “mempool” or “txpool.” Miners would listen to the mempool, accept valid transactions, and prioritize them based on the highest fees if there is not enough space in the block.
This was a straightforward system and decentralized-friendly: as a miner, you could simply run default software and earn fee income similar to what you would earn from highly specialized mining farms. However, around 2020, people began exploiting what is known as Miner Extractable Value (MEV) – income that can only be obtained by executing complex strategies that understand the inner workings of various DeFi protocols.
For example, consider a decentralized exchange like Uniswap. Suppose at time T, the USD/ETH exchange rate is $3000 on both a centralized exchange and Uniswap. At time T+11, the USD/ETH exchange rate on the centralized exchange rises to $3005. But there is no new Ethereum block yet. It arrives at time T+12. Whoever creates that block can have their first transaction be a series of Uniswap purchases, buying all available ETH on Uniswap at a price ranging from $3000 to $3004. This is additional income called MEV. Applications other than DEXs also have similar issues, as detailed in the 2019 Flash Boys 2.0 paper.
The problem is that this breaks the “fairness” of why mining (or block proposals post-2022) can be considered “fair”: now, larger participants with better optimization abilities for such extraction algorithms can earn better rewards in each block.
Since then, there has been an ongoing debate between two strategies, which I refer to as MEV minimization and MEV isolation. MEV minimization takes two forms: (i) actively developing MEV-less alternatives to Uniswap, such as Cowswap, and (ii) building protocol-level technologies like encrypted mempools that reduce the information available to block producers, thus reducing their potential earnings. Specifically, encrypted mempools can prevent sandwich attacks and other strategies that place trades before and after user transactions to economically exploit them (“front-running”).
The idea behind MEV isolation is to accept MEV but attempt to limit its impact on the centralization of power within the staking community by dividing the market into two types of participants: validators responsible for proving and proposing blocks, and a separate auction protocol for selecting the content of the block. Individual stakers no longer need to worry about optimizing DeFi arbitrage themselves; they simply join the auction protocol and accept the highest bid. This is known as Proposal/Builder Separation (PBS). This approach has precedents in other industries: one of the key reasons why restaurants can remain decentralized is that they often rely on fairly centralized suppliers for various operations that do have significant economies of scale. So far, PBS has been quite successful in ensuring a fair competitive environment between small and large validators, at least in terms of MEV. However, it brings another problem: the task of selecting which transactions to include becomes more centralized.
My view on this has always been that MEV minimization is good, and we should pursue it (I personally often use Cowswap!) – although encrypted mempools have many challenges, MEV minimization may not be enough; MEV will not go to zero or even close to zero. Therefore, we also need some form of MEV isolation. This presents an interesting challenge: how do we make the “MEV isolation box” as small as possible? How do we give builders as little power as possible while still allowing them to absorb the role of optimizing arbitrage and collecting MEV in other forms?
If builders have the power to completely exclude transactions from the block, it becomes easy for attacks to occur. Suppose you have a collateralized debt position (CDP) in a DeFi protocol backed by an asset whose price drops rapidly. You want to add collateral or exit the CDP. Malicious builders could attempt to collude to exclude your transactions, delaying them until the price drops enough to forcibly liquidate your CDP. If this happens, you would have to pay a substantial penalty, and the builders would gain a significant portion. So how do we prevent builders from excluding transactions and carrying out such attacks?
This is where inclusion lists come into play.
Inclusion lists allow block proposers (i.e., stakeholders) to select the transactions that need to be included in the block. Builders can still reorder and insert their own transactions, but they must include the proposer’s transactions. Ultimately, the modification of the inclusion list constrains the next block rather than the current block. In either case, it deprives builders of the ability to completely exclude transactions from the block.
MEV is a complex problem, and even the above description overlooks many important nuances. As they say, “you may not be looking for MEV, but MEV is looking for you.” Ethereum researchers have been consistently committed to the goal of “minimizing the isolation box” to minimize the harm builders can cause (e.g., by excluding or delaying transactions as a way to attack specific applications).
That being said, I do believe we can go further. In history, inclusion lists have often been considered a “special-case feature”: something you wouldn’t normally think about, but just in case malicious builders start doing crazy things, they give you a “second path.” This attitude is reflected in current design decisions: in the current EIP, the gas limit for inclusion lists is around 2.1 million. But we can philosophically shift how we view inclusion lists: treat them as blocks and the role of builders as adding transactions as an auxiliary mechanism to collect MEV. What if builders have a 2.1 million gas limit?
I find the idea of pushing for a smaller isolation box in this direction very interesting, and I support moving in this direction. This aligns with the “2021-era philosophy”: in the 2021-era philosophy, we are more enthusiastic about the idea that now that we have builders, we can “overload” their capabilities and have them serve users in more complex ways, e.g., by supporting ERC-4337 fee markets. In this new paradigm, the transaction verification part of ERC-4337 must be built into the protocol. Fortunately, the ERC-4337 team has been increasingly excited about this direction.
Summary: The idea of MEV has brought the focus back to empowering block producers, including giving them direct power to ensure user transactions are included. Account abstraction proposals have brought the focus back to eliminating reliance on centralized relayers or even bundlers. However, there is a good argument that we haven’t gone far enough, and I think there is great value in pushing the development process further in this direction.
Staking Liquidity
Today, individual stakers represent a relatively small portion of all Ethereum staking, and most staking is done by various providers – some centralized operators and other DAOs like Lido and RocketPool.
I have done my own research – various surveys, polls, face-to-face conversations, asking the question “Why don’t you – specifically you – stake individually today?” For me, a strong ecosystem of individual stakers is the preferred outcome for Ethereum staking, and one of the best things about Ethereum is that we are actually trying to support a strong ecosystem of individual stakers rather than just succumbing to delegation. However, we are still far from this outcome. In my surveys and polls, there have been some consistent trends:
The majority of non-individual stakers attribute their primary reason to the minimum 32 ETH requirement.
Among those who cited other reasons, the biggest one is the technical challenges of running and maintaining a validator node.
The loss of instant availability of ETH, security risks of “hot” private keys, and the loss of the ability to participate in DeFi protocols simultaneously are significant but smaller concerns.
Staking research needs to address two key questions:
How do we address these concerns?
Even though there are valid solutions to most of the issues, how do we maintain the stability and robustness of the protocol to withstand attacks if a majority of people still don’t want to stake individually?
Many ongoing research and development projects are aimed at addressing these problems:
Verkle trees, combined with EIP-4444, allow staking nodes to run with very low disk requirements. Additionally, they enable staking nodes to sync almost instantly, greatly simplifying the setup process and switching from one implementation to another. They also reduce the data bandwidth required to provide proofs for each state access.
Overall, there is progress being made, but there is still work to be done. The Ethereum community is actively addressing these concerns and pushing for improvements to make Ethereum more accessible, secure, and decentralized. This ongoing effort is essential for the continued growth and success of Ethereum.Making Ethereum Light Clients More Feasible
Research (such as these proposals) allows for methods that enable a larger set of validators (achieving a smaller minimum staking value) while reducing the overhead of consensus node. These ideas can be implemented as part of single-slot finality. This will also make light clients more secure as they will be able to verify the full set of signatures instead of relying on a sync committee.
Despite the growing history, ongoing optimizations of Ethereum clients continue to reduce the cost and difficulty of running validator nodes.
Research on the punishment cap could alleviate concerns about private key risks and allow stakers to simultaneously stake their ETH in DeFi protocols if they wish.
Withdrawal credentials (0x01) allow stakers to set their ETH address as the withdrawal address. This makes decentralized staking pools more feasible and advantageous over centralized staking pools.
However, there is still more we can do. Theoretically, validators could withdraw faster: even if there is a small percentage change in the validator set every time finality is reached (once per epoch), Casper FFG will still be secure. Therefore, if we strive for it, we can greatly shorten the cycle. If we want to significantly reduce the minimum deposit size, we can make difficult decisions and trade-offs in other directions. For example, if we increase the finality time by 4 times, the minimum deposit size will decrease by 4 times. Single-slot finality will solve this problem by surpassing the “every staker participates in every epoch” model.
Another important part of the whole problem is the economics of staking. A key question is: do we want staking to be a relatively niche activity, or do we want everyone or almost everyone to stake all of their ETH? If everyone stakes, what responsibilities do we want everyone to take? If people simply delegate their responsibilities out of laziness, it may eventually lead to centralization. There are important and profound philosophical questions here. The wrong answers could lead Ethereum down the path of centralization and “recreating traditional financial systems with extra steps”; the right answers can create a shining example of a successful ecosystem with a wide and diverse range of independent stakers and highly decentralized staking pools. These questions involve Ethereum’s core economics and values, so we need more diverse participation.
Node Hardware Requirements
Many key issues in decentralized Ethereum ultimately boil down to the question of how to conveniently run nodes and how to achieve it.
Running nodes is difficult today. Most people don’t do it. On my laptop where I am writing this article, I have a reth node that takes up 2.1 TB – the result of heroic software engineering and optimization. I need to buy an additional 4 TB hard drive to put in my laptop to store that node. We all want running nodes to become easier. In my ideal world, people would be able to run nodes on their phones.
As I mentioned above, EIP-4444 and Verkle trees are two key technologies that bring us closer to this ideal. If both are implemented, the hardware requirements for nodes could eventually be reduced to less than 100 gigabytes, and if we completely eliminate the responsibility for historical storage (which may only apply to non-staking nodes), it could approach zero. Type 1 ZK-EVM eliminates the need to run EVM computations yourself as you can simply verify the evidence of correct execution. In my ideal world, we would stack all these technologies together, and even Ethereum browser extension wallets (such as Metamask, Rabby) would have a built-in node to verify these proofs, sample data availability, and ensure the chain is correct.
The above vision is often referred to as “The Verge.”
This is all well-known and understood, even by those who have concerns about the scalability of Ethereum nodes. However, there is one important concern: if we remove the responsibility for maintaining state and providing proofs, isn’t this a centralization vector? Even if they cannot cheat by providing invalid data, isn’t relying too much on them contrary to the principles of Ethereum?
A recent version of this concern is the discomfort many people have with EIP-4444: if regular Ethereum nodes no longer need to store old historical records, then who will? A common answer is that there are certainly enough large participants (such as block explorers, exchanges, Layer 2) who have the incentive to hold this data, and compared to the 100 PB stored by the Wayback Machine, the Ethereum chain is small. Therefore, the idea that any history will actually be lost is absurd.
However, this argument relies on a few large participants. In my trust model categorization, this is the N-of-1 assumption, but N is very small. This has its tail risks. One thing we can do is store old historical records in a peer-to-peer network where each node only stores a small portion of the data. This network would still have enough replication to ensure robustness: each piece of data would have thousands of copies, and in the future, we can use erasure coding (in fact, this is already built-in with EIP-4844-style blobs that store historical records) to further improve stability.
The simplest way to provide super stable storage for all of Ethereum’s history is likely to put the beacon and execution blocks into blobs. Image source: codex.storage
For a long time, this work has been on the backburner. Portal networks do exist, but they have not received the attention they deserve given their importance in the future of Ethereum. Fortunately, there is now a strong interest in dedicating more resources to a minimized portal version that focuses on distributed storage and historical accessibility. We should build on this and work together to implement EIP-4444 as soon as possible and combine it with a powerful decentralized peer-to-peer network to store and retrieve old historical records.
For state and ZK-EVM, this distributed approach is more challenging. To build an efficient block, you only need to have the full state. In this case, I personally lean towards a pragmatic approach: we define and stick to some level of hardware requirements for a “do-everything node” that is higher than the (ideally decreasing) cost chain of simple verification nodes but still low enough that enthusiasts can afford it. We rely on the N-of-1 assumption to ensure that N is quite large.
ZK-EVM proofs may be the trickiest part, and real-time ZK-EVM proof verifiers may require more powerful hardware than archival nodes, even with advancements like Binius and worst-case boundaries of multi-dimensional Gas. We can work on a distributed proof network where each node takes responsibility for a fraction of the proofs, e.g. one percent of block execution, and then block producers only need to aggregate a hundred proofs in the end. Proof aggregation trees can provide further help. But if this doesn’t work well, another compromise is to allow for higher hardware requirements for proofs, but ensure that the “do-everything node” can directly verify Ethereum blocks (without proofs) at a fast enough speed to effectively participate in the network.
Summary
I believe that as long as there is a market mechanism or zero-knowledge proof system that forces centralized participants to act honestly, the Ethereum philosophy of the 2021 era has indeed become accustomed to shifting responsibility to a few large participants. Such systems generally work well under normal conditions but can fail catastrophically in the worst case.
At the same time, I believe it is important to emphasize that the current Ethereum protocol proposals have deviated significantly from this model and are taking the need for a truly decentralized network more seriously. Ideas around statelessness, MEV mitigation, single-slot finality, and similar concepts have gone further in this direction. A year ago, serious consideration was given to the idea of using relays as semi-centralized nodes for data availability sampling. This year, we no longer need to do these things, and PeerDAS has made surprisingly strong progress.
However, there is still much more we can do to push further in this direction on all three central issues I mentioned above and many other important issues. Helios has made great strides in providing “true light clients” for Ethereum. Now, we need to include it by default in Ethereum wallets and have RPC providers offer proofs and their results for verification, and extend light client technology to Layer 2 protocols. If Ethereum scales with a Rollup-centric roadmap, the second layer needs to have the same security and decentralization guarantees as the first layer. In a Rollup-centric world, there are many other things we should take more seriously; a decentralized and efficient cross-L2 bridge is just one example. Many dapps obtain logs through centralized protocols because Ethereum’s native log scanning has become too slow. We can improve this through dedicated decentralized subprotocols; this is a suggestion I have on how to do it.
There is an almost infinite number of blockchain projects targeting the market of “we can be super fast, we’ll think about decentralization later.” I don’t think Ethereum should join this lineup. Ethereum L1 can and should be a strong foundational layer for second-layer projects that adopt a massively scalable approach, using Ethereum as the pillar for decentralization and security. Even a second-layer-centric approach requires the first layer itself to have sufficient scalability to handle a large number of operations. But we should deeply respect the unique features that make Ethereum what it is and continue to work on maintaining and improving those features as Ethereum scales.
Special thanks to Dankrad Feist, Caspar Schwarz-Schilling, and Francesco for their quick feedback and review.
Tags
Vitalik Buterin
Ethereum
Wu Shuo Blockchain Real
Source link:
https://mp.weixin.qq.com/s/eAp0jtR_KkB7IpOMwt2aFw
Note: The opinions expressed in this article represent the author’s views and do not constitute investment advice.
Original link: https://www.bitpush.news/articles/6806827
Related News
Galaxy Digital: Weekly Crypto Commentary – Ethereum ETF, FIT21, Hong Kong, Re-staking
Which tokens are likely to launch ETFs after ETH? SOL has the highest probability, followed by Doge
What is the future of the re-staking market under regulatory pressure?
How to view the future impact of Ethereum ETF: Under the compliance stick, “copying the traditional financial system with extra steps”?
Thoughts: What makes a meme coin successful?