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.