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 peersTargetNumberOfKnownPeers
(default value:100
) - a target of known peers (must be larger or equal toTargetNumberOfRootPeers
)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 (viachain-sync
,block-fetch
andtx-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
andDebugPeerSelectionInitiatorResponder
(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 ascold
,warm
orhot
(which we callremote cold
,remote warm
orremote 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:
- Configuration files
Documentation
- Cardano Node documentation
- Cardano CLI
- Internal API docs for ledger, consensus and network
- Compatibility matrix
Changelogs
Node
NONE
Consensus
- Report consensus initialisation errors (#4015).
Ledger
NONE
Network
- Split
WarningDevelopmentNetworkProtocolVersions
intoWarningDevelopmentNodeToNodeVersions
andWarningDevelopmentNodeToClientVersions
(#4691). - Provided
NodeToNodeVersion
andNodeToClientVersion
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
toSendFetchRequest
(IntersectMBO/ouroboros-network#4167). - Added
TraceDemoteLocalAsynchronous
(IntersectMBO/ouroboros-network#4127). - Fixed issue IntersectMBO/ouroboros-network#3968).
- Fixed issue IntersectMBO/ouroboros-network#4064).
- Report exceptions thrown when configuring a socket in the subscription component (non p2p) (nput-output-hk/ouroboros-network#3970).
- Configure socket passed through systemd socket activation (IntersectMBO/ouroboros-network#3977).
- Reinitialise dns library on Windows (IntersectMBO/ouroboros-network#3968).
- Interpolation of peer metrics (IntersectMBO/ouroboros-network#3915)).
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 | ✔️ |