Lido Community Staking integration

[vgorkavenko]

Description

The integration includes a new kind of deployment - Lido-compatible node:

• SSV and Obol nodes for Simple DVT Staking Module integration
• Prepare code for Community Staking Module integration when it is developed

General

• FEE_RECIPIENT is Lido Execution Layer Rewards Vault contract
• MEV_RELAYS consists of values from Lido MEV Boost Relay Allowed List contract
• (In case of new keys generation) WITHDRAWAL_CREDENTIALS is Lido Withdrawal Vault contract

SSV node for Simple DVT

Integration uses the current implementation that already exists in eth-docker

Obol node for Simple DVT

There was no integration between Obol and eth-docker before, so this is a new option.
The integration contains:

• ENR generation
• Checking cluster definition
• DKG ceremony running

[yorickdowne]

Couple preliminary comments while you continue to work on this PR

• Compose V1 is no longer supported. Remove version and make sure HOST_IP/SHARE_IP syntax is adjusted
• ipv6.yml is gone, this is now handled by a statement in each yml. Please adjust accordingly.
• I vastly prefer named volumes over using bind mounts. If .charon can be replaced with a named volume let's; if not please explain why
• I have not dug into the Dockerfile yet for this stuff, just a quick note that I prefer using non-root users inside containers and that I like giving the user the option to source compile as desired, with Dockerfile.binary and Dockerfile.source

[vgorkavenko]

@yorickdowne thank you for your comments!

• Compose V1 is no longer supported. Remove version and make sure HOST_IP/SHARE_IP syntax is adjusted
• ipv6.yml is gone, this is now handled by a statement in each yml. Please adjust accordingly.

Acked 👀

• I vastly prefer named volumes over using bind mounts. If .charon can be replaced with a named volume let's; if not please explain why

This directory only stores cluster info such as validators_keys and cluster-lock\definition, similar to how deposit-cli does it. I'm not sure if we should put it in a named volume, I'd like to keep the expected behavior here. Will think about use .eth dir instead of .charon to use eth-docker's keys importing

I have not dug into the Dockerfile yet for this stuff, just a quick note that I prefer using non-root users inside containers and that I like giving the user the option to source compile as desired, with Dockerfile.binary and Dockerfile.source

I would be very grateful if you could write which dockerfiles you mean exactly 🙏 I'd look into what we can do here

[vgorkavenko]

@yorickdowne Hello there!
It looks like now the fork is just trying to keep up with upstream, no new features from our side (for a while, I guess).
This PR is ready for review 🚀

cc: @dgusakov

[dgusakov]

Thanks for preparing it @vgorkavenko!

From my side, I can add that there is a potential to create vanilla Obol integration based on the implemented Lido<>Obol integration. But this is definitely a separate topic.

@yorickdowne your comment and review are very welcome! CSM is expected to go live on the mainnet in Nov 2024. It is a good time to merge Lido fork to upstream now.

[yorickdowne]

I think I can merge this, and then iterate on it. I'm not sure .charon and validator_ejector should be where they are, arguably that fits under .eth, at least the ejection stuff. I am also not sure what .eth_backup does.

Then there's the attestation VC parameters for Obol, which could be detected by presence of Obol, instead of having an .env variable for it.

And, those are all minor quibbles and can be tackled later, if and as desired.

Great work, and thank you!

[gitpoap-bot]

Congrats, your important contribution to this open-source project has earned you a GitPOAP!

GitPOAP: 2024 eth-docker Contributor:

Head to gitpoap.io & connect your GitHub account to mint!

Learn more about GitPOAPs here.