Node 10.5.1 provides a number of improvements over node 10.5.0. In particular, the Tracing system fixes the slotsMissed_int metric, while networking improvements include Windows socket fixes, reduced caching time of DNS lookup errors, refined PeerSharing configuration behavior (see networking changes below for details), and the deprecation of --non-producer-node in favor of --start-as-non-producer-node command line switch for starting the node. This release also removes a number of irrelevant binaries from the Node artifacts and adds tx-generator.

Benchmarking reports relevant to the 10.5.1 release can be found in this post on Cardano Updates.

System testing results for the 10.5.1 release can be found on the corresponding tag testing page.

Please note the changed default behavior for PeerSharing for relay nodes, but not for block producers. This reflects the recommendations for mainnet usage -- mainnet block producers may not meet the Praos performance guarantees if PeerSharing is enabled and IP will also be leaked, but this is not an issue for relays.

Known Issues​

There is a known bug when starting from a Byron snapshot. The node will reject the snapshot and replay the chain from the start. However the time it takes to replay the Byron era is small, and very few users are expected to need to start the node from a Byron snapshot. Therefore the issue will be fixed in 10.6.0.

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2, M3 or M4) processor
• 24GB of RAM when running with the InMemory backend, 8GB when running with the OnDisk backend (pending confirmation)
• 300GB of free storage (350GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 20.04 LTS, 22.04 LTS, 24.04 LTS; Mint 20, 21, 21.1, 21.2, 21.3, 22, 22.1; Debian 11, 12)
• Windows 64-bit (10, 11)
• MacOS 10.15, 11 (Big Sur), 12 (Monterey), 13 (Ventura), 14 (Sonoma), 15 (Sequioa)

GHC/Cabal supported versions​

• GHC 9.6
• Cabal 3.8/3.12
  ~~

Node 10.4.1 integrates UTxO-HD into the Cardano node. UTxO-HD is a rework of the Consensus layer of the node which allows the UTxO set to be stored either fully in-memory (as with previous node versions) or else on some external storage medium (e.g. SSD or HD). The latter lowers the memory requirements of the running node at the cost of some speed. This first version of UTxO-HD provides an LMDB backend, but future releases will incorporate a more fine-tailored backend based on LSM trees. More information on UTxO-HD can be found in the consensus website.

This release also provides fixes and enhancements to the tracing system, to the location of LedgerDB configuration options, and to the node CLI and API. It also updates the dependency on Plutus to 1.45.

System testing results for the 10.4.1 release can be found on the corresponding tag testing page.

Benchmarking reports relevant to the 10.4.1 release can be found in this post on Cardano Updates.

Important

Users migrating from a previous version of the node should read the migration guide to properly configure the node and convert the database such that a replay from genesis can be avoided. Mainnet block producers and associated relays should only use the V2InMemory UTXO-HD backend.

This version of the node is mainnet ready. It is recommended for production use using the in-memory backend only.

Warning

The LMDB backend has not yet been benchmarked. While it may provide sufficient performance for edge nodes (wallets, explorers, exchanges etc.) at a valuable reduction in memory usage, it should not be used for block producer or relay nodes on mainnet.

Known Issues​

There is a known bug with the experimental Ouroboros Genesis feature that is not yet recommended for mainnet use.
ChainSync Jumping (CSJ) is not disabled once a node is caught up. This should not affect normal operation of the syncing node, but does risk a DoS attack for the caught-up node. It will be corrected in a future release (Issue IntersectMBO/ouroboros-consensus#1490).

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2, M3 or M4) processor
• 24GB of RAM when running with the InMemory backend, 8GB when running with the OnDisk backend (pending confirmation)
• 300GB of free storage (350GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 9.6
• Cabal 3.8/3.12
  ~~

Node 10.3.1 primarily improves on performance: it improves execution speed, reduces memory usage and gives faster synchronisation times. In addition, it provides several enhancements to the new tracing system. It also provides support for light-weight checkpointing that is needed to enable ouroboros-genesis. Finally, it includes bug-fixes for a number of CLI commands. The docker images for node and submit-api have also received improvements to streamline operations.

System testing results for the 10.3.1 release can be found on the corresponding tag testing page.

Benchmarking reports relevant to the 10.3.1 release can be found in this post on Cardano Updates.

Known Issues​

• New tracing system: connectionManager_* metrics are incorrect; the underlying trace message ConnectionManagerCounters however logs the correct values.
• New tracing system: slotsMissed metric is incorrect; it falsely counts slots since the most recent block production as missed. However, the block producer does not actually miss a slot.
• GenesisMode: the optional peerSnapshotFile declaration in the topology file interprets relative paths with respect to node's binary directory rather than the topology file directory.
• There is a known bug with the experimental Ouroboros Genesis feature that is not yet recommended for mainnet use.ChainSync Jumping (CSJ) is not disabled once a node is caught up. This should not affect normal operation of the syncing node, but does risk a DoS attack for the caught-up node. It will be corrected in a future release (Issue IntersectMBO/ouroboros-consensus#1490).

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2, M3 or M4) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 9.6
• Cabal 3.8/3.12
  ~~

Node 10.2.1 provides support for the new tracing system and an initial integration of Ouroboros Genesis, a new feature which enables nodes to bootstrap from the network. It also provides a number of bug fixes and enhancements, including fixes and improvements to a number of CLI commands.

Benchmarking reports relevant to the 10.2.x release series can be found in this post on Cardano Updates.

Limitations​

Note that lightweight checkpoints are not integrated into node 10.2.1, so it is recommended to only use Ouroboros Genesis for testing purposes (on e.g. Preview or PreProd) and not on Mainnet.

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2, M3 or M4) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/9.6/9.10
• Cabal 3.8/3.12
  ~~

