zkStudyClub - STARKs overview

Transcript

Yeah. So, this is the uh working group that we have put together the last few weeks. This is the first time we're trying it out. Um Matthew is going to be doing like a highle intro to the case darks, which I think we've all been very excited about. We have had a little bit of trouble getting the sound and video set up. Well, I really um and um we'll definitely try to find another setup for next time, but we hope that if people are watching this after that you can at least understand it and yeah, you might want to join us next time. So, I think that's maybe the way I would start. And Matthew, if you want to maybe just do a quick introduction about what you're covering today, that might be helpful, too.

All right. Yeah. Uh so for the kickoff talk, we're going to look at the last uh presentation that Eli Benzison did at Web 3 Summit. Um so I took some detailed notes. Um Alex, who's not on the call, uh but he also had some very detailed notes. So I think I'm going to I'm using a combination of what we wrote as we were watching that uh that talk. Um it's meant to be a bit of a high level overview. It's also taking, you know, it's it's basically what he talked about for those of you who've already watched it. So, it's an overview of where he and his team are at with Starks, but it's also dipping into snarks and bulletproofs. Um, mostly because those are the most famous or the most known um

kind of use cases or there's use cases of it, you know, out there in the world. So, that's why those three are being talked about the most. Certainly, there are others and it's such a hot space right now. for for research. It seems that the amount of papers coming out over the last years is increasing which is which is fantastic and makes for lots of good evening and weekend reading I guess for all of us. So if there's no other no other remarks then do you want to just um do are your notes something you can share?

Yeah, absolutely. So this is just this is just a markdown file and there's another document here that Alex had shared of his notes. So at the ending at the ending we could share both of these. Um I need to publish mine somewhere probably. I'll put them also on Google Docs because that seems to be where we're sharing everything. I'm looking for Alex's notes here, but I did he post them somewhere or he just shared them directly? He he did send them as a DM at 4:00 a.m. my time. So, I don't know where he is, but I I was just looking over them as we were waiting to start.

Okay. I'm just wondering if there's something we can follow along, but you can also do this after. Um I mean, I could do it really quickly. We'll see. Yeah, for those of you that that want to read, let's do this. Let's do Telegram came up. So, here are the notes of Alex. I guess it's okay to share them. Hopefully, he's not Hopefully that's okay.

Okay. And make a new one. This is my machine struggling. That was good. Thanks for that. Um, it's not it's not sending this one though.

There's something there. There we go. All right. That's just my machine struggling. Cool. And here are my notes. Amazing. Thanks. Okay. Yeah, that's good. Okay. Okay, so mine are in markdown, which is why I'm going to I guess present off of this screen and I'm going to switch over to Alex's when we get to the demo because he did a really great job breaking it all down. All right, so um let's get into it. Um so, uh the main I guess the main link and also this is

something that got recommended in the Telegram channel was zk.science. Um that seems to be a really good collection of papers. So the I think if we if we wanted to rally around a resource maybe we could start opening up uh you know poll requests there for other papers that we find interesting. I know that possibly in our group we we will do something else but um that seems to be a good starting collection. Um, so the way I guess the way that uh that Eli was, you know, describing it as, you know, how to talk to the general public about what is a zero knowledge proof, he had this good metaphor of it being like a grocery receipt. So you

have a list of items with a price and it's summing up to a total. Um, and this is a nice, you know, mathematical statement that you could make because it's very obvious that you could give anybody this piece of paper and they would be able to say, "Okay, as long as I have all those uh items, you know, in my grocery bag, then I know that this transaction we just had was correct. You're not lying. There's nothing missing. Um, and and this is in fact the total which I'm about to pay you for." So th this is quite nice as a metaphor then into zero knowledge proofs because if you're if you're wanting to be the prover, you could be choosing that some of those items some of those prices on

this receipt are private and you're going to blank them out and you could still you could still trust the total amount due to uh you know the mathematics behind um how how the proof itself is working. Um, so this is this is quite nice if you're trying to I don't know talk to your talk to your friends or significant other or maybe parents about what what it is. I I thought that this was this was a nice metaphor. Um, so the I guess starting off with the general overview, the first instance or the first paper of zero knowledge uh was in 1985 and was a collaboration research uh of MIT and University of Toronto. Um so Shafi

Goldwasa and Sylvio Mali and Charlie Rakov. Um and since 1985 there has been many many more advances. Um but this being the first you know Golvasa and Macalli got Turing awards for their works on these kind of proofs. Um so it is it is quite it is quite nice I guess that we're building on something that is so old even though there there are some constructions that are quite new. Um there's been enough time I think for for research to be done on this. Um then yeah what like why why would you want to use this or what are some examples that that one could prove? Uh I guess looking at the blockchain space as

