Great. So, hope everyone had a good lunch. Who here did not have a good lunch? Okay, good. So I mentioned briefly this morning about EIP-8288 and some of the connection between how Ethereum is going to be integrating a lot of advanced cryptography and especially zero-knowledge proofs to become much more scalable and much more private. So today I wanted, or here I wanted to talk about one of the specific ways in which I hope that this will happen. So 8288, this is an EIP. It's written. You can check it out yourself at eip.ethereum.org/8288.
And what it does is in-mempool recursive STARK aggregation. And so I'll go through both how this works and, in particular, what it means for scalability, for privacy, for post-quantum 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 precompile is 3,000. Also you have to pay call data costs. Call data for an ECDSA signature is 65 bytes. And in Geth, I think the gas cost per byte is going to be increased, and so actually, yeah, the data itself will cost another 4,000, so maybe 7,000. Now what about a quantum-safe signature? Now we have recently been working very aggressively to reduce the gas cost of hash-based signatures, and so we have SPHINCS-, which is basically an adaptation of a lot of ideas from hash-based signature theory, and trying to choose some optimal parameters to make it really work for the Ethereum context and be maximally efficient. The gas cost is somewhere around 150,000. Now it depends, like it can go as low as 100,000, it can go as high as like 200,000 or 300,000. The trade-off is basically how much do you care about cheap on-chain 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 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. Who here in the last year has made a withdrawal from either Tornado Cash or Railgun or privacy pools? Nice. 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 paid, I withdrew from a privacy protocol, the transaction fee was about $10. It actually goes up and down. Sometimes it takes about 50, sometimes it's about $10. Back in 2021, when there was a high volume of usage, the highest fee I ever paid to do a private withdrawal was $800. Why? Because the most efficient privacy protocol withdrawal you can possibly get, if you optimize very hard, is about 350,000 gas. The 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 big and expensive. So a STARK is between 100 and 300 kilobytes. Let's call it 100 kilobytes if you make the client do more work. If it's 100 kilobytes, then multiply by 64 gas per byte. The cost is going to be 6.4 million gas 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 EDCON and convince Ethereum to adopt their favorite signature scheme, right? Sometimes it's passkeys, sometimes it's EdDSA Curve25519. Sometimes it's a new BLS curve. Sometimes it's a different BLS curve. Sometimes it's ML-KEM, sometimes ML-DSA, sometimes it's Falcon. The problem is that 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, 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 EIP-8288 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 off-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 to be 8288-compatible, and replace them all with one single object that attests that all of the statements that are being included are true. So from the user side, they will send a transaction, and that transaction will come with a signature and a STARK that goes into the mempool. In the mempool, nodes aggregate, so they prove 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 there is a new frame type for dependencies. So this builds on top of EIP-8141, which is likely to go into Fusaka, and the way that it works is that in each frame of this type, it expects 96 bytes. Actually it can be 96*k bytes. You can have multiple dependencies in one dependency frame. And each 96 bytes contains three objects. There is a scheme, and right now there's just two schemes. Basically either it's a lean SPHINCS- signature or it's a lean STARK. Then you have a message hash or a data hash, and then you have a SNARK public key hash or a STARK verification hash. And there's two different things that this could represent. If the scheme is 10, then basically it says there exists a signature of the message hash that verifies against the public key hash. If the scheme is 11, then there exists a proof that verifies against the public input, again with a statement that's defined by a verification key whose hash is the verification hash. So a dependency frame basically just says here is a statement that I am asserting, and somewhere else there is a proof of it. And there is a single block-wide STARK that is asserting the existence of valid signatures and valid proofs for all of these statements.
Now this is a somewhat different way of doing 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 computation that assumes the signature is valid. It assumes the proof is valid. It assumes everything is fine. And 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 mempool is basically every node in the mempool is running the same algorithm. So a node is watching and it's accepting incoming objects. Well, we call them envelopes. So every node in the mempool, it waits, it accepts for some incoming envelopes, and then every tick, about every half second, it outputs 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. 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 as 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 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 Verge Ethereum effort, because we need the exact same technology to have an efficient quantum-secure consensus layer.
So basically every single node in the mempool does this. It accepts transactions. It accepts envelopes. It outputs envelopes. Those envelopes have proofs. And so 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 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 hyperscaling 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 big blob is there is to prove something. If that's what you have, then you replace it with a proof, and then the mempool replaces everybody's proofs with one single proof.
One other interesting thing that this is doing is with the STARK proof system, this is also like a big step of introducing a new VM to Ethereum. Right. 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 RISC-V. So this is a big step for Ethereum in this sense as well. I've been talking about adding RISC-V 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, we're starting to do some much more explicit separation of computation into two kinds of computation, right? So you have what I call business logic, which is basically, you know, if this then that. If you like in a multi-sig 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 protocol's 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 hyperscaled, 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 ways to think about what is happening here, right? But what is really going on at a high level, right? What's going on is basically that this is a particular form 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 mempool node. And as soon as the signatures make it into the mempool, 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 ZK-SNARKs do not have to go on-chain. Instead, the ZK-SNARK only makes it to the first mempool node, and then from that point forward it gets aggregated. So anything that you want to do that's extremely gas-expensive today, there will be ways to make it much cheaper, right? So 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 the easiest thing to scale is actually signatures and proofs, and sharding the verification, sharding the data is exactly what EIP-8288 is doing.
Another thing you notice is that the developer experience here is changing, right? And 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 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, you need this kind of signature. And so in Bitcoin, every transaction is a dependency. Everything is kind of very statically typed, like 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 computational power, but it's also good for scalability. And so what 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. You can save a lot of gas, and Ethereum should be able to process, by the time this comes in, hundreds of private TPS almost at the same time as it would be able to process hundreds of non-private TPS.
So this is 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 continue building and actually hopefully get live like very soon after we have account abstraction in Ethereum, hopefully next year. So thank you. Thank you. [applause]
