1. Introduction
Ethereum staking and its related derivatives are undoubtedly the hottest topics in the past year or two. From Beacon Chain to The Merge to Shanghai Advanced, from LST to DVT to Restaking and LSTfi, we have witnessed the rise and rapid development of staking and related tracks. Investigating 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 Ethereum’s staking paradigm will evolve in the long term, and how it will affect related tracks and major players.
Vitalik published on October 7th titledThe article proposed some plans to optimize the current Ethereum pledge mechanism, providing a reference path for Ethereum to further reduce the degree of centralization and reduce the consensus load. Some of these ideas will bring about major changes to the staking mechanism and are in line with the main trends of Ethereum development. Therefore, 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 double-layer pledge
Vitalik calls Ethereum’s current staking pattern two-tiered staking. In this staking model, there are two layers of participants: Node operators and Delegators.
Node operators: Node operators are responsible for operating Ethereum nodes.
Delegators: Delegators, users who participate in staking in various ways (except running nodes themselves).
Currently, the main way for delegators to participate in staking is to use the services provided by staking service providers such as Lido and Rocket Pool.
2.2 Problems
Vitalik believes that the double-layer pledge model has brought about two problems, namely the centralization risk of the pledge track and unnecessary burden on the consensus layer.
Centralization risk of the staking track: After delegators pledge ETH, they need service providers such as Lido to select nodes. The specific selection mechanism will bring about the centralization risk of node operators from different angles. For example, if Lido determines operators through DAO voting, node operators may be inclined to hold a large amount of LDO to increase their market share; Rocket Pool allows anyone to become a node operator after pledging 8 ETH, which allows companies with strong financial strength to Operators are able to buy market share directly.
Unnecessary burden on the consensus layer: 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 One slot aggregates and verifies 800,000 signatures, that is, the task remains unchanged, and the time is shortened to 1/32 of the original, which puts higher requirements on the hardware of the running node. Judging from the current two-tier staking structure, most of the verification work is performed by node operators. Although the number of verifiers is large, the subjects who actually run the verifiers are not diverse. In other words, the increase in the number of nodes has not reduced the centralization of Ethereum, but has increased the consensus burden on Ethereum. Therefore, the number of verification nodes can be reduced (reduce the number of signatures that need to be processed), thereby reducing the consensus load of Ethereum (it sounds more centralized, and the supporting measures to reduce centralization will be explained in the following section).
Additional background knowledge:
Slot (time slot): refers to the time required for a new block to be included in the consensus. A slot in Ethereum is about 12 seconds. 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 and their votes determine the validity of the proposed block. That is, all validators do not need to participate in the verification work of a certain slot. Only the validators of the selected committee can participate normally. 2/3 of the votes of the committee can make the status of the slot valid. Each slot does not require all validators to participate, which makes it easier to manage network load.
Epoch (period): refers to a time period containing 32 slots. An epoch in Ethereum is approximately 6.4 minutes. In an epoch, a validator can only join one committee, and all active validators in the network need to show proof to show their active status in this epoch. The first slot of each epoch (normally) is also called a checkpoint.
Finality: The finality of a transaction in a distributed network means that the transaction becomes part of the block and cannot be changed unless a large amount of ETH is destroyed causing the blockchain to be rolled back. Ethereum manages finality through “checkpoint” blocks. If a pair of checkpoints (the first slot of adjacent epochs) receives more than 2/3 of the votes from the total number of staked ETH, then the pair of checkpoints will be upgraded. The newer of the two checkpoints will become the reasonable state, and the older checkpoint will be upgraded to the final state from the reasonable state obtained in the last epoch. On average, user transactions will be in a block in the middle of an epoch, half an epoch away from the next checkpoint, indicating that transactions are finalized in 2.5 epochs, about 16 minutes (after 0.5 epochs, the next checkpoint is reached point; after another epoch, the next checkpoint will obtain a reasonable state; after another epoch, the next checkpoint will obtain the final state). Ideally, the 22nd slot of an epoch will achieve the reasonableness of the epoch checkpoint. Therefore, the average transaction finalization time is 14 minutes (16+ 32+ 22 slots).
Single Slot Finality (SSF, single slot finality): Finality is achieved immediately after each slot produces a block. The current time it takes for Ethereum to finalize blocks is too long. Most users do not want to wait about 15 minutes to finalize transactions, 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 reorganizations, which can be exploited by attackers to censor certain blocks or conduct MEV extraction. The mechanism for handling staged upgrade blocks is also quite complex and is one of the more vulnerable parts of the Ethereum codebase to minor bugs. These problems can be solved by shortening the finalization time to one slot. SSF is on The Merge branch of the Ethereum roadmap (reference:https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1), is one of Ethereum’s long-term goals. However, Ethereum officials do not expect SSF to be launched within a few years, and it will require major upgrades such as Verkle Trees and Danksharding as preparatory work.
2.3 Solution
Vitalik pointed out that the current delegators have not played their due role, and believed that both of the above problems can be solved by giving more rights and obligations to delegators. The two main ways 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 proactive position in selecting staking service providers and node operators. At present, this method actually partially exists, because delegators holding stETH or rETH can directly withdraw money and then pledge it to other staking pools. However, there are many limitations, such as the inability to directly choose an operator and insufficient withdrawals. Flexible etc.
Vitalik mentioned three ways to expand delegators options:
Better voting tools within pools, optimizing voting within the pool: that is, optimizing voting within the staking pool, allowing users in the pool to choose their own node operators, but this method does not currently exist. Rocket pool allows any staker to become a node operator; in Lido, LDO holders determine node operators, although Lido has proposed a two-tier governance model of LDO + stETH (proposal link: https://research. lido.fi/t/ldo-steth-dual-governance/2382).
More competition between pools, strengthen competition between pools: that is, increase the level of competition between staking pools, so that delegators have richer choices. But in fact, LST in the long-tail staking pool is at a disadvantage in terms of liquidity, trustworthiness, and dapp acceptance. It cannot compete with leading projects like Lido, so delegators have no choice. Vitalik believes that the three issues of liquidity, trust and dapp acceptance can be solved through a series of measures, such as reducing the amount of slash fines to reduce the slash risks faced by delegators, making it possible for users to withdraw pledged ETH at any time, thereby solving LST liquidity and untrustworthiness issues; at the same time, a unified LST token standard can also be introduced, so that all staking pool LSTs are issued through a unified contract to ensure the compatibility and security of LST for different dapps.
About slash:
What is slash: The Ethereum consensus requires a certain incentive mechanism for validators to perform actively. To participate in the Ethereum consensus, validators need to pledge a certain amount of ETH in advance. If a validator behaves inappropriately, their staked ETH may be slashed. There are two main types of behavior that are considered dishonest: proposing multiple blocks in a slot (ambiguity) and submitting conflicting votes.
Why reducing the amount of slash can reduce the risks faced by delegators: In the current double-layer pledge structure, delegators only provide pledged ETH, and the behavior of the verifier is actually the behavior of the node operator, so when the operator does evil, it will cause delegators Be punished on your behalf. Projects such as Rocket Pool require node operators to contribute a certain amount of pledged ETH to reduce the agency problem. If the amount of ETH that can be slashed is reduced at the Ethereum level to the extent that the node operators share can cover it, then delegators can eliminate the risk of slashing, and the pledge service provider can allow delegators to withdraw money at any time without having to reserve a certain amount of liquidity.
Enshrined delegation, native integrated delegation: that is, Ethereum directly and natively integrates the above-mentioned related delegation functions, such as forcing delegators to select node operators when participating in pledges at the Ethereum protocol level, etc.
2.3.2 Consensus participation
Consensus participation allows delegators to participate in the Ethereum consensus in a lighter way without bringing additional burden to the 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 actively participate in the 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 types: 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 validator: undertakes the main verification and calculation work of Ethereum and needs to stay online at all times. The amount of ETH pledged by each complex validator will be required to be increased to 2048 ETH (the example given by Vitalik), which will bear the risk of slashing. The number of complex validators in the entire network is limited to 10,000.
Simple validator: There is no quota limit, no staking threshold, and it is immune to slashes. It 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 to 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 article, and small stakers and simple validators will be used interchangeably below)
Several possible ways for a simple validator to work
Each slot will have 10,000 simple validators randomly selected to vote for the state they approve of.
A delegator can send a transaction to declare that they are online and are willing to become a simple validator for the next hour to vote for the block header they approve of, and need to sign out after the work is completed.
A delegate can send a transaction to declare that he is online and willing to become a simple validator for the next hour. Each epoch, 10 random delegates will be selected to form the block recommendation list, and more than 10,000 delegates will be selected to become voters. Simple verifiers in this part do not need to sign out, and the online requirements expire over time.
The characteristics of the above three solutions are: they are all designed to prevent 51% attacks by node operators and improve Ethereum’s censorship resistance. The first and second solutions mainly prevent the finality from being reversed; the third solution focuses more on the censorship resistance of the network, and simple verifiers need to do more work.
Prerequisite for lightweight participation: There is an ultra-light client for simple verifiers to use, allowing them to complete verification work through mobile phones or web pages; this involves related research on lightweight Ethereum clients (such as the introduction of Verkle Tree, stateless, etc.), aiming to lower the participation threshold for validators.
source:https://notes.ethereum.org/@vbuterin/staking_2023_10
2.3.2.2 Third-party project integration
Third-party project integration refers to realizing the participation of delegators in the Ethereum consensus mainly through the upgrade of the staking pool itself. The core idea is to introduce the joint signature of delegators and verifiers in the consensus voting process to reflect the wishes of the delegators group. The following are three options proposed by Vitalik:
The Staking pool declares two staking keys when opening a validator account, namely P (persistent staking key) and Q (quick staking key, which is actually the output result when an Ethereum address is called). The nodes respectively track the signatures of P and Q on the message chosen by a certain fork. If the choices of P and Q are the same, the verification is successful; if they are different, the verification fails. The Staking pool is responsible for randomly selecting delegators as Q-key holders of the current slot.
The verifier randomly generates a pledge public key P + Q in each slot, and the voting signature of each slot requires joint calculation by the verifier and delegaotrs. Since each slot randomly generates different keys, there are related attribution issues when a slash occurs, and certain designs need to be made to address this issue.
Put Q into the smart contract rather than as a key directly held by delegators. Q managed by smart contracts can introduce diverse trigger conditions, thereby bringing richer voting logic to the staking pool.
2.3.3 Summary
Vitalik believes that if the above solution is adopted properly, adjustments to the proof-of-stake design can achieve two birds with one stone (reduce the centralization of pledges and reduce the consensus load of Ethereum):
Provide 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 participate 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 chosen option can improve the current situation.
Reducing the number of signatures that the Ethereum consensus layer needs to process per slot, even with a single-slot deterministic implementation, can be reduced to approximately 10,000. This contributes to decentralization and makes it easier for everyone to run a validator node.
Although the above solutions are at different levels of abstraction, including optimizing intra-pool elections, strengthening inter-pool competition, and Ethereum native integration, their goals are to solve the current problems of Ethereums pledge centralization and consensus load. Vitalik believes that specific implementation solutions should be carefully considered before being adopted, and the optimal solution should still achieve the desired goals while minimizing protocol changes.
3. Analysis of the impact on staking-related tracks
3.1 Overview of staking related tracks
Referring to @StakingRewards’s division of the Ethereum staking ecosystem, it can be divided from the bottom up into the verifier layer, staking layer, bridging layer, DeFi infrastructure layer and the top structured product layer. The internal logical relationships and respective values can be summarized as follows:
Verifier layer: Represented by node operators such as P2P and Stakefish, it provides the lowest level hardware resources for the staking layer or solo staking customers. These also include service providers SSV and Obol, which provide DVT technology. The verifier layer solves hardware-related problems for the pledge layer.
Pledge layer: Pledge service providers represented by Lido and Rocket Pool receive funds from delegators and interface with node operators on behalf of delegators to carry out consensus verification of Ethereum, including EigenLayer, which proposed the concept of restaking. The pledge layer encapsulates delegators indirect participation in PoS into financial products, lowering the participation threshold and introducing more pledge shares to Ethereum.
Bridging 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 to protocols such as Curve to provide delegators with the liquidity to withdraw from staking early. Reduce the opportunity cost of delegators participating in staking.
DeFi infrastructure and structured product layer: Use LSTs value storage and profitability to develop derivative products and services, create more LST application scenarios, enrich the DeFi ecosystem, and attract users to come and pledge.
Source: https://twitter.com/StakingRewards/status/1711409661734219886/photo/1
In the staking ecosystem, the staking layer plays a core role in connecting the past and the next: introducing more staking shares to Ethereum and delivering liquidity to the DeFi system through LST. The core position of the pledge layer allows its own changes to cause changes in the entire pledge ecosystem, so we will focus on analyzing the impact of relevant solutions on the pledge layer projects. The staking track in this article will mainly refer to the staking layer.
3.2 Potential impact of the above solutions on the staking track
The implementation angles of the above solutions are different, but they will all have an impact on the staking track. In the following, we will analyze the impact of different solutions and infer the feasibility of adopting the corresponding solutions.
3.2.1 Expanding delegate selection powers
The following is a brief analysis of the potential impacts of the three options for expanding delegators options mentioned by Vitalik.
Optimize voting tools within pools (Better voting tools within pools): that is, optimize voting within the staking pool, allowing users in 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 leading staking service providers more; the operator options that were originally more controlled by the staking service providers will be Part of it is transferred to delegators, which may reduce the value capture of the original governance token.
Adoption possibility analysis
The overall cost is small: no changes to the Ethereum consensus layer are required, only the pledge service provider needs to change its own mechanism.
Lack of incentives for existing staking service providers: This solution requires existing staking service providers to actively change and bear larger costs, including development costs and the cost of reduced utility of governance tokens.
Summary: It partially solves the problem of pledge centralization, but it cannot solve the problem of consensus load, and the final effect may be average. The implementation cost is low, but existing pledge service providers have no incentive to do it and are less likely to adopt it. There may be new staking service providers that use this feature to enter the market.
Strengthen competition between pools (More competition between pools): that is, strengthen competition between staking pools so that delegators have rich choices. At present, the core difference between different staking pools in attracting users lies in the liquidity, trustworthiness and dapp acceptance of LST. Vitalik proposed reducing the amount of slash and introducing a unified LST standard to reduce the above three differences and strengthen competition among pledge service providers.
Potential impact: The difference between staking service providers decreases, and the market share of leading projects such as Lido decreases, reducing the centralization of the staking track; the LSTfi ecosystem may become more prosperous, because the corresponding dapp can support more staking pools of LST; the Staking Service Chamber of Commerce In order to seek differentiation in other aspects, the direction of competition may turn to the staking income of LST itself, especially in the MEV withdrawal strategy.
Adoption possibility analysis
The overall cost is medium: the technical cost is low, because this solution does not require changes to the Ethereum consensus layer, only the introduction of the new LST token standard, and the cooperation of the pledge service provider in reducing the users slash share and adopting the new LST standard. However, during the adoption process, 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 here.
Lack of incentives for existing pledge service providers: This solution requires existing pledge service providers to make certain proactive changes, bear certain upgrade and development costs, and involve a large amount of LST conversion costs and risks. The adoption of this solution has also caused existing service providers to face pressure from declining market share.
Summary: The problem of centralization of pledges has been solved to a large extent, but the problem of consensus load cannot be solved, and the solution to the problem is incomplete. The overall implementation cost is medium, but existing pledge service providers have no incentive to do it, and the possibility of adoption is low. There may be new staking service providers that use this feature to enter the market.
Native integrated delegation (Enshrined delegation): Directly incorporate the above-mentioned related delegation functions into the Ethereum protocol layer, such as users directly selecting node operators, Ethereum launching its own LST token standard, etc.
Potential impact: The same impact as the above-mentioned 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 increase the burden on the Ethereum consensus because users participation in delegation at the Ethereum protocol layer will bring more verification work to the Ethereum consensus.
Adopt feasibility analysis
The overall cost is high: the Ethereum consensus layer needs to be upgraded to natively support related delegation functions.
It may go against the original intention of the upgrade: it increases the consensus burden on Ethereum; the method in which delegators directly select node operators for hosting through the protocol level is essentially closer to DPoS, which may be a result Vitalik does not want to see.
Summary: It solves the problem of pledge centralization to a large extent, but it will increase the problem of consensus load. At the same time, the cost of upgrading is relatively large and requires certain changes to Ethereum. Adoption is highly unlikely.
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 is whether it is implemented through native integration of Ethereum or within a third-party project.
3.2.2.1 Native integration
According to Vitaliks idea, Ethereums native integration solution will directly divide the network into two groups: complex validators and simple validators. The pledge threshold for complex validators will be increased to 2048 ETH, and the number of validators is limited to 10,000. They need to stay online in real time and be responsible for the main verification and calculation work; while simple verification only needs to use their own equipment to run a lightweight client. Participate in consensus at a specific time and only undertake lightweight tasks such as voting.
Note: 2048 ETH is the example given by Vitalik in the original article, but it is more likely to become the number adopted in subsequent plans. Combined with Vitalik in the articleFrom the explanation in and the EIP-7251 quoted by Vitalik in the original article, we can know that this data has practical significance: 2048 ETH can limit the number of validators in the equilibrium state to an ideal level and reduce the consensus burden of Ethereum. Paving the way for SSF implementation. at the same time, 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; and then use 2048 ETH as the overall pledge limit. To allow validators to choose their own tiers. In summary, it can be seen that using the number 2048 ETH for analysis in the following analysis has great reference value.
Source: https://notes.ethereum.org/@vbuterin/single_slot_finality
potential impact
It can solve the centralization of pledges and the load problem of Ethereum consensus at the same time: the native integration allows the majority of delegators and other ordinary users to participate in the consensus in a simple and low-cost way, greatly improving the decentralization of the Ethereum network; at the same time, 10,000 The limit on the number of complex validators reduces the difficulty of reaching consensus and the aggregate signature size of each slot, reducing the consensus burden on Ethereum.
The value of security technologies such as the services of pledge service providers and DVT will become higher, and the penetration rate will be further improved: a single complex verifier needs to conduct more active network verification and ensure an extremely high online rate, so the relevant hardware operation As the dimensionality threshold increases, the value of security technologies such as DVT is further highlighted; the pledge threshold of 2048 ETH makes most users who could originally pledge solo turn to delegators; based on the above, the penetration rate of pledge service providers and technical service providers such as DVT will increase.
There will be a ceiling in the market size of the staking track: In Vitaliks vision, the way for simple validators to participate in the consensus is to run ultra-light nodes on their own. The pledged ETH from the delegators part will not create more TVL for the pledge service provider, and other users who become simple validators do not need to become delegators through the pledge service provider, because they themselves need to run ultra-light nodes and there is no need to host them for pledgers. service provider and pay the corresponding hosting fees. Therefore, the TVL that staking service providers can capture will reach an upper limit of 20.48 million ETH.
Long-term growth of pledge service providers and related projects may stagnate
There is still space in the short and medium term, but the motivation is insufficient: judging from the current market size, the total supply of ETH has stabilized at around 120 million after EIP-1559 and Merge. The number of Ethereum participating in pledges is approximately 28 million, and the pledge rate is approximately At 23.29%, there is still some room for improvement in the staking track; but judging from the queuing situation of validators entering and exiting, the growth of ETH staking has reached a bottleneck with the decrease in staking income. Without the increase in on-chain transaction volume, If the MEV income rises significantly, the number of pledges will be in a stable equilibrium state, and growth will lack momentum.
The growth of technology projects such as pledge service providers and DVT will stagnate in the long term: from pledge service providers represented by Lido to DVT projects represented by SSV, their income models are to charge a certain percentage of fees on the pledge income of this part of the funds. . When the upper limit of delegators funds is 20.48 million ETH, then this part of the funds will be less than the current 28 million. If the future MEV income does not increase enough (meaning that the pledge rate is not increased enough), the absolute income scale of the staking track will not be Increase instead of decrease, and there is no source of growth in the long term.
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 of validators may be introduced in the long term.
One of Ethereum’s long-term development goals requires the introduction of a similar layered architecture of validators: Vitalik inpointed out that as blocks become larger (state expansion 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 to ensure that there is Acceptable trustlessness and censorship resistance. At the same time, in order to achieve features such as single-slot determinism (SSF) that improve the performance and security of Ethereum, 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 (stratification).
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 solutions 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 more arduous work (such as storing blobs and building blocks) to ensure efficiency; let more lightweight Nodes participate in consensus to ensure decentralization.
fromWe can see from the main idea that the SNARKization (lightweighting) of verification is to provide a reference method for simple verifiers to participate in consensus. We can also see in the Ethereum roadmap that related research including stateless, The Verge, etc. are all preparing for users to be able 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 pledge centralization and consensus load at the same time. The cost of adoption is extremely high and requires changes to the PoS rules at the Ethereum consensus layer, but it is in line with the long-term development interests of Ethereum, and the relevant preparations have been partially reflected in the Ethereum roadmap. Adoption is possible in the longer term, but realization in the short term is less likely.
3.2.2.2 Third-party project integration
Vitalik also proposed an implementation plan that is only implemented through staking pool without native support of Ethereum. The core is to split the verifiers private key into two parts, P and Q, respectively, and give them to verification nodes and users respectively, allowing users to participate in the consensus through the joint signature of P and Q.
Potential impact: It can solve the centralization problem of staking servers to a certain extent, but the effect is uncertain because the user participation process is relatively complex and the willingness to participate may be small. This plan is more of an internal adjustment of the pledge service provider and will have little impact on the layout of the track.
Adopt feasibility analysis
Moderate implementation cost: No major changes to the Ethereum consensus layer are required, but existing pledge service providers are required to carry out more complex upgrades, including the design of key splitting, custody and joint signatures, while also attracting users to participate in simple consensus verification.
The costs borne by pledge service providers will increase, and existing projects may not be incentivized to upgrade: firstly, the splitting and custody of validator private keys, and secondly, the design of user UX, will bring certain upgrade costs to existing pledge service providers, but it is difficult to Bring higher profits to existing service providers.
As the verification logic becomes more complex, it may increase the workload on Ethereum: more complex verification logic includes comparing messages signed by P and Q, etc.
Summary: It can solve the centralization problem of pledge servers to a certain extent, but the effect is uncertain and it will have little impact on the pattern of track projects. Existing projects are less likely to adopt it, but new staking service providers may use this feature to enter the market.
3.3 Summary
Vitalik did not clearly express his preference for a certain solution in his article, but we can still infer what may happen by analyzing the effect and impact of the solution and combining information from Vitaliks previous articles and the Ethereum roadmap.
Three solutions for the direction of Expanding delegate selection powers
The problem is not completely solved: Expanding delegate selection powers related solutions are mainly optimized for the problem of pledge centralization, but the solution effect is uncertain. Because the current two-tier staking structure around delegates-staking pools is already close to DPoS in nature, 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, this related solution does not solve the problem of Ethereum consensus load, and the solution that natively integrates delegation may also increase the burden on the Ethereum consensus.
The incentives for existing players to adopt are small: Solutions in this direction will harm the interests of existing pledge service providers. At the same time, solutions to optimize intra-pool elections and strengthen inter-pool competition also require the support of pledge service providers. Therefore, existing pledge service providers have little incentive to adopt relevant solutions. smaller.
In the short term, it may be adopted by new projects: New staking service providers may use this as a more decentralized feature to enter the market and compete with existing projects.
For solutions in the direction of Consensus participation
The native support solution may be a long-term solution: the native support solution can simultaneously solve the staking centralization and Ethereum consensus load problems mentioned by Vitalik. Meanwhile, preparations are underway to implement a similar layered validator architecture. It is difficult to achieve in the short term, but it is very possible in the long term.
Compared with Expanding delegate selection powers, third-party integration solutions can solve the problem of pledge 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 small incentives for existing players to adopt it. In the short term, new staking service providers may use this feature to enter the market.
4. Conclusion
In Vitaliks many 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 the competitiveness of Ethereum, Ethereum has not chosen to directly integrate all features, but leaves some functions to third-party projects to build. . Many third-party projects have also well answered the propositions left by Ethereum and found their own market positioning. However, as Ethereum itself continues to evolve, the problems and opportunities facing 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 and anticipate and seize end-game opportunities.
In the analysis of this article, we tried to conduct a comprehensive deduction on the variables that the current staking track-related projects may face in the future based on Vitaliks assumptions. Although Vitalik plans for the possible end of Ethereum in the relevant article, the future is still full of uncertainty, as current plans may change with new market demands and technological advancements. In this ever-changing scenario, only players with end-game thinking and the ability to capture current window bonuses can stay ahead in the long-term race.
