The snarkOS network protocol establishes a peer-to-peer network of nodes that maintains ledger liveness by actively exchanging transactions and blocks.
snarkOS uses TCP connections to facilitate data transfers over the network. Networking on snarkOS is built with asynchronous calls in Rust and tokio.rs. Tokio tasks are spawned to handle new connections and send messages to the main event loop.
snarkOS downloads, verifies, and stores the history of valid blocks and transactions prior to becoming an active node on the network.
When a node joins the network for the first time, it needs to populate a list of active peers in the network. In order to bootstrap peer discovery, snarkOS includes a set of optional specialised “beacon” nodes. Once connected, these provide an initial set of peers which includes the address of a sync provider. The sync provider will supply the node with an initial sync of the chainstate. To allow users flexibility, snarkOS provides allows users to configure the initial set of nodes in the configuration file, or as a input via a command-line flag.
Once a node is connected to one or more nodes, it may scan the network to discover more peers.
This processes starts by asking peers for more connected nodes in the network with a
followed by attempts to establish a connection with each newly discovered peer.
Upon success, snarkOS will store the new peer address to allow it to connect directly with this peer in the future, without needing to use beacons to startup in the future.
Peer connections are established with an XX noise handshake.
Peer connections are maintained with a ping-pong protocol that periodically relays
Pong messages to
verify that peers are still connected. snarkOS will update its peer book to account for newly-connected peers,
and disconnected peers.
Before a node can participate in the network, it must sync itself to the latest state of the ledger. Whether a node is newly connecting to the network or simply has stale state, it must sync with its peers, and download its missing blocks and transactions.
snarkOS uses a “Header-First” approach to syncing blocks, where a node downloads and validates each block header before downloading the corresponding full block, in parallel.
When a node determines it needs to download state, it selects a peer as the sync-node and sends it a
GetSync message contains information about the current block state of the node,
so the sync-node is able to determine which block headers are necessary to send as a response.
Upon receiving a
GetSync message, the sync-node sends back at most 100 block headers via a
The requester then validates these headers and downloads the blocks in parallel by sending out
After these blocks have been downloaded, the requester sends another
and repeats this process until its chain state is fully up to date.
Here is a basic iteration of the sync protocol:
|Node||Sync Node||1 or more block hashes|
|Sync Node||Node||Up to 100 new block headers|
|Node||Any Peer||Block headers of the requested blocks|
|Any Peer||Node||A serialized block|
A node may broadcast a transaction to the network by sending a
Transaction message to its connected peers.
The peers receiving this transaction verify the transaction
and further propagate the transaction by broadcasting it to its connected peers.
This transaction continues through the network until it is propagated to every connected peer in the network.
A node may broadcast a block using a
Block message, in the same manner as broadcasting a transaction.
pub use config::*;
pub use errors::*;
pub use inbound::*;
pub use message::*;
pub use node::*;
pub use peers::*;
pub use sync::*;
pub use topology::*;
Each histogram holds the last
metric_types mod) measurements for internal RTT for the indicated message
type. The snapshot produced for the RPC stats is the average RTT for each set.
The maximum amount of time allowed to process a single batch of sync blocks. It should be aligned
The noise handshake pattern.
The pre-shared key for the noise handshake.
The maximum amount of time in which a handshake with a regular node can conclude before dropping the
connection; it should be no greater than the
The maximum number of block hashes that can be requested or provided in a single batch.
The maximum size of a message that can be transmitted in the network.
The amount of time after which a peer will be considered inactive an disconnected from if they have not sent any messages in the meantime.
The spec-compliant size of the noise buffer.
The spec-compliant size of the noise tag field.
The version of the network protocol; it can be incremented in order to force users to update. FIXME: probably doesn’t need to be a u64, could also be more informative than just a number
The maximum number of peers shared at once in response to a