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.

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

Move signing keys selection to NodeOperatorsRegistry #226

Merged
merged 8 commits into from
Dec 8, 2020

Conversation

skozin
Copy link
Member

@skozin skozin commented Dec 4, 2020

Currently, signing keys are selected from eligible Node Operators in the following manner:

  1. Lido obtains all Node Operators' data (except pubkeys/signatures) from NodeOperatorsRegistry and caches it into memory.
  2. Lido performs as many 32 ETH deposits as possible. Before making each deposit, Lido selects the Node Operator with the least effective stake and retrieves its next unused pubkey and signature from NodeOperatorsRegistry.
  3. After performing all deposits, Lido updates used keys counts in NodeOperatorsRegistry.

This PR changes the process to the following:

  1. Lido calculates the number of deposits it's allowed to make.
  2. Lido requests the desired number of unused pubkeys/signatures from NodeOperatorsRegistry, which selects the operators with the least effective stake and returns their pubkeys/signatures as two concatenated byte arrays, updating operators' used keys counts at the same time.
  3. Lido performs the deposits.

The new approach has a number of benefits:

  1. It uses significantly less gas due to making fewer Aragon-proxied calls and transmitting less data.
  2. The resulting code is less coupled and more testable (e.g. one can test pubkey selection without making actual deposits).
  3. The size of the Lido contract's bytecode and sourcecode is decreased.

Gas profiling

The profiling was performed for 10 Node Operators, each having one key already used. The numbers below were obtained using the mock deposit contract and corrected for the real deposit gas usage (assuming it's 49000 for inter-contract calls).

Total gas, 1 deposit Total gas, 10 deposits
master 517,399 1,349,282
this PR 186,150 985,423
Reduction 64% 26%

Index underflow fix

Also, this PR fixes #227 which was discovered in the process the refactoring.

@skozin skozin mentioned this pull request Dec 4, 2020
@skozin skozin added solidity issues/tasks related to smart contract code enhancement New feature or request labels Dec 4, 2020
the upsides are significant gas savings, less coupled code and decreased size of the Lido contract (which is currently the heaviest one)
@skozin skozin force-pushed the optimize-operator-selection branch from 1cb1bb0 to 1d7422f Compare December 4, 2020 22:22
this has a side effect of changing the key assignment order in the case when several node operators have the same effective stake: previously, keys were assigned in the id-reverse order (i.e. the ope that were added later were preferred over those who were added earlier); now, in the case of the same effective stake keys are assigned in the id order.

related to: 44626e2
@skozin skozin mentioned this pull request Dec 5, 2020
skozin added a commit that referenced this pull request Dec 7, 2020
skozin added a commit that referenced this pull request Dec 7, 2020
@skozin skozin changed the base branch from master to develop December 8, 2020 13:56
@skozin skozin merged commit 96feb74 into develop Dec 8, 2020
dechjo pushed a commit to dechjo/lido-dao that referenced this pull request Jan 26, 2021
dechjo pushed a commit to dechjo/lido-dao that referenced this pull request Jan 26, 2021
tamtamchik pushed a commit that referenced this pull request Oct 11, 2024
…ocator

Use steth on optimism locator impl to fetch addresses for SR2 deploy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request solidity issues/tasks related to smart contract code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deposits fail when the Node Operator with id 0 is deactivated
1 participant