System

A High-level look into the Züs System

Züs is a blockchain-based, decentralized storage system designed to offer high performance, security, and data integrity through a combination of blockchain validation and storage decentralization.

Unlike traditional decentralized storage solutions, Züs is structured as a Blockchain-Observed Storage System (BOSS), ensuring data correctness, availability, and incentivization through an integrated architecture that includes miners, sharders, blobbers, and validators.

The system consists of two primary subsystems that work in tandem:

• The Blockchain Subsystem – Manages transactions, data integrity, and consensus through miners and sharders.

• The Storage Subsystem – Ensures the reliability and availability of stored data via blobbers and validators.

Beyond these core components, the system incorporates various supporting nodes and services to facilitate integration with external applications, APIs, and tokenized incentives.

A Diagram of the High-Level Architecture of the Züs System that makes all the features possible.

1. Blockchain Subsystem

The Blockchain Subsystem is the backbone of the Züs network, responsible for ensuring data integrity, security, and decentralized validation. It records transactions, manages consensus, and enables smart contract execution.

The key responsibilites include:

• Block Generation & Validation: Ensures that transactions are processed securely and stored immutably.

• Data Model Management: Maintains the structure of transactions and their impact on the network.

• Storage Observation & Incentivization: Oversees the Storage Subsystem and distributes rewards based on performance.

Node Types:

• Miners:

  • Generate, validate, and notarize blocks in the blockchain.

  • Implement consensus algorithms to ensure data integrity.

  • Active miners participating in block production are referred to as the Active Set.

• Sharders:

  • Store finalized blocks and maintain the data model of the blockchain.

  • Provide historical access to the blockchain's state.

By separating block generation and storage, Züs enables high scalability and efficiency, reducing transaction processing delays while maintaining high security.

2. Storage Subsystem

The Storage Subsystem manages decentralized data storage, ensuring continuous availability and correctness of user data. Unlike traditional blockchain-based storage solutions, Züs separates storage providers from transaction validators, allowing for improved scalability and enhanced security.

The key responsibilites include:

• Data Storage & Management: Provides reliable decentralized storage for users' data.

• Challenge-Based Validation: Ensures blobbers provide accurate and untampered storage.

• Incentivization Model: Rewards storage providers for uptime and penalizes errors.

Node Types:

• Blobbers:

  • Store user-uploaded data on their local file systems.

  • Organize files into an accessible storage structure.

  • Provide APIs for interacting with stored files.

• Validators:

  • Verify blobbers' claims of stored data by conducting challenges issued by the network.

  • Provide digital signatures to confirm correct storage, allowing blobbers to earn rewards.

The separation between blockchain operations and storage operations enables the system to function efficiently and securely.

The Blockchain Subsystem observes and validates the Storage Subsystem without interfering with storage operations, reducing overhead and improving scalability.

Supporting Nodes and Helper Systems

The core blockchain and storage systems are supported by additional nodes that provide network services, authentication, and external integrations.

The Blockchain Network

This is the set of nodes that cooperate to generate and persist blocks of the blockchain. It consists of Miners and Sharders, which both will be explained in more deeper details in the next sections.

