☁️
Zus Docs
  • About Züs
  • System
    • Providers and Services
      • Miner
      • Sharder
      • Blobber
      • Validator
      • Authorizer
      • Node Locator (0DNS)
    • Storage
      • Architecture and Data Management
      • Protocol
        • Allocations
        • Reference Objects
        • Challenges
        • Write Markers
          • Chain Hashing
          • Two Commit
        • Blobber Repair Protocol
      • ZS3 Server
        • Backup, Recovery and Replication
        • Encryption and Compression
        • S3FS Setup and Usage
        • Backup & Recovery with Restic on Blimp + ZS3 Server
        • Backup & Recovery with Veeam on Blimp + ZS3 Server
      • File Operations
        • Upload
        • Download
        • File Sharing
        • Partial Error Recovery
        • Streaming
        • Rent a Blobber
    • Smart Contracts
      • Storage S.C.
      • Miner S.C.
      • ZCN S.C.
      • ERC-20 S.C.s
      • Bridge Protocol
    • Blockchain & Consensus
      • Entities
    • User Authentication and Wallet Management System
      • OKTA Integration
      • Key Management System (KMS)
  • APIs
    • 0DNS API
    • JS API
    • Mobile API
  • CLIs
    • Storage CLI
      • Quickstart
      • Configuring the tool
    • Wallet CLI
      • Wallet Configuration
      • Quickstart
      • Configuring the tool
  • SDKs
    • Go SDK
      • GO SDK Microservices
    • JS SDK
  • Tokenomics
    • Staking
    • Reward & Penalty
  • ✨Züs Apps
    • 🗝️Vult
      • Getting Started
        • Web
        • Mobile
      • Vult AI
        • Batch Processing
        • Memory Retention
        • Technical Implementation
        • Architecture Overview
      • Login / Register
      • File Management Pages
      • File Sharing
      • Storage Management Dashboard
      • Storage Maintenance and Troubleshooting
      • Züs Subscription
      • Wallet Management
      • Refer a friend
      • Settings
    • 🏗️Blimp
      • Getting Started
      • Login / Register
      • Configure Storage
        • Create Standard Storage Allocation
        • Create Enterprise Allocation
        • Create S3 Server Allocation
        • Create Cloud Migration Allocation
        • Allocation Maintenance and Troubleshooting
      • File Management Pages
      • File Sharing
      • Manage Allocations
      • Upgrade Storage
      • Blimp Vault
      • Refer a friend
      • Settings
      • Launching ZS3 Server
      • Using CLI to backup files into Blimp + ZS3 Server
    • 🏠Chimney
      • Getting Started
      • Login / Register
      • Create New Deployment
      • Manage Your Deployments
      • Homepage
      • Staking Dashboard
      • Rank Dashboard
      • Monitor Dashboard
      • Stats Dashboard
      • Logs Dashboard
      • Wallet Dashboard
      • Operations on your Deployments
      • Restricted Blobbers
      • Settings
        • Manage Profile
        • Wallet Settings
        • Update Blobber Settings
        • Update Blobber Version
        • Refer a friend
        • Help
    • 🌐Atlus
      • Getting Started
      • Home page
      • Service Providers Page
      • Charts Page
        • Market Charts
        • Network Charts
        • Storage Charts
      • Blockchain Page
      • Server Map Page
      • Storage Explainer Page
      • Details Pages
        • Block Details Page
        • Transaction Details Page
        • Wallet Details Page
        • Miner Details Page
        • Sharder Details Page
        • Blobber Details Page
        • Validator Details Page
        • Authorizer Details Page
        • Allocation Details Page
      • Appendix: Common Components
    • ⚡Bolt
      • Getting Started
        • Web
        • Mobile
      • Login / Register
      • Sign In with external wallet
      • Staking Dashboard
      • Staking/Unstaking a provider
      • Claiming Rewards
      • Send/Receive ZCN tokens
      • Buy ZCN
      • Deposit/Withdraw ZCN tokens
      • Activity Dashboard
      • Refer a friend
      • Settings
  • Releases
    • Hardfork
Powered by GitBook
On this page
  • Züs Consensus Protocol
  • Consensus Process
  • Consensus Guarantees
  • Threat Model and Byzantine Fault Tolerance
  • Handling Network Delays and Failures
  • Finalization of Blocks
  • Attack Vectors and Mitigation
  • Protocol Complexity and Performance
  1. System

Blockchain & Consensus

PreviousBridge ProtocolNextEntities

Last updated 1 month ago

Züs utilizes a synchronous Byzantine Fault Tolerant (BFT) consensus protocol designed for high-speed, decentralized blockchain operations.

The protocol ensures the security, scalability, and efficiency of transactions while maintaining a distributed network of miners and sharders.

This documentation outlines the key aspects of Züs' consensus mechanism, its security guarantees, and how it achieves fast finalization of transactions.

Züs Consensus Protocol

