Let's get ready for our third session and third talk of the day. This time I'd like to invite Uma from Succinct to tell you all about what they're doing with SP1. So please give Umi a round of applause applause . Greetings. My name is Zuma.
I am one of the co-founders of Succinct co-founders of Succinct . And today I'll talk about ZK, what we're doing with SP1, and some cool hackathon ideas that can be built on it. So, let's start with a very general overview of what ZK allows. It's obviously a very popular term and buzzword, and it's often portrayed as quite complicated, but I actually think there's a very simple way to talk about it. Essentially, in ZK systems, you have a prover who wants to prove that when you perform certain calculations with a certain set of inputs, you get a result.
So, they generate a proof that when you run a function f on a sequence of input data x, it results in an answer y. And then the verifier can check the proof and then accept or reject it. And critically, ZK has this property of conciseness that makes checking the proof of the original computation much more efficient than re-doing the computation. So, this is the property of brevity, and it is in its honor that our company is named. Now the other interesting part of ZK other interesting part of ZK is the zero- disclosure part, where you can essentially hide the input data for the actual computation.
So this is important for use cases like online privacy, which I'll touch on in a bit. And that's kind of the magical part of ZK, is that you can prove that a statement or calculation has a certain answer without even revealing what the input was . And that's the part that people find very magical. Um, and there's a lot of interesting math in it about how to actually achieve this result. So in the context of blockchains, let's talk about why ZK is powerful and necessary.
So the first property - the first property - the success property - is success property - is really important for scalability. You can imagine that there is inherent overhead in decentralized systems, as all these nodes around the world re- execute transactions execute transactions , verify the results, and make sure that the balances are calculated correctly. So, there is an overhead from these excess calculations. In the ZK world, uh, you can ask these nodes to verify proofs of computations, and they don't have to re- execute them, and that's how we scale all these blockchain all these blockchain systems. In particular, Ethereum’s roadmap focused on aggregation does embrace ZK as a kind of solution for decentralized systems that scale but are still subject to verification.
And in the Ethereum ecosystem, there are a number of topics that a lot of people have been talking about lately, such as fast finality, interoperability between all these ledgers, unified liquidity, bridges that will be addressed by implementing ZK into the Ethereum stack. Another thing ZK is useful for in the context of blockchains is privacy. So, today in systems like Ethereum or Bitcoin, there are completely transparent ledgers where you can see the history of all account actions . And with ZK, you can hide transaction inputs and enable on- chain privacy while still maintaining auditability. For example, take systems like Tornado Cache, where you can hide the recipient of a transfer.
ZK is also powerful outside of blockchains, and that is also a big area of interest. For example, these two properties, privacy and verifiability verifiability , can help systems beyond Ethereum, Bitcoin, or the blockchains we know . So, let's just look at some specific examples that are less talked about at these, um, conferences, which I think are still very interesting, today, uh, in Web 2 or any other system that we interact with, if you want to provide want to provide any information to external parties, users are expected to disclose all their data. So, to give a really concrete example, if you've example, if you've ever signed a lease and your landlord wants to know that you have enough income to cover the rent, you need to provide your entire bank statement and income history, which is very intrusive. You can imagine that with zero- disclosure evidence, you simply provide the landlord with proof that your income is over a certain threshold, and they will learn the information they need to know without revealing any additional details that you may want to keep private.
Similarly, to verify your age, um, in any online system, you have to provide all the details of your driver's license or passport. And with ZK, you can simply prove that I am over 21 or over 25 without revealing my exact date of birth. And finally birth. And finally , when you want to log in and prove that you have some kind of Twitter account or any Twitter account or any other social media account these days, um, you have to give access to your entire Twitter account and reveal who you are. But you can imagine that, um, people want to include Twitter accounts just for the sake of it, and you wouldn't have to disclose that you're a particular Twitter user.
You can simply reveal that you are in the set of accounts that are approved in the future ZK. Verifiability is also quite interesting. So today, uh, you have a lot of, you know, these agencies that are compliant, uh, but they don't have real verifiability. So to give a specific example, in a credit agency credit agency , which determines people's credit scores, which is extremely important for use cases like getting a mortgage or determining your interest rate, uh interest rate, uh , today they can just update your credit score based on whatever information they want. There is no real accountability except for the intervention of a government regulator.
But in the ZK world, you can imagine that instead these credit agencies, every time they update your credit score, they have to provide evidence that it was done according to some machine learning model that is fair and, you know, not racist or sexist, and also sexist, and also , you know, it's a machine learning model that we all agree on, uh, that fixes things, uh, that has the appropriate inputs according to your credits or whatever other information goes into updating your credit score. So, there are a bunch of examples today where instead of regulators doing spot checks on these agencies, they could use an audit to make sure they're doing things right and honestly. These are some of the ZK usage options. And now I'll talk about what we're building at Succinct, namely ZKVM, which makes ZK very easy to use. What is SP1?
This is our ZKVM. It's actually a very fast ZKVM that allows any developer to use ZK by simply writing regular Rust code. So, how it works " So, how it works " under the hood": you have an SP1 program, which is regular Rust. It compiles into this ISA called risk 5, and then we generate a proof of your program with some input data, using a bunch of cryptographic and mathematical knowledge that you know, which I won't go into. And at the end you get a proof of your program with some input data, which leads to a certain result.
Similar to my first slide where I describe what ZK looks like at a high level. So it seems pretty simple and straightforward. You write some program or calculation that you want to prove, and then SP1 helps you generate the proof. But I'm going to talk about why SP1 is super cool. And for that, we need to go through the old way of doing CK.
So SP1 seems very intuitive . You just write your program in regular code. But the old way of doing ZK was not like that at all. Basically, the old ZK way, and I have some screenshots that look, you know, pretty scary. And that's because the old ZK way was very complicated.
You needed to write these things called schemes where you could write down your calculations that you wanted to generate a proof for and break them down into very low-level, almost assembly language additions and multiplications, which we call a scheme. And you needed to learn all these specialized languages and DSLs to actually do all of this. And often it turned out to be a not very pleasant situation. You needed to know a lot of math in cryptography. So in the old days of ZK, to do anything, you needed a really big team that really specialized in cryptography, to even use ZK.
And there were many problems with this . Uh, obviously . Uh, obviously one big one is that you need specialized knowledge. So it's not that accessible. Another thing is that it is very difficult to configure, maintain and upgrade systems because every time you want to maybe do a new FE feature, you have to spend a lot of engineering effort to add it to your system.
Furthermore, auditing these systems was very difficult because it requires a lot of specialized knowledge and it was all very complicated, and in general it was also expensive and difficult to implement universal applications using this old ZK model. And then, with SP1, because you can just use regular code, uh, now anyone can use ZK and you can actually prove any statement you want. So this is an example of an SP1 program, and for those of you who are familiar with Rust, this is calculating the nth Fibonacci number in SP1, which is kind of like a ZK hello world, and you can see that it looks like completely normal code, and it's all very simple code, and it's all very simple . You don't need to understand any math or cryptography. And that's why SP1 is super cool.
You can just write plain Rust. You can reuse existing libraries from existing software stacks and truly build anything with ZK and be any developer. You don't need to know any complex math. So SP1 is also kind of a breakthrough because it has very high performance. And so on our team we did a lot of new cryptographic things to make SP1 very fast.
So, specifically, one of the biggest use cases for ZK today is the rollup of ZK in the Ethereum ecosystem, as I mentioned earlier. And one interesting fact we noticed is that in the ZK aggregation paradigm, most of the ZK overhead is spent on truly repetitive cryptographic operations, such as hash operations, such as hash functions and elliptic cryptography verification for verifying digital signatures. And so we implemented this system, which we call our precompilation centric architecture, where there's a way to have specialized circuits for these really resource-intensive operations that connect to our main Risk 5 processor and speed everything up by an order of magnitude. So SP1 is essentially the fastest ZKVM by an order of magnitude, especially for these aggregation and blockchain use cases, thanks to this pre-compilation central architecture, which can philosophically be considered a native ZK build. We also implemented an optimized GPU optimized GPU proxy, which helps improve cost and latency by an order of magnitude.
And then we have a bunch of other algorithmic optimizations in cryptography that make SP1 really fast, especially for these blockchain use cases. So, now that I've looked at ZK, what it's good for, and why SP1 makes ZK simple and super fast, I'm going to look at a bunch of apps that impress me that we've built with SP1. So, as I said before, one of the biggest uses of ZK today is ZK aggregation today is ZK aggregation . And in the Ethereum-centric roadmap, for those of you who are familiar, there is a world where every Ethereum build will be a ZK build. And so with SP1 we were able to take REF, which is an implementation of the Ethereum client on Rust, and we were able to plug it into SP1 and get it running.
And there is an actual program And there is an actual program that actually implements ZKVM in SP1. And in 1100 lines of code, which is really very little, you can create a full-fledged ZKVM that verifies Ethereum blocks and Ethereum transactions using SP1 plus the Ethereum implementation on Rust in a weekend. So on Rust in a weekend. So , that's pretty cool, and that's what we released. And one really cool thing to put some numbers on the lightning speed of SP 1 is that if you look at the execution of real Ethereum blocks, you'll see that the transaction verification costs are very low.
In this case, you can see that on average the cost of verifying a transaction is between 0.1 and 0.2, sometimes 0.3 cents, which is really very low. And this demonstrates that with SP1 today, ZK is not only very easy to use, right?
You just take the ref run in SP1, but it's also very cheap, fast and practical. Another thing we did recently with SP1 is we took OP stack, which is a very popular framework for folding on Ethereum, and then we took their state transition feature, which is required for OP stack folding to actually be settled on Ethereum, and we ran it in SP1. And this allows us to convert to convert any OP stack chain into a full-fledged ZKVM type 1 with very simple integration, using SP1 capabilities. uh, and this is a repository for it. So this is related to the previous work on launching in SP1, and in this case it's taking an existing very popular folding framework folding framework that folding uses, like base, if you guys have heard of it, and turning it into a full-fledged ZK folding.
And finally, another big category of work we've done is building ZK thin clients with SP1. So, overall, there's a really big problem today: you have all these different chains: Ethereum, Salana, a bunch of Cosmos chains, and moving money and interacting between them is a really big challenge. And ZK helps solve this because you can verify the consensus of one chain at the execution level of another chain, and then you can have truly seamless interoperability. And so we built a bunch of ZK-like clients with SP1 to interoperate between Ethereum, tender-based chains in the Cosmos ecosystem, and then even chains in the polka dot ecosystem. And again, I have some code examples that show that with SP1 you can simply import existing libraries like Tenderment or Helios, which is a Rust Ethereum client, and easily build all these ZK-like clients with a few lines of code using Rust plus SP1.
So these are some of the things we built with SP1. And that kind of shows that these are practical use cases use cases . People use them today. It's very simple. This is very fast.
But now I want to talk about it because apparently there's a global ETH hackathon happening this weekend . What other ideas do you have for things we're looking forward to building with SP1? So, the first set of ideas I want to talk about are all about the same topic: updating the current blockchain stack with SP1 and ZK, and using ZK wherever needed to help scale the blockchain. One interesting idea is that you can implement new consensus algorithms in SP1 to bring more ecosystems together. For example, we have already connected Ethereum and the Cosmos ecosystem using our tender light client, but there are many more chains that could benefit from implementing ZK light clients, which would be fairly simple to implement in SP1.
Also, there are a bunch of bridges out there today that support modular security checking, and it would be really interesting to take all of these ZK light clients and actually integrate them into existing bridge frameworks so that existing bridges can be upgraded to zkite client security, as opposed to the multi-signatures that they have today. Another interesting project, not in the Ethereum ecosystem, but in the Bitcoin ecosystem, and actually I think someone worked on this at a previous hackathon, is that you take the entire Bitcoin chain and generate a proof of its state transition function and a proof of work , to actually prove the entire history of the chain from Genesis to now, and that would be possible to do in SP1. I think actually some people have done this in the past using the ZK scheme method, but it was very cumbersome and had a lot of, you know, complex code. And I think it would be relatively simple to do in SP1. And then, in general, there were a few talks, um, a talk by Rushi from Move, um, two talks ago, uh, about the Move VM, which is an alternative finite state machine that is different from the EVM.
And in general, there were many different state machines: Move VM, SVM, Cosmos SDK, all of which can be tested in SP1. And you can imagine a future where every blockchain runtime is validated in ZKVM so they can all interoperate and be verifiable verifiable . There is a certain category of interesting on-chain applications that may be possible with SP1. So one thing that's really cool about SP1 is that you can not only test state machines, you can actually test any software. For example, if you have a Rust implementation of a video game like Nintendo, Pokemon, or Doom, you can take that code and run it in SP1, and now you can have testable video games that are hosted on-chain.
So, this is an interesting idea that fascinates me. You can also imagine certain types of NFT certain types of NFT broadcasts with very complex properties using ZK and SP1. For example, you can create an NFT where you can prove that the image was generated according to some complex model. Normally this would be extremely expensive to do in-chain, but you could just write a rest function for it, prove it in SP1, and then make conditional mint code based on the proof. Um, and I think that's a very interesting idea too.
And another category in a related direction that excites me is porting machine learning models to the chain using ZK. So usually, it's very expensive to have things like mnest, or, you know, GPT1, GPT2, or logistic regression in a chain. You also probably don't want to write this kind of thing in solidity because there are no existing machine learning libraries in solidity. But fortunately, since you can now just take regular Rust code and run it in SP1, you can start bringing more software, especially machine learning into the blockchain, which I think would be pretty interesting as well . And the final category of ideas that I'm looking forward to talking about are the real-world applications of ZK in non-blockchain ZK use cases that I covered in my first few slides.
So one idea that I think is really cool and that I would like to see implemented is a proven image editor. Today on the internet, if you go on Twitter, it's impossible to tell whether the image was from a real camera, or an iPhone, or just created by something like Midjourney or Dolly. It would be very interesting to take the signature that signs the image. So if you have a test, do you have verified equipment that signs off on the fact that the image was created from a real camera. Uh real camera.
Uh , the iPhone already does this today. You can prove that the image was generated from a real camera on real equipment and then transformed by cropping or JPEG compression into the image you see being fed to Twitter. And I think ZK is going to be a really important part of how we can determine the authenticity of images and generally other data on the Internet in the future. So that would be a really cool demonstration. Another thing that a lot of people want to do with SP1 is run it on their mobile phone, and no one has done that yet, and that would also be really cool to explore, like whether you can take SP1 and run it in Swift or run it on an iPhone and see how it works.
There are some other really cool examples of taking web 2 data and moving it to web 3. For example, checking emails or checking passports in SP1 and moving that data up the chain. Today, almost all emails are signed with a cryptographic protocol by the name server that issued the email. For example, if you receive an email from Twitter, Twitter's public key for their mail server will sign that email, certifying that it was sent by a real person from Twitter. And you can verify that signature in SP1 and prove that you received the email from a specific source.
You can also do the same with passports. Passports are typically signed by the issuing country and passport authority, and there is a public key registry. So you can check if I have a passport issued by the United States and reveal certain information, for example, to prove that you are a citizen on the blockchain. So all of this would be cool to do in SP1. In general, I think there are potentially many other sources of digital signatures, you digital signatures, you know, in different data sources.
So, emails and passports are just two examples. What other areas are there where there are signatures that we can verify in ZK and then selectively reveal information and move it to the blockchain or also use it in an off-blockchain context to selectively reveal only the information we want to reveal instead of hiding our entire identity? And finally, things like PDF documents or image capture and running machine learning models, I think that's also a really interesting real-world use case for ZK, where you can start to bring that data onto the blockchain or even use it in an off-blockchain context. So, these are some examples of SP1 that I'm really excited to see implemented in many different applications and ecosystems. Hmm, and yes ecosystems.
Hmm, and yes , I hope this was interesting. Hmm, if you're interested, you can, this is my information, you can contact me. Um, these are the repositories I mentioned. And so, overall, I'm really happy to see that ZK, now that it's much more accessible, is getting a lot more adoption and a lot more people are building with it . Thank you.
Automatic transcript — names and jargon may be misspelled.
