The Future of Proving With Stwo - Maya Dotan

Transcript

[Music] Hi. So, hi everyone. Um, thanks for coming. Uh, so I'll talk here today about uh stew and the future of start net scalability and hopefully these words will be meaningful by some part of the talk. So, All good.

Okay. Sorry about that. So um first we'll talk a little bit bit about what starket is. Then we'll talk about what stew is. H stew is our nextgen prover. This is the main part of the talk. H hopefully we'll understand why you need a prover for starknet at this point. and then we'll talk a little bit about how this relates to Starknet's privacy roadmap and what we want to be doing in the future. Um, so raise of hands, who knows Starnet? Okay. And who knows about the ZK roll-ups? Okay, so most of everyone. So I'll keep that short. So Starnet is a ZK

rollup over Ethereum. It's the first ZK rollup. It's the most performant ZK rollup and h it's the first one to also be stage one. And what does this mean? It means that uh it is a blockchain. Uh just like Ethereum, there are blocks, there's transactions in blocks. It operates differently, but the idea is the same. And every block as opposed to in Ethereum where a block is verified by validators and the entire network re-executing transactions to verify the state. In starknet each block is proven.

Uh what does this mean that is proven? It means that the h execution of the block is translated into a trace. uh which is some we can think of it as a mathematical statement and this ma mathematical statement is proven and a proof is written to the Ethereum blockchain and to a contract a smart contract that verifies this proof and h then all of the Ethereum validators run this smart contract because they re-execute everything and this way the state of Starknet is verified. So, Starket enjoys all of the security of Ethereum H without the need to

re-execute every block. So, this of course only makes sense when proving and verifying are cheaper than re-executing, right? Because otherwise it would make sense for everyone on the Stark network network to just re-execute everything. But we want it to be cheaper and faster and more performant. So the purpose is to h greatly increase by orders of a magnitude what type of computation you can do on a blockchain, enjoy the same uh security of Ethereum and utilize uh proving and soon harknet will also be a hopefully a sec rollup over bitcoin. Um so it will enjoy not only

the security that comes from Ethereum proof of stake but also from Bitcoin proof of work and also will enhance every what you can do with Bitcoin uh bringing DeFi and other opportunities to Bitcoin. So okay I think this is an old version of the that slidesh okay so what is two? So we said that proving and verifying need to be performant enough for all of this to make sense. Currently starkinet runs with a the stone prover stone starket one and now we're moving to stew starket 2 which is a new prover. So stone is

based on stark stark technology stark net and stew h is meant to increase the performance and uh of proving greatly. So how is this done? Stone was developed to make verification super cheap and it really is pretty cheap. It runs in production on top of Ethereum for years and there's no problem verifying the proofs. However, h stone is not as fast at proving because we aim to have fast verification. Now that things are stable enough, we've been live long enough. We want to optimize for proving h because

the proving also has to be cheap enough to scale to the extent that extent that we want to. So this is why we came up with STU the great people at Starkware. It's based on circle star technology. So this is very beautiful math um which allows a the a stark like protocol to exist over a small field small finite field. So stone operated over a pretty large field h but still operates over the mer field which is 2 to 31. And there's very very nice math behind it. I left some links at the end of the uh slides if anybody wants to read about how this

works. But uh basically the idea is to find a field that has that is small h but also has a large multiplic multiplicative subgroup. Um and this happens to be the unit circle in the mer field. And so this allows us to utilize fast arithmetics that come from the small field but also have enjoy all of the properties that we need for folding and the stir fry protocols. So everything kind of magically works in this construction. So very nice if you're interested in that. Uh Stew also utilizes a flat air design. What does this mean? So um proving time scales

linearly with the number of rows in a trace. So remember when you execute a program in Cairo or anywhere you you can translate translate this into a trace and this trace is then interpreted as a set of polomials. So um the longer so you have this trace it's a table. Think of it as a table. Um, the more rows you have, the slower the prover. Uh, the more columns you have, the slower the verifier. Stone optimized for many rows and few columns to have fast verification. Stu opt optimizes for fewer rows at the expense of columns. Not too bad for verification, but uh this is it. You can

think about it when you look at actually how the air how the errors are written, how this translation to trace is done. you it kind of looks like oneliners in Python where you kind of have lambda functions. So this enables the trace to be kind of squashed and flat. Uh so this brings a lot of performance to ste and um also ste it's not written here but uh ste has a very nice property where each op code is a a different trace element and you don't need to pad the trace to the nearest power of two which also brings a very big performance boost compared to stone and to competitors. So

uh we saw that SP1 posted about them doing this. This already exists in two. Um so it's very very performant and I have some benchmarks to show show you. Um I don't something happened to the slides. Sorry about that. So all of these perh benchmarks that I'm going to show is two is benchmarked on Cairo zero code. So just Cairo code. So it's a general uh purpose prover. You can prove any code just uh proven in Cairo and we compared against competitors in Rust but also against pre-ompiles. So these are benchmarks for SHATU and we see increasingly growing targets and you can

