The hardfork that created the Hive blockchain was coded by contributors from the community.
In the past few months, we've seen Hive's ecosystem grow to include a wealth of community members contributing to the open source core code and beyond. It's been an exciting time to watch people stepping up to help bring Hive to life! There are an increasing number of devs working on making a better blockchain every day. If you'd like to learn more about the source code, how to contribute, or even just how to watch and comment on what's happening, please check out the core development post for a walkthrough. We're fast approaching being ready for the first Hive hardfork, and there are more than twenty developers who have contributed to the blockchain and library changes for this version.
With that being said, work on the core code for this hardfork addresses a lot of areas that aren't super flashy or necessarily very easy to follow along with, even if you know where in the repos to look. To help get everyone up to speed on the impending hardfork, here's some information about the release candidate, testnet creation, what potential timing will look like, and an overview of what's included in HF24.
What is a hardfork release candidate? When can we expect HF24?
When software is being developed, eventually a set of upgrades are chosen to be the "final version" of the next release. There are still some steps to take to make sure that this final version is working correctly and covers off everything it needs to! As a release candidate, the code is stable, ready to go, and no further work will be done unless a problem is found. The code is frozen (which means new features stop being added to the version) and enters a period where it is thoroughly tested. This is why it's called a candidate: as long as no significant bugs are found during wider testing, it's ready to be the version run by everyone.
The @HiveIO account will make a post with details on the release candidate and testnet for HF24 on Monday, June 8th.
While a number of people have contributed to the code, it's time to get even more people trying to break it! 💪 Everyone's invited (and encouraged!) to jump in for testing, and the next post will talk a little more about how you can get involved at any level- whether you're an end user, project manager, node operator, or developer.
As testing progresses, we'll learn a bit more about an accurate time frame for the actual hardfork date. If things look smooth and no big bugs are found right away, then exchanges will be notified and the chosen date could be as early as two to three weeks later. Should a problem come up immediately or really heavy final vetting needs to be done, the chosen date could be closer to four to five weeks away. The more people testing and giving feedback, the faster things will move! Part of choosing the date for a hardfork is giving a sufficient amount of notice to exchange teams so they can prepare their nodes to support the upgrade. It's important to give them an advance window and be ready to assist if they need it to help make sure that wallet maintenance downtime is minimal.
What sort of changes are included in HF24? What will this hardfork do?
The most important parts of the first Hive hardfork involve making sure that it's easier and faster for everyone everywhere to use and support the Hive network. Many of the devs working on the hardfork have been personally documenting their progress. Here is a quick layman's overview of the biggest things that this hardfork will change:
- Changing the blockchain ID.
- To help existing frontends and dApps migrate quickly and easily, the chain ID was not changed at the time of Hive's creation. However, this is an important part of improving secure access to the blockchain going forward, and needs to be done now in preparation for even more projects joining the ecosystem.
- To help existing frontends and dApps migrate quickly and easily, the chain ID was not changed at the time of Hive's creation. However, this is an important part of improving secure access to the blockchain going forward, and needs to be done now in preparation for even more projects joining the ecosystem.
- 30 day cooldown time on newly powered up HP for governance voting.
- The Hive governance system is made up of both witness voting and DHF voting. When additional new funds are powered up, their weight will NOT count towards governance voting for the following 30 days. This adds a healthy buffer period to any potential malicious coordinated takeover attempt which allows the community a chance to respond, and is an important yet reasonable safeguard to help prevent attacks via funds stored on exchanges without impacting funds in any way.
- The Hive governance system is made up of both witness voting and DHF voting. When additional new funds are powered up, their weight will NOT count towards governance voting for the following 30 days. This adds a healthy buffer period to any potential malicious coordinated takeover attempt which allows the community a chance to respond, and is an important yet reasonable safeguard to help prevent attacks via funds stored on exchanges without impacting funds in any way.
- A huge number of preliminary changes to make running a Hive node easier.
- This is a simplified statement that covers a ton of work and portions of the core code. One of the most restrictive parts of growing Hive has been the cost, amount of resources needed, and the difficulty of running infrastructure to support the blockchain. It's meant that helping further decentralize Hive with more seed nodes, witnesses, and RPC nodes has been a lot harder to do than it should be. Exchanges running nodes have needed longer maintenance times and more direct help with Hive. Projects, dApps, and developers who want to build on Hive have found it can be hard to get started because they can't afford their own nodes or that public options are still limited. While this sounds very technical, it translates directly into a poor experience for end users and investors too. Making Hive easier, faster, and more affordable to run allows for better decentralization, from blockchain level to the diversity of projects and users in the ecosystem.
- This is a simplified statement that covers a ton of work and portions of the core code. One of the most restrictive parts of growing Hive has been the cost, amount of resources needed, and the difficulty of running infrastructure to support the blockchain. It's meant that helping further decentralize Hive with more seed nodes, witnesses, and RPC nodes has been a lot harder to do than it should be. Exchanges running nodes have needed longer maintenance times and more direct help with Hive. Projects, dApps, and developers who want to build on Hive have found it can be hard to get started because they can't afford their own nodes or that public options are still limited. While this sounds very technical, it translates directly into a poor experience for end users and investors too. Making Hive easier, faster, and more affordable to run allows for better decentralization, from blockchain level to the diversity of projects and users in the ecosystem.
- Correct the incorrectly excluded Hive airdrop recipients and include any additional users supported by the community via proposal voting.
- The list of corrections can be found in a previous post. Also, while the group of excluded users as a whole were voted against being included, some individual proposals have been supported by the community and will be airdropped during the first block of the hardfork.
- The list of corrections can be found in a previous post. Also, while the group of excluded users as a whole were voted against being included, some individual proposals have been supported by the community and will be airdropped during the first block of the hardfork.