Multicast as the Only Viable Architecture for Billion-Transaction Networks

Because nothing says “scalable” like wasting 26 terabits per second to prove you can’t count past three hops

Keywords: multicast, transaction propagation, bandwidth efficiency, billion transactions per second, gossip protocol, SPV, scalability, network determinism, miner communication, edge filtering

Thesis Topic: Multicast as the Inevitable Backbone of Billion-Transaction Bitcoin Networks: Why Gossip is Dead on Arrival

Introduction

It is a peculiar ritual in the so-called scaling debates that proponents of “broadcast gossip” still cling to the fantasy that a billion-transaction-per-second network could somehow be duct-taped together by endlessly forwarding packets across a mesh of peers. The arithmetic alone damns the idea before it leaves the whiteboard. A single billion transactions per second, even at a modest mixed size of 325 bytes, generates a data firehose of 2.6 terabits per second. That is not an abstract number, not a hypothetical dream: it is a physical rate of data creation, a volume of bits that must be moved, without loss, without duplication, and within strict time bounds, if such a system is to function. To pretend this can be shuffled about by the same redundant chatter that underlies today’s hobbyist node gossip networks is not merely naïve; it is structurally impossible.

The problem is not ideological. It is not a question of taste between decentralised romanticism and cold engineering. It is simple physics married to network architecture. In gossip, every node retransmits to a fanout of peers, creating exponential amplification of redundant traffic. Even in the most optimistic three-hop configuration, covering only 1,000 receivers, the originating source is forced to spew ten copies of the stream, immediately magnifying its uplink to twenty-six terabits per second. The waste multiplies across the network: collisions, duplication, and overhead inflate the workload by forty percent or more compared to an optimal tree. At the same time, latency variance and packet loss increase because dozens of overlapping TCP/UDP flows carry the same payloads. One does not need to model this endlessly; the first-order calculation condemns gossip outright. It dies at scale.

Multicast, by contrast, was designed precisely for this regime: a single stream replicated at branch points, with each backbone link carrying exactly one copy. The sender uplink remains fixed at the generation rate—2.6 terabits per second in this model—and the distribution tree propagates the data to all receivers without multiplying the source burden. Even under a three-hop constraint, a modest branching degree of ten suffices to reach over a thousand endpoints. The result is deterministic, efficient, and predictable. Unlike gossip, multicast does not pretend to conjure efficiency out of duplication; it enforces efficiency by construction.

This is not to suggest that every receiver can or should swallow the entire firehose. Even miners, the twenty core block producers, bear the heavy load of receiving all transactions in full payload form. Exchanges and peripheral services, by contrast, need far less. Using simplified payment verification, Merkle proofs, and subscription filters, their bandwidth collapses from terabits to kilobits per transaction of actual interest. In practice, the full multicast stream is reserved for the core, and the edge consumes filtered, interest-aligned substreams. This is precisely why Bitcoin’s original architecture made sense: miners need everything, end-users need only proofs.

The structure of this essay proceeds accordingly. First, it will define the scaling problem concretely, grounding the analysis in physical bandwidth requirements rather than ideology. Second, it will compare multicast and gossip models, with attention to throughput, redundancy, and determinism. Third, it will examine receiver constraints, emphasising what miners must endure versus what exchanges and users can realistically ingest. Fourth, it will analyse path and latency considerations, demonstrating why three hops set an unforgiving ceiling that gossip cannot breach. Fifth, it will explore interest filtering and SPV as the mechanism that reduces the firehose to personal relevance. Sixth, it will outline the architectural mandate—that multicast, augmented by filtering and proofs, is the only viable design. Finally, it will draw out broader implications: what this means for the future of blockchain networks, why the “everyone validates everything” cult is untenable, and how the network must embrace engineering reality rather than ideological delusion.

The thesis is therefore stark. Gossip-style broadcast is mathematically and structurally incapable of supporting billion-transaction throughput. Multicast, in combination with edge filtering and proofs, is not an optional optimisation but the only architecture compatible with physical reality. Anything else is wishful thinking disguised as design.

---

Section 1: The Scale of the Problem

It is best to begin with the arithmetic that scaling theorists prefer to sweep under the rug. In any serious discussion of transaction distribution, numbers do not negotiate. The composition of a billion transactions per second is not arbitrary chatter—it is a blend of small payments and larger contractual operations, a mix that reflects actual demand. Taking ninety percent of these as “small” 250-byte transfers and ten percent as “large” 1,000-byte transactions yields a weighted mean of 325 bytes. Multiply that by one billion per second, and the crude reality appears: 325 gigabytes per second, or, expressed in the language of the backbone, 2.6 terabits per second. This is not a negotiable quantity; it is the bare minimum rate of raw data that must leave the source. Everything begins and ends with this firehose.

