Zines

zNS: Identity and Property in the Metaverse

If Bitcoin is virtual currency and Ethereum is virtual law; zNS is virtual property. zNS (Zero Name Service) is Zero's primary protocol for managing the scarce allocation of unique digital property within the Zero Network. A zNS namespace can represent virtually anything – such as a username on a social network, a digital wallet address, a device's IP address, or a parcel of virtual land inside the Metaverse.

Starting in May 2021, the public will be able to purchase unique zNS addresses. The purpose of this Zine is to give a brief overview of the core problems that zNS solves for distributed networks in general. In subsequent Zine's we'll look at different ways of potentially valuing zNS namespace as well as things like virtual property in the Metaverse.

(For more specifics on zNS, please check out the original Zero Whitepaper, zNS docs, Zero Improvement Proposal (ZIP) 001, and/or public Github repo).

Your ZNA

Your zNA (Zero Name Address) is a human readable address.

Similar to 'http://', your zNA is preceded with the Zero protocol notation '0://'. It is simultaneously a unique web address, username, digital wallet and cryptographic mechanism for verifying that you are actually you. It can be used for authentication (such as a simple login system for a dApp), or it can be used to represent actual value on the blockchain via a 1-of-1 NFT. You can easily trade it or resell it; and it is completely scarce and unique – just like you.

We'll organize this Zine around the two principle benefits zNS provides:

Unique Identity: This is defined as a unique entity that is located at a fixed point within the Zero Network. An entity can represent any type of arbitrary data and includes a cryptographic signature that can only be verified by its owner. Entities can represent an actual person's identity (i.e., '0://wilder.frank') or any type of data – such as an Ethereum contract, an IPFS hash, or a virtual asset. Similar to a domain name like 'www.wilderworld.com', the owner of a zNA can choose how it is programmed and what it resolves (links) to.
Global Human Readability: This makes it easy for humans to get to your content. Instead of using cryptographic hashes to address content (like '0x0...'), you can use a human readable domain (like a web address) to access any data on any type of decentralized or distributed network. Domains can also have children that are structured within a hierarchical and recursive data system. For example, the zNA '0://wilder.fashion.hats' could point to an index of virtual hat NFTs, which could then ranked by market capitalization or daily trading volume.

1. The Problem of Unique Identity

There are three current problems with online identity as it relates to centralized internet platforms.

First, current platforms do not enable users to have sovereign ownership over their online identities. Even if you spend tens of thousands of hours building content, fans, and economic value at 'instagram.com/frank.wilder', you do not and really cannot own your handle on Instagram's servers. You have merely been granted temporary access to it, according to certain terms and conditions that were determined in the sole discretion of the platform. Irrespective of how much value you create for yourself and the platform at large, you have no real control over the ways in which you generally identify yourself online.

Second, even if Twitter was willing to sell your handle to you, centralized architectures provide no guarantees that an attacker couldn't (potentially quite easily) steal your identity. This happened to Twitter last year, where the accounts of top government officials, celebrities, and entrepreneurs (including Obama and Elon Musk) were taken over and used to facilitate crypto scams [1]. In the wrong hands, these vulnerabilities could have lead to significant geopolitical risk.

Third, assuming you were able to solve problems one and two, the architecture of centralized platforms are highly inflexible in their application and use. For instance, your Instagram handle will always point to your Instagram page. The same is true for all centralized platforms other than perhaps domain providers. If you are to truly own an identity that is unique, as the owner you should be able to decide where and how that identity is utilized and/or expressed. Perhaps you want your identity to point to your personal blog, or Ethereum wallet, or Polkadot dApp, or LinkedIn page. Traditional platforms are ridged in how data is structured, stored, and interpreted. You, not the service, should determine how your digital identity is expressed.

1.1 Asymmetric Incentives Between Users and Platforms

In addition to issues of unique identity, centralized platforms tend to make money using extractive mechanisms: i.e., advertising, paywalls, commissions and/or the sale of private data [2]. Fake news, mental health, and election interference are some of the threats posed by the underlying design of centralized platforms as they exist currently [3]. These incentive models are antithetical to the essence of decentralized systems, which aim to restore the individual ownership of user data and align incentives between platform stakeholders. We can refer to these models broadly as 'rent seeking'.

Early decentralized protocols, such as Bitcoin and Ethereum, capture value for stakeholders by requiring the use of a native token to pay for the operational costs of running the network in the form of fees. In Proof-of-Work systems (like Bitcoin) this is the real cost of electricity and computation. In Proof-of-Stake systems (like Ethereum 2.0) this becomes the time/value of risk capital. These models are elegant and defensible. As system usage increases, market token demand increases, and the value of the network increases. We can refer to these systems as using a 'resource' token model. What users are effectively paying for is the cost of procuring and coordinating the underlying resources required to operate the network.

