This doc is closed!
Pls comment on and refer to https://hackmd.io/@lido/csm-v2-internal
We all know that custom-tailored clothes tend to be comfier than the mass-market ones. The same goes for Ethereum validation with LST protocols. Community Staking Module (CSM) has already proven to be a market-leading solution for various Ethereum stakers, starting from home stakers and ending with professional Node Operators. Such a diverse set of participants requires some tailored solutions.
CSModule.sol
currently has several methods for creating Node Operators. During the Early Adoption (EA) period, these methods allow only members of the EA List to join. Once the EA period is over, these methods become permissionless. This approach is extremely limited in terms of customization. Hence, the concept of Gates and Extensions is proposed.
To implement this concept Node Operator creation methods in CSModule.sol
should be permissioned. Only members of the corresponding role (CREATE_NODE_OPERATOR_ROLE
) can call these methods. These role members are what we call Gates and Extensions.
Gates are smart contracts that allow users to join CSM. There are two types of gates:
Gate can assign a custom Node Operator type (defined by bondCurveId
) to the operators created using it. A permissioned gate can allow existing Node Operators to prove they are eligible to get the corresponding Node Operator type and claim one (corresponding bondCurveId
).
This is a stateless contract that proxies addNodeOperator*
calls with no additional functionalities. It keeps the invariant with mandatory keys uploading.
A gate that allows to join only vetted addresses using Merkle Tree. Additionally, it sets a special bond curve for the Node Operator.
Similar to gates, extensions are smart contracts that allow Node Operators to join CSM. Extensions also abstract Node Operator management in some form. An extension might assign itself as a CSM Node Operator manager and/or reward address to do that. This allows an extension to implement custom principles of Node Operator management, like taking a reward share from the Node Operator rewards or allowing only verified validator keys to be uploaded.
A good but not exhaustive example of the extension is a DVT-powered extension. Since DVT assumes the collective operation of a single validator by the cluster participants, a DVT-powered extension can manage individual cluster participants and share rewards. The other possible aspect of a DVT-powered extension can be on-chain key validation, ensuring that only keys created via DKG can be uploaded to CSM via this extension.
Node Operator creation will have an interface similar to the current one. However, the contract to be called will be different. By default, it is assumed that CSM will have two native gates:
Permissionless gate will have a simplified interface for Node Operator creation (without proof argument):
Identified Home stakers gate will inherit existing CSM interface for Node Operators creation:
In addition to the Node Operator creation, the Identified Home stakers gate will also provide a method for the existing CSM Node Operators to claim beneficial bond curve:
All other interactions with CSM will remain intact except for the minor changes in the interface of the addKeys
methods (from
argument added):