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