a really good candidate for this that if you were wanting to prove to the government or whoever it is uh that is your tax authority uh and you wanted to make a statement like I paid all my taxes on cryptocurrencies last year. This is something that is possible because when all of the transactions have been done on a public ledger, you could construct a proof such that you know the the public inputs are available and and I think that this is really you know this this is really nice. I don't know if all banks uh in in the near term are going to be using blockchains but certainly this is something that becomes possible in the future uh for private individuals to to make statements like this.

Um yeah, something else something else that is also uh kind of important in the blockchain space is crypto exchanges themselves being able to make a statement that they are you know in so-called in the black that they are uh you know they're holding enough reserves for all the funds that they are supposed to be controlling. Um and you know you could swap cryp crypto exchange with banks um and this is in fact what they're supposed to do. they need to keep a certain amount um of value in in reserve. They can't they can't, you know, leverage 99% of all the value that they're supposed to be uh that they're supposed to be keeping uh keeping track of.

Um yeah, so so the quick facts I guess about ZK Starks is that in in the past five years there I mean so it's I guess this is Starks and Snarks in a way. Um but in the last five years there's been a number of uh there's been a number of de like developed basically software libraries. Um I'm going to say of varying quality. I've seen you know I've seen more of the research academic libraries being said as you know warning this is alpha software. It doesn't have a security review. Um it's good. It's definitely good enough to play with and uh and probably not something you want to deploy in production because of security concerns. But additionally, they haven't been optimized. Um, which is just to say they'll, you know, they

will work. Um, but probably better probably better to to, you know, take a closer look if you're planning to put this uh into a product or service and deploy it. But with that being said, there is a number of implementations which is uh which is great and they're available uh mostly on GitHub. And for those of you for those of you that are interested uh which I think is most of us hopefully about what is being put in there then yeah this is the quick list of topics um that that you might want to look at. Um so what what is a zk stark? What is the core part of that? Um well you know the zk part of course is

zero knowledge uh meaning that there are private inputs and they can be shielded. Um the other important part about a stark is that they're scalable in the sense that uh you have a proof of computation that's lasting t cycles. So that's bounded. Um and you can generate it in roughly t cycles as well. So what that means is as you're generating the proof this isn't you know exponentially growing as as you're doing the generation. Um the next the next very important part is that verification is exponentially faster uh than than the t cycles. So roughly it's log t and and this is a great property to have.

Um and the example that Eli gave which I think is pretty nice is that if you had um if you had 1 million uh cycles then the log t of that is 13 and if you go to a billion cycles then the log of that is 20. So for for those of you who've forgotten you know log maths this is really great whenever you see that something is log t uh yeah it's it's going to scale quite nicely. Um the other important part of a stark is uh is the t which is transparent. Um like roughly what this means is that there's no trusted setup. Um and slightly more specifically it means that uh verifier messages are using public

random coins uh which is uh which is yeah being based on interactive oracle proofs. Um the next part of of the stark name is that it's an argument of knowledge. Um so the proof is only generated by the party knowing the private input. Um and so this is something important for for the zero knowledge you know kind of family of algorithms is that if you know a secret constructing a proof does not reveal that secret. Um and of course the the output um the output is that there's you know there's a witness statement that can then be proven. Um and and with all of this you have you know formally an

efficient procedure uh that the prover can make a statement and then it can later be verified by anybody. Um and to to then say you know if if you have a stark what is a snark the the only you know roughly the only difference is that snark is simply succinct non-interactive argument of knowledge. Starks are also non-interactive. Uh what this means is that the prover is able to do all the work up front and publish one statement and then anybody could come and do the verification later. Uh the first paper in 1985 uh I think was was largely driven by this.

They were looking at they were trying to look at um interactive proofs and move it into a non-interactive setting. An interactive setting would be one where the prover is the prover is in a you know kind of live communication with a verifier and the verifier is choosing questions to pose um to the prover and so a non-interactive setup is nicer in the fact in the sense that or in the fact that you don't need to have both the prover and the verifier online at the same time. The verifier could be anybody in the world at any time in the future. So this is really nice that you you know you as an individual don't have to trust but can but can verify yourself um and you don't need the prover to be

online and ready to answer your questions if you wanted to verify. Um so moving into kind of you know the the three main algorithms that are that are out there in the world and deployed. Um yeah as it was said in the talk you know there's many others and and definitely more are coming in the future. uh but these are the three that are deployed and are in use right now. Um so so the comparing and contrasting uh having a stark prover um it's it's somehow quasi linear to the naive computation. Um naive being that there's no zero knowledge aspects at all. Um snarks are snarks are very similar. Uh

