Peer-to-peer networking
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. Experimental peer-to-peer networking and message-propagation layers exist in an internal prototype for internal development only, their design is still being explored, and no security, privacy or resilience property is claimed for them. No public network exists, and nothing is publicly available for live use.
Before you read: Operating a node: intended roles and what exists today.
How do nodes find each other and pass messages and transactions? This page explains what peer-to-peer networking is for in a shared network and what exists experimentally today. It does not describe how the experimental layers work: their design is still being explored, and further technical reference is not yet available. It closes with what operators would plan for once node software is released.
What peer-to-peer networking is for
In a shared network, nodes exchange transactions and other messages directly with one another, rather than through a central server. That gives networking three jobs:
- Finding other nodes and staying connected. A node needs a way to find other nodes and to keep connections to them, so that it is not cut off from the rest of the network.
- Spreading messages. New transactions and results need to spread across the network so that every node learns about them. This documentation calls this message propagation.
- Carrying transactions through their lifecycle. In the intended design, admitted transactions are passed between nodes so that the network, rather than a single node, can process them. In the documentation’s lifecycle terms such a transaction is propagated — a stage that is planned and is not described as exercised by the internal prototype. See Transaction lifecycle: from submission to result.
An application or wallet that submits a transaction would not normally observe this activity directly. It is part of how the network itself would operate, and it is mainly a concern for the people who run nodes.
What exists today
Experimental implementation exists — internal prototype only.
- An experimental peer-to-peer networking layer exists in an internal prototype; its design is still being explored.
- An experimental message-propagation layer exists in an internal prototype.
- Both are used for internal development only. There is no public network to connect to; see Networks and environments.
- Their existence does not mean that a network of independent operators is running anywhere.
What is not described
This page states purpose and existence only. It does not describe:
- protocols, message formats, identifiers, connection settings or network ports;
- how nodes find each other or how messages are routed, beyond the purposes above;
- any security, privacy or abuse-resistance property. No claim is made that network traffic is protected, private or resistant to attack.
Further technical reference is not yet available.
What operators would plan for
Planned. Once node software is released, operators would plan for the following:
- Connectivity. A node would need network connectivity to other nodes. Operators would watch the health of their node’s connections alongside its other status; see Node monitoring and observability.
- Supported requirements. Network requirements and configuration would accompany a supported release. None are published, and this documentation states no ports, settings or capacity figures.
- What the network can reveal. Information visible at the network level can reveal activity even when data contents are protected. The design acknowledges that some protocol metadata remains observable even with confidential execution, and is exploring ways to bound and reduce it; see What remains observable.
Assumptions, trust and limitations
- The experimental networking is internal, and its design may change substantially before any release.
- The behaviour of the experimental layers is not evidence of how a released network would behave, including how it would perform or cope with failures.
- Statements on this page describe the state of development as of the page’s date.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once supported node software exists, this page would describe supported networking behaviour at the level approved for publication and link to the corresponding requirements. Status changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- any protocol, message format, identifier or port;
- any security, privacy or resilience property for network traffic;
- that a public network, or a network of independent operators, is running anywhere.
Anything not stated here as available should be treated as unavailable.
Related pages
- Operating a node: intended roles and what exists today — the operator’s view of the network.
- Transaction lifecycle: from submission to result — where passing transactions between nodes fits.
- Node monitoring and observability — watching a node’s health, including its connections.
- Networks and environments — which networks exist (none publicly).
- What remains observable — what network-level information can reveal.
Glossary
References
No approved public references yet.
