The last update to the Olympia public network has now been released to node runners, officially starting the countdown until the sunset of Olympia and the dawn of a new era for programmability and usability with Babylon.
How does it work?
Like all coordinated updates on Olympia, a new version of the node is created which is fully backwards compatible with the version currently running on mainnet. Validators who adopt the new software cast an on-ledger vote indicating that they have adopted the update and are ready to proceed. The weight of a vote is equivalent to the amount of XRD staked to that validator.
In order for an update to be enacted, two things have to occur:
- A hard-coded vote threshold has to be reached.
- A minimum network epoch number must have passed.
Once both of those conditions are met, the entire network deterministically switches to the new protocol. Normally, the network then continues ticking along with the new rules, but this last protocol update is a little more exciting…
How does this one work?
At the moment the last protocol update is enacted, the network will cease processing new transactions, and every node will calculate the Olympia network end state and save the results. Then they sit, waiting for anyone to ask them about that end state.
In the run-up to this moment, Babylon nodes have been sitting around twiddling their thumbs, periodically nagging the Olympia nodes to ask if Olympia is done yet. Once the state calculation has completed, the Olympia nodes say “here you go” and pass on that final state to the Babylon nodes, who will use it as input for the genesis of the Babylon network, seamlessly migrating everything to the new model. As soon as Babylon validators comprising over 2/3rds of staked XRD have completed ingesting the state, Babylon begins!
So the switch happens on September 27th?
Because all this update logic is tied to epoch numbers, which don’t have perfectly predictable durations on Olympia, there’s some educated guesswork at play here in order to achieve the desired calendar date of September 27th. The last protocol update includes a minimum update epoch which is targeted, based on average network speed over time, to occur on that date. As long as validators meeting the stake threshold (79%, in this particular case) have cast their vote by then, Olympia will enact the shutdown sequence. If the network is running faster or slower than average over the next month, it will be a little sooner or a little later, and no doubt some eager beavers in the community will be putting up countdown timers that constantly update the exact predicted moment for the changeover.
What about the Babylon node software?
While community validators have already been running test builds of the Babylon node on the RCnet test networks, the production-ready version will not be released until September, with plenty of time left for them to get set up for the changeover. There will also be another public test of a Stokenet migration, to be doubly sure that everyone has had a chance to get used to the process.
Is it time to get excited?
Absolutely.