The Züs blockchain employs a Dfinity-like synchronous consensus protocol to ensure fast block production and verification. Unlike traditional Proof-of-Work (PoW) or Proof-of-Stake (PoS) models, Züs uses a multi-step process involving miners and sharders.

Key Participants

  • Miners: Responsible for block production and verification. Miners store the current state of the blockchain but not the full history.

  • Sharders: Store full blockchain history, ensuring long-term data availability. They do not participate in block validation.

  • Generators (Leaders): A subset of miners chosen to propose new blocks in each round.

  • Replicas (Verifiers): Other miners who validate the block and sign it using verification tickets.

Consensus Process

The consensus operates in rounds, where miners and sharders work together to finalize new blocks.

Rounds and Subrounds

  • A round consists of the process of producing a single block.

  • Subrounds occur if the generator fails to produce a block within the allotted time.

  • Miners notarize blocks based on the votes they receive from verifiers.

Block Production Workflow

  1. A generator miner (leader) is selected to propose a block.

  2. Replicas verify the block and generate signed verification tickets.

  3. If a block receives 2/3+ approvals, it is notarized.

  4. Miners broadcast the notarized block to sharders, who store it permanently.

  5. If a block is not notarized, a new subround starts, and the next generator takes over.

Consensus Guarantees

Züs ensures three key properties in its consensus mechanism:

  1. Liveness: The blockchain continuously progresses, generating new blocks in a sequential manner.

  2. Safety: Every honest node eventually reaches the same correct state.

  3. Finalization: Once a block is finalized, all future blocks extend this blockchain, preventing forks.

These properties ensure that once a block is validated, it becomes immutable.

Threat Model and Byzantine Fault Tolerance

Züs' consensus is stable as long as fewer than 1/3 of miners act maliciously. The protocol assumes zero-delay adversaries, meaning attackers can coordinate in real time.

Byzantine Fault Tolerance (BFT)

  • Even with adversarial actors, the system ensures that honest nodes reach the same state.

  • If a miner produces invalid blocks, the network will reject them and switch to another generator.

Synchrony Assumptions

The protocol assumes a synchronous network, meaning:

  • Every node has a bounded network delay (Δ).

  • Messages must reach all honest nodes within Δ.

  • Synchronization prevents adversaries from introducing hidden forks.

Handling Network Delays and Failures

Delayed Nodes

  • Nodes that fall behind can sync back to the network using notarization events.

  • This prevents long-term splits or chain divergence.

Optimistic Responsiveness

  • If a block is verified quickly, the network does not wait for timeouts.

  • The next round starts immediately, speeding up consensus.

This means that blocks are finalized as fast as the network latency allows, ensuring high throughput.

Finalization of Blocks

Finalization guarantees that a block and its predecessors cannot be reversed. This is achieved through the lock-commit mechanism, inspired by HotStuff and Tendermint.

Finalization Process

  1. In round r, at least one block is notarized.

  2. If all notarized blocks extend the same block B(r-2), that block becomes finalized.

  3. This prevents forks and ensures every honest node agrees on the same history.

Probabilistic Finality

Even if the above conditions are not met immediately, the next rounds will eventually converge to a single chain, ensuring eventual finalization.

Attack Vectors and Mitigation

Züs' protocol is designed to withstand various attack scenarios.

Trigger Timeout Attack

  • A malicious leader can delay rounds by equivocating (sending different blocks to different nodes).

  • Solution: Honest nodes will switch to a new leader if timeout occurs.

Delayed Finalization Attack

  • An adversary may create multiple competing blocks to delay finalization.

  • Solution: The network eventually selects the longest valid chain, resolving conflicts.

Miner Forfeit Attack

  • A malicious leader may intentionally extend a weaker block to deprive another miner of rewards.

  • Solution: Honest miners always extend the heaviest notarized block, ensuring fair rewards.

These mechanisms ensure that even under adversarial conditions, the blockchain continues to function securely and efficiently.

Protocol Complexity and Performance

Züs' consensus protocol achieves high throughput with minimal overhead.

Complexity Analysis

  • Best-case scenario: O(n²) messages at network latency speed.

  • Worst-case scenario: O(f × Δ) latency, where f is the number of faulty nodes.

This ensures that honest transactions are finalized quickly, while attacks slow down only malicious nodes.

Throughput Optimization

  • No artificial delays—blocks are notarized as soon as consensus is reached.

  • High-speed notarization allows transactions to be confirmed in milliseconds.

This makes Züs one of the fastest decentralized consensus protocols available today.

Through optimistic responsiveness and notarization-based synchronization, Züs achieves scalability and security, making it a powerful solution for decentralized applications and cloud storage systems.

The Dfinity-inspired consensus model, combined with robust failure-handling mechanisms, ensures that even under network failures or adversarial conditions, the blockchain continues progressing without forks.

Fig1: Züs Consensus Protocol