Solana maakt transacties 3,3 keer groter met nieuwe V1-upgrade
Solana heeft de maximale transactiegrootte in één klap verhoogd van 1.232 naar 4.096 bytes. Transaction V1 ging op 15 september rond 01:00 UTC live op mainnet en geeft ontwikkelaars ruim 3,3 keer zoveel ruimte per transactie.
Dat klinkt als een simpele capaciteitsverhoging. Technisch verandert er meer: grote multisigs, zero-knowledge-bewijzen en gebundelde acties kunnen nu vaker binnen één atomische transactie passen.
De upgrade verhoogt alleen niet rechtstreeks het aantal transacties per seconde.
Transaction V1 is nu live op mainnet
De txv1-feature gate werd bij de start van epoch 1035 geactiveerd.
De officiële Solana-pagina bevestigt dat V1 inmiddels actief is op mainnet, testnet en devnet.
De nieuwe limiet bedraagt 4.096 bytes per transactie.
Legacy- en v0-transacties blijven daarnaast gewoon geldig. Een applicatie hoeft dus niet naar V1 over te stappen om op Solana te blijven werken.
Wie de extra ruimte wil gebruiken, moet V1 wel expliciet ondersteunen.
Van 1.232 naar 4.096 bytes
De oude grens kwam voort uit Solana's oorspronkelijke netwerkontwerp.
Solana hield rekening met een conservatieve MTU van 1.280 bytes. Na technische overhead bleef daarvan maximaal 1.232 bytes over voor een transactie.
Sinds QUIC wordt gebruikt voor het binnenhalen van transacties bestaat die harde beperking niet meer.
SIMD-0296 verhoogt de limiet daarom naar 4.096 bytes. SIMD-0385 introduceert het V1-formaat waarmee die grotere transacties worden verstuurd.
4.096 gedeeld door 1.232 komt neer op ongeveer 3,3 keer zoveel ruimte.
ZK-bewijzen en multisigs krijgen meer lucht
Die extra bytes zijn vooral interessant voor toepassingen die tegen de oude grens aanliepen.
Solana noemt zelf onder meer zero-knowledge-bewijzen, grote multisigconstructies en cryptografische handtekeningsystemen zoals BLS.
Ook Winternitz one-time signatures worden expliciet genoemd.
Voorheen moesten ontwikkelaars sommige grotere processen opdelen.
Daarvoor konden bijvoorbeeld meerdere gekoppelde transacties of Jito-bundels nodig zijn.
Met V1 kan meer werk als één transactie naar het netwerk.
Eén transactie betekent ook één uitkomst
Daar zit een praktisch voordeel.
Een Solana-transactie is atomisch.
Alle instructies slagen gezamenlijk of de volledige transactie mislukt.
Wanneer een proces over meerdere afzonderlijke transacties moet worden verdeeld, wordt dat moeilijker. Een eerste stap kan al zijn bevestigd voordat een latere stap faalt.
Met 4.096 bytes kunnen sommige workloads nu binnen één atomisch geheel blijven.
De echte winst is niet alleen meer data. Ontwikkelaars kunnen complexere acties vaker als één ondeelbare handeling uitvoeren.
Solana stelt dat dit in bepaalde situaties ook minder handtekeningen en minder afzonderlijke bevestigingen kan betekenen.
V1 gooit Address Lookup Tables eruit
Transaction V1 is niet simpelweg een grotere versie van V0.
Het formaat is anders opgebouwd.
V0 ondersteunt Address Lookup Tables, waarmee adressen compact kunnen worden gerefereerd. V1 gebruikt die tabellen niet.
In plaats daarvan kunnen maximaal 64 adressen rechtstreeks in de transactie worden opgenomen.
Door de grotere limiet is daar veel meer ruimte voor.
De officiële specificatie houdt daarnaast een maximum aan van 12 handtekeningen en 64 instructies per V1-transactie.
Dat maakt V1 groter, maar tegelijk strakker gedefinieerd.
ComputeBudget verhuist naar transactionConfig
Een tweede grote wijziging zit bij rekenlimieten en priority fees.
Legacy en V0 gebruiken daarvoor instructies van het ComputeBudgetProgram.
V1 doet dat anders.
Limieten zoals compute units, heap size, geladen accountdata en de priority fee staan in een aparte transactionConfig binnen het bericht.
Dat moet het voor het netwerk sneller maken om belangrijke transactiekenmerken uit te lezen.
Het hoeft daarvoor niet eerst een hele lijst instructies af te zoeken.
Voor gewone gebruikers is dat grotendeels onzichtbaar.
Voor software die transacties analyseert is het een belangrijke wijziging.
Oude indexers kunnen stilletjes verkeerde data tonen
Hier zit waarschijnlijk het grootste operationele risico van de upgrade.
Een systeem dat bij V1 nog steeds naar oude ComputeBudget-instructies zoekt, kan voor bijvoorbeeld compute limits of priority fees nul rapporteren zonder een duidelijke foutmelding te geven.
Solana waarschuwt hier expliciet voor.
Ook RPC-clients moeten V1 herkennen.
Bij getTransaction en getBlock moet maxSupportedTransactionVersion op 1 worden gezet.
Gebeurt dat niet, dan kan een V1-transactie ervoor zorgen dat een request faalt. Bij getBlock kan zelfs het volledige blokrequest mislukken zodra één V1-transactie wordt aangetroffen.
Voor explorers en datadiensten is dit dus geen cosmetische update.
Wallets hoeven niet onmiddellijk over
Voor normale gebruikers verandert veel minder.
Een bestaande wallet kan legacy- en V0-transacties blijven gebruiken.
Dapps mogen bovendien niet zomaar aannemen dat iedere wallet V1 kan tekenen.
Wallets moeten via de Solana Wallet Standard aangeven welke transactieversies zij ondersteunen. Een dapp hoort eerst te controleren of versie 1 wordt geaccepteerd en anders terug te vallen op V0.
Dat voorkomt dat een applicatie een transactie bouwt die de wallet van de gebruiker vervolgens niet kan ondertekenen.
RPC-nodes en Jito-leaders moeten opletten
Solana adviseert twee groepen expliciet om minimaal versie 4.2.2 te gebruiken.
Jito-Solana-leaders met oudere software kunnen V1-transacties niet opnemen in hun blokken.
RPC-nodes vóór Agave 4.2.2 kennen een ander probleem.
Die kunnen een V1-bericht bij opslag verkeerd terugzetten als V0, waarbij de nieuwe configuratie verloren gaat. Daardoor kunnen computegegevens verkeerd worden weergegeven.
Alle v4.2.x-validatorknooppunten ondersteunen de grotere transacties wel op consensusniveau.
Het is dus niet correct om te stellen dat iedere validator verplicht naar exact 4.2.2 moet.
Grotere transacties kunnen meer kosten om voorrang te krijgen
4.096 bytes betekent bovendien niet gratis extra ruimte.
Een grotere transactie vraagt meer netwerkcapaciteit om te ontvangen en verwerken.
Solana verwacht daarom dat de scheduler bij vergelijkbare druk hogere priority fees kan verlangen voor grotere transacties dan voor kleinere transacties met vergelijkbare prioriteit.
Dat is iets anders dan zeggen dat V1 standaard duurder is.
Een applicatie die met één grote transactie drie losse transacties vervangt, kan juist handtekeningen en bevestigingen besparen.
De uiteindelijke kosten hangen dus af van wat er wordt samengevoegd en hoeveel netwerkruimte de transactie inneemt.
4 KiB is bewust gekozen
Solana had de limiet ook veel hoger kunnen leggen.
Dat gebeurde niet.
De 4.096-bytegrens sluit aan bij een standaard 4 KiB-geheugenpagina die door validatorhardware wordt gebruikt. Daardoor kan één transactie binnen een logische geheugeneenheid blijven.
Nog grotere transacties zouden daarnaast over meer QUIC-frames moeten worden verdeeld.
Wanneer één frame verloren gaat, moet extra data opnieuw worden verstuurd.
Solana kiest dus bewust voor meer ruimte zonder transacties onbeperkt te laten groeien.
Dit is geen directe TPS-upgrade
Daarmee komt de belangrijkste nuance.
Transaction V1 verhoogt niet simpelweg de maximale TPS van Solana met factor 3,3.
De upgrade verandert hoeveel informatie binnen één transactie past.
Dat kan toepassingen efficiënter maken als ze eerder verschillende losse transacties nodig hadden.
Maar één transactie van 4.000 bytes gebruikt juist meer netwerkruimte dan een kleine betaling van enkele honderden bytes.
V1 draait daarom vooral om rijkere transacties, niet automatisch om meer transacties.
Vooral complexe financiële apps kunnen verschil merken
Dat kan uiteindelijk wel veel uitmaken voor applicatiebouwers.
Complexe handelsacties kunnen meerdere accounts en instructies nodig hebben.
Institutionele multisigs vragen meerdere handtekeningen.
ZK-toepassingen moeten relatief grote bewijzen meesturen.
Onder de oude limiet werd dan al snel tegen 1.232 bytes aangelopen.
V1 verschuift die grens fors.
Voor exchanges, wallets, explorers en andere partijen die Solana-data verwerken, ligt het werk nu vooral bij correcte ondersteuning van het nieuwe formaat.
Voor eindgebruikers kan de winst later zichtbaar worden als dapps handelingen die nu nog uit meerdere stappen bestaan binnen één bevestiging krijgen.
Solana heeft dus niet simpelweg 3,3 keer meer transacties gekregen.
Het heeft iedere afzonderlijke V1-transactie 3,3 keer meer ruimte gegeven.
En voor ontwikkelaars die jarenlang tegen die 1.232-bytegrens aanliepen, is juist dat het cijfer dat telt.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
