Multicast Within Multicast: Anycast, Sharded Resends, and Hierarchical Distribution for Transaction and Block Propagation

Designing a Naming, Hashing, and Subtree Allocation Framework for Scalable Transaction Dissemination and Ordered Consensus

Keywords

Multicast, Anycast, IPv6, transaction propagation, block distribution, hierarchical sharding, resending algorithm, subtree numbering, distributed systems, miners, ordering, allocation.

Thesis

This paper argues that transaction and block propagation at scales of millions to billions of transactions per second cannot be achieved through naïve peer-to-peer gossip or unicast architectures. Instead, the answer lies in a layered multicast system: multicast within multicast, where transactions are distributed via deterministic hash-based groups, resharding mechanisms, and subtree allocation algorithms. By combining anycast entry points, structured naming, and sharded resend protocols, the system ensures that miners and nodes receive all required data, that missing segments are detected and corrected, and that global ordering is preserved across individually allocated substreams. This creates a verifiable, low-latency, and scalable propagation model aligned with the design philosophy of Bitcoin as digital cash at global scale.

Section I. Introduction — The Limits of Gossip and the Promise of Structured Multicast

The central bottleneck of distributed systems is never computation in isolation but communication at scale. When one speaks of a system capable of billions of transactions per second, one is not speaking of arithmetic, hash functions, or signature verification; modern processors and accelerators have already demonstrated capacity in orders well beyond these figures. The true limitation arises in how information is distributed: how bytes are routed across a heterogeneous global network, how miners remain synchronized in the face of latency and packet loss, and how redundant data floods can be eliminated without sacrificing completeness.

For the last decade, transaction propagation in digital cash systems has largely been approached with the same primitive strategies inherited from early peer-to-peer file sharing: gossip relays, mempool flooding, and unicast broadcasts. These methods work tolerably in networks with thousands of transactions per second; they catastrophically collapse when one scales the target to billions. Gossip assumes redundancy is a feature, not a bug: a transaction is sent repeatedly through a graph until probability guarantees convergence. Yet redundancy consumes bandwidth quadratically with node count, and latency is unbounded because no deterministic delivery path is enforced. In a system of global scope, where even a single lost transaction can produce diverging ledgers, gossip cannot serve as a foundation.

Unicast relay—the naive “push it to every peer individually” model—fares no better. Unicast requires O(N) duplication per sender. At scales of millions of transactions per second, this quickly exceeds any feasible bandwidth budget. More subtly, unicast lacks the property of collective verification: each transmission is point-to-point, leaving no common sequence numbers or observable gaps that would allow detection of missed information. A miner that silently drops 0.01% of incoming transactions may diverge in mempool state without any signal that reconciliation is required.

Mempool flooding, the present norm, inherits the worst features of both gossip and unicast. Every node maintains a giant in-memory structure of “pending” transactions and shouts them at every neighbor. The result is duplication, bandwidth waste, lack of ordering guarantees, and no systematic way to detect whether a transaction is missing or corrupted along the path. What should be a precise, verifiable, and auditable broadcast is instead a stochastic rumour mill.

Naïve peer overlays—systems where transactions are simply shuffled around via arbitrary TCP connections—multiply these failures. They presume that if enough links exist, information eventually arrives. Yet at global scale “eventually” is not a meaningful metric. Microsecond precision matters when miners race to order transactions into blocks. An architecture that relies on randomness to achieve liveness cannot satisfy the determinism required of a financial system at planetary scale.

The vision, therefore, must be radically different. The architecture cannot be based on random flooding but on structured communication primitives—multicast groups, anycast ingress, and hierarchical nesting of multicast within multicast. Multicast exists precisely to solve the “one-to-many” problem at scale. A sender emits once; the network distributes efficiently to all members of a group. Anycast, in turn, allows the world of clients and wallets to inject transactions into the system at the closest possible ingress point, from which they are deterministically routed into their proper multicast group. By combining anycast ingress with a hierarchy of multicast layers, transactions are neither shouted indiscriminately nor sprayed redundantly, but placed directly into the groups where they belong.

