3. Scourge — Stop centralization
Earlier this year, Peter Szilagyi, a leading Ethereum Developer, said, "Ethereum was losing the plot.” The research team was good at “centralizing everything as long as it could be verified.” “A cute charade — decentralized validation but centralized control.”
The whole point of scaling with L2s is retaining Ethereum’s decentralization, trustlessness, and security. If these qualities cannot be retained, then we might as well use TradFi's centralized systems. With “Scourge,” we discuss how to retain these core qualities.
2 main areas that risk Centralization:
1. Block Building
One would think that with the move from Proof-of-Work to Proof-of-Stake, building blocks would no longer be a technically sophisticated job since one does not need sophisticated equipment to solve complex math problems anymore. You simply stake ETH, and when it is your turn, you build a block by picking the maximum possible transactions from the mempool that earn you the highest amount in fees.
This has not proved to be true mainly because of the Maximal Extractable Value (MEV). In addition to fees, Validators can now also earn MEV. They do this by including, excluding, or reordering transactions in a manner that profits them. MEV enjoys high economies of scale. Someone with resources can spend on the best algorithms to maximize MEV. Unsophisticated entities like solo stakers don’t have access to such algorithms and hence earn less per block.
2. Staking Pools
If you want to contribute to securing the network but cannot stake yourself either because you lack the technical skills, are afraid of getting slashed, don’t have the minimum required 32ETH, or realize that you can’t compete with the larger players with their sophisticated algorithms, chances are that you’ll delegate your ETH to a staking pool.
But Staking Pools do more than just take on the sophisticated task of validating blocks for you. They also give you liquidity. If you were staking ETH yourself, you would have locked your capital. When you lock ETH with Staking Pools, you get a Staked Token (stETH, rETH, etc) that represents the ETH you’ve staked with them. You can continue to use this token for borrowing/ lending/ trading and sundry DeFi transactions.
Further, MEV, which has become an increasingly important component of staking revenues, is a volatile revenue source. A solo staker likely gets a chance to propose a block only once every four months, and if the MEV in that slot is insufficient, their economic model fails. Solo stakers spend 0.85% per year running nodes and cannot afford to have returns lower than that.
Given the advantages of using staking pools, there is a limited economic rationale for solo staking. But if everyone delegates to pools, these pools will become larger and more powerful, and the staking mechanism will become more centralized.
At the time of writing, 44% of all staking is being done through 3 players (Lido, Coinbase, and Binance).
How are we tackling the centralization of block building?
PBS: The first approach that has already been implemented is Proposer-Builder Separation (PBS). Here, builders do the technically sophisticated job of Block Building, including maximizing MEV. Builders then sell pre-built blocks to Proposers, who add the blocks to the chain. Block proposing remains decentralized, and block building becomes more centralized. Last month, 88% of blocks were built by two Builders, Titan and BeaverBuild.
ePBS: Today, 90% of blocks are built by an out-of-protocol solution called MEV-Boost. In addition to only 2 block builders building 88% of blocks, 99% of blocks relied on 6 relays operated by 5 entities. Relays are centralized entities that can censor blocks and are vulnerable to regulation. Ethereum is considering Enshrined PBS (ePBS), a version of PBS built into the consensus layer to tackle the centralization threat of relays.
Attester-Proposer Separation (APS): APS is a slightly modified approach. In PBS, validators propose the blocks, but in APS, builders do both building and proposing. The advantage of APS is that proposers don’t have to co-locate with builders.
This, however, could make builders even more powerful, and powerful builders can censor transactions. In a situation where block building is 90% centralized, if your transaction is not time-sensitive, it won't bother you if it takes a few minutes to go through. But if your transactions are time-sensitive, like when you’re at risk of liquidation, this is a real problem.
Inclusion Lists: One way to counter censorship is through inclusion lists. Proposers create a list of transactions that builders must include in their blocks. Builders can change the order of transactions and include additional transactions, but they cannot censor transactions that are already on the inclusion list.
Fork-Choice Enforced Inclusion Lists (FOCIL): A further protection to remove the possibility of collusion between proposers and builders is that the task of creating inclusion lists is divided among multiple inclusion list creators.
Unconditional Inclusion Lists: What if an auction winner of multiple back-to-back slots gets around inclusion lists by simply not publishing blocks in slots except the last one they control in order to earn multi-block MEV? The solution could be unconditional inclusion lists. These automatically become the block if the Builder does not provide one.
Multiple Concurrent Proposers (MCP): Yet another option being considered is MCP, in which instead of separating the building and proposing duties, total block production is divided among several actors. Each actor will need to have a moderate level of sophistication. They wouldn’t need to have as high a level of sophistication as builders, nor can they be a “dumb pipe.” Multiple proposers generate lists of transactions that are ordered using a pre-determined algorithm.
Encrypted Mempools
Many of the above, particularly MCP and APS, require Encrypted Mempools, which allow users to send transactions in encrypted form without sharing the contents with the block builder. The transaction details are decrypted later.
The problem currently being faced is that users need to reveal the information at the right time. Revealing information as late as possible could give one an advantage. Not revealing the information would be an even bigger issue. Some form of automatic decryption, such as “Threshold Decryption” or “Delay Decryption,” could be the solution.
How are we tackling the centralization of staking pools?
We might be headed in a direction where every ETH holder stakes their ETH and stakes it in exchange for the same Liquid Staking Token (LST). In that case, given that everyone will be slashed equally in case of bad behavior, everyone’s relative position will be the same, and we’d be needlessly issuing ~1mn odd tokens every year.
So, if everyone staking with LSTs is inevitable, then why not decentralize liquid staking?
To make this happen, we’d need to reduce penalties.
* One approach is to cap slashing to 1/8, leaving 7/8 as non-slashable.
* Another is to have 2 tiers of staking; one earns higher returns and is slashable, and the other earns lower returns and is unslashable.
Pricing the risk-bearing stake is complicated, given that the protocol has no idea how much money is being made through MEV. In PBS, MEV is captured in the amount builders pay proposers. In 2-tier staking, the risk-bearing stakers will earn MEV in addition to the fixed rate set by the protocol.
Additional ways to encourage solo staking
In addition to decentralizing liquid staking, there are several out-of-protocol attempts to encourage solo staking:
- Hardware: Develop hardware that makes staking easier. The hardware could also earn its owners additional revenue, for example, by running nodes for a decentralized VPN.
- Squad Staking: As long as at least M of N nodes of a squad are online, the squad will not get slashed. This reduces the penalty for stakers with, say, unreliable energy sources.
- Airdrops: Preferential Airdrops to solo stakers would improve their economics
- Retain MEV at App Layer: Apps could keep MEV to themselves rather than let it leak to L1 by, say, putting all ops in a queue, executing them in the next block, and auctioning off the right to jump the queue.
The full series available in below links:
1. Merge — Improving on Proof-of-Stake
2. Surge — How will Ethereum scale?
3. Scourge — Stop centralization
4. Verge — Verification should be so easy; your smartwatch should be able to do it