the main difference is that you have this setup um and and specifically that the setup is scaling linear to the computation and the prover time. Um there was some really nice graphs that were in the presentation. So when for those of you that want a bit more of a visual uh of this um maybe later I update these notes and I'll drop a time stamp in there. Uh but really what this means is that as the circuit is getting bigger um the snark setup is also getting bigger and this has some this has some some concerns because already the setup is you know quite a special ceremony um and as you need to do more work uh during that setup phase then you're going to yeah it's going to take

longer or you might want to increase the number of participants if you're doing um you know some distributed computation um and you know The reason that the setup is not so nice is that uh you know if you're doing a snark that means you're trusting the setup and that entire ceremony and yes the keys are getting larger as the computation becomes larger. Um something something kind of new that's being done with this KOD project is recursive snarks. So by using this idea of epochs, you don't have like you're not growing the setup because the computation is being bounded by epoch. Um so in the case of KOD, they're saying that every block would be

a new epoch. So if you have a known size of block, then this would this would be how much uh or how large the key would need to be. Um oh, I see that the formatting is interesting. that that's supposed to be nested. But yeah, um so you're breaking the computation down into sequence of eblocks. Um something I guess something that was a bit of a jab uh and I hadn't really thought about was that uh even if you're delaying by one block, this might not even be enough time to generate the recursive snark. So block time is uh important. Um and and still to say that with this recursive snark um there is

still a trusted setup going on because it is a snark after all. Um and and the proving time will be larger. Um so bulletproofs um bulletproofs have a great proof link. That's a really nice property of of using this setup. Um the verification time is super linear along computation and proving time. And what this means is that verifying isn't fast like it is in starks and snarks. So when you're doing a large computation for proving, everybody who's verifying is also going to need to do a large amount of computation for verifying. So uh I think one of the main things that um that that Eli has in mind is

scalability. He mentioned this very often in his talk and what and bulletproof is kind of out of the race then because if the verification time is scaling along with the prover then you're not really the like the network is not really reaping the benefits of this uh and bulletproofs would I think be the wrong approach there um and uh so all something to say about all of them is that they're all using um Peterson hashes um and so these are being deployed right Now like snarks are very much um being uh researched and and released in a way by Starkware. Um snarks are uh being used uh by Zcash and bulletproofs are being used in Monero.

So why you know kind of why do we want to do all of this um in in the sense of Starks? Why, you know, if we have bold proofs and they're good at some things and we have snarks and they're good at other things and and they're existing, why why do we want a Stark? And it it is really about the T in the name, which is transparency. So removing the trusted setup is pretty important. um even if you're doing uh you know this distributed computation there's still the single point of failure in the sense that you had this setup phase at all and it it adds it adds overhead to being able to use this uh to being able to use this cryptography. Um so it would be

nice to have a stark because anybody can do it at any point in time. somebody who wants to prove a statement can simply do the computation um you know pub publish the the witness and the verifier key and then and then they're done. They could they could disappear from the internet forever but anybody would be able to come and and verify that into the future and not need to worry about who like what who or what mysterious group of people did a setup. Um, so there is there is something to be said about um I don't I don't fully understand what he meant by this, but there is something to be said about relying on symmetric cryptography. I guess until now um it's been it's been

stated that it's postquantum secure. uh so it's not something I'm I'm very knowledgeable about but I have heard that using symmetric cryptography specifically there is not a big advantage if and when we move into um you know quantum computation uh which is which is quite nice and so future proofing uh is is a good thing to have um I don't know if stark the reason I don't know is I don't know if starks are the only ones that have this but Um but yeah um and and so additionally you know there's simpler simpler constructions and you're building on years of implementation so uh using CR

CR and Fiat Shamir you know these are these are things that have been existing in the world for a while and so the mathematics I think is a little bit more known and we're moving away from this so-called spooky moon math um if we're using mathematics that had been around and understood for for a while. Um so so for stark scalability, um, this was where, so this this was one of the things I think that Eli was driving. It seems I think he's doing it because he's, uh, they're on commission with the Ethereum Foundation. Um, and so this is why uh this is why scalability is something that they're very interested in to be able to deploy it into the

world in in Ethereum blockchain. So he had an update where in 2017 at uh the consensus um conference they had one transaction uh and the the size of this proof was 500 kilobytes and then in this year they were able to show oh sorry they were able to show 500 to 80 uh improvement uh kilobyte size and now they were able to reduce that further to 45. uh he was very optimistic about saying that they didn't yet identify a lower bound. So they're going to keep looking for uh for improving that number and already that's pretty fantastic I

think to take it from 500 kilobytes to 45 is still quite large um compared to compared to Snark and Bulletproof but um that's good to know that they're saying they're going to keep driving that number down. um a really nice number and uh and something that I I had not been aware of is that if you're batching, so if you were to put 10,000 transactions and make a proof out of this um they were able to change, you know, they were able to improve that number from 190 to 135. And uh and so this was something I hadn't thought about that if it's 45 um you know kilobit for one transaction proof to put 10,000 more is

