Motivation
A migration to L2 also presents an opportunity to deploy a new staking contract. The reasons for deploying a new staking contract instead of using the existing BondingManager code include:
- Improved gas efficiency in a new staking contract is still useful on L2 since it will decrease transaction fees on L2
- The existing BondingManager contains a lot of one-off patches for bug fixes from the past few years and the code for these patches increase gas consumption, code complexity and developer maintenance burden
- While a contract can be upgraded after deployment, the restrictions around contract storage layout make drastic changes to how state is managed in a contract post-deployment difficult so it would be preferable to make any big technical changes such as how state is managed before deploying a new contract
This post outlines ideas for a new staking contract that could be deployed to L2 (or any EVM compatible domain including L1).
Delegation share based accounting
Today, the BondingManager contract uses an earnings pool based accounting mechanism to calculate the LPT rewards and ETH fees that orchestrators and delegators are entitled to. At a high level, the basic idea of this mechanism is to keep track of the state of an orchestrator’s earnings pool per round and the state of an orchestrator’s earnings pools from two rounds can be used to calculate rewards and fees earned during the period between those two rounds.
Although the gas efficiency of this mechanism was improved with LIP-36, which drastically reduced the amount of on-chain computation required, and LIP-52, which allowed orchestrators and delegators to submit a single transaction to “catch up” on rewards and fees earned in the past, this accounting mechanism still presents a few problems:
- State needs to be checkpointed per round which increases gas consumption
- The state model makes it difficult to allow a delegator EOA to be delegated to multiple orchestrators (more on this in the next section) which is why a delegator EOA can only be delegated to a single orchestrator right now
- The code is complex to maintain and a number of edge cases were uncovered after the LIP-36 and LIP-52 upgrades that required bug fixes
A candidate update is to switch to a delegation share based accounting mechanism. At a high level, the basic idea of this mechanism is to keep track of a single delegation pool for each orchestrator and delegators would receive delegation shares from the pool in exchange for their delegated stake. A delegator would then trade in their delegation shares for their stake and also a pro-rata share of the rewards and fees that have been added to the delegation pool since the creation of the delegation shares.
The benefits of this mechanism include:
- State would not need to be checkpointed per round which reduces gas consumption
- The state model makes it easy to allow a delegator EOA to be delegated to multiple orchestrators (more on this in the next section)
- The state model makes it easier to support tokenization of stake in external contracts (i.e. Tenderize) for liquid staking/staking derivative use cases in the DeFi ecosystem since a contract could mint tokens whenever delegation shares are created
- Reduced code complexity as this mechanism should require less code to implement
The remaining research that still needs to be completed for this mechanism include:
- Restricting delegators from earning rewards/fees from multiple orchestrators in a round without imposing additional per round state checking (discussion)
Multi-delegation support
Today, the BondingManager does not support multi-delegation so delegator EOAs cannot delegate to multiple orchestrators simultaneously. It is possible to build a multi-delegation mechanism in an external contract, but this would be really expensive in terms of gas usage because new contracts would need to be created for each delegation.
A nice byproduct of delegation share based accounting is that multi-delegation becomes easy to support since a delegator EOA could own delegation shares from different orchestrators’ delegation pools.
The benefits of this feature include:
- Enables a more dynamic delegation market in which delegators can diversity their stake delegations across multiple orchestrators - this can help delegators to construct delegation portfolios that suit their risk/reward appetite and high potential orchestrators to attract stake
- Makes it easier for external contracts to build DeFi products based on portfolios of delegations
Next Steps
- Complete research for restricting delegators from earning rewards/fees from multiple orchestrators in a round without imposing additional per round state checking (discussion)
- Complete a full implementation (currently in-progress)
- If these ideas are validated in an implementation and there is community support, create a draft LIP