Oxfinger

220k TPS on Supernova $EGLD

Supernova is live on Battle Net. Here's what changed under the hood and why it matters. The paradigm shift nobody's talking about: Every blockchain in the industry is measured on two metrics: block time and throughput. Faster blocks = better chain. More TPS = better chain. ---------- Supernova breaks this framing entirely. For the first time in the blockchain industry, block finality is faster than block slot allocation. Let me explain what that means. How every other blockchain works: Traditional blockchains follow Execute → Propose → Vote. Validators must execute every transaction before proposing a block. The block slot is the clock. Finality can never be faster than the slot, because execution is in the critical path. Ethereum: 12.8s slot, ~12.8 minutes finality. Solana: 400-600ms slot, 13 seconds finality. Sui: variable, ~500 to 1000 ms for complex transactions. In every case: finality ≥ block slot. This is treated as a law of physics. It's not. ---------- How Supernova works: We flipped the model to Propose/Vote → then Execute. Consensus proceeds independently of execution. Validators agree on transaction ordering first. Execution results are notarized in subsequent block headers via inclusion proofs. The inclusion proof is the key innovation: it allows a block to be finalized with cryptographic proof that its transactions will execute correctly, before the execution itself completes. The virtual state tracker in the transaction pool maintains a deterministic view of account states (nonces, balances, pending transactions) so consensus can validate without waiting for full execution. Result: the block is finalized faster than the block round itself. 88ms finality measured in testing. Sub-200ms under real-world conditions. On 600ms block slots. Finality < block slot. First time in the industry. ---------- The throughput story: With the same hardware specification as pre-Supernova mainnet, the network now achieves ~120,000 transactions per second in burst mode. Same nodes. Same machines. 10x the block production cadence. This is the same validator infrastructure running fundamentally better software. The backpressure system (Execution-Result Inclusion Estimator) ensures this scales safely - dynamically adjusting per-block gas limits if execution lags behind proposals, so minimum-spec nodes never get overwhelmed. What this means in context: - Block time: 6s → 600ms (10x) - Finality: ~88ms measured (first blockchain where finality < slot time) - Throughput: ~120,000 TPS burst mode (same hardware) - Architecture: consensus fully decoupled from execution - Sharding: 3 execution shards + metachain, fully preserved - Validators: 3,200+ nodes, no hardware upgrade required ---------- Battle of Nodes is stress-testing all of this right now. $150K in prizes to find what breaks. Validators, security researchers, builders, and guilds pushing the limits. If Supernova survives this, it ships to mainnet. 150,000 lines of new protocol code. 20 months of engineering. The most significant upgrade since genesis.

The latest network stress test put serious pressure on our BoN infrastructure, especially on the gateway-facing observers and the indexers. A few important details on the current setup: - one observer per shard behind the gateway - well below spec for sustained stress testing; on mainnet we use multiple observers per shard for load balancing - a single indexing cluster accessed by all services - on mainnet, different services use different clusters - a single observer per shard (one squad), with notifier, serving internal services - on mainnet we run multiple squads, and these roles are split across different machines. Regular API requests and VM queries are also served by different machine types there We also found a misconfiguration on BoN for VM queries. Under stress, it led to request buildup and out-of-memory issues, which affected both the API and the gateway. We are fixing this. Over the last two days of testing, we also uncovered optimizations needed for Supernova when the network is hit with very high transaction volume continuously over long periods. These issues only surface under sustained heavy load. The optimization has already been prepared and tested internally, and we will likely deploy it on BoN as well. One clear lesson: running stress tests like this while also keeping infra costs low is a challenge on its own. That said, the network is still up and running, and more optimizations are on the way to improve behavior under heavy load. And finally, a big thank you to everyone involved - these findings were possible because of your efforts.