only is only moving the number up by a factor of three. Um, and that's that's pretty, you know, that's that's pretty impressive. And uh and and likely likely is I I think that this is where we're going to see so this is my bias as an engineer. Likely this is where I see that there's going to be uh actual implementations and use cases of this. I I don't I don't think that there's going to be a lot of cases where one transaction um is having a proof made on it, but instead large large batches. And so that's good to know that um you know the the size of the proof isn't ballooning when you're when you're doing these batches. In fact, it's it's pretty great.

Um and so to compare and contrast then when you take a look at uh at what a snark is uh when you have one transaction you're getting 200 byt. If you're putting 10,000 transactions in you're getting 200 byt. This is one of the uh nice properties of a snark is that um you you have a constant size of a proof. Um however, if you uh if you're doing a snark, then you have a setup and the key size is going to grow with the with the size of computation. So for one transaction, you're at 500 megabyte and if you're at 10,000 transactions, you're at 500 gigabyte. Uh so this this is a problem. Um and and that's that's simply

part of the the construct of Snark. Um for bulletproof to compare and contrast, one transaction is uh 1.5 kilobyte and 10,000 is 2.5. Uh yeah, great proof length. Nothing more to say there. The trade-off is that verification time is scaling linear with the proving time. So you don't uh you don't get this you don't get this nice fact that the verifiers are going to be able to keep up with a prover if you know so if you're using this uh if you're using this in a blockchain so if you're wanting to verify everything uh and you're looking at Monero then yeah all the verifiers are also doing quite a lot of work to do verifications.

So, so then moving in moving in more to Starks then that first part of the talk was comparing and contrasting kind of showing the current state of of all these techniques and especially of the improvements they made with Stark. So, how to build an efficient Stark. Um, again the the high level or the gist of it is that you're going to take some computation and you're going to put it into this thing called air which is algebraic intermediate representation. Um he made the special note that uh you know this rank one CS which which is used in Starks um is technically a special case of an air. Um I I don't

know enough to kind of unpack what what he said there. But good to know that kind of uh air air in a way is like a superset of what was being done in snark. So I don't think that all of that work is being thrown out as they're moving into starts and and taking a look at uh constructing circuits in this way. Um so when when you're going to build one of these you're you're taking the state of computation and you're making a sequence of field elements and in the computer you're just going to capture these in some register. um- which means yeah which means it's you know deterministic and you're going to just bind some variables to some value to some values as you're moving over uh a a

sequence. Um and the overall program then is going to be represented as sets of constraints as you move from state to state. Um and these constraints are lowderee polomials. Um longer term uh longer term there should be some tooling that's going to convert programs directly into this uh air uh and medium-term and I think already we see this there are um you know some DSLs domain specific languages um that are good for doing certain types of computations.

Um he then moved into to two examples. Um the first one being a Fibonacci sequence. So with Fibonacci you always have uh you always give it two numbers and then it's giving you a result. So for Fibonacci you can start with uh zero and one or zero and one. uh you you people know who you are but yeah you can start with you can start with a given state and uh you know the spec is you have two field elements which are the latest two and then you're going to repeat this state n number of times to get the final Fibonacci number that you wanted. So the constraints for for this is that um you're going to make sure that one registered has been copied into

the next one and that you have an addition of the previous two. This is, you know, the high level spec of Fibonacci. Um, and the constraints you're going to have are for equality and addition, which is the air. Um, and then and then jokingly it was simply stated, and then you're just going to apply more crypto and algebra, of course. You know, it's just that easy to sprinkle some of that on top. Um, he uh he he has posted some talks that he did at Techneon on YouTube. Um, I'd very much like to uh to to watch those. I haven't yet. Uh and additionally there was a there was a threepart blog post from Vitalik and uh and I linked to it here. Um so the Stark series from

Vitalik um especially here I think this is where he was talking about VDF which which is an important part of this. Um and so for those of you interested uh or for for a future talk that we have uh it would be good to kind of unpack that and get into the maths uh there. Um, another example is a Peterson Merkel path. Um, which I think is pretty important. A lot of things end up being um, Peterson commitments uh, in this world of zero knowledge. Um, and so this example is you want to prove that you know a leaf in a Merkel tree of depth D when the Merkel root is R. So, uh, so yeah, this this is like if if you only had a Merkel

route, which is usually what is published, you don't you don't necessarily need to know everything that's in the Merkel tree, but you definitely want to know that top that top node. What what is the value there? Um, and you're going to say, I I I know I know that uh this leaf is existing. Um, and so yeah, the Merkel root is usually put into the public. Um and knowing that leaf then can be used in some interesting ways. Uh in the Zcash sapling circuit um it's used for shielded transactions.