It is required that all Cardano stake pools and relays upgrade to this node version in order to mitigate a potential DoS attack following a hard fork to Protocol Version 10 ("Plomin" hard fork on mainnet). It is recommended that all other node users upgrade to this version. Node users who do not upgrade put themselves at risk of a potential DoS attack following the hard fork.

Node 10.1.4 is a mainnet-ready release of the Cardano node that is capable of crossing the Chang#2 ("Plomin") hard fork. It adds safeguards at the mempool level to block specific types of transaction that could lead to a DoS attack following the hard fork.

For further details about cardano-node 10.1.4 please see the release notes for node versions 10.1.1, 10.1.2 and 10.1.3.

Benchmarking reports relevant to the 10.1.4 release can be found in this post on Cardano Updates.

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2, M3 or M4) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/Cabal 3.8.1.0
  ~~

It is required that users upgrade to this version of the node.

Node 10.1.3 is a mainnet-ready release of the Cardano node that is capable of crossing the Chang#2 hard fork. This update addresses a ledger issue where DRep delegations could be removed under some conditions. This inadvertently affected the ability to withdraw rewards in Protocol Version 10, and changed the stake distribution for some DReps.

For further details about cardano-node 10.1.3 please see the release notes for 10.1.1, since significant upgrades were performed compared to previous versions of the node.

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/Cabal 3.8.1.0
  ~~

Node version 9.2.1 is a minor node release that improves the performance of certificate validation.
It is recommended that stake pool operators upgrade to this version of the node.

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/Cabal 3.8.1.0
  ~~

Node version 9.1.1 fixes an issue with node 9.1.0 where nodes would replay from the Genesis block if they were restarted when in the Conway era, as described in IntersectMBO/cardano-ledger#4589. If a node is upgraded to 9.1.1 from node versions 9.0.0/9.1.0 then no replay should be required. Updating from earlier versions might require one replay from Genesis.

It is recommended that all users upgrade to node version 9.1.1 when restarting a node.

Known Issues​

Cardano-cli shows the wrong sync percentage on query tip. Being fixed in IntersectMBO/cardano-cli#851. Solved in cardano-cli-9.3.0.0

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC/Cabal supported versions
  GHC 8.10.7/Cabal 3.8.1.0
  ~~

Cardano node 9.1.0 includes all the features that are necessary to be able to cross the upcoming Chang hard fork. The main change from node 9.0.0 is that node 9.1.0 requires a Conway genesis file at startup, where the genesis file was optional in node 9.0.0. This file is needed to cross the Chang hard fork. The necessary Conway genesis and other configuration files can be found here.

This release also incorporates a number of bug fixes and enhancements to the CLI and API, including a "query treasury" command, and changes to ensure compatibility with CIP69 and CIP119.

SPOs and other critical node users (exchanges, explorers, wallets, etc.) are strongly encouraged to upgrade to this version of the node. An update proposal to trigger the Chang hard fork will be submitted when sufficient SPOs and exchanges have upgraded to this version.

Known Issues​

Cardano-cli shows wrong sync percentage on query tip. Being fixed in IntersectMBO/cardano-cli#851.

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC/Cabal supported versions
  GHC 8.10.7/Cabal 3.8.1.0
  ~~

Node 8.9.4 fixes an issue that could lead to high system load when specific transactions were submitted to Cardano, in exactly the same way as node 8.12.1. This release is provided for users who are running older node versions and prefer not to upgrade to node 8.12.1.

There are no other changes compared to 8.9.3.