The concept of multicast within multicast is the key innovation. At the base layer exists a global group that all miners must subscribe to: a channel for essential transactions, block headers, and ordering information. Above this baseline are layers of subgroups: sharded groups determined by hash functions on transaction identifiers, subtree allocations where miners can subscribe to subsets of flows, and specialized channels for large or application-specific data. Each multicast stream is itself partitioned into further substreams, forming a “tree of trees.” This hierarchy preserves bandwidth, provides explicit ordering via sequence numbers, and allows targeted repair of missing segments.

What emerges is a structured, deterministic broadcast fabric. Missed data is not a silent divergence but a detectable event: sequence gaps and numbering expose loss immediately, and shard-level resend algorithms correct it efficiently. Each node and miner receives the right subset of transactions, and every transaction can be audited for placement, ordering, and integrity.

The central challenge, then, is not whether multicast can deliver to many receivers—it has been used for decades in video distribution, financial data feeds, and high-performance computing—but how to adapt it to a trustless, adversarial, and massively scaled digital cash network. The requirements are strict: (1) every miner must receive every transaction relevant to global consensus; (2) every missed packet must be identifiable and repairable within bounded time; (3) ordering must be maintained across shards and subtrees; (4) naming and hashing algorithms must map transaction IDs and block IDs deterministically to multicast addresses; and (5) the entire scheme must scale horizontally by adding shards, groups, and subtrees without central coordination.

In other words, the introduction of multicast within multicast, bound to transaction IDs by hashing and resharding, with anycast as the injection layer, is not a matter of engineering elegance but one of existential necessity. Without it, the dream of a digital cash system operating at billions of transactions per second collapses under its own communication overhead. With it, one achieves a fabric where the addition of nodes and miners increases robustness rather than bandwidth costs, where ordering is explicit, where missed data cannot hide, and where the system finally aligns with the mathematical inevitability that gossip is entropy, but structured multicast is order.

---

Section II. Anycast as the Entry Layer: Naming and Hashing for Transaction Injection

Anycast, properly understood, is not simply another routing trick but a structural mechanism for collapsing distance into determinism. In its conventional form, anycast assigns the same IP address to multiple nodes distributed across the globe. When a packet is sent to that address, the routing fabric delivers it to the nearest or lowest-cost instance. For a digital cash system, this property makes anycast the natural ingress layer. Wallets and clients do not need to know which miner or which relay sits in Tokyo, Frankfurt, or São Paulo; they send transactions to a canonical address, and the network ensures that the transaction enters at the closest possible point. The consequence is twofold: latency is reduced to near-physical minima, and the system achieves balanced ingress without centralized assignment.

Yet anycast alone is insufficient. A transaction delivered to an ingress node must still be routed into the correct distribution group. This is where naming and hashing become essential. The global system cannot rely on arbitrary forwarding tables; it must derive group membership from cryptographic identifiers themselves. The key insight is to bind transaction identifiers (TXIDs) and block identifiers (BlockIDs) to multicast addresses in a deterministic, collision-resistant manner. By doing so, the network eliminates ambiguity: given a TXID, every node in the world can independently compute the multicast group into which that transaction must be injected.

The process begins with the TXID itself, a 256-bit hash. From this, a naming algorithm selects a shard or group address. The simplest scheme is to take the low-order k bits of the TXID hash and map them onto a group identifier space. With k = 8, for instance, the system divides the transaction universe into 256 multicast groups; with k = 16, into 65,536 groups. Each group is represented by an IPv6 Source-Specific Multicast (SSM) address, pre-allocated from a reserved organisational prefix. The mapping is entirely deterministic: every transaction is bound to precisely one group, and the group can be recomputed at any time from the TXID. No coordination is required, no central registry exists, and the mapping cannot be gamed without controlling the TXID itself, which is cryptographically infeasible.

