Ethereum-medoprichter Vitalik Buterin heeft een voorgesteld transactieontwerp uiteengezet dat de voorwaarden die nodig zijn om een transactie te valideren zou loskoppelen van de acties die uiteindelijk op het netwerk worden uitgevoerd, waardoor Ethereum validatiewerk mogelijk efficiënter zou kunnen verwerken.

Het voorstel put uit verschillende onderzoekslijnen binnen Ethereum, waaronder EIP-8141, keyed nonces, alternatieve state-ontwerpen en recursieve STARK-gebaseerde mempools. Buterins onderzoek onderscheidt transactieacties, die veranderingen op Ethereum teweegbrengen, van afhankelijkheden, die opgelost moeten worden voordat die acties veilig kunnen worden uitgevoerd.

Onder het voorgestelde model zou deze scheiding het mogelijk maken verschillende onderdelen van transactieverwerking onafhankelijk af te handelen, in plaats van te vereisen dat validatie en uitvoering nauw verbonden blijven.

Transactieontwerp zou parallelle validatie mogelijk kunnen maken

Acties beschrijven de effecten die een transactie genereert, zoals het overmaken van tokens, het bijwerken van accounts of het interacteren met smart contracts. Afhankelijkheden daarentegen vertegenwoordigen de voorwaarden die vastgesteld moeten zijn voordat die acties kunnen plaatsvinden.

De bestaande transactiestroom van Ethereum koppelt deze validatievereisten aan de uitvoering: knopen (nodes) ontvangen transacties, controleren of aan hun vereisten is voldaan en verwerken vervolgens de gevraagde bewerkingen.

Buterins voorstel suggereert dat veel afhankelijkheden juist onafhankelijk afgehandeld kunnen worden, omdat ze niet per se dezelfde kenmerken delen als de acties zelf.

Sommige afhankelijkheden steunen op informatie in de state van Ethereum, terwijl anderen geëvalueerd kunnen worden zonder toegang tot de netwerkstate. De laatste categorie, beschreven als pure afhankelijkheden, zou mogelijk al geverifieerd kunnen worden voordat een transactie in een blok wordt opgenomen.

Door dit werk naar de mempool te verplaatsen kan de hoeveelheid validatie die knopen tijdens de blokuitvoering moeten herhalen worden verminderd. Het zou bovendien meerdere afhankelijkheden gelijktijdig laten controleren, in plaats van dat elke voorwaarde sequentieel verwerkt moet worden.

Dat onderscheid kan steeds relevanter worden naarmate Ethereum-transacties complexer worden en geavanceerdere autorisatie- en uitvoeringslogica vereisen. Parallelle uitvoering en verbeterde validatiedoorvoer zijn terugkerende thema's in de schaalbaarheidsroadmap van Ethereum, die de nadruk legt op het vergroten van de transactiecapaciteit van het netwerk door een combinatie van layer-2-rollups en verbeteringen op de basislaag.

Recursieve STARK's en accountabstrakcie maken deel uit van het voorstel

Recursieve STARK-technologie is een ander onderdeel van het concept. Meerdere voltooide verificatiecontroles zouden mogelijk kunnen worden samengevoegd in één cryptografisch bewijs, zodat validators een geaggregeerd resultaat kunnen verifiëren in plaats van elke onderliggende berekening afzonderlijk te herhalen. Op STARK's gebaseerde bewijssystemen worden al elders in het Ethereum-ecosysteem gebruikt, onder andere in zero-knowledge-rollups, waar ze berekeningen comprimeren tot beknopte bewijzen.

De voorgestelde architectuur sluit ook aan op het bredere onderzoek naar accountabstrakcie binnen Ethereum. EIP-8141 onderzoekt transactieformaten die flexibelere autorisatie- en uitvoeringsmechanismen ondersteunen, terwijl keyed nonces meer flexibiliteit kunnen bieden in de volgorde van transacties van individuele accounts. Accountabstrakcie is op Ethereum geleidelijk gevorderd door eerdere initiatieven zoals ERC-4337, dat een alternatieve mempool en smart-contract-accounts introduceerde, en EIP-7702, waarmee extern owned accounts tijdelijk functionaliteit van smart contracts kunnen aannemen.

Traditionele Ethereum-nonces dwingen transacties van hetzelfde account doorgaans in een sequentiële volgorde. Als gevolg daarvan kan een vertraagde transactie verhinderen dat volgende transacties naar bedoeling worden verwerkt.

Keyed nonces zouden afzonderlijke transactiereeksen binnen één account creëren, waardoor ongerelateerde bewerkingen onafhankelijk kunnen doorgaan in plaats van te worden opgehouden door een eerdere transactie.

Alternatieve state-ontwerpen kunnen verder veranderen hoe Ethereum transactie-informatie organiseert en bepaalt welke voorwaarden gevalideerd moeten worden.

Samen genomen wijzen deze benaderingen naar een modulairdere transactiearchitectuur waarin intentie, autorisatie, afhankelijkheidsverificatie en uitvoering als afzonderlijke componenten kunnen worden afgehandeld.

Voorstel blijft een ontwikkelend onderzoeksoncept

Het transactiemodel blijft een ontwikkelend concept in plaats van een bevestigde netwerkupgrade van Ethereum. De implementatie zou verder werk vergen om te bepalen hoe de architectuur veilig kan worden ingezet en welke technische vereisen ze aan de infrastructuur van Ethereum zou stellen.

Als de aanpak praktisch blijkt, zou het loskoppelen van afhankelijkheden van acties mogelijkheden kunnen openen voor parallelle validatie, dubbele berekeningen kunnen verminderen en de transactieverwerking efficiënter kunnen maken.

Vooralsnog vertegenwoordigt het voorstel echter een gebied van lopend onderzoek. De mogelijke impact zal afhangen van verdere ontwikkeling, beveiligingsbeoordeling en het vermogen van Ethereum-ontwikkelaars om de onderliggende ideeën om te zetten in een werkbbaar netwerkontwerp. Net als bij eerdere Ethereum-verbetervoorstellen zou het concept door de openbare beoordelings- en standaardisatieprocedure van het ecosysteem moeten gaan voordat enig onderdeel de mainnet kan bereiken.

Bron: Hokanews