Now, add the structural constraint. This stream must reach not one or two peers, but twenty block-producing miner/data nodes plus one thousand exchanges. That is 1,020 independent receivers, each of which must obtain valid data within a strict propagation window of three hops or fewer. Any further delay compounds orphan risk, increases latency tails, and fractures the consistency of the network. The system must, therefore, distribute 2.6 Tb/s continuously, to over a thousand endpoints, within three layers of replication. No amount of rhetoric alters this boundary condition.

The scale of the task becomes clear when set against real hardware. A single 100-gigabit Ethernet port, fully saturated, carries only 0.1 Tb/s. To consume 2.6 Tb/s, a node would need twenty-six such ports bonded and sustained at full capacity. Upgrade to modern 800-GbE interfaces, and the load still requires four fully-utilised ports. Even the latest 1.6-TbE links—exotic, expensive, and available only in the highest-end datacentres—would require multiple connections per receiver. And these are not peak bursts; this is sustained throughput, second after second, without reprieve. A billion transactions per second is not a traffic spike; it is a permanent deluge.

This physical comparison lays bare the absurdity of naïve distribution models. If one were to attempt gossip-style broadcast, where each node sprays the stream to a handful of peers, the uplink of the source node would immediately explode. A fanout of ten, sufficient to cover 1,000 recipients within three hops, inflates the source’s burden to twenty-six terabits per second—ten times the generation rate. That figure is not simply impractical; it exceeds the capacity of any known commercial uplink by an order of magnitude. It moves the problem from “extremely difficult” into the category of “physically impossible.”

The challenge is not confined to the source. Each relay in a gossip mesh must buffer, retransmit, and manage duplicates. Packets collide, overlaps accumulate, and the aggregate link-throughput across the network swells far beyond necessity. Even under a conservative thirty percent redundancy estimate, the network carries roughly 1.4 times the minimal traffic of a multicast tree. This translates to wasted bandwidth, hotter links, and rising packet loss. The cost is borne not in theoretical models but in dropped frames, retransmissions, and cascading latency under load.

Contrast this with a multicast model. In a properly engineered tree, each backbone link carries a single copy of each transaction. The sender emits one stream at 2.6 Tb/s, not ten. Branching occurs at the network core, not in endless peer chatter. The total number of link transmissions remains tied to the number of receivers—1,019 in the minimal case—but the per-link burden never exceeds the base generation rate. In other words, multicast distributes the inevitable 2.6 Tb/s; gossip multiplies it catastrophically.

The scale of the problem, therefore, is not merely “big data.” It is the convergence of three unforgiving constraints: a billion events per second, multi-terabit throughput, and thousand-fold replication within three hops. When translated into hardware, the requirements dwarf the capacity of naïve peer-to-peer broadcast. Routers, switches, and interfaces strain under sustained terabit loads even in the best-provisioned networks. Any architecture that multiplies those loads by redundant retransmissions collapses before it leaves the design stage.

The conclusion of this first analysis is blunt: the problem is not ideological but physical. Delivering a billion transactions per second is an engineering challenge on the order of the world’s largest content distribution networks. Attempting to solve it with hobbyist broadcast protocols is a category error. The arithmetic admits no alternative: only architectures that respect the minimal burden—multicast with structured replication—can even pretend to scale. Everything else is fantasy dressed in protocol.

---

Section 2: Multicast Distribution Model

The essence of multicast lies in its refusal to duplicate effort at the wrong end of the network. Where gossip-based systems wastefully replicate streams at every node, multicast imposes order: one sender, one stream, replicated only where branches diverge. The principle is simple, almost embarrassingly so. But it is precisely this simplicity that makes it the only architecture mathematically stable under billion-transaction-per-second loads.

The definition is twofold. At the lowest layer, there exists native IP multicast—a facility embedded into the fabric of Internet Protocol, developed decades ago for applications ranging from video conferencing to market data distribution. Where routers and switches honour the IGMP and PIM protocols, a packet injected once is replicated only at branch points to reach all interested receivers. At higher layers, application-layer multicast has evolved: software-level overlays where nodes cooperate to form trees that mimic the behaviour of native multicast even when routers refuse to participate. In either form, the structural principle is identical: replication occurs on the branch, not at the root. The source never shoulders more than a single outgoing stream.

Mathematically, the burden is clear. For a billion transactions per second at 325 bytes each, the generation rate is D = 2.6 Tb/s. In a multicast distribution model, the source uplink is precisely D. Not ten times D, not twenty-six times D, but one copy, pushed once into the network. From there, the tree takes over. If there are R receivers, the minimal spanning tree requires R–1 edges. With twenty block-producing miners and one thousand exchanges, R = 1,020, and the tree has 1,019 edges. Each edge carries the full 2.6 Tb/s stream, but crucially, only once.