Blocks are handled identically. Each BlockID (the hash of the block header) is mapped into a multicast group by the same algorithm. This ensures that block propagation, like transaction propagation, benefits from partitioning and load balancing. It also aligns the system across scales: the same naming and hashing scheme applies whether the object is a 200-byte transaction or a 4-gigabyte block. Consistency is preserved, complexity reduced.

The interplay of anycast ingress and deterministic multicast mapping solves the first great problem of scaling: how to inject transactions into the global distribution fabric efficiently, fairly, and without duplication. A wallet in Nairobi submits a payment by sending it to the canonical anycast address. Routing delivers it to the nearest ingress node, perhaps in Johannesburg. That ingress node computes the transaction’s multicast group from its TXID and injects it into the correct multicast stream. From there, every miner subscribed to that group receives it directly. If a miner needs global coverage, it subscribes to all groups; if it wants only a shard, it subscribes selectively.

This model eliminates the inefficiencies of gossip. Instead of being flooded through random peer connections, each transaction is injected once, deterministically, into its destined multicast channel. Bandwidth is conserved: one emission suffices. Latency is minimized: ingress is geographically close via anycast, distribution is direct via multicast. Ordering is recoverable: sequence numbers within each group allow gaps to be detected and repaired. And global fairness is achieved: every transaction is assigned its place in the broadcast lattice by its hash, not by arbitrary routing luck.

Moreover, because the mapping is deterministic and public, it can be verified. If a transaction with TXID T appears in group G, every participant can check whether G = f(T), where f is the hash-to-group function. If the mapping is violated, the packet is rejected. This protects against spoofing or mis-routing, ensuring that the structure of the system is upheld regardless of who operates anycast ingress nodes.

The effect is to turn the global network into a transaction fabric in which anycast collapses distance, hashing ensures determinism, and multicast provides efficient distribution. A transaction, once signed and transmitted, enters at the closest gateway, is mapped by its identity into the correct group, and is delivered to all miners who have subscribed. If a packet is lost, sequence gaps expose the omission, and shard-level resends fill it. Nothing depends on chance; everything depends on computation, which is cheap and verifiable.

This combination—anycast ingress with deterministic multicast mapping—is the necessary entry layer for scaling digital cash. Without it, the system drowns in gossip. With it, the global network is not a rumour mill but an ordered lattice of groups, each anchored in cryptographic identity, each accessible from the nearest entry point, each capable of delivering billions of transactions per second without duplication, without ambiguity, and without loss.

---

Section III. Multicast Within Multicast: Hierarchical Layers for Transaction and Block Dissemination

If anycast provides the entry point and deterministic hashing dictates where a transaction belongs, the next question is how the distribution itself should be structured. The answer is not a single flat multicast channel, nor an unbounded number of ad hoc groups, but a hierarchy: multicast within multicast. This is the architecture by which global distribution, sharded parallelism, and local specialization can be reconciled in one coherent framework.

Baseline group: the universal layer

At the root of the hierarchy sits the global baseline group. Every miner subscribes to it. Its function is not to carry all traffic—that would reproduce the inefficiencies of gossip under a different name—but to guarantee that essential information reaches all consensus participants. This includes block headers, minimal ordering metadata, and critical “universal” transactions that must be visible everywhere (for instance, coinbase or transactions that serve as parent dependencies for wide trees of child payments).

The baseline group forms the common knowledge substrate. No miner can claim ignorance of block commitments or core transaction anchors. It functions as the spine of the tree: narrow, fast, and globally subscribed.

Sharded groups: partitioning by hash

Above this baseline are the sharded multicast groups, each derived from the hash of the transaction identifier (TXID). As described earlier, a deterministic function selects the shard: the low k bits of SHA-256(TXID) might map into one of 2^k multicast addresses. These groups are the workhorses of the system, carrying the bulk of transaction flow.

