System Overview

A High-level look into the Züs System

Core subsystems

Züs is defined as : Blockchain-based, Decentralized Storage system. This implies the two core parts of the Züs system:

Blockchain Subsystem

The subsystem responsible for generation of the blocks and persistence of the blockchain, as well as maintenance and mutation of the data model by means of running the transactions against the smart contracts. This whole system's core purpose is to observe the storage subsystem, enabling decentralization of users' data while maintaining its correctness and high-availability by means of validation and incentivization.

This subsystem consists mainly of 2 (replicable) node types:

  1. Miners: provide block generation, validation and notarization, implements the consensus algorithms.

  2. Sharders: provide block storage and maintenance of the data model.

Miners that are currently taking part in block production are referred to as being in the Active Set. More about them in the next sections.

Storage Subsystem

Storage Subsystem: The subsystem responsible for storing and providing users' data. Nodes in this subsystem are incentivised to provide 24/7 availability and pure error-free correctness of the data the users upload by means of Reward and Penalty.

This system consists mainly of 2 (replicable) node types:

  1. Blobbers: provide storage of users' data and organize it on the file system, also provides an API to access the files and modify them.

  2. Validators: provide validation of

This segregation is a primary principle our system goes by, and a core difference of our system from the existing blockchain-based storage solutions, hence named: Blockchain-observed Storage System (BOSS). It allows both subsystem to work efficiently and securely, and provide better scalability and maintainability for both of the system.

Helper nodes and subsystems

Around these two subsystems, other nodes and helper systems are built to support the core functionality and integrate with external systems to facilitate usage of the system:

1. Node locator (0DNS)

A node used by off-chain services (any service that is not a miner or a sharder) to locate the miners and the sharders deployed on the system.

2. ZS3 Server

A Minio S3 Gateway deployment, provides a no-code s3-compatible decentralized storage server. It enables users to access their data using an S3-like object storage interface.

3. Authorizer

A node used to authorizer mints and burns related to bridge protocol, to provide decenstralized exchange of tokens between Züs native tokens (ZCN) and ERC-20 Züs tokens (WZCN). More on that in the Bridge Protocol page.

5. DEX Subgraph

A subgraph used to index the Ethereum smart contracts used in DEX flow. More about that in the Bridge Protocol page.

Smart Contracts

Smart contracts are the actual code that is executed by the transactions to perform changes on the data of the network. Any transaction that you run against the network will eventually execute a function/procedure in the smart contract, called a handler, applying the changes intended by the transactions. In Züs system, we have 3 core SCs:

1. Miner SC

A smart contract of handlers that control the network view of available Miners and Sharders, along with other operations like paying transaction fees, and collecting rewards.

2. Storage SC

A smart contracts of handlers that control the network view of the blobbers and validators, but most importantly, users' data. It contains handlers responsible for :

  • Managing users' Allocations, which are contracts of storage of some data between the client and the system (specifically blobbers).

  • Observing the validity of the data on Blobbers by generating and validating Challenges

  • Payment of storage fees to blobbers by redeeming storage read and write markers.

More on all the storage-related concepts in Storage System Features page

3. ZCN SC

A smart contract mainly used for Bridge Protocol (connection between native Züs token and ERC-20 Züs token (WZCN). It consists of handlers that controls network view of the authorizers as well as Mint and Burn functions. More on these concepts in Bridge Protocol page.

In the next pages, we'll discuss each of these parts of the systems in more details.

Last updated