Node: Staying Up-To-Date
Last updated
Was this helpful?
Last updated
Was this helpful?
This is a step-by-step guide on how to stay up to date with hardforks of the core repository, as well as instructions for core team members on how to execute updates that could cause a hard fork on the network. This doc should help node operators and the core team release new code in an organized way, particularly so that the developer community has sufficient time and resources to upgrade their nodes.
Subscribe to release notifications on GitHub
Which repos?
(important)
(important)
(important for exchanges like Coinbase)
How to subscribe
Click “Watch” at the top
Select “Custom”
Check “Releases”
Whenever a major version update occurs, e.g. moving from 2.9.9 to 3.0.0, be sure to read the release notes and reboot your node within the next week to avoid issues
Note that occasionally a resync will be required, which could cause ~20 minutes of downtime unless done in parallel with a second running node. Be sure to read the release instructions to avoid any interruptions.
Follow and on or for on-chain announcements and discussion
Follow and on Twitter
Gate all the forking changes by a ForkHeight which initially should be set to math.MaxUint32 for both mainnet and testnet, and 0 for regtest.
Verify that the code passes all basic tests:
core unit tests
core integration tests
node syncs with hypersync + txindex on testnet and mainnet
node syncs with blocksync + txindex on testnet and mainnet
rosetta can sync mainnet
repeat steps c. and d. for postgres
test that all of the changes work in the reference frontend
make sure to run more comprehensive tests when deploying a complex change
Assuming you’re ready with all the content for the steps in the next sections, you should announce everything at 12:00 PM PT and set the testnet fork height to 1 day from the announcement, and the mainnet fork height to a minimum of 7 days from the announcement.
We will strive to give as much time for node operators to upgrade as possible, erring on the side of two weeks. However, in the interest of moving quickly, it will sometimes be necessary to make updates with less warning, though generally with no less than one week of warning.
Come up with a description of what happens in the fork. Make it a couple sentences, or a couple paragraphs depending on the scope of the change. See what fits based on next steps.
Assuming the release number is XX.YY.ZZ (major.minor.patch):
You should increment the major XX
-> if the node operators will be required to upgrade their software within a fixed amount of time, otherwise risking ending up on a stale fork.
You should increment the minor YY
-> if the node operators can do nothing and still properly participate in the network. The code augments the node in a backwards-compatible fashion.
You should increment the patch ZZ
-> If the update fixes a bug in a backwards-compatible fashion.
Cut the new release
Create twitter announcement for the fork
Create diamond announcement for the fork
Create discord announcement for the fork
Draft a Fork Preparation Checklist document which is a step-by-step checklist/walkthrough of what node operators need to do in order to upgrade their nodes (inspired by )
(Optionally) Write a before and after table which describes what happens in the fork. The left column should describe different aspects of the “before” tech and the right shows how they updated / changed “after” the fork. (also )
Put all of the above in a new draft release on github, similar to how , or how