Solana verkortt bloktijden met 17% naar 250 milliseconden
Belangrijkste punten
- •Solana verlaagde op 18 september 2026 de doelsloottijd van 300 naar 250 milliseconden, met de activering van de vierde fase van SIMD-0525 bij de start van epoch 1037.
- •De blokproductie steeg naar vier slots per seconde vanaf ongeveer 3,3, maar de transactiedoorvoer nam niet toe omdat de compute-limieten per slot zijn verlaagd van 60 naar 37,5 miljoen en de datashred-limieten zijn teruggeschroefd.
- •Het voornaamste praktische voordeel is een snellere dataactualiteit: prijzen, accountstatussen en blockhash-vensters worden vaker bijgewerkt, in plaats van meer ruwe capaciteit.
- •De epochduur is gecomprimeerd van circa 36 uur naar ongeveer 30 uur, met gevolgen voor validators, de verdeling van staking-beloningen en protocollen die aan epochgrenzen zijn gekoppeldDe uiteindelijke doelstelling van 200 milliseconden, al getest op devnet en testnet, hangt af van block-skip-rates op mainnet die binnen aanvaardbare grenzen blijven, nu de leader-controlvensters zijn verkort van 1,2 naar 1 seconde.

Solana heeft de cadans van zijn blokproductie aangescherpt: op 18 september 2026 is de doelsloottijd verlaagd van 300 milliseconden naar 250 milliseconden, gelijktijdig met de start van epoch 1037. Deze wijziging verhoogt de blokproductie naar vier slots per seconde, tegenover voorheen ongeveer 3,3 slots per seconde — een verkorting van de sloottijd met circa 17%. De sloottijd is het interval dat elke validator heeft om een blok te produceren, en daarmee de meest directe maatstaf voor hoe snel nieuwe netwerkstatus beschikbaar komt.
Deze activering markeert de vierde fase van SIMD-0525, een gefaseerd voorstel om de blok-cadans van Solana geleidelijk aan te scherpen, met een uiteindelijk doel van 200 milliseconden per slot.
Snellere blokken, niet meer capaciteit
Contra-intuïtief leiden snellere blokken niet tot een hoger aantal transacties per seconde. Om het netwerk stabiel te houden, heeft Solana de compute- en datalimieten per slot evenredig verlaagd samen met de tijdsaanpassing. Het maximale aantal compute-units per slot daalde van een basislijn van 60 miljoen naar 37,5 miljoen, en de datashred-limieten zijn in dezelfde richting aangepast.
In sectorvergelijkingen worden bloktijd en doorvoer vaak door elkaar gehaald, maar ze meten verschillende dingen — hoe vaak nieuwe blokken binnenkomen versus hoeveel elk blok kan bevatten. Het praktische voordeel ligt hier niet in ruwe doorvoer, maar in dataactualiteit. Prijzen, accountstatussen en blockhash-vensters worden allemaal vaker bijgewerkt — een verschuiving die enorm belangrijk is voor toepassingen die afhankelijk van actuele informatie, omdat er minder tijd verloren gaat aan handelen op verouderde status.
Ook de epochduur is gekrompen. Omdat epochs worden gedefinieerd op basis van het aantal slots in plaats van kloktijd, comprimeert het kortere slot alles wat aan epochgrenzen gekoppeld is. Bij 250 milliseconden per slot duurt de epoch van Solana nu circa 30 uur, tegenover ongeveer 36 uur daarvoor. Dat heeft gevolgen voor validators, de verdeling van staking-beloningen en elk protocol dat timing aan epochgrenzen koppelt.
Een gefaseerde uitrol met een duidelijke routekaart
SIMD-0525 is in weloverwogen stappen voortgeschreden in plaats van in één sprong. De eerste mainnet-verlaging bracht de sloottijden op 19 augustus 2026 naar 350 milliseconden. De tweede verlaagde ze op 25 augustus 2026 naar 300 milliseconden. De activering van 18 september is de vierde fase, wat betekent dat er tussen eind augustus en half september een derde stap heeft plaatsgevonden.
De uiteindelijke doelstelling van 200 milliseconden is al getest op zowel devnet als testnet. Wat tussen die mijlpaal en mainnet-activering staat, is de block-skip-rate: de validators van Solana missen af en toe hun toegewezen slot, en bij strakkere timingvensters wordt de tolerantie voor dergelijke missers kleiner. De kernontwikkelaars willen eerst bevestigen dat de skip-rate binnen aanvaardbare grenzen blijft voordat de definitieve verlaging live gaat.
Ook de leader-controlvensters zijn met deze wijziging strakker geworden, van 1,2 naar 1 seconde — vier opeenvolgende slots per leader in de nieuwe cadans. Validators hebben nu minder tijd om hun blokken uit te zenden — een van de variabelen die de skip-rates beïnvloeden. Nu de strakkere vensters live zijn, is het skip-rate-gedrag op mainnet de maatstaf om in de gaten te houden nu de community de laatste stap naar 200 milliseconden afweegt.