Solana zou zich volgens berichten voorbereiden om de maximale grootte van één netwerktransactie te verdrievoudigen, een wijziging van de transactielimiet van de blockchain die applicaties meer ruimte zou geven om complexe transacties in één transactie te verpakken. Volgens berichtgeving over de geplande upgrade betreft de wijziging de hoeveelheid data die één transactie kan bevatten. De exacte bytelimieten, de status van het voorstel en de activeringstijdlijn zijn niet bevestigd.

Wat de vergroting van de transactiegrootte zou veranderen

De wijziging betreft hoe groot een individuele Solana-transactie kan zijn, gemeten in bytes — niet hoeveel transacties het netwerk per seconde verwerkt. Het verdrievoudigen van die limiet zou de hoeveelheid instructie- en accountdata die één transactie kan bevatten verhogen.

De beschikbare berichtgeving vermeldt niet de huidige bytelimiet, de voorgestelde nieuwe waarde of een identificatiecode voor het voorstel, zodat precieze oude en nieuwe cijfers niet kunnen worden gegeven. Solana-netwerkparameters worden doorgaans gewijzigd via het Solana Improvement Documents-proces, waarvan de open voorstellen publiekelijk worden bijgehouden.

Het is belangrijk een groter transactieformaat te onderscheiden van hogere doorvoercapaciteit. Het verdrievoudigen van de transactiegrootte is iets anders dan het verhogen van de doorvoer, executiecapaciteit of blokcapaciteit. Een groter formaat verhoogt op zichzelf niet het aantal transacties per seconde of de compute-unit-budgetten; het verandert alleen hoeveel data in één transactie kan worden gecodeerd. Voor lezers die protocolwijzigingen in verschillende ecosystemen volgen, behoort dit soort parameterafstemming tot breder werk aan netwerkcapaciteit op smart-contract-blockchains — bijvoorbeeld Ethereums historische gebruik van blokgaslimieten en calldata-prijzen om te bepalen hoeveel data transacties verbruiken — al stelt en beheert elke blockchain dergelijke parameters op eigen wijze.

Hoe grotere transacties complexere transacties zouden kunnen ondersteunen

Een groter transactieformaat zou in beginsel een applicatie in staat stellen meer transactiegerelateerde instructies of accountreferenties in één transactie onder te brengen, afhankelijk van het uiteindelijke ontwerp van de wijziging. Dit is het praktische voordeel dat de berichtgeving aan de vergroting verbindt, hoewel er geen specifieke applicatie, benchmark of verklaring van ontwikkelaars is gegeven.

Als hypothese zou een meerstaps-swap of een bundel van gecombineerde transactieoperaties die momenteel gesplitst moet worden over meerdere transacties, mogelijk in één transactie kunnen passen. Dit is relevant voor samenstelbaarheid: wanneer verwante operaties over afzonderlijke transacties gesplitst moeten worden, kunnen ze onafhankelijk van elkaar mislukken, een lang bestaand pijnpunt voor complexe on-chain-workflows. Dit blijft puur illustratief; er is geen bevestigde workflow aangetoond. Solana draagt al zware transactierouteringsactiviteit via platformen zoals Raydium en Jupiter — het soort applicaties dat een groter transactieformaat het meest direct zou beïnvloeden.

Andere limieten op transactiecomplexiteit

De transactiegrootte is slechts één beperking van wat een transactie kan doen. Executielimieten zoals compute-unit-budgetten en regels voor accounttoegang begrenzen eveneens hoe complex een transactie kan zijn, en de berichtgeving vermeldt niet of die limieten samen met de vergroting zouden veranderen.

De wijziging mag niet worden opgevat als een belofte van lagere kosten, betere prijzen of minder slippage; geen van die effecten wordt ondersteund door het beschikbare bewijsmateriaal.

Wat nog bevestigd moet worden over de uitrol

Er is geen tijdlijn, activeringsvoorwaarden, client-release of mainnet-bevestiging gegeven voor de wijziging. De technische specificatie, de status van het voorstel, de implementatieomvang en de activeringsdatum zijn allemaal nog niet geverifieerd.

Ook is onbevestigd of applicatietooling of code voor transactieconstructie aangepast moet worden om een groter formaat te gebruiken, en er zijn geen gemeten prestatie- of resource-afwegingen beschikbaar. Zolang er geen specifiek voorstel en geen client-release zijn geïdentificeerd, beschrijft de melding een gemeld plan in plaats van een uitgerolde upgrade.