This is the difference between stability and chaos. As receivers scale, the number of edges grows linearly: every new participant adds exactly one new edge. But the per-link burden never increases, and the source uplink remains fixed. No matter how many exchanges join, the generator emits exactly one stream. This property—constant source burden, bounded per-link load—is the mathematical foundation that makes multicast sustainable. It transforms scaling from exponential madness into linear accounting.

Consider the efficiency in practical terms. If a new exchange comes online, a new edge must be added to the distribution tree. That edge must carry the same 2.6 Tb/s as every other. Yet the rest of the system remains untouched. No upstream node sees its workload multiplied by the presence of additional downstream receivers. Each branch absorbs only its proportional responsibility. This is precisely why multicast was not an academic toy but a serious field of networking research in the 1990s and early 2000s. The architecture was not devised to impress theorists; it was designed to distribute television broadcasts, financial data feeds, and real-time simulation traffic across wide-area networks without drowning the source.

The historical context matters. Engineers in the early Internet recognised that scaling real-time distribution could not be achieved by brute-force broadcast. IP multicast was standardised as early as RFC 1112 in 1989, with subsequent refinements throughout the 1990s. It was tested in projects such as the MBone (Multicast Backbone), which demonstrated global real-time video and audio distribution across academic and research networks. By the turn of the millennium, multicast was proven technology. Its deployment was hampered not by performance but by policy: Internet service providers resisted wide-scale support due to billing models and concerns about control. The irony is striking: what failed to reach mass adoption for streaming video may yet be demanded by a financial network that aims to process a billion transactions per second.

The architecture of multicast further reinforces its determinism. Latency remains bounded by the hop count, not inflated by the noise of redundant retransmissions. Jitter is easier to control, because packets are not arriving from multiple peers with competing clocks. Error recovery can be structured with forward error correction or selective retransmission from known branch points. The tree provides discipline where gossip provides chaos.

One can even extend the mathematical argument. Let the source generation rate be D, the number of receivers R, and the number of edges R–1. Then the total “network work,” the sum of all link transmissions, is (R–1) × D. That is the unavoidable minimum; no architecture can deliver R copies without at least R–1 transmissions. Gossip inflates this figure by redundancy—30%, 40%, or worse. Multicast holds to the floor. This is why it is not merely “better” but categorically the only model consistent with the laws of arithmetic at billion-transaction-per-second scale.

To place it in the bluntest terms: multicast does not cheat physics, but it does not insult it either. It accepts that one stream must be delivered and that replication must occur, but it confines that replication to the exact branching points where it is necessary. It does not delude itself that spraying ten redundant streams from the source could ever be efficient. It does not multiply the uplink load beyond what exists at generation. It scales linearly, predictably, and within the capacity of engineered networks.

The irony, of course, is that what the world abandoned in video streaming it may yet rediscover in finance. A network that aspires to global digital cash at industrial scale cannot rely on nostalgic peer-to-peer myths. It must confront the arithmetic of throughput and the constraints of hardware. Multicast is not an option; it is the architectural mandate. Everything else is theatre.

---

Section 3: Gossip/Broadcast Model

If multicast represents discipline, gossip represents the absence of it. It is a system built not upon order but upon noise, upon the vain hope that redundancy will substitute for structure. The gossip model operates with a simple, even childish principle: every node forwards every message to a handful of peers, and those peers in turn forward again, until eventually, by sheer repetition, the entire network has heard the news. It is the architecture of the playground rumour, not the high-speed exchange.

Formally, gossip in this context is defined by two parameters: the fanout (g), the number of peers each node forwards to, and the time-to-live (TTL), the number of hops after which retransmission stops. In order to reach approximately one thousand receivers within three hops, the fanout must be on the order of ten. A single node sends to ten peers; those ten each send to ten more, producing one hundred; those one hundred each forward to ten more, yielding one thousand. In the idealised, non-overlapping case, ten plus one hundred plus one thousand equals 1,110 unique reaches.

The arithmetic turns ugly immediately. Recall that the raw generation rate is D = 2.6 Tb/s. In gossip, the source uplink is not D. It is g × D. With g ≈ 10, the source uplink becomes 26 Tb/s. This is not a matter of subtle inefficiency; it is an order-of-magnitude catastrophe. To frame it concretely, if a source node required four 800-GbE interfaces to sustain 2.6 Tb/s in multicast, gossip would demand forty such interfaces, each saturated. No existing hardware configuration can sustain such demands, and none will appear by miracle. Gossip begins by breaking the source.

The problem compounds downstream. Every transmission in gossip is duplicated unnecessarily. The 1,110 transmissions in the perfect, overlap-free expansion already exceed the 1,019 links required by an optimal multicast tree. Real networks are not perfect. Peers overlap; nodes forward duplicates. A conservative redundancy factor of 30% inflates the figure to approximately 1,443 transmissions per transaction. Thus, the network is executing forty percent more work than the minimum simply to deliver the same payload.

