Staking Router + Community Staking Module upgrade announcement
This post aims to highlight the technical details of the proposed upgrade to the DAO. If no strong objections are raised within two weeks, the specified parameters will be put forward in an on-chain vote for approval. Valset tech contributors are available to address any questions that may arise.
The protocol upgrade consists of three main components:
- LIP-23: Negative rebase sanity check with second opinion
- LIP-25. Staking Router 2.0
- LIP-26. Community Staking Module
Some parameters are proposed to be set during the contract deployment before the vote, while others are through on-chain voting.
Part 1. Deployment
Sanity Checker
- The
churnValidatorsPerDayLimit
parameter has been split intoexitedValidatorsPerDayLimit
andappearedValidatorsPerDayLimit
. maxAccountingExtraDataListItemsCount
has been renamed tomaxItemsPerExtraDataTransaction
.maxNodeOperatorsPerExtraDataItemCount
has been renamed tomaxNodeOperatorsPerExtraDataItem
.- Added three new parameters
initialSlashingAmountPWei
,inactivityPenaltiesAmountPWei
, andclBalanceOraclesErrorUpperBPLimit
appearedValidatorsPerDayLimit = 43,200
This parameter defines the maximum number of validators that can be reported as “appeared” in a single day, limited by the maximum daily deposits via the Deposit Security Module (DSM).
BLOCKS_PER_DAY = (24 * 60 * 60) / 12 = 7_200
DSM_MAX_DEPOSITS_PER_BLOCK = 150
DSM_MIN_DEPOSIT_BLOCK_DISTANCE = 25
appearedValidatorsPerDayLimit = BLOCKS_PER_DAY / DSM_MIN_DEPOSIT_BLOCK_DISTANCE * DSM_MAX_DEPOSITS_PER_BLOCK = 43_200
exitedValidatorsPerDayLimit = 9,000
This parameter defines the maximum number of validators that may be reported as “exited” per day, depending on the consensus layer churn limit.
The parameter is calculated with the two-year growth projection of the CHURN_LIMIT
. The parameter can be revised after implementation of EIP-7251
// https://beaconcha.in/
CURRENT_ACTIVE_VALIDATORS_NUMBER = 1_100_000
// https://www.validatorqueue.com/
CURRENT_EXIT_CHURN_LIMIT = 16
EPOCHS_PER_DAY = 225 // (24 * 60 * 60) / 12 / 32
// https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#validator-cycle
MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT = 8
MAX_VALIDATORS_PER_DAY = EPOCHS_PER_DAY * MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT = 1_800 // 225 * 8
MAX_VALIDATORS_AFTER_TWO_YEARS = MAX_VALIDATORS_PER_DAY * 365 * 2 + CURRENT_VALIDATORS_NUMBER = 2_500_000 // 1_100_000 + (1_800 * 365 * 2)
// https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#validator-cycle
CHURN_LIMIT_QUOTIENT = 65_536
// https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#get_validator_churn_limit
MAX_EXIT_CHURN_LIMIT_AFTER_TWO_YEARS = MAX_VALIDATORS_AFTER_TWO_YEARS / CHURN_LIMIT_QUOTIENT = 38 // 2_500_000 / 65_536
exitedValidatorsPerDayLimit = MAX_EXIT_CHURN_LIMIT_AFTER_TWO_YEARS * EPOCHS_PER_DAY = 9_000 // 38 * 225 rounded up
maxItemsPerExtraDataTransaction = 8
This parameter defines the maximum number of data list items that can be reported to the accounting oracle as extra data in a single transaction. Each module (Curated, Simple DVT, CSM) can report items related to stuck or exited keys.
The optimal number of items is greater than 6 (2 items for stuck or exited keys per 3 modules) to ensure a small report can fit into a single transaction. However, there is additional capacity in case a module requires more than 2 items. Hence, the limit of 8 items per report is proposed.
maxNodeOperatorsPerExtraDataItem = 24
This parameter defines the maximum number of node operators that can be reported per extra data list item. It’s chosen based on the maximum gas consumption of each module during an operator update operation.
// Max gas consumption for updating a single node operator
CSM_ONE_OPERATOR_UPDATE_MAX_GAS = 41_150
CURATED_ONE_OPERATOR_UPDATE_MAX_GAS = 15_500
// Max gas consumption per 1 item
MAX_GAS_FOR_TX = 8_000_000 // Intentionally less than the block limit
MAX_GAS_PER_ITEM = MAX_GAS_FOR_TX / maxItemsPerExtraDataTransaction = 1_000_000 // 8_000_000 / 8
MAX_GAS_PER_OPERATOR_UPDATE = max(CSM_ONE_OPERATOR_UPDATE_MAX_GAS, CURATED_ONE_OPERATOR_UPDATE_MAX_GAS) = 41_150
maxNodeOperatorsPerExtraDataItem = MAX_GAS_PER_ITEM / MAX_GAS_PER_OPERATOR_UPDATE = 24 // 1_000_000 / 41_150
Negative rebase parameters
initialSlashingAmountPWei = 1000 (1 ETH): Defines the maximum initial slashing penalty for validators in the case of misbehavior. It ensures that a slashed validator can be penalized up to 1 ETH, contributing to the overall negative rebase calculation during the sanity check process.
inactivityPenaltiesAmountPWei = 101 (0.101 ETH): Represents the penalty for a validator being inactive over a prolonged period. It reflects the attestation penalties amounting to 0.101 ETH for validators who fail to participate in consensus duties.
clBalanceOraclesErrorUpperBPLimit = 50 (0.5%):
Specifies the error tolerance level for discrepancies in the reported aggregate balance of all validators in Lido on Ethereum.
Considering oracle balances comparison is triggered only by a negative rebase, the general attack scenario is as follows: colluded oracles aim to disrupt the protocol, while the second opinion oracle defends against it.
- If this parameter set to zero, then any validator introduced outside of Lido will impede the execution of a negative rebase and will require governance intervention. This essentially prevents reporting until governance intervenes, resulting in a denial-of-service (DoS).
- If this parameter set to positive infinity, then the second opinion mechanism ceases to provide protection, which is highly detrimental and irreversible.
It’s observed an asymmetry in impact — a small value can lead to DoS, while a large value allows a malicious rebase to be processed through validators donated to Lido. Therefore, it is necessary to adjust the value moderately to eliminate the DoS without degrading the primary protection parameters.
Lido’s Total Value Locked (TVL) is approximately 10 million ETH at the moment. A threshold of 0.5% would imply that, to carry out an attack at the current TVL, it would be necessary to activate about 1,500 validators. The situation can be resolved in four days either by withdrawing validators or by changing the parameters. Effectively, the attacker would be donating these validators to Lido.
The values were chosen based on LIP 23.
Deposit Security Module (DSM)
A new parameter, maxOperatorsPerUnvetting
, has been added to the DSM contract, which limits the number of operators involved in unvetting.
maxOperatorsPerUnvetting = 200
When the Council Daemon finds an invalid key in the deposit queue, it sends a transaction for unvetting keys to the DSM contract.
Unvetting a single operator requires approximately 20,000 gas. Thus, the maximum number of operators per unvetting is defined as 200 to keep the maximum transaction cost below 4,000,000 gas.
1 operator unvetting = 20,000 gas
200 operators unvetting = 4,000,000 gas
Part 2. Voting
Staking Router
The maxDepositsPerBlock
and minDepositBlockDistance
are proposed to be defined per module.
maxDepositsPerBlock
: Defines the maximum number of deposits that can be processed within a single block for a specific module. Different modules can have distinct limits based on their risk profiles and operational characteristics.
minDepositBlockDistance
: Specifies the minimum number of blocks that must pass between consecutive deposits for a given module. It ensures that deposits are spaced out over time to prevent abuse and enhance the security of the deposit process. Different modules can have distinct deposit block distances based on their risk profiles and operational characteristics.
maxDepositsPerBlock & minDepositBlockDistance
Module | maxDepositsPerBlock | minDepositBlockDistance |
---|---|---|
Curated | 150 | 25 |
Simple DVT | 150 | 25 |
Community Staking | 30 | 25 |
The values were chosen based on Front run Deposit attack research.
Priority exit share threshold
The priority exit share threshold is a parameter that defines the maximum share of validators a module can hold before it triggers prioritized validator exits. If a module’s share exceeds this threshold, its validators are given higher priority for exit.
Module | Share Limit | Share Threshold |
---|---|---|
Curated | 100% | 100% |
Simple DVT | 4% | 4.444% (10% drop) |
Community Staking | 1% | 1.250% (20% drop) |
The suggested values indicate that the priorityExitShareThreshold
for the Community Staking module will be triggered after a 20% TVL drop, while for the Simple DVT module, it will trigger after a 10% drop.
CURATED_PRIORITY_EXIT_SHARE_THRESHOLDS_BP = 10000 // 100% in basis points
SDVT_PRIORITY_EXIT_SHARE_THRESHOLDS_BP = 444 // 4.44%
CS_STAKE_SHARE_LIMIT_BP = 100 // 1%
CS_PRIORITY_EXIT_SHARE_THRESHOLD_BP = 125 // 1.25%
The values were chosen based on this research.
Community Staking Module (CSM)
The new module will be added to the protocol with the following parameters.
CS_MODULE_NAME = "Community Staking"
CS_STAKE_SHARE_LIMIT = 100
CS_PRIORITY_EXIT_SHARE_THRESHOLD = 125
CS_STAKING_MODULE_FEE = 600
CS_TREASURY_FEE = 400
CS_MAX_DEPOSITS_PER_BLOCK = 30
CS_MIN_DEPOSIT_BLOCK_DISTANCE = 25
// Initial oracle epoch if the vote starts on October 22nd, 2024
CS_ORACLE_INITIAL_EPOCH = 326715
Stake share lime = 100 (1%): Defines the limit of stake allocation to the new module. The value was chosen based on Lido Proposal and Risk assessment research.
Priority exit share threshold = 125 (1.25%): Defines the maximum share of validators the CSM can hold before triggering prioritized exits of validators. It is designed to account for potential protocol volatility, such as a 20% drop in Total Value Locked (TVL), to ensure a balanced distribution across staking modules. For more detailed information, refer to the previous Priority exit share threshold section.
Staking module fee = 600 (6%): Defines the percentage of fee from protocol rewards allocated to the module. Chosen value based on the risk assessment for community staking research.
Treasure fee = 400 (4%): Defines the percentage of fee from protocol rewards allocated to the treasury. Base Lido 10% fee on staking rewards minus module fee (10% - 6% = 4%).
Max deposits per block = 30: Defines a limit on the number of deposits to the module at a time. Chosen value based on security assumption for CSM module. For more detailed information, refer to the previous Staking Router section.
Min deposit block distance = 25: Defines the minimum distance between deposits to the module. For more detailed information, refer to the previous Staking Router section.
CSM Oracle initial epoch = 326715: The CSM Oracle initial epoch is calculated as the start time of the vote plus the voting duration and the Oracle report frame.
If no strong objections or last-minute findings arise, the expected voting date is either October 22 or October 29.
/*
calculation formula:
initialEpoch = epoch12UtcDayOfVote + voteDuration + delay + csmOracleFrame
*/
DELAY = 15 // epochs (1.5 hours after the main Oracle report)
CSM_ORACLE_FRAME = 225 * 28 // 28 Days
VOTE_DURATION_IN_SECONDS = 259200 // Vote duration in seconds (3 days)
CL_GENESIS_TIMESTAMP = 1606824023
// Initial oracle epoch if the vote starts on October 22nd, 2024
VOTE_START_TIMESTAMP = 1729598400
initialEpoch = ceil(ceil(((VOTE_START_TIMESTAMP + VOTE_DURATION_IN_SECONDS) - CL_GENESIS_TIMESTAMP) / 12) / 32) + CSM_ORACLE_FRAME + DELAY; // 326715
// Initial oracle epoch if the vote starts on October 29th, 2024
VOTE_START_TIMESTAMP = 1730203200
initialEpoch = ceil(ceil(((VOTE_START_TIMESTAMP + VOTE_DURATION_IN_SECONDS) - CL_GENESIS_TIMESTAMP) / 12) / 32) + CSM_ORACLE_FRAME + DELAY; // 328290
Coming Soon: Deployed Contracts and Audit Verifications
After the deployment, addresses for the newly deployed contracts will be provided. These contracts will undergo verification by external auditors, audit reports will be released, detailing the findings and mitigations.
Additionally, descriptions of the items up for vote will be published, offering the community a clearer understanding of the proposed changes and their implications for the protocol.
Stay tuned for further updates!