QUIL’s Secret to Unlimited TPS: An Auto-Load-Balancing Sharded Structure Author: (X) @otterpal24 Date: October 23, 2025 This article provides an accessible overview of QUIL’s innovative consensus framework, designed to achieve high transaction throughput through an auto-load-balancing, sharded structure. Unlike traditional serial blockchain models, QUIL employs a spiderweb-like sharded architecture that enables near-unlimited transactions per second (TPS) while maintaining decentralization and security. This document outlines the key components of QUIL’s consensus mechanism, its load-balancing capabilities, and its approach to computational value measurement, with minimal focus on technical implementation details. For a deeper understanding, readers are encouraged to explore the source code. 1. Introduction: The name QUILIBRIUM likely derives from equilibrium, symbolizing dynamic balance and load balancing. QUIL reimagines blockchain consensus from the ground up, prioritizing high performance through automatic load balancing. This article introduces QUIL’s high-performance, sharded consensus structure and explains how it overcomes the limitations of traditional blockchain architectures. 2. The Limitations of Traditional Blockchain Structures 2.1 Serial Consensus Model. Most blockchain networks rely on a serial consensus model based on the longest chain: Block 1 → Block 2 → Block 3 → Block 4 →... This structure limits scalability because only one block is produced at a time. During periods of high transaction volume, transactions congest within a single block, creating bottlenecks. From a cloud computing perspective, this is akin to routing all traffic through a single server, which is inherently unscalable. 2.2 Existing Solutions and Their Shortcomings To address scalability, blockchain projects have explored several approaches: - Sacrificing Decentralization: Centralizing block production to a few high-performance servers (e.g., Solana). - Increasing Block Capacity: Expanding block size to accommodate more transactions, though blocks cannot scale infinitely. - Layer 2 (L2) Solutions: Offloading transactions to secondary layers, which still rely on a limited number of nodes. - Parallel Transaction Processing: Allowing non interdependent transactions to run independently (e.g., SUI/Aptos), but ultimately requiring submission to a single block. These solutions often compromise decentralization by requiring high-performance nodes controlled by project foundations, limiting the openness of the network. QUIL addresses these challenges with a fundamentally different approach. 3. QUIL’s Spiderweb-Sharded Structure 3.1 Overview QUIL abandons the linear serial consensus model in favor of a spiderweb-like sharded structure. Each “grid” in this web represents a shard, and each shard operates with its own consensus engine. This design eliminates the concept of a traditional block, enabling parallel transaction processing across countless shards. 3.2 Two-Layer Consensus QUIL’s consensus is divided into two layers: - Globe Shards Consensus: Responsible for state validation, confirmation, and synchronization across the entire network. Limited to 256 globe shards,these ensure global security and finality. - App Shards Consensus: Handles validation, storage, and transaction processing within individual shards. App shards submit validation results to globe shards for global confirmation. - Shard Structure and Growth • Globe Shards: The innermost layer, limited to 256 shards, forms the back-bone of the network. Each globe shard contains a linear structure called a frame, which aggregates proofs and digests from parallel shards to ensure global consensus. • Core Shards: Each globe shard oversees 65,536 core shards, which in turn manage data shards. The total shard address space supports up to 2256 shards, though shards activate dynamically based on network demand. • Dynamic Growth: Shards grow like a spider weaving a web, starting with the 256 globe shards and expanding core and data shards as needed. 4. Automatic Load Balancing: Shard Splitting and Merging 4.1 The Problem with Serial Blockchains In serial blockchains, high transaction volumes overwhelm a single block, causing congestion. QUIL solves this by distributing transactions across shards, each with its own provers (nodes) for storage and processing. 4.2 Shard Splitting and Merging • Hot Shard Splitting: When transaction volume on a shard increases, QUIL’s rewards for that shard rise, attracting more provers. If the number of provers exceeds 32, the shard splits into two, diverting traffic and balancing the load. • Cold Shard Merging: If a shard’s prover count drops below 6, it merges with another shard. These processes occur automatically within 1–2 frames (10–20 seconds). This dynamic splitting and merging enable QUIL to achieve near-unlimited TPS, as each shard processes thousands of transactions per second independently. 5. High-Performance Transaction Processing 5.1 Transaction Flow QUIL’s transaction process leverages its sharded structure for efficiency: -Shard-Level Execution: Transactions occur on specific shards. For example, User A’s assets on Shard A and a smart contract on Shard C process a transfer. Provers on each shard elect a leader to produce a “block” for that shard, verified by other provers. -Cross-Shard Coordination: Shards A and C submit proofs to a globe shard for global validation. If validated, the transaction completes; otherwise, both shards roll back to prevent double-spending. -Localized Processing: Only the provers on relevant shards process the transaction, reducing network-wide overhead. 5.2 Hypergraph-Based Organization QUIL’s shards are organized using a hypergraph, which assigns data and transactions to provers based on geographic or operational proximity. For example, an application targeting European users is primarily processed by European provers, minimizing latency and aligning with cloud computing principles. 6. Consensus Security 6.1 Minimum Replication Factor Each application’s data is stored across three globe shards and three core shards,typically involving 24 prover nodes (8 per shard). This Minimum Replication Factor ensures redundancy. 6.2 Cross-Verification Security Modifying a shard’s data requires controlling over two-thirds of the network’s nodes due to QUIL’s cross-verification mechanism: • Data from one application is stored across multiple shards, and shards store data from multiple applications. • Modifying one shard requires altering data across a vast network of provers,making attacks computationally infeasible. • KZG and VDF Signatures: Even if malicious actors control most provers, a single honest prover can use KZG (data state proof) and VDF (verifiable delay function) signatures to enforce correct data via cryptographic verification. 6.3 Cryptographic Mechanisms • KZG Proofs: Prove state changes within a shard with minimal data size. • VDF: Ensures non-accelerable computation, serving as a global clock with a 10-second frame interval. VDF’s fast verification (microseconds) ensures rapid validation. • BLS Threshold Signatures: Require two-thirds of participants to achieve consensus, similar to Ethereum. 7. Proof of Meaningful Work (PoMW) Incentives 7.1 Reward Structure QUIL’s Proof of Meaningful Work (PoMW) incentivizes provers through: • Storage-Based Rewards: Provers earn rewards proportional to the storage their shards contribute to the network’s worldstate. • Ring Queue System: Each shard has a graded queue (ring0, ring1, etc.), with ring0 offering the highest rewards (100%) and subsequent rings offering reduced rewards (e.g., 50% for ring1). • Seniority Mechanism: Stable provers gain seniority, improving their queue priority. Offline provers face penalties and demotion. 7.2 Multiproof Mechanism Provers can prove multiple shards simultaneously using a single CPU core per shard. Rewards follow a square-root formula (√shards_number), encouraging deep data replication while discouraging over-centralization. 8. Measuring Computational Value 8.1 Why It Matters Measuring computational value is critical for blockchain cloud computing. Unlike Bitcoin’s hash-based Proof of Work, QUIL measures computational work through: - Encrypted Circuit Computing: Ensures correct calculation by breaking application logic into logic gates. - KZG Proofs: Verify data existence and state changes. - VDF Proofs: Measure computation time, ensuring non-accelerable processing. 8.2 Process - Application Input: Code logic is converted into an encrypted circuit (e.g., if (x > 10) then y = x * 2 else y = x + 5 becomes a series of logic gates). - Execution and Proof Generation: • Initial state → KZG Commitment → VDF Time Proof. • Each operation updates the state, generating new KZG and VDF proofs in a continuous cycle. - Reward Allocation: Computational resources consumed (calculation correctness, data changes, and time) determine prover rewards. 8.3 Comparison with Other Projects Unlike Filecoin, Storj, and AO, which focus on storage proofs, QUIL measures both storage and computation. Compared to ICP’s Proof of Useful Work (PoUW), QUIL’s PoMW avoids reliance on Proof of Stake inflation and restrictive node onboarding, ensuring greater decentralization. 9. Instant Confirmation and Low Latency 9.1 Frame Interval vs. Confirmation Time QUIL’s 10-second frame interval applies to global consensus synchronization, not transaction confirmation. Transactions on individual shards are confirmed instantly by shard leaders, limited only by network latency (typically 200ms–10s). Rollbacks, if needed, are network-wide to prevent fund loss. 9.2 Running a Prover Applications requiring low latency can run their own prover on relevant shards,ensuring immediate verification and enhanced security. 10. Conclusion QUIL’s auto-load-balancing, sharded structure redefines blockchain scalability and performance. By distributing transactions across countless shards, each with its own consensus engine, QUIL achieves near-unlimited TPS while maintaining decentralization and security. Its innovative use of KZG, VDF, and PoMW ensures robust consensus and fair reward distribution, positioning QUIL as a leader in decentralized cloud computing. 11. References • QUIL Source Code (refer to official repository for details).