Solana activeerde zijn txv1-functie op het mainnet rond 01:00 UTC op 15 september, aan het begin van epoch 1035. Door de upgrade steeg de maximale transactiegrootte van 1.232 bytes naar 4.096 bytes, meer dan drie keer de eerdere capaciteit.

De extra ruimte is beschikbaar via het V1-transactieformaat. Applicaties moeten expliciet ondersteuning toevoegen voordat ze het kunnen gebruiken, terwijl legacy- en V0-transacties volledig ondersteund blijven binnen hun bestaande limieten.

Een grotere transactie is niet hetzelfde als een grotere SOL-overboeking

De nieuwe limiet heeft betrekking op de hoeveelheid informatie die een transactie bevat, niet op de hoeveelheid SOL die een gebruiker kan versturen. Voor een standaardoverboeking is doorgaans weinig data nodig, omdat deze slechts een klein aantal accounts, instructies en handtekeningen bevat.

Geavanceerdere handelingen kunnen meerdere instructies, talrijke accountadressen, meerdere goedkeuringen of cryptografische bewijzen vereisen. Wanneer die informatie de eerdere limiet overschreed, moesten ontwikkelaars de payload verkleinen, de handeling over meerdere transacties verdelen of alternatieven gebruiken, zoals address lookup tables en transactiebundels.

Solana kan niet-gerelateerde transacties parallel verwerken, zoals beschreven in deze gids over de werking van Solana. V1 verandert dat uitvoeringsmodel niet. Het biedt in plaats daarvan extra ruimte wanneer één handeling meerdere samenhangende onderdelen moet bevatten.

Wanneer die instructies als één atomische transactie worden ingediend, worden ze als één geheel verwerkt. De volledige handeling slaagt of de wijzigingen worden teruggedraaid. Zo wordt voorkomen dat slechts enkele instructies het ledger bereiken.

Handelingen die kunnen profiteren van extra ruimte

• Gebundelde transacties: Een handelsapplicatie kan samenhangende instructies in één transactie plaatsen in plaats van meerdere bevestigingen te coördineren.
• Grote multisig-goedkeuringen: Treasury- en bedrijfswallets kunnen meer handtekeningen en accountinformatie verwerken wanneer meerdere personen een handeling moeten autoriseren.
• Zero-knowledge proofs: Applicaties kunnen aantonen dat aan een voorwaarde is voldaan zonder alle onderliggende informatie openbaar te maken, maar het bewijs zelf kan veel transactieruimte vereisen.
• On-chain-handtekeningschema’s: Sommige cryptografische handtekeningsformaten genereerden eerder meer data dan in één Solana-transactie paste.

De Solana Foundation noemt vertrouwelijke overboekingen, geneste multisigs, gebundelde handelingen en bepaalde on-chain-handtekeningschema’s als mogelijke toepassingen voor het nieuwe formaat.

De meeste walletgebruikers hoeven niets te doen

Door de activering hoeven gebruikers hun SOL niet te verplaatsen, geen ander adres aan te maken en geen bestaand account om te zetten. Applicaties die legacy- of V0-transacties blijven gebruiken, zouden moeten functioneren zoals vóór de upgrade.

Gebruikers hebben een compatibele wallet nodig wanneer een applicatie ervoor kiest een V1-transactie te versturen. Door walletsoftware bijgewerkt te houden, komt die ondersteuning beschikbaar zodra aanbieders deze introduceren. Een applicatie moet de compatibiliteit echter nog steeds controleren voordat zij een wallet vraagt een transactie te ondertekenen.

Voor gebruikers kan de verandering uiteindelijk zichtbaar worden als minder goedkeuringsverzoeken voor complexe handelingen. Een dienst die eerder meerdere samenhangende transacties nodig had, kan dan één verzoek tonen en op één bevestiging wachten.

Ontwikkelaars en indexers moeten hun software bijwerken

Het versturen van V1-transacties is optioneel, maar het uitlezen ervan kan compatibiliteitsproblemen veroorzaken voor infrastructuur die niet is bijgewerkt.

