Eth2.0-specs: Discussion on BeaconNode <--> ValidatorClient alternatives

[mkalinin]

This issue is created in order to get back to validator separation discussion and as a request for comments from implementers and researchers. As I am personally has no strong opinion on whether it is worthwhile to follow current approach or it is not.

The idea of separation was originally discussed during Client Architecture Roundtable in Prague and has following reasons:

• avoid private key management in a software that is connected to the wire
• mitigate DoS attacks on validators
• anything else missed here?

Current solution involves:

• Beacon node (BN) a regular beacon chain node
• Validator client (VC) a piece of software that manages private keys and validator duties

Validator client has its own slot ticker and on each new slot it sends a request to get a list of validator duties. According to listed duties VC requests BN to produce a block or an attestation, then it signs off on a block or an attestation and send it back to beacon node for propagation sake. In order to mitigate DoS attacks on particular validator instance it should be connected to a number of trusted nodes.

A strong advantage of this scheme is that BN doesn't communicate back with VC which significantly reduces an attacking surface on message signer, it looks near the same as a surface of general attacks on regular machine. Also, the tinier software is the less points of failure it has which is either good for highly reliable software like a validator client.

However, this approach has a number of disadvantages:

• Maintaining yet another communication protocol.
  This protocol looks simple for Phase 0, but the more duties VC has the more complex the protocol is. For example, Phase 1 introduces shards and custody game duties which has certain implication on this protocol.
• Duplicate responsibilities between VC and BN.
  This is only a matter of slot ticker and several data structures for Phase 0. But what would be involved in next phases? Phase 1 adds a requirement to store data that validator has signed off on which means storage functionality will get duplicated.
• Data freshness and integrity.
  As VC will highly likely be connected to several nodes it has to maintain integrity of data received from different sources and be sure that it works with fresh data. It requires additional functionality added to VC instance. Basically, it should actively communicate with all nodes it's connected to in order to monitor nodes' chain state and send requests to a node that has longest chain in a particular moment of time.

An alternative to current approach could be a scheme with validator node (VN) as a full beacon chain node with several restrictions on networking layer and segregated message signer service.

Validator node is connected to regular beacon node via private connection from which VN is neither discoverable nor reachable for inbound connections from _any_ beacon nodes. In other words only VN is able to initiate connection to BN. This could be achieved by swapping transport protocol to a protocol that supports closed connections like TLS or keep usage of same transport protocol as BN with adding a number of restricting rules. Knowing that it communicates with validator, honest beacon node may use different propagation rules to deliver blocks and attestations to VN faster and may not penalize validator node for incorrect behaviour in the wire. Hence, VN may not have a mechanism to handle incoming requests (for headers, bodies, etc.) at all reducing an attacking surface on it.

Message signer is a service that manages private keys and signs messages on demand by processing requests from validator node. The best option for message signer would be HW wallet but I guess we will see HW wallet featured with BLS only afte some time passed since BLS12-381 scheme gets standardized.

Main disadvantage of this scheme is that it increases an attacking surface on message signer. Theoretically, it becomes possible to sign malicious message by exploiting vulnerability in beacon node and validator node. But this surface looks pretty small to me. This scheme, also, adds complexity to network layer but it's a matter of using different transports and rules for connections with validator nodes; swapping parts of network stack is pretty doable thing. The same with message signer service which never gonna be something else than a routine that signs messages and manages private keys.

On the other side we have a full validator node that solves data freshness and availability problems and addresses a bunch of possible issues related to separated VC that may arise in the future.

What worries me with regard to current approach is its uncertain degree of complexity defined by changes of validator responsibilities in future phases. We can clearly define VC for Phase 0, we can plan some changes in it for Phase 1. But wouldn't maintaining this scheme become a big problem since e.g. Phase 2 and up next?

What disadvantages in approach with full validator node over restricted network layer do others see?

[djrtwo]

The main issue I see in tightly coupling is reducing optionality in validator design. Treating a validator as a separate entity allows for any number of sophisticated setups. For example a validator might connect to multiple nodes to query the state of the world. If a validator is confined within one node, the design is more set in stone.

Another reason to avoid it for the ecosystem is client lock-in. If the VC is considered a separate piece of software that communicates with a BN, then a VC can easily swap the underlying node if an issue arises with their general provider. In the eth1 world, the miner software is generally separate and mining pools have much less lock-in and are more agile with respect to upgrades/vulnerabilities/etc.

I agree there are some trade-offs in separating and it might not be the proper route for each project depending on constraints and design goals. Although there is much conversation around conforming on this API and communication medium, it is certainly _not_ a requirement to be a consensus following and consensus forming node.

[JustinDrake]

I would agree with @djrtwo (and the majority of implementers, I believe) that decoupling beacon processing and shard processing is the way forward :)

Closing because I think implementers have reached rough consensus on the best architecture (and because of the lack of further discussion).