The article aims to spread basic knowledge on blockchain security, Welcome to follow and discuss with us
Author: Lunaray security Team
0x01 preview
When you are using the electronic banking application on your smartphone, you must have encountered a system prompting you to update. At this time, you usually have to consider and agree to the update before the system can be upgraded. Maybe your phone will update automatically without notifying you. After all, a software upgrade is a necessary process, and if you do not have the latest version of the software installed, you may not be able to continue using the associated service.
In Open-Source Software (OSS) cryptocurrencies, the situation is quite different. You don’t need to read every line of code that underpins Bitcoin, but it’s helpful if you can. Because you will find that there is no hierarchy of governance in a decentralized environment and no bank to push updates and content modifications to you at will. Therefore, it is a challenge to implement an update of a new function in a blockchain network.
0x02 Who are the decision-makers in the blockchain network?
In Bitcoin, you can roughly divide participants into three distinct subsets: developers, miners, and full node users.They are actually nodes of various parties participating in the network and contributing. And like widely used light nodes (for example, wallets such as mobile phones, laptops, etc.), they are not real “participants” to the network.
- Developer：Developers are responsible for creating and updating code. For traditional tokens as you know them, anyone can contribute code to the process. The code is publicly available, so they can submit changes to other developers for review.
- Miner :Miners are participants in securing the network. They run the cryptocurrency’s code and devote computing resources to adding new blocks to the blockchain. For example, in the Bitcoin network, they do this through proof-of-work. Miners will obtain corresponding mining income in the form of collective rewards.(Block Reward)
- Full node user: Full nodes are the backbone of cryptocurrency networks. They are responsible for validating, sending and receiving blocks and transactions, and maintaining a copy of the blockchain’s data.
0x02 What is a fork?
Forks, or the threat of them, seem to be an established feature of the cryptocurrency landscape. But what are they? Why are they such a big deal? And what is the difference between a hard fork and a soft fork?
A “fork,” in programming terms, is an open-source code modification. Usually, the forked code is similar to the original, but with important modifications, and the two “prongs” comfortably co-exist. Sometimes a fork is used to test a process, but with cryptocurrencies, it is more often used to implement a fundamental change or to create a new asset with similar (but not equal) characteristics as the original.
Not all forks are intentional. With a widely distributed open-source codebase, a fork can happen accidentally when not all nodes are replicating the same information. Usually, these types of accidental forks are identified and resolved. A majority of cryptocurrency forks occur due to disagreements over embedded characteristics.
One thing to bear in mind with forks is that they have a “shared history.” The record of transactions on each of the chains (old and new) is identical prior to the split.
Note that such events are common in open source projects and have been around long before Bitcoin or Ethereum. However, only in the blockchain space does the distinction between hard forks and soft forks exist. Below we will discuss in detail.
Hard forks
A hard fork is a software upgrade that does not support backward compatibility. Typically, these situations occur when a node adds a new rule in a way that conflicts with the old node’s rule. New nodes can only interact with software nodes running the new version. As a result, the blockchain split, producing two separate networks: one operating under the old rules and one operating under the new rules.
So now there are two networks running in parallel. They will continue to produce blocks and transactions, but will no longer work on the same blockchain. All nodes have the same blockchain (and the history still exists) until the blockchain network reaches the forked block, but after that they will have different blocks and transactions.
Since there is the same history, if you held coins before the fork, you will get coins on both networks at the same time. Suppose you had 5 BTC in hand when the fork occurred at block 600,000. You can choose to spend the 5 BTC on the original blockchain when the block height reaches 600,001, but the consumption at block height 600,001 will not be recorded on the newly generated blockchain. Assuming the encryption has not changed, these 5 tokens will still be present in your private key on the new forked network.
Another example of a hard fork is the one that occurred in 2017 when Bitcoin split into two separate chains, the original Bitcoin (BTC) and the new Bitcoin Cash (BCH).The fork came after a lot of debate in the community over the scaling of block sizes. Bitcoin Cash (BCH) proponents want to increase the block size, while Bitcoin (BTC) proponents oppose the change. An increase in the block size requires a modification of the rules. This was done before the SegWit soft fork, so nodes will only accept blocks smaller than 1MB. If you create a 2MB block, other nodes will refuse to validate.Only nodes that have upgraded their software to support block sizes greater than 1MB can accept these blocks. Of course, this makes them incompatible with previous versions, so only nodes with the same protocol can communicate with each other.
Soft folks
Soft forks are software upgrades that support backward compatibility, and upgraded nodes can still interact with non-upgraded nodes. Soft forks are usually upgraded by adding a new rule to the program that does not conflict with the previous old rule.
For example, a block size reduction can be achieved through a soft fork. Let’s take the example of Bitcoin again to illustrate this point: there is a limit on the upper limit of the block size in the Bitcoin network, but there is no limit on the lower limit of the block size. If you only want to accept blocks below a certain size, just reject blocks larger than that.
However, doing so will not automatically disconnect you from the network. You can still interact with nodes that don’t enforce these rules, but some of the information they pass to you is filtered out.
The aforementioned Segregated Witness (SegWit) is a good example, which happened shortly after the split between Bitcoin and Bitcoin Cash. Segwit is an update that changes the format of blocks and transactions, and it’s designed in a clever way. Old nodes can still validate blocks and transactions (in a format that doesn’t violate the rules), but for some fields, they can’t read them. Only when the node is upgraded to a newer version will some fields be readable and other data will be parsed correctly.
Even more than two years after the activation of Segwit, the upgrade of all nodes has not been completed. There are also many benefits to doing this, such as no network outages and less urgency for upgrades.
0x03 Hard fork or soft fork, which one is more advantageous?
Essentially, these two types of forks work differently. Controversial hard fork upgrades will split the community in two, but planned hard fork upgrades allow all participants to freely choose whether to modify the program.
A soft fork is a more stable option. In general, you can only enforce certain restrictions as new upgrades do not conflict with previous rules. That said, if you can implement the upgrade in a compatible way, you don’t need to worry about the risk of network fragmentation.
0x03 Summarize
Hard forks and soft forks are critical to the long-term success of a blockchain network. Despite the lack of a central authority, they are able to make changes and upgrades in a decentralized system.
Forks allow blockchains and cryptocurrencies to integrate more new features as they are developed. Without these mechanisms, we would need a centralized system with top-down control. Otherwise, we can only abide by immutable rules for the life of the software agreement.
