# Blockchain & Consensus 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.

Fig1: Züs Consensus Protocol

#### **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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.zus.network/zus-docs/system-overview/blockchain.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.