P2P
Introduction
Canopy implements a custom Peer-To-Peer communication layer that attempts to balance simplicity and robustness. It implements a secure, multiplexed, and encrypted communication system between network nodes that enables both efficient gossip and point-to-point transmission.
Authentication Protocol (Handshake)
When two peers connect, Canopy converts a standard TCP connection into encrypted transport by executing the following authentication protocol:
Key Exchange: Use Diffie-Hellman key *ephemeral exchange over the X25519 elliptic curve (ECDH) to establish a shared secret between peers. This allows peers to generate the same encryption keys without ever transmitting the real keys themselves.
Key Derivation: Apply a HMAC-based Key Derivation Function to the shared secret to generate three outputs:
Encryption key
Authentication key
Nonce (used as a unique initialization vector)
Message Encryption: Use the derived keys along with the ChaCha20-Poly1305 Authenticated Encryption with Associated Data scheme to
Encrypt messages
Decrypt Messages
Authenticate all subsequent communication
↪ By establish an encrypted connection, the Canopy P2P protocol:
Provides confidentiality (messages can't be read by others)
Ensures authenticity (messages haven't been tampered with)
Verifies integrity (messages arrive exactly as sent)
Multiplexing
The P2P system uses multiplexing to allow multiple independent communication channels over a single TCP connection. This is achieved by:
Topic-Based Channels: Each message is assigned to a specific topic (like blocks, transactions, or peer discovery).
Independent Streams: Each topic gets its own
Streamwith its own message queue and inbox.Packet Headers: Each packet includes a header that identifies which topic it belongs to.
➭ This approach is similar to how a single phone line can carry multiple conversations using different frequencies. By multiplexing, the system can efficiently handle different types of messages without needing separate connections for each type, reducing overhead and improving performance.
Wire Protocol
➭ This design decision comes with several benefits:
Programming language and platform neutrality
Code generation for other implementations
Future proofed support through community and enterprise backing
Schema driven development
Highly performant compared to
JSON
DOS Mitigation
In order to prevent Denial-of-Service attacks on the Peer-to-Peer level, Canopy implements specific logic to mitigate these threats:
Peer Reputation System:
Track interactions with a peer using a reputation score
Each bad interaction results in a negative delta
Each good interaction results in a positive delta
Too low of a score results in a drop & ban
Rate-Limiting:
Per-connection outflow and inflow limits
Protocol wide max message size limits
Inbound / outbound connection limits
Custom Liveness protocol:
Operation specific read and write timeouts
Ping / Pong heartbeat check
IP Bannings:
Canopy allows manual banning of any IP address
Canopy automatically bans any IP address that fails the Authentication Handshake Protocol
Peer Management
The P2P system uses several techniques to discover and manage peers:
Must Connect: The P2P module is aware of the Validator Status of this node and the Active Validator List. If this node is a Validator, it attempts to establish connections with the other Validators — ensuring direct communication during the BFT process.
Peer Book: Nodes maintain a list of previously active peers.
Peer Book Exchange: Nodes periodically exchange lists of known peers with each other.
Peer Churn: The system periodically craws the Peer Book and attempts to connect to the peer to ensure it's still reachable. After multiple failed cycles of this - the peer is removed from the peer book.
Message Dissemination
Due to the requirements of NestBFT's linear communication complexity — the P2P module implements two different modes of message dissemination:
Point-to-point: Directly send a message to a peer
Gossip: Send a message too all connected peers excluding the originator of the message.
Peer Configurations
Canopy allows users to adjust the P2P module behaviors to their specific needs with the following configurations:
Maximum Inbound Connections (Node receives the connection)
Maximum Outbound Connections (Node initiates the connection)
Dial Peers: A list of peers to dial upon start
Trusted Peer IDs: Public keys of peers that may bypass limits
Banned Peer IDs: Public keys of peers that may not connect
Banned IPs: IP addresses that may not connect
Minimum Peers To Start: Minimum connections needed to start
Last updated
