Proofs of STEEL: View Calls using RISC Zero - Rami Khalil | RISC Zero

thank you hey guys my name is Ramy uh I'm a senior engineer at risk zero today I'll be talking to you guys about steel our library for performing view calls um using risk zero um if you're unfamiliar with risk zero uh we provide a general purpose uh ZK VM um that you can use through riding uh Native rust programs and you can use this uh VM in ethereum in your smart contract by just uh basically calling a proof verifier from your contract um using the proves you generate in the VM and this allows you to write your application in what we call a ZK co-processor model or basically if you have a very intensive uh compute aspect um in your application that you don't want to perform in your contract to save on gas you can delegate that comput ation uh to the ZK VM and only verify um the proof of that computation being performed correctly so your contract lives onchain delegates the computation to some single offchain uh approver and verifies the proof to proceed so this is simple to outline however if you're a developer you want to write complex uh application specifically if you're an ethereum developer you might want to look at the state of other ethereum contracts for example a price Oracle or inspect the balance of some other contract so if your offchain compute part is not able to easily access this information you're not going to have a great experience so steel um sort of fixes that for you in a pretty uh easy to use manner and you might already have some experience trying to access manually uh some storage uh slots in ethereum you might know how cumbersome it is for you to try and calculate the exact slot that you want to look at in storage try to get um authenticated access to that slot through your RPC node and then interpret and Par your data it's a lot of code to have to deal with it's also very uh prone to errors so this entire process is something you don't have to worry about if you're using the steel uh library and um another part that um you also don't have to worry about is how to authenticate this data so if you're not very familiar with the ZK Cod processor model or writing ZK proofs in general not everything you directly throw in ZK uh gets magically authenticated for example let's say you do want to uh access a certain slot then if all you do is ask the host or the native machine that is running your ZK VM for that data the machine could lie right could give you a different value than what is really there and that's why you have to use uh the proof to authenticate the lookup and then only when that happens within the ZK VM do you have something meaningful like a soundproof that you can use on chain and be guaranteed that no one is lying about the data that was used in the computation and um some other platforms offer ways for you to look these slots up they're not very user friendly um because you might you need to know the exact slot instead of delegating that ethereum this is something you don't actually deal with at all uh normally uh when you're writing something on chain right you basically call some view call tell it for example I want to get the balance of and then the contract that other contract figures out uh what the storage slot to be accessed is and you're happy on chain but then you're just paying gas for all this or your users are paying gas for so this is not a very uh nice devx if you want to shortcircuit all that uh to have to look up the slot to know the slot manually or calculate the slot manually so what steel allows you to do is very simply call uh issue the view call from within the zvm program and what that looks like is all this code I'm not sure if this is uh visible like is does anyone have any problem um with the visibility of the code it's kind of bright from my perspective but I think it might be better from yours yeah so first part of that is that you just declare the uh ABI of your view call right um in your guest program um and if you're somewhat unfamiliar if you are unfamiliar with what a guest program for the zkm is we have a workshop going on that you can come to at any time I'll talk more about that after the presentation um but essentially inside your guest program the first thing you do is just provide the AI for the view call that you want to reference from within the zero knowledge proof and you define these uh structures that prefer to the uh ABI in which contract to uh interact with using the address uh to issue that call right so so far so good you define what you would have written normally in solidity and then you then point to a contract and then uh within the actual body of the program being executed you instantiate um this view call object and you use it with a certain chain spec so you don't want your program maybe to run arbitrarily on any chain you're maybe writing this for specifically uh optimism or ethereum or test net um for security reasons and just uh basically calling the command to uh execute this and read the result gives you what you want under the hood there is a lot going on specifically um within the risk zero ZK VM the evm is being executed so if you're familiar with um another tool that we released uh a few months ago called zth which is a ZK evm we did the same thing we took a standard rust crate for evm execution which is called revm combined it with alloy another rust crate for um coding decoding a lot of uh ethereum types and created as EK evm Prett quickly in three weeks so under the hood of Steel we just letting you feed input to that evm that would have been executed onchain and just do it offchain using a certain uh block as a reference and at the very end just get the result of that execution in your ZK program so if you had also used zth you know it takes a lot of time and um it um needs some coordination to retrieve the necessary storage data from some RPC node so with the magic of Steel you don't have to worry about how that coordination happens um the evm execution simply looks things up verifiably as it goes along for how however long it needs to execute your view calls and this is called the pre-flight phase essentially your um your program is executed outside of ZK just to get an idea of which storage slots are required and then just preload all the data that's NE necessary for authentication as and then feed that as input um into the uh executor and the prover so in terms of performance um you could do a lot more compute of course offchain than you would in an onchain world because there is a gas limit even if you have infinite ethereum or if you're into burning uh tons of money there's a gas limit on your block right and there's also a stack limit so you can't really go as deep as you want uh in terms of your view calls but in the offchain world uh these limits are you know kind of stretched they're more specifically you could we've tested this with up to a 100,000 view calls which might be a bit more than you're used to doing in your applications but maybe you have this thing that wants to inspect the balance of every single token user for some reason that uh is up to you we're not judging you for that but it's your thing uh you could do that now with this um improving time per call is also uh pretty good and expect it to get a lot better um as we improve our tool chain um so one thing you have to keep in mind when using all of this is um it could be that your offchain uh proving happens as of a certain block right it it will certainly not happen as of the latest block because that block has to be mined for its fed in to the proof and then it can't you know reference itself but um right for for all the authentication to make sense once you do receive your proof it is going to tell you um according to the data read as of some block hash this is the result verifiably right and in ethereum we have this look implementation where um we can only inspect block hashes uh uh natively in the contract if the block hash is not older than 256 blocks so you just have to bear in mind that um you're giving up being able to look at the latest information right now in exchange for being able to access unlimited information um but uh yeah that's uh basically the primary uh disadvantage otherwise um it's nice so yeah pretty short talk um there's a lot more to discuss however and if you're interested in that uh we're running a hacker house uh that is only a 10-minute walk away uh so please give us a visit um and if you're interested in learning anything else uh about risk zero how to use it um yeah we'll be here thank [Applause] you so I did not take up a lot of time at all so because I want questions um a pretty uh direct demand but [Music] yeah all right uh so basically um in a regular evm node um the node is able to access the entire storage try to look up things as it executes transaction and that storage try is kind of big right uh this is just referring to a sparse version of that try that only has the nodes that are required to look up the storage slots that your view call is accessing um and this and this is uh just what how we refer to it it's a small inmemory database that we had to create to make the proofs uh efficient [Music] yes otherwise it's not going to give you the proofs uh that you need can can you just uh like by a show of hands how many people are familiar with the ZK core processor model or how many people have used the live ZK proof in their contracts okay not many how many are planning to that's better yeah well hopefully this makes your lives easier how many are not planning to like how many you know feel this tooling is incredibly mundane or useless or just not appropriate for the use case good otherwise you would not be seated here that's uh that makes sense right yeah well the cost on ethereum is just the cost of verifying a growth 16 proof which which is depending on the data you attach to it could be something around 300,000 gas um but the cost of proving creating that proof um there are two ways to measure that um the first thing is how many cycles your proof is taking so here we have this metric like it's a six million Cycles uh for a single view call and that translates to about 30 seconds of proving on a single commercial GPU so this this is something you find in your uh laptop not even you know not the 4090 or those large instances um so once you have that you've created your Stark right but because uh that is too large to verify on chain you have to do the Stark to snark uh phase of all this and um then that is a separate cost that is basically like a fixed addition in terms of proving um because the Stark proof that you receive uh doesn't get larger like with other platforms uh with the size of your computation or the size of your input um how fast is start to depends on your instance because you can get it down really fast if you scale it up it we run a standard snark prover um it's the um you were saying this this morning yeah but the Prov underneath is just the ciron sended ciron prover oh yeah it's rapid snark rapid snark so you're basically proving like a million constraints using rapid snark so how fast you can get that is your thing [Music] I can repeat the presentation for the people who came in late that's otherwise there are no more questions you have 10 minutes back yep oh you don't have a question sorry cool thank you very much [Applause]