Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Off-chain storage & management for Lido validators' keys #341

Open
kadmil opened this issue May 5, 2021 · 9 comments
Open

Off-chain storage & management for Lido validators' keys #341

kadmil opened this issue May 5, 2021 · 9 comments

Comments

@kadmil
Copy link
Contributor

kadmil commented May 5, 2021

Prize Title

Off-chain storage & management for Lido validators' keys

Prize Bounty

3000 LDO (ERC20)

Challenge Description

Lido is a liquid staking protocol on Ethereum. The crucial protocol actors are Node operators: teams running ETH2 validator nodes and earning ETH2 beacon chain rewards for the protocol. Every validator has a key+signature pair conforming to the spec and the signature must contain the protocol's withdrawal credentials. Also, the keys must be unique. The protocol governance checks the key+signature pairs before allowing to delegate ether to new validators. The delegation method is permissionless. If there are no unused and approved key+signature pairs, no ether gets delegated on the delegation method call.

Currently the protocol stores all the operators' keys in the separate smart contract — Node operators registry. This results in significant gas costs, as the need in blockchain storage grows linearly with the amount of ether deposited. The challenge is to bring operators' keys off-chain and build the process for operations in such a setup. The possible method for validating the keys is Merkle-tree proofs.

The goal is to implement proof-of-concept: the key management smart contract, off-chain tooling and the demo code for the happy-path scenario.

Submission Requirements

Valid submission to win the prize consists of the open source PoC for the off-chain validator key management. The solution should:

  1. Not rely on storing the validator keys on the smart contracts.
  2. Have the demo of the working system. There are three actors in the demo: Node operator, Governance and Stranger. Node operator submits the data on key+signature pairs, Governance checks and approves the keys for delegation, and Stranger calls the delegation method which takes next approved key and uses it.
  3. The delegation method delegates the ether only to the keys which are approved and aren't used yet.

Note that the use of the actual ETH2 deposit contract isn't required and the mock will suffice. Having more than one Node operator in the proof-of-concept also isn't required. You can and probably should also mock/TODO most of Lido outside of adding keys and making deposits including the governance inner workings.

As a starting point please take a look on the Dummy Node Operators Registry storing the key pairs on-chain: https://gist.github.com/kadmil/e6c648a02cd656d41fa983615c4a21a3

Current production implementation you can find here: https://github.com/lidofinance/lido-dao/blob/master/contracts/0.4.24/nos/NodeOperatorsRegistry.sol

The submission must contain instructions for running the code and the happy-path in the README.md

Further reading

Judging Criteria

The winner would be chosen between the submissions with working PoC demo made by the deadline. Assessment criteria are:

  1. Working prototype with the the happy-path scenario
  2. Meets the tech requirements
  3. Clean code

Winner Announcement Date

Winners will be announced at the conclusion of Open-Defi hackathon.
@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 0.001 ETH (3.38 USD @ $3378.63/ETH) attached to it.

@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 0.001 ETH has been submitted by:

@DougAnderson444
Copy link

@kadmil how long does the Off-chain storage need to be saved for? Forever? Or less than forever?

@kadmil
Copy link
Contributor Author

kadmil commented May 12, 2021

@DougAnderson444 it's less than forever for most keys, most likely. The keys should be stored until the funds are staked with the key.

@gitcoinbot
Copy link

gitcoinbot commented May 16, 2021 •
edited

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work has been started.

These users each claimed they can complete the work by 4 days, 16 hours from now.
Please review their action plans below:

1) tomafrench has started work.

Modification of Node Operator registry to allow offchain storage of validator credentials
2) tanishqjasoria has started work.

Keys would be stored off-chain using the IPFS Protocol and IPFS Hash would be stored on-chain, separate for each node operator, preferably in the NodeOperator struct. A merkle root would also be stored on chain for verification purposes. Dao would verify the keys and then update approvedIpfsHash and approvedMerkleRoot after verification. User would submit keys with merkle proofs as arguments to depositBufferEther call. The keys would be verified using the approvedMerkleRoot and after successful verification, _ETH2Deposit function can be used to stake the required ehter.

Learn more on the Gitcoin Issue Details page.

@TomAFrench TomAFrench mentioned this issue May 19, 2021
Closed
@gitcoinbot
Copy link

gitcoinbot commented May 19, 2021 •
edited

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 3000.0 LDO (7710.00 USD @ $3.18/LDO) has been submitted by:

  1. @guayou888
  2. @tomafrench

@kadmil please take a look at the submitted work:

@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

The funding of 3000.0 LDO (5280.00 USD @ $2.03/LDO) attached to this issue has been approved & issued to @tanishqjasoria.

@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

The funding of 3000.0 LDO (5130.00 USD @ $1.71/LDO) attached to this issue has been approved & issued to @tanishqjasoria.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kadmil @DougAnderson444 @gitcoinbot and others