The ‘mysteries’ of Teranode find explanation in mundane realities

Find the limits, imagine the future beyond them, and get it built somehow. That’s what has driven BSV development to this current point in our quest to achieve a true globally-scaling, efficient blockchain network. BSV Association’s Teranode development team has released a new node software that adheres to the original Bitcoin protocol—one that will finally be the game-changer this industry has promised for years.

Like many other aspects of BSV, it’s also ahead of its time. The world desperately needs this technology, even if most don’t yet understand why. We feel privileged to be among those who do understand, and are in a position to shift the paradigm.

Recent examples of this include discussions around Multicast, a one-to-many method of communicating a single data packet, efficiently and near-simultaneously, from a single source to multiple intended recipients. In the blockchain context, it’s the ability to propagate transaction data to all nodes, without the linear bandwidth duplication of existing protocols using “Unicast fan-out.”

“Teranode’s architecture is designed to take advantage of IPv6 Multicast features to reduce duplicated traffic dramatically, as well as total network load,” said Siggi Óskarsson, Director of Teranode at BSV Association. “By doing this, it therefore reduces cost while allowing far more receivers (nodes, services, participants) to consume the same stream. Multicast matters because it changes the scaling curve.”

But does Multicast always work the way people need it to? That’s where things become more complicated.

Given that technical discussions often take place in public, there’s a need to clarify certain terms and situations. Readers of, and participants in, these discussions have various levels of knowledge on different aspects of the technology. This can lead to misunderstandings when specific points remain unaddressed, or even instances of disinformation from others deliberately seeking to muddy the waters around BSV.

Óskarsson said Teranode’s protocol itself is not mysterious, and no aspect of it remains unsolved.

“What it does mean is that the Multicast concept can be said to be “unsolved” in wider-world practice. This is because backbone networks that most people depend on, particularly cloud and transit environments, themselves tend not to implement end-to-end, customer-usable IP Multicast as a first-class, widely-distributed service across their fabrics.”

Yes, these environments can move packets and do any number of overlays, he added. They can offer point-to-point connectivity at enormous scale. However, providing broad, routable multicast across the backbone is not yet a priority for them. At present, demand for this particular feature is limited, and operational complexity is real. Like IPv6 adoption itself among internet service providers and network administrators, it isn’t worth the time and effort… for now.

Other ways to approach the distribution problem 

Teranode’s own documentation states: “While currently using libp2p, Teranode’s architecture is designed to potentially benefit from IPv6 multicast in the future for even more efficient transaction dissemination, though this is currently limited by AWS platform constraints.”

If today’s reality among modern cloud hosts doesn’t include ubiquitous, end-to-end multicast distribution, then what are the other possible solutions? They may include: content delivery networks; relay meshes; application-layer fan-out; managed pub/sub; or purpose-built overlay distribution.

These all work, but also come with their own limitations and frictions that some engineers will inevitably encounter. Then once again there’s the issue of cost and labor, just moved to another place. Someone has to design and run it, and someone has to pay for it. Do the economics work any better for these solutions than they do for multicast distribution on cloud hosts?

In a perfect world, we’d have infinite resources in the form of skill, labor, time, and money to build new solutions tailored to meet all requirements. Since that isn’t the case, the most efficient option is to use existing services.

Perhaps, instead of using terms like “catch-22” or “chicken/egg,” we should rephrase it instead as a “temporary misalignment of incentives,” and remain mindful that this is often the case when deploying new technologies to meet a variety of needs. Over time, incremental improvements are made and each one unlocks a new capability. Eventually, almost everyone gets what they want to complete their vision, even if they don’t receive all their presents in one stocking, on the same day.

Until then, the alternatives exist, but they require deliberate architecture and money, usually in the form of CDN-style distribution or overlay systems. That is why “there are solutions” yet “nothing is implemented,” at least at the level people expect.

Our best chance, then, is to continue making our voices heard, with solid use cases and convincing arguments, to those with sufficient skills and resources.

This is exactly the spirit that produced Bitcoin and blockchain in the first place. Our mission has always existed at the outer limits of what technology can and should do. It doesn’t always find a receptive target immediately, but is instead the beginning of a long and often too-slow journey to success.

If you’ve read this far, you’re probably interested enough to consider jumping on board. There is room for all skillsets and capacities. BSV is already leading the way and demonstrating to other blockchain networks what’s possible, and in a way it’s our job to hit limitations before breaking through them.

Watch | Teranode explained: BSV leaders on blockchain scaling & the future of digital economy