04 Apr 18:06

f0b4ac8

Cardano Node 1.35.7

Node 1.35.7 is a bug fix release that addresses an issue with the legacy network stack connecting to a P2P relay. SPOs are recommended to deploy this version on all their nodes.

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

NOTICE Minimum resources were adjusted in this release due to chain growth.

Please note that this version contains no breaking changes

Known Issues

Shelley ledger era Tx body in CDDL format is not supported by some CLI commands (#3688)
Cardano-cli computes wrong collateral return output for multiple occurrences of collateral inputs (#4744)
A hot -> warm -> hot busy demotion / promotion cycle is not fixed in this release (#4385)
cardano-submit-api can't handle transactions (#4829)
Please see here for other known issues. None of these is considered to be a blocker.
They will be addressed in future releases.

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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Docker image
Static binaries:
- linux
- windows
- Mac
Configuration files

Documentation

Changelogs

Node

NONE

Consensus

NONE

Ledger

NONE

Network

Fixed interoperability bug in the legacy (non-p2p) networking stack exposed by p2p nodes (IntersectMBO/ouroboros-network#4467).

Cardano-cli

NONE

Cardano-api

NONE

Submit-api

NONE

Sign off

Role	Approval
Cardano Head of Engineering	✔️
Cardano Head of Product	✔️
Test Engineer	✔️
Site Reliability Engineer	✔️
Release Engineer	✔️

Assets 2

16 Mar 14:01

disassembler

1.35.6

07b0c71

Cardano Node 1.35.6

Node 1.35.6 is a release adding P2P support without need of development network protocols when EnableP2P is set to true. The legacy topology is still supported as a parallel mode of operation. This release is based on the release/1.35 branch so has no changes not related to P2P included.

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

P2P Configuration

To run a node in P2P mode set EnableP2P to true (the default is False) in the configuration file. You will also need to specify the topology in a new format which is described here. There are a few new tracers and configuration options which you can set (listed below by component):

Outbound Governor

The outbound governor is responsible for satisfying targets of root peers, known (cold, warm and hot), established (warm & hot) and active peers (synonym for hot peers) and local root peers. The primary way to configure them is by setting the following options:

TargetNumberOfRootPeers (default value: 100) - a minimal number of root peers (unlike other targets this one is one sided, e.g. a node might have more root peers
TargetNumberOfKnownPeers (default value: 100) - a target of known peers (must be larger or equal to TargetNumberOfRootPeers)
TargetNumberOfEstablishedPeers (default value: 50) - a target of all established peers (including local roots, ledger peers)
TargetNumberOfActivePeers (default value: 20) - a target for hot peers which engage in the consensus protocol

Let us note two more targets. In the topology file you may include local root peers. This is a list of groups of peers, each group comes with its own valency. The outbound governor will maintain a connection with every local root peer, and will enforce that at least the specified number of them (the valency) are hot. Thus the TargetNumberOfKnownPeers , TargetNumberOfEstablishedPeers and TargetNumberOfActivePeers must be large enough to accommodate local root peers.

The following traces can be enabled:

TracePeerSelection (by default on) - tracks selection of upstream peers done by the outbound-governor. Warm peers are ones with which we have an open connection but don't engage in consensus protocol, hot peers are peers which engage in consensus protocol (via chain-sync, block-fetch and tx-submission mini-protocols), cold peers are ones which we know about but the node doesn't have an established connection. Note that the notions of hot, warm and cold are only related to usage of initiator sides of mini-protocols in a connection (which can be either inbound or outbound).
TracePeerSelectionCounters (by default on) - traces how many cold / warm / hot / local root peers the node has, it's also available via ekg.
TracePeerStateActions (by default on) - includes traces from a component which executes peer promotion / demotions between cold / warm & hot states.
TracePublicRootPeers (by default off) - traces information about root / ledger peers (e.g. ip addresses or dns names of ledger peers, dns resolution)
DebugPeerSelectionInitiator and DebugPeerSelectionInitiatorResponder (by default off) - a debug tracers which log the information about current state of the outbound governor.

At this point haddock documentation of the outbound governor is available.

Inbound Governor

The inbound governor is maintaining responder side of all mini-protocols. Unlike the outbound governor it is a purely responsive component which reacts to actions of remote peer (its outbound governor).

TraceInboundGovernor (by default on) - traces information about inbound connection, e.g. we track if the remote side is using our node as warm or hot peer, traces when we restart a responder.
TraceInboundGovernorCounters (by default on) - traces number of peers which use the node as cold, warm or hot (which we call remote cold, remote warm or remote hot). Note that we only know if a peer is in the remote cold state if we connected to that peer and it's not using the connection. This information is also available via ekg.
TraceInboundGovernorTransitions (by default on) - a debug tracer which traces transitions between remote cold, remote warm and remote hot states.

The inbound governor is documented in The Shelley Networking Protocol (section 4.5).

Connection Manager

Connection manager tracks the state of all tcp connections, and enforces various timeouts, e.g. when the connection is not used by either of the sides. The following traces are available:

TraceConnectionManager (by default on) - traces information about new inbound or outbound connection, connection errors.
TraceConnectionManagerCounters (by default on) - traces the number of inbound, outbound, duplex (connections which negotiated P2P mode and can use a connection in full duplex mode), full duplex (connections which run mini-protocols in both directions, e.g. at least warm and remote warm at the same time), unidirectional connections (connections with non p2p nodes, or p2p nodes which configured themselves as initiator only nodes).
TraceConnectionManagerTransitions (by default on) - a low level traces which traces connection state changes in the connection manager state machine.

The connection manager is documented in The Shelley Networking Protocol (section 4).

Ledger Peers

Ledger peers are the relays registered on the chain. Currently we use square of the stake distribution to randomly pick new ledger peers. You can enable TraceLedgerPeers (by default off) to log actions taken by this component.

Server

The accept loop. You can enable TraceServer to log its actions or errors it encounters (by default it is off, however we suggest to turn it on) .

Please note that this version contains no breaking changes

Known Issues

Shelley ledger era Tx body in CDDL format is not supported by some CLI commands (#3688)
Cardano-cli computes wrong collateral return output for multiple occurrences of collateral inputs (#4744)
A hot -> warm -> hot busy demotion / promotion cycle is not fixed in this release (#4385)
Please see here for other known issues. None of these is considered to be a blocker.
They will be addressed in future releases.

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)
16GB of RAM
120GB of free storage (200GB 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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Docker image
Static binaries:
- linux
- windows
- Mac
Configuration files

Documentation

Changelogs

Node

NONE

Consensus

Report consensus initialisation errors (#4015).

Ledger

NONE

Network

Split WarningDevelopmentNetworkProtocolVersions into WarningDevelopmentNodeToNodeVersions and WarningDevelopmentNodeToClientVersions (#4691).
Provided NodeToNodeVersion and NodeToClientVersion JSON instances (#4691).
Modified P2PWarning, it now sais: You are using an early release of peer-to-peer capabilities, please report any issues. (#4691).
Removed not needed P2PWarningDevelopmentNetworkProtocols (#4691).
New p2p topology file format (#4559).
Fixed warm -> cold demotion (IntersectMBO/ouroboros-network#4163).
Added PeerGSV to [SendFetchRequest](https://input-output-hk.gi...

Assets 2

27 Jan 13:01

disassembler

1.35.5

8762a10

Cardano Node 1.35.5

Node 1.35.5 is a maintenance release addressing a fix in ledger internal data structures.

Please note that this version contains no breaking changes

Known Issues

Shelley ledger era Tx body in CDDL format is not supported by some CLI commands (#3688)
Cardano-cli computes wrong collateral return output for multiple occurrences of collateral inputs (#4744)
Please see here for other known issues. None of these is considered to be a blocker.
They will be addressed in future releases.

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)
16GB of RAM
120GB of free storage (200GB 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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Docker image
Static binaries:
- linux
- windows
- Mac
Configuration files

Documentation

Changelogs

Node

NONE

Consensus

*NONE

Ledger

Fixes internal data structure representation

Network

NONE

Cardano-cli

NONE*

Cardano-api

NONE

Submit-api

NONE

Sign off

Role	Approval
Cardano Head of Engineering	✔️
Test Engineer	✔️
Site Reliability Engineer	✔️
Release Engineer	✔️

Assets 2

07 Nov 18:06

disassembler

1.35.4

ebc7be4

Cardano Node 1.35.4

Node 1.35.4 supports the use of SECP256K1 elliptic curves via new Plutus primitives at protocol version 8. It also includes some CLI improvements, including changing the default ledger era to Babbage for transaction commands.

Please note that this version contains breaking changes, as listed below:

Breaking Changes

With this version, all transactions are created in the Babbage ledger era format if --<ledger-era>-era is not passed as an option.

Known Issues

Shelley ledger era Tx body in CDDL format is not supported by some CLI commands (#3688)
Please see here for other known issues. None of these is considered to be a blocker.
They will be addressed in future releases.

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)
16GB of RAM
120GB of free storage (200GB 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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Docker image
Static binaries:
- linux
- windows
- Mac
Configuration files

Documentation

Changelogs

Node

Update Plutus to version 1.0.0.1 to enable SECP256K1 primitives at protocol version 8
Benchmark results for SECP256K1 Primitive
Update cardano-crypto-class to version 2.0.0.0.1 to add SECP256K1 crypto primitives
Update block header advertised version in babbage to 8.0

Consensus

The maximum major protocol version of the Cardano protocol is now correctly
based off of Babbage instead of Alonzo.

Ledger

NONE

Network

NONE

Cardano-cli

Improve memory efficiency of query ledger-state command (PR4205)
Update transaction build command to automatically calculate total and return collateral values(PR4198)
Allow reading and writing text envelope files from pipes(PR4384)
Update transaction view command to render inline datums and reference inputs (PR4089)
Switch default era in cardano-cli from Alonzo to Babbage (PR4485)
For the transaction build and transaction build-raw commands, always use ledger's CDDL format for transaction body creation.
Remove the cli-format flag and make --cddl-format deprecated and hidden
(PR 4303 PR 4617)
Allow reading signing keys from a pipe (PR 4342)

Cardano-api

Expose Key interface via Cardano.Api.Shelley (PR4048)
Append, not prepend change output when balancing a transaction (PR4343)
Expose convenience functions executeQueryCardanoMode, determineEra, constructBalancedTx and queryStateForBalancedTx (PR 4446)

Submit-api

NONE

Sign off

Role	Approval
Cardano Head of Engineering	✔️
Test Engineer	✔️
Site Reliability Engineer	✔️
Release Engineer	✔️

Assets 2

11 Aug 17:12

LaurenceIO

1.35.3

950c4e2

Cardano Node 1.35.3

Node 1.35.3 fixes some important issues with previous versions of the node and provides some CLI enhancements. The node provides full Vasil era capabilities.

Node 1.35.3 adds important functionality that will enable the use of new Plutus capabilities
following the Vasil hard fork, including node and CLI support for:

Reference Inputs (CIP 31)
Inline Datums (CIP 32)
Reference Scripts (CIP 33)
Collateral Output (Draft CIP 40)
Plutus v2 primitives and the associated new cost model

It also includes significant improvements to the logging/monitoring, and networking codebases, as well as significant memory and time performance improvements, including the first implementation of diffusion pipelining, and reduced VRF checks, as well as several improvements to the ledger.

Please note that this version contains breaking changes, as listed below, specifically with respect to operational certificates
on the CLI. Stake pool operators may need to update their management scripts to accommodate this change.

Breaking Changes

With this version, the ledger state will need to be replayed from the genesis block, meaning that the initial synchronisation may be slow. Users should account for this when deploying the node.
Restricted opcert issue number increment, as of Babbage. Previously op cert issue numbers could be anything, provided it was larger than previously used numbers. Now the op cert counter must be exactly one more than the previously used op cert.
The decentralisation ('d') updatable protocol parameter has been removed, as of Babbage. It will no longer be possible to change this from its current setting (fully decentralised).
Bugfix: transaction validity intervals will actually be limited, as of Babbage.

Known Issues

Shelley era Tx body in CDDL format is not supported by some CLI commands (#3688)
Please see here for known issues.

None of these issues are considered to be blockers for the mainnet hard fork;
they will be addressed in future releases.

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)
16GB of RAM
100GB of free storage (150GB 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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Documentation

Changelogs

Node

RTS workaround converting SIGTERM into SIGINT (#3641)
Install a dummy SIGHUP handler for non p2p mode (#3896)
Add --shutdown-on-slot-synced test and ensure ExitSuccess (#3670)
cardano-node: implement --shutdown-on-block-synced (#3932)
Update dependencies and pins. (#3700)
Propagate protocol in block type (#3818)
Create VRF signing key file with correct permissions (#1948)
Fix for eliding of the ChainDB tracer (#4038)
Tracing infra updates:
- Configuration structure rework, for better UX: (#3867)
- Rework implementation to eliminate prototypes from trace definitions (#3731)
- Fix tracing config to allow selection of the new tracing system (#3655)
- Register GC metrics. (#3858)
- Metrics are no longer impacted by severities and frequency limits (#3876)
- Porting ekg-direct metrics to new-tracing (#3873)
- Node state data point extensions and fixes: (#3854, #3656)
- Old peers tracing was erroneously called in new tracing (#3880)
- Remove unused constraints from TraceConstraints (#3822)
- Properly init trace forwarding when needed. (#3634)
cardano-tracer:
- Format fixes for forwarded traces: (#3640, #3654, #3660, #3671).
- Test fixes: (#3714)
- Remove symlink, fix logs cut off. (#3930)
- Fix bug with empty line (#3962)
- RTView, a web performance dashboard, as part of cardano-tracer (#3852)
- RTView: CPU usage (GC + App) as pct, https by default, errors export (#3934)
Documentation updates;
- Update Haskell installation method and mention libsecp256k1 (#3796)
- Update cardano-node-cli-reference.md (#3630)
- Documentation improvements for new tracing. (#3834, #3842)
- Recommended system requirements. (#4005)
- Further explain the libsodium installation (#4000)
Various workbench, build, testing and benchmarking infrastructure improvements. (#3638, #3643, #3705, #3789, #3812, #3824, #3941, #3851)
Bump block header protocol version (#4260, #4211)
Update dependencies (#4242, #4220, #4146)

Consensus

The obsolete node check in the new 'Praos' protocol was not performing the check that was intended. It is supposed to check that the current protocol version is no greater than the max major protocol version. It was instead checking that the max major protocol version was not greater than the protocol version listed in the block header (which is currently not supposed to have any semantic meaning, and is used to manually check the readiness of the network for a hard fork). Note that this mistake is only in the Praos protocol, not in TPraos. The consequence of this incorrect check is that nodes will not properly halt after a hard fork when they do not have the required software for the hard fork. (#3891)
Block diffusion pipelining (#3688, #3742, #3752, #3688)
Moving from two VRF checks to one, as of Babbage (#3595)
Restricted opcert issue number increment, as of Babbage (#3595)
New function getOpCertCounters (#3781)
Bugfix: transaction validity intervals will actually be limited, as of Babbage (#3754)
Simplification: Babbage will run proper Praos protocol instead of Transitional Praos, since d will remain at 0 (#3595)
protocol: add PraosProtocolSupportsNode class (#3758)
Provide an EpochInfo that can fail to ledger. (#3770)
Add COMPLETE pragma for FallingEdge pattern synonym (#3766)
Simplification: remove stale handshake versions (#3696, #3699)

Ledger

Implementing the Babbage era. (#2560, #2599, #2602, #2613, #2618, #2619, #2629, #2633, #2643, #2645, #2654, #2661, #2664, #2666, #2678, #2681, #2689, [#2694](https://github.com/input-output-hk/cardano-ledg...

Assets 2

07 Mar 15:40

LaurenceIO

1.34.1

73f9a74

Cardano Node 1.34.1

Node version 1.34.1 is a minor release that fixes two issues:

the tracer configuration settings were not respected, meaning that tracing was always enabled;
the node start time and basic information (version etc) were not recorded in EKG logs.

Known Issues

To avoid increased synchronisation times, we recommended that Windows users DO NOT upgrade to this node version. We recommend instead that they continue to run node 1.33.0. Future releases will address this issue which is specific to 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)
12GB of RAM
50GB of free storage

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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Docker image
Hydra binaries
⚠️ Please note that due to an issue with syncing, Windows users should not upgrade to this release
Configuration files

Documentation

Changelogs

Fixed issues

Fix tracer config mismatches #3668
Fix #3664: Restore legacy metrics #3676

Sign off

Role	Approval
Technical Lead	✔️
QA Engineer	✔️
Ops	✔️
Release Manager	✔️

Assets 2

28 Feb 20:00

LaurenceIO

1.34.0

c23d5d3

Cardano Node 1.34.0

Node version 1.34 brings a number of important new features that will benefit stake pool operators and other users, including

a new tracing mechanism
a new command to query the local mempool
a new command to provide stake pool operators with their leadership schedule
a new command to check the validity of stake pool operational certificates (including verifying the KES period)
support for CBOR encoding in transaction build commands,
an option to output transaction bodies in ledger-compliant CDDL format,
an option to calculate the cost of executing a Plutus script,
incremental transaction signing.

It also includes a number of stability improvements, plus improvements to the performance of Plutus scripts.

Known Issues

To avoid increased synchronisation times, we recommended that Windows users DO NOT upgrade to node version 1.34.0. We recommend instead that they continue to run node 1.33.0. Future releases will address this issue which is specific to 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)
12GB of RAM
50GB of free storage

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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Docker image
Hydra binaries
⚠️ Please note that due to an issue with syncing, Windows users should not upgrade to this release
Configuration files

Documentation

Changelogs

Node

Separate the logic for shutdown via IPC and shutdown on reaching a specified slot. (#3320, #3508)
Tests for certifying and withdrawing Plutus scripts. (#3318)
Various documentation updates. (#2875, #2884, #2839, #2904, #3476, #3482, #3486, #3500, #3502, #3542, #3553, #3573, #3603)
Integrate the new tracing system in cardano-node. (#3450, #3496, #3497, #3498, #3570)
The stake credential history tool now additionally displays the protocol version. (#3409)

Consensus

Ledger

Network

Add a new mini-protocol to query the local mempool. (#3404)
Stop the MUX in case of miniprotocol timeout. This can happen if a peer is demoted to cold, and could result in lingering miniprotocols in an unknown state if the peer is again promoted. (#3575, #3580)
Avoid ordering peers based upon peerid in block fetch. Ordering based on peerid would often result in all nodes choosing the same second, third choice peers etc. These are now based on a node-local random ordering. (#3535)

Cardano-cli

Add a prettier rendering of update proposals. (#3208)
Add support for CBOR-encoded blobs in the transaction build and transaction build-raw commands. (#3483)

Implement a leadership-schedule command. This can calculate a stake pool's leadership schedule for the current and following epoch. It requires access to the VRF signing key for that stake pool. (#3464, #3494)

> cardano-cli query leadership-schedule \
   --testnet-magic 42 \
   --genesis example/shelley/genesis.json \
   --stake-pool-id  pool12t0y7agkqct89pf00eeytkvfjlquv76tjy27duannan9w63ckxv \
   --vrf-signing-key-file example/node-pool1/shelley/vrf.skey
   --current

   SlotNo                          UTC Time
   --------------------------------------------------------
   4073                   2021-12-29 17:26:54.998001755 UTC
   4126                   2021-12-29 17:27:00.298001755 UTC
   4206                   2021-12-29 17:27:08.298001755 UTC
   4256                   2021-12-29 17:27:13.298001755 UTC
   4309                   2021-12-29 17:27:18.598001755 UTC
   4376                   2021-12-29 17:27:25.298001755 UTC
   4423                   2021-12-29 17:27:29.998001755 UTC
   4433                   2021-12-29 17:27:30.998001755 UTC

The CLI now supports outputting transaction bodies in ledger-compliant CDDL in the transaction build and transaction build-raw commands. This is specified by using the --cddl-format flag. (#3505)

Implement a kes-period-info command in the CLI. This checks that your operational certificate is correct. It checks:

The counters match what is in the node's protocol state
The KES period in the operational certificate is correct (based on the current slot). (#3459, #3572, #3599)

> cardano-cli query kes-period-info --testnet-magic 42  \
  --op-cert-file example/node-pool1/shelley/node.cert
✓ The operational certificate counter agrees with the node protocol state counter
✓ Operational certificate's kes period is within the correct KES period interval
{
    "qKesNodeStateOperationalCertificateNumber": 6,
    "qKesCurrentKesPeriod": 404,
    "qKesOnDiskOperationalCertificateNumber": 6,
    "qKesRemainingSlotsInKesPeriod": 3760228,
    "qKesMaxKESEvolutions": 62,
    "qKesKesKeyExpiry": "2022-03-20T21:44:51Z",
    "qKesEndKesInterval": 434,
    "qKesStartKesInterval": 372,
    "qKesSlotsPerKesPeriod": 129600
}

The CLI now displays collateral inputs in a nicer fashion. (#3463)
The transaction sign command now allows for incremental signing by providing an already signed transaction via --tx-file. This allows more easily adding multiple signatures to a transaction. (#3549)

The transaction build command now supports an option (--calculate-plutus-script-cost) to compute the cost for included scripts. (#3589)

cardano-cli transaction build \
--alonzo-era \
--cardano-mode \
--testnet-magic "$TESTNET_MAGIC" \
--change-address "$utxoaddr" \
--tx-in "$plutusutxotxin" \
--tx-in-collateral "$txinCollateral" \
--tx-out "$dummyaddress+10000000" \
--tx-in-script-file "$plutusscriptinuse" \
--tx-in-datum-file "$datumfilepath"  \
--protocol-params-file "$WORK/pparams.json" \
--tx-in-redeemer-file "$redeemerfilepath" \
--calculate-plutus-script-cost "$WORK/create-datum-output.scriptcost"

> cat $WORK/create-datum-output.scriptcost
[
  {
      "executionUnits": {
          "memory": 1700,
          "steps": 476468
      },
      "lovelaceCost": 133,
      "scriptHash": "67f33146617a5e61936081db3b2117cbf59bd2123748f58ac9678656"
  }
]

Cardano-api

Expose lovelaceToTxOutValue. (#3381)
Implement two functions: currentEpochEligibleLeadershipSlots and nextEpochEligibleLeadershipSlots to get the leadership slots for the current/next epoch respectively. (#3464, #3494)
Add a capi library to support using the cardano node as a C library in other software. (#3501)
fromShelleyAddr now takes an explicit ShelleyBasedEra parameter to determine the era. The previous behaviour (with an implicit IsShelleyBasedEra constraint) can be obtained with fromShelleyAddrIsSbe. (#2253, #3606)

Plutus

Plutus script performance improvements

Deprecated features

Fixed issues

Fix some spelling errors in the CLI help text. (#3499)
Fix a spurious assertion failure that could be seen with regards to demoted hot peers. (#3588)

Sign off

Role	Approval
Technical Lead	✔️
QA Engineer	✔️
Ops	✔️
Release Manager	✔️

Assets 2

07 Jan 15:48

LaurenceIO

1.33.0

814df2c

Cardano Node 1.33.0

Cardano Node version 1.33.0 is a performance-focused release, bringing significant improvements in sync time, block propagation time, and reduced memory usage. Incremental stake aggregation and reward calculation allows much more uniform computation across the epoch, reducing the likelihood of spikes in CPU usage during the reward calculation period and so improving the consistency of block production.

In addition, more information is provided during node initialisation, and changes have been made to improve the handling of unexpected shutdowns when initialising the node. DNS support for IPv6 has been added. Tracing has been provided for Plutus scripts, making it easier to debug failure conditions.

Breaking Changes

With this version, the ledger state will need to be replayed from the genesis block, meaning that the initial synchronisation may be slow. Users should account for this when deploying 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)
12GB of RAM
50GB of free storage

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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Documentation

Changelogs

Node

Improvements to the tx-generator internal testing infrastructure. (#3425, #3426, #3427, #3436)
Disable idle GC in the default NixOS service. This matches options we have set by default in other deployments. (#3349)
Support for using TxIn as a key in JSON maps. (#3438)
Allow configuring the number of connections to accept. (#3435)

Consensus

Move the transitional praos protocol into its own package, in preparation for introducing a new version of the protocol in Babbage. (#3513)
Improve logging during node startup/chainDB initialisation. (#3505, #3506, #3518)
Various changes to the initialisation of the ChainDB. The intent of these changes is to handle the situation when the node receives a shutdown instruction during initialisation. Before these changes, the node would either fail to respond to the signal until initialisation was complete, or a supervisor process would notice this and send SIGKILL, resulting in an unclean shutdown. Following these changes, the node should gracefully handle signals sent during DB initialisation. (#3452, #3514)
Various improvements to the db-analyser tool. (#3471)
Expose an additional query for information relevant to reward processing. This offers current-epoch information to help clients make delegation preferences. (#3423)

Ledger

Preparatory work factoring out the transitional Praos protocol in preparation for the introduction of a new protocol in the Babbage release. (#2524)
Provide more information in the case of extraneous script witnesses being provided. (#2527)
Significant work to improve memory usage for the in-memory ledger state. (#2520, #2530, #2534, #2540, #2552, #2553, #2557, #2567, #2573, #2577, #2580, #2583)
Add a new tool to benchmark the ledger state. (#2532, #2535)
Remove the amount of state stored in the reward pulser. This change will require a rebuild of the ledger state (e.g. replay from genesis). (#2533)
Add an additional check when evaluating an (unsubmitted) transaction to determine the amount of ExUnits to specify. (#2522)
Distinguish between rewards earned as a pool member and as a pool operator in the ledger events. (#2536, #2549)
From protocol version 7, we no longer exclude from rewards those who are not registered at the start of the reward calculation. Those not registered when the rewards are paid out are still filtered, naturally. (#2569)
Add a stricter function for decoding addresses, which disallows extra bytes. These functions are provided for use by downstream tools. (#2556)
The reward calculation (which adds significant work to the middle portion of the epoch) is now computed incrementally by stake credential. Previously this was done by stake pool, but this had a couple of issues: it didn't allow the computation to be spread across the full range of slots, and it was significantly non-uniform: some stake pools are much bigger than others. This new computation should be more uniform and saturate the full slot range, resulting in more predictable and consistent resource usage. (#2542, #2585)
Add benchmarking to CI. (#2561, #2568)
Add tracing to Plutus script execution. (#2554)
Add the first draft of the Babbage formal spec. (#2559)
Document the construction of the script integrity hash. (#2576)
Compute the stake aggregation incrementally. Previously this was computed when a snapshot was taken, which resulted in a CPU spike. It is now continually maintained as transactions are processed. (#2538)

Network

Don't block when unregistering expired connections. (#3526)
Fix the rendering of cardano-ping messages. (#3529)
Various improvements to the pruning policy. (#3495, #3499)
Consider speed of block provision (in addition to speed of header provision) when ranking peers. (#3500)
DNS support for IPv6. (#3489)

Cardano-cli

Cardano-api

Deprecated features

Fixed issues

Miscellaneous fixes. (#2529, #2539, #2541, #2543, ...

Assets 2

13 Dec 16:18

LaurenceIO

1.32.1

4f65fb9

Cardano Node 1.32.1

Cardano Node version 1.32.1 introduces a number of improvements and enhancements to improve the usability of the Cardano node. Native asset name rendering has been changed in order to eliminate problems caused by non-printing characters, CLI commands now default to the Alonzo era, and default values have been added to simplify startup where a genesis file is not supplied (eg in test or standalone settings). Additional logging is available during node startup, enabling progress to be tracked more easily, and statistics counting has been disabled in order to reduce noise. Limits have been added to mini protocols. There is better rendering of some trace messages.
Documentation has also been improved in various areas.

This version also adds experimental support for peer-to-peer network. It is unverified and unsupported, and hence not recommended to be enabled in production.

Breaking Changes

Asset Name Format Change. Note that asset names are now output in hex format when querying UTxO entries. Any user who is relying on asset names to be represented as ASCII text will need to change their tooling. As a temporary transitional solution, it is possible to use Cardano-cli version 1.31 with node version 1.32.1 if desired, or to continue to use node version 1.31. This will not be possible following the next hard fork (which is expected in early 2022).
CLI default era change. CLI commands now default to the Alonzo era (previously Mary era). Tooling may need to be revised if it was relying on the default.

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)
12GB of RAM
30GB of free storage

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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Documentation

Changelogs

Node

Miscellaneous documentation updates. (#3138, #3286, #3323, #3342, #3343, #3348)
Update a number of scripts to use the $NETWORK_MAGIC environment variable. (#3148)
Integrate p2p networking functionality. (#3363)

Add additional logging to node startup. (#3380)

Note that the existing "nodeStartTime" counter still exists, but will ultimately be deprecated. The startup time is now logged in the following format:

{
  "thread": "5",
  "sev": "Notice",
  "data": {
    "startupTime": "1638866965"
  },
  "loc": null,
  "env": "1.31.0:be123",
  "msg": "",
  "app": [],
  "host": "waldorf",
  "at": "2021-12-07T08:49:24.22Z",
  "ns": [
    "cardano.node.nodeconfig"
  ],
  "pid": "33952"
}

Block delay counters are now not collected until the node has finished starting. Statistics collected during node startup would only add noise to the delay CDF. (#3386)

Consensus

Add per-miniprotocol byte limits, for things like how big a block arriving from the network may be. (#3409)
Various documentation updates. (#3435, #3461, #3446)

Ledger

Network

Early, unverified and unsupported p2p networking capabilities. Do NOT use in production. (#3467)

Cardano-cli

Default CLI commands to the Alonzo era. (#3339)
Add defaults for building the Alonzo genesis. (#3346)

Cardano-api

Asset names are now rendered in a more consistent fashion in JSON output. Previously names which happened to be valid ASCII were rendered as such, and ones which were not resulted in unprintable characters. Now all names are rendered as hex. Future clients may choose to additionally render ASCII names if plausible to do so. (#3211)
Expose ledger events via the ledger state API. (#3374)

Deprecated features

Fixed issues

Fix the rendering of RemoteConnectionId in trace messages. (#3199)

Sign off

Role	Approval
Technical Lead	✔️
QA Engineer	✔️
Ops	✔️
Release Manager	✔️

Assets 2

10 Nov 16:46

LaurenceIO

1.31.0

2cbe363

Cardano Node 1.31.0

Cardano node version 1.31.0 introduces a number of new features and provides performance improvements, including
reducing default logging information, and optimising memory and time behaviour. It also provides support for improved rewards logging in db-sync, includes a new CLI command to query stake pools, enhances the transaction build CLI command, fixes an issue where connections were dropped when using query tip, and provides various other CLI enhancements. It allows signatures to be specified when spending from pre-Plutus time-lock/multi-signature scripts, improves error logging for Plutus scripts, adds new logging modes, allows the size of the mempool to be configured, provides support for multiple versions of Plutus, and improves networking behaviour and robustness.
It is recommended that all users upgrade to this new version.

Breaking Changes

Update min utxo calculation cli command #3181
calculate-min-req-utxo requires a transaction output (TxOut era) instead of a Value in order to calculate the min required UTxO in the Alonzo era. This is required in the Alonzo era, and the change is made everywhere for consistency.

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)
12GB of RAM
20GB of free storage

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

Supported roles

Platform	Block Production	Relay	Client (Desktop)
Linux	✔️	✔️	✔️
Windows	❌	❌	✔️
MacOS	❌	❌	✔️

Downloads

Documentation

Changelogs

Node

Additional verification for the configuration files:
- Added a CI check that the configuration files in git match those produced during the nix build. (#3222)
- Add a test that the configuration file is valid. (#3236)
Various documentation updates. (#3060, #3120, #3142, #3191, #3243, #3265, #3284)
Introduce the trace-dispatcher library. This is built to replace the existing iohk-monitoring-framework. (#3073)
Add an example using a Plutus script as a stake credential. (#3162)
Don't inline a call to maybeToStrictMaybe during translation of ProtocolParameters. This turns out to trigger a GHC bug, resulting in extremely high compilation time. (#3275)
Introduce a YAML version of the mainnet configuration file, which can and has been commented to explain the various options. (#3269)
Add various additional metrics:
- About block propagation. (#2476)
- Tracking how many tips a node has served to downstream peers. (#3300)
- Counting the number of forks seen. (#3305)
Add the ability to configure the mempool capacity override. This allows an individual node operator to alter the maximum size of their mempool along various axes (size, execution units). (#3273)
Fix the verbosity of some log messages, which was causing excess detail in the node logs. (#3046)

Consensus

Improved documentation. (#2957, #3279)
Removed strictness annotations in traces. (#3244)
Exposing the ledger event logger. (#3292)
Supporting Alonzo protocol version. (#3347)
Overhauling the db analyser tool. This will allow the ledger team to run micro benchmarks without noise from other layers (like networking). (#3337)
Add additional capabilities in the db-analyser. (#3376, #3379, #3397, #3400, #3414, #3418)
Add a new version (10) of the node to client protocol, with two new queries: GetChainBlockNo and GetChainPoint. (#3346)
Expose the ability to override the mempool capacity. (#3413)

Ledger

Additions and corrections in the event logger. (#2441, #2487)
Memory optimisations. (#2442)
Updates to the Alonzo formal specification. (#2418, #2448)
Additional exports needed for db-sync integration. (#2450)
Moved protocol related types to a new module, cardano-protocol-tpraos. (#2445)
Preparatory work for storing the ledger state on disk. (#2449)
Updated the CHAINHEAD rule in the Shelley formal spec. (#2313)
Providing more information about the reward calculation inside of the reward provenance. (#2433)
Add a RetiredPools event, which gives details about retiring pools and the refund (or not) of the pool deposit. (#2487, #2495)
Fix the CDDL specification for transactions. (#2456, #2507, #2523)
Infrastructure and documentation improvements. (#2499, #2500, #2508)
Various work factoring out the definition of the transitional Praos protocol and isolating it from the ledger. This is done in anticipation of introducing a new version of the consensus protocol in the Babbage release. (#2491, #2505, #2510, #2516, #2518)
Document the minimum value computation for Alonzo. (#2486)
Various changes to compactify the in-memory representation of the Cardano ledger state:
- Unpack the TxId in a transaction input. (#2501)
Add support for V2 of Plutus (and for multiple Plutus versions in general). (#2485)
Expose more information concerning reward computation in the API. This is intended to support revised display of pool rankings in the wallet. (#2511)
Document both Value and TxInfo in the spec. (#2383, #2494)
Fix the serialisation of Alonzo transaction witnesses in the case of multiple Plutus versions. (#2525, #2526)
When incrementally computing the rewards, we now require this computation to complete by the first block within 2k/f slots of the epoch end. Previously it was required to complete by the end of the epoch. The motivation for this is to allow db-sync some time to insert the rewards distributed this epoch (which may be substantial) into its database before the end of the epoch. (#2521)

Network

...

Assets 2

Releases: IntersectMBO/cardano-node

Cardano Node 1.35.7

Known Issues

Technical Specification

Documentation

Changelogs

Sign off

Cardano Node 1.35.6

P2P Configuration

Outbound Governor

Inbound Governor

Connection Manager

Ledger Peers

Server

Known Issues

Technical Specification

Documentation

Changelogs

Cardano Node 1.35.5

Known Issues

Technical Specification

Documentation

Changelogs

Sign off

Cardano Node 1.35.4

Breaking Changes

Known Issues

Technical Specification

Documentation

Changelogs

Sign off

Cardano Node 1.35.3

Breaking Changes

Known Issues

Technical Specification

Documentation

Changelogs

Cardano Node 1.34.1

Known Issues

Technical Specification

Documentation

Changelogs

Sign off

Cardano Node 1.34.0

Known Issues

Technical Specification

Documentation

Changelogs

Sign off

Cardano Node 1.33.0

Breaking Changes

Technical Specification

Documentation

Changelogs

Cardano Node 1.32.1

Breaking Changes

Technical Specification

Documentation

Changelogs

Sign off

Cardano Node 1.31.0

Breaking Changes

Technical Specification

Documentation

Changelogs