um it's now using Peterson commitments in previous versions of Zcash it was Shaw 256 and uh if you're doing this VDF construction which is verifiable delay functions where yeah this is a way of trying to say you know in in the future something will be um you know something will be revealed and it's it's a verifiable delay in the sense that how long the delay is whether that is uh you know an epoch by time stamp or an epoch by number of computation cycles. Um you can make a proof out of out of that. Um and and one way is to say I'm going to hash this many times, you know, some millions of times. Um and you won't you won't know what the result is. So given

an X and then hashing that some millions of times, the result is Y. Um and you can make a proof out of this instead of also needing to do the computation of hashing X millions of times. Um so so he gave some specific numbers um that if you're going up to a 256 depth of of the path length then proving time is something like 7 seconds and verification time is something like 10 to 20 milliseconds. Um and yeah most of the work most of the work I guess right now in stark is is verifying um Merkel authentication paths.

Um and yeah, what are some use cases of using a Merkel prover? So yeah, you can prove that you know a leaf like in Zcash. Uh you can prove that account balances are being updated correctly. So when all of your accounts are being represented in a tree, if you're applying a transaction, you shouldn't be creating or destroying value. You should be moving it from one account to another. And you can you can do this. Um and yeah, similar for proving that trades are happening correctly. uh you shouldn't be creating or destroying value with with any luck. Um and you can prove this. Um and all of these are reduced to the statement that you know a Merkel path to a leaf uh and and the

Merkel route is is a public uh value. So when we're doing all this type of math there there is a degree of um error uh that are in these systems. Um, and this is where you're going to tweak the parameter for how much security. Um, specifically, he was talking about 80 to 128 bits of security. Um, it's something I would like to understand better myself because these numbers seem low. Um, and I'm not I'm not sure if that's a good instinct to have. Um, but it was my kind of gut reaction at the time and and it still is. Um I think later in the demo uh when he was running this uh this

Stark library on a phone at first it was at 80 bits of security and then he bumped it up to 128 and still on the phone the proving time uh was was something like well no yeah the proving time was something like 16 seconds. So even at 128 it it doesn't it didn't seem like an outrageous number. So I'm wondering why that isn't higher. Maybe that's something about the way that they made the circuit or some other limitation that I'm just not aware of. Um because yeah, the higher you move that security parameter, uh the complexity and the proof length are are becoming larger or are or simply becoming more resource intensive for proving.

Um so, okay. Yeah. Yeah. And and he did unpack it a little bit saying uh just jumping down that at 128 bits the verifier is asking 50% more queries um than at 80 bits of security and the proof length of course is larger. Um and and yeah that's something that we already talked about. Basically this I would like I would like to understand a bit more about about tuning that security parameter possibly I I just need to do some benchmarking. Um but I would like to dig deeper into that in the future. Um so for all of these zero knowledge constructs uh the math is being done over prime fields and so with

snarks and bullet proofs I guess they're they're using some number theoretic assumptions but starks are somehow generic enough that you're working over any algebraic domain is the statement that Eli was making. Um, and and I I guess this is important somehow that you don't need to have a very specific pairing and a very specific elliptic curve. Um, it's something that's very much out of my depth. Um, but I know that when when I don't know the NIST or some other government agencies are making a statement about uh what primes to use, what elliptic curves to use, there's maybe um, you know, maybe a bit of hesitation about wanting to trust

that the government agency, you know, is giving fair uh, pairings and that there's not some trick up their sleeve. Um so I think it's really nice that there are more people uh more research groups in the world that are coming up with pairings and lifted curves that are reasonably secure and are working for the for the type of constructs that they're wanting. And then it seems again with Starks that over any algebraic domain um it should be you know it should be possible um you know in theory it's possible. I think that still in practice there's going to be known you know known pairings known curves that that will be used because optimizations uh you know can can be found there when

those are pinned down and and then you build on top of that. Um yeah so the overall idea then okay yeah I see that we're running a little late uh or we're running we're running exactly as we started um so goodbye to those of you who are headed out um so if we're doing um I think I think most of this most of this we've kind of covered that when we're doing larger proofs um you you're going to ask simply more questions But you can do splitting of the work over over more rounds. Um, and then uh I think what's maybe more interesting

because interactive versus non-interactive is is in a way assumed. I think what's at least for me what's more interesting was thinking about the potential uses or or maybe what the research is that he and his team are doing um with the Ethereum Foundation um is being able to put Starksen into uh lower layers of the network um to to gain some aspects of scalability uh possibly privacy in the application uh level. Um, and one nice use case of all these zero knowledge proofs is that you could compress the amount of work needed to be done. Um, and for those that are wanting to track state of a blockchain, light clients, uh, you know, might not

