Vitalik: Maintain the minimalism of blockchain and avoid consensus overload on Ethereum
Written by: Vitalik Buterin
Compiled by: Web3 Grand Voyage
The consensus mechanism of the Ethereum network is currently one of the safest cryptoeconomic systems. Validator nodes worth 18 million ETH (approximately 34 billion USD) confirm a block every 6.4 minutes, and these validator nodes run various different protocol implementations to ensure redundancy. If there are issues with the cryptoeconomic consensus, whether due to bugs or intentional 51% attacks, a large community composed of thousands of developers and even more users carefully monitors to ensure the chain is correctly restored. Once the chain is restored, the protocol rules will ensure that attackers may face severe penalties.
Over the years, many ideas (often in the thought experiment stage) have been proposed to utilize the collection of Ethereum validator nodes, or even the social consensus of Ethereum, to achieve other purposes:
Ultimate Oracle: A proposal where users can vote to indicate the truth by sending ETH, using the SchellingCoin mechanism: anyone who votes for the majority answer can receive a proportional share of all the ETH voted for the minority answer.
The description continues: "So in principle, this is a symmetric game. What breaks the symmetry is a) the truth is a natural point of coordination, and more importantly b) those betting on the truth can threaten to fork Ethereum in case they lose."
Re-staking: A set of techniques used by many protocols (including EigenLayer) where Ethereum holders can simultaneously use their stakes as deposits in another protocol. In some cases, if they violate the rules of the other protocol, their deposits may also be penalized. In other cases, without incentives within the protocol, the stakes are only used for voting.
L1-driven L2 project recovery: It has been proposed multiple times that if L2 has a bug, L1 can fork to recover it. A recent example is this design, which uses an L1 soft fork to recover a failure in L2.
The purpose of this article is to explain in detail why I believe that some of these technologies will bring significant systemic risks to the ecosystem and should be stopped and resisted.
These proposals are often made with good intentions, so the goal is not to focus on individuals or projects, but on the technology. The general principle that this article will attempt to defend is: While there are some risks associated with the dual use of ETH staked by validators, it is fundamentally acceptable; however, attempting to "recruit" Ethereum's social consensus to serve the purposes of your application is undesirable.
Examples of the distinction between reusing validators (low risk) and social consensus overload (high risk)
- Alice creates a web3 social network where if you can cryptographically prove you control the key of an active Ethereum validator, you automatically gain the status of "validator." Low risk.
- Bob cryptographically proves he controls the keys of ten active Ethereum validators to demonstrate he has enough wealth to meet certain legal requirements. Low risk.
- Charlie claims he has disproven the twin prime conjecture and asserts he knows the largest p such that both p and p+2 are prime. He changes his staking withdrawal address to a smart contract where anyone can submit a claimed counterexample q > p, along with a SNARK proof that q and q+2 are both prime. If someone submits a valid claim, Bob's validator will be forcibly exited, and the submitter receives Bob's remaining ETH. Low risk.
- Dogecoin decides to switch to proof of stake and allows Ethereum holders to "double stake" to increase the size of its security pool, requiring Ethereum holders to change their staking withdrawal address to a smart contract where anyone can submit proof that they violated Dogecoin's staking rules. If such proof is submitted, the holder's validator will be forcibly exited, and their remaining ETH will be used to buy and burn DOGE. Low risk.
- eCash did the same as Dogecoin, but the project leaders further announced that if the majority of participating ETH validators colluded to censor eCash transactions, they expect the Ethereum community to hard fork to remove those validators. They believe that since these validators have been proven malicious and unreliable, Ethereum would be interested in doing so. High risk.
- Fred creates an ETH/USD price oracle that operates by allowing Ethereum validators to participate and vote without incentives. Low risk.
- George creates an ETH/USD price oracle that operates by allowing ETH holders to participate and vote. To prevent laziness and potential bribery, they add an incentive mechanism where participants who answer within 1% of the median answer receive 1% of the ETH from those who answer above the median by 1%. When asked, "What if someone credibly bribes all participants, and everyone starts submitting incorrect answers, resulting in honest people losing 10 million ETH?" George replied: Then Ethereum would have to strip the funds from the bad participants. High risk.
- George clearly avoids answering the medium-high risk (because the project might create incentives to attempt such a fork, so even without formal encouragement, there is a possibility of attempting a fork).
- George answers: "Then the attackers win, and we will abandon using this oracle." Medium-low risk (not entirely "low risk," just because the mechanism does create a large number of actors who might be incentivized to independently advocate for a fork to protect their deposits in a 51% attack).
- Hermione creates a successful layer two and claims that because her layer two is the largest, it is inherently the safest, as if an error leads to funds being stolen, the losses will be so great that the community will have no choice but to fork to restore users' funds. High risk.
If you are designing a protocol where, even if everything completely collapses, losses are limited to the validators and users who choose to participate and use your protocol, then this is low risk. On the other hand, if you intentionally introduce broader Ethereum ecosystem social consensus to solve your problems through forking or restructuring, then this is high risk, and I believe we should strongly resist all attempts to create such expectations.
The middle ground is a situation that starts in the low-risk category but incentivizes its participants to slide into the higher risk category; SchellingCoin-style technologies, particularly those with significant penalties for deviating from the majority, are a major example.
So, what’s the problem with over-utilizing (stretching) Ethereum consensus?
Suppose it is now 2025, and a frustrated group decides to create a new ETH/USD price oracle that determines the price by allowing validators to vote once an hour. If a validator votes, they will unconditionally receive a portion of the fees from the system as a reward. However, soon participants begin to become lazy: they connect to centralized APIs, and when these APIs are attacked, they either exit or start reporting incorrect values. To address this issue, they introduce an incentive mechanism: the oracle will also vote on the price from a week ago, and if your (real-time or retrospective) vote deviates from the median vote by more than 1%, you will be severely penalized, with the penalty going to those who voted "correctly."
Within a year, over 90% of validators participated. Someone asked: What if Lido colludes with several large stakers to launch a 51% attack on the voting, forcibly passing a false ETH/USD price value and extracting heavy penalties from all non-participating attackers? At this point, the oracle's supporters have deeply invested in this plan, and they respond: If that really happens, Ethereum will definitely fork to kick out the bad actors.
Initially, this plan was limited to ETH/USD and seemed very stable. However, over time, other indices were added: ETH/EUR, ETH/CNY, and finally the exchange rates of all G20 countries.
However, in 2034, things began to go wrong. Brazil experienced an unexpected severe political crisis that led to electoral disputes. One party controlled the capital and 75% of the territory, while another party controlled some northern regions. Major Western media believed that the northern party was clearly the legitimate winner due to its lawful actions, while the southern party's actions were deemed illegal (and they were fascists). However, official sources from India and China, as well as Elon Musk, believed that the southern party actually controlled most of the territory, and the international community should not try to act as the world's police but should accept this outcome.
At this point, Brazil already had a CBDC that split into two forks: (northern) BRL-N and (southern) BRL-S. When voting on the oracle, 60% of Ethereum stakers provided the ETH/BRL-S exchange rate. Most community leaders and businesses condemned the stakers' despicable capitulation to fascism and proposed a hard fork of the chain to include only the "good validators" who provided the ETH/BRL-N exchange rate, reducing the balances of other validators to near zero. In their social media bubbles, they believed they would clearly win. However, once the fork occurred, the strength of the BRL-S side was unexpectedly strong. Their anticipated overwhelming victory was, in fact, almost a 50-50 community split.
At this point, both sides existed in two separate universes, each with two chains, and were effectively unable to reunite. Ethereum, a global permissionless platform created partly to escape the influence of nation-states and geopolitics, was split in two due to unexpected severe internal issues in any one of the G20 member countries.
This is a great sci-fi story and could even make a good movie. But what can we actually learn from it?
The "purity" of blockchain, in the sense that it is a purely mathematical structure trying to reach consensus on purely mathematical things, is a huge advantage. As long as a blockchain tries to "hook" the external world, conflicts in the external world begin to affect the blockchain. If a sufficiently extreme political event occurs, in fact, considering that the above story is essentially a mimicry of events that have occurred in various major (>25 million population) countries over the past decade, even a currency oracle could tear the community apart.
Here are some possible scenarios:
The currency tracked by the oracle (even possibly the dollar) simply experiences hyperinflation, and the market collapses to a point where there is no clear market price.
If Ethereum adds a price oracle for another cryptocurrency, then a controversial split like the one in the above story is not hypothetical: it has already happened, including in the history of Bitcoin and Ethereum itself.
If strict capital controls are implemented, reporting which price between two currencies is the legitimate market price will become a political issue.
But more importantly, I believe there is a Schelling fence: once a blockchain begins to use real-world price indices as a layer of protocol features, it easily succumbs to interpreting more and more real-world information. Introducing a layer of price indices also expands the legal attack surface of the blockchain: it is no longer just a neutral technology platform; it more clearly becomes a financial instrument.
What about other risks besides price indices?
Any expansion of the "responsibilities" of Ethereum consensus increases the costs, complexity, and risks of running validators. Validators are required to expend human resources to pay attention to and run and update additional software to ensure they act correctly according to the other protocols introduced. Other communities gain the ability to externalize their dispute resolution needs to the Ethereum community. Validators and the entire Ethereum community are forced to make more decisions, each of which carries the risk of leading to community splits. Even without splits, the desire to avoid this pressure will create additional incentives to externalize decision-making to centralized entities through staking pools.
The possibility of splits also greatly enhances the bad too-big-to-fail mechanism. There are so many second-layer and application-layer projects on Ethereum that it is unrealistic for Ethereum social consensus to fork to solve all these problems. Therefore, larger projects will inevitably have a greater chance of receiving bailouts. This, in turn, will lead to larger projects obtaining moats: would you rather put your coins on Arbitrum or Optimism, where if something goes wrong, Ethereum will fork to save the day, or on Taiko, which is smaller (and non-Western, thus having fewer social connections in the core developer circle), where the likelihood of L1-supported rescue is lower?
But vulnerabilities are a risk, and we need better oracles. So what should we do?
I believe the best solutions to these issues are situational, as the various problems are inherently so different. Some solutions include:
Price Oracles: Either decentralized oracles that are not fully cryptoeconomic, or validator voting-based oracles that explicitly commit that their emergency recovery strategies are through means other than resorting to L1 consensus for recovery (or some combination of both). For example, price oracles could rely on a trust assumption that the corruption rate of voting participants is slow, so users would be warned of attacks in advance and could exit any systems relying on the oracle. Such oracles could deliberately delay rewards for a long time, so if the instance of the protocol stops being used (e.g., due to oracle failure and the community forking to another version), participants would not receive rewards.
More complex truth oracles about facts that are more subjective than price: A decentralized court system built on a non-fully cryptoeconomic DAO.
Layer 2 Protocols:
In the short term, relying on partial training wheels (referred to as phase one in this post).
In the medium term, relying on multiple proof systems. Trusted hardware (e.g., SGX) could be included here; I strongly oppose using systems like SGX as the sole guarantee of security, but as part of a 3-out-of-2 system, they could be valuable.
In the long term, hoping that complex features like "EVM verification" will eventually be incorporated into the protocol.
Cross-chain bridges: Similar logic to oracles, but also minimizing your reliance on bridges: holding assets on their source chains and using atomic swap protocols to transfer value between different chains.
Using the Ethereum validator set to protect other chains: One reason the (safer) Dogecoin method listed above may be insufficient is that while it does prevent 51% finality reversal attacks, it does not prevent 51% censorship attacks. However, if you are already relying on Ethereum validators, one possible direction is to stop trying to manage an independent chain and instead become an effective validation system anchored to Ethereum. If the chain makes such a change, its protection against finality reversal attacks will be as strong as Ethereum's, and it will be able to prevent up to 99% of censorship attacks (compared to the previous 49%).
Conclusion
The social consensus of the blockchain community is a fragile thing. Because of the need for upgrades, the existence of vulnerabilities, and the ever-present possibility of 51% attacks, social consensus is necessary, but because it carries such a high risk of leading to chain splits, we should use it cautiously in mature communities. There is a natural impulse to expand the core functionality of the blockchain, as the core has the greatest economic weight and the most community observers, but each such expansion makes the core itself more vulnerable.
We should be wary of application-layer projects taking actions that may increase the "scope" of blockchain consensus unless those actions validate the core Ethereum protocol rules. It is natural for application-layer projects to attempt such strategies, and such ideas often arise without an awareness of the risks, but the results can easily lead to significant inconsistencies with the overall goals of the community. Such processes without limiting principles may lead the blockchain community over time to increasingly possess "responsibilities," pushing it into an uncomfortable choice between facing high-risk splits each year and some form of bureaucratic control over the chain.
We should maintain the minimalism of the chain, support uses of re-staking that do not appear to be a slippery slope, and expand the role of Ethereum consensus while helping developers find other strategies to achieve their security goals.