As we move up the stack – from decentralized blockchains to protocols and applications – it remains to be seen if the resource model makes sense. The common argument against using a resource token for a dApp is: "why introduce the friction point of an additional payment token when a service can be paid for in BTC, ETH or USDC?". Resource models work when there is an intrinsic underlying cost or resource required in order to deliver a digital service. These models become redundant and indefensible if token models do not add additional real world value to the user and network. When there is no intrinsic reason for the token to exist, these token models become rent-seeking rather than resource-based. Specifically, this highlights a very real threat to the world of open-source software. In order to appropriately value (and adequately fund) the code required to build a new generation of decentralized applications – including social networks, marketplaces and productivity tools – we will need to find a token model that intrinsically works for network protocols and dApps. A model where creators no longer have to work for institutions; but rather, can begin to work for smart contracts on open networks.

1.2 The Property Model

zNS uses what we refer to as the 'property model'. It establishes a better way to ensure protocols, dApps and open-source software can adequately be funded. It achieves this through the sale of scarce virtual property and is based on the principle that value wants to flow to that which is first useful, and then scarce.

To understand the property model relative to the resource model, let's compare the usefulness and scarcity of Bitcoin compared to zNS:

The usefulness of Bitcoin is the ability to provide a sovereign digital and monetary hedge against the fiat monetary system. Its scarcity is driven by deflationary tokenomics that are enabled by the real cost and coordination of energy and compute power.
The usefulness of zNS is the ability to easily access a location (address) on the blockchain with a unique and human readable name (like a web url). The scarcity of zNS is the limited number of unique character combinations in the human language (and therefore, a zNA domain).

Similar to the halving system used in Bitcoin, human readable namespace has a natural deflationary mechanism (in orthogonal space). As names become longer and more complicated, they become less human readable, and therefore less useful and valuable. From this perspective, property in digital networks are akin to property in the physical economy, albeit at a higher level of abstraction. A fundamental resource of an information network is its traversable property. Traversable here indicating the degree to which one can easily get to a certain network location. The property model is a natural and intrinsic mechanism for capturing network value on decentralized and distributed networks that does not require the need to impose artificial payment tokens.

2. The Problem of 'Global Human Readability' in Distributed Networks

Distributed network architectures make creating human-readable namespace quite difficult. Unlike decentralized networks, which maintain consensus of global system state, distributed networks (at least currently) have no means of achieving this. In order to create human-readable names, something like a global state is required to ensure certain namespaces can be allocated to certain operators. Global state in a distributed network would require one or more nodes on the network (and ideally every node) to know the entire current state of the network for a specific moment in time. Latency between machines alone makes this an implausibility. Time is also relative; therefore, it is unlikely that this constraint can or ever will be different for this network topology.

In fully distributed networks this introduces the challenge of reliably maintaining the allocation of 'scare and unique' resource space in a global network. For example, if two nodes on different sides of the world try to both register the username '0://wilder.frank' at close to the same time, how is the decision made for who is to receive the domain? Once a domain gets registered by one user, how does it not become immediately registered by another? Human readable namespace is atomic and unique, meaning that every namespace is effectively 'one of one'. If it becomes anything less than one (i.e. is divided), it is no longer one – it is something different. Both centralized and decentralized architectures do not have the problem in terms of managing and issuing global human readable namespace; they both execute transactions linearly into a shared database from a single reference of time.

Distributed networks generally use random hash generators to ensure that network IDs are unique in order to prevent data collisions. This solves the problem of data uniqueness on the network, but does not solve the problem of human readability. This is why user ids and wallet addresses on distributed networks tend to look like 'fb378743b681f8d05e2febd362d2aee2560422' and not '@real_n3o'. zNS solves this problem by utilizing the Ethereum blockchain (as well as a network of blockchains and layer2 solutions) to maintain a hierarchical set of namespaces (ZNAs), each of which can reference virtually any type of metadata on any type of chain or distributed network. This enables data on distributed networks to be mapped to unique and human readable addresses on other decentralized and distributed networks, merging the useful aspects of decentralized and distributed architectures into a higher order pattern that we call a 'metachain'. Another way to think of this is as 'a new Internet'; one made up of structurally different relationships than the current Internet. An Internet that is made up of the structural relationships between nodes on decentralized and distributed networks, not DNS.

Conclusion

zNS is responsible for the allocation of the scarce resource of 'human-readable' namespace, which is capable of addressing content that, from an architectural standpoint, can not itself have a native human readable name (i.e., any truly distributed protocol). Beyond Layer1 blockchains, we believe that the zNS property model is a better way for decentralized and distributed protocols to monetize their networks and provide funding to continue the growth of their projects.

In subsequent Zines, we will look at different valuation models for zNS namespace as compared to traditional token models, as well as the types of unique property that will soon emerge on zNS – including unique creators, communities, dApps, and my personal favorite, fully virtual real estate inside the Metaverse.

To Infinity & Beyond,

n3o