Solana mikt op vijf blockmomenten per seconde
Wij geloven in volledige transparantie naar onze lezers. Sommige van onze artikelen bevatten links naar affiliate partners. Via deze samenwerkingen kunnen wij een commissie verdienen. Dit heeft echter nooit invloed op de onafhankelijkheid van onze analyses, meningen of reviews. Onze beoordelingen zijn uitsluitend gebaseerd op onze vastgestelde evaluatiecriteria. Lees meer.
Solana plant op vrijdag 9 oktober de laatste stap naar slots van 200 milliseconden, een verlaging vanaf de huidige 250 milliseconden. De upgrade moet meer momenten voor blockproductie opleveren, maar verkleint tegelijk de rekencapaciteit per block en vraagt validators vaker te stemmen. Of de extra snelheid opweegt tegen de hogere druk op de infrastructuur, hangt mede af van de stabiliteit van het netwerk.
Wat verandert er technisch voor Solana?
Een slot is het tijdvenster waarin een aangewezen validator een block kan produceren. Volgens aanvullende berichtgeving over de upgrade zou de overgang naar 200 milliseconden vijf blockproductiemomenten per seconde mogelijk maken, tegenover 2,5 bij de oorspronkelijke configuratie van 400 milliseconden.
Die hogere frequentie betekent niet automatisch dat Solana als geheel twee keer zoveel transacties kan verwerken. De maximale hoeveelheid rekenwerk per block daalt volgens die berichtgeving van 37,5 miljoen naar 30 miljoen compute units; doordat blocks vaker verschijnen, blijft de theoretische totale capaciteit ongeveer gelijk.
Voor wallets, exchanges en handelsapplicaties kan de kortere slotduur wel betekenen dat zij vaker nieuwe netwerkgegevens ontvangen. Dat kan de wachttijd tussen het indienen van een transactie en de verwerking ervan verkorten, al is de werkelijke uitkomst afhankelijk van de prestaties van validators en de netwerkcondities.

Meer stemmen, kortere productievensters
The Defiant meldde op 8 oktober dat Solana de laatste verlaging naar 200 milliseconden inplant. De publicatie benadrukt dezelfde operationele afweging: lagere rekengrenzen per block moeten de totale capaciteit behouden, terwijl validators vaker stemmen en minder tijd krijgen om blocks te produceren.
Validators die op iedere slot stemmen, zouden bij de nieuwe configuratie ongeveer twee keer zo vaak een stemtransactie moeten indienen als bij slots van 400 milliseconden. Dat verhoogt de hoeveelheid netwerkverkeer en kan de operationele kosten opvoeren, vooral voor validators die weinig stemkosten via blockproductie kunnen terugverdienen.

Validators produceren volgens de aanvullende berichtgeving blocks in reeksen van vier opeenvolgende slots. Hun aaneengesloten venster om transacties te ordenen krimpt daardoor van 1,6 seconde bij de oorspronkelijke instellingen naar 800 milliseconden. Snellere verwerking kan de ruimte beperken om transacties uit te stellen of voordeel te halen uit prijsbewegingen op andere handelsplatforms, maar maakt de eisen aan verbindingen en uitvoering ook strenger.
Ook gebruikers kunnen een praktisch nadeel merken. Een transactie gebruikt doorgaans een recente blockhash als referentie; bij een kortere geldigheidsperiode is er minder tijd om de transactie goed te keuren en te versturen. Dat kan vooral processen met handmatige goedkeuring of offline ondertekening lastiger maken.
Voor toepassingen waarbij snelle en betrouwbare afwikkeling van belang is, zoals institutionele settlement op Solana, wordt de balans tussen lagere vertraging en stabiele netwerkprestaties daarmee concreet relevant.
Epoch 1053 wordt het volgende ijkpunt
De aanvullende berichtgeving plaatst de verwachte overgang rond de grens van epoch 1053, naar verwachting omstreeks 15.00 uur UTC op vrijdag 9 oktober. De laatste verlaging is volgens die informatie al uitgerold op testnet en devnet, maar de mainnet-activatie blijft afhankelijk van de netwerkcondities, waaronder het aantal gemiste blockproductiemomenten.
Een eerdere configuratie met een doelduur van 250 milliseconden kwam volgens Solana Compass in recente epochs gemiddeld uit op circa 266 tot 269 milliseconden per slot. Dat verschil onderstreept dat een ingestelde doelduur niet hetzelfde is als de feitelijke netwerkprestatie.
Na de geplande activatie zijn daarom vooral gemiste slots, validatorconnectiviteit en de werkelijk gemeten slotduur van belang. De technische afweging lijkt op die bij andere netwerkupgrades, waar hogere verwerkingsambities ook gevolgen kunnen hebben voor nodes en stabiliteit, zoals blijkt uit een stresstest van de Ethereum-gaslimiet. Pas de prestaties op mainnet laten zien of de kortere slots de verwachte snelheidswinst opleveren zonder de betrouwbaarheid onnodig onder druk te zetten.