The article is from ethereum.org

Part of the content is translated by ChatGPT

The current state of Ethereum can be described as including a large portion of emerging two-tier staking. When I say two-tier staking, I mean a staking model where there are two types of participants:

1. Node operators, who run nodes and stake their reputation or a fixed amount of capital as collateral.
2. Delegators, who provide a certain amount of ETH, with no minimum commitment and no strict requirements other than participating by carrying collateral in any other way

This emerging two-tier staking is driven by the actions of most stakers participating in staking pools that provide liquidity staking tokens (LST), such as Rocket Pool and Lido.

There are two main flaws in the current state:

• Centralization risk of node operators. The mechanism for selecting node operators in existing staking pools is either not very decentralized or has other flaws.
• Unnecessary consensus layer burden. Ethereum L1 verifies about 800,000 signatures per epoch, and the final determinism per slot may increase to 800,000. This is a huge load. In addition, since the share of liquid staking is significant, the network does not receive all the benefits of bearing this load. If the network can achieve acceptable decentralization and security without requiring every stakeholder to sign in every slot, then we can rely more on this solution and reduce the number of signatures per slot to, for example, 10,000.

This article will describe possible solutions to these two problems. It will take a particular perspective: assuming that we believe that most capital is held by those who are unwilling to personally run staking nodes in their current form, unwilling to sign messages in every slot and lock up their deposits, and unwilling to reduce them. What other role can they play to make meaningful contributions to the decentralization and security of the network?

How does two-tier staking work today?

The two most popular decentralized staking pools today, Lido and RocketPool, are creating emerging two-tier staking ecosystems. In the case of Lido, the hierarchy is as follows:

Node operators: These node operators are elected through voting in the Lido DAO, and are thus effectively elected by LDO holders.

Delegators: People holding stETH. When someone deposits ETH into the Lido smart contract system, stETH is created, allowing node operators to stake it (however, since the withdrawal credentials are tied to the smart contract ETH address, they cannot claim it for themselves).

In the case of Rocket Pool, the hierarchy is:

Node operators: Anyone can become a node operator by depositing 8 ETH and a certain amount of RPL tokens.

Delegators: People holding rETH. When someone deposits ETH into the Rocket Pool smart contract system, rETH is created, allowing node operators to stake it (but not for themselves).

Representative roles

In these systems (or new systems enabled by potential protocol changes in the future), a key question to ask is: What does it mean to have delegators from a protocol perspective?

To understand why this question matters, let's consider the following scenario. A recent protocol change was implemented to limit the slashing penalty to 2 ETH. In response, Rocket Pool reduced the node operator deposit to 2 ETH. Rocket Pool's market share increased to 100% (not only among stakers, but also among ETH holders: as rETH becomes risk-free, almost all ETH holders become rETH holders or node operators).

Assuming rETH holders receive a 3% return (including protocol rewards and priority fees + MEV), and node operators receive a 4% return. We also assume a total supply of ETH of 100 million.

The math is calculated as follows. To avoid dealing with compound interest, we will look at daily returns instead of annual returns, so that the quadratic term becomes small enough to ignore:

Now, let's consider a different scenario. Rocket Pool does not exist. The minimum deposit for each staker is reduced to 2 ETH, and the total staked ETH limit is 6.25 million. Additionally, the return rate for node operators is also reduced to 1%. Let's calculate:

Now, let's consider these two scenarios from the perspective of attack cost. In the first scenario, attackers would not register as delegators: delegators have no power, so it's meaningless. Therefore, they would use all ETH to register as node operators. To gain a 1/3 share of all stakes, they would need to invest 2.08 million ETH (fair to say, this is still quite a lot! For example, see the discussion about the supercommittee, a staking expansion proposal that would also reduce the attack cost to a similar value). In the second scenario, attackers only need to stake, and to gain a 1/3 stake, they would need to invest… 2.08 million ETH.

