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.
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
A generator miner (leader) is selected to propose a block.
Replicas verify the block and generate signed verification tickets.
If a block receives 2/3+ approvals, it is notarized.
Miners broadcast the notarized block to sharders, who store it permanently.
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:
Liveness: The blockchain continuously progresses, generating new blocks in a sequential manner.
Safety: Every honest node eventually reaches the same correct state.
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
In round r, at least one block is notarized.
If all notarized blocks extend the same block B(r-2), that block becomes finalized.
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.
Last updated