Skip to content

Cardano Node 1.35.6
Compare
Choose a tag to compare
@disassembler disassembler released this 16 Mar 14:01
· 2723 commits to master since this release
1.35.6
This tag was signed with the committer’s verified signature.
coot Marcin Szamotulski
GPG key ID: 827103837AF0BC20
Learn about vigilant mode.
07b0c71
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

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

Documentation

Changelogs

Node

NONE

Consensus
  • Report consensus initialisation errors (#4015).
Ledger

NONE

Network
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