Considerations
Zero is designed to be simultaneously agent-centric, meta-consistent, self-healing, and trust-full. These are the four primary considerations that make Zero unique when compared to purely cloud-based or blockchain maximalist architectures.
First, Zero is 'agent-centric', which enables the preservation of data integrity across an unlimited number of peers (also referred to as Zero Nodes), without the need for global consensus. Given that no central server or shared ledger exists, Zero Nodes exchange information directly by connecting to peers through a gossip protocol. Zero Nodes store data in their own private and local append-only chain called a zChain. In aggregate, all zChains and Nodes in the network make up the Zero Grid. Within agent-centric architectures, each peer has its own unique (subjective) view of reality, compared to data-centric architectures such as blockchains, where peers require global consensus to maintain a shared (objective) view of reality. Zero's agent-centric (distributed) architecture enables each peer to operate its own individual zChain, which is then replicated across n nodes using eventual consistency Collectively, this architecture gives rise to the collective parallel processing capacity of the Zero Grid. Git, IPFS, SSB and Holochain are notable examples of agent-centric architectures in practice.
Second, Zero is 'meta-consistent'. zChain enables Zero to act as a central repository for credentials and data stored in existing web3 systems and protocols. Zero does not aim to compete with traditional blockchains, and is designed to integrate both agent-centric and data-centric approaches into a single application stack called the Zero Open System (or zOS for short). For instance, while financial transactions are well suited for a shared global ledger like Ethereum, global consensus is computationally inefficient for use-cases such as sending private messages between a limited number of peers. Zero's 'meta-consistent' approach enables developers to use both 'agent-centric' and 'data-centric' approaches depending on the use-case, in a way that still prioritizes speed, security and decentralization. Zero can be thought of as the ultimate abstraction layer for the web3 ecosystem, not dissimilar to how desktop operating systems once provided a novel interface for command prompts, or how the browser provided a visual way to explore the world wide web.
Third, Zero is 'self-healing', meaning that a large portion of the system can function offline, on a local area network, or sneakernet. Zero's network transport layer is agnostic, meaning that various protocols can be used to transmit data between Nodes on different types of networks. In the event of partial internet failure, short-term disconnection, or complete loss of access, Zero intelligently propagates new data entries across peers as they come online in what mimics a self-healing network.
Fourth, Zero is 'trust-full', rather than purely 'trustless', and utilizes a Members social graph to determine trusted peers to replicate information from within the Zero Grid. One of the primary inventions provided by blockchain is the enablement of transactions to occur in an entirely 'trustless' fashion. This is a good catch-all where data-centric approaches are required, however highly inefficient where 'trust' is already established and can be used as a proxy to find more efficient paths for data propagation (providing of course, that decentralization is not compromised). Trust in distributed systems is a powerful concept that can be used to significantly enhance Member experience not only at the level of data exchange, but also at the level of Member experience across a wide array of applications. Imagine if any app on your mobile device automatically knew which people and devices you already trusted, without having to add new contacts, friends, or followers each and every time a new application was downloaded. Providing Member consent, Zero applications can access a Member's 'trust-graph'. Architecturally it makes sense to have trust data at the protocol level, rather than being siloed within individual applications. This opens a range of trust-related features and capabilities for applications built on top of zOS.
Last modified 2yr ago