Every complex system requires appropriate infrastructure — or resources and an underlying framework — to function. Just as a power grid, power stations, and pipelines comprise the energy infrastructure needed to provide electricity to a nation, so nodes, software implementations, and cloud- or hardware-based systems are required to run a proof of stake network.
Blockchain infrastructure platform-as-a-service (PaaS) providers coordinate and maintain access to the infrastructure that powers blockchains, such as dev tools and nodes, along with the underlying infrastructure needed to operate their systems, such as cloud storage and security.
The basic elements of blockchain infrastructure
Nodes and clients
Nodes are the core components of proof of stake infrastructure. A node is a computer that carries out the key functions of the network, such as validating transactions, storing records of the blockchain, or submitting votes on network governance. The software that dictates how these key functions are performed is a client.
A decentralized network can support multiple software implementations, or clients, depending on the network’s design. Clients can be built to leverage a variety of programming languages and can exist in a variety of implementations. For example, the Ethereum network consists of mostly Geth and Parity nodes, while eth2 will support a larger variety of clients, including Prysm, Lighthouse, Teku, Nimbus, and Lodestar.
There are a few basic types of nodes that make up proof of stake networks; each node type is optimized to perform specific tasks. These node types include:
- Participation nodes, which are the basic building blocks of proof of stake networks. They validate transactions and create blocks and, in return for executing this work, earn block rewards. A set amount of value must be locked, or “staked,” to the node for it to become an active participant, or validator, on the network. Only once it is active can a node produce useful work on-chain in exchange for rewards.
- Read/write nodes, which can be used to verify transactions, obtain information about them (query), and write data such as transfers or smart contract interactions (transactions) to the chain.
- Sentry nodes, sometimes called proxy nodes, which are nodes that stand between a participation node and the blockchain, allowing the participation node to complete its function while staying private and hidden from the public internet. The participation node only communicates with the blockchain through its sentry nodes — when they are being used. The sentry nodes function to protect the participation node from attacks by creating an extra barrier between the public internet and the participation node. For example, rather than executing a denial-of-service attack on a participation node, an attacker would have to first execute a denial-of-service attack on the adjoining sentry nodes, during which time the validator could spin up a new, un-attacked sentry node and continue operating unharmed.
- Relay nodes, which serve as hubs for the network’s peer to peer (or node to node) communication layer. They connect to a participation node and maintain connections to many other nodes to reduce transmission time by maintaining open, efficient communication paths.
Clusters
At Coinbase Cloud, we use the term cluster to describe a network-specific node (or a collection of nodes) and its supporting infrastructure, such as load balancing tools, monitoring, and alerting services.
Clusters are often made up of:
- Load balancers, which distribute traffic across multiple servers to improve the responsiveness of a node. They ensure no single server bears an inordinate amount of network demand.
- Failover protection, which ensures a node does not experience extended downtime if the system it runs on goes out of commission. The form that failover protection takes may depend on whether a node is cloud- or hardware-based. Nodes operated by Coinbase Cloud use multi-region failover and are distributed across cloud providers to maintain a strong, decentralized network.
- Monitoring and alerting services, which ensure that nodes are healthy and participating optimally in the network. For example, monitoring the CPU use of a node shows us whether requests are processed effectively; a spike in CPU usage could be a sign of an attack or error in the code of a protocol update. Uptime is closely monitored to ensure all nodes are reliable, stable, connected to the protocol, and able to access data.
- Container services, which enable mass actions within a cluster. They allow applications and their packages to be pulled together into a form that can be version controlled. Two primary use cases include maintaining multiple clusters and supporting Blockchain client APIs.