What does this mean in practice? It means hot links. Certain links, especially those bridging between major clusters of peers, will carry multiple redundant streams of the same transaction. These links become overloaded, their buffers choked with duplications. The result is packet loss, followed by retransmission, followed by further congestion. It is the classic positive feedback loop of a poorly designed system: failure begets recovery, which begets more failure.

Replay storms are a natural consequence. When buffers overflow and packets are dropped, nodes attempt to repair the missing data by re-forwarding. Yet because gossip has no central coordination, the same missing packet may be retransmitted by dozens of peers simultaneously, each attempting to fill the perceived gap. The network drowns itself in its own attempts at healing.

Latency fares no better. Gossip requires a mesh of per-peer TCP or UDP flows. Each flow introduces its own vagaries: head-of-line blocking, where a delayed packet stalls all subsequent packets in the queue; duplicate suppression overhead, where nodes must maintain tables to detect and discard already-seen messages; and per-peer backpressure, where a slow or overloaded peer drags down the sender’s ability to proceed. In theory, gossip propagates rapidly. In practice, under the load of a billion transactions per second, the tail latency stretches, variance grows, and guarantees disappear.

The contrast with multicast is total. In multicast, one packet is paced into the network, replicated deterministically at branch points, and delivered with bounded latency. In gossip, dozens of redundant packets are sprayed from the source, collide across the mesh, and demand suppression. Multicast provides structure; gossip provides entropy. Multicast ensures each link carries exactly one copy; gossip ensures some links carry many, others too few, and the system as a whole carries more than it can sustain.

Defenders of gossip argue for its simplicity, its robustness against single-node failure, its decentralised flavour. But simplicity is not the same as scalability, and robustness is not achieved by multiplying chaos. At 1e9 transactions per second, gossip is not robust but suicidal. It does not simply fail to optimise; it fails to function at all.

The unavoidable truth is that gossip carries the burden where it can least be afforded. It breaks the source with uplink demands an order of magnitude beyond hardware. It breaks the backbone with redundant transmissions that multiply waste. It breaks latency guarantees with uncoordinated flows and suppression mechanisms. The mathematics are not negotiable. No amount of ideology or enthusiasm for “peer-to-peer” aesthetics alters the arithmetic of throughput.

Where multicast is disciplined, gossip is profligate. Where multicast respects the minimal bound of (R–1) × D, gossip exceeds it needlessly. In a network tasked with carrying 2.6 Tb/s of live financial traffic, gossip is not an option. It is the embodiment of inefficiency, a design fit for academic simulations and romantic manifestos, not for the architecture of money.

---

Section 4: Receiver Burden and Capacity

The receiver problem is as merciless as the sender’s. It does not care whether the architecture is elegant, decentralised, democratic, or bathed in the moral language of “peer-to-peer.” The mathematics remain. If the network must deliver D = 2.6 Tb/s, then every receiver that demands the full transaction payload must ingest 2.6 terabits every second, continuously, without reprieve. There is no hand-waving past this figure.

Consider what that means in hardware. To carry 2.6 Tb/s requires roughly 26 fully saturated 100-GbE ports. Imagine the racks, the cabling, the switching overhead. It requires at least four 800-GbE links, each driven to capacity. Or, more bluntly, it demands multiple 1.6 TbE interfaces, hardware that sits on the bleeding edge of what manufacturers can deliver and at costs fit for a national data centre, not a financial exchange. Multiply this requirement across one thousand receivers and the absurdity becomes manifest. We are no longer describing a payments network; we are describing a global science experiment in over-provisioned networking.

This is why the fantasy of every exchange, wallet, or lightweight participant ingesting the full transaction firehose is untenable. It is simply too much. Even if capital were infinite and every exchange could purchase racks of 1.6 TbE switches, the operational realities would destroy them. Each receiver must buffer, store, verify, and route 325 gigabytes per second of live data. That is not a financial feed; that is a punishment. Only the 20 miner/data nodes, the machines tasked with full replication, proof construction, and block assembly, can justify bearing this burden. For them, 2.6 Tb/s is the job. For the thousand exchanges, it is a death sentence.

This leads directly to the necessity of adjustment. The network cannot pretend that every receiver is equal. Equality in bandwidth is a fantasy. Exchanges and other non-miner participants must not be handed the entire payload. They must be offered something smaller, something that fits the scale of their legitimate needs. This is where sharding, filtering, and interest-based replication enter as pragmatic design features, not luxuries.

Sharding means dividing the transaction stream into partitions: subsets of activity routed to subsets of receivers. But even sharding has limits; the financial system cannot fracture arbitrarily. More powerful is interest-based filtering. Exchanges do not need the world; they need only their world. If an exchange handles ten million transactions per second in customer traffic, it has no use for the other 999,990,000. It needs only the proofs that its subset of transactions have been correctly placed into the global ledger.

