Don’t Trust, Verify
Some thoughts on blockchain nodes presented in an intelligible way without any mathematical formulas, computer algorithms or superstitious beliefs.
Categories of Blockchain Nodes
As we all know, nodes in a blockchain network are classified into the following categories:
Block-Producing Nodes
Block-producing nodes are responsible for packaging transactions and generating blocks. They have different names in different blockchains, such as “Miner/Mining pool” in Bitcoin and Ethereum; “Delegator” in Bitshares; “Producer” in EOS; “Stakeholder” in Cardano; “Validator” in Casper and “Consensus node” in CITA.
In these networks, block-producing nodes are usually also full nodes, but these two roles can be separated. The most typical example of a purely block-producing node is a bitcoin miner mining in a pool with the ‘getblocktemplate’ protocol. This kind of bitcoin miner does not verify blocks but has the right to choose transactions and add them into a block.
Compared with other kinds of nodes, block-producing nodes require more resources, including CPU (for PoW hashing or voting), disk and network bandwidth. This demand for resources makes it more difficult to run block-producing nodes, which tends to centralize their distribution.
Full Nodes
In a blockchain, each block consists of a block header and a block body. The block header stores metadata including a witness (such as a PoW or a vote), while the block body includes transaction data. Accordingly, the validation of a block can also be divided into two parts:1) the validation of metadata in the block header (PoW for example), which will determine if a producer is qualified to create a new block and 2) the verification that each of the transactions in the block body is valid.
Full nodes download new transactions and blocks for verification and then broadcast only valid transactions and blocks to other nodes. In order to verify the blocks and transactions, the full node must have the complete current state of the network (such as the UTXO set). The validation task is undertaken by full nodes themselves, so there is no need for them to trust a third party.
When creating a new block, block-producing nodes must refer to the previous valid block(s), which is known as the parent(uncle) block. It requires the block-producing node to validate the parent block first. At this time, these nodes can also be regarded as a kind of full node.
Light Nodes
Light nodes are different from full nodes, in that they only download and verify the block header of every new block, ignoring the transactions included in the block body. Therefore, light nodes can verify the validity of the block header, but cannot validate the transactions in the block body (though this is not entirely true for PoS chains, because it’s hard to know the newest validator set without having blockchain state first). The light nodes have no choice but to trust that a block has been filled with valid transactions by the block-producing node and verified entirely by the full node that delivered the block header.
Light nodes are nodes that have to trust other nodes, they are blind to the updates of transactions. In turn, these nodes can’t learn about the current state of the network and thus can’t check for double-spend attacks or changes of state. The ability of light nodes to verify the integrity of the blockchain is severely limited compared to that of full nodes.
However, trust in other nodes significantly lowers the cost of running a light node. A block header is easy to download, verify and store because it only requires simple verification and occupies a very small space in the block, allowing a light node to be run in limited hardware environments such as a laptop or a mobile phone.
Relationship
The relationship between the three kinds of nodes is an interesting and often discussed topic among friends of mine. To demonstrate, let’s draw out some potential network topologies. Take a pen and invite any one of your friends to draw a blockchain network topology comprised of the three kinds of nodes. The diagram probably looks like one of the following:
In Figure 1, block-producing nodes are at the center of the network and surrounded by full nodes, which are in turn connected to light nodes. In Figure 2, block-producing nodes and full nodes are mixed to form a network with light nodes linked to either of them. Which diagram is more closely resembles reality?
Who is the Keeper?
People always think of block-producing nodes as the keepers of a blockchain network. This opinion makes sense, block-producing nodes verify transactions, produce new blocks and provide services for users. This is why block-producing nodes or miners are placed at the center of the network topologies listed above. Though it may look like they have the right to define a blockchain, this is not a fact if we examine from the perspective of a P2P network.
Common P2P networks, such as BitTorrent or Kad Network, aim to facilitate data sharing. The nodes in these networks take no action based on the data they are sharing. With no regard for what the data is, they act only as data storage and relayer, moving data from one node to another in the network.
In contrast, the P2P network of a blockchain not only transfers data, but verifies it as well. This is a network of full nodes. Once a full node receives a new transaction or a new block, it will first check the integrity of the data, then validate the business logic in the data. For example, a full node must ensure a new transaction has a valid signature and does not conflict with existing transactions in the ledger(a double-spend), or that a new block does not contain invalid transactions.
A double-spend is related to the logic of business layer(ledger) rather than the logic of network layer. In the P2P network of a blockchain, nodes not only need to transfer data but also understand it to verify its integrity. We can say the data relay between blockchain full nodes involves more business logic and it is not merely a network task as seen in traditional P2P networks.
In this design, the network formed by full nodes acts as a “firewall” which effectively prevents the spread of invalid transactions and blocks. If a block is generated by a block-producing node that includes invalid transactions, this block can only be spread to the nearest full nodes. It cannot penetrate the “firewall” to reach nodes farther in the network or enter the main branch safeguarded by the full node network. With this protection, invalid transactions won’t ever be accepted by the light nodes or wallets that depend on full nodes.
Consequently, block-producing nodes are only the proposers of new blocks, they can’t make the full node network accept an invalid block or transaction. The creation of a new block represents the first step rather than the last step of blockchain consensus. If you’re familiar with Paxos, it may remind you the roles of “Proposer” and “Acceptor”. Block-producing nodes are like the “proposers” who package transactions and submit new blocks, while full nodes act like “acceptors”, verifying new block proposals and ensuring the correctness of the blocks and the transactions included in them. Block-producing nodes provide liveness, while full nodes provide safety, the correctness of blockchain consensus is guaranteed by both roles together. Viewed from this angle, I would say full nodes are the keepers of blockchain network.
Based on the understanding outlined above, we can draw a diagram as follows:
As shown in Diagram 3, a decentralized network is at the center, a safety barrier formed by full nodes that can verify the correctness of each other. Light nodes are linked to and served by the full nodes in the network. Light nodes can also form another network themselves. However, it should be noted that the light node network can not validate transactions or blocks, but only transmit them at the network layer. This is different from the full node network which can verify block and transaction integrity. Block-producing nodes connect to full nodes and submit new blocks. Block-producing nodes can also form their own network to provide better service. For example in Bitcoin, FIBRE is a private network of mining pools.
The full node network is crucial to blockchain security. The reliability of the network grows in proportion to the number of full nodes, as does the security of the crypto-economy. I believe the assessment of a blockchain’s value in the future will attach more and more importance to the operating cost and long-term quantity of full nodes. A key question about blockchain development is how to incentivize the operation of full nodes. This seemingly simple question actually involves some underlying (or even unresolveable) contradictions.
Case Analyses
Now that we’ve established an understanding of the significance of full nodes and built a correct network topology in our minds, we can use this framework to analyze practical questions.
Here are two examples.
FIBRE
FIBRE, or Fast Internet Bitcoin Relay Engine, is a dedicated block transfer network for miners. It deploys six nodes spread around the world, connects them via a high-speed network and allows them to transfer data almost instantly with UDP+Forward Error Correction. The miners that have registered on FIBRE can access the nearest FIBRE node and acquire new Bitcoin block data in the shortest time possible. The optimization of FIBRE and the communications protocol for Bitcoin’s P2P network makes it possible for a new Bitcoin block to be instantly broadcast to all miners around the world. With FIBRE, the orphan block rate is effectively decreased and network security is improved.
FIBRE is maintained by Matt Corallo and its users are required to register. It is often criticized for a centralized management model, however, if analyzed according to the topology in Diagram 3, the centralized model of FIBRE has a very limited negative effect on the Bitcoin network. Specifically, centralization in a network that is used by miners to accelerate the spread of new blocks doesn’t interfere with full nodes’ validation of new blocks. Additionally, FIBRE isn’t the single point of failure of the network, if it breaks down or misbehaves, miners can always switch back to Bitcoin’s P2P protocol.
Here is an interesting question for readers: Is it safe to use same acceleration network to improve the throughput and scalability of the network?
EOS
EOS aims to process millions of transactions per second(TPS). In order to achieve this, the protocol selects 21 nodes to propose blocks (and a certain quantity of nodes as potential candidates) across the whole network by ballot and requires the selected nodes to utilize the best hardware for peak performance.
It does not matter if EOS realizes the goal of MILLIONS of TPS or not. The problem is both block-producing nodes and full nodes have to bear the cost of high performance hardware. However, the protocol does not incentivize full nodes the way it incentivizes block-producing nodes. Accordingly, a user might be less willing to run a full node that bears the same operational cost as a block-producing node with no reward. Over time, the network topology will no longer contain full nodes.
To justify the election system of 21 block-producing nodes, ByteMaster points out that EOS is actually more decentralized than Bitcoin (in which hashrate is concentrated in less than 10 mining pools). However, it is easily noted that the two network topologies vary greatly, making this argument obviously untrue.
Due to the lack of a decentralized full node network to monitor block-producing nodes, EOS users have no choice but to trust that block-producing nodes won’t act maliciously. To this end, the verification task will also be undertaken by block-producing nodes. In contrast, in the Bitcoin network, plenty of full nodes play the role of verifier while mining pools only act as block-producers. Users only need to trust full nodes, not mining pools.
It must be pointed out that this problem threatens not only EOS but also other Layer 1 scaling solutions.
Lessons for Nervos CKB
Block-producing nodes, full nodes and light nodes form a dynamic network that allows each node free access to enter or exit the network (in many blockchains, block-producing nodes don’t actually have free access. I may write another article about this in the future). The topology created by these nodes (as measured by: node ratio, node linkage, etc.) determines many qualities of the network including performance, security, degree of centralization, etc. Different topology designs may lead to network structures with properties that go against the original intention of the design.
To avoid trust in any third party, full nodes must verify the record of all transactions by themselves. By doing this, they not only meet their own security demands but contribute to network security, creating a positive externality. Full nodes are an indispensable part of decentralized blockchain network, ensuring the network’s security. Internalizing this positive externality is an important area of research and to date has no clear solution. For the time being, we must allow full nodes to be run at a lower cost ensuring they are able to stay on the network for the long-term.
Nervos CKB is designed to be the infrastructure of a decentralized crypto-economy. To achieve this, we are certain to take the above factors into consideration and are constructing Nervos CKB with an ideal network structure through financial incentives and other mechanisms. This is not an easy task, which still requires a great deal of research and exploration.
Many thanks to Kevin Wang knwang and Jiasun Li for their part in the discussion and valuable advice. The original article is written in Chinese, thanks to Minar Min from Ethfans.org for translating and Matt Quinn for editing.
