The Technical Debt of Bitcoin’s Supplementary Layers

wire_turn
5 min readAug 31, 2021

--

For the last 3 years, contributors building on top of the original Bitcoin protocol have been racing to define, build and accumulate essential libraries, APIs and protocols, in a mission of utmost urgency. To rapidly prototype workable solutions for the layers that define the Metanet; a vast and complex network of disparate microservices that empowers and subsumes the internet. Many of these are missing pieces that were planned for in the early days of W3C’s toolset, yet never fully realized.

In the early days of the web, there were plans for micropayments, peer networks, native secure handshakes, digital signing protocols, native payment channels, inbuilt secure identity layers, universal keychains, monetization templates, 3rd party data sharing options and P2P communication with E2E encryption built in. These were the hardest hurdles to conquer, but Bitcoin and its native scripting predicates gave us a whole new toolset for addressing many of these internet layer issues.

As the BSV reference node implementations grew in iterative on-chain scaling capacity, developers who aligned with Satoshi’s original vision for Bitcoin began a veritable cornucopia of frenzied building. Buttons, logins, auths, handshakes, wallets, icons, avatars, games, indexers, uploaders, caching, mapping, emulators, point-of-sale, social and network tools and a whole set of libraries, APIs, SDKs, schemas and protocols to manage on-chain deeds, trusts, multiparty signings, images, audio, video, attestation, documents, files, ticketing, identity, SPV, concatenation, obfuscation, metadata, tokens, NFTs and many, many more.

Quick and dirty iterative build and release cycles. That’s how groups of individuals aligning to a common goal develop in small, disparate groups around the world. Very rarely will you see a dedicated DevOps team, Scaling Engineer, Enterprise Architect, Solutions Architect or even a SysAdmin. More often than not, it’s a small group of people with an idea and zero VC funding, struggling to grasp the latest tools available and build using them, with gusto.

The predominant language of choice for most of these tools during BSV’s first 3 years has been JavaScript. JavaScript has a huge following, has a massive gamut of libraries to choose from and is very easy to learn and use, especially when paired with popular JS libraries like React. With the advent of Node.js the sheer range of tools that any budding developer could want, was now freely available in some flavor that could be extracted to create applications that, would at the very least, act as a proof of concept.

JavaScript’s most compelling feature is the speed and ease of developing rapid prototypes and having a wealth of ever-growing libraries to choose from, which meant there was always something, somewhere that was suitably befitting from a plethora of open source libraries from many projects.

We are now in the era of not so small blocks, in the ballpark of a few gigabytes. Already we are beginning to see that this early prototyping infrastructure, built to compliment Bitcoin’s true unbounded scaling abilities, is fast being made obsolete. Obsolescence is something that enterprises expect and plan for, especially having all of those scaling and architectural boffins focussing on that very specialist engineering issue as a full time career.

We are now faced with a new problem. This is a problem that will bite us all very quickly, if action is not taken immediately. Every second layer solution built in the last 3 years is already obsolete, completely useless the moment that Teranode (BSV’s next iteration of scaling microservices Bitcoin node implementation) drops. All of the 3rd party software we rely upon today will become a massive bottleneck for applications scaling on BSV.

This is something to take very seriously. A chain is only as strong as its weakest link. The last thing we all need right now is to give our detractors more ammunition, especially when it is completely avoidable. If you think the rate of growth upon BSV this last 3 years was impressive, the growth predicted over the next 3 years will be exponential. None of our wallets, buttons, indexers, uploaders, games, script emulators etc. can handle tomorrow's load, so we need to plan now.

JavaScript was great, it still is. We can still iterate and speed up various improvements. Certain BSV NPM libraries are suitable for porting over to DENO. Although still early days, DENO is NODE’s successor and handles JavaScript’s superset, TypeScript. TypeScript supports better memory allocation and optimization and is a compiled language, so is a much better all-round performer.

This isn’t a fix though, we’re going to need to either refactor or re-write everything from the ground up. Before, I did this mostly alone, now I will need help. I don’t need developers, I need the support of the enterprises building on BSV to reach out to me, so that I can prioritize my workload.

Over the coming weeks and months, I will begin rapidly releasing code into the public domain. I will not be discriminating against C, C++, Rust, Go or Julia. Each project will be evaluated on its own merit and each project will be looked at from a macro perspective and given its own considerations.

First, I will start out small, fixing and refactoring some of the most pertinent issues both behind the scenes and publicly. I am very aware that there are technical standards committees in effect, and in principle I support this continued roadmap. Sadly, there are no plans to upgrade the technical debt we inherited, due to the rapid release cycle we adopted, caused by ourselves in the early days.

Now, I must get to work…

--

--