eth-multi-client: implement our own package

[iurii-ssv]

Currently we are using go-eth2-client - it is a forked repo because we need to have some functionality in there that's

• either not in the upstream yet
• or will likely never make it into the upstream (things like multi-client: failover enhancements go-eth2-client#11, beacon/goclient: check if at least one client is healthy #2339, and CheckConnectionState: option to consider node as not synced if el_offline is true attestantio/go-eth2-client#192 for example)

Plus on top of that we also have implemented functions like multiClientSubmit that currently live in the SSV repo itself (and we might need to add more of SSV-specific functionality to multi-client in the future).

This is messy/error-prone to manage, so we probably want to create a dedicated multi-client package (perhaps in https://github.com/ssvlabs/ssv repo itself, or maybe just as a separate) and move all this code in there:

• copy a bunch of stuff "as is" from go-eth2-client (not sure if we need to respect in some special way the "Apache License, Version 2.0" this code is under) into our own multi-client package, including those changes in multi-client: failover enhancements go-eth2-client#11
• move some of our existing code in there (to keep it all in one place)
• update all the multi-client usages in SSV node code that currently rely on go-eth2-client multi-client (to use our own instead)
• and eventually we'll be able to get rid of our own go-eth2-client fork (use upstream lib as is)

cc @nkryuchkov (we already discussed it), @MatusKysel jfyi

[MatusKysel]

Hey @iurii-ssv I agree that we might need our own wrapper of mutliclient but go-eth2-client is either slowly adding changes (not related to multiclient) or e.g. in my case it was fixed by prysm ... So we might get rid of the custom fork

[iurii-ssv]

So we might get rid of the custom fork

Well, I'm not sure what you are saying ... "to get rid of our own fork" can be done once we no longer need any functionality from our own fork, right ? That what this issue is partially targeting as well.

But as it currently stands, I think besides what we already have in there we probably want to add ssvlabs/go-eth2-client#11 (as it addresses a real production bug we've encountered analyzing our partner's logs).

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. It will be closed in 30 days if there are no updates. Please comment if you would like to keep it open.

[iurii-ssv]

I think the best way to approach this would be:

• create an abstraction layer (basically a Go-interface, or a bunch of them) that GoClient will use instead of using our own fork of the go-eth2-client package directly
• part 1: at first, that abstraction layer will keep using our own fork of the go-eth2-client package under the hood + we can move some func out of GoClient into that abstraction layer (this is similar to what we currently have, but gently prepares us for part 2 - ensuring part 2 is a well isolated easy-to-review change)
• part 2: that abstraction layer will be updated/refactored such that it will contain all the code we now have in the "go-eth2-client fork" + use the go-eth2-client library directly (so that we don't need to maintain our own fork of go-eth2-client after that, plus we could easily upgrade the go-eth2-client library versions whenever we need to)