see that Stew beats the competitors with Cairo codes even when compared to pre-ompiles. So that's how performant Stew is. You can see that on Cairo zero code it beats SP1 and risk zero pre-ompiles. Not even talking about Rust. Um also on SHA three chains catch so we have 32bit catchups and these are running for increasingly long chains. So just recursively hashing and you can see again that STO outperforms SP1 and risk zero pre-ompiles with Cairo zero code by a factor of like 30 to

40 and so this is even without writing dedicated errors for stew for these targets that we probably will do at some point. Okay so skipping a little bit. Okay. So what is the road map for STU? Um STU currently proves Cairo code. Uh we are aiming to h implement a variant of Cairo called Cairo M31 which basically restricts Cairo to the small field and we expect this to give a performance boost of between 10 to 50x over the benchmarks that you just saw. So hopefully this will be coming

soon. Also we are working very hard on implementing a GPU functionality force 2 which also should drive up performance by quite a bit. So this should be coming within this year I think. Um also there are already uh risk five errors for STO developed by Nexus the Nexus team and we aim to enhance those and build upon this so people can if they want prove rust with stew but the main purpose that we developed STO is to decentralize starknet so we are committed to making starknet the most decentralized zk

rollup this means that it will be decentralized not only in sequencing which is coming soon but also in proving. So we want to make two so fast that it can prove the starket state. It will be cheap enough to prove the second state that we can really decentralize proving because don't we don't want to be in control of proving the network. We really want to decentralize it and additionally we want the bonus of having people be able to prove things on client side. So proving claims on uh end devices for instance for privacy private payments. We know this is a kind of a painful spot for blockchains. Uh hopefully by utilizing too you could have h private payments in your uh in

your mobile device uh AI use cases. So provable AI is becoming a hot topic. We hope too. We have some benchmarks on matrix multiplication and we have the Giza team implementing errors for AI uh purposes for STU and ZK identity verifiable credentials. All of this uh we want to make STU the default for all of these use cases. It is the fastest and best and we want to drive this even further. Steu is fully open source. You can play around with it now. Um we also will build a lot of dev tools for it. So you can just easily utilize it for your code. Um so STU and the ecosystem we're

going to um so the Kakarot team are working hard on real-time proving of Ethereum blocks with STU and we hope that this will happen uh sooner than later. Um as I said we want to be a ZK rollup over Ethereum. This two is the driver of this h because the starknet stat would have have to be verified using bitcoin script. We're making a push in that direction. Um layer 3es so blockchains on top of startnet could settle their state to starknet uh using stew h as well as any other blockchain that would want to settle their state to startet and

um that's it. So as I said this kind of all coincides with privacy. Uh so at Starknet we want to be a home for privacy applications and we have several ways that we want to drive this. Um so the first and foremost I would say is that we want to make ST the first truly ZK zk prover. So currently zk snark prover. So currently uh snark provers are pretty naturally zk but stark provers are typically not zk. They offer typically sufficient privacy for all use cases that you can think of but uh to be truly ZK would be nice and we

hope to make that happen in the next year. Um we are making a big push to be the home for private compliant payments. So uh bringing cheap, fast, scalable, compliant payments uh to starket is really a goal for us. So anyone interested in building anything like that too, we hope to make the home for that. And also Starknet is a very cheap home for verifying snark proofs. So we have an ongoing collaboration with Aztec and Noir to bring noir developers to Starknet. Um so you are very welcome to uh write your code in noir and you can automatically uh generate a starknet

onchain verifier uh for your noir program and have privacy on stark net basically for free doing that um free coding wise not free uh transaction fee wise but very cheap transaction fee wise um and that's part of our goal to be truly decentralized in the technological stack proving stack sequencing stack. So uh that's where we're going and here are some resources. So you can go to the stew and stu kairo repos and stu cyro has actually examples that you can run and you can write code and prove it locally with stew and um there's a link to Nexus and their risk 5 efforts and

some GPU resources. And if you want to read about the very beautiful math behind Circle Stark, there's a couple of blog posts here by ZK Security and I think they're amazing. They're the best ones I've had the uh chance to read. Um yeah, so thank [Applause] you. We've got about 10 minutes for questions, so quite enough time. So feel free to ask, guys. The microphone is just here. raise your hand if you if you want to ask a question.

I saw some topics about the AI but you never mentioned. Can you explain me more about the topics that how can be starkness will be achieving some AI or Okay. So first of all is a good choice for proving AI anything related to I think a a really use interesting use case is to verify the authenticity of photos or you know how a photo was maybe edited or video. So maybe you take a photo and you want to make sure you want to prove that the only editing you did is cropping. So you write your editing software in Cairo and you prove with two you have a signature from your device that you took the photo with the device where and when you said and then