A miner seeking full mempool visibility subscribes to all shards; a miner focusing on specific classes of work may subscribe selectively. Bandwidth is conserved because transactions are injected into only one shard, never all. Ordering is preserved within each shard by sequence numbering, and gaps are immediately visible if packets are lost. Resend protocols can operate independently per shard, avoiding congestion across the whole system.

Sharding introduces horizontal scalability. As transaction rates increase, the system need not increase per-channel bandwidth indefinitely; it simply increases the shard count, halving, quartering, or further subdividing the space by additional hash bits. Each shard becomes a manageable flow, parallel to others, yet still globally verifiable because the mapping is deterministic.

Subtree allocations: narrowing subscription further

Beneath shards are subtree allocations. These are finer subdivisions intended for cases where miners or nodes wish to filter further: for example, transactions tied to specific script templates, applications, or extended data payloads. The subtree mechanism allows subscription to subsets of a shard without collapsing determinism. Each transaction carries, alongside its TXID, a template identifier or subtree index. This index determines not only where the transaction is injected but also how it is numbered within the group.

The value of subtree allocation is in allowing specialization without forcing the entire network to bear the bandwidth of specialised traffic. A miner uninterested in a niche application stream need not subscribe, but those who do can still rely on ordering and repair mechanisms identical to those at higher levels.

The hierarchy as a “tree of trees”

The result is a lattice: baseline → shard → subtree. Each layer is itself a multicast tree, and together they form a tree of trees. At the top, the baseline group resembles a trunk, strong and universal. From it branch the shards, each an independent multicast tree rooted in deterministic hashing. From each shard branch the subtrees, narrower and application-specific.

This nesting provides three critical properties:

1. Bandwidth efficiency. No transaction is transmitted more than once per level. Injection occurs once into its shard or subtree; miners receive only the groups they elect to subscribe to.

2. Ordering. Within each group, packets are sequenced. Missing packets reveal themselves as sequence gaps. Reassembly across groups is deterministic because each transaction’s rightful place is derived from its TXID and, where relevant, its subtree index.

3. Discoverability of loss. Because each stream has explicit numbering and bounded repair, any missed segment is observable. Silent divergence—where one miner has data another lacks—becomes impossible.

Conceptual diagram

One can picture the architecture as concentric rings of trees:

• At the centre, a single baseline multicast tree carrying headers and critical anchors.

• Radiating outward, multiple shard trees, each rooted in a different multicast address determined by TXID hashing.

• From each shard, branching subtrees, each narrower, carrying specialised transaction streams.

Every miner sees at least the centre. Some miners see the entire ring of shards. Others peer deeper into specific subtrees. The whole forms a tree of trees: efficient, ordered, and fault-detectable.

---

Section IV. Shard Resending Algorithm and Missed Information Detection

A broadcast system at planetary scale cannot be judged only by what it delivers but by how it reveals what is missing. The value of multicast is efficiency—send once, deliver to many—but efficiency without verifiability is fragile. What makes the architecture robust is the ability of each shard to not only transmit but to prove absence when something fails to arrive. The shard resending algorithm exists to achieve exactly that: to transform packet loss, late joiners, or temporary disconnections into bounded, deterministic recovery rather than silent divergence.

Independent sequence spaces per shard

Each shard is a logically independent stream. It maintains its own monotonic sequence number space, incremented by one for each transmitted packet. This independence is crucial: if the system relied on a single global sequence, the cost of wraparound and synchronization across billions of transactions would be catastrophic. By giving each shard its own sequence, numbering remains bounded and simple, and gaps can be detected locally without reference to any other stream.

The rule is straightforward: every subscriber to shard S expects to see packet numbers n, n+1, n+2, …. If packet n+1 is absent when n+2 arrives, the gap is exposed. Sequence discontinuity is proof of loss.

Targeted resends: repairing gaps without duplication

