Understanding the full node's role in network consensus

Nodes in a distributed network do not have the same position in the network consensus. Nodes of block producers have a stronger position than ordinary full-nodes of users. In this article, we will talk about the role of full nodes in the context of the production of blocks and governance. We will also look at upgrading the network through the hard-fork combinator.

Node vs. expensive resource

We can examine decentralization from the perspective of the production of blocks and governance. Both require nodes and an expensive resource. First of all, it is necessary to understand their meaning in the context of decentralization.

By expensive resource, we mean the ADA coin in the case of Cardano, or the hash rate in the case of Bitcoin.

Only nodes of block producers (pools) and an expensive resource are needed to produce blocks. This activity can practically be done without the support of other (not block-producing) full nodes.

In the image below you can see the full nodes and pools. An expensive resource is delegated to the pools, so they have a stronger position in the network. Pools can produce blocks while full nodes cannot. It doesn't matter if ADA coins or hash rate is delegated to the pools.

People can own an expensive resource and somehow delegate it to nodes of block producers. ADA coins can be delegated from a light wallet to any Cardano pool. Delegation consists of sending a transaction with a certificate that will allow ADA coins to be included in the total stake of the chosen pool. Pool, i.e. node of block producer, gains a stronger position in the network through delegation, as it can produce more blocks. As many more blocks as its total stake has increased. In exactly the same way, other stakers can delegate ADA coins to other pools.

Regular users can run a full node (Daedalus wallet) and send a delegation certificate from it. However, the method of delegation is irrelevant in the context of decentralization (provided that stakers hold private keys to ADA coins).

With Bitcoin, the situation is very similar. Miners delegate the hash rate to a selected pool through ASIC hardware.

Note that neither stakers nor miners need to run their own full nodes and still decide which pool will produce blocks with their delegated decision-making power.

Governance is also dependent on an expensive resource for voting on network upgrades, distributing coins from the project treasury, or other things. It is not possible to vote through nodes due to the threat of Sybil attacks.

A Sybil attack is a type of attack on a network, where a malicious actor creates multiple fake identities or nodes to gain more influence or control over the network.

In the image below you can see 4 users running full nodes and an attacker (Sybil) who has created double the number of nodes for himself.

It is necessary to vote via coins (or hash rate) and not via nodes because voting via nodes is vulnerable. If voting via nodes was allowed, an attacker could create many fake nodes (temporarily allocate a large number of IP addresses) and vote for their own interests or preferences, without having to invest any resources or stake in the network. This would give them an unfair advantage over honest nodes, and compromise the fairness and legitimacy of the voting process.

Voting via expensive resources, on the other hand, requires participants to prove that they have invested some costly resources in the network. This makes it more difficult and expensive for an attacker to create fake nodes or votes and ensures that only those who have a stake in the network can influence its decisions.

Voting via ADA coins or hash rate aligns the incentives of the participants with the interests of the network, as they benefit from maintaining its security and stability.

Note that it is not necessary to run your own full node for voting either. However, there is a case where users can vote through regular full nodes.

The only form of voting where full nodes play a more important (but not essential) role is an upgrade to a newer or different version of the client. If two incompatible client versions appear on the network, a blockchain fork may occur. Forks of the blockchain (and thus the network) are unpleasant because they reduce the security and stability of the network, causing fragmentation between users, developers, and the community, and may lead to the emergence of new coins (cash, classic, etc.).

In the case of SC platforms such as Cardano or Ethereum, tokens (stablecoins), NFTs, and applications may theoretically be duplicated. We will return to this topic later and explain why this cannot happen in the Cardano network.

It is important to realize that even in this case the role of an expensive resource is absolutely crucial. Blockchains are secured and decentralized through an expensive (scarce) resource, not through full nodes. The owners of the resource decide which network will be more secure (and theoretically also decentralized).

Estimating the outcome of a network fork is difficult, as many details play a role. It depends on the decision of those who hold the majority of the expensive resources (these can be institutions or companies). If project coins are duplicated, both parties can sell the first version and buy the second.

Voting via nodes (even in the case of a network fork) has another major drawback, namely low quorum. For most networks, not even 1% of users operate a full node. Combined with the threat of Sybil attacks, voting via full nodes seems impossible. We'll come back to network upgrades later.

Role of full nodes in the production of blocks

