Partnered With:

Read in-depth V God’s long article on Staking: How will his concept profoundly affect the staking track?

Read this article in 38 Minutes

Ethereum should remain neutral and minimalist.

Original author: Hank Han

1. Introduction

Ethereum staking and its related derivative tracks are undoubtedly the hottest topics in the past year or two. From Beacon Chain to The Merge, from Shanghai Supremacy to LST, DVT, Restaking, and LSTfi, we have witnessed the rise and rapid development of staking and related tracks. Behind this driving force, we can easily find that its development originated from the paradigm shift of Ethereum staking. Therefore, we should also consider: how will the staking paradigm of Ethereum evolve in the long term, and how will it affect related tracks and major players?

In an article titled <Protocol and staking pool changes that could improve decentralization and reduce consensus overhead> published by Vitalik on October 7th, he proposed some optimization solutions for the current Ethereum staking mechanism, providing a reference path for further decentralization and reducing consensus load. Some of the proposed ideas will bring significant changes to the staking mechanism, while also aligning 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 Double-layer collateral status

Vitalik refers to the current staking structure of Ethereum as "two-tiered staking", in which there are two types of participants: Node operators and Delegators.

Node operators: refers to the operators who are responsible for operating Ethereum nodes.

Delegators: refers to users who participate in staking through various means (excluding 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 Existing Problems

Vitalik believes that the double staking model brings two problems, namely the centralization risk of the staking track and the unnecessary burden on the consensus layer.

·Centralization risk in the staking industry: After delegators stake ETH, they need service providers like Lido to select nodes. The specific selection mechanism may bring centralization risks to node operators from different perspectives. For example, if Lido decides on node operators through DAO voting, node operators may tend to hold a large amount of LDO to increase their market share. Rocket Pool allows anyone to become a node operator after staking 8 ETH, which allows financially strong operators to directly "purchase" market share.

·Unnecessary consensus layer burden: Currently, the Ethereum consensus layer needs to aggregate and verify about 800,000 signatures per epoch. If the goal of Single Slot Finality (SSF) is to be achieved, Ethereum will need to aggregate and verify 800,000 signatures per slot, which means that the task remains the same but the time is shortened to 1/32 of the original time, putting higher demands on the hardware of running nodes. From the current two-layer pledge structure, most of the verification work is done by node operators, and although there are many validators, the actual main body of running validators is not diversified. That is to say, the increase in the number of nodes has not reduced the centralization degree of Ethereum, but has increased the consensus burden of Ethereum. Therefore, the number of verification nodes can be reduced (reducing the number of signatures to be processed), thereby reducing the consensus load of Ethereum (which sounds more centralized, and measures to reduce centralization will be discussed in the following section).

Background Information:

Slot: Refers to the time required for a new block to be included in consensus. In Ethereum, a slot is approximately 12 seconds. In each slot, the network randomly selects a validator as the block proposer, who is responsible for creating a new block and sending it to other nodes on the network. Additionally, in each slot, a validator committee is randomly selected to vote on the validity of the proposed block. Not all validators need to participate in the validation work of a slot, only the selected committee's validators need to participate normally. A 2/3 vote of the committee can make the slot's state 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 that contains 32 slots. An Ethereum epoch lasts approximately 6.4 minutes. During an epoch, a validator can only join one committee, and all active validators in the network must provide proof of their "active" status during this epoch. The first slot of each epoch (usually) is also known as a checkpoint.

Finality: The "finality" of a transaction in a distributed network means that the transaction becomes part of a block and cannot be changed unless a large amount of ETH is destroyed, causing a blockchain rollback. Ethereum manages finality through "checkpoint" blocks. If a pair of checkpoint blocks (the first slot of adjacent epochs) receives more than 2/3 of the total staked ETH in votes, then the pair of checkpoint blocks will be upgraded. The newer of the two checkpoint blocks will become "justified" and the older checkpoint block will be upgraded from "justified" in the previous epoch to "finalized" status. On average, user transactions will be in a block in the middle of an epoch, with half an epoch remaining until the next checkpoint, indicating that the transaction is finally determined to be 2.5 epochs, or about 16 minutes (after 0.5 epochs, reaching the next checkpoint; after another 1 epoch, the next checkpoint obtains a justified status; after another 1 epoch, the next checkpoint obtains a finalized status). Ideally, the 22nd slot of an epoch will achieve the justification of the epoch checkpoint. Therefore, the average finality of a transaction is 14 minutes (16+32+22 slots).

Single Slot Finality (SSF): Each slot produces a block that achieves finality immediately. Currently, the time required for Ethereum to achieve finality for a block is too long, and most users do not want to wait about 15 minutes to finalize a transaction. This also limits the development of applications that hope to achieve high transaction throughput. In addition, the delay between block proposal and finality also creates opportunities for short-term reorganization, allowing attackers to review certain blocks or perform MEV extraction. The mechanism for processing 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 issues can be resolved by reducing the finality time to a single slot. SSF is one of Ethereum's long-term goals in The Merge branch of the Ethereum roadmap (see: https://twitter.com/VitalikButerin/status/1588669782471368704/photo/1). However, Ethereum officials expect that SSF will not be launched in the next few years, as it requires major upgrades such as Verkle Trees and Danksharding as prerequisites.

2.3 Solution

Vitalik pointed out that the current delegators have not played their due role, and believes that both of the above issues 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 choice of delegators and giving them a more proactive role in selecting staking service providers and node operators. Currently, this approach is partially in place, as delegators holding stETH or rETH can withdraw and stake in other staking pools. However, there are many limitations, such as the inability to directly choose operators and inflexible withdrawal options.

Vitalik mentioned three ways to expand delegators' voting rights:

·Better voting tools within pools: optimizing voting within staking pools, allowing users within the pool to choose their own node operators. However, this method does not currently exist in practice. 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 governance model using LDO + stETH (proposal link: https://research.lido.fi/t/ldo-steth-dual-governance/2382).

·More competition between pools: Strengthening the competition between staking pools, providing delegators with more choices. However, in reality, long-tail staking pools are at a disadvantage in terms of liquidity, trustworthiness, and dapp acceptance compared to top projects like Lido, leaving delegators with no choice. Vitalik believes that the three issues of liquidity, trustworthiness, and dapp acceptance can be solved through a series of measures, such as reducing the amount of slash penalties to lower the risk of slash faced by delegators, making it possible for users to withdraw staked ETH at any time to solve the liquidity and trust issues of LST. At the same time, a unified LST token standard can be introduced, allowing all staking pools' LST to be issued through a unified contract to ensure the compatibility and security of LST for different dapps.

About slash:

What is slash: Ethereum consensus requires a certain incentive mechanism to encourage validators to actively participate. Validators need to pledge a certain amount of ETH in advance to participate in Ethereum consensus. If a validator behaves improperly, their pledged ETH may be destroyed (slash). There are mainly two behaviors that are considered dishonest: proposing multiple blocks in a slot (ambiguous) and submitting conflicting votes.

Why reducing the slash amount can reduce the risk faced by delegators: In the current two-layer staking structure, delegators only provide ETH for staking, while the behavior of validators is actually the behavior of node operators. Therefore, when operators behave maliciously, delegators will be punished on their behalf. Projects like Rocket Pool require node operators to contribute a certain amount of staking ETH to reduce delegation agency issues. If the amount of ETH that can be slashed at the Ethereum level is reduced to the extent that it can be covered by the operator's share, delegators can eliminate slash risk, and staking service providers can allow delegators to withdraw funds at any time without having to reserve a certain amount of liquidity.

Enshrined delegation, native integration of delegation: that is, Ethereum directly integrates the above-mentioned delegation functions natively, such as requiring delegators to participate in staking by selecting node operators at the Ethereum protocol level, and so on.

2.3.2 Consensus participation

When setting up a validator account, a 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 signature of the message selected for a fork by P and Q respectively. If the choices of P and Q are the same, the validation is successful; if they are different, the validation fails. The staking pool is responsible for randomly selecting delegators as the Q-key holders for the current slot.

Validators generate a staking public key P + Q randomly in each slot, and the vote signature in each slot requires joint calculation by validators and delegators. Since different keys are randomly generated in each slot, there are attribution issues related to slash, which require certain design considerations for the problem.

Put Q into the smart contract instead of holding it as a key directly as a delegator. The Q managed by the smart contract can introduce diversified triggering conditions, thus bringing richer voting logic to the staking pool.

2.3.3 Summary

Vitalik believes that if the above solution is implemented properly, it can achieve two goals with one stone in adjusting the design of proof of stake (reducing the centralization degree of staking and reducing the consensus load of Ethereum):

1. Provide an opportunity for those who currently lack the resources or ability to participate in PoS to participate, allowing them to have more control (including the power to choose the nodes they support) and participate in a lighter but still meaningful way. At the same time, Vitalik also pointed out that not all participants will choose these two options or one of them, but any chosen solution can improve the current situation.

2. Reduce the number of signatures that the Ethereum consensus layer needs to process per slot, even in the case of single-slot determinism, to approximately 10,000. This helps with decentralization, making it easier for everyone to run a validation node.

For the above solutions, including optimizing pool elections, strengthening inter-pool competition, and native integration with Ethereum, although they are at different levels of abstraction, their goals are to solve the problems of centralization and consensus load in Ethereum staking. Vitalik believes that specific implementation plans should be carefully considered before being adopted, and the optimal solution should be able to achieve the expected goals while minimizing protocol changes.

3. Analysis of the Impact on the Pledge-Related Track

3.1 Overview of Pledge-related Tracks

Reference to @StakingRewards' classification of the Ethereum staking ecosystem, it can be divided from the bottom up into the validator layer, staking layer, bridging layer, DeFi infrastructure layer, and the top-level structured product layer. The internal logic and respective values can be summarized as follows:

·Validator Layer: Represented by P2P, Stakefish and other node operators, it provides the lowest level of hardware resources for customers who stake in the pledge layer or solo pledge. This also includes service providers such as SSV and Obol who provide DVT technology. The validator layer solves hardware-related issues for the pledge layer.

·Pledge Layer: Pledge service providers represented by Lido and Rocket Pool receive funds from delegators and act as intermediaries between delegators and node operators to carry out Ethereum's consensus verification, including EigenLayer, which proposed the concept of restaking. The pledge layer encapsulates the behavior of delegators' indirect participation in PoS into financial products, reducing the participation threshold and introducing more pledge shares to Ethereum.

·Bridge Layer: This refers to the LST (Liquid Staking Token) issued by the collateral layer, which allows users to participate in various DeFi protocols through LST. Collateral service providers add LST-ETH trading pairs in protocols such as Curve to provide liquidity for delegators to withdraw collateral early and reduce the opportunity cost of participating in collateral.

·DeFi infrastructure and structured product layer: Develop derivative products and services using the value storage and revenue capabilities of LST, create more application scenarios for LST, enrich the DeFi ecosystem, and attract users to pledge.

Source: https://twitter.com/StakingRewards/status/1711409661734219886/photo/1

(Note: This content contains HTML tags and links, which should not be translated. All Chinese characters will be translated.)

In the staking ecosystem, the staking layer plays a crucial role in introducing more staking shares to Ethereum and providing liquidity to the DeFi system through LST. The central position of the staking layer allows its own changes to cause changes in the entire staking ecosystem. Therefore, we will focus on analyzing the impact of relevant solutions on staking layer projects. In this article, the staking track mainly refers to the staking layer.

3.2 The Potential Impact of the Above Plan on the Pledge Track

The implementation perspectives of the above solutions differ, but they will all have an impact on the staking track. We will analyze the impact of different solutions in the following text and infer the feasibility of adopting corresponding solutions.

3.2.1 Expanding delegate selection powers

Possibility analysis of adoption

Overall cost is moderate: the cost of technology is relatively low because the solution does not require changes to the Ethereum consensus layer, only the introduction of a new LST token standard and cooperation from staking service providers to reduce user slash shares and adopt the new LST standard. However, in the adoption process, a large number of existing LST holders need to exchange their LST for the new unified standard LST, so there is a significant migration cost here.

Existing pledge service providers lack incentives: This scheme requires existing pledge service providers to make certain proactive changes, bear certain upgrade and development costs, as well as a large amount of LST conversion costs and risks. The adoption of this scheme also puts existing service providers under pressure to face a decline in market share.

Summary: It largely solves the problem of centralization in pledging, but cannot solve the problem of consensus load, and the problem is not completely resolved. The overall implementation cost is moderate, but existing pledging service providers have no incentive to do so, so the likelihood of adoption is small. There may be new pledging service providers entering the market with this feature.

·Native integration of delegation (Enshrined delegation): Directly incorporating the delegation functionality mentioned above into the Ethereum protocol layer, such as users directly selecting node operators, and Ethereum introducing the LST token standard.

Potential impact: Similar to the impact of the aforementioned pool competition scheme, but the support of the Ethereum protocol layer will to some extent ensure the security of the corresponding transformation. It may increase the burden on Ethereum consensus, as users participating in delegation at the Ethereum protocol layer will bring more verification work to Ethereum consensus.

Feasibility analysis accepted.

Summary: It largely solves the problem of centralization in pledging, but it will increase the consensus load. At the same time, the cost of upgrading is high and requires some changes to Ethereum. The possibility of adoption is extremely low.

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 native integration with Ethereum or within a third-party project.

3.2.2.1 Native Integration

Note: 2048 ETH is an example given by Vitalik in the original text, but it is highly likely to be adopted as the number in subsequent plans. Combining Vitalik's explanation in the article "Paths toward single-slot finality" and EIP-7251 cited by Vitalik in the original text, we can see that this data has practical significance: 2048 ETH can limit the number of validators in a balanced state to an ideal level, reduce the consensus burden of Ethereum, and pave the way for achieving 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, raise the upper limit of validator balance to 2048 ETH while retaining the lower limit of 32 ETH; then use 2048 ETH as the overall pledge limit to let validators choose their own layers. In summary, analyzing with the number 2048 ETH in the following analysis has significant reference value.

One of Ethereum's long-term development goals is to introduce a similar validator layer architecture: Vitalik pointed out in <Endgame> that as the 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 to ensure acceptable trustlessness and censorship resistance. At the same time, in order to achieve features such as Single Slot Finality (SSF) to improve Ethereum's performance and security, two types of validators are needed to work together. The responsibilities of the two types of validators are different and are suitable for different staking rules (layering).

The validator layering structure has appeared multiple times in the Ethereum roadmap and related articles, and there are many solutions related to lightweight clients being planned and researched, aiming to create conditions for simple validators to participate in consensus.

From important upgrades such as PBS and Danksharding, we can see a similar idea of layering and division of labor: allowing specialized nodes to take on more heavy work (such as storing blobs and building blocks) to ensure efficiency, while allowing more lightweight nodes to participate in consensus to ensure decentralization.

From the main concept of <Endgame>, we can see that the SNARKification (lightweighting) of verification provides a reference for simple validators to participate in consensus. In the Ethereum roadmap, we can also see that related research such as statelessness and The Verge are being conducted to prepare users to run super light nodes.

Source: https://vitalik.ca/general/2021/12/06/endgame.htm

Source: https://twitter.com/VitalikButerin/status/1588669782471368704

(This content does not require translation as it consists of HTML tags and a URL in English.)

Summary: It can solve the problems of both centralized pledge and consensus load at the same time. It is very expensive to implement and requires changing the PoS rules at the Ethereum consensus layer, but it is in line with Ethereum's long-term development interests, and relevant preparations have already been partially reflected in Ethereum's roadmap. It may be adopted in the long term, but the possibility of short-term implementation is small.

3.2.2.2 Third-party project integration

Vitalik also proposed an implementation that only relies on staking pools, without requiring native support from Ethereum. The core idea is to split the validator's private key into two parts, P and Q, and give them to the validator node and the user respectively. Users can participate in consensus by using the joint signature of P and Q.

·Potential impact: It can to some extent solve the problem of centralization in pledge services, but the effect is uncertain because the user participation process is relatively complex and the willingness to participate may be small. This solution is more of an adjustment within the pledge service providers and has little impact on the overall landscape of the industry.

·Adopt feasibility analysis

Implementation cost is moderate: no major changes need to be made to the Ethereum consensus layer, but existing staking service providers need to undergo relatively complex upgrades, including the design of key splitting, custody, and joint signature, while also attracting users to participate in simple consensus verification.

·The cost of pledge service providers has increased, and existing projects may not have incentives to upgrade: First, the splitting and storage of validator private keys, and second, 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.

Due to the increased complexity of the verification logic, it may add workload to Ethereum: more complex verification logic includes comparing the messages of P and Q signatures, and so on.

·Summary: It can solve the problem of centralization in pledge services to a certain extent, but the effect is uncertain and has little impact on the pattern of the industry. Existing projects are less likely to adopt it, but there may be new pledge service providers entering the market with this feature.

3.3 Summary

Vitalik did not express a clear preference for any particular solution in the article, but we can still infer what might happen by analyzing the effects and impacts of the solutions, and combining information from Vitalik's previous articles and the Ethereum roadmap.

Problem not thoroughly solved: Expanding delegate selection powers. The related solutions mainly optimize the problem of centralized pledge, but the effectiveness of the solution is uncertain. This is because the current double pledge 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, this related solution does not solve the problem of Ethereum consensus load, and the native integration of delegation may also increase the burden on Ethereum consensus.

Existing adopters are incentivized: The plans in this direction will harm the interests of existing staking service providers, and the plans to optimize pool elections and strengthen inter-pool competition also require the support of staking service providers. Therefore, the existing staking service providers have relatively small incentives to adopt relevant plans.

·Regarding the plan for Consensus participation direction