When a gap is detected, the subscriber does not flood the entire network with a request. Instead, it issues a negative acknowledgement (NACK) targeted to the shard’s designated resend endpoint. This endpoint is typically the ingress node that injected the transaction into the shard or a set of mirrors announced in the shard manifest.

The resend protocol is selective: it requests only the missing sequence numbers, not the entire stream. The shard endpoint maintains a short-term buffer (for example, the last few seconds or minutes of packets) specifically for repair. When a NACK arrives, the buffer replays the requested packets. Subscribers receiving the resent data can verify it against the sequence and payload hash, reintegrating it without duplication. Because all packets carry cryptographic checksums of the full transaction payload, replay attacks or corrupted resent data cannot poison the stream.

The result is deterministic recovery: every missing fragment is either repaired or conclusively known to be unrecoverable. No silent divergence is possible.

Numbering and subtree allocation

Every packet does not merely carry a sequence number; it also encodes its subtree allocation. This field is derived from the transaction’s TXID and any higher-level grouping rules (such as template IDs or application tags). Subtree identifiers are stable across the system: a transaction deterministically belongs to (shard_id, subtree_id).

Within each shard, numbering is per-subtree, which means that even highly specialized flows have their own ordered sequences. This prevents starvation: packets in one subtree cannot displace or reorder packets in another. Ordering is therefore reconstructed along two axes simultaneously—global within the shard, and local within the subtree.

This dual numbering system gives miners confidence that reconstruction of state is deterministic. If packet 100 in Subtree A is missing, the absence is visible, and repair is targeted. If Subtree B is complete, its numbering proceeds unaffected. This avoids entanglement and reduces contention across unrelated transaction classes.

Avoiding duplication and ensuring fairness

The shard resending protocol explicitly prevents duplication. Because each packet is bound to (shard_id, sequence_number, payload_hash), a resent packet can never masquerade as a new one. If the subscriber already holds it, the duplicate is discarded; if not, it is reinserted exactly where the gap had been detected.

Fairness is achieved through bounded resend windows. Every subscriber has equal opportunity to request repairs within the repair horizon (say, sixty seconds). There is no preferential treatment: either a missing packet is requested within the window, or it expires from the buffer and becomes unrecoverable. This uniform policy ensures that no miner gains advantage by selectively hoarding or withholding resends.

Moreover, because resends are targeted only to explicit sequence gaps, they do not create systemic congestion. One subscriber’s packet loss does not punish the entire network. The burden of repair is proportional to the actual loss experienced, and the repair traffic is dwarfed by the steady-state multicast flow.

Deterministic recovery: bounded divergence and convergence

The final property is deterministic recovery. A miner cannot unknowingly diverge, because sequence gaps make absence visible. A miner cannot inject false packets, because sequence and hash binding make spoofing impossible. A miner cannot reorder packets, because numbering is monotonic and tied to subtree identifiers.

Thus, the shard resending algorithm guarantees that the system converges. Even at billions of transactions per second, every subscriber either (1) has the complete and ordered sequence of packets for the shards it subscribes to, or (2) can prove exactly which packets are missing and, if within the repair horizon, recover them deterministically.

What emerges is not a stochastic rumour network but an auditable broadcast fabric. Every shard is a verifiable stream; every gap is observable; every repair is targeted and bounded. Ordering, fairness, and completeness are preserved not by chance but by mathematics.

---

Section V. Block-Level Ordering, Subtree Allocation, and Individual Miner Indexing

Transaction-level dissemination provides the raw feed of economic activity, but consensus is expressed at the level of blocks. A propagation scheme that cannot extend seamlessly from transactions to blocks will fragment, and fragmentation at consensus scale is catastrophic. Thus the architecture of multicast within multicast must encompass blocks as first-class citizens. The same principles—deterministic mapping, shard-based sequencing, subtree allocation, and targeted repair—apply, but at a higher granularity where integrity is guaranteed not merely by hashes of single transactions but by Merkle commitments spanning billions of them.