Known Issues​

None.

Haskell Security Advisory​

Haskell Security Advisory is a repository of security advisories filed against packages published via Hackage. cabal-audit output:

Found advisories:

dependency "base" at version 4.19.1.0 is vulnerable for:
  HSEC-2023-0007 "readFloat: memory exhaustion with large exponent"
  published: 2024-05-04 20:52:44 +0200
  https://haskell.github.io/security-advisories/advisory/HSEC-2023-0007
  No fix version available
  toml, parser, dos

dependency "process" at version 1.6.18.0 is vulnerable for:
  HSEC-2024-0003 "process: command injection via argument list on Windows"
  published: 2024-05-04 20:52:44 +0200
  https://haskell.github.io/security-advisories/advisory/HSEC-2024-0003
  Fix available since version 1.6.19.0
  windows

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/Cabal 3.8.1.0

~~

This version of the node fixes an issue with the peer sharing networking feature which prevents a node from sharing peers with others that it is connected to.

NOTE: As with 8.9.0, please refrain from updating all relays simultaneously; instead, we recommend spreading out the rollout over the upcoming weeks to minimize disruptions.

Known Issues​

Haskell Security Advisory Haskell Security Advisory is a repository of security advisories filed against packages published via Hackage. cabal-audit output:

Found advisories:

dependency "base" at version 4.14.3.0 is vulnerable for:
  HSEC-2023-0007 "readFloat: memory exhaustion with large exponent"
  published: 2024-04-08 23:04:08 +1000
  https://haskell.github.io/security-advisories/advisory/HSEC-2023-0007
  No fix version available
  toml, parser, dos

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/Cabal 3.8.1.0

~~

NOTE:​

Please refrain from updating all relays simultaneously; instead, we recommend spreading out the rollout over the upcoming weeks to minimize disruptions.

Cardano Node 8.9.0 is a release that introduces genesis lite a.k.a bootstrap peers. Please refer to here to read more about it. This version fixes a small bug on the dynamic block forging logic and also includes some overall improvements.

Benchmarking reports relevant to the 8.9.0 release can be found in this post on Cardano Updates.

Known Issues​

Technical Specification​

Minimum System Requirements​

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
• 24GB of RAM
• 200GB of free storage (250GB recommended for future growth)

Platforms​

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions​

• GHC 8.10.7/Cabal 3.8.1.0

~~

This Cardano node release is mainnet ready and updates the Plutus interpreter. All SPOs are encouraged to update, especially ones that are currently running Cardano node version 8.1.1.

Node 8.1.2 is a minor release of the Cardano node, which updates the Plutus interpreter.

Known Issues​

Please see list of 8.1.0 issues

Technical Specification​

Minimum System Requirements

• An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
• 24GB of RAM
• 150GB of free storage (250GB recommended for future growth)

Platforms

• Linux 64-bit (Ubuntu 18.04 LTS, 20.04 LTS; Mint 19.3, 20; Debian 10.3)
• Windows 64-bit (8.1, 10, 11)
• MacOS 10.13, 10.14, 10.15, 11

GHC/Cabal supported versions

• GHC 8.10.7/Cabal 3.8.1.0

~~

Node 8.0.0 is a major release of the Cardano node that adds initial, experimental, support for the Conway ledger era (Protocol Version 9.0). It includes some additional CLI commands, bug fixes, and network configuration options. SPOs are recommended to deploy this version on all their nodes. This version of the Cardano node:

Introduces the Conway era (Voltaire) as a developmental hard fork. Note: the node does not have any Voltaire features yet, this just prepares the way by creating the transaction formats and providing the ability to hard fork into the era. Adds a governance action for SPO polls (cardano-cli governance poll) that the Cardano Foundation will use to conduct an SPO survey Introduces a fairness improvement into the mempool logic Adds query commands to inspect metrics and data in mempool Allows the network to be defined via CARDANO_NODE_NETWORK_ID instead of needing to be passed in every CLI query Adds more detailed output in the query tip CLI command Allows modification via configuration file of connection limits Provides versioned serialization formats for ledger Provides a ledger API Changes the tracking of deposits It also includes some bug fixes and performance improvements.

IMPORTANT: On mainnet, P2P networking is only intended to be ran on a single relay at this time. Please continue to run any other relays with P2P disabled using the legacy topology.

Please note that this version contains breaking changes

Needs newer libsodium-vrf revision dbb48cce5429cb6585c9034f002568964f1ce567

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.

KES key and operational certificate renewal completed. Operators generate KES files on a regular basis and issue operational certificates with new KES files approximately every 90 days to operate the pool. Blocks cannot be generated after expiration.