I realize that my presentation is a bit more technical than anything else you've heard today. Sorry for the scary title, but I promise that everything will become clear by the end of this report. So will become clear by the end of this report. So , before we start, raise your hands, how many of you are already working or have ever worked with zero- disclosure schemes? Perfectly.
And how many of you knew what a catch-up function was catch-up function was before Carty explained it? Perfectly. Okay, great. I promise that everything will be clear by the end. So, you may have heard that zero- disclosure cryptography is the future of Ethereum and blockchain scaling, but perhaps the details are a little fuzzy.
What exactly does this mean? In this talk, I will focus on, um, three aspects of it. One is, um, increasing transaction volume, and that's what Yeh from Axiom talked about on Monday. Currently, all Ethereum nodes, all, ahem, all validators, must re- execute transactions to ensure they were executed according to Ethereum rules. And that limits how much information we can add to these transactions.
Think about payment processors payment processors , this limits the number of payments they can process within a 12- process within a 12- second window. So the idea behind ZK-EVM is that if we can move to a world where a validator, an Ethereum node validator, an Ethereum node , can only verify a transaction, it doesn't have to re- execute it from scratch, then we can increase the throughput of the entire network. Another aspect of Ethereum's development, of our ecosystem's development, is to attract more institutional clients to the blockchain and ensure that they can operate safely from a regulatory perspective. And for this we need KYC (know your customer). But if you're anything like me, you're not going to upload your passport data to a public blockchain public blockchain .
That would be a bit silly. But you're probably perfectly fine with certifying that you're not from a sanctioned country, that you're perhaps an accredited investor, and just uploading a small piece of proof that doesn't reveal all of your personal details to the public blockchain public blockchain . So, this aspect of the chain can in some way increase the number of counterparties you can interact with in the chain. And then, as the volume of transactions increases, as the number of counterparties increases, the rates also grow higher and higher. Therefore, we may implement some kind of credit scoring or risk scoring to be able to make sure that the counterparties we interact with are good value for their money.
Maybe they don't want to reveal all their positions, all their strategies, but still convince us that they have funds somewhere if something goes wrong. So we can use ZKP, zero- knowledge proofs, for all these aspects of scaling our ecosystem. However, there is a small obstacle in all this, and it is called Keccak. Keccak is a hash function used by Ethereum and all EVM-based blockchains. It is used to record the state of the blockchain at any point in time.
So you can recognize these strange transaction hashes in block explorers. This is essentially a guarantee that everything under that hash remains unchanged. So, all account balances for this hash are already fixed and users cannot cheat and change them later. And Keccak is great because it's very fast on the CPU, and if you have a network node, like an Ethereum node like an Ethereum node , then, um, you need to commit as many transactions as possible on it, so you need that commit to be very, very fast on your CPU so that you can fit more transactions into one 12-second block one 12-second block . Unfortunately for us, Keccak is extremely difficult to prove in zero- disclosure schemes.
Um, it creates a bunch of overhead, but it's also too late to move on and replace it with something else. It already exists, we have already processed hundreds of thousands, if not millions of blocks. So we're not going to move away from it anytime soon anyway . So, our team set a goal to make Keccak work better in zero- disclosure schemes? How can we make it better for all the use cases I mentioned.
And the key insight here is that we almost never want to prove the hash of a single gadget. This doesn't really make sense to anyone. Instead, uh, we'll always be dealing with hundreds, if not thousands, of them, uh, and even the facts that we're trying to prove. And spoiler alert, we could exploit this fact, exploit the fact that we're dealing with tons of hashes at once, uh, and provide results that are much better than the current state of affairs. Before I describe how this works, let me further convince you that we are always dealing with a large number of cases.
So, let's take the simplest example of scaling transaction volume and moving from nodes and validators that execute all transactions to nodes and validators that just verify, uh just verify, uh , simple proofs, you know, verify small proofs. But that means someone else outside the blockchain had to create this evidence in the first place. And in order to create this evidence, they need to execute and prove everything that happens in your smart in your smart contracts. And even if you don't see it in your solidity source code, you are constantly interacting with Keccak. If you want to update an account balance, you use Keccak to calculate where that balance is stored.
So, this would be one example. If you call a function, you are computing Keccak. So, in each smart smart contract transaction, there are hundreds and hundreds of them. Hmm, and in fact hundreds of them. Hmm, and in fact , modern ZK-EVMs probably spend about 40% of their time proving those Keccak hashes that you don't even see.
Another example see. Another example , uh, risk assessment { , uh, risk assessment { slash} credit scoring, uh, we might want to prove some properties of your wallet. For example, prove that you have $5 somewhere. Maybe you don't want to reveal exactly where. It doesn't really matter.
Hmm, but what you can do is convince your counterparty that you have that $5 somewhere. Hmm have that $5 somewhere. Hmm , and to do that you need to establish a chain of trust from the block hash through the root state of the entire blockchain, through your account, all the way to the storage slot where your account balance is stored. So you choose the path from your account balance to the block hash account balance to the block hash . By doing this, you already need to compute dozens of Keccak hashes, and for any reasonable creditworthiness assessment, risk assessment, you'll probably have to check these balances over time, or you'll have to check more than one way.
So, again, we move into a world of hundreds of hashes at once. And the third aspect I touched on is the use of ZK KYC. And for this particular problem, you may problem, you may not necessarily need to use Ketchak, but I hope the rest of this conversation will convince you to consider Ketchak again because of the improvements we've made. So, ZK KYC is a little different because we usually have two separate components. The first option works like a Stark evidence system, which generates evidence fairly quickly, but that evidence is also quite large.
And they are too large for a smart contract to handle. Therefore, we cannot work with it directly. So the ecosystem usually wraps this evidence in another proof system called a SNARK, a concise non-interactive argument of knowledge. This gives us all the nice features of a cheap check, in a very tiny size. Something that is perfect for working with blockchains.
And this outer layer, this wrapper, is essentially supposed to verify the inner proof. Again, we establish a chain of trust where if the smart contract accepts the SNARK, the external proof, it means that the internal proof verification was performed correctly, which in turn means that the initial computation initial computation we wanted to do was performed correctly. For example, checking your passport details against a sanctions list or something similar, or checking that you are an accredited investor. And this outer layer, again, has to compute thousands of hashes to be able to verify the inner layer. And now with this ZK-KYC problem, we have an interesting compromise where people can choose different hash choose different hash functions.
We're not tied directly to any particular hash function, but depending on what we choose, we'll be, uh , very, uh, compromising. So, now a lot of people are using something like Poseidon, which is much more convenient for zero- disclosure schemes, but it is much more expensive to compute on a CPU than Keccak. So expensive to compute on a CPU than Keccak. So , the performance characteristic might look something like the diagram on the left, where you spend a lot of time on these dark computations of these ZK- computations of these ZK- friendly hashes so that your outer SNARK layer is significantly faster. Now, with a protocol that we call Keccak verification, which is our contribution, we say that you can go back to Keccak, which is about 10 times faster than Poseidon times faster than Poseidon , with about a five- fold improvement in the internal proof system with only a small overhead on the external proof system.
So, hopefully, if you structure this properly, overall productivity will increase. So, how do we do this? Our team started looking into a protocol called GKR, which is a way of expressing your program using polynomials, and it promises that a single instance of a problem won't necessarily be very fast, but GKR will scale much better than anything else. So, the more such problem instances you add, the more benefits you will get from using GKR. It promises sublinear scaling.
And the comparison I can give here for a little intuition is computing on a CPU and a GPU GPU . Imagine you have a computer screen, it has about 8 million pixels on it, and GPUs are very well optimized to process all those pixels as fast as possible, having literally thousands of cores on your GPU GPU . Each of these cores is not particularly powerful. It's, you know, quite limited in what it can do, but it works very, very effectively with pixel data and a limited set of operations that you can perform on pixel data. On the other hand, a CPU is something like a super-powerful, super-fast core, but there are only a few of them, and they can only process one element at a time.
So, GKR in this scenario is something like a GPU in a ZK-resistant industry. So that's exactly what we did. We applied GKR to Keccak, saw what would happen, and you know, it worked, scaled sublinearly, everything was great. However, the basic version was very, very slow. And to continue my GPU vs.
CPU analogy, it's like taking a 10-year-old GPU and comparing it to a modern CPU. Yes, the logic still applies, but the CPU is so much faster, it has so much more raw power that even if it were to process everything sequentially, it would be faster. So, GKR wasn't enough to move things along for us. So, next we took the original idea of GKR, which is to put all the inputs of our hash inputs of our hash functions as the first layer, and then instead of processing hash by hash or instance, we take all our inputs at once and apply the first operation in Keccak to all of them at once. We then take these results and apply the second Keccak operation to all of these instances simultaneously.
But instead of having a general-purpose computer that can do anything, we really tuned all the operations inside to be as efficient as possible with Keccak and using everything we could think of about Keccak hashes. So our algorithm, you know, you can't apply it to other problems, but it's really very effective with Keccak itself. And the gain that we were able to get is a logarithmic figure, so it might be a little hard to read, but compared to the current state-of-the-art of our implementation, which is a popular framework that a lot of people working in ZK circles use, we start to break even at about 13, 16-32 Keccak instances. And again, that's already a win, because, you know, even a simple proof for storage would be about that size. But by the time you have 200 or 500 instances, we will be 10-30 times faster than Gnark.
So all of this shows that despite all the progress we've made over the years, there's still a lot we can do to improve the efficiency, the productivity, the cost of our zero- disclosure schemes if we apply the, ahem, ZK talent to specific problems. So we can still improve a lot of protocols, um, by looking for these custom solutions to make everything a little bit cheaper to operate. Uh, this can also be used to increase privacy, as we can now do more and more things, for example, on mobile devices. One of the things we're working on is speeding up mobile verification so that, for example, your passport details never leave your phone, so you don't have to trust anyone with your personal details. Another thing we can apply this to is the ZK-KYC process I mentioned.
Uh, if you're a large institution, you can integrate your existing data sources with your smart data sources with your smart contracts, with your new blockchain operations blockchain operations , and you can do it in a way that preserves privacy, where you don't need customer data, you don't need your strategy data, but you have some agent acting on your behalf on the blockchain that you can reference to make sure that certain properties that you're interested in are there. Uh, I'm Jagosh. I am the co-founder of Freilabs. If this was in any way interesting to you, you can say hello at this email address . And then if you want to learn more about the protocol that we created, we call it Kattach check.
You can scan the QR code, which points to a blog post with more technical information about how these things work. It also gives you a link to the official document where you can read all the complex mathematical calculations behind it and access to the GitHub repository where you can already try it out. Thank you.
Automatic transcript — names and jargon may be misspelled.