Block IDs and multicast mapping

Each block header is itself a 256-bit hash, the BlockID. The BlockID serves the same function as the TXID at the transaction layer: a cryptographic anchor for naming, indexing, and group assignment. The deterministic hash-to-group mapping ensures that every block enters the broadcast lattice at the correct address. A block cannot masquerade in the wrong shard or subgroup; the mapping is verifiable by all.

At minimum, block headers must be placed into the baseline global group. This ensures that all miners, regardless of shard subscription, observe candidate blocks, can verify their headers, and can initiate validation. However, full block payloads—potentially gigabytes in size—are distributed through the sharded multicast hierarchy. The BlockID determines the shard, and the block’s internal structure (its transaction set) determines its subtrees.

Transaction subtrees within blocks

A block is not a monolithic object but a structured tree. Each transaction belongs to a shard, as established in Section III. The block therefore decomposes into transaction subtrees aligned with those same shards. For every shard, the miner constructs a Merkle subtree from the ordered list of included transactions. The collection of these subtrees reassembles into the block’s global Merkle root.

In multicast terms, this means that each shard already maintains the transactions relevant to its slice of the block. The block announcement consists of (1) the header in the baseline group, (2) subtree commitments broadcast into their respective shard groups, and (3) numbering information that guarantees the order of transactions within each subtree. A miner receiving these announcements does not require re-flooding of data it already possesses; it simply verifies that the shard-level transactions it holds align with the commitments.

Block segmentation and subtree numbering

Large blocks must be transmitted incrementally. Each block segment is placed into its shard-subtree stream with explicit segment numbers. These segment numbers form a secondary sequence space nested within the shard’s existing numbering. Thus, a miner receiving shard S observes two intertwined but separable streams: the continuous transaction flow (shard sequence numbers) and the bounded block segments (block sequence numbers). Both have deterministic order, both expose gaps, and both are repairable by the shard resend protocol.

The effect is compositional: block-level dissemination is not a separate channel but an overlay on the same multicast lattice. Segments are just packets, packets belong to shards, shards are mapped deterministically by hash. A late joiner can reconstruct not only the mempool state but also any in-progress block assembly by requesting the missing numbered segments from the shard repair buffer.

Miner-specific substreams

Consensus requires uniformity of ordering, but bandwidth allocation may be individualized. Each miner or node can be assigned individually allocated substreams within the shard lattice. For example, Miner A may subscribe to all baseline and shard streams; Miner B may subscribe only to those shards whose transaction patterns it prioritises; Miner C may subscribe to a dedicated substream carrying transactions of a specific application template.

Despite these individualized allocations, all miners conform to the global structure: the mapping of TXID → shard → subtree → sequence is universal. A miner cannot invent its own numbering or routing; it can only choose which subset to subscribe to. This flexibility allows miners to optimise for their bandwidth and processing priorities without compromising the determinism of the system as a whole.

Ordering and verifiable reassembly

The final question is ordering: how can one prove that the block as reassembled from distributed shards is ordered correctly and completely? The answer lies in deterministic numbering plus Merkle commitments.

1. Deterministic numbering. Every shard enforces monotonic sequences, every subtree adds its own sequence, and every block segment carries its position. These numbers are non-fungible: gaps prove loss, duplicates are discarded, and reassembly order is fixed.

2. Merkle commitments. The miner building the block computes Merkle roots for each shard-subtree and then composes them into the global block Merkle root. Each shard group publishes both the transactions and the subtree root. A receiving miner verifies that the root matches its transaction set; the baseline header includes the final global root.

3. Verifiable reassembly. By combining the deterministic numbering with the Merkle proofs, any miner can reconstruct the exact ordered transaction list for the block, detect any omissions, and confirm that the miner who proposed the block has not fabricated or misordered data.

The scheme thus maintains ordering at two layers: locally within shards and subtrees, and globally at the block level via Merkle roots.

