EIP-8288: In-mempool recursive STARK aggregation | Vitalik Buterin | ETHTaipei 2026

[music] Great. So, hope everyone had a good lunch. Who here did not have a good lunch? Okay, good. Um so [snorts] I um I mentioned uh briefly this morning about E um EIP um 8288 and uh some of the connection between how Ethereum is going to be uh integrating a lot of uh advanced cryptography and especially zero knowledge proofs to become much more scalable and much more private.

Um so today I wanted or here I wanted to talk about one of the like specific ways in which uh I hope that this will happen. Um so um 8288 this is an EIP it's uh it's written um you can check it out yourself at eip.ethereum.org8288 /ip-8288. Um, and uh, what it does is uh, inme recursive stark aggregation.

And so I'll go through like both I mean like how this works and in particular like what it means for scalability, for privacy, for postquantum security, and for Ethereum's ability to have all three of those at the same time. So let's talk about some problems. So first of all, quantum safe signatures are big and expensive. So who here knows how much gas it costs to independently verify one ECDSA signature on Ethereum? If anyone knows the number, shout it out.

So the gas cost in the pre-ompile is 3,000. Um also you have to pay call data costs. call data for ECDSA signature is 65 bytes. Um and uh in Gamster Dam I think the gas cost per bite is going to be increased and so actually yeah the the data itself will cost another 4,000 so maybe 7,000. Now what about a quantum safe signature?

Now we have uh recently been working very aggressively to reduce the gas cost of hashbased signatures and so uh we have sphinx minus which is basically an adaptation of uh a lot of uh ideas from hashbased signature theory and like to try to choosing some optimal parameters uh to make it really work with for the Ethereum context and be maximally efficient. the gas cost um is uh somewhere around 150,000. Now it depends like it can go as low as 100, it can go as high as like 200 or 300. The trade-off is basically how much do you care about cheap onchain verification versus how much do you care about signing being possible to do like for example in a hardware wallet. Now 150,000 gas is a lot of gas.

So a basic ETH send on Ethereum costs 21,000 gas. We do not want basic operations on Ethereum to in to go up from being 21,000 gas to being 170,000 gas. So this is the first problem. Second problem, privacy protocol proofs are big and expensive. Um, who here um in the last year has made a withdrawal from either tornado cache or rail gun or privacy pools?

Nice. Um, who here has used at least two of those? All three. Okay. So, you probably remember how much gas it cost you.

Or if you don't remember the gas number, you'll remember the transaction fee. Last time I uh paid a uh uh I withdrew from a privacy protocol, the uh the transaction fee was about $10. It actually goes up and down. Sometimes it takes about 50, sometimes it's about $10. Back in uh 2021 uh when many when there was a high volume of usage, the highest fee I ever paid to do a private withdrawal was $800.

Why? because uh the by the most efficient privacy protocol withdrawal you can possibly get if you optimize very hard is about 350,000 gas. The [snorts] privacy protocols you use today do not optimize very hard and so it often costs 1 million gas. So that's the second problem. The third problem quantum safe privacy protocol proofs are prohibitively being big being big inexpensive.

So a stark is between 100 and 300 kilobytes. Let's call it 100 kilobytes if you make the client do more work. If [snorts] it's 100 kilobytes then multiply by 64 gas per bite. The cost is going to be 6.4 million gas um on chain.

So basically if everyone becomes private and quantum safe, Ethereum as it exists today will be able to do like less than one half of a TPS. So this is a problem. Now another problem everyone loves trying to go on ECD and convince Ethereum to adopt their favorite signature scheme, right? Sometimes it's pass keys, sometimes it's eddsa curve 25519. Sometimes it's a new BLS curve.

Sometimes it's a different BLS curve. Sometimes it's ML CAM, sometime MLDDSA, sometimes it's Falcon. The problem is that like if you try to support all of this, then the protocol will just become extremely bloated, right? If you don't then all of these things would if you try to implement them with raw EVM they will cost a huge amount of gas also millions of gas. So these are four problems and I will argue that uh EIP8288 can solve all four of them.

So here is the solution. Instead of putting all of these complicated signatures and proofs on chain, what we're going to do is we're going to aggregate all of them on chain and replace all of the objects that users send with a single proof. So every block will have one single proof. And the one single proof will replace every signature, every snark made with uh made to be um A288 compatible and replace them all with one single object that attests that all of the statements that are being that um that are being included are true. So users from the user side, they will send a transaction and that transaction will come with a signature and a stark that goes into the meool.

In the me poolool nodes aggregate so they prove that there um that there exist these signatures and starks and it all gets aggregated down to one proof that gets created by the block builder that goes into a block. So the way that this is implemented is uh there is a new frame type for dependencies. So this builds on top of EAP 8141 which is uh likely to go into harst star and uh each the way that it works is that um each in each frame of this type there um it expects 96 bytes. Actually it can be 96* k bytes. You can have multiple dependencies in one dependency frame.

And each 90 96 bytes contains three objects. there is a scheme and right now there's just two schemes uh basically either it's a either it's a lean sphinx uh signature or so um or it's a lean stark then you have a message hash or a data hash and then you have a sonark public key hash or a stark verification hash and there's two different things that this could represent if the scheme is 10 then uh basically it says there exists a signature of m that verifies So of the message hash that verifies against the public key hash. If it's if the scheme is 11, then there exists a proof that verifies against the public uh the public input again with a statement that's defined by a verification key whose hash is the is the verification hash. So a dependency frame basically just says here is a statement that I am asserting um and somewhere else there is a proof of it. Um and uh there is a single block a blockwide stark that is asserting to the existence of valid signatures and valid proofs for all of these statements.

Now this is a uh somewhat different way of uh doing uh development right because you're not doing verification directly inside of the EVM. You're not kind of inlining everything. What you're just saying is you're splitting up the computation and you're saying here is one part of a of a computation that assumes the signature is valid. It assumes the proof is valid. It assumes everything is fine.

And [snorts] then there is a separate part of the computation which actually checks that the signatures and the proofs exist. And we're taking the second part and we're just replacing it with one big proof. So the way that this works in the meool is basically every node in the me pool is running the same algorithm. So a node is uh watching and it's accepting incoming um uh objects. Well, we call them envelopes.

So every node in the memp pool it waits it accepts for some incoming envelopes and then every tick about every half second it it outputs a me an envelope and the envelope that it outputs contains every transaction that it saw plus one single proof that verifies that every transaction has a proof of it. So there is proof recursion going on. There's a you have proofs that are coming in and then you have a proof of all of the proofs coming out. And so if you trace this through and you ask the question well what is the overhead of all of this you will notice that you have the transactions same same that we have now the overhead is the starks and every node is outputting one single stark every tick. So in this case 100 to 300 kilobytes maybe every half second.

This is completely viable with modern internet connections right. So the overhead is actually very manageable and it does not go up with the uh amount with the amount of volume. The main cost here is basically that nodes have to do a lot of aggregation and this is something that is already being heavily optimized as part of the Yen Ethereum effort because we need the exact same technology to have an efficient quantum secure consensus layer. So this basically every single node in the mele does this. It accepts transactions.

It accepts envelopes. It outputs envelopes. Those envelopes have proofs. And so there [snorts] because of those proofs, every node at every step is confident that all of the dependencies in the transactions are correct and it has a proof that they're correct. But the original signatures, the original proofs, they don't even make it past the first node.

So how do we think about this? I think there's a few different kind of ways to think about what 8288 is doing. So one of the ways to think about it is this is hyperscaling computation. It's also hypers scaling data. So it is like sharding but it's a specialized kind of sharding.

It's sharding for the specific case where you have a computation that's only interacting with the rest of Ethereum by verifying a claim. So you have one big blob. The blob would normally cost a million gas to verify and all that that big blob is there is to prove something. If that's what you have then you replace it with a proof and then the meool replaces everybody's proof with one proofs with one single proof. One other interesting thing that this is doing is uh with the stark proof system this is also like a big step of uh introducing a new VM to Ethereum.

Right. So, so far the only VM that Ethereum recognizes is the EVM. And here this is saying this is actually directly enshrining some kind of language that these proofs are written in into Ethereum. And currently the leading contender is risk 5. So this is um so it's a big step for Ethereum in this sense as well.

you know, we I've been talking about uh adding risk five or adding something similar for at least I think the past two years now. This is likely to be the first way in which it happens. Also, this is uh we're starting to make do some much more explicit separation of computation into two kinds of computation, right? So you have what I call depend um business logic which is basically you know if this then that if you like in a multi-IG wallet you know if you have two valid signatures you're allowed to send the money and then you have dependencies which are actually verifying the signatures. So right now from the Ethereum protocols point of view all of those things are just one big blob.

Here we're saying well no users have to declare this is business logic this is dependencies and the benefit that you get is basically that dependencies become hypers scaled and then the remaining business logic becomes lighter. It becomes cleaner and so it actually even allows the ordering dependent parts of distributed block building to become easier. So these are kind of some of the some of the ways to think about what's happening what is happening here right but uh you like what is of really going on at a high level right what's going on is basically that this is a particular form of of hyperscaling Ethereum of making it much much cheaper to do the things that we care about a lot that are at the same time extremely expensive. Right. 10 times more expensive.

With 8288, becoming quantum safe becomes even cheaper than today. Why? Because the signatures are not going off chain. The signatures do not make it anywhere later than the first meool node. And as soon as the signatures make it into the meool, the mempool aggregates them and it replaces all of them with one big proof.

Today we care about privacy. The problem is being private is expensive. With 8288 being private will be cheap. Being private may be cheaper than not being private is today. Again, why?

Because the private the the ZK snarks do not have to go on chain. Instead, the zk snark only makes it to the first meool node and then from that point forward it gets aggregated. So [snorts] anything that you wants to do that's extremely gas expensive today it will become like there will be ways to make it much cheaper right so and the way that this is happening is basically while we're saying instead of trying to just scale all of Ethereum at the same time we're going to figure out the parts of Ethereum that both need scaling the most and that have special properties that make them easier to scale And uh the easiest thing to scale is actually signatures and proofs and uh sharding the verification charting the data is uh exactly what EIP8 um EIP8288 is doing. Another thing you notice is that the developer experience here is changing right and uh here one way that I think about this is that Ethereum is sort of becoming a little bit more like Bitcoin, right? So if you look at what a Bitcoin transaction does, a Bitcoin transaction, it like it contains a bunch of inputs, right?

And every input is saying this has to be true, this has to exist, this has to be unspent, this like you need this kind of signature. And so in Bitcoin, every transaction is a dependency. everything is kind of very statically typed like you you don't have any dynamic object where there's some address that you can compute and then modify the address and this is very restrictive in terms of like computational power but it's also good for scalability and so we're starting to do here is we're starting to say well let's make Ethereum a little bit more statically typed let's make Ethereum a little bit more of an environment where you have to declare what type of computation your computation is. And then the benefit that you get is if it's a type of computation that's easy to scale, then you get much more scaling. It becomes extremely cheap.

um you can save a lot of gas and Ethereum should be able to uh process um by the time this comes in hundreds of private TPS almost at the same time as it would be able to uh to process hundreds of non-private TPS. So this is uh something that I hope that we can see more work on implementing. There's already starting to be tests on proof recursion, a lot of research on proof recursion and hopefully this is a direction that we can um continue building and uh like actually uh [snorts] hopefully get live like very soon after we have account abstraction in Ethereum uh in Ethereum hopefully next year. So thank you. Thank you.

[applause] Thanks again. Uh so we have a few minutes for the Q&A.

So

any questions?

Uh which one do you can you design? Okay. Mhm.

Um I was wondering if uh my understanding of all the production stark systems

is that they are not 128 bits security yet.

So I'm curious like how you think about like

security for

these kinds of proofs like do you actually need 128?

Mhm. And also my understanding is that even they're not 128 now and even the

assumptions that they use it's like very maybe unlikely that we would get to 128 with the speeds that we need.

Yeah, I think a lot of that was completely true a year ago, but it's improved a lot especially in the last few months. I mean, Justin Drake has been like very insistent on kind of putting down the hammer and basically saying, you know, last year was the year of making proofs possible. This year is the year of kind of of cleaning up. And so I believe like we've already moved to a goal of having at least 120 bits of uh security. Um, and like it's probably too much effort to try to go sometimes from 120 to 128 because uh, you know, it's always kind of half the width of the hash and then like divided by n or square root of n and uh, kind of 120 is enough, right?

Um, and but then there one of the big gaps has been this whole kind of conjecture versus provable thing and there has been some work on narrowing that gap recently. actually that's what the one of the AI contests um is that I talked about earlier and also Justin has been insistent that anything that's admissible right now it has to be provable so that's uh two and [snorts] then in terms of uh kind of raw efficiency so lean VM recently kind of officially moved over to being based on Blake right so we uh switched over from Poseidon to Blake over the last kind of two or three months and uh there's work ongoing ongoing work on formally proving it. There's work on optimizing the recursion step. The recursion step can run in already in uh hundreds of milliseconds on a CPU. Um and so that's with you know 120 plus bit security with you know provable all of the uh all of the good parameters.

So it's uh so I think it's it's like there has been a really uh huge amounts of improvements on all of that especially over the last couple of months.

Yeah, I think it's

Thank you. So we can have one more question.

Yeah,

I just wanted to you touched on that the developer experience would be different

and I'm just imagining what it would be like as putting in some of my contracts. So

Mhm. I've put like snarks and in my contracts and

from what I understand it's

you're putting you would still have to put all the call data in that and you would have to

okay here so let's like go through an example right so let's say for example you're writing a privacy protocol right like you know you have something like rail gun today the user's transaction is and let's like temporarily you know like assume we have frames to like forget about like abstraction wpping and so on right so Today you [snorts] would have the synarch so which is you know today about like 500 to a,000 bytes and then postquantum it's like 300 kilobytes that's part of call data and then you have EVM code that is running as part of you know like Ethereum's main loop in frames it would be part of the verification phase and uh and so like it would be call data of the verify frame um and uh you would like it would basically just you know like be run as part of main execution right so that's kind of like today or very soon with 8288 what would happen is you would take you would have two frames. So you would take the uh so any statement that you're proving right on chain there's always like a verification key and then you have the like the h the hash of the public params right and what you would do is you would take the verification key and the public params and you would put that into this into this dependency frame and [snorts] then you would also have a verify frame and then the verify frame instead of doing the verification all that it would do is it would use a kind of cross frame introspection op code like dx paramm or frame perm and it would basically check for the existence of the dependency frame. So the verify frame all it does is it verifies that the dependency frame exists. Now when you send when a user sends a transaction the transaction would be wrapped in a uh kind of a meool layer object that's called an envelope wi where you have the transaction and then separately you would have the stark that verifies like basically the statement that's in the dependency frame for a node to accept it like nodes in a memp pool they will not accept raw uh transactions that contain dependency frames they accept transactions that contain dependency frames. names only inside of an envelope.

And so a node in a memp pool, they would see your transaction in an envelope and then in the envelope the transaction would be like a few hundred bytes and then the snark would be yeah like 200 kilobytes and then they would verify this the snark and then they would like replace it with an aggregated proof and then your transaction fully makes it on chain but then the stark gets replaced with a yeah recursive stark. So you're basically fully separating out kind of the statement that you're proving from the proving logic and then the proving logic gets verified and aggregated through a completely separate channel.

I see. Okay. I think from an RPC perspective it's not going to be that different. Uh basically uh like to generate a proof right you need you need some private information you know you need and then the there's like information you have to grab about like the deposit route and the Merkel tree and all of the things that happen already right and then uh from [snorts] and then to generate one of these transa like the data that you need to generate a transaction is basically the same as the data that you need to generate a transaction today and [snorts] then you broadcast and you broadcast into the meool and or potentially you could broadcast to an RPC node. An RPC node would be part of this meool.

Um and then from there you don't care. It would be aggregated. Um and then when it gets included on chain probably the biggest difference that you see is that like the thing included on chain is not going to include your envelope, right? The thing included on chain is just the raw transaction. And so you're not going to be able to see your own proof.

You're just going to be able to see the proof of everyone's proof.

All right. So we are running out of time. So thank you Vitalik for sharing the insights on EIPA2A.