RPC-diensten die transacties of blocks ophalen, moeten maxSupportedTransactionVersion: 1 instellen. Zonder die instelling kan een verzoek om een V1-transactie een fout opleveren. Ook kan één niet-ondersteunde transactie ervoor zorgen dat een verzoek om een volledig block mislukt.

Indexers lopen een ander risico. V1 slaat de compute-limiet, de limiet voor geladen accountdata en de prioriteitsvergoeding op in transactionConfig in plaats van in Compute Budget-instructies. Software die de oude locatie blijft uitlezen, kan de transactie verkeerd classificeren of de resource-limieten en prioriteitsvergoeding als nul rapporteren.

Applicaties die V1-transacties aanmaken, moeten hun limieten voor compute units en geladen accountdata expliciet instellen. Beide waarden staan in het nieuwe formaat standaard op nul. Als ze worden weggelaten, kan de transactie vóór uitvoering mislukken.

Transacties groter dan 1.232 bytes moeten ook met base64-codering worden ingediend. Het base58-indieningspad behoudt de eerdere maximale omvang.

V1 biedt meer ruimte, maar verandert andere limieten

V1 is niet simpelweg V0 met een grotere payload. Het kan maximaal 64 accountadressen rechtstreeks in de transactie opnemen, maar ondersteunt geen address lookup tables. Dubbele accountadressen worden eveneens geweigerd.

Die regels leiden tot een andere ontwerpkeuze voor applicatieteams. V0 blijft nuttig wanneer lookup tables een efficiënte manier bieden om naar accounts te verwijzen, terwijl V1 bedoeld is voor handelingen die meer profiteren van extra ruimte voor instructies, handtekeningen of bewijzen.

Een eenvoudige betaling zal waarschijnlijk niets winnen met het nieuwe formaat. V1 is geschikter voor applicaties die een complexe reeks kunnen vervangen of data kunnen verwerken die eerder helemaal niet in één transactie paste.

Grotere transacties kunnen hogere kosten met zich meebrengen

Het verhogen van de byte-limiet maakt niet automatisch elke V1-transactie duurder. De kosten hangen af van de aangevraagde resources, het aantal handtekeningen en de door de applicatie gekozen prioriteitsvergoeding.

Grotere berichten gebruiken wel meer bandbreedte van validators. Volgens de documentatie van Solana zal de scheduler naar verwachting een hogere prioriteitsvergoeding vereisen voor een grotere transactie dan voor een kleinere transactie die dezelfde prioriteit nastreeft, vooral wanneer blockspace schaars is.

V1 drukt de prioriteitsvergoeding uit als een totaalbedrag in lamports. V0 gebruikt een prijs per compute unit. Daarom moeten analyseplatforms beide formaten normaliseren voordat ze ze vergelijken.

De vraag naar prioriteitsvergoedingen kan sterk veranderen door netwerkactiviteit, zoals blijkt uit de recente feegegevens van Solana. Ontwikkelaars zullen daarom het gemak van één grotere handeling moeten afwegen tegen de kosten om deze tijdens drukke periodes opgenomen te krijgen.

Activering luidt de adoptietest in

De upgrade neemt een beperking weg die eerder bepaalde hoe Solana-applicaties werden gebouwd, maar activering op het mainnet garandeert geen brede toepassing. Wallets, RPC-aanbieders, indexers en applicatiebibliotheken moeten het nieuwe formaat correct verwerken voordat ontwikkelaars erop kunnen vertrouwen in producten voor eindgebruikers.

De eerste voordelen kunnen zichtbaar worden bij workloads die al moeite hebben met de eerdere limiet, waaronder vertrouwelijke overboekingen, institutionele multisig-constructies en applicaties met veel instructies. Voor gewone overboekingen blijven de bestaande formaten de eenvoudigere optie.

Het belang van V1 zal afhangen van de vraag of het onderbrengen van deze workloads in één atomische transactie voldoende besparingen oplevert op het gebied van coördinatie, handtekeningen en mislukte pogingen om de benodigde infrastructuurupdates te rechtvaardigen.

Dit artikel is uitsluitend bedoeld ter informatie en vormt geen financieel of beleggingsadvies. Compatibiliteit van wallets, ondersteuning door applicaties en transactiekosten kunnen veranderen.

Bron: Coindoo