need to download the entire blockchain because you could you you don't, you know, you're not trusting that sort of remote full node is giving you all the correct details, but instead you will have proofs that you could verify the state and and still have a very small amount of data that you need to sync with the full node because you would be able to have you'd be able to have yeah the proof coming in in a reliable way and and then you and then it's going to make bootstrapping and syncing much nicer for everybody.

Um and so if if you're scaling by by putting some computation offchain um especially with Ethereum there is you know there there is a gas limit of something something like 8 million right now on mainet. I don't know if that's going to change much because that will cause much larger um block sizes. So if if we want to do more computation uh moving it offchain is is quite nice then both for computation and additionally for storage. So in the future there could be something of computation nodes and storage nodes that are you know syncing or you know pinning their state um onchain

and uh and and again if you're verifying something like 10,000 transactions you're only doing 3x uh or you're only increasing the proof size the 3x of a single transaction. So there's something to be said there where you know these side chains could play an important part of scalability. Not everything needs to go onchain and instead you're rooting trust onchain. Um and at least at least for me that that seems like a reasonable way forward.

Um, and so if you're if you're scaling if you're scaling by batching, then when we have all of these uh tokens that are on chain, um you could instead be signing transactions to a prover node on one of these side chains. Um you'll do this you'll do the same signing as you do today. Um but the prover node is going to be able to batch together, you know, thousands of transactions and then making a single statement onchain. Um and then and then you know the state transition you know balances of accounts uh can can move and again if you're using um like a Merkel prover then there's going to be a statement made

that no tokens no tokens were created or destroyed uh all the transactions were uh were done correctly and the final balances of all the accounts are are what were expected. Um and then the verifier is going to be you know committing state updates to storage instead of saying this account with this balance. Um and it's something it's something very similar uh in a way with uh with payment transactions. Um one I think one thing interesting here was that you know there's a centralization tradeoff. Um and and he said unless it's done by the miners, uh it's something something a little off topic, but yeah, um I think

centralization could could be an issue here or what what these side chains look like could be an issue here. Um and also that idea of having just a verifier commit updates to storage. Sorry, I'm going to jump in a little bit. Um that that's not just Starks. I mean that's any all like that's been proposed for all sorts of um like other zero knowledge implementations but it's interesting. I mean it's it's an obvious use case but I don't know if it's like better with starks. Yeah. Abs. Yeah, absolutely. Um and yeah and so that's that's kind of I mean we're we're kind of at the ending. I don't I I feel that I'm just reading the examples now. Um, and additionally, Alex had uh

Alex's notes had a really thorough walkthrough of what happened in the demo. I think it was down at the bottom. So, for those of you interested, you could watch the talk or read Alex's notes. Um, and yeah, so that's that's every that's everything I guess in in my notes. Sorry if that was more or less than what you wanted. We could have the meta meta talk later about how the talk was, but I don't know any Oh, I I really I thought that was great. It was super nice to have you go through these bullet points like I like and it's also really nice to see I know the the format's kind of interesting. We're so used to seeing presentations with like visuals, but like actually your

bulletoint notes and then explanations. Personally, I'm finding this really useful. So, thank you for doing that. That's at least my my take on it. Nice. I don't know if Alistister or Philip have anything they want to share. I'm still here. Yeah. No, that that was that was good. We'd have questions. Yeah. I don't Yeah, I I don't know. So the like the purpose of this is that I'm um you know I I wanted I wanted us to kick off. So if you have questions I could maybe say yes or maybe it's uh the questions turn into future topics. Um

and I and may maybe that's where we're at like what what other things would we like to do with this working group. So, I had I did have um a few things that I marked down as like notes. So, one was there's always talk about how darks don't need a trusted setup. Um but I don't understand what they do instead exactly. Or I mean maybe that's like I I don't know how a Stark starts if you understand.

Yeah. what I mean like I understand now how a snark starts. Right. Right. Um so that would be something that I'd like to explore a little bit further. That was one that I that I had a little note on. The other one was uh when they talked about recursive snarks, I wondered if I I did I think we lost you there. Are you still talking Anna?

Oh, you look a little frozen. Is she frozen or am I frozen? She's She's still frozen. Okay, I think we can still talk. All right, we'll tell her Instagram. All right. Yeah, I guess um what what does every what does everybody else think? Do do you guys have do you guys have notes because maybe we could sync all of that into Google Docs as you know open questions or maybe you guys already had had topics that you wanted to dig into.

Well, I know I want to understand how how Starks work. Um, where we're at with scalability, where we're at with, you know, actually implementing this this thing, where Starkware are at, you know, whether these things, how feasible this is right now. Um, you know, what are the limitations? That's what I want to know. Mhm. Um, but to get there, you probably want to um look into what the what the actual technology is, how it works.

