October 16, 2019

Edge Cases: Part 2.3 — Protocol Locality


Read the full post and the rest of the series on the nChain Medium account here.

Welcome back to Edge Cases, the Metanet blog series. If you’re just joining us, you can find the start of the series here.

In the last post, we looked at the types of domain structure that emerge from the properties of trees created using the rules of the Metanet protocol. We looked at how such tree structures can be mapped to domain-like constructs, and how we can interpret the permissioning hierarchy of the Metanet protocol as similar in function to the chain of trust model employed by many parts of the existing Internet.

Today, we look at how Metanet graphs interact with existing data-oriented protocols that have been developed for use on Bitcoin SV in recent months, and how they lead to a richer description of the content data embedded within such tree structures.

Part 2.3 — Protocol Locality

We begin today’s post by casting our minds back to late November 2018. It was then, at the CoinGeek Week conference, that Dr Craig Wright made the first public announcement of his vision of the Metanet.

In order to understand exactly where the Metanet protocol sits within the thriving present-day landscape of Bitcoin SV, we first need to understand exactly how the playing field looked back then, and how it has evolved in the subsequent months.

At the time of the talk, there were a number of OP_RETURN protocols already publicly described and up-and-running, with various functions, such as the Tokenized protocol and the blockchain-based Memo platform.

The standard at the time was that such protocols were added to a central Github registry, which you can still find here. Each protocol is assigned a 4-byte protocol prefix, which is then used as a marker in an OP_RETURN transaction output to indicate that a given transaction has been created according to a particular protocol specification or certain rules.

The wider ecosystem would then refer to this registry as the central source of information when (i) trying to use an existing protocol; or (ii) trying to design and add a new protocol.

The registry, as it survives today, looks like this: