Zines

Introducing the next-generation of Zero OS — v2

As Zero becomes increasingly distributed we will begin to share more designs to solicit community feedback. The objective of this document is to communicate the principles and requirements behind Zero v2. We welcome any thoughts or ideas for how we can improve this process as well as the architecture of Zero v2.

1. Background

The notion 'Zero' is represented by a number of applications and protocols, including but not limited to Zero OS, zAuction, zDAO, zFi, zBanc, zSpace, zOWS and zChain. These systems can be collectively referred to as Zero 'subsystems'. If you're unfamiliar with these terms it may be worth reviewing the docs on Zero Knowledge, the Zero Technical Trailer or Zero Whitepaper. Our objective has and continues to be to integrate these systems into a single and cohesive experience, while preserving the ability for each subsystem to operate as its own standalone service. When working with distributed systems in general, it is often the case that parts of the system should be well isolated with clearly defined inputs and outputs. This enables subsystems as well as the teams building them to operate in parallel, increasing throughput and isolating potential points of failure.

The long-term vision of Zero is to ensure that Zero as a whole becomes fully decentralized and distributed. Similar to Bitcoin, the objective is that everyday Internet platforms can become part of a public commons that transcends the need for intermediary institutions – for companies to become networks. One of the central problems of blockchains and distributed systems at the present time is their inability to scale. For instance, Ethereum can still only process ~15 transactions per second at the time of this writing. Many other blockchains aim to solve this problem, but generally do so at the expense of security or decentralization (i.e., the blockchain trilemma). P2P systems like IPFS, Arweave, Urbit and Holochain have their own limitations, partly driven by the necessity of hosting data on your own device, which introduces local storage, bandwidth, and end-user security concerns (such as having your private keys lost, stolen or destroyed). Then there is the speed of data propagation within p2p networks as well as a whole host of attack vectors (DDoS, etc.). Many projects will tout their wares as having solved these fundamental challenges, but the reality remains that no one has quite figured out how to build scalable dApps or platforms that rival that of Facebook, YouTube, and WhatsApp. No one has even really figured out how to build a simple and scalable distributed chat app that works well. Token market caps would have you believe otherwise, but this remains a basic truth.

Zero's approach to date has been to build a better collaborative experience for distributed communities from the human perspective backwards. While many aspects of Zero's core architecture are blockchain-centric, we are not blockchain maximalists or really maximalist about anything; we will use the best tools available to achieve the best outcome. Right now, we believe that the next generation of networks will be based on the integration and interoperability of all prior widespread network typologies. This will be the only way to achieve usability, speed, security and decentralization.

2. Network Topologies

Before we dive into data classification in Zero v2, we need to align on a shared definition of the various network topologies that are used within the v2 stack. Zero v2 will be made up of three primary network structures:

A centralized network means that a single entity (such as a corporation or group of users) hold control over a specific aspect of application state and/or architecture. This means that in theory this group could change a member's state or how an application/service handles data without the explicit consent of its members.
A decentralized network means that no single entity can impact a member's application state, other than the application states rightful cryptographic owner. I.e., there can be no service, platform, hosting provider, and/or organization (corporation, LLC, government entity, or otherwise) who has greater authority than the rightful owner of a specific portion of application state, at any location within the application and network stack. This objective can be achieved by deploying code on blockchains that are extremely difficult to 51% attack and immune to collusion schemes (i.e., Ethereum, Bitcoin, Cardano, Polkadot, but not EOS, Tron, Solana, etc.).
A distributed network builds on the features of a decentralized network with two added benefits: 1) it does not require global consensus between all nodes in order to create new ledger transactions, and 2) it has the ability to interact and manipulate application state directly and locally (i.e., without an Internet connection). This largely solves the scalability problem (including GAS fees) that exist currently within purely decentralized networks.

3. Data Classification

Data classification in Zero can be evaluated across three primary axes of importance: security, accessibility, and sovereignty:

Security: How easy is it to hack an individual user's account or steal their credentials? How easy is it to change application state by anyone other than its rightful owner (including service provides)? How easy is it to take down or significantly impair the network?
Accessibility: How easy is it to get access to your data? Can you easily access it from multiple locations and devices? How quick is the end-member experience of reading, writing and propagating data to other members on the network? What if the Internet goes down, partially or fully?
Sovereignty: How do you know that you own your data (and that only you own your data)? Do you have the right to sell your data? Can anyone else take your data away without your explicit consent? How much flexibility do you have to do what you wish with data you own?

Data classification in Zero is determined by the degree to which these vectors are honored.

3.1 First Class Data

First Class data represents the practical maximum level of security, accessibility, and sovereignty of data within Zero. Specifically:

Security:

Best-in-class encryption must be utilized for the storage, retrieval and transmission of all system and member data (i.e., AES-256 encryption).
Data must only be accessible and modifiable by its owner, providing they have the appropriate provable credentials (i.e., proper private keys).
Members must be able to securely replicate and store private keys outside of a single device, without compromising the security of the private keys.
User identifiable data must not be cached or permanently stored on remote services (i.e., cloud services, third-party computers/networks).

Accessibility:

Data must be accessible online as well as offline, or via any type of local area network (i.e., a sneakernet). In other words, this has to work in deep space, and elegantly synchronize state when it returns to Earth.
Reading, writing or modifying data should not cost money (i.e., members cannot incur GAS fees to write their own data under any circumstances).
Standard application functions must operate with a high degree of speed and with minimal latency (<10 ms). It is important that an individual can access/retrieve data and interact with it within a reasonable timeframe (i.e., seconds not minutes, hours, or years). If the system is slow relative to existing Internet services, people are not likely to use it.

Sovereignty:

It cannot be possible under any circumstances for a higher-level operator in the network or technical stack, such as a hosting provider or ISP, to take away ownership of any portion of a member's data/state, without their explicit consent (i.e., digital signature).
A local (your private key on your local device) and global mechanism (network consensus) is required to ensure that a particular aspect of data is in fact sovereign — i.e., provably owned by a certain member or group.
This does not just include an individual member being able to access data that is their own, but includes the capacity for anyone on the network to prove that a particular aspect of state is owned by a specific member.
Data ownership must be able to be transferred from one member to another (or agent) without the risk of a double spend. Two or more individuals/groups can never be able to own the same aspect of state under any circumstances.

Primary examples of First Class data in Zero are:

Auth: Authentication and login; this must be verified with a private key held on a trusted device.
Communication: Conversations, such as general channel discussions, direct messages and contextual discussions (such as in specific feed posts, notes and tasks).
Settings: Individual member and/or local device settings (i.e., theme settings, account settings, system preferences, etc.).

3.2 Second Class Data

Second Class data represents a lower relative level of security, accessibility, and sovereignty of data within Zero, based on the primary axes outlined above. It is less strict than First Class data:

Security:

Same as First Class data.

Accessibility:

Same as first class data with two exceptions: 1) access does not need to be available offline, and 2) GAS fees are appropriate to create transactions that modify application state.

Sovereignty:

Same as first class data.

Primary examples of Second Class data are:

Global Identity:

A member's 'global' identity, handle/url (such as '0://wilder.frank'), and associated profile must be actually owned and controlled by the individual and not the service/platform (i.e. Zero and/or associated Zero organizations). Global is salient here due to the fact that identity as a concept does not necessarily always need to be 'global'; i.e., have consensus among everyone.
No private keys or identifiable member data related to an individual can be held in centralized locations under any circumstances (such as Amazon servers, third-party cloud systems, etc.).
It is important that this level of security does not render Zero unusable or impractical. For instance, like with many modern Internet applications, a member must be able to cache their login sessions, such that they do not need to explicitly login every single time they open an application or web browser. Financial, governance, and potentially irreversible transactions however, must always require the explicit signing from a members private key.

Network Routing & Authority:

Similar to individual identity, network namespace ownership on Zero must be owned and controlled by the holder of the private key of the Network namespace (i.e. '0://wilder').
Routing between Networks must happen according to the structure of the zNS protocol. An individual should not be able to create or navigate to a Network / namespace that is created outside of the zNS namespace typology, unless they are directly visiting content hosted on a third-party network (such as the Internet, IPFS, Ethereum, etc.).

Money & Currency Transactions:

This refers to any type of monetary transaction in Zero as well as the application state of a particular token/currency (i.e., a ledger of historical transactions).
Dynamic Tokens in Zero are tokens issued on a bonding curve that utilize a Dynamic Reserve. These are generally used for Network Tokens but can also be attached to zNS namespaces. Fixed supply tokens have a fixed-token supply, and are generally used as governance tokens in DAOs.
All transactions that change the state of a Dynamic or Fixed-supply token must happen according to the requirements of Second Class data.

Governance:

This refers to any type of voting process that is required in order to change the state or ownership of a contract's state, such as assets held by a DAO (Decentralized Autonomous Organization).
The process of voting itself must be fully decentralized and have no single point of failure or capture, outside of the internal logic of the DAO systems own smart contracts.

3.3 Third Class Data

Third class data represents data that has the relative lowest requirement for the security, accessibility, and sovereignty of data within Zero:

Security:

Same as first class data, with the exception that private keys can be stored on centralized servers, in the event it is absolutely necessary.

Accessibility:

Same as second class data.

Sovereignty:

Does not require data to be sovereign. Data can be stored on centralized servers that is accessible with a permission system only (i.e., a provable mechanism of sovereign ownership is not required). For this reason it is generally recommended that Third Class data is either simply not important/sensitive or completely stateless (i.e., any state is temporary and/or able to be cross-referenced/derived deterministically from First or Second Class data).

Primary examples of Third Class data are:

Game state; such as the individual geocoordinates of players and objects within a particular virtual world. This could in theory be hosted by a centralized cloud system, so long as the system has checksums that are continually verified from the state of First and Second Class data. For example, a proof mechanism could be utilized to ensure that the game engine binaries hosted on a central server have not been tampered with. This could be achieved using a round robin mechanism that requests nodes to provide accurate binary hashes on a set or random interval, similar to the 'Proof of Spacetime' algorithms used by Filecoin and Chia. So long as these servers manage mostly ephemeral and non-critical state, there are limited concern with making the data Third Class. This is slightly different than Filecoin in that what is being verified here is not that a file is being stored correctly, but that an application binary is 'running' correctly.
The same can be said about a number of application types, from video hosting and live streaming to instant messaging.

3.4 Data Classification Matrix

The following table illustrates a summary using a scale of one to three; with three representing the maximum degree of importance along a particular classification vector, and with one representing the least.

4. Application Levels

Zero v2 is made up of three primary 'Application Levels'. Application Levels are not analogous to Data Classification; instead they represent the degree to which data is public and/or private along a spectrum.

Level 1: Represents data that is encrypted and private; the most private type of data within the Zero stack. It requires authentication with a private key; the owner can determine the trust of other machines that can store particular aspects of state.
Level 2: Represents data that requires credentials, such as a username and password or a private key, to access certain aspects of application state (such as a private Zero Network).
Level 3: Represents data that is 100% Public. This data can exist on a blockchain like Ethereum of p2p network like IPFS or zChain. This represents the public facing version of Zero and any public data that is chosen to be exposed by an individual network.

Everyone knows about Level 3 data and has access to it but cannot necessarily modify it. Everyone knows that Level 2 data exists, but does not know what the data entails unless they have the proper access verification. Level 1 data can only be known to exist by explicitly declared trusted machines on the network. This process can be done manually or via trust algorithms.

5. Graceful Degradation

The principle of graceful degradation in this context refers to Zero's ability to gracefully add or remove functionality and data access as it becomes available (or unavailable) under different conditions. If a particular subsystem fails or becomes inaccessible for whatever reason, the entire system should not fail. This could be for any variety of reasons; a system could become corrupted, have a bug or become compromised; the Internet could go down, traffic on a network subsystem could become congested, etc. To the degree possible, Zero must strive to make data as available as possible under these circumstances, and move as elegantly as possible between changes in the external or internal environment. This of course will not be possible for all types of data and/or transactions, but should be deeply considered when designing any subsystem or designing/testing any use case.

6. Repository Structures

From an Architecture perspective it is important that there is both horizontal and vertical separation of concerns within the Zero stack:

Horizontal separation refers to the logical separation of Zero services (i.e., protocols and applications that can be used by developers or end-users as their own independent systems). For instance, it is important that systems can operate and be worked on independent from one another, and continue to function in the face of significant code or architecture changes, so long as systems do not break their own external facing API. This must be true for all protocols (i.e., zNS, zAuction, etc.) as well as Zero applications (i.e., Chat, Tasks, Market, Choices, etc.).
Vertical separation refers to the logical separation of types of code/logic that exist at different levels of a particular application and/or protocol. For instance, front-end code (JavaScript, HTML, etc.) must be sufficiently decoupled from front-end state, application logic and protocol logic, such that teams can work on these systems independently and in a way that is maximally distributed. At a minimum, protocol code (Solidity code on Ethereum for instance), must be sufficiently decoupled from a protocols Subgraph code, as well as provide a separate protocol SDK that enables a front-end to easily access a protocol's core methods, without needing to understand how it functions under the hood.

Other non-negotiables:

Horizontal and vertical slices within the Zero stack must exist as their own code repositories, as well as provide very simple, clear, and accurate documentation as to their intended use.
Every repository must provide as close to 100% functional and automated test coverage (as is practically possible of course).
Merges should never happen into repositories directly. They should always go through a peer-review process according to the policies of that individual team, and pass all automated tests before being deployed to a staging environment for further testing.

7. Initial Applications – Enter Wilder

The highest priority application for Zero will be the success of the Wilder community, Zero's first official Universe. In order for Zero to succeed, Wilder must succeed. Therefore, it makes sense to prioritize what it is Wilder needs in order to have a successful product launch and scale. Wilder's initial value proposition is a Decentralized Artist Guild that solves three problems relative to existing NFT marketplaces and virtual worlds: 1) Liquidity, 2) Decentralization, and 3) Providing utility via useable and photorealistic 3D game ready assets. More specifics on the exact benefits of Wilder World are outlined in this recent Zine.

Wilder is a natural starting place to attract members to the Wilder Artist Guild, liquid NFT marketplace, and Zero. Given the decentralized and distributed nature of Wilder, it is an ideal community for prototyping a new way to collaborate that is directly aligned with the goals of Zero. For this reason, we will sequence the rollout of Zero v2 in four stages for Wilder:

7.1/ Wilder World Liquid NFT Marketplace (using zNS):

Core Principles:

The entire application of Wilder must consist entirely of Second Class data (i.e., it must function as a proper dApp).
It must be able to be hosted at it's own web address ('app.wilderworld.com'), as well as be publicly accessible from within the Wilder Universe ('0://Wilder') on Zero OS.
Authentication will be managed solely by connecting a valid Ethereum Wallet (e.g., Metamask). In order for a member to have an account on the Zero Network they must register a valid zNA (Zero Name Address) via zNS.

Core Functionality:

The Marketplace must implement the primary requirements of Wilder, including but not limited to;
The ability to mint domains (i.e., NFTs) inside the Wilder namespace ('0://Wilder').
The ability to buy and sell domains (via zAuction).
The ability to mint, link and buy/sell Dynamic Tokens in a specific domain.

Integrated DEX (Decentralized Exchange):

Wilder must provide the ability to buy/sell both $WILD token (created using zToken) and the $LOOT token (a Zero Dynamic Token / Network Token), publicly on the Wilder World website and app.
Additionally, members must be able to easily purchase Wilder related tokens directly within the Wilder Universe on Zero, as well as be able to easily retrieve historical prices on a traversable graph.

7.2/ Wilder Artist DAO (using zDAO):

Core Principles:

Same as defined in the prior architecture section.
This must operate as a secondary application within the deployed Wilder app, which is easy to switch between.

Core Functionality:

Holders of $WILD must be able to create proposals for transactions on behalf of the DAO, as well as vote on them in a way that is maximally gas efficient.
Members must be able to propose the creation of 'sub-daos' that have their own internal governance structure.
DAOs created within the Wilder Artist DAO must require a corresponding zNA (Zero Name Address) in the Wilder domain.

Core Principles:

Same as defined in the prior architecture section.

Core Functionality

Members holding a domain within the Wilder Universe ('0://Wilder') must be able to 'follow' specific namespaces within the zNS directory tree (i.e., '0://Wilder.Frank'). Following a specific namespace will by default follow all subsequent (downstream) zNA's in the directory tree (i.e., following '0://Wilder.frank' will also follow '0://Wilder.Frank.Coronalisa', '...Frank.DeadBenji', etc.).
Members must be able to have contextual real-time discussions related to a particular post (i.e., domain/NFT creation event), in chronological order. This subsystem can initially be Third Class data, but is intended to be First Class data as soon as is humanly possible.
Members must be able to navigate to a custom configured feed of posts (like Facebook, Instagram or Twitter) that works in reverse chronological order, of domain trees they've explicitly followed.
Members must be able to 'unfollow' a particular domain anywhere in the tree. Similar to explicit 'following', explicit 'unfollowing' will unfollow every namespace in the subsequent domain tree, but not followed domains above it.
Members can only create new domains within domains that they control. Members must be able to create new posts directly from the Feed View, which will by default be the Members zNA address. Posting requires a member to control at least one zNA, of which the post can be chosen to explicitly originate from (within).

7.4/ Private Guild Integration (using Zero OS):

Core Principles:

This is the first part of the Wilder use-case that will move from being a Level 3 system to Level 2.
Data within this system is eventually intended to be a blend of First and Second class data, but can/will remain Third Class for as long as is necessary, providing proper encryption and security practices are present.

Core Functionality:

Similar to Zero v1; primary features include: direct messaging, open/public/private channels, voice/video channels, social feed, market, tasks, member management, maps, as well as network tokens, DAO management, and zNS integration.

8. Development Sequence & Next Steps

Zero v2 will be rolled out in a series of six stages. This is of course subject to change, however is based on a significant amount of R&D as well as in market testing:

8.1/ Public Launch of zNS with Wilder World v1:

Finalize the zNS, zAuction, zBanc, and zToken smart contract audits (this was successfully completed and passed on May 7th, 2021 by Consensus Diligence).
First launch of zToken with $WILD token for Polkastarter IDO (The deployment of the $WILD token took place on May 7th; the IDO is scheduled to take place on May 11, 2021).
Deploy typescript SDKs for relevant Zero protocols, which decouple protocol state management from front-end code.
Utilize zNS and Wilder World as the first example for the Zero v2 user interface components; built using Zero's new Design System. This will be unveiled in a subsequent Zine.
Deploy a new version of the zNS front-end to 'app.wilderworld.com', which includes the ability to create, transfer, and buy/sell (auction) NFTs using zNS namespaces.
Deploy the ability to link Dynamic Tokens to individual namespaces within zNS, as well as buy and sell these tokens. Include the ability to set valid Dynamic Tokens as well as set stake fees within a particular domain.
Deploy the ability to mint ERC-1155 contracts to existing ERC-721 domains, in order to support NFT editions.
Deploy L2 scaling solution with ImmutableX.

8.2/ Public Launch of zDAO with Wilder DAO (for $WILD token 'hodlers'):

Finalize core spec for zDAO (the third and hopefully last architecture for zDAO).
Finalize the core smart contracts for zDAO, in particular the Voting, Neuron, and Reputation Systems.
Complete the zDAO subgraph and Typescript SDK.
Launch an integrated version of the Zero dApp as a secondary app in Zero OS. This system has already been designed to work seamlessly with the zDAO token contracts that were audited and deployed to the Ethereum Mainnet (above).

8.3/ Public Launch of NFT powered Social Network for Wilder World:

The ability to 'follow' and 'unfollow' specific zNS name trees.
The ability to see a reverse chronological feed of zNS namespace branches you follow.
The ability to amplify messages (similar to a retweet) for zNS entries (i.e., feed posts).
The ability to easily buy creator and content Dynamic Tokens directly from the feed.

8.4/ Integration with Zero OS (vertical integration of Wilder Artist Guild):

The ability to integrate zNS routes directly into Zero OS.
The ability to seamlessly move between Application Levels.
The implementation of the revised Authentication system.

8.5/ zChain and 8.6/ zSpace:

Due to the length of this post and depth required to fully articulate the importance, usefulness, design and progress of both zChain and zSpace, we will discuss in subsequent Zines.

9. Conclusion

In this Zine we gave a sneak peak of the Zero v2 UX, as well as expressed a number of fundamental concepts behind its construction and design. We introduced the concept of transcending and including multiple known network typologies into a single and cohesive stack that enables usability, speed, security and decentralization for mainstream internet platforms. We introduced the concept of Data Classification Vectors across three primary axes of importance: security, accessibility, and sovereignty. We introduced the concepts of Application Levels, each of which represent different levels of data privacy within Zero, as well as the use of Graceful Degradation to elegantly handle changes in Zero's internal and external environment. We discussed the importance of structuring code and teams in ways that are both vertical and horizontal, which enable the maximum amount of organizational (and data) throughput and resilience when building distributed systems. We discussed Zero's initial focus and core use-cases, and how Wilder in particular will play a crucial role in achieving our long-term objectives.

With the launch of the Wilder IDO ($WILD) happening in less than 48 hours, I could not be more excited and honored to release this Zine; outlining our immediate and long-term objectives as we embark on this wild adventure.

Thank you to all the Wilders that have made this possible. We honor and salute you.

From Zero to Infinity,

n3o

Introducing the next-generation of Zero OS — v2

1. Background

2. Network Topologies