Edge Cases: The Metanet Blog
Part 2.2 — Domains, Naming, & Locating
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 took a detailed look at the node and edge structure that underpins the Metanet DAG, and how it can be used to create applications that require structured data with an in-built permissioning hierarchy. In today’s post, we are going to examine some of the emergent properties of the Metanet graph, and the trees within it, to see the features and utility that is achieved by the rules of the Metanet protocol that we described last time.
Part 2.2 — Domains, Naming, & Locating
The node and edge structure we detailed in the previous post delineated that nodes are transactions and edges are signatures in the Metanet graph. In addition, we also saw how the rule set of the Metanet protocol prescribes the tree structures of the Metanet in such a way that leverages the power of digital signatures, which are native to Bitcoin SV, to ensure that the write access for any node in the graph is well-defined by key pairs.
Before we look at the properties of such tree structures more closely, we should briefly re-cap the rule set that we established for the Metanet protocol.
Recap of the Metanet Protocol Rules
We were able to distil the Metanet protocol, describing on-chain graph structures, into four fundamental rules:
1. Nodes are transactions;
2. Edges are created by signatures;
3. Each node is uniquely defined by the pair (P(node), TxID(node)); and
4. Each node must specify the node ID of itself and its parent.
These rules are the absolute essentials that allow us to describe well-formed graph structures that can live natively on the blockchain. In order to begin mapping such structures to typical use cases and applications for on-chain data, we also introduced two additional rules:
5. The in-degree of a node should be 0 (no parent) or 1 (one parent);
6. The out-degree of a node should be free.
These extra two stipulations, expressed using the language of graph theory that was introduced in part 2, are the only necessary additions that we require in order to begin thinking about hierarchical Metanet graphs that can be used to represent real-world usages, including websites, file systems, directories, and much more.
We will see, shortly, how the combination of these six rules now allows rich domain structure to emerge from Metanet graphs.
Metanet-Valid Transactions and Edges
A concept, or rather a terminology, that was introduced during my CoinGeek talk was that of ‘Metanet-valid’ transactions and edges. What I mean by ‘Metanet-valid’ is anything that appears valid according to the Metanet-protocol rule set we have just discussed.
At this point it is important to note that it is, of course, possible to view Metanet-validity based on differing sets of criteria. I have therefore made the distinction between the fundamental rules 1. — 4. and the additional rules 5. — 6. in the last section; we could perfectly well perceive two nodes as Metanet-valid or invalid, depending on whether it follows just rules 1. — 4. or rules 1. — 6. in their entirety.
We consider Metanet-valid transactions and edges as those which are prescribed by the rule set 1. — 6. for the rest of today’s post.
This is sensible at this stage, since these rules describe the trees that are shown in the technical summary, the slides from my talk, and indeed almost all of the Metanet structures that are being built on the blockchain already by services such as Bitmesh, Rate-SV, and many others currently in the works.
So, if we turn our attentions back to what such Metanet tree structures look like at the node and edge level, we can understand very simply what we mean by Metanet-valid nodes and edges.
In the diagram below, both transactions, according to our set of six rules, are considered Metanet-valid. The transaction on the left is a Metanet-valid root node since its input signature stems not from a parent node, while the transaction on the right is a standard Metanet-valid node since its input is signed by the parent node. It follows that a Metanet-valid edge is also defined between the two nodes, as shown by the blue arrow:
It should also be noted that both transactions above must also be ‘Bitcoin-valid.’ In other words, both transactions must follow the rule set of the underlying blockchain protocol in order to be deemed valid by mining nodes and included in a block on the blockchain.
If we consider now, instead, what happens when an attempt is made to create a Metanet edge without the correct input signature, we see in the diagram below that it is impossible to do so:
In the above example, Alice starts by creating a valid root node on the left. A bad actor, Bob, now attempts to create a child (on the right) of Alice’s node without her permission (i.e. without access to her key-pair). It is clear in such a scenario that both the node that Bob creates and the edge between it and Alice’s root node will be deemed Metanet-invalid according the rule set established for the Metanet protocol.
Such validity or invalidity is how the permissioning structure we discussed in the last post manifests itself through the Metanet protocol. It is by applying our simple rule set to each transaction that we can both interpret and enforce the desired write-access controls for any node in a Metanet tree.
Domain Structure
It is a simple extension of the ideas we have just discussed to see how hierarchical domain-like structure naturally emerges by simple application of the Metanet-protocol rules.
Consider a simple binary hierarchy as shown in the three ordered figures below. From what we have just established, we know that there is a clear permissioning hierarchy that defines the write-access for the tree. We can follow the flow of permissions through the tree in the following steps:
- Only the owner of P(0) can create children of the root node:
2. Only the owner of P(1) can create children of the left child node:
3. Only the owner of P(2) can create children of the right child node:
We can see that, for any given node in the tree defined by two data elements (P(node), TxID(node)), the permission to create a child of the same node lies solely with whoever (or whatever) has the ability to sign using the key pair associated with P(node).
Herein lies the key innovation of the Metanet protocol. That the ability to create a Metanet-valid child of a node rests with the burden of being able to produce a signature on that child is precisely how the Metanet protocol achieves its permissioning hierarchy and, indeed, domain structure.
In fact, for those familiar with the architecture of the Domain Name System (DNS), and in particular the DNSSEC, the permissions flow that I have described as dependent on the ability to sign over a child may be starting to sound familiar. Indeed, there is a strong analogy to be made between the permissioning hierarchy of the Metanet protocol and the chain-of-trust model used in the infrastructure of the DNSSEC.
In this model, domains are effectively secured by a sequence of certificate authorities (CAs) successively signing over one another to create a hierarchy until an end-point certificate is reached. It is no great leap, then, to see how we can begin to map and implement domain structure within the Metanet protocol.
Domains
Now that we have a good understanding of the hierarchical graph structures that can be created with the Metanet protocol, and we know how such structures look in terms of transactions and signatures, we can demonstrate mapping a domain structure to them.
The reason I said that there was an analogy between the DNSSEC and Metanet graphs is that I wanted to make clear the point about a chain-of-trust model, which is common to both. The precise function of the DNSSEC, and CAs in general, may differ from what can be done in a given Metanet tree — although the concept of actually implementing such CAs on-chain is something worth its own discussion, one which my other colleagues at nChain may be best suited to facilitate properly.
But, the key point to take away from today’s post is that the fact that a chain-of-trust model exists as part of the Metanet protocol allows for the representation of structures akin to websites and other online domain types.
Consider the simplest example, whereby we want to implement a fully-fledged on-chain website using only blockchain transactions that follow the Metanet protocol. Using our discussion from the previous section, doing so can be as simple as representing the entire website in a hierarchical fashion as a Metanet tree, and treating the root node of the tree like a top-level domain (such as ‘.org’).
By treating the root node as our top-level domain, we can further define sub-domains by simply treating children (and grand-children etc.) as subsequent sub-domains (such as .wikipedia or .nchain) as shown in the diagram below:
Based on our understanding now, we can say that the domain, as defined by a node, corresponding to ID(node) is the set of all descendant nodes for which the node is an ancestor. In other words, we introduce the following definition for a domain in the Metanet protocol:
A domain defined by ID(node) is the set of descendants of ID(node).
We see immediately that this definition of a domain in the Metanet protocol not only defines a domain according to a particular node in the graph, but because we defined ID(node) to be dependent on P(node) earlier, it also encodes the permission to make changes (i.e. write access) to the domain.
The diagram below shows how the paradigm of defining a domain as the set of all descendants of a particular node effectively means that each sub-tree in a Metanet structure can be used to define a new sub-domain.
To put it more formally:
A sub-tree in a Metanet structure defines a sub-domain.
Now that we have a clear understanding of how rich domain-like structure can be realised by simple application of the Metanet-protocol rules, we need to ask ourselves a significant question: what about identity?
Anchoring to Identities
It should be clear at this point in today’s post, and particularly if you’ve been reading the rest of the series, that:
The Metanet protocol does not solve ‘the identity problem.’
The problem we are referring to here is of course that of being able to safely, securely and robustly manage and utilise our identity in the context of digital activity, e-commerce and social interactions online. As I’ve mentioned on many occasions, the Metanet protocol’s primary function is to allow structure and permissioning for on-chain data and utility. As such, the Metanet protocol should be a beneficiary of any such solution that addresses the identity problem to a satisfactory degree.
In the technical summary of the Metanet protocol, we made this clear by assuming that a robust mapping exists between real-world identities and their Metanet-protocol counterparts. In reality, such counterparts are the nodes of Metanet structures themselves — in particular root nodes. For example, consider a root node representing an on-chain blog written by Bob that is defined using the Metanet protocol by:
ID(root) = ID(bobsblog)=H(P(bobsblog)||TxID(bobsblog))
In the technical summary, we made the assumption that a reliable and robust mapping exists between Bob’s real-world identity ‘bobsblog’ and the root-node ID of his on-chain blogging website. Such a map would functionally look like the following:
It is clear, then, that the Metanet protocol is not a catch-all solution for every aspect of achieving the goals and vision of the Metanet as a fully-fledged, blockchain-based value network. Instead, the Metanet protocol has been designed to make the best use of such a solution to on-chain identity management. In other words, once a suitable map between real-world identities and on-chain data exists — an identity management system — the Metanet protocol allows creators and users to apply such a system to their Metanet graph structures.
The diagram above illustrates the simplest and most straightforward example of how the Metanet protocol can utilise such a solution for identity handling and management. We have simply anchored a root node to the real-world identity. It is a simple yet powerful example of how the Metanet protocol can be combined with such a solution to implement websites, document management, and much, much more on the Metanet.
The Metanet protocol + identity management = ownership of data.
The above statement may seem like a bold one, and of course there are implementation details that it inevitably simplifies, but we can see that the combination of structured on-chain data and proper identity management is one of the fundamental pillars required to realise the aims of users reclaiming sovereignty over their online data.
The good news is, there is already significant proof of work that is going into finding the best solution for handling on-chain identity.
We have seen a number of projects and developments working hard to see the same goal realised, including:
- LegallyChained;
- Paymail;
- protocols such as AIP, BAP, MAP, etc.; and
- whatever magic may emerge from CambrianSV!
The use of the Metanet protocol is far from contingent upon such a solution to identity management. But, we can see that some of its true power will be realised once we can safely consider the issue resolved — watch this space.
Naming & Locating
Once we have established our domain-like on-chain structures, and been able to map real-world identity to them, we can begin playing around with the meaning we ascribe to each node in a graph.
In the simplest example, we can begin to assign ‘names’ to our Metanet nodes, which may in practice be in the form of a flag, raw text, or some other format — depending upon the particular use case. More generally, by ‘name’ we simply mean an element(s) that tells us something interesting about the node. We could call it ‘metadata,’ but that might get confusing to read and write about very quickly for obvious reasons…
We instead call such elements ‘attributes,’ which are additions to the fundamental four elements that we stipulated a Metanet node must always have and which we detailed in the last post.
The diagram above shows a node now identified by a MetanetURL (MURL), which is simply a conceptual model for some resource locator to find Metanet nodes.
I would stress here that the idea of a MURL is a conceptual one. It allows us to consider how the process of traversing a Metanet graph is closely related to the way in which Uniform Resource Locators (URLs) are used to traverse content resources in the existing web.
The diagram below shows our conceptual definition and model for a MURL, the Metanet analogue of a URL:
We see that, like a standard URL, it is largely made up of four main components:
- Protocol identifier — a way of specifying which protocol we are using to resolve the MURL.
- Domain — a domain, which has been (or can be) mapped to a real-world identity.
- Path — a path through different nodes in the graph, expressed by an ‘attribute’ of each node.
- Name — the ‘attribute’ of the target node.
What I have just outlined will make much more sense (as always) when shown visually, as we see how such a MURL demonstrates a process of graph traversal for Metanet structures:
In this diagram, the target node is named ‘tennis’ using an attribute. The path to the target has been expressed in terms of the attributes of the nodes that lead to the target, and the domain has been defined by mapping the real-world identity (or domain space) to the unique identifier ID(node) of the root node.
So really, a MURL as described here can be viewed either in its abstracted form — as it should appear to a user in a browser — or in its lower-level form, where we understand what each part of the MURL refers to in terms of Metanet graph components.
Abstracted: mnp://bobsblog/sport/tennis
Low-level: mnp://ID(node)/attribute(path)/attribute(target)
The key concept to take away from here is that we can construct resource locators for the Metanet that allow us to leverage the intrinsically efficient searchability of traversing DAG structures.
We have already seen novel approaches to URLs implemented to find content by TxID reference (B:// protocol) and by content hash (C:// protocol). It is an extension of such paradigms — the desire to find on-chain content using new URL types — that we would aim to encode a graph traversal in such a blockchain-oriented URL schema.
I have been involved in a number of conversations along these lines already, and I hope that in the near future we will start to see implementations of resource locators for blockchain data that do so. Schemes that are able to leverage the ability to traverse Metanet graphs (in addition to identity management) in order to unlock the potential of the Metanet protocol for on-chain content.
Mapping Keys to Domain Structures
As a final thought for today’s post, I want to draw your attention to the utility of domain structures in the Metanet protocol for implementing complex functionality involving hierarchical key management.
In a Metanet tree, each node (excluding multiple versions of the same node) is assigned its own key pair, denoted by P(node). As we have already detailed, the key pair associated with P(node) defines the write-access to create a subsequent child of the node.
It follows, then, that we can aim to map entire hierarchical key structures, such as those used in hierarchical deterministic (HD) wallets, to to Metanet trees. We can picture something like the following:
Although it is not essential to employ such a key-management technique when using the Metanet, it does produce significant benefits for a multitude of different use cases.
For example, it becomes possible to delegate the creation of new nodes in a particular branch to somebody — effectively allowing for the outsourcing of content creation. The same mechanism can also be used to assure the control hierarchy for a particular organisation, where each individual member becomes responsible for their own key pairs.
Delegated Sub-Trees
Finally, I would like to make a very last-minute addition to today’s blog post, which is written in light of the excellent article published by Satchmo just a few hours ago.
In the post, the concept of allowing a user (Bob) to be permitted write-access to a particular sub-tree of another user’s (Alice’s) sub-tree is explained very clearly indeed. As I have alluded to above, it is a powerful concept that has always existed as a native aspect of the Metanet protocol, which I personally like to call ‘delegated sub-trees.’ In short, the principle is that a user such as Alice wants to give, sell, or delegate the write-access to a particular branch or sub-tree, which is a part of her own Metanet graph structure.
The use cases for doing so are myriad, but some simple examples would include a website where each page is outsourced to a particular content creator, and has even been used by Rate-SV already. I hinted at such a feature of the Metanet protocol during my talk at the CoinGeek Toronto conference, where I suggested such delegation could be used to implement a social media Metanet graph.
In the diagram above, we can see that this example implementation, for a blockchain-based social media platform like Twetch, uses a linear chain of Metanet nodes for user interactions. The key point I want to highlight here, though, is that each linear feed of transactions is actually a delegated sub-tree within the larger social media graph.
The delegation occurs at the top of each sub-tree, where the social media provider delegates the write-access to each user — by means of the user’s master key — in an account-creation transaction. We will explore such ideas in a little more detail in future posts.
Stay tuned for the next instalment, where we’ll look at how the Metanet protocol intertwines with the myriad other protocols that we have seen being developed for on-chain data handling on Bitcoin SV.
Resources
The following resources will be useful as supporting material for this series in general:
- Metanet Protocol (Technical Summary).
- _unwriter’s explanation of the Metanet.
- Metanet slides from CoinGeek Toronto (2019).
- The Genesis Metanet tree: graph, thread.
- The MetaWriter tool: github, thread.
- Metanet planaria.
This week I must also direct you to a wonderful article, written by Satchmo:
Copyright
© 2019 nChain Limited. All rights reserved. This article is provided without any warranties whatsoever and shall not result in the grant of any license, whether implied or otherwise. nChain Limited shall not be liable in any way for the use of the information provided herein.