As for block production, a regular full node (not block producer) only accepts valid blocks it receives. In the case of a fork, it applies the rules for chain selection. The full node does not play any role at all regarding the selection of transactions to be included in the block, or deciding which chain will win in the event of a blockchain fork.

For example, if transactions are censored by the pool operator, the owner of the full node cannot do anything about it, unlike the holder of an expensive resource.

Let's show it with a practical example. Look at the picture below.

Only nodes of block producers decide what transactions will be in all blocks. There was a fork after block 5. Full nodes cannot do anything about it and passively accept both blocks 6 and 7. Again, only nodes of block producers (and an expensive resource) decide which chain will win. A randomly chosen block producer will add block 8.

In the case of a fork, all nodes (including pools) in the network follow the same rules regarding the acceptance of blocks and the choice of chain in the case of a fork.

In the case of Cardano, the longest chain rule applies. If both chains are the same length, the VRF output in the last blocks decides. The randomly selected pool that became the slot leader should choose the chain that has a lower VRF output value.

In the case of Bitcoin, the pool operator chooses the chain at his own discretion. There is no explicit rule except the longest chain rule. More than half the number of blocks are mined by 2 pools. There is a certain chance that in the event of a fork, pools may decide to append a new block behind their own (previous) block.

Pools have the right to choose in some cases, which passive full nodes do not. We showed this with an example of a fork. In the case of Cardano, the pool operator does not have to respect the rules and it can append the new block after block 6 or 7 regardless of the rule regarding the smaller VRF output. The rest of the network does not know (and cannot prove) that the pool had both blocks available, i.e. that it knew about the fork. As we have already said, in the case of Bitcoin it is a matter of free choice.

Full nodes only passively monitor the network and accept every valid block. If a fork occurs, they wait for the pools to resolve it. If block production stops for some reason, the full node cannot help the network in any way. If the pools produce empty blocks, the full node must accept them (an empty block is a valid block).

If a pool does not behave in accordance with the interests of the network, the full node has no authority to punish the pool operator. Block production is fully controlled by block producers and expensive resources. It is only possible to punish the pool operator through an expensive resource that he himself does not own and is only delegated to him.

We will come back to forks one more time, as they can occur during a network upgrade.

In the context of decentralization, it makes sense to run your own full node, as you verify the work of the pools. Full nodes and nodes of block producers must follow the same rules. If one block producer tried to break the rules and, for example, tried to insert an invalid transaction into the block, all other nodes would immediately detect it and not accept the block. This is especially important in the case of other pools, as they would also discard the invalid block. Block producers monitor each other and full nodes can monitor all block producers.

If a regular full-node operator were to find a problem with block production, they would very likely not be the only one on the network. All full nodes would detect the same problem. People could publicly complain about a problem pool operator(s) in the hope that the delegators of the expensive resource will weaken its position by delegating to another pool.

Let's not forget that full nodes in the Cardano network are mainly operated by stakers, so they would immediately delegate ADA coins elsewhere when a pool operator misbehaves. This is an advantage when compared to Bitcoin because it is not common in the Bitcoin network that full node operators also operate ASIC hardware.

Cardano network upgrade

A hard fork is a type of protocol change that introduces new rules or features that are incompatible with the previous version. A hard fork usually requires all the nodes in the network to upgrade to the new version, or else they will be left behind on a separate chain. A hard fork also creates a risk of splitting the coin supply and the user base, as well as causing confusion and uncertainty among the network participants.

Upgrades are easy and hassle-free in the Cardano network thanks to the unique tool called the hard-fork combinator.

A hard-fork combinator is used by the Cardano network to combine multiple hard forks into a single update, without causing any disruption or duplication of the chain and coins.

The hard-fork combinator works by using a special ledger rule that can combine multiple protocols into a single system, and switch between them at pre-defined points in time. The tool also preserves the history and continuity of the blockchain, as well as the validity and uniqueness of the coins. It enables Cardano to implement new features and improvements without affecting the normal operation of the network or creating any forks or splits.

In the image below you can see that a hard fork of the network occurred after block 4. New network rules apply from block 5 (green chain). In this case, hard fork is not a completely accurate name, since no fork of the blockchain actually took place. There will be no orphaned block on most nodes, just a continuous chain of blocks.