From both the perspective of staking economics and attack cost, the end result of these two scenarios is exactly the same. The share of ETH held by node operators increases by 0.00256% per day, while the share held by non-node operators decreases by 0.00017% per day. The attack cost is 2.08 million ETH. Therefore, in this model, delegation seems to become a meaningless Rube Goldberg machine: we might as well eliminate the middleman, significantly reduce staking rewards, and limit the total staked ETH to 6.25 million.

The purpose of this argument is not to advocate for a fourfold reduction in staking rewards and a limit of 6.25 million staked ETH. Instead, it is to point out a key attribute that a well-functioning staking system should have: that delegators should do something truly important. Furthermore, if delegators are largely motivated by community pressure and altruism to take the right actions, that's fine; after all, this is the primary force driving people to choose a more decentralized and secure (but more effortful) way of enhancing security, rather than today's concentrated (but less effortful) way of threatening security.

If delegators can play a meaningful role, what might that role be?

I see two types of answers:

Representative selection: Representatives can choose which node operators to delegate their stake to. Node operators will have a "weight" in consensus that is proportional to the total stake delegated to them. Today, representative selection already exists in a limited form, in a sense, rETH or stETH holders can withdraw their ETH and switch to a different pool, but the actual availability of representative selection can be greatly improved.

Consensus participation: Delegators can choose to play a role in consensus that is "lighter" than full staking, and not subject to long withdrawal and significant risk, but still serves as a check on node operators. Many delegators do not want to do this and prefer the simplest interface, holding ERC20 and doing nothing else, but some may choose this option.

Expanding representative selection

There are three ways to expand representative selection:

• Better voting tools within pools
• Increased competition between pools
• Accredited representative groups

Currently, there is actually no in-pool voting: in Rocket Pool, anyone can become a node operator, and in Lido, the voting is done by LDO holders, not ETH holders. Lido has proposed a dual governance of LDO + stETH, which would give stETH holders a voice, as they can activate a small tool to block new votes, thus preventing node operators from being added or removed. In other words, it's limited and could potentially be more powerful.

Cross-pool competition exists today, but it's weak. The main challenges are that staking tokens in smaller staking pools have (i) poor liquidity, (ii) are less trusted, and (iii) have less application support.

We can improve the first two issues by limiting slashing penalties to smaller amounts, e.g. 2 or 4 ETH. Then, the remaining (non-slashable) ETH can be safely deposited and withdrawn immediately, allowing ETH-based LST to be exchanged bidirectionally with ETH, even for the smallest staking pools. We can address the third issue by creating a centralized issuance contract for LST—somewhat similar to wallet-based ERC-4337 and ERC-6900—ensuring that any staking tokens issued through this contract are secure. It's strongly encouraged for applications (e.g., RAI versions supporting staked ETH) to support all staking tokens issued through this registry.

Divine delegation does not currently exist in the protocol, but it may be introduced. It would involve logic similar to the above ideas but implemented at the protocol level. See this article for the pros and cons of divine delegation.

All these ideas are improvements to the current state, but their benefits are limited. Token voting governance is terrible, and ultimately any form of incentive-less representative selection is just token voting; this is why I've been uncomfortable with proof of stake from the start. Therefore, considering implementing a more powerful form of consensus participation seems valuable.

Consensus Participation

Even without considering the current issues around liquid staking, the current standalone staking method has limitations. Assuming a single-slot finality, our best estimate suggests a limit of ~100k - 1M BLS signatures per slot, and assuming slot times significantly increase. Even if we use recursive SNARKs to aggregate signatures, the responsibility for slashing (for the purpose of slashing) requires a bitfield for each signature. If Ethereum becomes a global-scale network, even using full danksharding to store the bitfields is not enough: each slot's 16 MB can only support about 64 million stakers.

From this perspective, splitting staking into a higher-complexity layer that operates every epoch but may only have 10,000 participants, and a lower-complexity layer that is only occasionally called upon to participate, is valuable. The lower-complexity layer can be completely free of slashing, or can randomly offer temporary (i.e., for a few epochs) deposits and the chance of slashing for its participants.

