Subnetworks

A BlockDAG raises throughput by publishing more blocks in the same slot. That is vertical scaling, and it has a limit: every transaction still has to reach every node, so the wider the network gets, the more traffic each participant carries.

Subnetworks are the researched answer to that — a way to scale Waterfall horizontally by partitioning the network so that transactions propagate only where they are needed, while the ledger stays whole and identical for everyone.

Status

Subnetworks are a research direction, not part of the running protocol. This page summarises published work by the Waterfall research team; the mechanisms below describe the proposed design, not current mainnet behaviour.

Why this only works on a BlockDAG

In a classic blockchain, one block is published per round. To have any chance of being included in that block, a transaction must be propagated across the whole network — so there is no way to reduce network load by keeping transactions within a subset of nodes. This is a structural property, not an implementation detail.

A BlockDAG changes the premise. Several blocks are produced in the same round, so a transaction does not need to reach every potential producer to be published promptly — reaching the producers of any of that round's blocks is enough. Better still, it is actively useful for different producers to hold different sets of transactions: it guarantees that blocks published in the same round carry different transactions instead of duplicating each other.

That is what makes subnetworks possible here and not in a linear chain.

What a subnetwork is — and is not

A subnetwork is a set of nodes within which certain information is propagated, and outside of which it is not. Concretely, in the proposed design:

each node belongs to exactly one subnetwork;
it stores and distributes only the transactions of that subnetwork;
it still receives, stores and distributes all blocks of the BlockDAG, and therefore keeps a complete copy of the entire ledger.

This is deliberately not sharding. The ledger is the same for all nodes and the operational logic of the protocol is unchanged — only the propagation of pending transactions is partitioned. Nobody ends up with a partial view of state, and there is no cross-shard settlement problem to solve.

What a valid partition has to satisfy

Three requirements fall out of the protocol:

Every node carrying Validators must belong to a subnetwork. Nodes without Validators — wallet nodes that only create and relay transactions — may pick one arbitrarily.
Every subnetwork must contain Validators. Otherwise transactions submitted there would never be published to the BlockDAG.
Verifiers in a subnetwork must produce blocks often — read either probabilistically, as at least one block per slot on average, or deterministically, as at least one block per slot.

The third requirement is the binding one: it means a partition cannot simply minimise distance, it also has to keep clusters roughly equal in Validator weight.

How the partition is computed

Three approaches to splitting nodes into non-overlapping subnetworks were considered: each node choosing for itself, pseudo-random assignment, and assignment based on the quality of connections between nodes. The published work takes the third — it is the most demanding to implement, but it is the only one that actually reduces latency inside a subnetwork.

The mechanism works without any central coordinator:

Measurement is published in-band. When a Validator publishes a block in the BlockDAG, it includes metric information about its nearest neighbours. Since every node holds the full BlockDAG, every node can reconstruct the same picture from the same data.
Virtual nodes separate storage from network. The design introduces the notion of a virtual node to decouple the ledger-storage level from the network level; Validators on one machine are combined into one virtual node, so they always share a subnetwork number.
The result is a graph clustering problem. From the published information, every node derives the same undirected weighted sparse graph of links between virtual nodes, and then clusters it — under constraints of low computational complexity and approximately equal cluster weight by Validator count.

Because every node runs the same algorithm over the same finalized data, they all arrive at the same partition without exchanging anything extra.

Which clustering algorithms work

Both agglomerative (AHC) and divisive (DHC) hierarchical algorithms were implemented and modelled, in several variants each. Simulation used 30 generated datasets of 300 nodes, with each node weighted by a Validator count from 1 to 25, partitioned into k = 4 clusters and scored on silhouette, diameter, sphericity, standard deviation and uniformity of cluster weights.

The outcome was clear:

Agglomerative methods lost. They produced much greater non-uniformity of cluster weights — a difference of up to two times — and occasionally emitted clusters consisting of a single virtual node, which is inadmissible. Their computational cost is also too high.
Divisive methods with global search won. Variants using a global search for the most distant nodes (global_dijkstra, global_bfs) gave the best clustering quality, at a significant computational cost; cheaper traversal-based variants trade some quality for speed.

The full test results, generated source data and visualisations are published as datasets alongside the paper.

What it would change in the protocol

Partitioning transaction propagation requires reworking the Waterfall transport layer, which is based on Ethereum's devp2p:

a node reports its subnetwork number in its status message;
every transaction carries the number of the subnetwork it belongs to when created;
a node records and processes only the transactions of its own subnetwork;
if too few of a node's neighbours turn out to be in its subnetwork, it requests neighbour tables from its neighbours and picks suitable peers from them, repeating if necessary.

Re-partitioning happens on an era boundary. The result is fixed by the finalized state two epochs before the end of the era — one epoch for finalization, one to run the clustering. A node whose new subnetwork number differs from its current one temporarily keeps both, maintains two transaction pools, and exchanges transactions with nodes on either side, so that pending transactions belonging to its future subnetwork are not stranded during the switch.

How this relates to the measured limits

The private-network test series showed the practical shape of the problem from a different angle: every configuration reached its theoretical peak, but retention across the full run fell as per-node pressure grew, and recovered when nodes were added. Test 26 changed nothing except node count — 10 nodes to 17 — and gained 32% on full-run throughput.

Test	Slot	Blocks/slot	Nodes	Blocks/slot per node	Peak TPS	Sustained 30s TPS	Retention
25	3 s	25	10	2.50	83,333	68,000	71.69%
26	3 s	25	17	1.47	83,333	76,000	84.80%
27	3 s	35	17	2.06	116,667	103,333	55.52%
28	2 s	25	17	1.47	125,000	106,333	51.32%
29	2 s	35	17	2.06	175,000	128,333	72.54%

The conclusion of that series was that protocol configuration alone is not enough — throughput depends on the interaction between configuration, node distribution and hardware capacity. See the full analysis. Subnetworks address one specific component of that: the cost of propagating every transaction to every node.