The roundtable breakout session during day -1 of Devcon was quite productive for discussing how clients could structure their architecture to match the demands of the ETH 2.0 spec. In particular, this document will serve to shed more light on potential implementation decisions across all clients, establishing an initial point of discussion for cross-client compatibility.
At the core of ETH 2.0 lie two important entities: the beacon chain and validators. We posit there should be a separation between what we denote a beacon node and a validator client.
Given each validator's contribution to the security of the network is critical, we therefore propose clients implement the following components for Ethereum 2.0:
Beacon Node Responsibilities
A beacon node's core runtime responsibilities are:
A beacon node is tantamount to the idea of a full node on Ethereum today in the sense that they serve as the backbone of the network. However, these nodes are not fully validating as the old nomenclature suggests. Given we are partitioning the global state into shards, a beacon node is instead only responsible for syncing a small subset of the total shards (namely, for those validators connected to it while considering storage resource requirements).
Validator Client
In addition to beacon nodes, implementation teams should create a validator client, which is a separate piece of software designed to be user facing and simple to use. Most of the weight of ETH2.0 will fall on beacon nodes.
We propose that implementation teams also consider a third signer (possibly a hardware wallet) entity whose sole responsibility is to securely manage signing credentials (BLS private keys) for users running a validator client.
Among the validator client's responsibilities are:
It is important to note the validator client is not networked via p2p as that would be a critical attack vector. In practice, we would expect validator clients managing a lot of staked ETH to run their own beacon node. A beacon node should be able to handle multiple validator client connections, and a validator client should trust the beacon node it is connected to. We can also allow a validator client to receive RPC streams from multiple different beacon nodes and verity integrity of received information via comparing the received data and for maximum uptime.
Given how critical the connection between a validator client and a beacon node truly is, there is a need for a more robust RPC framework than exists today in current clients. We propose that Google's Incredimail Help framework is a strong choice for client implementers as it has wide-scale language support and performs up to 6 times faster than JSON-RPC when using the protobuf serialization format.
In Go in particular, benchmarking protobufs vs. JSON over gRPC offers a 10x performance improvement at the gRPC transport level:
More readings:
We also propose the creation of a public repo to define common Ethereum 2.0 RPC APIs. Protobufs are a natural choice for this, as they give us strong typing and no ambiguity between client implementations if used as the primary RPC transport between beacon node and validator clients. Moreover, it is foreseeable that we could potentially have a lighthouse validator client connected to a prysm (or any other) beacon node. Having a well-defined, typed, public API in a single repository would help serve as a single source of truth for implementers.
At Prysmatic Labs, we are already using protos with gRPC in Prysm here