System Architecture
A Diagram of the High-Level Architecture of the Züs System that makes all the features possible.
Last updated
A Diagram of the High-Level Architecture of the Züs System that makes all the features possible.
Last updated
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.
This node is responsible for keeping a directory index for the addresses of the miners/sharders based on the Magic Block. All these terms will be explained in more details as we go with the documentation.
Those are the nodes responsible for storing users' data.
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.
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.
Those are the smart contracts deployed on the EVM enabling the Bridge Protocol between the Züs Network and the Ethereum Network.
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.
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.
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
Blobber communicates with the 0DNS through the 0DNS API to get the addresses of the miners/sharders.
Validator communicates with the 0DNS through the 0DNS API to get the addresses of the miners/sharders.
Blobber communicates with the network through the Transaction API & the Sharder API to submit transactions like challenge_response , sync its allocations and send heartbeats.
Validator communicates with the network through the Transaction API & the Sharder API to send heart beats.
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 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 communicates with 0DNS to get the addresses of the miners/sharders to be able to communicate with the Network.
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.
Our WZCN smart contracts are deployed on the EVM (simplty, the Ethereum Network) to enable the DEX (Decentralized Exchange) flow between ZCN tokens inside the Züs Network and other ERC-20 token in the Ethereum Network.
The Network communicates with the Message Queue to publish the events, which represent mutation of data after processing the transactions.
0Box communicates with 0DNS to get the addresses of miners/sharders to be able to communicate with the network.
0Box communicates with the Event Message Queues as a Subscriber for the events the are published by the Network. 0Box reads and processes the events to get in sync with the data model at the Network, as it will be used by the clients to get information about the Network data.
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 communicates with 0DNS to get the addresses of miners/sharders to be able to communicate with the network.
Clients communicate with the Network to submit transactions to Transaction API and read some data from the Sharder API.
Clients communicate with the Blobbers to perform file operations on the allocations.
Clients communicate with ZCN DEX Smart Contracts to submit transactions related to the DEX (Decentralized Exchange) flow.
Clients communicate with the authorizers to authorize ZCN mint/burn tasks within the DEX flow.
Clients communicate with 0Box through the 0Box API in order to get information about the network and its entities, as well as reading the historic data of the values that 0Box tracks their change over time.