In practice, this can be achieved by raising the validator balance cap and then implementing balance thresholds (e.g., 2048 ETH) to determine which existing validators enter the higher or lower complexity layer.

Here are some ideas on how these small-stake roles could work:

• Randomly select 10,000 small stakeholders for each slot, who can sign on what they believe is the head of that slot's content. The LMD GHOST fork choice rule is run using the input of small stakers. If the small-staker-driven fork choice and the node-operator-driven fork choice disagree, the user's client does not accept any finalized blocks and displays an error. This forces the community to mediate in such a situation.
• Delegators can send a transaction declaring their willingness to act as small stakeholders in the next hour. Messages (blocks or proofs) from nodes and randomly selected delegators must be signed.
• Delegators can send a transaction declaring their willingness to act as small stakeholders in the next hour. Each epoch, 10 delegators are randomly selected as inclusion list providers, and more than 10,000 are selected as voters. These are pre-selected for k epochs and given a k-epoch window to publish messages on-chain, confirming their online status. Each confirmed selected inclusion list provider can publish an inclusion list, and a block is invalid unless for each inclusion list, it either (i) includes the transactions in that inclusion list, or (ii) it includes votes from 1/2 of the selected voters showing the inclusion list is unavailable.

These small-stake roles all have a commonality: they do not involve active participation in every slot, are non-slashable (thus having very low critical management risk), and are very "light" as they don't even require running a full node. Just validating the consensus layer is enough. Therefore, they can be implemented through applications or browser plugins, which are mostly passive and have very low computational expense, hardware requirements, or technical knowledge, and don't even require technological advancements like ZK-EVM.

These small-stake roles also have a common goal: they prevent 51% of node operators from engaging in transaction censorship. The first and second also prevent most people from participating in finality reversals. The third more directly addresses the censorship regime, although it's more susceptible to the likelihood of most node operators also choosing to censor inclusion list provider confirmation messages.

These ideas are written from the perspective of implementing a two-tier staking solution in the protocol, but they can also be implemented as staking pool features. Here are some specific implementation ideas:

• At the protocol level, each validator can specify two staking keys: a persistent staking key and an Ethereum address that, when called upon, outputs a fast staking key. Nodes track the fork choice based on the persistent-staking-key-signed messages and the message-key-signed messages; if they disagree, they don't accept any finalized blocks. The pool is responsible for randomly selecting delegators as message-key holders for the current slot.
• Alternatively, the protocol can remain essentially the same, but the staking public key for the slot's validators is set as persistent + message. Note that for slashing, two slashable messages may have different message keys, but they have the same persistent key; slashing design needs to address this.
• Alternatively, message keys can only be used in the protocol to sign and verify inclusion lists in blocks. In this case, the message key might be a smart contract rather than a single key, so the pool can use it to implement more complex voting logic, which accepts inclusion lists from randomly selected providers or enough votes indicating the inclusion list is unavailable.

Conclusion

If done well, adjusting the stake design can kill two birds with one stone:

(1) Provide an opportunity for those who currently lack the resources or ability to stake individually to participate in staking, giving them more power:

(i) Power to choose which nodes they support and (ii) power to participate actively to some degree in consensus is lighter than full staking node operation, but still meaningful. Not all participants will choose one or both options, but any choice significantly improves the current state.

(2) Reduce the number of signatures the Ethereum consensus layer needs to process in each slot to a smaller number, e.g., around 10,000, even in a single-slot finality mechanism. This will also help decentralization, making it easier for everyone to run a validating node.

For many such solutions, there are different levels of abstraction, and the solution to the problem can exist at these levels of abstraction: the power granted to users in staking pool protocols, the choices users make between staking pool protocols, and the provisions within the protocol. This choice should be carefully considered, minimizing feasible provisions, minimizing the degree of change in protocol complexity and protocol economics, while still achieving the intended goals, is generally best.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。