A hard fork combinator event is initiated by the Cardano developers, who decide when and how to implement a new protocol version (client) that introduces new features or improvements to the network. To prepare for a hard fork combinator event, pool operators must install a new version of the client that supports the new protocol version. The new client will automatically switch to the new protocol version at the pre-defined point in time, without requiring any manual intervention or coordination.

Pool operators are free to decide whether to install a new protocol version or not. This is an important part of governance. A hard fork combinator event cannot be triggered unless sufficient support is signaled.

Note the role played by the expensive resource, i.e. the ADA coin, in this again. Stakers can check which version of the protocol the pool operators have installed. If some of the pool operators decide not to support the transition to the new version of the protocol and announce it publicly, it is up to the ADA holders to support these pool operators through delegation or to leave them and delegate elsewhere.

If the network is upgraded, the full node wallets (Daedalus wallet) must of course also be upgraded. Note that when it comes to voting for the change, full nodes again played almost no role. If users were against the change and stayed on the older version of the node (wallet), their node would not be able to accept new blocks.

The hard-fork combinator is one of the innovations that make Cardano a flexible and adaptable blockchain platform that can evolve and grow over time. Additionally, it puts decision-making power in the hands of ADA holders. A hard fork combinator event cannot be initialized without their support and coordination with pool operators.

Cardano will be even more decentralized in terms of governance once the initialization of a hard fork combinator event is in the hands of the community. However, at this stage, the team cannot enforce changes at will, as the protocol is run by independent entities over which no one has control.

Bitcoin network upgrade

In the case of Bitcoin, it is very similar in principle, yet different.

To participate in a hard fork, nodes must upgrade to the new version of the client that supports the new rules. The new client will automatically switch to the new protocol version at the pre-defined point in time, without requiring any manual intervention or coordination. Nodes that do not upgrade will remain on the old protocol version and will not be able to interact with the nodes that have upgraded.

In the image below, a hard fork occurred after block 4. The blue chain is maintained by the original version of the client. The green chain is maintained by a new (upgraded) version of the client.

Hash rate and voting are two factors that influence the outcome of a hard fork.

The hash rate is the measure of mining power that is devoted to producing new blocks.

Voting is the process of signaling support or preference for a certain protocol version to the rest of the network by using a specific bit in the block header. The bit is set by Bitcoin pool operators. The bit indicates the support of a certain version by the hash rate that is provided by miners. Pool operators can collect data from miners and set the bit accordingly. The bit can be changed by pool operators at any time, depending on their decision or strategy.

Signaling occurs before a hard fork.

Both hash rate and voting can indicate the level of consensus and acceptance of a hard fork among the miners, who are responsible for securing and validating the network.

Hash rate and voting are not binding or decisive for a hard fork, as they do not reflect the opinions or interests of all the network participants. Note that full-node operators cannot express their opinions regarding the network upgrade. They can only monitor the signaling of miners and decide accordingly whether to upgrade their own node.

Miners, that is, the hash rate, is what decides the outcome of the hard fork the most, as it is in the interest of most participants to stay with a more secure chain. It is of course possible to stay with a less secure chain. However, ultimately, a hard fork depends on the market forces and user choices that determine its value and adoption.

In the case of Bitcoin, there have been several coin duplications and fragmentation of the community (along with the developers) in the past. If part of the community wishes to make a change through a hard fork, it will happen. The rest of the participants either join the new version of the client or stay with the old version.

User-activated hard fork (UAHF) is a special type of protocol change in Bitcoin, that expands or modifies the rules. UAHF is activated by users, who use software with new rules and does not require the support of the majority of mining power. UAHF can cause the blockchain to split into two (or more) branches, that are not compatible with each other. Nodes with new rules will follow their own chain regardless of their mining support.

UAHF is a way to allow different groups of Bitcoin users, who have different opinions or visions, to voluntarily separate from the original chain and create their own version of the cryptocurrency. However, operators of full nodes may not have a guarantee that the network will be sufficiently secured by miners.

UAHF seems to me to be a certain form of coercion where full node operators (users) can ignore miners and vice versa miners can ignore users.

I'm not sure if UAHF will be a relevant form of voting in the future. As mentioned above, very few people run their own full nodes, so there is little chance that the minority of users will be joined by the majority of miners. Full nodes operated by exchanges can have a higher weight than user nodes.

