Anemone (v1.1.1)

Obsolete, use Anemone (v1.1.2) instead.

Anemone (v1.1.0)

Summary

This is the v1.1.0 node, containing the anemone protocol update, and a few other improvements.

This is a required update. All mainnet nodes will need to have updated to this version by the time the anemone protocol update enacts. This will likely happen at the start of epoch 70574 at 16:20:57 UTC on Wednesday 7th February. Configuration for the anemone protocol update triggering on mainnet can be found here.

The protocol update on stokenet was triggered on 30th January to allow time for developers to test on stokenet before mainnet is live.

Details for node set-up are on the docs site here. There should be no need for configuration changes as part of updating to this release. For those running natively, you should update both jar and native library from the attached assets. For those running in Docker, the new image is available on dockerhub.

Please note also:

• If you run a validator, after updating, you MUST signal readiness for anemone according to the Readiness Signal Process section of this guide.
• If you run a Gateway, and wish to avoid downtime, be aware that you need to update to Gateway v1.2.4 before updating to node v1.1.0, and then update to Gateway v1.3.0.

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

Details

Key changes

• Support for protocol updates - Including the new (protocol update) flash transaction type, additions to the System API, ability to define protocol update thresholds and content, node startup verification, and node monitoring for protocol updates. Also includes new metrics under the rn_protocol_ sub-namespace.
• Support for the anemone protocol update - as per the Scrypto release notes (on docs site and github). Notably:
  • Corrects the creation cost for validators to 100 USD equivalent of XRD.
  • Brings basic BLS support to Scrypto.
  • Allows requesting TimePrecision::Second when requesting the current time in Scrypto.
  • Tweaks the pool blueprints to improve precision, and improve behaviour with non-18 divisibility resources.
• Ledger size pruning - includes a pruner of ledger proofs which reduces ledger disk usage by validators by a significant margin.
• Core API additions we have added the following functionality:
  • Balances changes can be requested from the Stream API
  • New /core/stream/proofs endpoint which can be used for retrieving proofs, with various filters.
  • New transaction type (the flash transaction)
  • Addition to the /core/state/validator and /core/state/consensus-manager endpoints to include a breakdown of the current readiness signals for validators.

Important note

The state pruner will take around 60 minutes to catch up / reduce disk space usage, and in this time will use a lot of IO. This may cause some delays in other parts of the node, and may cause your validator node to miss some proposals. You may wish to swap to a back-up node, or unregister for this hour or two, to mitigate this.

The initial logs will be very noisy after spinning up a new node. Note these logs are in the Rust part of the node, so you may not see them if you are only explicitly streaming your Java logs. When the catching up gets to the current epoch, the logs will stop being so noisy. IO slowness and disk space usage may persist for a time as RocksDB does further DB compactions to free-up the reclaimed space.

Small artifact update

The babylon-node-v1.1.0.zip artifact was updated on 20th February to include a native keygen, to reduce dependence on docker. This will be present in future built zip files.

Anemone (v1.1.0-rc.1)

Pre-release for the upcoming anemone version. Not for running on production!

Babylon (v1.0.5.4)

This is identical to Babylon (v1.0.5.2), but with native assets attached for our supported host operating systems. Please see the release notes for Babylon (v1.0.5.2) for more information.

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

Babylon (v1.0.5.2)

Notice

This node's asset publishing didn't complete correctly. Please see the equivalent build Babylon (v1.0.5.4) which has full assets.

Summary

This is the v1.0.5.2 node, which is a minor tweak on v1.0.5, but provides a fix for the same issue for stokenet.

If you are running a node on a non-stokenet environment, such as mainnet, you are fine to stay on v1.0.5. The update to v1.0.5.2 is only required for stokenet nodes running v1.0.4 at epoch 19100 (on Saturday 16th December 2023).

On start-up, if necessary, the node will spend roughly 5 minutes recovering, before being ready to proceed. The network won't be able to function normally till a quorum of validators have updated.

Further details / explanation regarding the outage and the fix will follow in due course. In the mean time, the diff from v1.0.4 is available here.

Details for node set-up are on the docs site here. There should be no need for configuration changes as part of updating to this release. For those running natively, you should update both jar and native library from the attached assets.

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

Babylon (v1.0.5)

Summary

This is the v1.0.5 node, which is a required immediate update for all node runners, especially validators.

All mainnet nodes require updating to this version to handle epoch 51817 and to proceed to epoch 51818.

On start-up, if necessary, the node will spend roughly 5 minutes recovering, before being ready to proceed. The network won't be able to function normally till a quorum of validators have updated.

