Network & Protocol / Data Infrastructure
One of the obvious objections to using multicast for large-scale BSV Blockchain data distribution is also one of the simplest:
The public Internet generally does not forward multicast traffic between networks.
Lightweb Inc. accepts that limitation rather than assuming it will disappear.
In a new engineering paper, Multicast over a unicast Internet: the fabric is an overlay, developer Jeff Harris describes how the 1BSV distribution architecture is intended to operate across today’s Internet by treating ordinary unicast tunnels as links between multicast routers.
The Internet itself never has to understand or forward the multicast traffic inside those tunnels.
That distinction connects several pieces of Lightweb’s broader 1BSV work: transaction distribution, BEEF application objects, selective subscriptions, retransmission, regional routing and the economics of operating a shared intake and delivery network.
The paper does not establish a new throughput record or prove operation at the largest scales discussed in the architecture. What it provides is something different: a detailed explanation of how a multicast-oriented BSV distribution network could be built over infrastructure that remains predominantly unicast today.
The Internet Only Has to Carry Unicast
Lightweb begins from the conventional networking objection.
Transit providers generally do not carry customer multicast traffic across the public Internet. Internet exchanges do not automatically switch it between participants, and ordinary access networks may simply drop it.
The proposed 1BSV fabric does not require them to change.
Instead, multicast routing occurs between routers operated as part of the fabric. Where two of those routers cannot connect over a multicast-capable physical link, Lightweb proposes carrying the multicast packet inside a GRE tunnel between them.
To the surrounding Internet, that tunnel is an ordinary point-to-point unicast connection.
A router on one side takes the multicast datagram, adds an outer unicast IPv6 header and GRE encapsulation, and sends it to the known address of the router at the other end. That router removes the outer headers and presents the original multicast packet to its own routing system.
The Internet therefore sees a normal packet traveling from one address to another.
The multicast tree exists between the fabric routers.
This is not a newly invented tunneling technique. GRE is an established networking mechanism. Lightweb’s architectural choice is to design the distribution fabric so that a tunnel can be treated as an ordinary link in the multicast topology rather than as an exceptional workaround.
Ingress, Spine and Edge
The paper organizes the fabric into three functional tiers.
Ingress is where a transaction or other supported object enters the system. The sender reaches an ingress point, which assigns the information needed for distribution and emits the object into the fabric.
Spine routers carry the multicast trees between regions and reproduce traffic where a tree needs to branch.
Edge routers receive the subscribed traffic at the destination side of the tree and hand it to miners, service providers or applications.
The final delivery from an edge to an ordinary consumer can still be unicast.
That is an important part of the design because a wallet, exchange, application server or other subscriber does not itself have to become part of a multicast-enabled public Internet.
The multicast fabric handles shared distribution between network points where replication is useful. At the edge, the selected stream can be delivered through familiar unicast connections.
This creates a separation between how the shared network distributes one stream efficiently and how an individual customer ultimately receives it.
The Tunnel Approach Has a Cost
Running multicast over point-to-point tunnels does not reproduce every efficiency of native multicast.
Lightweb’s paper is unusually direct about that limitation.
On an IPv6 path, the described GRE arrangement adds 52 bytes of encapsulation to each packet. A 1,500-byte path therefore has less room available for the inner multicast packet.
There is also replication at tunnel branch points.
The paper gives a worked example involving 800 subscribers, divided among eight edge routers with 100 subscribers each.
If the publisher sends an independent unicast copy to every subscriber, its side must originate 800 copies.
In the overlay example, the publisher emits one copy into the fabric. A spine router then produces eight copies—one for each downstream tunnel—and each edge handles delivery to its 100 local subscribers.
Native multicast on a shared link could reduce that spine replication further, but the tunnel version cannot.
The comparison is useful precisely because it is not presented as free efficiency.
The architecture moves the replication burden away from every publisher and concentrates it at selected network branch points, where links and routers can be provisioned for that role.
The 800-subscriber example is an architectural illustration with stated assumptions, not a measured production benchmark.
Missing Packets Are Repaired Near Where They Were Lost
Multicast distribution also creates another practical problem: the sender does not maintain an individual delivery session with every receiver.
If a packet goes missing, somebody has to detect the gap and recover it.
The 1BSV design uses sequence information in its frames for that purpose.
A receiver that sees frames 1, 2, 3 and then 6 can immediately determine that 4 and 5 are missing. It can request those specific frames from a nearby retransmission cache rather than asking the original publisher to resend the entire stream.
If the nearest cache does not have them, recovery can move farther upstream.
This mechanism is formalized through BRC-126 — Multicast Transaction NACK Retransmission Protocol.
The important architectural point is locality.
A packet lost close to one receiver does not necessarily require the original sender to retransmit it globally. Repair traffic can be handled closer to the part of the network where the loss occurred.
The same recovery mechanism is intended to work regardless of whether the underlying link is a physical cable, a cross-connect or a GRE tunnel.
Application Data Does Not Have to Be One Giant Firehose
The multicast-over-unicast paper explains how the fabric can cross today’s Internet.
A companion paper, Sharding the object plane: topic bits turn one firehose into network traffic an operator can shape, addresses a different question:
What if an application only wants a small portion of the data moving through that fabric?
Lightweb’s BEEF object plane is designed around topics.
Each topic receives a SHA-256-based identifier. Leading bits from that identifier place the topic into a multicast band, while the full identifier continues to distinguish the exact topic.
The network therefore does not need a separate multicast route for every application topic in existence.
Routers forward groups of topics at the band level. Near the consumer, filtering can narrow the arriving objects to the exact topics the subscriber elected to receive.
This means a wallet or application interested in particular overlay data does not necessarily need to consume every object produced by every other application.
The same distribution fabric can carry a large topic space while applications subscribe selectively.
Sharding Does Not Remove Network Limits
The object-plane paper is also careful about the constraints.
Multicast routers maintain state for the source-and-group combinations receivers join. That state is finite.
Lightweb therefore does not propose creating one multicast group for every topic or using the entire available address space simply because the addresses exist.
The paper describes a practical join budget in the range of a few hundred source-group entries per receiver. In its example operating posture, that leads to a much narrower number of active bands—roughly 128 or 256 across two regions—rather than tens of thousands of groups.
There is another limitation: widening the number of bands can split traffic when a band becomes busy, but it does not automatically divide one exceptionally hot topic across several groups. The paper reserves such a mechanism for future work rather than claiming it has already been solved.
That distinction helps keep the architecture grounded.
The object plane avoids routing state that grows directly with every application topic, but it still operates within the forwarding, subscription and hardware limits of real routers.
The Economic Model Separates Intake From Delivery
The third Lightweb paper, The cost of being reachable: transaction-intake economics for Teranode miners, adds an economic layer to the same architecture.
Its premise is that global transaction intake has a cost.
A miner that wants low-latency submissions from users in multiple regions can build its own global footprint, rent reach from infrastructure providers or participate in shared intake infrastructure.
Lightweb’s proposed 1BSV model separates the cost of admitting data into the shared fabric from the cost of delivering selected streams to consumers.
The current model describes transaction admission as carrying no additional 1BSV intake charge, while delivery is the metered service.
A miner, service provider or application pays for the streams it elects to receive rather than charging every sender for entering the network.
This does not mean the network itself is costless.
The paper explicitly models substantial bandwidth, site, hardware and operational expenses at extreme throughput. Its vendor-cost figures are planning models rather than negotiated commercial quotations, and the largest-scale scenarios are not production measurements.
The economic argument is narrower: a shared distribution fabric may avoid each miner or service provider independently constructing and paying for the same global reach and repeated copies of the same traffic.
Whether the commercial model ultimately proves competitive requires deployment experience and real operating costs beyond the paper’s estimates.
The Fabric Can Be Upgraded Link by Link
One of the more practical elements of the multicast-over-unicast design is that the tunnel architecture is not presented as the final ideal form.
A GRE tunnel connecting two routers today can later be replaced by a direct cross-connect if both operators reach the same facility.
A conventional 1,500-byte connection can later become a larger-frame link.
If two networks eventually support compatible native multicast peering, the tunnel between them can be replaced by that native link.
The higher-level distribution model does not have to change each time.
The multicast groups, subscriptions, frame formats and recovery mechanisms remain the same; only the link connecting two points improves.
That gives the architecture a progressive migration path rather than requiring native multicast support across the wider Internet before the system can begin operating.
Implementation Exists Beyond the Papers
Lightweb has also published substantial implementation material around the architecture.
The public bsv-multicast project documents components for ingress, multicast listeners, retransmission caches, shard manifests, infrastructure deployment, traffic generation and integration bridges.
The repository also includes bridges designed around Teranode and Arcade, alongside a growing family of multicast-related BRC specifications.
Lightweb currently describes 1BSV as a production deployment of this layered multicast architecture.
That statement should still be separated from broader performance claims.
The existence of software, specifications and an operating service does not by itself establish independent commercial-scale measurements, widespread integration among Teranode mining operators or demonstrated operation at the billion-transactions-per-second scenarios discussed in planning material.
Those remain different evidentiary thresholds.
From Network Theory to an Operable Topology
BSV TIMES has previously covered pieces of this work.
Early 1BSV multicast development appeared in the former Today’s Community Picks in June, while an October Under the Surface edition examined BRC-135, which allows an 80-byte block header to be distributed independently from a larger block announcement.
The newer Lightweb papers provide a broader frame around those individual components.
They explain how the multicast protocols are intended to fit into an actual network topology, how application traffic can be selectively distributed, how missing data can be repaired, and where the operator expects the costs of such a network to fall.
The central engineering idea is comparatively simple:
multicast inside the fabric does not require multicast across the public Internet.
The Internet can continue carrying ordinary unicast packets between known routers. The fabric uses those links to build its own multicast trees, replicates traffic where the topology branches, repairs losses through nearby caches, and delivers selected streams to consumers at the edge.
That architecture still has costs and limits.
Tunnels add overhead. Branch points replicate traffic. Router subscription state remains finite. Extremely hot topics require additional work. Global intake and delivery still consume substantial bandwidth and infrastructure.
But those limitations are part of the published design rather than being ignored.
For Under the Surface, that is what makes the current work notable: it moves the 1BSV multicast discussion away from an abstract claim that “the Internet should support multicast” and toward a documented question of how a multicast distribution fabric can be engineered around the Internet that already exists.
Developer Context
Jeff Harris — Lightweb Inc. is the author of the three engineering papers and the principal author behind a substantial family of BSV Blockchain multicast standards.
Relevant work includes:
- BRC-124 — Multicast Transaction Frame Format
- BRC-126 — Multicast Transaction NACK Retransmission Protocol
- BRC-129 — IPv6 Multicast Group Address Assignments
- BRC-135 — Multicast Block Header Frame Format
- BRC-148 — Multicast Shard Domain Partitioning and the BEEF Object Plane
- BRC-149 — Multicast BEEF Object Frame Format
The public Lightweb repositories also contain implementation components for ingress, listeners, retransmission, manifests, testing, infrastructure deployment and integration with other BSV Blockchain services.
Source Links
Multicast over a unicast Internet: the fabric is an overlay — Lightweb Paper 012
The cost of being reachable: transaction-intake economics for Teranode miners — Lightweb Paper 003
Lightweb BSV Multicast — GitHub
BSV TIMES — Today’s Community Picks, June 14, 2026
BSV TIMES — Three Developments Under the Surface: Payments, Offline Identity and Block Headers
BSV TIMES – Under the Surface
Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.
Update — October 29, 2026
Leave a Reply