Blockchain protocol upgrade process
by Iurii Shyshatskyi, Chief Scientist at Jax.Network
Introduction
Any complex and heavily used piece of software requires timely updates, which improve its performance, efficiency, reliability, user experience or, simply, fix bugs. That’s true for the software used in blockchain networks. However, the upgrade process of the decentralized blockchain protocol has a peculiarity: there is no central authority that can force all participants to upgrade their nodes.
It’s never enough to stress the fact that any central authority is a potential point of failure. The presence of such an entity contradicts the principles of decentralization. Fortunately, a blockchain network has a mechanism that enables upgrades without relying on a central authority.
In this post, we will review the blockchain network upgrade process and its potential risks. Then we will switch the focus to the architecture of JaxNet protocol and issues specific to its upgrade mechanism.
Upgrade-ready nodes
In a decentralized network, participants might have different interests and different visions on the necessity of a certain protocol upgrade. Some upgrade proposals are useless or even harmful. Therefore, it’s important that protocol upgrades become a subject of discourse and gain strong support from the community.
Moreover, even if the prospective upgrade is completely necessary and supported by the community, a fraction of nodes could face technical obstacles. Some participants might find that a proper patch for their version of the node is not available.
In a truly decentralized network, block producers and casual users have the freedom to choose one of many software implementations of the node. These node-clients are developed by different teams of developers using different programming languages. Every blockchain user chooses a client that better suits his needs. Unfortunately, sometimes developers fail to prepare bugless patches or even suspend the support of their product.
It can result in multiple independent groups of nodes during the blockchain upgrade process. For example, the first group of nodes consists of nodes that are unable to make an update or do not want to patch their nodes. Meanwhile, the second group consists of upgrade-ready nodes that want to apply the patch and have everything ready for this move.
There can be other groups as well. Some participants may use inappropriate patches with bugs. As a result, their nodes might behave differently from nodes in the first two groups.
So the landscape of the blockchain network during the upgrade process can be very diverse. When a blockchain is used by thousands of individuals and organizations, there is a risk that despite all preparations there will be a few nodes and a few user wallets that won’t be timely upgraded.
The risk of the chain split
The diverse landscape during the protocol upgrade process is a source of security risks, which should be taken into account by developers. The primary risk here is a chain split. It could occur when a group of miners uses an outdated or improper blockchain client and generates an invalid block or even a sequence of invalid blocks.
Chain splits are neither uncommon nor scary. Unintentional chain splits often occur in truly decentralized blockchain networks. Under normal circumstances, a node easily determines the main chain using consensus rules. However, if node software is outdated, it can reject blocks generated according to the new protocol rules. As a result, this node may mistakenly connect to the wrong chain. A malfunctioning node connected to the wrong chain may expose its carefree owner to double-spend attacks.
Issues during an update process may cause financial damage due to service downtime, lost opportunities, and wasted resources. They may affect miners, cryptocurrency exchanges, and various service providers. Such incidents may cause reputational damage to developers and the whole blockchain platform too.
Fortunately, the blockchain industry has developed rather reliable procedures and safety measures that effectively mitigate update process risks. Protocol upgrade proposals are announced and reviewed beforehand. Their implementation goes through thorough testing. For this purpose, one or multiple test networks are created. Blockchain nodes download upcoming update patches beforehand, signal to their peers about their upgrade-ready status, and activate the update after a certain block, according to the conceived plan.
Despite the ever-growing complexity of blockchain underlying protocols, smart contracts, and blockchain bridges, protocol updates on well-established blockchain platforms often go rather smoothly.
Hard forks and soft forks
Protocol updates are not all the same from the security perspective. They are often categorized into two groups: hard forks and soft forks¹ ².
A soft fork is a change to the protocol, where any block generated by updated nodes is considered valid by nodes that haven’t installed the update. Since old nodes recognize new blocks as valid³, a soft fork is backward-compatible. In contrast to a soft fork, a hard fork is an upgrade that introduces blocks that may be rejected as invalid by outdated nodes.
Soft forks are considered to be a more secure way to upgrade the network. If the majority of hash power in the network has approved the update and timely upgraded their nodes, then the whole process goes rather smoothly.
Miners with updated nodes will generate the heaviest chain in the network. Although miners with outdated nodes can generate invalid side-chain blocks, they will always recognise the heaviest chain and its blocks as valid because of the backward compatibility of the soft fork. They don’t have a chance to generate any long side branch of blocks since they always reconnect to the heaviest chain and continue mining on top of its blocks. It’s also worth mentioning that mining invalid blocks is rather expensive and professional miners rarely do that.
In the soft-fork scenario, carefree users with outdated nodes have a risk of accepting a side-branch block, however, that block will never get sufficiently enough confirmations. So users who follow common security recommendations and wait for multiple block confirmations always avoid any potential damage, at least in this theoretical scenario.
Soft forks are often associated with adding new features such as new types of transactions or smart contracts. They may be used for fixing some security vulnerabilities in blockchain virtual machines.
Unfortunately, not all protocol updates can be implemented via a soft fork. Radical changes to the protocol or its core rules could be implemented only through a hard fork. For example, maximum block size increase, alteration of chain-weight calculation rules or difficulty adjustment algorithms always require a hard fork. Fortunately, such radical changes are rarely necessary. Frequent hard forks are common for immature and ambitious blockchain networks with overcomplicated protocol logic. Luckily, well-designed blockchain protocols that withstand the test of time can remain immutable for many years.
Update activation mechanism
We have established that secure and successful protocol upgrades require the support of the majority of nodes involved in consensus. A curious reader may wonder how network participants learn when the upgrade gets sufficient support and how they coordinate their actions in this process.
In real life, people can use online and offline forums, meetups and conferences to chat, discuss, negotiate, and coordinate their actions. These methods are sufficient for networks with permissioned participation in which members often know each other. Although this approach is commonly used in blockchain communities, it’s not sufficient for permissionless blockchain networks in which blocks might be mined anonymously.
Decentralized blockchains often record processes related to protocol updates. Miners or block producers place certain data within a block to indicate their support, readiness and willingness to enforce an update, according to the rules outlined in the protocol.
Other network participants learn and calculate flags, signals or voting bullets left by block producers within a given timeframe to learn whether the transition to new protocol rules is going to happen. As a rule of thumb, new protocol rules get activated on the block of a certain height so that any subsequent block in the chain is forced to comply with new protocol rules.
This update mechanism was introduced and battle-tested in Bitcoin. Other decentralized blockchain networks adopted similar procedures. Interestingly, the original Satoshi’s Bitcoin client didn’t have such an algorithm. Thus creation and improvement of the update mechanism was a goal of first Bitcoin Improvement Proposals (BIPs)⁴. In particular, BIPs 8, 9 and 34 describe update schemes used by the Bitcoin community at different stages of development⁵.
Hard forks in a sharded network
We have reviewed an upgrade process in single-chain blockchain networks. Let’s proceed with sharded blockchain networks, as they seem to provide a more interesting case. Nodes in such networks support more than one chain and follow more complex protocols.
Proof-of-Stake (PoS) sharded blockchains are notorious for complexity of their protocols. In PoS, block producers and validators work in a restrictive synchronous setting and slash the stake of their peers who misbehave.
An even bigger problem in the PoS network is the fact that lightweight nodes can’t calculate the chain weight on their own. Thus the majority of their casual users have to rely on centralized services to determine the main chain during synchronization and in the event of any fork. Therefore the upgrade process in the PoS networks resembles the top-down maintenance in a centralized cloud service.
Sharding in Jax.Network has a different design. Jax.Network is a Proof-of-Work (PoW) blockchain network that adopts the Parallel Chain Model. It consists of the beacon chain and multiple shard chains which work in the asynchronous setting.
The first stage of the upgrade process is similar to the one in Bitcoin. Miners use beacon chain blocks as a place for their signals. They agree on what block height an upgrade should be activated.
Since there are multiple chains in the network, every chain has its own value of height. However, in a PoW network, new shard blocks arrive randomly. So there is no guarantee that shard chains will reach their activation points simultaneously. Thus there could be a situation when a fraction of shard chains follow the previous version of the protocol, while other chains have already activated an upgrade.
Special hard-fork mechanism
Aforementioned issue may not be a problem for casual users and their nodes. However, it may affect miners who merge-mine multiple shard chains simultaneously. At some moment, these miners will have to produce and accept shard blocks composed according to different protocol rules.
For example, the protocol upgrade may affect block difficulty verification, merge-mining process, or profitability. In this scenario, there is a threat that some miners might decide to discard certain shard chains from their merge-mining list before they reach the upgrade activation point. This issue can break one of the principles of chain independence which we have formulated in our previous post:
There is no block arrival event on one shard chain which could affect block production, block validity, or chain forking on another shard chain or the beacon chain.
For such extreme cases, Jax.Network has a special protocol upgrade scheme. In contrast to the common flow in which new validation rules are applied to all blocks above a certain height, new rules are enforced gradually in the Jax.Network special scheme. Here, every shard chain has its own activation height. However, once this height has been reached, a node may continue accepting blocks generated according to previous rules.
Any miner may merge-mine multiple shards according to previous rules even though some shard chains have reached respective activation points. Once the miner notices that all shard chains have reached their activation points, he can switch to mining according to new rules simultaneously on all chains, which he has chosen for merge-mining.
After a shard chain reaches a certain height, blocks, generated according to previous protocol rules, become prohibited. As a result, new rules are enforced. Once all shards in Jax.Network stop accepting legacy blocks, the transition to new protocol rules is finished.
It is worth mentioning that there is no need to use a special mechanism every time a soft fork needs to be applied. However, in some cases, it may be useful and necessary. This mechanism is also interesting from the theoretical point of view. It is specific to sharded Proof-of-Work blockchain networks such as Jax.Network.
Conclusions
In Jax.Network, a protocol update is not a single event, it’s a process. This process includes the discussion of the proposal by the blockchain community and the subsequent graduate transition of every node to the new version. Only when the last shard chain in the network has completely switched to the new updated protocol, the upgrade can be considered finished.
The Jax.Network team works steadily on the improvement of the JaxNet protocol, reference client and mining software. In the upcoming months, we will add some features that were described in our whitepaper and other documentation. They include a difficulty adjustment algorithm and an improved algorithm of node synchronization. We also make necessary preparations for opening new shards.
¹https://cointelegraph.com/blockchain-for-beginners/soft-fork-vs-hard-fork-differences-explained
² https://www.investopedia.com/terms/h/hard-fork.asp
³ Invalid from the perspective of new protocol rules
⁴https://learn.saylor.org/mod/book/view.php?id=36383&chapterid=19042
