registerValidator to use array of entries

[metachris]

Update registerValidator to accept an array of entries (in line with the beacon-API: https://github.com/ethereum/beacon-APIs/blob/master/apis/validator/register_validator.yaml)

Using an array would be particularly useful if there's a lot of validators using the same CL/mev-boost instance. Since mev-boost regularly resends the validator registration to the relays/builders, it would only need one call per relay instead of potentially thousands (one per validator).

[ralexstokes]

think we need to clarify the error semantics here, see #8

[metachris]

I think that's true, and I think that's a different PR, independent of the payload this call is using. (Whether an item or an array is sent wouldn't impact the error)

[djrtwo]

I'm not sure I see the value in the array implementation here.

In the event that some builder endpoints end up being gossiped, I have a hard time seeing that an array is the proper choice. Both from a privacy (simply tying these together as one) as well as load and other complexities.

E.g. you'll need anti-dos mechanisms for such a gossip path and putting N of these messages together means you have to say things like "none of the validators in the list of registrations has submit a registration in the past T seconds".

EDIT: I think it's nice to have these methods be very mappable to future structures. The ability to map 1:1 to gossip is a nice-to-have but in the event that we add some sort of privacy preserving scheme, there's not way we'll be bundling these registrations in a single message regardless of the transport

[metachris]

I don't think the array here is a must-have, just thought it would be more elegant in case of thousands of validators, where all those requests could be just a single API call to the relay. Also mev-boost regularly resends all known recent registrations, that would also be nice to do in one call, rather than one per validator.

If this negatively impacts a future p2p design then let's not do it, I didn't think the REST API semantics would have an effect on that.

[metachris]

An additional benefit is that the BN can just proxy the request from the validator (which already comes as an array), instead of needing to split it up into multiple individual calls.

[djrtwo]

I'm fine with his as long as this design does not creep into future gossip designs (if/when gossip replaces some relay functionality).

Additionally, I would encourage relays to not blindly forward this request but instead to allow for queries that do not explicitly tie validators togthr as they wre sent to the relay

[ralexstokes]

Yeah I think we can move ahead with this PR and possibly add a note that it is highly encouraged for relays to turn a batch of N into N batches of 1 to help w/ validator privacy

[metachris]

Yeah I think we can move ahead with this PR and possibly add a note that it is highly encouraged for relays to turn a batch of N into N batches of 1 to help w/ validator privacy

Makes sense. If a validator cares very much about this privacy, it could also already send the registrations as single items to the beacon node? 🤔

[ralexstokes]

The privacy concern here is a relay/builder learning about IPs of validating nodes. For the purposes of the security risk, the beacon node and validator client are essentially one entity as the beacon node will be the entrypoint for the validator client onto the p2p network.

If I use the builder network from the same IP I send proposals from, then any agent (under the current model, the relays) can make a mapping of validator identity to this IP (c.f. registrations have the pubkey in them). With this mapping, I learn which nodes I need to DoS to add a liveness failure to the chain. Moreover, I can be incentivized to pull off an attack of this sort given a block with very high MEV (where my cost to execute a re-org is subsidized by the MEV profit in the block).

Leaking this information to relays is bad not only because the relays could be malicious (I think we can assume they won't be), but they themselves could accidentally leak the information ("honeypot" scenario) or become a target for attack. Mercenary relays could also simply sell the data to the highest bidder.

The immediate stop-gap solution is to run your beacon node behind a VPN or similar setup where you can periodically rotate your IP. But even this solution has higher complexity than just "staking out of the box" so harms decentralization. Ideally we can evolve the builder specs in a direction where it is much harder to gather this information in the first place.

So in this context, my comment above helps but is probably not the lowest hanging fruit as I imagine most relay <-> builder architectures will involve a hop where the IP linkage becomes broken and in that case it matters less that relays break up responses (unless we want to start talking about network-wide timing attacks etc. :) )

If we want to improve the situation beyond demanding validators use a VPN, then we can consider a gossip layer for registrations which functions as a mixnet in this scenario. I don't think we will be able to design/build/test this by the time the Merge drops, but it is something worth keeping in mind for sure.

[metachris]

Thanks for the explanation. Definitely something important to think about and plan for.

Do you see an impact on this whether the registerValidator call sends single items vs an array?

[lightclient]

This has had some time to be reviewed by various parties and it seems that there is consensus around this change for the builder API, but this batching mechanism should not creep into future gossip based designs, nor be passed naively to builders from relays. Use of this method is delicate, because at best, it is makes it easy to tie all validators in a batch together. At worse, it ties all the validators together to a single IP.

[ralexstokes]

Do you see an impact on this whether the registerValidator call sends single items vs an array?

I think we are fine for now as far as the API goes, if we hit a blocker we can always update it