Okay. Yeah. Yeah. I So, I I I like I liked Anna's question to be honest. I don't really know how to build a snark compared to a snark because a snark you're going to do the setup and then the desired outputs of that step are the verifier key and the prover key and those both become you know public values but I don't know I don't know in a stark does that just simply mean that there is no prover key and it's simply done you know in process let's say and the result then is just the proof and a verifier key I don't know if anybody on the call can answer that other keys so this this doesn't use uh public key cryptography at all. Right.

Okay. Right. So so like prover key verifier key as in it becomes input uh it becomes input to to a function. Right. So not not yeah this is not how starts work. Okay. We only have hashes hashes all the way down. That's like almost all the cryptography. H I like the sound of that. All right. Hey, Anna, you're back. Totally not. Yeah, this is why I need I could hear you from I noticed when I froze, but then I I could hear you for a while. So,

I Yeah, I followed everything you said. So yeah, that question that I had originally of like how I instead of a trust setup, but Alistister I guess not it doesn't even factor in if it's just hashes. Well, I know I think well they're obviously they said it curves or something. I tried to think uh I don't know. That's why I want to know the technology but it's not like that. Okay. So do you want to put that? It would be great to add that somewhere as a uh as a question as well. I'm taking some notes. Yeah, I'm taking some notes right now.

Yeah, we can see your screen. So, great. Um, and then yeah, so the and the other question that I had said, I don't know if you guys heard me, but it was a recursive start question. Question is something like, is that a thing? I think there Um, what else did we have the I mean there was there was a part where you started to go into sort of the transaction details and like why like

it's so much faster. I mean I think I still have a question mark as to why but it's cool to see that like to just be like okay this is what this is where it's at. This is how it scales so far. the fact that you can do like if you do you know many transactions the amount of I guess it was it was like the kilobyte size of the proof didn't increase that much that's what I would have understood it as right well this is the great thing everything is scale as logs and that's why I guess right okay and it's going to scale to way more than 10k and still be very small and that's uh

that's when even though these things are think they're still going to be useful. Guess my bias, but it sounds like it's other people's biases as well, is that it's not just the research and the mathematics behind it, but it's also how, you know, how can we wield one of these Starks um and and apply it in the world. So, I think I really think batching is is kind of where this will get used the most. um moving computation offchain is kind of necessary and so being able to to you know kind of compress many transactions you know many messages into one uh you know into one transaction that occurs onchain I think that this is you know this is important and and probably where

we're going to see it used uh at least in the beginning because who who knows uh who knows other what other applications we might have but I think in the future and again this it's also it's also where this research is going when I understand what is the relationship between Starkware and the Ethereum Foundation. Um so yeah I'd be I'd also be curious to know what it is that KOD like where KOD protocol is at because yeah Eli was kind it seemed like you know very you know very nicely but it seemed like he was ribbing KOD protocol a little bit in the sense of does this work in practice? if you have faster block times, are you going to be able to have this recursive snark keep

up with the blockchain or or was it like, you know, was it even meaningful to uh to do this? Well, I I'm happy to say that we just I think I might have mentioned this in the last call, but we were we just did a recording with Kota and it should come out in like two weeks and I'm actually doing the edit right now. So, um, definitely like if we want to do a session on them, we can use that as a primer like just to hear because I actually asked that question of like where they're at. And so they've they've released they actually have open s just open sourced their code this week.

Okay. Last week and uh they are live. So you can look at what they've done so far. Um, nice. And I think that would be really neat. And I think actually the timing might be good because it's in two weeks that we'd release it and I think people would need some time to look at what they've done and also it would be good for us to hear like feedback on what they've just released as well like from other people. Yeah. Nice. Um I think that could be a cool topic.

Yeah. like to sort of dive into how these things work before talking too much about all the exciting things other people have done doing because otherwise how would you how would you recommend doing that Alistister like how what kind of like what how what's your process for getting inside this stuff I don't know so I I sort of been reading papers and going backwards trying to work out where all all the uh this stuff comes from so I can start understanding something like the start So would that would that be a good goal then that that we maybe figure out what are the building blocks so that we could

get through the Stark paper or do you want to do you want to start at the Stark paper and then figure out if we need to take a step back? Well that's a tricky part, isn't it? Where do we start if if the paper if the paper Oh, sorry. Please. what you doing? Uh um so if the paper is the goal, we could try we could try to do a readthrough of the paper and then and then we might come up with a road map of okay these these things are important and we don't you know we don't grock it yet so we got to go learn that and then and then that might also I don't know that might also be a nice sensation to

