EOS.IO will implement the most complicated hard fork upgrade in history
What does the popularity of hard forks mean?
Author: Cyborg of EOSForce
Foreword
EOS.IO development team Block.one released the EOSIO version of 1.8.0-rc2 on May 15, 2019. It is the most important releases of EOSIO since it became open source. This release will set the tone for EOSIO to rapidly iterate through hard fork upgrades in the future, and will allow the entire blockchain industry to revisit the importance of hard fork upgrades. Meanwhile, all users, wallets, exchanges and DAPP will be affected.
In early 2019, some of the media started reporting a drop in the number of EOSIO code submissions, and we EOSForce team publicly responded that EOSIO has multiple developers submitting code every day in different branches, and needs to be tested before being merged into the main branch. 1.8.0-rc 2 is such a case, which has been under development since early 2019 or even earlier and its released on May 15, 2019.
Next we will explain in details why this update is so important.
Version: 1.8.0
Github: https://github.com/EOSIO/eos/releases/tag/v1.8.0-rc2
1. The key improvements of 1.8.0-rc2
1.1 Scalability enhancement and code refactoring:
In this release we see a large number of commits focusing on code refactoring and thread security.
First, for code refactoring, many people often don’t care about these code changes that neither adding features nor improving performance, but from a development perspective, these actually constitutes an important foundation for the follow-up development. We can see that since the beginning of the year, the core developers of Block.one have been improving EOSIO ‘s code structure and gradually building an abstraction layer from the design level. The most obvious is the improvement of EOSIO.cdt, which makes up the framework of EOSIO. Unlike many teams that start with a large architecture, the EOSIO was developed with a pragmatic, bottom-up approach by the Block.one development team.
In version 1.8.0, developers at Block.one split a lot of huge classes, stripping away some of the complex logic scattered around, such as the ’pending_block_state’ related state management has being stripped out from ‘block_header_state’. And the ‘transaction traces’ is also reorganized this time.
Another aspect is about multi-thread, In the recent period, there are a lot of commits about thread security, in preparation for the next step of multi-thread related development, Block.One team attaches great importance to multi-threading in the development of 2019. This refactoring will make the multi-threading described in the EOSIO white paper even better, taking TPS to the next level.
As is known to all, multi-thread development in medium or large scale C++ software has always been a “ tar pit “. In order to ensure the stability of EOSIO while introducing parallel computing, Block.one team is not eager to develop new features related to multi-threading. Instead, patiently troubleshoot thread-security issues in your code and improve infrastructure support. At the same time, the corresponding multi-threaded implementation is introduced in a specific independent module suitable for concurrency, such as chain API and P2P module.
1.2 Improve chain security
In this version, the Block.one team fixed some of the resource computation issues left over from the previous section. There are many resource-related logics in EOSIO, and they are extremely scattered. In order to improve chain performance and avoid unnecessary computation by nodes, a lot of resource-related specialization logic has been added to EOSIO. This also caused the ambiguity of user resource computation in many specific scenarios. For the EOSIO chain, this brings a lot of potential security issues. The blocking transaction problem exposed by the delayed transaction in the previous stage is largely the problem of incomplete resource inspection.
In addition, the problem of resource computation in some scenarios will also lead to the loss of users’ rights and interests, so it is imperative to modify this aspect.
1.3 Smart contract security
The EOSIO community has been plagued by smart contract security for a long time. DAPP developers have found a number of issues in practice in the past year. The Block.one team has absorbed these issues and made significant improvements. This update is more friendly to smart contract developers.
For DAPP developers, for example, the good news is the long-awaited ` GET_SENDER ` API is finally coming to EOSIO, DAPP developers can use this API to determine whether the current Action is triggered by the inline action, thus can avoid a lot of attacks that triggered by inline action from attacker’s contracts. This update can partially solve the problem of random numbers that have been plaguing the community for a long time. It should be noted that even though this API can block many CURRENT attack means and the attack cost will be greatly increased, it does not mean that DAPP developers can rest easy. For developers, security issues should always be noted, there is no silver bullet that is once and for all.
1.4 Hard fork upgrade mechanism
Updates in this area can make future hard fork upgrades more efficient while making a hard fork upgrade process not affect the user experience.
Recently, Block.one added a lot of new features, including the ones mentioned above. None of them have appeared in the past updates. A main reason is that developers must guarantee the compatibility of EOSIO. The node can choose not to upgrade the node version. Obviously this will greatly hinder the development of EOSIO. The biggest difference between this version of 1.8.0 and the previous one is that this version is not compatible with the previous version. Also known as the “hard fork”, before this version, EOSIO did not have a mechanism to deal with hard forks. The hard fork process can have a big impact on the user’s use. In order to make future updates not have the same impact as this one, a series of hard fork upgrade mechanisms have been added to this update. In the future, the hard fork update can be smoother and more secure.
In the past updates of EOSForce, the EOSForce team also encountered the same problem. So the chain configuration function was introduced. By this mechanism, the features of opening block height and chain maintenance state were added to the chain to solve the transition problem in the hard fork. Block.one’s countermeasures are similar. By introducing the protocol feature to solve this problem, unlike the EOSForce’s simple and universal solutions, Block.one’s design hopes to solve the feature’s compatibility problem more specifically. The design can be found in #6831.
Here you can judge that there will be more hard forks in the development process of Block.one than before. The progress of EOSIO in the future will be significantly faster than in the past.
2. Effects of EOSIO hard fork
EOSIO first used hard fork to upgrade, so the impact is huge.
2.1 Node: Most nodes should not have experienced a hard fork upgrade. If you strictly follow the hard fork requirements, all nodes need to replay the block. According to the current node configuration, most nodes need at least several days. Of course, there is a lazy way to directly use of snapshots provided by other organizations, but the downside is that if too many core nodes especially BPs update in this way, it will affect the security of the entire blockchain.
2.2 Users: All P2P nodes such as exchanges, wallets, block explorers, DAPPs, etc. will be suspended over a period of time, all other external access will be interrupted and user perception is very obvious.
Of course, the blockchain itself does not suspend, just for the security reason to suspend the interaction between the external and the chain.
2.3 DAPP developers: In theory, the hard fork of the chain does not affect the operation of the contract. But considering that many DAPPs have adopted a semi-centralized architecture and there is a lot of logic running outside the chain and interacting with the chain. So a hard fork will inevitably bring certain risks.
3 Benefits and risks of hard fork
3.1 Benefits:
In the Internet age, product iterations are commonplace. Developers release new versions almost every week, and users are used to updating to enjoy more features and services.
Previously, the hard fork upgrade was almost very rare in the blockchain industry, because most of the blockchain consisted of decentralized free developers, so the development progress was slow and the nodes were extremely scattered, and the hard fork upgrade was more troublesome. For example, an overflow vulnerability in 2010 led to the creation of a 184 billion BTC out of thin air. Satoshi Nakamoto first released a new version of the hard fork upgrade to avoid the Bitcoin crisis. Later, after Satoshi Nakamoto left the community, Bitcoin is taken over by the community, and it is difficult to reach a consensus on hard fork upgrades, so the hard fork upgrade is rarely used.
The Block.one team is a professional development organization, and the development progress has been exponentially improved compared to the previous blockchain project, so the rapid iteration to adapt to user needs has become the mainstream. In view of the current technical architecture of most public chains, if a large-scale functional upgrade is to be implemented, the hard fork upgrade is inevitable.
3.2 Risk
If the block producers have bad intentions during the fork, the fork process becomes very dangerous.
If some nodes join together to reject the upgrade, then there are two EOSs with a high probability.
Block.one did some precautions: Although Block.one had a lot of development in the first half of 2019, there were a lot of new features, but this update only includes some necessary features and security issues to fix. After the feature is online, the hard fork will get smoother.
4. Note for this hard fork
This is the first hard fork update of EOSIO, and it is not performed under an effective upgrade mechanism, requiring more effort from nodes and community.
The EOSForce team has conducted several large-scale hard fork upgrades since the mainnet launched to iterate new features. Here we share some of the experiences in the hard fork upgrade:
First, the more you prepare, the smoother the update. Before the update, the node must do a backup job. The current EOSIO node data is very large. When backing up a node, the efficiency of restoring the backup data must be considered. The backup data and the node must be in the same intranet. Don’t rely on someone else’s backup. Otherwise, it will take a long time to transfer backup data when there is a problem. The best way is to directly create a backup node for the node.
Secondly, you need to pay attention to control the interaction of the nodes. During the update process, the entire EOSIO network will be in a semi-compatible state for nodes. At this point, if someone submits a transaction that triggers incompatible logic to a BP that has already been updated, it will cause the updated BP to immediately fork. Although the hard-fork function itself is based on the feature to manage whether it is effective, and the transaction that performs the logic error is generally not transmitted in the p2p network. But it is difficult to sure all actions cannot cause fork from nodes. Therefore, nodes, especially block producers, should pay attention to control interaction during the update process. The first is to control the opening of http API. Several RPC nodes can be opened properly, but there must be no direct p2p connection between RPC nodes and block producer nodes, nor direct p2p connection between nodes and other external nodes. so that key nodes can be guaranteed to run when hard forks occur.
Finally, the update order needs to be controlled. If nodes can orderly update, even if there is a hard fork, most nodes will not be affected. The nodes in EOSIO are often divided into data nodes, block producer nodes, RPC nodes and synchronization nodes. It is easy to establish a “green zone” for the block producer nodes by controlling the interaction of the nodes, shielding the external influence on the core block producer nodes. At this point, the block node can be upgraded. After this, gradually update the block producer node and the external synchronization nodes. At the same time, an update window period should be reserved for data nodes and other read-only nodes in the community. The nodes of the community and the developer can be similarly, first establish a green zone by establishing a shielded synchronization node, update the internal node, and finally update the synchronization node. Finally update the RPC nodes after most nodes and all core nodes are updated. Then complete the update of the entire network.
In fact, the means and deployment specifications mentioned above have long been a commonplace, but the maintainers of many nodes do not strictly plan the deployment of nodes according to the specifications. It is foreseeable that if the node maintainers are still not perfect node deployment, then it will be a concentrated outbreak of many problems in this update.
In general, the more preparation, the better. Many problems are unpredictable, so it should be do one or more walkthroughs of your EOSIO upgrade before you officially update it.
5. What is the meaning of hard forks
Hard forks should be a common technical term, but hard forks for different purposes can produce different results, so the community has a very different understanding of the hard fork concept.
From a technical point of view, hard forks can cause new rules to be incompatible with previous rules, and if you get the support of the community owner, the high probability will have no effect.
From a community perspective, if there are different consensus and technical routes when hard forks, the high probability community will split into two public chains, each supporting different routes.
In 2016, the EAO crisis occurred in Ethereum (ETH). The founder Vitalik decided to roll back the transactions. Some people in the community did not agree to roll back the transactions. They believed that the blockchain ledger could not be tampered with and refused to roll back. Therefore, ETC was born (Ethereum Classic).
In 2017, the congestion of Bitcoin (BTC) made the big-block supporters eager to improve Bitcoin, but there were different opinions in the community, so Bitcoin cash (BCH) was born.
In 2018, when the EOS mainnet was launched, the EOSForce team proposed different governance routes, and then the EOSForce (EOSC) was born.
We can see that the Block.one team has done a lot of preparation.
6. The importance of this hard fork
This hard fork is the most important version since the birth of EOSIO. All public chains based on EOSIO such as EOS, EOSC, ENU, Telos, BOS, Worbli, etc. need to be upgraded through hard forks.
As one of the highest level development organizations in the industry, Block.one is very bold in its development. This time, the hard fork mechanism has been added, which means that there will be at least two or three hard forks in the second half of the year.
In the past, blockchains were very afraid of hard forks. Only the BCH community maintained a hard-forward upgrade for half a year. EOSForce also carried out several hard fork upgrades. With the development of node and community awareness, ‘hard forks’ will no longer be a scary word, but it will become a way of making progress in the blockchain, even if there is a new branch.
This hard fork upgrade will bring more functions and better user experience to EOSIO. It can be expected that if you want to adapt the public chain to the development of the times, the upgrade method of hard fork will become the mainstream in the future.
7. Recent community rumors about BM’s leaving
Rumors that BM has developed new projects have triggered panic in the EOSIO community.
From the perspective of EOSIO, Block.one has made great efforts on EOSIO after the mainnet was launched. Continuous and efficient development has made EOSIO the most powerful decentralized application software platform. At the same time, there are teams like EOSForce, EOS Canada, BOS Core that have been deeply involved in the development of the public chain. Even if BM leaves the community, it will not affect the development of EOSIO.
EOSForce team tracked the development progress of most of the world’s mainstream public chains, whether the development speed or code quality, Block.one has better performance in EOSIO development than other mainstream public chain development teams. There are a lot of branches that are as important as 1.8.0-rc2, and we are waiting to see.
