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 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:
- Nodes are transactions;
- Edges are created by signatures;
- Each node is uniquely defined by the pair (P(node), TxID(node)); and
- 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.
A hierarchical Metanet graph structure created by BitMesh.
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 edgeis also defined between the two nodes, as shown by the blue arrow:
A Metanet-valid edge, created between Metanet-valid nodes.
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:
An Metanet-invalid edge.
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.
Learn more about the Metanet, and read the full post and the rest of the series on the nChain Medium account here.