Solana heeft zojuist 50 milliseconden afgeschaafd van de tijd die validators nodig hebben om een blok te produceren, en het is de eerste keer dat het netwerk dit ooit heeft gedaan. De Solana slot time-upgrade ging vrijdag live op mainnet, waarbij de doel-slot-tijd werd verlaagd van 400 milliseconden naar 350 milliseconden en een proces in gang werd gezet dat ontwikkelaars omschrijven als een gefaseerde, epoch-voor-epoch mars richting een veel snellere doelstelling van 200 milliseconden.
Summary
Belangrijkste punten
- De slot-tijd van Solana’s mainnet is gedaald van 400 milliseconden naar 350 milliseconden, de eerste dergelijke verlaging sinds de lancering van het netwerk.
- De wijziging werd geactiveerd als feature SIMD-0525 op slot 440.208.000 in epoch 1019, nadat deze op 14 mei in de codebase was opgenomen.
- Drie extra verlagingen van 50 milliseconden, naar 300, 250 en uiteindelijk 200 milliseconden, zijn gepland via afzonderlijke feature gates, elk afhankelijk van gezonde block-skippercentages.
- De upgrade wordt aangeduid als een breaking change, en Solana zegt dat indexeringsaanpassingen voor tools van derden nog worden uitgewerkt.
- Jacob Creech, vicevoorzitter technologie bij de Solana Foundation, bevestigde dat 300 milliseconden het volgende doel op de roadmap is.
Solana verlaagt voor het eerst de slot-tijd op mainnet
De kern van het antwoord is eenvoudig: Solana heeft er net voor gezorgd dat blokken sneller aankomen, zonder de onderliggende structuur van het netwerk te veranderen. Dit is de eerste verlaging van de slot-tijd sinds het ontstaan van Solana, en het verkort direct het tijdsvenster dat elke validator krijgt om een blok met transacties samen te stellen en uit te zenden.
Details van de activatie en directe effecten
De feature, geregistreerd als SIMD-0525, werd geactiveerd op Mainnet Beta op slot 440.208.000 in epoch 1019, volgens Solana’s eigen explorer. Het voorstel zelf werd op 14 mei opgenomen in de verbeteringsdocumenten van het netwerk, waardoor ontwikkelaars enkele maanden de tijd kregen om validatorsoftware voor te bereiden voordat de schakelaar werd omgezet.
Het praktische effect is vrijwel onmiddellijk zichtbaar in de bevestigingssnelheid. Een momentopname die door The Block werd gerapporteerd, wees uit dat een reeks van 1.000 slots kort voor de wijziging 415 seconden nodig had om te voltooien, vergeleken met 368 seconden voor een vergelijkbare reeks nadat de upgrade was geactiveerd in epoch 1020 — een reële daling die in lijn is met de nieuwe doelstelling van 350 milliseconden.
Omdat elk epoch op Solana nog steeds 432.000 slots bevat, vertalen snellere slots zich direct in snellere epochs. Wat vroeger ongeveer 48 uur duurde om te voltooien, is nu in ongeveer 42 uur klaar, ook al is er niets veranderd aan de interne telling van het epoch.
Technische basis die de upgrade mogelijk maakt
Niets hiervan zou mogelijk zijn geweest zonder werk aan de validatorclient-kant. Solana schrijft de vooruitgang toe aan verbeteringen in Turbine, de blokpropagatielaag van het netwerk, en Replay, het proces dat validators gebruiken om binnenkomende blokken te verifiëren en erover te stemmen, als de technische factoren die een kortere slot-tijd op schaal werkbaar maakten.
Deze twee systemen moesten sneller worden voordat het netwerk de tijd die beschikbaar is voor een leider om een blok af te ronden, het via Gulf Stream door te geven aan de volgende leider en de rest van de validatorset het te laten herafspelen en erover te stemmen, veilig kon inkorten. Het verkleinen van dat venster zonder deze upgrades zou waarschijnlijk de skippercentages hebben verhoogd en de blokproductie hebben gedestabiliseerd.
Gefaseerde aanpak voor verdere verlagingen van de slot-tijd
Solana gaat niet in één keer naar het eindpunt. In plaats daarvan beweegt het netwerk zich door vier afzonderlijke fasen, van 400 milliseconden naar 200 milliseconden, waarbij elke stap zijn eigen activatie en eigen gezondheidscontrole vereist voordat de volgende mag worden uitgevoerd.
Feature-gate-mechanisme voor toekomstige upgrades
Elke extra verlaging van 50 milliseconden, of dat nu naar 300, 250 of 200 milliseconden is, zal worden geactiveerd via een afzonderlijke feature gate die in een later epoch wordt geactiveerd, in plaats van via één allesomvattende schakelaar. Die structuur geeft de Solana Foundation en validatoroperators de ruimte om te observeren hoe het netwerk zich gedraagt bij elke nieuwe snelheid voordat ze zich vastleggen op de volgende verlaging.
Anza, het validatorclient-ontwikkelingsteam dat is voortgekomen uit het oorspronkelijke Solana Labs, heeft een voorlopige Agave v4.2-planning opgesteld die alle vier de gefaseerde verlagingen als doel heeft voor uiteindelijke mainnet-activatie. Er is nog geen kalenderdatum of specifiek epoch vastgesteld voor de stap naar 300 milliseconden, die als volgende op de planning staat.
Risicobeheersing op basis van block-skippercentages
Hier wordt de voorzichtigheid echt zichtbaar. De Solana Foundation heeft duidelijk gemaakt dat het netwerk niet zal doorgaan naar de volgende verlaging van de slot-tijd als de block-skippercentages te hoog oplopen — wat betekent dat te veel validators er niet in slagen hun toegewezen blokken op tijd te produceren. Die ingebouwde rem is belangrijk omdat kortere slots elk downstreamproces comprimeren: blokvoltooiing, transactiepropagatie en validatorstemmen hebben allemaal minder kloktijd om correct te verlopen.
Waarom dit belangrijk is: een gefaseerde uitrol met een skiprate-trigger verandert snelheid in feite in een gemonitorde variabele in plaats van een vaste belofte. Als validatorhardware of -software het tempo van 300 milliseconden niet kan bijbenen, kan het netwerk daar eenvoudig pauzeren in plaats van door te duwen en instabiliteit te riskeren.
Ruimere implicaties en impact op het netwerk
Snellere slots betekenen niet automatisch een sneller netwerk in elke betekenis, en dat onderscheid is belangrijk voor iedereen die Solana’s doorvoercijfers volgt. Validators verwerken slots vaker, maar elke individuele slot bevat minder werk, dus de wijziging verbetert vooral de latentie en bevestigingssnelheid in plaats van de ruwe transactiecapaciteit. Solana heeft in juli 2025 afzonderlijk zijn limiet voor compute units verhoogd naar 100 miljoen, een aparte upgrade die erop gericht is om meer werk in elk blok te kunnen stoppen.
Status als breaking change en impact op indexering
Solana zelf bestempelt de algehele Solana slot time-upgrade als een breaking change, en de vereiste indexeringsaanpassingen voor tools en diensten van derden moeten nog worden bepaald. Dat is een opvallend hiaat: Solana’s eigen documentatie beschrijft de standaard slotduur nog steeds als 400 milliseconden, ook al bevestigt de explorer van het netwerk dat de eerste feature gate van 350 milliseconden al actief is. Ontwikkelaars die bouwen op indexers, analysetools of blokexplorers moeten rekening houden met enige frictie op korte termijn terwijl de tooling zich aanpast aan de nieuwe timing van het netwerk.
Officiële verklaringen en inzicht in het upgradepad
Jacob Creech, vicevoorzitter technologie bij de Solana Foundation, omschreef de stap als de eerste verlaging van de slot-tijd van het netwerk en bevestigde dat 300 milliseconden het volgende doel op de roadmap is. Noch Creech, noch de openbare upgradepagina van de Foundation heeft een vaste datum gekoppeld aan die volgende stap, en het plan hangt expliciet af van hoe het netwerk zich eerst gedraagt bij 350 milliseconden.
Er is hier ook een langere horizon. Slot-tijd en volledige finaliteit zijn niet hetzelfde — de blokken van Solana hebben vandaag de dag nog steeds ongeveer 12,8 seconden nodig om volledig onomkeerbaar te worden, zelfs bij het nieuwe slotritme van 350 milliseconden. Een afzonderlijke, nog in ontwikkeling zijnde herziening genaamd Alpenglow is erop gericht om dat finaliteitsvenster uiteindelijk terug te brengen naar ongeveer 150 milliseconden, wat een veel grotere structurele verandering zou zijn dan de huidige gefaseerde verlagingen van de slot-tijd. Het netwerk heeft onlangs ook de Firedancer-client van Jump Crypto toegevoegd, gebouwd in een andere programmeertaal dan de dominante Agave-stack, wat de diversiteit van validatorclients verbetert terwijl de bredere snelheidsinspanningen doorgaan.
FAQ
Welke wijziging heeft Solana recent aangebracht in zijn slot-timing?
Solana heeft de slot-tijd op mainnet verlaagd van 400 milliseconden naar 350 milliseconden, wat de eerste verlaging sinds het ontstaan van het netwerk betekent.
Hoe zullen toekomstige verlagingen van de slot-tijd worden beheerd?
Toekomstige verlagingen naar 300, 250 en 200 milliseconden zullen afzonderlijk worden geactiveerd via feature gates en zijn afhankelijk van het feit dat block-skippercentages niet te hoog worden.
Heeft de verlaging van de slot-tijd invloed op de epoch-structuur of ticks per slot van Solana?
Nee, de upgrade verandert het aantal ticks per slot, de leader-span of het aantal slots in een epoch niet.
Waarom wordt de upgrade beschouwd als een breaking change?
De upgrade is een breaking change omdat deze indexeringswijzigingen vereist voor tools en infrastructuur van derden, hoewel die aanpassingen nog moeten worden bepaald.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Welke wijziging heeft Solana recent aangebracht in zijn slot-timing?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Solana heeft de slot-tijd op mainnet verlaagd van 400 milliseconden naar 350 milliseconden, wat de eerste verlaging sinds het ontstaan van het netwerk betekent.”}},{“@type”:”Question”,”name”:”Hoe zullen toekomstige verlagingen van de slot-tijd worden beheerd?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Toekomstige verlagingen naar 300, 250 en 200 milliseconden zullen afzonderlijk worden geactiveerd via feature gates en zijn afhankelijk van het feit dat block-skippercentages niet te hoog worden.”}},{“@type”:”Question”,”name”:”Heeft de verlaging van de slot-tijd invloed op de epoch-structuur of ticks per slot van Solana?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Nee, de upgrade verandert het aantal ticks per slot, de leader-span of het aantal slots in een epoch niet.”}},{“@type”:”Question”,”name”:”Waarom wordt de upgrade beschouwd als een breaking change?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”De upgrade is een breaking change omdat deze indexeringswijzigingen vereist voor tools en infrastructuur van derden, hoewel die aanpassingen nog moeten worden bepaald.”}}]}
Artikel geproduceerd met behulp van kunstmatige intelligentie en beoordeeld door de redactie.
