A detailed explanation of the similarities and differences of the Ethereum 2.0 liquidity staking scheme
Editor's Note: This article comes fromBlock beats BlockBeats (ID: BlockBeats), reprinted by Odaily with authorization.
Editor's Note: This article comes from
Block beats BlockBeats (ID: BlockBeats)
Block beats BlockBeats (ID: BlockBeats)
, reprinted by Odaily with authorization.
Since the launch of the Ethereum 2.0 beacon chain in just over a month, the balance of the Ethereum 2.0 mortgage address has exceeded 2.4 million Ethereum. At the same time, a large number of third-party staking platforms have been launched, including the centralized trading platform Binance and decentralized DeFi projects such as Rocket Pool and Lido. These different staking solutions differ in many ways.
Despite their differences, they have one thing in common: all projects are coming up with solutions to the inevitable friction that staking Ethereum creates. So, what exactly are these frictions?
First, the technical complexity of Ethereum 2.0 staking is beyond the reach of ordinary users. With the price of Ethereum rising rapidly ($1040 at the time of compiling this article), the minimum deposit requirement of 32 ETH is becoming increasingly out of reach for the average user. Finally, to enable the transition to Ethereum 2.0 in a safe and controlled manner, staking has an illiquid lockup period of 18-24 months.
Taken together, these restrictions can keep less sophisticated users from entering the "lucrative" Ethereum 2.0 staking market.
How do staking pools solve this problem?
This is where Ethereum 2.0 staking pools come in. They acquire Ethereum from multiple users and stake Ethereum 2.0 on behalf of users, enabling any participant to earn staking rewards regardless of their skill level or deposit size.
Additionally, they attempted to alleviate lengthy liquidity requirements by issuing Ethereum mainnet tokens representing deposits and rewards users earn on the Ethereum 2.0 chain. These pledged tokens provide holders with the opportunity to unlock liquidity, allowing users to trade Ethereum 2.0 pledged tokens for Ethereum native tokens on secondary markets such as Uniswap to exit pledges early, as well as utilize their pledged tokens The ability to participate in DeFi (e.g. as collateral at Aave).
In short, there are many differences in the mechanics of tokens from different staking pools that can lead to confusion with undesirable consequences for end users. However, these differences can be categorized and evaluated in order to discover the strengths and weaknesses of the respective staking pools. Furthermore, this comparative analysis can demonstrate the price efficiency of different Ethereum 2.0 staking tokens.
Single Token Design
In this article, I will demystify the principles of Ethereum 2.0 tokenization and give examples of how tokenization of different pledge pools works.
Staking Token Model
According to the classification of token structure, two different structures can be distinguished: one is a single token design, which aims to obtain the initial deposit and income deposited in one token at the same time; the other is a dual token design, which combines pledged deposits and Rewards are given separately as two different tokens.
Single Token Design
The single token structure is based on the concept of rebalancing or repricing tokens. This is the most popular design, and most staking pools use this strategy, probably because of its simplicity. By issuing a single token when users make deposits, staking pools seek to implement reward and penalty accountability within the same token. This can be achieved in two ways:
1. Change the quantity: The rewards and penalties in the Ethereum 2.0 pledge contract are reflected by changing the token balance. In the 1.5 token circulation stage, each pledged token will be in the pool at a ratio of 1:1 Convert to ETH;
2. Change the price: The rewards and penalties in the Ethereum 2.0 pledge contract are reflected in the price of tokens. In the 1.5 token circulation stage, the redemption amount of each pledged token is rewarded by the pledge pool. fluctuation.
Understand with a simple diagram:
1. The way to change the number of tokens, representative projects are: Lido and Binance.
2. Change the way of representing prices, Rocket Pool, Cream, StaFi and Stkr.
While using different mechanisms to reflect the accumulation of rewards, the single token designs have one thing in common: bundling deposits and rewards in the same token. This means that whenever you buy or sell tokens on the market or get tokens from a depositor, you will receive/sell both the deposit and any rewards that have been accumulated to the pool in the past.
Dual Token Design
Instead, the dual-token structure is based on the concept of two rebalancing tokens that reflect deposits and rewards, respectively.
In contrast, the dual token structure is based on the concept of two rebalancing tokens reflecting deposits and rewards respectively. Taking stakewise tokens as an example, the deposit and return tokens are stETH and reETH respectively.
When holding pledged tokens with a dual-token design, the token stETH representing pledged Ethereum will not grow, while the rwETH (rewarded ETH) token that accumulates rewards at a ratio of 1:1 will reflect the share of revenue in the pledge pool. increase. Together, the sum of these tokens constitutes the overall yield state and can be freely transferred between the Ethereum network and used in smart contracts in the same way as individual tokens.
It accumulates reward tokens for as long as staked tokens are held. As the reward pool grows, the balance of the Ethereum token stETH representing the deposit remains the same, but holding addresses are rewarded with the reward token reETH.
The sum of the deposited and rewarded Ethereum tokens is always equal to the amount of Ethereum in the pool; the exchange rate of the two tokens remains at 1
The dual token structure allows for the creation of a dynamic new hybrid model similar to bonds, but differs in that it splits the pledge into two tranches with different accrual values and cash flow expectations (principal and interest), enabling Manage individual staking more efficiently and flexibly.
Details of staked tokens
When it comes to the core of how Ethereum 2.0 staking tokens work, the design choices of different pools become more subtle, but can still make a significant difference.
Off-chain oracles
In order to be an effective solution to stagnant liquidity, the token must accurately reflect the value of the staked tokens held. This requires placing the correct amount of Ethereum in the staking pool to support the corresponding pledged tokens. To do this, staking pools need to track their node balances in the Beacon Chain and issue tokens against them.
But what you need to know is that the contract responsible for issuing tokens and the balance of the verification node are not on the same blockchain (Ethereum 1.0 VS Ethereum 2.0).
Unfortunately, the ERC-20 contract responsible for issuing tokens is not on the same chain as the node's balance (ETH1 vs ETH2). Token contracts on the Ethereum 1.0 chain cannot directly sync balances from beacon chain validators. Staking pools need to get around this limitation by using off-chain oracles, which work on a similar principle to the now ubiquitous Chainlink.
Off-chain oracles can obtain beacon chain data in the following ways: First, an oracle computing node must run both Ethereum 1.0 and Ethereum 2.0 nodes in order to interact with both chains at the same time. Once both nodes are up, the oracle will collect information from the beacon chain about validators belonging to a particular staking pool and transfer it to an ERC-20 smart contract on the Ethereum 1.0 chain. Once the information of the beacon chain is submitted to the ERC-20 contract, the number of tokens will be updated (or the exchange rate will be changed to issue new tokens) according to the change of the validator balance. This change can go up or down, depending on whether the balance increases (i.e. earns a reward) or decreases (i.e. incurs a penalty/).
Unfortunately, off-chain oracles introduce a drawback: the entity that controls the oracle effectively controls the renewal of tokens. To alleviate this problem, the staking pool requires multiple oracles to submit the same information at the same time, in order to update the token information through the consensus mechanism, and allocate oracles to achieve a certain degree of decentralization.
Pledged Token Balance Refresh Rate
However, in cases of massive slashing, daily updates may not be enough. "Slashing" occurs whenever a validator makes a slashing-inducing mistake, which results in a validator losing money within minutes. If the balance is updated less frequently than 24 hours, it will be disastrous.
Summarize
The problem here is that any user can track by epochs (via a beacon chain explorer) the amount of Ether in a validator monitoring a staking pool, and "know" that their balance will decrease before the token updates its balance. Once users realize the potential loss that is about to occur, they will execute the ERC-20 smart contract in advance, sell the token in the secondary market to reduce the loss, and make the unsuspecting liquidity provider suffer permanent loss and be fined A large number of positions are held in the pledge pool.
In order to avoid this situation, the pledge pool can adjust its ERC-20 contract refresh frequency to a higher frequency, increasing the Gas fee cost to prevent the risk of balance mismatch during slashing. In practice, however, it is unlikely that the staking pool will update token balances more frequently (let alone each epoch). Instead, they prefer to reduce the risk of slashing by improving security procedures, or are only prepared to increase the frequency of updates if a slashing event does occur.
