Van 1.232 naar 4.096 bytes per transactie.
Solana wil op 9 september Transaction V1 activeren en geeft ontwikkelaars daarmee ruim drie keer zoveel ruimte binnen één atomaire handeling.
Voor gewone gebruikers verandert die dag weinig. De winst zit vooral bij zware transacties met ZK-proofs, multisigs en andere cryptografische data die nu tegen de limiet aanlopen.
4.096 bytes vervangt de oude grens niet volledig
De
officiële Solana-roadmap voor grotere transacties beschrijft een verhoging van 1.232 naar 4.096 bytes.
Dat is ongeveer 3,3 keer zoveel ruimte.
De huidige grens komt uit een oude netwerkkeuze rond de maximale pakketgrootte. Door het gebruik van QUIC kan Solana volgens
SIMD-0296 nu grotere transacties verwerken.
De extra ruimte geldt alleen voor het nieuwe V1-formaat.
Legacy- en V0-transacties blijven bestaan.
9 september is gepland, maar nog geen voldongen feit
Solana Foundation-technoloog Jacob Creech zette op 29 augustus de komende upgrades op een rij en noemde 9 september voor Transaction V1.
Die datum moet wel als geplande activatie worden gelezen.
De officiële Solana-pagina markeert de feature op dit moment nog als Pending Feature Activation. Ook de uitrolschema's van validatorsoftware waarschuwen dat activatiedata kunnen veranderen.
Voor ontwikkelaars is 9 september dus de datum om op te sturen.
Niet een garantie die technisch niet meer kan verschuiven.
Waarom 1.232 bytes soms te weinig is
Een gewone tokenoverdracht heeft geen 4 kilobyte nodig.
Het probleem ontstaat bij complexere handelingen.
De ontwerpdocumenten noemen bijvoorbeeld zero-knowledge proofs, grote multisigconstructies, Winternitz-handtekeningen en cryptografische schema's zoals BLS.
Bij zulke transacties stapelen signatures, instructies en andere gegevens zich snel op.
Onder de huidige limiet moeten ontwikkelaars sommige processen daarom over meerdere transacties verdelen.
Dat heeft een nadeel.
Als stap één slaagt en stap twee faalt, moet de applicatie daar rekening mee houden. Eén atomaire transactie is simpeler: alles wordt uitgevoerd of niets.
Confidential transfers passen straks in één transactie
Solana noemt confidential transfers als concreet voorbeeld.
Zo'n transfer kan meerdere zero-knowledge proofs nodig hebben. Die bewijzen maken het mogelijk iets cryptografisch aan te tonen zonder alle onderliggende informatie openbaar te maken.
Onder de huidige limiet moet zo'n workflow soms worden opgesplitst.
Met Transaction V1 kan de complete handeling volgens de Solana Foundation in één transactie passen.
Dat is een echte technische winst.
Maar het betekent niet dat
Solana plotseling 3,3 keer zoveel transacties per seconde verwerkt.
Grotere transacties betekenen geen 3,3 keer hogere TPS
Dat onderscheid is belangrijk.
Transaction V1 verhoogt de maximale datagrootte per transactie.
Het verhoogt niet automatisch de totale rekencapaciteit van ieder block met dezelfde factor.
Een grotere vrachtwagen betekent tenslotte niet dat er ineens drie keer zoveel vrachtwagens over de weg kunnen.
Netwerkcapaciteit, blocklimieten, slottijden en consensus worden via andere wijzigingen aangepakt.
Wie de stap van 1.232 naar 4.096 bytes vertaalt naar “3,3 keer snellere Solana”, trekt dus de verkeerde conclusie.
V1 gooit Address Lookup Tables eruit
De extra ruimte komt bovendien met een technische ruil.
Transaction V1 ondersteunt geen Address Lookup Tables, oftewel ALTs.
V0 gebruikt zulke tabellen om adressen buiten de transactie op te slaan en er compact naar te verwijzen.
Dat bespaart ruimte.
Maar ALTs voegen ook complexiteit toe voor validators en ontwikkelaars. V1 kiest daarom voor een groter transactiepakket zonder die lookup tables.
Het maximale aantal direct gebruikte accounts blijft daarbij 64.
Meer bytes betekent dus niet automatisch dat ontwikkelaars veel meer accounts in één transactie kunnen proppen.
Ook de manier waarop fees worden ingesteld verandert
V1 verandert meer dan alleen de grootte.
Onder oudere formaten kunnen instellingen voor compute units en priority fees via aparte Compute Budget-instructies in een transactie worden geplaatst.
V1 verplaatst zulke gegevens naar een eigen transactionConfig.
Dat maakt de verwerking voor validators overzichtelijker.
Het heeft wel gevolgen voor software die transacties uitleest.
Indexers, explorers en RPC-diensten moeten V1 kunnen herkennen. Wie alleen naar oude Compute Budget-instructies blijft zoeken, kan bijvoorbeeld verkeerde informatie over priority fees rapporteren.
Voor eindgebruikers is de overgang optioneel.
Voor partijen die de
blockchain analyseren, kan de nieuwe versie dus wel degelijk aanpassingen vragen.
Solana draait sinds 28 augustus al op 300ms-slots
Transaction V1 komt bovendien tijdens een periode waarin Solana meerdere technische wijzigingen kort achter elkaar uitrolt.
Op 28 augustus ging de tweede stap van
SIMD-0525 live.
De beoogde slottijd op mainnet zakte daarmee van 350 naar 300 milliseconden.
De oorspronkelijke waarde was 400 milliseconden.
Er staan nog twee stappen gepland: eerst naar 250ms en uiteindelijk naar 200ms.
Dat proces staat los van Transaction V1.
Grotere transacties en kortere slots worden dus afzonderlijk geactiveerd.
Ook het minimale saldo voor accounts moet omlaag
Creech wees daarnaast op de eerste stap van een verlaging van Solana's zogeheten rentparameter.
De naam kan verwarrend zijn.
Dit gaat vooral om het minimale saldo dat accounts moeten vasthouden voor opslag op het netwerk, niet om een maandelijkse “huur” die gebruikers steeds opnieuw betalen.
SIMD-0437 stelt vijf afzonderlijke stappen voor.
De parameter lamports_per_byte moet uiteindelijk van 6.960 naar 696 zakken.
Dat is een totale verlaging van 90%.
Maar die volledige daling komt niet in één keer.
Iedere fase heeft een eigen feature gate en de volgende stap moet worden beoordeeld op gevolgen voor de hoeveelheid data die validators moeten bewaren.
Alpenglow is de veel grotere wijziging
Daarna wacht Alpenglow.
Creech noemt oktober als huidig doel voor de overgang, maar ook dat is geen gegarandeerde mainnetdatum.
SIMD-0326 vervangt uiteindelijk grote delen van het huidige consensusmechanisme.
De inzet is veel snellere definitieve bevestiging van transacties.
Transaction V1 verandert daar op 9 september niets aan.
De drie ontwikkelingen moeten daarom uit elkaar worden gehouden: V1 vergroot transacties, SIMD-0525 verkort slots en Alpenglow verandert de consensus.
Voor ontwikkelaars begint de echte test pas na activatie
Gebruikers hoeven op 9 september geen wallet te migreren.
Legacy en V0 blijven functioneren.
Ontwikkelaars die van de 4.096-byte limiet willen profiteren, moeten daarentegen bewust V1 gaan gebruiken en hun software aanpassen.
Daarmee wordt adoptie de interessantere graadmeter dan de feature gate zelf.
Als ZK-toepassingen, grote multisigs en confidential transfers de extra ruimte daadwerkelijk benutten, lost V1 een concrete beperking op.
Gebeurt dat nauwelijks, dan is 4.096 bytes vooral meer beschikbare ruimte.
Solana zet de deur op 9 september volgens de huidige planning drie keer verder open. Daarna moet blijken wie er werkelijk iets groters doorheen stuurt.