Further details / explanation regarding the outage and the fix will follow in due course. In the mean time, the diff from v1.0.4 is available here.

Details for node set-up are on the docs site here. There should be no need for configuration changes as part of updating to this release. For those running natively, you should update both jar and native library from the attached assets.

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

[IGNORE] Please install v1.0.5

Not for running. Please run v1.0.5 instead.

Babylon (v1.0.4)

Summary

This is the v1.0.4 node, with a number of high-priority fixes.

This is a required update. All mainnet nodes require updating to this version to sync through state version 11584503. We recommend that all node runners, particularly validators, update as soon as practicable. Please read the key changes and important note below before starting to update.

Details for node set-up are on the docs site here. There should be no need for configuration changes as part of updating to this release. For those running natively, you should update both jar and native library from the attached assets.

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

Details

Key changes

• Ledger size pruning - includes a pruner of stale state tree nodes which reduces ledger disk usage by over ~50% (and state tree nodes specifically by ~80%). The remainder is mostly ledger proofs, for which we will be working on a pruner as a next priority.
• CVE Fixes in the docker image for CVE-2023-4911 and CVE-2023-38545
• Consensus tweaks to better cap timeout delays
• Metrics Improvements:
  • Various metrics for database size and record count (eg ng_raw_db_size by category label).
  • The ledger_recent_self_proposal_miss_count metric now requires a match on both validator address and public key to increment, so will no longer fire on your backup nodes.
  • There is a new rn_ledger_self_consensus_rounds_committed counter metric with round_resolution label of Successful, MissedByGap or MissedByFallback which may be easier to use for monitoring than the windowed ledger_recent_self_proposal_miss_count.
• Core API addition to add non fungible balance changes to LTS transaction outcomes.
• Key store fixes - We have updated to bouncy-castle 0.80, which fixes some of the issues we saw where certain re-created keystores could not be loaded by the node. As part of this change, we now permit an empty keystore password. If you previously ran with an empty keystore password, this was previously turned into the password "radix". In that case, to run your v1.0.4 node, you will need to run with RADIX_NODE_KEYSTORE_PASSWORD=radix.
• Bug fixes as part of this release:
  • Updating the key of an active validator to a wholly invalid key could cause errors interpreting the end of epoch event.
  • A global call made by an owned but unattached child component would be associated with an incorrect auth zone.
  • If a payload contained an Array<i128> or Map involving an i128 then it was not possible to re-encode it as a ScryptoValue.

Important note

The state pruner will take around 40 minutes to catch up / reduce disk space usage, and in this time will use a lot of IO. This may cause some delays in other parts of the node, and may cause your node to miss some proposals. You may wish to swap to a back-up node, or unregister for this hour or two, to mitigate this.

This process will be nearing its end when your node first outputs a log containing "Flushing the last buffer". This should correspond with state_manager::store::gc logs moving from every second or so to every minute. Note these logs are in the Rust part of the node, so you may not see them if you are only explicitly streaming your Java logs.

There may still be some async compaction / IO churn for a few minutes after this point, whilst RocksDB continues to clear up disk space, but your node should be okay to pick back up its main duties at this point.

Debugging

If your node fails to boot up with a log message of PKCS12 key store mac invalid - wrong password or corrupted file, this is likely because your previous keystore password was empty, which was previously implicitly replaced by the password "radix". Please update your keystore environment variable to RADIX_NODE_KEYSTORE_PASSWORD="radix" to run the node with this keystore, or regenerate the keystore with an empty password.

Babylon (v1.0.3)

Important note:

It is required to update mainnet nodes to v1.0.4.

---

Summary

This is the v1.0.0 node, but with the mainnet genesis included.

You can run this node as a mainnet node. Details for setting this node up as a production node are here: https://docs-babylon.radixdlt.com/main/node-and-gateway/node-introduction.html

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

Mainnet configuration

The mainnet-specific configuration for native nodes is:

network.id=1
network.p2p.seed_nodes=radix://node_rdx1qf2x63qx4jdaxj83kkw2yytehvvmu6r2xll5gcp6c9rancmrfsgfw0vnc65@52.212.35.209,radix://node_rdx1qgxn3eeldj33kd98ha6wkjgk4k77z6xm0dv7mwnrkefknjcqsvhuu4gc609@54.79.136.139,radix://node_rdx1qwrrnhzfu99fg3yqgk3ut9vev2pdssv7hxhff80msjmmcj968487uugc0t2@43.204.226.50,radix://node_rdx1q0gnmwv0fmcp7ecq0znff7yzrt7ggwrp47sa9pssgyvrnl75tvxmvj78u7t@52.21.106.232