That is where Simplified Payment Verification (SPV), Merkle proofs, and subscription-based replication become essential. Instead of receiving the raw payload, the exchange receives headers, filters, and proofs—cryptographic evidence that the transactions relevant to it exist and are anchored in the ledger. This transforms the burden from terabits per second to megabits or gigabits per second, proportional to the exchange’s activity rather than the network’s totality. The difference is existential. With SPV, the exchange survives; without it, the exchange is smothered.

The separation of duties is thus non-negotiable. Miners must handle the firehose. They must operate the iron foundries of data, consuming terabits, compressing chaos into blocks, generating the proofs. Non-miners must not attempt to mirror this burden. They must subscribe by interest, receive by filter, and verify by proof. Any architecture that insists otherwise is doomed to collapse under the sheer physics of bandwidth.

The irony is that advocates of “everyone a full node” often posture as defenders of equality. Yet it is precisely their model that creates inequality. Only the richest organisations could ever hope to build the capacity to ingest 2.6 Tb/s directly. By contrast, the SPV model—where miners shoulder the firehose and everyone else consumes their slice—creates genuine universality. Anyone can participate, because participation scales with one’s actual needs.

At the scale of a billion transactions per second, receiver burden is not a matter of ideology. It is the line between design and delusion. The network must choose: either force every participant to drown in terabits per second of unwanted traffic, or adopt a rational structure where the burden is borne by the few who must and relieved from the many who need not. Only the latter survives.

---

Section 5: Three-Hop Constraint and Topology

Impose a hard ceiling of three hops and the topology all but chooses itself. With a branching degree of roughly ten at each interior level, a multicast tree fans 1 → 10 → 100 → 1,000 in three layers. Add the twenty miner/data nodes at or near layer one (or graft them as co-equal first-hop children), and you arrive at 1,020 receivers covered within the hop budget. The important observation is not the headline arithmetic but the structural consequence: every packet is injected once, replicated only at branch points, and delivered to all endpoints with a bounded, predictable path length.

Spell it out. Let the root be the source of rate D = 2.6 Tb/s. First hop: ~10 edges at D each (ten children). Second hop: each of those ten children has ~10 children → ~100 edges at D. Third hop: each of those ~100 has ~10 children → ~1,000 edges at D. The minimal edge count to span R = 1,020 receivers is R − 1 = 1,019 links carrying the stream. The multicast tree matches that order of work (up to the minor placement of the twenty miners), and critically, no link carries more than one copy of the traffic. Total link-work scales linearly in R; the source and per-link burdens remain at D.

Now contrast the gossip equivalent under the same three-hop constraint. To reach ~1,000 receivers in ≤3 hops, a fanout g ≈ 10 is required: 1 → 10 → 100 → 1,000 in the ideal, non-overlapping case. But gossip does not replicate at branch points under control; each participant re-sprays the payload to its peers. The source immediately explodes to g × D ≈ 10 × 2.6 Tb/s = 26 Tb/s, violating the hop budget’s intent before the first relay forwards a bit. The “path budget” also bloats. Idealised transmissions: 10 + 100 + 1,000 = 1,110. Real networks overlap: neighbours share peers, meshes echo packets, and deduplication is imperfect. With a conservative 30% redundancy, effective transmissions swell to ≈ 1,443, already ~1.42× the multicast floor of 1,019.

The hop limit sharpens the knife. In multicast, three layers are sufficient and exact: the root’s degree sets the tree’s width, and every receiver’s depth is bounded by construction. In gossip, three hops are a gamble. A slow or congested peer at hop one throttles ten downstream paths; buffer backpressure at hop two propagates upstream; duplicate suppression tables churn to discard the same packet arriving via multiple neighbours. The result is the familiar cocktail of hot links, buffer overruns, replays, and a fat-tail latency profile precisely when the network most needs determinism. The hop ceiling, intended to cap delay, instead exposes gossip’s lack of topological discipline.

Compute the “path budget” explicitly for 1,020 receivers. A multicast spanning tree uses 1,019 link-copies of the stream and guarantees depth ≤3 for all leaves (root → degree-10 → degree-10²). Place the twenty miners at hop one (root degree ~20) and fan the remaining ~1,000 exchanges over the second and third layers; the algebra is unchanged, only the branching split differs. Gossip under the same targeting must still honour g ≈ 10 to hit the width, but pays twice: uplink amplification at the source and mesh amplification across the interior. The hop budget is met on paper, yet wasted in practice by redundant paths and volatile queues.

The verdict is mechanical. With three hops, multicast preserves determinism: one injection, one copy per link, fixed depth, linear work. Gossip collapses into redundancy: tenfold source blow-up, ~40% excess link-work even in conservative models, and latency variance born of uncontrolled replication. The constraint that was meant to keep the network tight becomes a millstone for gossip and a natural fit for a multicast tree.

---

Section 6: Interest Filtering and SPV Proofs