Synthesis

In this model, block propagation is not a special case but an emergent property of the multicast hierarchy. Transactions flow continuously through shards and subtrees; blocks simply bind subsets of those flows into committed structures. The same mechanisms—sequence numbering, targeted repair, deterministic hash-to-group mapping—apply at both scales. Individual miners maintain their own subscription profiles, but all align to the same universal lattice. Ordering is not inferred probabilistically but enforced deterministically.

Through this design, the network achieves the dual requirement of scalability and consensus: billions of transactions can be partitioned, transmitted, and reassembled across multicast streams, and yet all miners converge on the same ordered block view, provable by sequence numbers and cryptographic commitments.

---

Section VI. Implications and Conclusion — Scaling Digital Cash Through Structured Propagation

The preceding sections converge on a single thesis: gossip cannot scale. No amount of optimisation, no clever re-wiring of peer overlays, no “smarter” flooding will overcome the inherent inefficiencies of stochastic dissemination. At billions of transactions per second, redundancy becomes waste, silence becomes divergence, and probability becomes failure. What remains is the necessity of structure: anycast ingress, deterministic mapping, hierarchical multicast, shard-level resends, and subtree numbering. These components, integrated, form the only viable communication substrate for digital cash at planetary scale.

Efficiency

Efficiency is immediate and measurable. Instead of O(N) unicast duplication or quadratic gossip floods, multicast reduces distribution to a single emission per group. Transactions and blocks enter once, at the nearest ingress node via anycast, and are deterministically routed into their rightful shards. Bandwidth is preserved not by throttling but by design; there is no redundancy because none is required. Subtree allocations further economise distribution: miners receive only what they subscribe to, not everything shouted by every neighbour.

Verifiability

Verifiability is the second pillar. Every packet is sequenced; every gap exposes absence. Loss is not silent but visible, repairable, and provably resolved. Merkle commitments ensure that reassembled blocks match precisely the ordered transaction sets miners have received; no one can fabricate or omit without detection. The network ceases to be a rumour mill and becomes an auditable fabric, where absence, presence, and order are cryptographically anchored.

Scalability

Scalability emerges both horizontally and vertically. Horizontally, shards can be expanded by adding hash bits: 2, 4, 8, 16, 2^k groups, each independently manageable, each deterministically mapped. No coordination is required to grow capacity; the hash space itself provides partitioning. Vertically, subtrees allow finer allocations, filtering flows down to specialised application classes without burdening the rest of the system. Together, these dimensions provide virtually unbounded scale: billions of transactions can be distributed, ordered, and reassembled without the architecture collapsing.

Economic and consensus implications

At the economic level, the implications are profound. A network that can reliably propagate billions of transactions per second creates the conditions for true micropayment economies—instant settlement, high-frequency commerce, and novel business models impossible under bandwidth-starved gossip networks. Consensus itself becomes stronger: miners remain in synchrony because every shard, every subtree, every block segment is ordered and repairable. Fairness is preserved; no miner can quietly diverge by dropping flows. Auditability ensures that disputes can be resolved by reference to deterministic packet sequences and Merkle roots rather than probabilistic peer testimony.

Conclusion

What emerges is not merely an optimisation but a new layer of communication architecture. Where gossip was entropy, structured multicast is order. Where mempool flooding was waste, shard-level sequencing is precision. Where unicast was fragility, anycast ingress is resilience. Together, these mechanisms enable the Bitcoin system to scale to its design capacity—not thousands or millions, but billions of transactions per second—without sacrificing efficiency, fairness, or verifiability.

The lesson is simple: consensus begins not in cryptography but in communication. To scale digital cash globally, one must first scale the broadcast fabric itself. By embracing structured multicast—layered, sharded, and verifiable—we unlock the true potential of the system, transforming it from a fragile rumour network into an ordered, auditable infrastructure for global economic exchange.