Or for Docker:

RADIXDLT_NETWORK_ID=1
RADIXDLT_NETWORK_SEEDS_REMOTE=radix://node_rdx1qf2x63qx4jdaxj83kkw2yytehvvmu6r2xll5gcp6c9rancmrfsgfw0vnc65@52.212.35.209,radix://node_rdx1qgxn3eeldj33kd98ha6wkjgk4k77z6xm0dv7mwnrkefknjcqsvhuu4gc609@54.79.136.139,radix://node_rdx1qwrrnhzfu99fg3yqgk3ut9vev2pdssv7hxhff80msjmmcj968487uugc0t2@43.204.226.50,radix://node_rdx1q0gnmwv0fmcp7ecq0znff7yzrt7ggwrp47sa9pssgyvrnl75tvxmvj78u7t@52.21.106.232

All configuration starting with genesis should be removed, in particular, genesis.use_olympia/RADIXDLT_GENESIS_USE_OLYMPIA should be removed or set to false.

If configuring with the Node CLI, configure as a normal node, not in Olympia switchover mode.

Babylon (v1.0.0)

This build is the mainnet-ready node build for the Babylon mainnet launch.

For those setting up a mainnet node, this v1.0.0 version is a required update from rcnet-v3.1-r5 for a successful Babylon switchover.

License

The Babylon node code is released under the Radix License. Executable components are licensed under the Radix Node EULA.

Mainnet set-up documentation

Please see the babylon migration documentation for instructions on setting up the Olympia and Babylon nodes in preparation for Babylon mainnet.

If you've already set up rcnet-v3.1-r5 node, then you will need to:

• Stop your node running, swap the binaries, restart your node
• Run the version verification check below, and then check the logs are still correctly reporting "Successfully connected to the Olympia node..."

To swap the binaries, depending on your setup:

• EITHER update with the cli
• OR update your docker container version to v1.0.0
• OR update both jar and native library with the artifacts attached below)

Then restart your node, and verify that your node is running v1.0.0 by using the System API. Go inside your host / docker container, and run the following command (replacing 3334 with the System API port you have assigned to your babylon node, if you have provided an override from the default value). You should check this returns { "version": "v1.0.0" }:

curl http://localhost:3334/system/version

Finally, check that you are still getting logs saying: "Successfully connected to the Olympia node..." and your Babylon side is ready.

On the Olympia side:

• If you're a validator, please don't forget to signal readiness if you haven't already
• Double-check you are on version 1.5.0 of your Olympia node. If you are still on an older version or downgraded, now is the time to get back on 1.5.0

Stokenet set-up documentation

As of Friday 22nd September, our main public test network, Stokenet, has had its ledger wiped, and has been restarted on a fresh slate for Babylon, running the v1.0.0 node. Stokenet now replaces Zabanet as our recommend public testnet to run nodes on and use as builders/developers.

Wiping the ledger has has allowed us to add a Babylon faucet, remove useless ledger bloat, and start the validator set from scratch, allowing for healthier consensus without lots of stake assigned to offline nodes. Stokenet is now running the same version of the network which will go live later this week for the mainnet switchover.

If you wish to set up a testnet node on our Stokenet environment, then please see the documentation site for details on setting up a node.

Your stokenet node should not be set up in migration node. If you have previously run a stokenet node, you will need to:

• Wipe your ledger
• Remove your migration-specific configuration
• Update your binaries
• Update your seednodes as follows

The configuration to use is as follows. Note that stokenet genesis is hardcoded into the node, so doesn't need to be provided:

network.id=2
network.p2p.seed_nodes=radix://node_tdx_2_1qv89yg0la2jt429vqp8sxtpg95hj637gards67gpgqy2vuvwe4s5ss0va2y@13.126.248.88,radix://node_tdx_2_1qvtd9ffdhxyg7meqggr2ezsdfgjre5aqs6jwk5amdhjg86xhurgn5c79t9t@13.210.209.103,radix://node_tdx_2_1qwfh2nn0zx8cut5fqfz6n7pau2f7vdyl89mypldnn4fwlhaeg2tvunp8s8h@54.229.126.97,radix://node_tdx_2_1qwz237kqdpct5l3yjhmna66uxja2ymrf3x6hh528ng3gtvnwndtn5rsrad4@3.210.187.161

If setting up a validator, the docs are here, and you can then request a large stake on Discord.