DNS Resolver (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. This node is responsible for keeping a directory index for the addresses of the miners/sharders based on the Magic Block.

Blobbers

Those are the nodes responsible for storing users' data.

Validators

Those are the nodes responsible for validating the correction of blobbers' claims about the data they store, as part of the Challenge Flow, explained further on.

Authorizers

Those are the nodes responsible for authorizing Burn Events, which compensates for the minted ZCN tokens in the Züs Network or the ERC-20 WZCN tokens in the Ethereum Network. This is the core node of the Bridge Protocol, which is how the DEX (Decentralized Exchange) flow between Züs Network and the Ethereum Network happens.

ZCN DEX Smart Contracts

Those are the smart contracts deployed on the EVM enabling the Bridge Protocol between the Züs Network and the Ethereum Network.

0Box

This is the Explorer Node of the network. It provides endpoints to explore the data of the network and its change over time. It also does a crucial task in users' profile management and some functionality provided by the Webapps.

Event Message Queue

This is a messge queue node to persist and provide the events published by the network. Those events represents change of date in the network.

Clients

This is a general term used for all the consumers of the APIs of all the system nodes. Those include:

• Lower level clients

  • SDKs

• Higher level clients

  • CLIs

  • Webapps

  • Mobile apps

ZS3 Server

An 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.

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:

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.

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

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.

SDKs, APIs, and CLIs

Züs SDKs

To support creating awesome applications on top our robust system, we offer SDK support for all the major platforms:

• General Purpose SDK in Go.

• JS on the browser (and other supported platforms) using WASM.

• Android Native.

• iOS Native.

• macOS.

• Windows.

Plug in our SDK and start building awesome applications and gaining rewards! Check the documentation of our SDKs here.

Züs APIs

We also offer HTTP APIs to extend our support beyond the platforms supported by our SDKs, with enhanced security using your wallet public/private keys. Our APIs provide major functionality, including but not limited to:

• Viewing data about nodes/services/addresses.

• Issuing transactions to our Smart Contracts.

• Interacting with the files (upload/download/move/...)

• Managing your resources (allocations/staking/wallets/...)

Those APIs include:

• Miner/Sharder APIs: Provide endpoints to retrieve data about the blockchain progress, also to issue transactions.

• Smart Contract APIs: Provide endpoints to retrieve data about the system entities (nodes, transactions, allocations, rewards, ...).

• Blobber API: Provide endpoint to interact with your files stored on the blobbers (storage servers), including upload, download, move, etc...

• 0DNS API: Provide location information about the blockchain network nodes (Miners/Sharders).

Check the full documentation of these APIs here.

Züs CLI Tools

For a higher level no-code interaction with Züs System, we offer 2 main CLI tools:

• Wallet CLI: Interacts with the client's wallet, support staking and an interface for token swap with Ethereum-based tokens.

• Storage CLI: Interacts with the client's storage spaces (allocations) and their files.

Check the full documentation of these CLIs here.

Ecosystem Applications

Züs provides five major applications that interact with its blockchain and storage system.

1. Vult:

   • A personal secure cloud storage service.

   • Offers privacy-focused file storage with end-to-end encryption.

2. Blimp:

   • A full-featured storage management system.

   • Provides ransomware protection, blockchain-backed transparency, and user-controlled data security.

3. Chimney:

   • Allows users to monetize excess storage space.

   • Provides decentralized storage leasing for businesses and individuals.

4. Atlus:

   • A block scanner for monitoring network transactions.

   • Provides real-time blockchain analytics.

5. Bolt:

   • Enables staking and rewards based on decentralized storage contributions.

System Communication

The Züs network employs multiple communication layers to facilitate seamless interactions between its components.

Connection	Description
Blobber ↔ 0DNS	Blobber communicates with 0DNS through the 0DNS API to get the addresses of the miners/sharders.
Validator ↔ 0DNS	Validator communicates with 0DNS through the 0DNS API to get the addresses of the miners/sharders.
Blobber ↔ Network	Blobber communicates with the network through the Transaction API & Sharder API to submit transactions like challenge_response, sync its allocations, and send heartbeats.
Validator ↔ Network	Validator communicates with the network through the Transaction API & Sharder API to send heartbeats.
Blobber ↔ Validator	Blobber communicates with the validator through the Validator API to request validation of challenges and get their results. The blobber finds the validator using the validator URL assigned to the challenge by the Storage Smart Contract.
Authorizer ↔ Network	Authorizer communicates with the Network through the Transaction API to check for Burn ZCN events to mint WZCN in the Ethereum Network, as well as sending heartbeats.
Authorizer ↔ 0DNS	Authorizer communicates with 0DNS to get the addresses of the miners/sharders to be able to communicate with the Network.
Authorizer ↔ ZCN DEX Smart Contracts	Authorizer communicates with the ZCN DEX smart contracts deployed to the EVM to verify Burn WZCN Events to be able to mint ZCN in the Züs Network.
ZCN DEX Smart Contract ↔ EVM	WZCN smart contracts are deployed on the EVM (Ethereum Network) to enable the DEX (Decentralized Exchange) flow between ZCN tokens inside the Züs Network and other ERC-20 tokens in the Ethereum Network.
Network ↔ Events Message Queue	The Network communicates with the Message Queue to publish events representing mutations of data after processing transactions.
0Box ↔ 0DNS	0Box communicates with 0DNS to get the addresses of miners/sharders to be able to communicate with the network.
0Box ↔ Events Message Queue	0Box communicates with the Event Message Queue as a Subscriber for events published by the Network. 0Box reads and processes the events to get in sync with the data model at the Network, providing information to clients.
0Box ↔ Network	0Box communicates with the network to read changes in the data model of the network and submit some transactions. This should be deprecated gradually until removed in a future fork.
Clients ↔ 0DNS	Clients communicate with 0DNS to get the addresses of miners/sharders to be able to communicate with the network.
Clients ↔ Network	Clients communicate with the Network to submit transactions to the Transaction API and retrieve data from the Sharder API.
Clients ↔ Blobbers	Clients communicate with the Blobbers to perform file operations on the allocations.
Clients ↔ ZCN DEX Smart Contracts	Clients communicate with ZCN DEX Smart Contracts to submit transactions related to the DEX (Decentralized Exchange) flow.
Clients ↔ Authorizers	Clients communicate with the Authorizers to authorize ZCN mint/burn tasks within the DEX flow.
Clients ↔ 0Box	Clients communicate with 0Box through the 0Box API to get information about the network and its entities, as well as reading historical data of values tracked over time.

Züs provides a decentralized, blockchain-secured storage network with robust smart contracts, SDKs, APIs, and a thriving ecosystem of applications.

By combining blockchain validation and storage decentralization, Züs offers a scalable, secure, and efficient data management solution. In the subsections, we will dive deeper into system architecture and its components.