Edge Cases: Part 2.3 — Protocol Locality

By: Jack Davies

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:

So, how have things changed from the extant paradigms of November 2018?

Well, the concept of using short hexadecimal prefixes for certain protocols is still in full force. The Metanet protocol itself does, of course, use the protocol prefix 0x6d657461, which is just the hex representation of the word ‘meta’.

The current standards for hexadecimal protocol prefixes, used for all manner of Bitcoin SV applications, can be found in the documentation here.

Moreover, you can find a list of Bitcoin SV application protocols using this specification listed on the same github repository, which currently looks like this:

The hexadecimal prefix methodology is clearly still popular, and is used by a number of compelling applications on Bitcoin SV today. However, as many of you may already be aware, an alternative new paradigm has also emerged alongside the existing hex prefix method.

Learn more about the Metanet, and read the full post and the rest of the series on the nChain Medium account here.

Other Blog Posts

Nakasendo™ (Beta) Version 0.3.0 Goes Public

Team nChain Read

Payment Channels and Smart Contracts on Bitcoin*

Wei Zhang, Senior Researcher Read