The problem of transaction distribution at billion-scale is not merely a question of moving raw bytes; it is a question of where those bytes must, and must not, flow. The Simplified Payment Verification (SPV) principle—first articulated in the original design—was never a decorative option. It is the architectural safety valve that makes scaling possible, by ensuring that most participants never face the absurd requirement of swallowing the entire firehose. SPV dictates that lightweight clients need not process or store full transaction payloads. Instead, they validate transactions relevant to them using block headers and Merkle proofs. The elegance lies in the fact that this does not compromise security: a client can be assured a transaction is included in a block without replaying the universe of unrelated data.

Quantify the relief. Suppose one billion transactions per second, with an average size of 325 bytes, producing the firehose of 2.6 terabits per second at the source. If every one of the 1,020 receivers—miners and exchanges—were expected to ingest this stream in full, each would need the capacity of dozens of fully saturated 100-GbE ports or multiple 800-GbE and 1.6-TbE interfaces. Such requirements might be tolerable for twenty industrial-scale data nodes, but they are catastrophic for the thousand exchanges and service providers who have no interest in global replication. Here, SPV intervenes.

A Merkle proof for a transaction in a block of ten minutes’ worth of data at one billion transactions per second is deep, but not unwieldy. With ≈6×10¹¹ transactions per block, the tree depth is about log₂(6×10¹¹) ≈ 39 levels. Each level contributes 32 bytes of sibling hash, giving ≈1,248 bytes. Add 32 bytes for the transaction ID and a handful of bytes for the positional index, and one arrives at a compact proof of about 1.3 kilobytes. In other words, to verify that a transaction has been committed to the block, a client requires only the block header (80 bytes) and ~1.3 KB of proof material—not the 325-byte payload of every other transaction that happened to share the block.

The bandwidth savings are violent in scale. A full-payload receiver is bound to consume 2.6 terabits per second. An SPV client, by contrast, consumes bandwidth proportional only to its personal transaction rate multiplied by ~1.3 KB. An exchange handling a million customer transactions per second would therefore face ≈1.3 GB/s of proof traffic—not trivial, but within the range of contemporary datacentre links. The same exchange, forced to ingest the full firehose, would be obliterated under terabit demands. The difference between these figures is the line between theoretical possibility and operational ruin.

The design lesson is stark: the firehose is not a universal obligation. It exists only for the small cadre of miners or archival data nodes who must hold and propagate the full transaction set. For everyone else—the overwhelming majority of participants—proofs substitute for payloads. Exchanges, payment processors, wallets, and analytic services require only those slices of the data that intersect with their commercial or fiduciary responsibilities. For them, the replication of irrelevant transactions is wasted bandwidth, wasted storage, and wasted engineering effort. SPV cuts the fat, ensuring each participant carries only the weight of its own affairs.

Consider the exchange use case more closely. An exchange does not need to know the full details of every micro-transaction processed across the network. It needs certainty that the deposits and withdrawals made by its clients are valid, settled, and anchored into the blockchain. By ingesting block headers and demanding Merkle proofs for each transaction it touches, the exchange can achieve the same level of assurance that a miner does when validating blocks. The difference is that the miner must grind through the entirety of the data to build the tree, whereas the exchange can cherry-pick proofs from the tree that the miner has already constructed. The exchange’s security position is intact; its operational burden collapses from terabits to gigabits.

This division of labour is the only rational way forward. Attempting to place every participant on the same footing as a miner is a category error—an insistence that every clerk in a bank vault carry the entire reserve on his back. The network succeeds by differentiating roles: the few that must bear the full brunt, and the many that subsist on verified fragments.

Thus, the broader implication. A billion-transaction-per-second system does not spray the full load to all comers. It constructs a hierarchy: the core nodes ingest and replicate the full payloads, preserving the canonical record, while the periphery consumes only what it needs, with mathematical certainty delivered through proofs. The architectural mandate is clear. Build for multicast at the core to preserve efficiency in full-payload replication, and SPV at the edge to make participation accessible and sustainable. Replicate payloads only where necessary. Everywhere else, distribute proofs.

This is not an optimisation; it is survival. Without SPV and interest filtering, the network degenerates into an unscalable parody of itself, demanding impossible bandwidths from every endpoint. With them, the system divides its burdens according to necessity, scales beyond human imagination, and remains operable for ordinary participants. The firehose exists, but only for those designed to hold it.

---

Section 7: Latency, Loss, and Recovery

At billion-transaction-per-second scale, the distribution problem is no longer one of theoretical throughput alone; it is the unforgiving arithmetic of latency and loss. In such an environment, every millisecond counts, every dropped packet compounds, and every recovery path either reasserts order or magnifies chaos. The contrast between multicast and gossip is not a minor trade-off in implementation detail—it is the line dividing a bounded, stable system from one that collapses into entropy under its own chatter.

