Staking Router + Community Staking Module upgrade announcement

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:

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 into exitedValidatorsPerDayLimit and appearedValidatorsPerDayLimit.
  • maxAccountingExtraDataListItemsCount has been renamed to maxItemsPerExtraDataTransaction.
  • maxNodeOperatorsPerExtraDataItemCount has been renamed to maxNodeOperatorsPerExtraDataItem.
  • Added three new parameters initialSlashingAmountPWei, inactivityPenaltiesAmountPWei, and clBalanceOraclesErrorUpperBPLimit

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!

14 Likes

Lido ValSet workstream contributors have deployed updated core protocol contracts for proposed Staking Router and Community Staking Module upgrade based on the previously approved LIP-23 and LIP-25.

The deployed contracts implementations follows the architectural changes presented with LIP-23: Negative rebase sanity check with second opinion and LIP-25: Staking Router 2.0.

See the announcement above for details on the initial upgrade parameters.

Contratcs

Deployed contracts for Community Staking Module will be announced separately.

6 Likes

CSM contracts are also deployed - Community Staking Module - #67 by dgusakov

5 Likes

Staking Router 2.0 + Community Staking Module voting script

2 Likes

Staking Router + Community Staking Module upgrade actions plan

Contributors from the Lido ValSet workstream have developed a detailed action plan based on the previously approved LIP-23, LIP-25 and LIP-26 proposals.

The objective is:

  • Upgrade the Staking Router and related contracts.
  • Upgrade the Accounting Oracle sanity checker.
  • Add the Community Staking Module (CSM).

Recap and References

Technical Details

The following contracts were deployed in advance:

See the announcement above for details on the initial upgrade parameters.

Voting Script

The voting script, including all necessary upgrades for Negative Rebase, Staking Router 2.0, and Community Staking Module features, has been prepared and published on the forum. A full description can be found by following this link.

Tentative Upgrade Timeline

  • Oct-22-2024 (Tue): Start Aragon voting.
  • Oct-24-2024 (Thu): Main voting phase ends.
  • Oct-25-2024 (Fri): Contingent on the voting outcome.
    • The objection phase and overall voting conclude. Enactment if passed.
    • Announce of new CSM UI.
  • Oct-26-2024 (Sat): First post-upgrade Accounting Oracle report.
  • Oct-28-2024 (Mon):
    • Announce of Node Operator Widget UI update.
    • Further minor protocol-related announcements.

Contingency Planning

The proposed upgrade has passed a rigorous security process. However, in the event of a failure during the upgrade:

  • If the vote fails to reach quorum, a vote restart will be suggested.
  • Operational delays or last-minute security concerns will be communicated, and new dates will be announced accordingly.
  • A postmortem will be issued in case of any severe unforeseen issues.

Discussion

Any additional feedback or suggestions on this proposal would be highly appreciated.

7 Likes

Hi everyone :wave: The MixBytes team is here!
The Lido Locator contract code was not included in the audit scope of our recent audit, and consequently, the verification of the deployment was not included in the final report. Nevertheless, we checked that the deployed contract bytecode of the implementation at address 0x3abc4764f0237923d52056cfba7e9aebf87113d3 corresponds to the bytecode of the current implementation [0x39aFE23cE59e8Ef196b81F0DCb165E9aD38b9463](https://etherscan.io/address/ 0x39aFE23cE59e8Ef196b81F0DCb165E9aD38b9463) except for the values of immutable variables depositSecurityModule and oracleReportSanityChecker that were audited. All other values in the Lido Locator don’t change between previous and proposed implementations.

7 Likes

The vote to upgrade the Staking Router and connect the Community Staking Module will also include items to rotate the address that Instadapp uses in the Lido Oracle set.

The detailed description of the vote steps has been updated to include new items (27-33) regarding oracle rotation: Staking Router 2.0 + Community Staking Module voting script - HackMD

3 Likes

:rotating_light: Voting has started! :rotating_light:

We’re excited to announce that voting has begun for a major upgrade: Vote #180.
This is a huge milestone that multiple teams have been working on for a significant amount of time.

The vote will be open for your “For” or “Against” input until the end of the main phase: Oct 24, 16:00 UTC.

Make sure your voice is heard by reviewing and casting your vote!
For instructions on how to verify the vote items, please follow this guide.

Let’s shape the future of Lido and decentralization together! :herb:

5 Likes

Thank you to everyone who voted! :heart:
The vote was enacted!
Results:
“Yes” — 59616915.9 (5.96%)
“No” — 93.8 (0.01%)
136 voters participated directly or through their delegate.

This upgrade marks a significant step forward for decentralization and the support of solo staking. The launch of the Community Staking Module (CSM) opens up exciting possibilities, making it easier than ever for individual validators to participate and for the community to take a more active role in securing the network.

Thank you again for supporting this pivotal upgrade!

6 Likes

Reasoning For Blockworks Advisory’s Vote On 180

We approve the integration of the Community Staking Module (CSM). The extrinsic risk liquid staking providers pose to Ethereum is relative to the quality of the validator set. More specifically, the extent of this risk depends on how fast an LSP can reallocate capital from node operators to a centralized operator. Lido’s vision of a diversified validator set neutralizes the cartelization risk a permissioned validator set presents to Ethereum. As such, we support Lido’s continued alignment with Ethereum by committing to diversifying the validator set with its Distributed Validator Technology module (DVT), exit priority limits, and now the CSM.

The Community Staking Module holds a competitive advantage in the solo-staking market with its 1.4 ETH minimum bond and higher less-volatile staking rewards (in part due to the dual reward structure of the CSM). The novel implementation of the Staking Router enables an equitable distribution of rewards despite the expected relative quality of CSM node operators (NO) being less than the Curated Module. By layering equitable rewards across modules with a performance threshold mechanism upholding a meritocratic self-elected validator set, a positive form of liberal welfare elevates the quality of the CSM validator set.

In line with our former opinion, we believe that version 2 of the Staking router is an integral aspect for the proper functioning of the CSM. By updating the Deposit Security Module (DSM), Validator Exit Bus Oracle (VEBO), Accounting Oracle (AO), and reward distribution mechanism, the curate module will be streamlined, validator exits will be proactively prioritized, and AOs will be scalable.

Lastly, while the likelihood of a negative stETH rebase is low, the existence of a dedicated fund and the approval of Lido DAO for slashing due to an inactivity leak provides a reassuring safeguard against this unlikely event.

Sources

Lido Improvement Proposals LIP-26

LIP-25 Forum Post: V2 Staking Router

LIP-23 Forum Post: Inactivity leaks

Github Lip 23

Reference Link: Reward Socialization

CSM HackMD Documentation