By Hank Han, Research Fellow at Mint Ventures
1. Introduction
Ethereum staking and its related derivative tracks are undoubtedly the hottest topics in the past one or two years. From Beacon Chain to The Merge to Shanghai Shangji, from LST to DVT to Restaking and LSTfi, we have witnessed the rise and rapid development of staking and related tracks. Looking at the driving factors behind it, it is not difficult to find that its development originated from the paradigm change of Ethereum staking. Therefore, we should also think about how the Ethereum staking paradigm will evolve in the long run and how it will affect related tracks and major players.
In his article <Protocol and staking pool changes that could improve decentralization and reduce consensus overhead> published on October 7, Vitalik proposed some solutions to optimize the current Ethereum staking mechanism, providing a reference path for Ethereum to further reduce centralization and reduce consensus load. Some of these ideas will have a significant impact on the staking mechanism, while also being in line with the main trend of Ethereum development, so we will interpret the article and analyze the potential impact of different solutions on the staking track.
2. Article Review
2.1 Current Status of Dual-Layer Staking
Vitalik calls Ethereum’s current staking structure two-tiered staking, in which there are two layers of participants: Node operators and Delegators.
Node operators: Node operators are responsible for operating Ethereum nodes.
Delegators: Delegators are users who participate in staking in various ways (except running their own nodes).
Currently, the main way for delegators to participate in staking is to use services provided by staking service providers such as Lido and Rocket Pool.
2.2 Problems
Vitalik believes that the two-tier staking model brings two problems, namely the centralization risk of the staking track and unnecessary consensus layer burden.
Centralization risk in the staking track: After delegators stake ETH, they need service providers such as Lido to select nodes. The specific selection mechanism will bring centralization risks to node operators from different angles. For example, Lido decides operators through DAO voting, so node operators may tend to hold a large amount of LDO to increase their market share; Rocket Pool allows anyone to stake 8 ETH to become a node operator, which allows operators with strong financial strength to directly "purchase" market share.
Unnecessary consensus layer burden: Currently, the Ethereum consensus layer needs to aggregate and verify about 800,000 signatures in each epoch. If the goal of Single Slot Finality (SSF) is to be achieved, Ethereum will need to aggregate and verify 800,000 signatures in each slot, that is, the task remains unchanged, and the time is shortened to 1/32 of the original. This puts higher requirements on the hardware running the node. From the current two-layer staking structure, the verification work is mostly carried out by node operators. Although there are many validators, the actual entities running validators are not diverse. In other words, the increase in the number of nodes has not reduced the degree of centralization of Ethereum, but has increased the consensus burden of Ethereum. Therefore, the number of verification nodes can be reduced (reducing the number of signatures that need to be processed), thereby reducing the consensus load of Ethereum (sounds more centralized, and the supporting measures to reduce centralization will be explained in the following section).
Additional background knowledge:
Slot: refers to the time required for a new block to be included in the consensus. A slot in Ethereum is about 12s. In each slot, the network randomly selects a validator as the block proposer, who is responsible for creating new blocks and sending them to other nodes on the network. In addition, in each slot, a committee of validators is randomly selected to determine the validity of the proposed block through their votes. That is, not all validators need to participate in the verification of a certain slot. Only the validators of the selected committee need to participate normally. 2/3 of the votes of the committee can make the status of the slot valid. Not all validators are required to participate in each slot, which can facilitate the management of network load.
Epoch: refers to a time period of 32 slots. An epoch in Ethereum is about 6.4 minutes. In an epoch, a validator can only join one committee, and all active validators in the network need to provide proof to show their "active" status in this epoch. The first slot of each epoch (normally) is also called a checkpoint.
Finality: A transaction is “final” in a distributed network when it becomes part of a block and cannot be changed without burning a large amount of ETH to roll back the blockchain. Ethereum manages finality through “checkpoint” blocks. If a pair of checkpoints (the first slots of adjacent epochs) receive more than 2/3 of the total staked ETH, then the pair of checkpoints will be upgraded. The newer of the two checkpoints becomes “reasonable” and the older checkpoint is upgraded from the reasonable state obtained in the previous epoch to the “finalized” state. On average, user transactions will be in a block in the middle of an epoch, and half an epoch away from the next checkpoint, indicating that the transaction is finalized in 2.5 epochs, about 16 minutes (0.5 epochs to reach the next checkpoint; 1 epoch after that, the next checkpoint gets reasonable; 1 epoch after that, the next checkpoint gets finalized). Ideally, the 22nd slot of an epoch will achieve the plausibility of the epoch checkpoint. Therefore, transaction finalization takes an average of 14 minutes (16+32+22 slots).
Single Slot Finality (SSF): Finality is achieved immediately after each slot produces a block. Currently, the time required for Ethereum to finalize a block is too long. Most users do not want to wait about 15 minutes to finalize a transaction, and it restricts the development of applications that want to achieve high transaction throughput. In addition, the delay between block proposal and finalization also creates opportunities for short-term reorganization, which attackers can use to censor certain blocks or extract MEV. The mechanism for handling phased upgrade blocks is also quite complex and is one of the parts of the Ethereum codebase that is more prone to subtle vulnerabilities. These problems can be solved by shortening the finalization time to one slot. SSF is in The Merge branch in the Ethereum roadmap (reference: https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1) and is one of Ethereum's long-term goals. However, Ethereum officials do not expect SSF to be launched within a few years, and it requires major upgrades such as Verkle Trees and Danksharding as preparatory work.
2.3 Solution
Vitalik pointed out that the current delegators are not playing their due role, and believed that the above two problems can be solved by giving delegators more rights and obligations. The two main directions to solve the problem are Expanding delegate selection powers and Consensus participation.
2.3.1 Expanding delegate selection powers
Expanding delegate selection powers means expanding the options of delegators, giving them a more active role in choosing staking service providers and node operators. Currently, this approach actually partially exists, because delegators holding stETH or rETH can withdraw funds directly and then stake them in other staking pools, but there are many limitations, such as not being able to directly choose operators and not being flexible enough in withdrawing funds.
Vitalik mentions three ways to expand the options available to delegators:
Better voting tools within pools: optimize voting within the staking pool, allowing users within the pool to choose their own node operators, but this method does not actually exist at present. Rocket pool allows any staker to become a node operator; while Lido's node operators are determined by LDO holders, although Lido has proposed a dual-layer governance model of LDO + stETH (proposal link: https://research.lido.fi/t/ldo-steth-dual-governance/2382).
More competition between pools: that is, to increase the degree of competition between staking pools, so that delegators have more choices. But in fact, the LST of the long-tail staking pool is at a disadvantage in terms of liquidity, trustworthiness and dapp acceptance. It cannot compete with leading projects such as Lido, so delegators have no choice. Vitalik believes that the three problems of liquidity, trustworthiness and dapp acceptance can be solved through a series of measures, such as reducing the amount of slash fines to reduce the slash risk faced by delegators, making it possible for users to withdraw staked ETH at any time, thereby solving the problems of LST liquidity and lack of trust; at the same time, a unified LST token standard can be introduced, so that all LST of staking pools can be issued through a unified contract to ensure the compatibility and security of LST with different dapps.
About slash:
What is slashing: Ethereum consensus requires certain incentive mechanisms for validators to perform actively. Validators need to stake a certain amount of ETH in advance to participate in Ethereum consensus. If the validator behaves improperly, the staked ETH may be destroyed (slashed). There are two main behaviors that are considered dishonest: proposing multiple blocks in one slot (ambiguity) and submitting contradictory votes.
Why reducing the amount of slashing can reduce the risk faced by delegators: In the current two-tier staking structure, delegators only provide the staked ETH, and the behavior of the validator is actually the behavior of the node operator. Therefore, when the operator does evil, the delegators will be punished on their behalf. Projects such as Rocket Pool require node operators to contribute a certain amount of staked ETH to reduce the agency problem. If the amount of ETH that can be slashed is reduced to a level that can be covered by the share of node operators at the Ethereum level, then delegators can eliminate the slashing risk, and the staking service provider can allow delegators to withdraw funds at any time without having to reserve a certain amount of liquidity.
Enshrined delegation: Ethereum natively integrates the above delegation functions, such as requiring delegators to select node operators when participating in staking at the Ethereum protocol level, etc.
2.3.2 Consensus participation
Consensus participation means allowing delegators to participate in Ethereum consensus in a lighter way without bringing additional burden to Ethereum consensus. Vitalik admitted that many delegators do not want to do this, they just want to hold LSTs in the simplest way, but he also believes that there will be delegators who will take the initiative to participate in consensus. Vitalik provides two implementation solutions: Ethereum native integration and third-party project integration, which will be discussed one by one below.
2.3.2.1 Ethereum Native Integration
At the Ethereum protocol level, validators are first divided into two categories: complex validators (higher-complexity slashable tier) and simple validators (lower-complexity tier), each of which undertakes different tasks to ensure the performance and decentralization of Ethereum.
Complex validators: They undertake the main verification and calculation work of Ethereum and need to stay online at all times. The amount of ETH staked by each complex validator will be increased to 2048 ETH (the example given by Vitalik), and they will be subject to the risk of slashing. The number of complex validators in the entire network is limited to 10,000.
Simple validator: no quota limit, no staking threshold, immune to slashing, and only needs to participate in consensus in some slots.
Sources of simple validators: Delegators who participate in staking through staking service providers and provide ETH for complex validators; and users in the network who want to become simple validators independently. (Note: Vitalik used small-stakers to refer to simple validators in the original text, and the following text will use small stakers and simple validators interchangeably)
Several possible working modes of simple verifier
For each slot, 10,000 simple validators are randomly selected to vote for the state they approve of.
A delegator can send a transaction to declare that it is online and willing to become a simple validator in the next hour to vote for the block headers they agree with, and needs to sign off after the work is completed.
A delegator can send a transaction to declare that it is online and willing to become a simple validator in the next hour. Every epoch, 10 random delegators will be selected to form the block recommendation list, and more than 10,000 delegators will be selected to become voters. These simple validators do not need to sign out, and the online requirement expires over time.
The characteristics of the above three solutions are: all are to prevent 51% attacks by node operators and improve Ethereum's anti-censorship. The first and second solutions mainly prevent the finality from being reversed; the third solution focuses more on the network's anti-censorship, and simple validators need to do more work.
The premise of lightweight participation: there is an ultra-light client for simple verifiers to use, so that they can complete the verification work through mobile phones or web pages; this involves relevant research on the lightweight Ethereum client (such as introducing Verkle Tree, statelessness, etc.), aiming to lower the threshold for participation of verifiers.
Source: https://notes.ethereum.org/@vbuterin/staking_2023_10
2.3.2.2 Third-party project integration
Third-party project integration refers to the participation of delegators in Ethereum consensus mainly through the upgrade of the staking pool itself. The core idea is to introduce the joint signature of delegators and validators in the consensus voting process to reflect the wishes of the delegators group. The following are three solutions proposed by Vitalik:
When opening a validator account, the staking pool declares two staking keys, P (persistent staking key) and Q (quick staking key, which is actually the output result when an Ethereum address is called). The node tracks the signatures of P and Q on the message selected by a fork. If P and Q's selections are the same, the verification succeeds; if they are different, the verification fails. The staking pool is responsible for randomly selecting delegators as the Q-key holders of the current slot.
The validator randomly generates a staking public key P + Q in each slot, and the voting signature of each slot requires joint calculation by the validator and the delegaotrs. Since each slot randomly generates a different key, there is a related attribution problem when a slash occurs, and certain designs need to be made for this problem.
Put Q into smart contracts instead of using it as a key directly held by delegators. Q managed by smart contracts can introduce diverse trigger conditions, thus bringing richer voting logic to the staking pool.
2.3.3 Summary
Vitalik believes that if the above solution is adopted properly, the adjustment of the proof-of-stake design can achieve two birds with one stone (reduce the degree of staking centralization and reduce the Ethereum consensus load):
Providing an opportunity for those who currently do not have the resources or ability to participate in PoS to participate, giving them more power (including the power to choose the nodes they support) and participating in a more lightweight but still meaningful way. At the same time, Vitalik also pointed out that not all participants will choose these two or one of the options, but any selected solution can improve the status quo.
Reduce the number of signatures that the Ethereum consensus layer needs to process per slot, even with single-slot finality, to around 10,000. This helps decentralization and makes it easier for everyone to run a validator node.
The above solutions, including optimizing intra-pool elections, strengthening inter-pool competition, and native Ethereum integration, are at different levels of abstraction, but their goal is to solve the current problems of Ethereum staking centralization and consensus load. Vitalik believes that specific implementation plans should be carefully considered before being adopted, and the optimal solution should be able to achieve the desired goal while minimizing protocol changes.
3. Analysis of the impact on pledge-related tracks
3.1 Overview of staking-related tracks
Referring to @StakingRewards’s division of the Ethereum staking ecosystem, it can be divided into the validator layer, staking layer, bridge layer, DeFi infrastructure layer, and the top structured product layer from the bottom up. The internal logical relationship and their respective values can be summarized as follows:
Validator layer: represented by node operators such as P2P and Stakefish, providing the lowest-level hardware resources for the staking layer or solo staking customers. This also includes service providers SSV and Obol that provide DVT technology. The validator layer solves hardware-related problems for the staking layer.
Staking layer: Staking service providers such as Lido and Rocket Pool receive funds from delegators and connect with node operators on behalf of delegators to conduct consensus verification of Ethereum, including EigenLayer, which proposed the concept of restaking. The staking layer encapsulates the indirect participation of delegators in PoS into financial products, lowering the threshold for participation and introducing more staking shares to Ethereum.
Bridge layer: This refers to the LST (Liquid Staking Token) issued by the staking layer. Users participate in various DeFi protocols through LST; staking service providers add LST-ETH trading pairs in protocols such as Curve to provide delegators with liquidity to exit staking early, thereby reducing the opportunity cost of delegators participating in staking.
DeFi infrastructure and structured product layer: Use LST's value storage and profitability to develop derivative products and services, create more application scenarios for LST, enrich the DeFi ecosystem, and attract users to pledge.
Source: https://twitter.com/StakingRewards/status/1711409661734219886/photo/1
In the staking ecosystem, the staking layer plays a core role in connecting the upper and lower levels: introducing more staking shares to Ethereum and delivering liquidity to the DeFi system through LST. The core position of the staking layer enables its own changes to cause changes in the entire staking ecosystem, so we will focus on analyzing the impact of related plans on staking layer projects. The staking track in this article will mainly refer to the staking layer.
3.2 Potential impact of the above scheme on the pledge track
The above solutions have different implementation angles, but they will all have an impact on the staking track. We will analyze the impact of different solutions below and infer the feasibility of the corresponding solutions being adopted.
3.2.1 Expanding delegate selection powers
The following briefly analyzes the potential impact of the three options mentioned by Vitalik for expanding delegators’ options.
Better voting tools within pools: This means optimizing voting within staking pools, allowing users within the pool to choose their own node operators.
Potential impact: It can make the staking service providers themselves more decentralized, but it cannot reduce the concentration of the staking track because users can trust the top staking service providers more; the operator selection rights originally controlled by the staking service providers have been partially transferred to delegators, which may reduce the value capture of the original governance tokens.
Adoption possibility analysis
The overall cost is low: no changes are required to the Ethereum consensus layer, only the staking service provider needs to change its own mechanism.
Existing staking service providers lack incentives: This solution requires existing staking service providers to actively change and bear greater costs, including development costs and the cost of reduced utility of governance tokens.
Summary: It partially solves the problem of staking centralization, but cannot solve the problem of consensus load, and the final effect may be average. The implementation cost is low, but the existing staking service providers have no motivation to do it, and the possibility of adoption is small. There may be new staking service providers using this feature to enter the market.
More competition between pools: that is, to strengthen competition between staking pools and provide delegators with more choices. At present, the core differences between different staking pools in attracting users are the liquidity, trustworthiness and dapp acceptance of LST. Vitalik proposed to reduce the amount of slash and introduce a unified LST standard to reduce the above three differences and strengthen the competition between staking service providers.
Potential impact: The differences among staking service providers will decrease, and the market share of leading projects such as Lido will decline, reducing the centralization of the staking track; the LSTfi ecosystem may become more prosperous because the corresponding dapp can support more LST in the staking pool; staking service providers will seek differentiation in other aspects, and the direction of competition may shift to the staking income of LST itself, especially in the MEV extraction strategy.
Adoption possibility analysis
The overall cost is medium: The technical cost is low because the solution does not require changes to the Ethereum consensus layer. It only requires the introduction of a new LST token standard and the staking service provider to cooperate in reducing the user's slash share and adopting the new LST standard. However, in the process of adoption, a large number of existing LST holders are required to exchange their LST for the new unified standard LST, so there is a large migration cost.
Existing staking service providers lack incentives: This solution requires existing staking service providers to make certain proactive changes, bear certain upgrade and development costs, and have a large amount of LST conversion costs and risks. The adoption of this solution also puts existing service providers under pressure to reduce their market share.
Summary: The problem of staking centralization has been solved to a large extent, but the problem of consensus load cannot be solved, and the problem is not completely solved. The overall implementation cost is medium, but existing staking service providers have no motivation to do it, and the possibility of adoption is small. There may be new staking service providers using this feature to enter the market.
Enshrined delegation: Incorporate the above-mentioned delegation functions directly into the Ethereum protocol layer, such as users directly selecting node operators and Ethereum launching its own LST token standard.
Potential impact: The same impact as the above inter-pool competition scheme, but the support of the Ethereum protocol layer will ensure the security of the corresponding transformation to a certain extent. It may add burden to the Ethereum consensus, because users participating in delegation at the Ethereum protocol layer will bring more verification work to the Ethereum consensus.
Adoption feasibility analysis
The overall cost is high: the Ethereum consensus layer needs to be upgraded to natively support the relevant delegation functions.
This may go against the original intention of the upgrade: it increases the consensus burden of Ethereum; the way delegators directly select node operators for hosting at the protocol level is closer to DPoS in nature, which may be a result that Vitalik does not want to see.
Summary: This solves the problem of staking centralization to a large extent, but it will aggravate the problem of consensus load. At the same time, the cost of upgrading is high and certain changes need to be made to Ethereum. The possibility of adoption is extremely small.
3.2.2 Consensus participation
The basic idea of Consensus participation is to allow more simple validators to participate in consensus. The difference between the two solutions lies in whether it is implemented through Ethereum native integration or within a third-party project.
3.2.2.1 Native Integration
According to Vitalik's idea, the native integration solution of Ethereum will directly divide the network into two groups: complex validators and simple validators. The staking threshold for complex validators will be raised to 2048 ETH, and the number of validators will be limited to 10,000. They need to stay online in real time and be responsible for the main verification and calculation work; while simple validators only need to use their own devices to run lightweight clients, participate in consensus at specific times, and only undertake lightweight work such as voting.
Note: 2048 ETH is an example given by Vitalik in the original article, but it is likely to become the number adopted in subsequent plans. Combined with Vitalik's explanation in the article <Paths toward single-slot finality> and EIP-7251 cited by Vitalik in the original article, we can know that this data has practical significance: 2048 ETH can limit the number of validators in equilibrium to an ideal level, reduce the consensus burden of Ethereum, and pave the way for the realization of SSF. At the same time, in <Protocol and staking pool changes that could improve decentralization and reduce consensus overhead>, Vitalik proposed a practical approach: Ethereum can first integrate EIP-7251 as a transition, that is, increase the upper limit of the validator balance to 2048 ETH, while retaining the lower limit of 32 ETH; then use 2048 ETH as the overall staking limit to allow validators to choose the tier by themselves. In summary, it can be seen that using the number 2048 ETH for analysis in the following analysis is of great reference value.
Source: https://notes.ethereum.org/@vbuterin/single_slot_finality
Potential impact
It can solve the problems of staking centralization and Ethereum consensus load at the same time: native integration allows delegators and other ordinary users to participate in consensus in a simple and low-cost way, greatly improving the decentralization of the Ethereum network; at the same time, the limit of 10,000 complex validators reduces the difficulty of consensus and the size of aggregate signatures for each slot, reducing the consensus burden of Ethereum.
The value of staking service providers' services and security technologies such as DVT will increase, and the penetration rate will be further improved: a single complex validator needs to perform more active network verification and ensure a very high online rate, so the threshold for related hardware operation and maintenance is increased, and the value of security technologies such as DVT is further highlighted; the staking threshold of 2048 ETH makes most users who could originally stake solo turn to delegators; based on the above, the penetration rate of staking service providers and technical service providers such as DVT will increase.
The market size of the staking track will reach a ceiling: In Vitalik's vision, the way for simple validators to participate in consensus is to run ultra-light nodes by themselves. The staked ETH from the delegators will not create more TVL for the staking service providers, and other users who become simple validators do not need to become delegators through the staking service providers, because they themselves need to run ultra-light nodes, and there is no need to host them to the staking service providers and pay the corresponding hosting fees. Therefore, the TVL that the staking service providers can capture will usher in a cap of 20.48 million ETH.
The long-term growth of staking service providers and related projects may stagnate
There is still room in the short and medium term, but the momentum is insufficient: judging from the current market size, the total supply of ETH has stabilized at around 120 million after EIP-1559 and Merge, with approximately 28 million Ethereums participating in staking and a staking rate of approximately 23.29%. The staking track still has some room for improvement; but judging from the queues of validators entering and exiting, the growth of ETH staking has reached a bottleneck as the staking income decreases. If there is no substantial increase in MEV income due to the increase in on-chain transaction volume, the number of stakes will be in a stable equilibrium state, and there will be a lack of momentum for growth.
The growth of staking service providers, DVT and other technical projects will stagnate in the long run: from staking service providers represented by Lido to DVT projects represented by SSV, their revenue model is to charge a certain percentage of the staking income of this part of funds. When the capital limit of delegators is 20.48 million ETH, this part of the funds will be less than the current 28 million. If the future MEV income does not increase enough (which means that the staking rate is not increased enough), the absolute income scale of the staking track will not increase but decrease, and there will be no source of growth in the long run.
Source: https://etherscan.io/chart/ethersupplygrowth
Source: https://www.validatorqueue.com/
Adoption possibility analysis
The overall cost is huge: Ethereum’s consensus participation rules need to be changed.
In line with the long-term development interests of Ethereum, a layered architecture for validators may be introduced in the long term.
One of Ethereum's long-term development goals is to introduce a similar validator hierarchical architecture: Vitalik pointed out in <Endgame> that as blocks become larger (state bloat problem), only a few hundred large nodes will have the conditions to run full nodes in the future. Ethereum needs to find another lightweight way to allow more people to participate in consensus and ensure acceptable trustlessness and censorship resistance. At the same time, in order to achieve features such as single-slot determinism (SSF) that improve Ethereum's performance and security, two types of validators are also needed to work together. The two types of validators have different responsibilities, and it is more reasonable to apply different staking rules (layering).
The validator hierarchical structure has appeared many times in the Ethereum roadmap and related articles, and there are a large number of lightweight client-related schemes under planning and research, aiming to create conditions for simple validators to participate in consensus.
From important upgrades such as PBS and Danksharding, we can see similar ideas of layering and division of labor: let professional nodes take on heavier tasks (such as storing blobs and building blocks) to ensure efficiency; let more lightweight nodes participate in consensus to ensure decentralization.
From the main idea of <Endgame>, we can see that the SNARKization (lightweight) of verification is to provide a reference method for simple verifiers to participate in consensus. In the Ethereum roadmap, we can also see that related research including stateless and The Verge are all preparing for users to run ultra-light nodes.
<Vitalik: Endgame>, source: https://vitalik.ca/general/2021/12/06/endgame.html
The Verge related content, source: https://twitter.com/VitalikButerin/status/1588669782471368704
Summary: It can solve the problems of staking centralization and consensus load at the same time. The cost of adoption is extremely high, and it requires changing the PoS rules at the Ethereum consensus layer, but it is in the long-term development interests of Ethereum, and the relevant preparations have been partially reflected in the Ethereum roadmap. It may be adopted in the longer term, but it is unlikely to be realized in the short term.
3.2.2.2 Third-party project integration
Vitalik also proposed a solution that can be implemented only through staking pools, without the need for native support from Ethereum. The core of this solution is to split the validator private key into two keys, P and Q, and give them to the validator node and the user respectively, and let the user participate in the consensus through the joint signature of P and Q.
Potential impact: It can solve the problem of staking service centralization to a certain extent, but the effect is uncertain because the user participation process is relatively complicated and the willingness to participate may be small. This plan is more of an internal adjustment of the staking service provider and has little impact on the track pattern.
Adoption feasibility analysis
Medium implementation cost: No major changes are required to the Ethereum consensus layer, but existing staking service providers will need to make more complex upgrades, including key splitting, custody, and joint signature design, while also attracting users to participate in simple consensus verification.
The costs borne by staking service providers are increasing, and existing projects may not be incentivized to upgrade: first, the splitting and safekeeping of validator private keys, and second, the design of user UX, will bring certain upgrade costs to existing staking service providers, but it is difficult to bring higher profits to existing service providers.
As the verification logic becomes more complicated, it may increase the workload of Ethereum: more complex verification logic includes comparing messages signed by P and Q, etc.
Summary: It can solve the problem of staking service centralization to a certain extent, but the effect is uncertain and has little impact on the pattern of track projects. Existing projects are unlikely to adopt it, but new staking service providers may use this feature to enter the market.
3.3 Summary
Vitalik did not explicitly express his preference for a particular solution in the article, but we can still infer what might happen by analyzing the effects and impacts of the solution and combining information such as Vitalik’s previous articles and the Ethereum roadmap.
Three options for the direction of Expanding delegate selection powers
Incomplete solution: The solution related to Expanding delegate selection powers is mainly aimed at optimizing the problem of staking centralization, but the solution effect is uncertain. Because the current two-layer staking structure around delegators-staking pools is essentially close to DPoS, and the solution for Expanding delegate selection powers does not break the existing structure, and may even highlight the characteristics of DPoS. At the same time, the solution does not solve the problem of Ethereum consensus load, and the solution of natively integrating delegation may even add a burden to Ethereum consensus.
Existing parties have little incentive to adopt: Plans in this direction will harm the interests of existing staking service providers. At the same time, plans to optimize intra-pool elections and strengthen inter-pool competition also require the support of staking service providers. Therefore, existing staking service providers have little incentive to adopt related plans.
In the short term, it may be adopted by new projects: new staking service providers may emerge and use this as a more decentralized feature to enter the market and compete with existing projects.
For the consensus participation direction
Native support may be a long-term solution: Native support can solve both the staking centralization and Ethereum consensus load problems mentioned by Vitalik. At the same time, preparations are underway to implement a similar hierarchical validator architecture. It is difficult to achieve in the short term, but very likely to happen in the long term.
Compared with Expanding delegate selection powers, third-party integration solutions can solve the problem of staking centralization to a greater extent, but they cannot solve the problem of consensus load. Similar to Expanding delegate selection powers, there is also the problem of low incentives for existing adopters. In the short term, new staking service providers may use this feature to enter the market.
4. Conclusion
In many of Vitalik's speeches and articles, we can see a core idea: Ethereum should remain neutral and minimalist. Although many features (such as account abstraction, liquidity staking services, privacy accounts, etc.) have improved Ethereum's competitiveness, Ethereum did not choose to directly integrate all features, but left some functions to third-party projects to build. Many third-party projects have also answered the propositions left by Ethereum and found their own market positioning. However, as Ethereum itself continues to evolve, the problems and opportunities faced by third-party projects are also changing. For these participants, this is not only a test of adaptability, but also a time to think deeply about the future, foresee and seize the final opportunity.
In this article, we try to make a comprehensive deduction of the variables that the current staking track-related projects may face in the future based on Vitalik's assumptions. Although Vitalik has planned the possible end of Ethereum in the relevant article, the future is still full of uncertainty, because the current plan may change with new market demands and technological advances. In this ever-changing scenario, only players with end-game thinking and the ability to capture the current window bonus can stay ahead in the long-term competition.
References
<Protocol and staking pool changes that could improve decentralization and reduce consensus overhead>
<Should Ethereum be okay with enshrining more things in the protocol?>
<Paths toward single-slot finality>
Etheream Roadmap: Single slot finality
<A Proof of Stake overview>
<Can we find Goldilocks? Musings on “two-tiered” staking, a native Liquid Staking Token design.>
<Endgame>
<The Beacon Chain Ethereum 2.0 explainer you need to read first>
FAQ on EIP-7251; Increasing the MAX_EFFECTIVE_BALANCE – HackMD