In a multicast architecture, the recovery problem is treated with mature engineering discipline. Streams are FEC-protected: forward error correction codes allow the receiver to reconstruct missing packets without begging for retransmission. Where FEC alone is insufficient, NACK-based recovery applies—receivers signal their need for specific packets along deterministic, low-fanout paths. Because the topology is a tree, not a mesh of improvisation, recovery signals follow predictable routes, and retransmission is a controlled supplement, not a competing flood. The multicast model thus couples two virtues: redundancy encoded at the source, and recovery bounded by clean, deterministic paths.

Gossip, by contrast, makes a virtue of disorder. Recovery is not centralised, nor predictable. Each of thousands of peers may resend fragments at slightly different times, with jitter introduced by processing queues, buffer states, and local scheduling. Duplication is not a safety net; it is a liability. Instead of one clean repair packet, dozens may arrive, often late and occasionally out of sequence. Worse, gossip architectures generate backpressure loops: a peer under strain slows its output, which cascades into its neighbours, creating oscillations across the network. The result is not recovery, but a proliferation of half-successful repairs and collisions, leaving receivers uncertain which copy of a transaction is authoritative.

The impact of these architectural choices is most brutally exposed in tail latency—the time taken to deliver the slowest fraction of transactions. In a multicast tree, tail latency is bounded. Paths are deterministic, repair strategies centralised, and delays accumulate linearly with hop count. Even under burst loss, the system can guarantee a delivery window measured in predictable multiples of round-trip time. In gossip, tail latency grows unbounded as load increases. Duplication storms create congestion collapse, late arrivals crowd buffers, and suppression algorithms trip over their own heuristics. What begins as millisecond-scale recovery metastasises into seconds of uncertainty at the system’s edges.

Reliability, then, is not a vague aspiration; it is an engineering preference codified in architecture. The multicast path reflects decades of research into efficient delivery: forward error correction to handle the ordinary, NACK recovery to handle the exceptional, and deterministic topologies to keep guarantees intact. Gossip substitutes determinism with hope. It spreads the cost of reliability to the periphery, assuming that endless peer retransmissions will somehow average out into coherence. But at billion-transaction scale, hope collapses under the arithmetic.

A network cannot afford to “probably” deliver. It must deliver, within bounded latency, and without collapsing its links in the process. Only multicast, with its structured recovery, provides this assurance. Gossip, for all its romanticised decentralisation, proves brittle in the only metric that matters: the certainty of timely receipt. In the economics of reliability, there is no middle ground. One system engineers for recovery; the other drowns in it.

---

Section 8: Architectural Mandate

At this point, the contrast between multicast and gossip is no longer an exercise in network theory but a blunt architectural mandate. The numbers do not lie: a billion transactions per second, averaging 325 bytes apiece, demands a throughput of 2.6 terabits per second. Faced with that torrent, only one approach holds its ground. Multicast delivers source stability, link efficiency, and deterministic behaviour. Gossip, by every measurable criterion, delivers the opposite: uplink explosion, redundant amplification, and unpredictable latency that metastasises as load grows.

Multicast succeeds because it obeys the logic of distribution rather than fighting against it. The sender produces a single stream; the network branches it where necessary; each link carries exactly one copy; and recovery operates on deterministic paths. Its resource profile scales linearly with the addition of receivers—edges increase, but neither the source uplink nor the per-link burden spirals out of control. It is a model of conservation in motion: efficiency and determinism applied at the root of the problem.

Gossip collapses precisely because it assumes that more chatter equals more safety. Each node spews multiple redundant copies; uplink demand balloons from 2.6 Tb/s to 26 Tb/s; redundancy multiplies total link-work by forty percent or more. Recovery, far from clean, is a miasma of overlapping retransmissions and jitter-induced uncertainty. The economic point is clear: waste at the foundation is not sustainable. A network designed to consume more bandwidth than physics will allow cannot scale, no matter how ideologically convenient its defenders find it.

This division between core and edge sharpens the mandate further. The twenty miner/data nodes are the only entities that must, by necessity, drink from the firehose. They alone require the full payload stream, for they alone write blocks and enforce the transactional ledger. Every other participant—exchanges, businesses, ordinary users—should not and cannot swallow terabit-scale flows. Their needs are satisfied through interest-based subscription: headers, filters, and Merkle proofs that compress relevance into tractable bandwidth. This bifurcation of roles is not optional; it is the only configuration that keeps the system within the laws of physics.

The economic dimension follows directly. Networks, like markets, survive only when they conserve resources. Multicast is efficient because it treats bandwidth as scarce capital. Gossip squanders it, multiplying cost for no gain, exhausting links, and rendering hardware unsustainable for all but the most fanatical hobbyist. The myth that gossip could somehow provide resilience is precisely that: a myth. Real resilience is engineered efficiency, not redundancy masquerading as robustness.

