Vitalik Buterin stelt voor de kosten van kwantumveilige privacy op Ethereum met meer dan 99% te verlagen
Belangrijkste punten
- •EIP-8288 is in juni opgesteld door Vitalik Buterin en Thomas Coratger.
- •Het voorstel zou transactieclaims combineren in een recursief STARK-bewijs dat elk Ethereum-blok dekt.
- •Volgens Buterin kunnen de kosten van kwantumveilige privétransacties dalen van ongeveer 10 miljoen gas naar tienduizenden gas.
- •RISC-V wordt overwogen als de gemeenschappelijke instructieset voor het recursieve bewijssysteem van Ethereum.
- •EIP-8288 is afhankelijk van de nog niet geplande Frames-herziening en geen van beide voorstellen is aan een fork toegewezen.

Medeoprichter van Ethereum Vitalik Buterin steunt een voorstel dat de kosten van kwantumveilige privétransacties in een toekomstige netwerkupgrade met meer dan 99% zou kunnen verlagen.
EIP-8288, dat Buterin in juni samen met Thomas Coratger heeft opgesteld, zou kwantumbestendige handtekeningen en STARK-bewijzen bundelen in één bewijs voor elk Ethereum-blok. Het conceptvoorstel zou het zwaarste cryptografische werk buiten het uitvoeringspad van het netwerk plaatsen.
Post-kwantumhandtekeningen zijn momenteel ongeveer 2 tot 3 kilobytes groot en kosten tussen 150.000 en 200.000 gas om te verifiëren. STARK-bewijzen zijn groter: ze zijn meer dan 128 kilobytes groot en kunnen bij snelle generatie oplopen tot 512 kilobytes, waardoor de verificatiekosten in de miljoenen gas uitkomen.
Buterin zei dat een goed ontworpen privétransactie momenteel ongeveer 300.000 gas kost, terwijl de kosten oplopen tot ongeveer 10 miljoen gas wanneer deze kwantumveilig moet zijn. Onder EIP-8288 zouden beide varianten volgens hem slechts tienduizenden gas kunnen kosten.
Het voorstel wordt beschreven in de EIP-8288-specificatie. Buterin besprak het ook in een bericht op X:
A note on recursive STARK mempools (EIP-8288) This is an EIP that I am hoping we can get included in I-star (the fork after Hegota) that you can think of as the next step after Frames, that would unlock extreme amounts of power. Particularly: *… — vitalik.eth (@VitalikButerin) September 9, 2026
Het ontwerp zou voorkomen dat de cryptografische bewerkingen rechtstreeks on-chain worden uitgevoerd. In plaats daarvan zou elke transactie een “dependency” verklaren: een korte claim dat een bericht door een bepaalde sleutel is ondertekend of dat gegevens aan een bewijs voldoen. Elke dependency zou 96 bytes kosten.
Mempoolnodes zouden de claims elke seconde verzamelen, één recursief STARK-bewijs genereren waarin ze allemaal samen worden bewezen, en dat bewijs doorgeven. Elk blok zou vervolgens één bewijs bevatten dat alle transacties in het blok dekt. Buterins oorspronkelijke bericht op X is beschikbaar via https://twitter.com/VitalikButerin/status/2097711433073172837.
RISC-V als gemeenschappelijke taal
Recursieve bewijzen hebben een gemeenschappelijke taal nodig om beweringen uit te drukken. De belangrijkste kandidaat is RISC-V, een open instructieset die wordt gebruikt bij chipontwerp. Door deze aan te nemen, zou RISC-V de feitelijke canonieke instructieset van Ethereum worden.
Buterin omschreef dat als een “big decision” die zorgvuldig moet worden benaderd, maar zei dat hij deze stap noodzakelijk acht. In juli opperde hij dezelfde mogelijkheid als onderdeel van een Lean Ethereum-roadmap die vrijwel elk belangrijk protocolonderdeel in drie of vier jaar zou herbouwen en recursieve STARKs centraal zou stellen.
Hij noemde ook private account abstraction als een andere mogelijke toepassing. Volgens die aanpak zou de logica van een account on-chain verborgen kunnen blijven, terwijl het eigendom van elke positie en elk bezit dat eraan is gekoppeld in één transactie wordt gewijzigd zonder prijs te geven om welke activa het gaat.
EIP-8288 is afhankelijk van Frames, de transactionele herziening die Buterin zondag promootte. Frames staat zelf nog niet op de planning. Buterin wil beide voorstellen opnemen in I-star, de upgrade na Hegota, waarvan hij heeft gezegd dat dit de laatste Ethereum-upgrade vóór het begin van het Lean-tijdperk zou zijn. Geen van beide voorstellen is aan een fork toegewezen.