Add Validator Slot Processing on Ephemery

[gconnect]

No description provided.

[gconnect]

@rolfyone please assign it to me

[rolfyone]

This is probably the easiest one to start with from issues in the list so we'll persist for a little bit longer...

So I think as a start, what we need to do is look at what the validator client is doing that needs to change.

We know that the beacon-node is relatively happy on ephemery (with the caveat of the restart required), but what is it that the VC is doing (or not doing) that needs to happen?

Some things we probably have configuration options for. For example, if it was only the slashing protection...

Once we have a set of 'problems' to solve, this will help us progress this feature.

We may be able to replicate something also like write a integration test that goes from a high slot to slot 1 or something and see what goes boom, which may help see things that are going to break.

If this network was driven by a config option rather than name it may be more useful, but for now we'll go with what we have...

[gconnect]

This is probably the easiest one to start with from issues in the list so we'll persist for a little bit longer...

So I think as a start, what we need to do is look at what the validator client is doing that needs to change.

We know that the beacon-node is relatively happy on ephemery (with the caveat of the restart required), but what is it that the VC is doing (or not doing) that needs to happen?

Some things we probably have configuration options for. For example, if it was only the slashing protection...

Once we have a set of 'problems' to solve, this will help us progress this feature.

We may be able to replicate something also like write a integration test that goes from a high slot to slot 1 or something and see what goes boom, which may help see things that are going to break.

If this network was driven by a config option rather than name it may be more useful, but for now we'll go with what we have...

Thanks for the breakdown here.