Why then does gossip persist in discourse? Partly, it is the fog of misunderstood decentralisation: the belief that if every node shouts loudly enough, freedom and fairness will be preserved. Partly, it is academic inertia: research papers valorising epidemic broadcast models for toy systems, never scaled into terabit territory. And partly, it is ideological baggage: a refusal to accept that structure and determinism can coexist with openness. The result is a stubborn clinging to a model that fails every empirical test yet survives as dogma in conferences and manifestos.

The mandate is therefore stark. If the network is to sustain a billion transactions per second, it must abandon the fantasy of gossip and commit to multicast plus interest filtering. Anything less is indulgence in mythology at the expense of physics. Multicast is not a choice; it is the only architecture that does not collapse. And in engineering, as in economics, collapse is not a theoretical risk—it is an inevitability when waste is enthroned as principle.

---

Conclusion

The arithmetic is uncompromising. At a billion transactions per second, averaging 325 bytes each, the network faces a sustained throughput of 2.6 terabits per second. Within that scale, the contrast between multicast and gossip is no longer academic—it is existential. Multicast delivers efficiency by holding the source burden constant, ensuring that each link carries only a single copy of each transaction. Gossip, in contrast, explodes the uplink tenfold, multiplies redundancy across every hop, and turns the act of distribution into a storm of waste. At billion-scale throughput, only multicast scales; gossip, by mathematical and structural necessity, does not.

The implications for system design follow directly. A network built to process digital cash at global scale cannot afford ideology in place of physics. Protocols that insist on gossip condemn themselves to collapse, for no amount of hardware can sustain terabits wasted on duplication, jitter, and redundant chatter. The architectural pattern that survives is multicast at the core—feeding the miner and data nodes with the firehose—and selective validation at the edge, where exchanges and users take only the flows they need. This is precisely the role of Simplified Payment Verification: headers, filters, and proofs that cut bandwidth from terabits to kilobytes, transforming the impossible into the routine.

The broader lesson is not simply about efficiency but about survival. Networks that conserve resources scale; networks that squander them implode. Multicast embodies stability, determinism, and sustainability. Gossip embodies redundancy, unpredictability, and failure under load. The choice is not between two equivalent philosophies but between a model that works and a model that mathematically cannot.

In the end, the conclusion is plain. Multicast is not an option in the design of digital cash at scale—it is a mandate. The fantasy that gossip could ever bear the load of global transaction throughput is revealed as precisely that, a fantasy. At a billion transactions per second, the network cannot indulge ideology. It must obey arithmetic. And arithmetic dictates that multicast is the sole architecture that sustains digital cash at scale.

---

Epilogue: Decentralisation Needs Multicast

Decentralisation is often romanticised as a cloud of gossiping nodes, each one passing messages along like whispers in a bazaar. But whispers scale only to the limits of a marketplace; they do not scale to billions of transactions a second. True decentralisation is not noise—it is distribution with structure. And distribution at scale requires multicast. Without multicast, decentralisation collapses under its own weight, leaving only a handful of centralised gateways capable of carrying the impossible uplink burdens of gossip. In other words, reject multicast and you do not strengthen decentralisation—you kill it.

Security flows from determinism. Multicast creates a clean, verifiable path from sender to all receivers: one stream replicated at branching points, each copy traceable, each loss recoverable by design. Gossip fractures security into chaos. Redundant forwards create uncertainty, packet collisions, and ambiguous delivery. In a gossip network, it is never clear whether a missed transaction was lost or merely delayed; in multicast, recovery is explicit, NACK-driven, and provable. Security is not the proliferation of copies but the certainty of one correct copy reaching all who need it.

Privacy, too, benefits from multicast. In a gossip mesh, every node sees every transaction multiple times, often forwarded redundantly across peers. This creates unnecessary exposure: nodes learn more about flows, patterns, and participants than they should. Multicast, by contrast, is subscription-driven. A receiver joins only the streams it needs, and the network delivers only those streams. This minimisation principle—receiving only what is necessary—protects privacy by design. Exchanges or wallets ingest only their relevant proofs, not the entire firehose. Gossip spills information everywhere; multicast directs it precisely.

The irony is that the ideological clinging to gossip is done in the name of decentralisation. Yet the physics of distribution dictate that gossip centralises power, because only the largest operators with vast uplink budgets can survive its waste. Multicast is the architecture that actually enables thousands of independent receivers, small or large, to participate under equal conditions. Efficiency is not a betrayal of decentralisation—it is its foundation. Without multicast, the network hollows into a central oligopoly; with multicast, it retains its diversity.

The final point is blunt. Decentralisation without multicast is theatre. It looks scattered, but in reality collapses into concentration, waste, and surveillance. Multicast restores what decentralisation promises: scalable security, bounded latency, minimal exposure, and the ability for many to participate rather than a few. The very values invoked by decentralisation—resilience, openness, privacy—are not sustained by gossip’s noise. They are only preserved by multicast’s discipline.