you crop it with a Cairo based photo editor and then you generate a proof because this is a general Cairo code. So you can just prove it on this input and then you have a proof that you didn't edit the photo other than cropping it. Uh same goes for video authenticity anything like that. agents uh in blockchains are a hot topic now. So anything like that. Giza are working on this. They already have some some implementation of this going and they're also working on like deep learning type of things. Um, so I think this is really an area to be explored because we are in a in a at a time that really AI is generating most of what we see. And at

least if you know what kind of AI or model was used on what input to generate what output. This is a lot of power that we currently don't have like watermarking techniques for AI are very weak at the pro at this moment. So I think this is a promising direction. Yeah. Another question is uh Plunk3 also integrates uh M M31 as a possible field for for the proof. So my question is does circle star only replace the field using quadratic extension to

restore primitive roots or or is there a specificity in the circle stark that is has a different functioning uh and different efficiency than the one used in pron. So the efficiency of st stems from several different things that we did. The first one being utilizing the mercen field with circle starks there the complexity was to understand how the math works right. So you have to basically for the the the hard thing to do is the folding that you need for fry and stir right the kind kind of like what you do with RSA and FFT. Uh so you would you need to to you needed to find

this multiplicative subgroup of large order and you needed to prove that you can uh both have this co-et uh that you can move and you can fold and you can half the number of uh half the size of the polomial basically. Um so this anyone can utilize with any any prover if they utilize circular starks correctly we have um so but this is open source anyone can do it but I think where starkware's implementation really shines is also in the air design so writing airs is not is kind of a very specialized field and um you need to take h the op codes of your virtual

machine if for us this This is Kairo virtual machine. It's optimized for proving but also for risk 5 you and you need to translate these operations of the virtual machines into arithmetic representation. This is what you call errors arithmetic intermediary representation and you really want these errors to be as succinct as possible and this is kind of a specialty and this is most of what we have done with stew. So writing the like the the initial circle stark implementation like coming up with it was was hard but the implementation was not the majority of what we took to makes two happen. Um so writing errors efficiently is kind of a very specialist

task especially when you try to minimize the number of rows at the expense of the columns you need still reasonable verification. So this is the what I was talking about of about the flat air design. This is a major change. Um, and also getting rid of the padding was another engineering effort. So kind of there's a lot of things to do. There's still room to improve. People are doing a weird uh protocol. People are doing uh multi- multi-variant polomials. There's still ways probably you can push this um and we are still doing that as well.

But uh so it's it's not just a matter of implementing circle starks. You really need to to work on a lot of things to push the performance. Yeah. Hi, how's it going? Thanks for presentation. This is uh Diet from Web 3 Wiz and I wanted to ask you about an application. Uh so what we do is we offer websites widgets that they can embed on their website to like interact with crypto. And we also saw the nosis hack that was focused on front end. So I was wondering if there is a way to use this proofs to prove the front end of uh blockchain applications and if you could give me at least a highlevel picture conceptually how it would work. Thank

you. Yes. So um currently STO is compatible. We're trying to we're working on pushing the performance a bit. Erh so technically yes anything with web assembly you can use sto to prove um and you would write your front end with cairo or a faster variant of cairo the kairo M31 when it's out and you would need to like once probably the user inputs their input to whatever they need the functionality you create a zero knowledge proof that this is the code that ran on your website and that's it.

You have a proof and then you can utilize it for whatever you want. You can go onchain, you can go offchain. I hope that answers your question. Yeah. Uh yeah, thank you. Um can you elaborate a little bit about the centralization? Did you mean to add more sequencers or do you mean something else? Thank you. So we are both adding more sequencers. So uh the the next version of Starknet will al will have all of the code to decentralize the sequencer and we will run several sequencers locally just to make sure that everything works the way it should and the hope is that in the following version or the one after that

we will open sequencing up to anyone. And we also want to reduce the cost of running a sequencer because currently it's quite expensive. We want it to be cheap enough to be viable for for users, but we also want to decentralize proving. So in starket you need to sequence it, but you also need to prove every block. And we don't want to be a centralized proving service. We want competition there. We want especially for livveness, right? You don't want to have only one one organization in charge of this. So, we aim to make this cheap enough and achievable for anyone that wants to I I have one question concerning uh RAM

usage and this is this might be a new question because I don't I actually don't know but is um the fact that some stark protocols are high in the RAM usage. Mhm. Is it inherent to Stark or is it just uh a byproduct of not optimizing for low RAM usage? I'm asking because of client side proving in the future. I don't know if it's a Stark thing because when we uh benchmark against Jolt, they run out of memory a lot sooner than we do on CPU. So they and they're snark based. So I don't think it's an inherent snark problem.

It's not something that we optimized for a lot but for stew but it is much faster even for like less RAM than competitors I think but they're also stark based so that the short answer is I don't know if it's a stark thing. Yeah. One more last question if anyone has any. Otherwise, we're ready to move. [Music]