read the paper and then come back you know some weeks later and go aha um and and we might get more out of it. or or yeah some some people suggested we start with a paper some people suggested we started with metallics post starts right oh yeah which are also nice but also get very uh involved quickly oh yeah has anybody else tried to read them because I made it through the first one and and it was it was a lot I had made it through the snark ones I guess the previous afternoon so I was trying to power through but I I realized I was, you know, I was out in the ocean swimming for sure.

The first one's very high level, but by the the third one is full of um Python snippets and examples and and and math. So, it's it's interesting. Uh it's actually very hands-on. So, I'm sure the the developers have quite appreciate um that. Okay, it right now. Um, I think so. I think the idea of this was to do the highle session which I think you've done really nicely because I think I think it was it was quite

straightforward to follow most of what you did. There were parts where you even got like a little deep for for my knowledge, but um maybe it is like I know that that was the original idea a little bit was why don't we do this highle intro so we understand what we're dealing with and then possibly go through the paper but I I wonder like paper versus metallics post which is better the posts which do you think would be better for this format? because maybe the paper is just something you read on your own, highlight what you don't know. Whereas the blog post could be something we could actually like dig into.

I don't know. I haven't even I haven't even looked at the paper, so I I really can't. Blog post looks like it could be a little bit more manageable in a session. We can also leave this as a we can put this question to the group as well and just like see what people want. Um but I think that could be the next followup is to start going into this one way or another either through his posts or through the actual paper.

Yeah. Yeah. If nobody if nobody on the call wants to raise their hand to you know to pick the next topic then then let's pose it to the telegram group. Yeah, I think that's good. Um, and I think another thing is like I really Matthew, I thought you were great presenting. So, if you want to do any other presentations like this, I I really at least personally I followed you really really nicely. So, yeah, if you're if you're like I hope you're walking away from this theme like, yay, because it would be great for you to do it again.

Yeah. Thanks. Um, yeah, I I would be I would be down for that. I think I'd like to prepare a little more. Going from, you know, a Monday a Monday evening saying yes to presenting Thursday morning. I didn't really prepare anything other than reread my notes. Um, but yeah. Um, I I would als I I think I would like to figure out the format because I'm agreeing with Alistair. I like doing this highle overview. Um, but that was more me sharing. I I would also like to I'd also like to be a little greedy and have someone present something I don't fully gro yet or figure out how to do an interactive session where as I've never done this before except for in university time and in in university time it was maybe preparing for a midterm or a final and

as a group one person would answer a question but we don't really have a textbook full of questions we're trying to answer. So I'm Yeah. So this is where I think we're gonna have a shortage of questions. Yeah. Yeah. And maybe and maybe a short like we don't have a I don't know. We don't have a teacher. So there So I'm I'm just going to throw it out there. There are Techneon like there are talks from Eli at Techneon where apparently he he's supposed to be unpacking Starks as well. I think that there was there was two that are supposed to be very technical. I wonder if that is going to be I wonder if that is going to be a better place to start than reading the paper. At least at

least for me when I don't fully understand the math I do like having a little bit of a human touch as opposed to just words on the page. Um sure. Yes. No, the talk would be good. I So what we kind of need to do uh is somewhere to have a high level overview of what the tools are that that go into a stock. Someone must have a page somewhere, right? Is I guess we want to start with pen and paper, right? As opposed to trying to build I mean trying to build a circuit would be way too much right now. At least for me, but is is that is that the next step that we want we want to do the pen paper mathematics and understand this a bit?

Well, understanding the mathematics that's hard. I don't think you want to go like how do you want to understand the the math Alistister? That's your point. I I do. Yes. Yeah. I don't know if I want to understand the math and then explain it to everyone here. You don't want to do that or you do want to do that? I'm not sure I want to do that. No, that's going to be tricky. It's always No, I could maybe solve it.

Is this Is this a monad? Is this a monad scenario? You're gonna you're gonna, you know, open that door, step into the next room, and then then suddenly Yeah. zero knowledge proofs. They're burritos. I don't know this reference. It's very All right. Well, listen, I think what we should do, I think I think given that we're now we are having very much a meta conversation, I think it would be great to include the rest of the group in that. Okay. Um, so I would I think if it's okay for you, I'd like to wrap the session and say thanks again for doing this. I feel like people are going to enjoy this video. I think your voice is going to be very clear, so that's good.

Um, I don't know how these questions are going to come through. We'll share this video. We'll share with the group and then we'll I mean all the questions we just raised about like what to do next, how to do it next, I think this is still something we need to figure out. Um, and yeah, I'm really looking forward to seeing what we do next. Yeah, great. Thanks for I want to clap, but I think it makes no sense on uh on you. So, I'll just Yay. Yeah. Yeah. Ca casual presentation over formal. Um really really glad that we kicked it off, guys. Thanks for thanks for joining and looking forward to the next one.

Nice. Cool. So, I guess you can Yeah, you can shut it down.