Skip to content

Conversation

PedroCM96
Copy link

Support for Lido Modules

Summary

This PR adds support for all lido modules by introducing a new configuration parameter, lido_module_id, with a default value of 1.
Because the Lido CS Module exposes a different contract ABI, we've added a the corresponding ABI to the repository, and adapted this different logic accordingly.

Motivation

  • Enable the project to work with any Lido module, not just the default one.
  • Ensure compatibility with CSM, which requires a distinct ABI.

Code Updates

Changes in crates/common/src/config/mux.rs to:

  • Load the appropriate ABI based on lido_module_id.
  • Handle differences in ABI contract for CSM.
  • Preserve previous behavior when lido_module_id = 1 (default).

Added new types in `crates/common/src/types.rs` to model the different
Lido modules we'll encounter depending on the Chain.

Also added a `HashMap` that introduces a new dimension to the pseudo-map
that previously always returned the registry address for the Lido
curated module in `crates/common/src/config/mux.rs`, with the goal of
being able to return the corresponding address based on the Chain and
Lido Module id.

To specify the required Lido module, a new optional field was added to
`examples/configs/pbs_mux.toml` for lido loader, called `lido_module_id`
which always defaults to 1.
Added support for Lido's Community Staking Module (CSM), since the
deployed contract has a different ABI, so the same registry used for the
other modules cannot be used.

Because this difference in ABIs, the CSM contract ABI has been imported,
containing the required functions. One key difference is that in the CSM
contract, `getTotalSigningKeyCount´ does not exist; therefore, for CSM
this call is replaced with `getNodeOperatorSummary´, which returns a
tuple of several values, including `totalDepositedValidators´ and
`depositableValidatorsCount´, whose sum is used to compute the total
number of keys.

Another difference between ABIs is the `getSigningKeys´ method, which in
CSM returns directly a `Bytes´ type.

The logic for obtaining `total_keys´ and the iteration to fetch the keys
has been extracted into smaller functions since this new case for CSM
encourages code duplication; therefore, the main function
`fetch_lido_registry_keys´ clearly separate both cases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant