The peer-to-peer (P2P) component implements a gossiping mechanism for subnets and creates and validates ingress message payloads for the Consensus layer. It contains the following sub-components:
- Gossip: Disseminate artifacts to other nodes in the same subnet. This is achieved by an advertise-request-response mechanism, taking priorities into account.
- Artifact Manager: Store artifacts to be used by this and other nodes in
the same subnet in the artifact pool. The artifact manager interacts with
Gossip and its application components:
- Distributed Key Generation
- Ingress Manager
- State Sync
- Ingress Manager: Processes ingress messages, providing the following
- Check ingress message validity of messages received from other nodes and broadcast valid ingress messages
- Select ingress message to form Consensus payloads
- Validate such payloads
- P2P guarantees that, up to a certain maximum volume, valid artifacts reach all nodes subject to constraints due to prioritisation and the applications' validation policies. More precisely, Gossip guarantees the delivery of artifacts of a bounded aggregate size within bounded time/eventually under certain network assumptions and provided that the rules and validity conditions specified by the application components are satisfied. Thus, valid artifacts that are of high priority for all nodes will reach all honest nodes in bounded time/eventually, despite attacks (under certain network assumptions). In other words, the priority function ensures that relevant valid artifacts reach enough nodes in the subnet, while artifacts that violate the policy or are of low priority may not reach all other nodes in the subnet.
- Eventual delivery differs from eventual consistency. Consistency models describe the contract between users and a system offering reading and writing to replicated state. Informally, eventual consistency guarantees that if no write occurs for a long time, all replicas return the same value for reads. Consensus does not require eventual consistency for the artifact pool: the priority function can drop adverts without requesting the artifact and different (valid) artifacts with the same identifier may exist in the system and Consensus often only needs at most one of them. Moreover, the offered guarantees are subject to bandwidth restrictions on all honest peers.
- Low number of open connections: An overlay topology defines which nodes exchange artifacts directly with each other. Together with the bounded-time/eventual delivery guarantee mentioned above, the topology ensures that enough honest nodes receive artifacts to make progress. Since the overlay topology describes which connections are established and maintained, it enables the broadcast protocol to trade off bandwidth consumption with latency.
- High throughput and predictability: Bandwidth must not be wasted on sending/receiving the same artifact twice. The behavior under load must be predictable (memory/bandwidth/CPU guarantees for different peers and for different components using gossip).
- Prioritization: Different artifacts are transferred with different priorities, and priorities change over time.
- Validity: ingress messages are broadcast to other peers only if they are valid.
- At-most-once semantics: an ingress message is selected to be in a Consensus payload at most once before its expiry time and only if it is valid (even if a node restarts).
DependenciesP2P relies on the following components:
- Transport for node-to-node communication.
- HTTP handler to submit validated ingress messages.
- Consensus to pass the Internet Computer time as well as finalized payloads and non-finalized payloads since the last executed height in the chain.
- Registry to look up subnet IDs, node IDs, and configuration values.
- Crypto to verify signatures in the Ingress Manager.
- Ingress History Reader to prevent duplicate Ingress Messages in blocks
The following diagram depicts the interfaces between the P2P components and other components. The interaction with the Registry is omitted for simplicity's sake as all components rely on it.
The P2P module exposes the peer-to-peer functionality.
A macro to choose between running malicious code or the normal replica code.