New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

ZK-Coprocessors: State of the Art & Future Directions | Severiano Sisneros - The GraphSemiotic Labs

Ethereum DenverWed, Oct 9, 2024, 12:00 AM

APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply

Transcript

hello okay hi hello everybody uh my name is Sev Naros um I guess we'll get started here so I'm a cryptographer with semiotic Labs we are cordev of the graph protocol uh and today I'm going to be talking about ZK co-processors and so just real quick to get a a feel who has heard of a ZK co-processor okay a handful of people nice uh so my my goal with this talk really is to kind of just uh talk about them at a at a high level so for those of you who haven't heard about them hopefully like you'll come away with an understanding of like what they are and how they uh fit uh in this blockchain context um and then I also want to talk about so we we're working on the graph protocol I want to talk about how the graph protocol can use ZK Cod processors or be used as a ZK Cod processor um and the things that we're kind of planning for this coming year uh to build on top of it all right so let's go ahead and get started okay so up first just to get a feel of like what core processors are right so it anybody know what this is It's a Intel 386 so an early 90s uh processor uh very popular but it couldn't do floating Point arithmetic very well and so then they invented the I 387 which is a floating Point Unit A co-processor which would supplement the 386 and so basically 386 was offload flowing Point arithmetic to this 387 and then when the 387 computation feed it back to the 386 uh and then the 386 could do stuff from there uh so that enable all kinds of things right so that Ena scientific Computing that enables statistics calculations all kinds of good stuff could be built now with this system now this here's another example of something that uses a co-processor so this is a smart card uh a lot of these smart cards they have a little microcontroller in there that is used to you know handle IO from a card reader and the the LC of the card a lot of them also do cryptographic signing right so they'll you know electric curve signing of messages you Ed like on authenticate with that card uh cryptographic operations for a lot of us we we know here uh they're pretty heavy duty right doing modular arithmetic with large numbers uh you can't do that on a microcontroller with any reasonable time you'd be sitting at your terminal for minutes waiting for your transactions to finish uh so they invented you know a little crypto core processor this is alongside the microcontroller and you can offload signing and all that stuff to that crypto Co processor and again another co- processor right so the the gpus and so the the point of this is to show co-processor is a broad definition right there's a lot of we had a Flo Point units we had module arithmetic units we have uh Graphics processors like it covers all big space it's a broad definition they all kind of have like one core thing that they do and it's they accelerate the performance of the system that's managed by the CPU so that's kind of like the core piece of a co-processor it accelerates and so now let's get into blockchain so the blockchain as we know here it's a new kind of computer right it has different uh strengths and has different limitations and so it also needs a co-processor right and so now we have a blockchain co-processor it's a new kind of co-processor to offload computation from the from the blockchain uh and then I I highlight here just we're talking about blockchain co-processor first not directly jumping into K cor processor and there's a reason why I I'll get into and so now to try to build some intuitive understanding of uh of what a blockchain co-processor is doing let's assume that this balloon uh represents all of the computation that you need your smart contract to perform uh so you need some result from some computation uh and this computation is like a big heavy duty computation if you do all this computation your smart contract you're going to be spending a lot of gas right so big computations big gas very expensive uh and you may not even be able to get it done so enter co-processors blockchain co-processors so a blockchain co-processor uh we introduce some little extra muscle so Hand squeezing approving system for example and it kind of distorts that uh computation so instead of all the computation having to be done in your smart contract we can now kind of like shift the computation around and so now we can have these co-processors which are doing the computation uh and then we have within our smart contract maybe just some little piece uh of computation that just verifies that what the cool processor did was correct so kind of to build these analogies a co-processor accelerates CPUs in like uh normal land a blockchain co-processor saves gas that's the whole point of it so you have broad definitions everything's a co- processor the the key piece is co-processors save gas okay now for a little more uh less abstract uh example so here is your computation without a blockchain Cod processor you've got your smart contract you've got some expensive computation or expensive calculation that you need to be run uh you've got your input and then you get your output and then whenever you want to use this you know you make your call to your expensive calculation with your input uh costs a bunch of gas because it's a big heavy duty computation uh and then you get your output and you do something with it in the blockchain co-processor uh situation you have a different uh something different gets executed in your smart contract so instead of doing your big expensive calculation in the smart contract you just do a cheaper operation verify expensive calculation and this takes in kind of three inputs now so instead of just passing your input all the way in you also take your input your expected output of the calculation and then some proof that this was done correctly and then your verify expected calculation returns suable flag says is valid so input does equal output and the proof says that it does uh and then and then you can use that to do something right so kind of the flow offchain you have your prove so your prove is proving that your output equals this expensive calculation on your input you get your proof then onchain you run verify expensive calculation on your input your output and including your proof and then if it returns is valid do something without so you get kind of you you get the same result you still get to do something with your output but you get to save big on gas by doing this expensive uh calculation offchain and then proving it somehow okay so now blockchain co-processors uh what is a ZK Cod processor why why differentiate ZK co-processors and so this gets into kind of like one of the core things that we do with blockchain right like trust is one of the biggest pieces that we talk about so ZK co-processor the distinction comes down to like who do you trust and so now we got to talk about trust assumptions right and so I've kind of like outline like four highlevel trust assumptions that I think kind of uh exist in our space right and we kind of use either implicitly or explicitly so kind of like the the strongest trust assumption is basically trust and Authority right so you have one Central Authority whatever they say is truth um and so you could use in your blockchain pro uh co-processor you could use uh you could have a blockchain Cod processor that is built off of like an authoritative trust assumption right so here in that case your prove rather than competing any type of proof it would just be the authority signs output is expensive calculation it is correct right so they have a they sign it they say it's correct your proof is the signature and on chain you just verify did this signature come from that Authority similar things right you have Quorum right so this is M of n trust so like kind of threshold trust this is kind of like a multisig right so you can imagine uh you know Dows that kind of thing you have a you have a group of people who you trust at least uh half of them or at least some threshold of them are going to be honest and so then you can do the similar thing here right they all sign a message aggregate it on chainy check you know did at least M people sign this then you're good optimistic uh it doesn't quite as fit as well in here but you you get a similar thing right you have oneof end trust assumptions here and then trust list all the way down here this is like this is the Holy Grail right this is why people love snarks uh because you no longer have to trust anybody right so now your proof here becomes a literal proof it becomes a ZK proof uh that your calculation was done correctly and so that's the that's the Holy Grail right and so really that's my I like breaking it out this way and talking about blockchain co-processors kind of abstracted because I think they they fit and there's there's valid situations where you could use each of them in these with these assumptions so there we go uh so now we we've talked about blockchain co-processors we talked about ZK co-processor trust assumptions uh so what are people doing with this right what are people building with blockchain co-processors and ZK co-processors and so the the first one I I lay here this one is kind of a this maybe just more of an observation right or maybe a reccon uh saying layer twos are are kind of blockchain co- processes or maybe they're more correctly they're using blockchain co-processors to prove you know the the state transition function uh or the execution of a bunch of transactions in a block and then outside of that co-process outside of that proving then they have some Logic for handling you know sequencies of transactions and then for like updating state in the layer one so layer twos that's a that's I think a good example of where ZK co-processor is being used more explicitly where the ZK co-processor word is being used uh is kind of like two big places that I've seen so I've been kind of you know surveying trying to track who's doing what these are kind of like the two big ones that I've seen one is like scalable Computing right so like literally taking your your big computation doing it off chain making your proof and then verifying it on chain and so the abuse cases here that I've seen the most are this AIML and so for example like modulus labs they have a setup where they're using snarks to prove this is like literally one of the things that they're doing they're using snarks to prove an appraisal price prediction from a machine learning model uh I think they like a gradient descent algorithm and they're attesting to that proof on chain right so they're generating snark proofs testing the proof on chain uh and and then they have kind of like a snark proved prediction the other big one is related to historical data so retrieving historical data from a blockchain and proving that that data was correctly or was actually committed to on the blockchain right so this is kind of like you think of events get emitted from from your contract executions uh you can only track like blockchain data back like to the Past 256 blocks so if your data is older than that you're not going to have uh you're not going to be able to directly access that data from the evm so you need some way to prove that this event was actually emitted uh and to do that you know we have uh inclusion proofs Mar inclusion proofs to a block and then you could batch a whole bunch of these together make a snark that all those markal inclusion proofs are correct uh and then now you can use that snark proof onchain to say oh all this data was committed to on the Chain uh and so yes we see that in storage proofs and then people are doing computation on those proofs too so uh not only you prove this data was onchain you also do some computation on that data and you prove that that data was done correctly and I also have privacy down here and I have some question marks on it because I I just saw it and I didn't have enough time to dig into it but it's really interesting right so ZK the true ZK is zero knowledge uh every all these other things are like the snark part of ZK snarks but privacy is the thing that gives you anonymity gives you uh the ZK piece and so this is just a a chart of the the companies that I've seen and I'm sure I'm missing some and I'm sure I'll uh meet some people here who are also building this uh but this is kind of like where people are kind of lying right so we've got the AI side we've got modulus Labs who are doing some pretty amazing stuff there we got Giza Ezekiel who are building like AI proving infrastructure they got space and time and Aura who are uh doing both Ai and also you know proving computations on historical data and you got axiim who kind of kicked off the whole ZK co-processor uh meme and these lrange herot brevis they're all kind of doing similar stuff with historical blockchain data then over here we have infrastructure level so here we got like Bonsai by risk zero uh which is uh you know a big scalable uh risk zero zkm Nexus has their own zkv M and they're building their own infrastructure for uh generating proofs uh same with uh Neil and then and then over here poto so I haven't had enough time to look into poto but he have something about privacy so so worth looking into more and seeing where they fit in this space okay I am blowing through time here so I'm going to try to speed things up right so this is just kind of uh high level trade space uh performance right so whenever we talk about snark proving performance is always kind of like one of the biggest things how fast can you prove something especially if you're talking about like an AI inference and for instance already expensive how much more expensive is your snark going to be proving uh being on top of that so these are the different ways that people kind of handle this uh so one you can start with a custom proving system so rather than using like plon with kcg uh you can kind of design your own proving system from the ground up to be uh super performant for the specific competition that you're trying to prove and so modulus Labs has done this with uh for ML proving so they just published a paper on this proofing system remainder uh which is like tailored specifically to the types of computations they want to approve uh pretty amazing stuff right so but pretty deep in the stack it's like at the base layer of your stack then when you go like kind of one up you have your proving system and then now what types of circuits are you trying to prove so you have guys like Risk zero uh Nexus the zkm crew who are all building uh basically Z kvms making it easy for people to develop applications uh that use their own knowledge right so you you write your code like you would normally write code compile it to your zkm and then now you can prove uh that code is executed so general purpose very easy to use but it's not going to be as performant as like an application specific proving circuit right so this is kind of like what axiim is doing so axiim is uh creating a framework where people write circuits and making it easy to right circuits that might be faster than you know than just proving with a ckvm um there's other things right so we've got this infrastructure uh these infrastructure groups are building you know different provs like is your pro module like can you swap out one proving system for another can you swap out Starks for uh for plunk say uh so important consideration and then always like this whole thing is getting proof back on chain right and so how fast how expensive is your is your smart contract verification um another one interesting here like data availability so similar how you have like data availability problems with l2s you have the same kind of data Avail availability problem here right the the problem is to prove your to verify your expensive calculation you need your input data right so you need this input data and the output data to ENT your proof right you need all this data to be able to actually prove that that or to actually ver run your verifi algorithm so if this input is very large um that's going to be pretty expensive so you probably have similar uh so then there's also similar Solutions you could use for data availability like maybe just kick off all the data somebody attests that data uh and then like yeah uh yeah attest to the data uh and then you know do your verification assuming that that attestation is correct so things you can do here similar to what l2s are doing okay so now the graph in three and a half minutes the other half of the presentation all right so for those of you who aren't familiar with the graph the graph is a decentralized blockchain data indexing and querying protocol uh and so yeah big thing here is decentralized right um this is just a our cute little figure showing you know kind of what the indexing process looks like say you've got your contract emits a bunch of different events this is how the events get emitted on the blockchain it's Mass if you want to be able to access your events you want you know all your yellow events uh you need a write an indexer to index all the stuff so you the graph does this for you right sets up the blocks makes indexing easy for you the graph is live right so the graph is running uh this past quarter quarter before it saw almost a billion queries so it's out there it's being used um and here's an important thing at least to me the the graph is a blockchain network so here I'm I'm borrowing phrases uh it and specifically like what a blockchain network means is the graph can make strong commitments about future Behavior right so the graph isn't a uh a company it's not an A company that might shut down if it doesn't get funding right the graph is a blockchain network it has a token it has incentives for indexers to be producing and doing what they do so as long as the protocol is live as long as indexers are working uh the graph will exist right um so that's an important thing here and then the F the the the final thing here is the graph is a blockchain co-processor um and I have an asterisk here because currently it has high trust assumptions and so let's dig into this like the graph is a blockchain co-processor the first uh time that I really kind of saw this idea was in Brandon one of the co-founders of the graph uh is graph day talk in 2022 he called it a read oriented rollup um so basically right reading data from the blockchain doing some processing on it so you know your query Transformations and then returning that data to the consumer um yeah and so currently the graph supports graphql queries so that's the type of like computations that you can do on the historical data soon we're going to SQL and more right and so I have a link here if you can access the slides uh go to this link and check out this toet data pla by Adam Fuller okay so the graph is a blockchain Cod processor with high Trust assumptions so the graph started out like many decentralized networks do uh as centralized right and we're we're progressively decentralizing removing points of centralization and one of the points of centralization is the way that we verify that data is correct is we have an arbitration Council who basically manages disputes so if somebody suspects an indexer of serving bad data you kick off a dispute with the arbitration Council and then the council decides who is the uh who is correct here and so so in the blockchain co-processor space we could say the block the graph is a blockchain co-processor with trust in an authority a trust in that arbitration Council Council and so the big thing here is lowering trust assumptions it leads to greater composability stronger commitments and enable stronger commence about future Behavior so that's what we want to remove we want to remove arbitration Council we want to be able to provide stronger commitments we want to make it easier to integrate uh and put less trust in humans have more trust in math um yeah so this is just kind of like the outline we're going to build a snark these are the types of things that we need to prove one we need to prove that the historical data is correct so this is like uh axent hisor historical data proofs you know this is throwing data came from the blockchain another big thing is proving that no data was excluded right so we're indexing data if you if you're trying to build a pricing Oracle based off of you know swap events if you you can skew your Oracle by emitting data right so you can still prove all the data is correct but you also but you've skewed it by by excluding data so we we can't allow that right we need to prove that no data was excluded um and then any computation that you do you do an average you need to prove that that average was done correctly on the on the data um and then other things for the graph that's that's a requirement right is all of our provs need to be open source uh and uh because we're you know a decentralized network everything that we do is open source everything that we published everything that we put out it's all open sore it's all available um we're decentralized uh it it's a Unstoppable blockchain Network right and so the proving system needs to be able to integrate with that type of network uh and then queries you know we're serving uh queries with with high throughputs so our proving systems need to be able to keep up with that and then modularity is actually pretty important here so we don't we're not going to be able to snark proove everything and we probably shouldn't snark prove everything uh we should be able to have different proving systems for different customers right because different customers have different requirements and all that stuff so yeah these are features of the system that we get out of the graph by uh by improving the trust assumptions um and yeah where are we now we're currently like in the design phase right and we're focusing on proving kind of arithmatic queries so rather than proving graphql queries or proving SQL queries directly we're proving like arithma queries like a sum an average that type of thing first um yeah and we want to ultimately right we want a ZK snark based solution that we can verify onchain with trustless and so that's where we're working if you think you can work with us or if you're interested in this uh reach out let's talk that's [Applause] all

Automatic transcript — names and jargon may be misspelled.