I dare to say that even in the case of Bitcoin, full nodes play a negligible role and upgrades are mainly decided by miners. It is in the interest of the users to stay with the most secure version, i.e. to respect the decision of the miners. However, the holders of a large number of coins and possibly wealthy entities (institutions, funds, etc.) play a significant role because their purchase or sale of coins directly affects the miners' rewards.

For Bitcoin, a fork would be unpleasant, which would divide the community and thus the hash rate into approximately two equal parts, as it would also reduce the security of Bitcoin A and Bitcoin B by half (at least in the short term). The hash rate, i.e. the rule of the longer chain, decides which chain will keep the original name of Bitcoin.

The role of teams

Let's talk a little more about the role of teams. The influence of the teams on the protocols is relatively small as far as decentralization is concerned since the versions of the clients they propose must be accepted by the network.

In the case of Cardano, the power of the team is slightly higher than in the case of Bitcoin, because the team (3 founding entities) initializes the hard-fork combinator event. This has certain advantages and disadvantages. The advantage is that the Cardano network cannot be split. There will always be only one Cardano network and 45,000,000,000 ADA coins. There will never be a Cardano Classic or Cardano Cash. On the other hand, the team has control over what Cardano is and what updates the new version of the client will contain. Would it be possible to make a hard fork without a hard-fork combinator? Maybe.

In the case of Bitcoin, anyone can do a hard fork at any time. Blockchain forks and coin duplication is part of governance. The problem is to convince the community, miners, developers, and also the exchanges to support the new chain. I think this is a huge obstacle not only in the case of Bitcoin but also in the case of Cardano. The relevance of the blockchain network is primarily about community and adoption, and secondarily about technology. Without significant community support, it makes no sense to consider a hard fork.

The team builds a new version of the client and offers it to the community (network). Holders of expensive resources and market forces decide which client will be used. In Cardano's case, the community has to accept the upgrade or it won't happen at all. A fork of the Cardano network cannot happen. In the case of Bitcoin, forks are part of governance.

In the image below you can see the team that offered the community a new version of the client (green). Most pool operators have accepted the new version. One operator remained on the old version (blue).

A team can have control over the network consensus if they keep an expensive resource. This can be easier in the case of PoS projects, as the team can keep a significant portion of the coins. However, in the case of Cardano, the vast majority of coins are in the hands of the community, so there is no such risk. I don't think the members of the Bitcoin Core team control a significant part of the hash rate. However, companies such as Digital Currency Group and recently Black Rock are gaining control over mining. Through the hash rate, they can have control over the network upgrades, i.e. over the team.

Decentralization is actually a very complex thing. If it was possible to do without an expensive resource (which rich people can buy) and rely only on nodes allowing peer-to-peer communication between users, it would be easier. Without network consensus, however, it is not possible to ensure, for example, protection against double-spending of coins or immutability of monetary policy (digital scarcity). A network consensus protocol is essential and participants must have their own skin in the game as there is no other form of protection.

Remember, the security of the network (and protection against 51% attacks) is primarily determined by the market value of coins. Decentralization is dependent on the distribution of an expensive resource. In the event of a network upgrade, it is important to maintain these features at the best possible level.

Full nodes have almost no effect on security or decentralization. Although full nodes can, in theory, influence the voting outcome, they cannot directly provide important properties to the network. They can only achieve this indirectly by demonstrating the will of those who run full nodes. From my point of view, it is much more effective to vote through an expensive resource.

Conclusion

Running a full node is beneficial for your privacy and independence from a third party. You can also monitor the work of block producers. However, from the point of view of network consensus and governance, the most important is the expensive resource.

Sybil attacks prevent the possibility of voting or making any opinion about the situation based on the number of full nodes and their possible signaling. The coins of the largest blockchains are held by tens to hundreds of millions of users, while full nodes are operated by thousands to ten thousand people. This is a large disparity, so the number of nodes has a very low telling value as far as user opinion is concerned. Block production is based on an expensive resource and it makes sense to use the same principles for voting and upgrades.

Sometimes I come across the opinion that the quality of network decentralization is primarily determined by the number of full nodes. I hope it is obvious that this cannot be the case. The decisive factor is primarily the number of block producers and the number of delegators. Secondly, it is necessary to deal with how the expensive resource is distributed and how many whales there are in the system.