Unlocking Boundless Execution with Steel

Transcript

hello everyone very nice to see you today hope your travels was safe to Bangkok so I'm Sasha from risk zero and let me just adjust this a little bit I'm frequenly tall so okay so today I'm going to be talking about steel which is our ethereum library for the Z kbm if you're familiar with the zkm that's great but if you're not don't worry I'll run through uh the basics for you as we go forward so I guess steel is nice we have a lot of metal uh metaphors with rust and boundry and alloy and all these other ones so steel is from risk zero it's an ethereum library for the zkm so that's all great but what is it actually unlock and then we'll talk about how it actually works so here's an example that igen layer uses steel or how they use steel

specifically they have a metric ton worth of uh view calls and slos they want to carry out uh it's physically impossible to carry these all out in one transaction in fact they want to compress 40 blocks of execution into one transaction ction which costs around 1.2 billion GS that's not possible and so you know we worked with the team for a while uh and uh they've been start they've started using our steel Library so steel here for about $10 to generate the proof they've run 40 blocks worth of execution and it cost around $10 on L1 to actually verify the proof now of course there's a trade-off there's latency right so to generate the proof there's latency but in fact for is use case that's fine but bear that in mind if you're thinking about using steel but

we'll go through the trade-offs as we go for further in the presentation actually 1.2 billion is I mean actually gas is pretty uh pretty low on execution front like computers are super quick compared to the evm and so you could run much more execution and this is the the kind of the the topic we talk about with boundless execution boundless is a is a product from risk zero and here we're talking about uh we're going to have a pro decentralized proving Marketplace but here we're talking about boundless execution using steel cuz you'll be part of that as well so what does it unlock well a limited execution at a constant gas cost the constant gas cost is just a gas cost of the verification of the

proof and the price of execution proving is just exponentially going down it's a tiny fraction of the price of onchain execution and the price has just been going down and down since z kbm uh so the price of proving is just getting lower and lower so i' I've said a lot of reasons of why to use steel in sense of you have a large execution you want to carry out but you can't to carry it out without paying a very large amount of money for the gas so what what is steel you can think of it as smart contract execution proofs and we can break that up a little bit so first we can do smart contract execution and then we can have proofs I won't bother you too much because I'm sure everyone knows what smart contract execution is but some famous examples you want to swap

something you got to do some execution based on uh checking the balances and making sure that everything is legit and actually carrying out the swap by updating the balances right so usually you have some sof State you want to change and carry out some calculation against same without any liquidity these are from un V2 so a usual workflow uh in smart contract execution and I appreciate this is a little hand wavy but it helps to explain steel is we have an input which is a transaction that transaction is basically requesting a state update from their inputs the arguments you can kind of think of a smart contract as having some sort of rules for the logic and also uh pointers to the state and then we can kind of think of the VM is well the the VM the

stack and it's going to go through and do the instructions and actually get to that state of date so that's great uh good question is that when you start taking execution off chain uh comes a bit of a problem because the whole point that the state onchain is for it to be verifiable now what do I mean by verifiable I mean if we want to execute on X and X is six uh we would like that to be a consensus that X is six because if we take it off chain and it's 12 all of a sudden then our execution isn't valid so blockchains are fantastic at this execution needs to be verifiable there's a whole consensus and everything like that to make sure that the stake in each smart contract is valid uh at the per in time so we need to keep that in our basically in our

workflow as we go offchain so that needs to be needs to stay and smart contract execution is limited the evm gas is expensive it ler choose help but it's still the execution is still pretty limited uh for you know more modern use cases so we've go through smart Contra execution let's have a look at what proofs the zkm is very straightforward if you've uh ever run any ZK things before you may have used a domain specific language uh run written circuits yourself in the zbm you don't have to worry about any of that we handle that for you you just write some Rust code it compiles to a risk 5 Target and then we handle that with a big risk five circuit generate proof for you so usually in a VM you have a program some inputs and you get an output the only

difference with a ZK VM is that you still have a program still have program inputs we call those a guest program just VM terminology you get an output but you also get a proof that that program ran in the right way and it could be a stock or a snog so we have some terminology here we have guest code which we should call the guest program so actually it compiles to an elf binary targeting risk five and that's why we get the name risk Zero from and we have the zkm that you pass it through and you get what's called a receipt don't worry about that I'll explain that a little later so you can think of Steel as smart contract execution proofs so actually before we saw we had rust code through the ckvm still allows you to write some slity code in the ckvm and compile that and

execute against that so before we we saw this workflow where we had an input for transaction we're asking for a state update based on some rules and the smart contract now with steel it's a little a little bit different because we have some steel code in the zbm and that's actually carrying out some execution and basically the input transaction and the evm here always doing the same thing when you use steel they're going to send through the proof in the call data and we're going to verify the proof onchain that's pretty much all the evm is handling and and some state of dates so then you can think about the smart contract as keeping the state and the logic will be offchain using steel so how does that work exactly a good question so a fundamental operation in solidity is a view call so when you

check uh for example a balance here on erc20 contract very straightforward I want a balance of something in order to make sure it's legit so we use alloy in the ZK BM so alloy is a rust library and for for Sol but basically giving rust bindings so here you just write in a handy Soul macro they have you can write any solidity in there here's an interface that declares a function signature of a view call that we want to carry out in the guest program within the ZK BM so here we're just going to check some balance so here we have the solidity uh code at the top and we have what's called a guest program now if you've used this ckm before it's been familiar but uh let's walk through it so

we have a call there with balance of call and um in the returns object we're actually instantiating a contract and we're passing through this evm environment on returns line and then we just have this assert line here which says hey if the balance is bigger than one then this proof will basically be valid and this uh this guest program will run and then we have some boiler plate in the bottom that I'll get to now this isn't particularly exciting CU all we've done here is call a contract View call uh instantiate it and then check the balance make sure it's larger than one for the example for this Workshop that it's just a stupid example but in general what is actually exciting is if you've used a zkm before there's a couple things you have to ask the first question is the zkm guest program has no

network access It's usually the guest program is uh well entirely it is a pure computation you cannot there's no file system there's no way to access the network so how am I calling an RPC cuz evidently I need to in order to get this balance so that's question and then other question you could ask is how can I trust this VI call data within the zkb right like maybe there's a malicious op CEO maybe maybe it's out of date or something or stale couple of questions that are very worth asking in now thankfully steel fixes most of these things for you in the back in the background uh and that's what we're trying to do with abstracting these away for you so you don't have to handw write these like storage proofs all by yourself so we use rvm within the guest program when you write steel uh when you

inst ITI still all of this is handled for you so you don't have to worry about it so I'll show you how that works so there's a host and a guest we've seen the guest program that's that was this one where hey I want to do something and based on that I want to do something like some execution based on some smart contract State we'll get to how it's veriable in a moment now that's handy because on chain we usually have a view call and then do some execution based on it or something rather like that so we want to carry that out on the guest program that's great as I mentioned the guest program has no network access so what we do is we have a host program the host program is another file in your workspace in the cargo workspace and that one does have network access and

can set up what's called an evm environment or we call it for steel so it's actually going to talk to the RPC and usually the host program is in charge of passing inputs to the guest program maybe getting outputs from the guest program and doing something with them you can kind of think of it as like a script wrapper on the guest program now in this case it's going to actually call the RPC and get the data now it's it's great to just call the RPC the balance and say it's and give it to the guest that's fine but that's not enough because we can't trust that necessarily especially with this like what chain is we getting it from we have to match a lot of things here so we also ask for the mercel proof the Merle storage proof from the RPC and obviously block metad

data so to match that against so usually the block hash and we pass that through to the guest program uh and in the guest program when you saw this code you didn't have to do any of the Merle proof verification this is all handled for you when you just instantiate the contract and do the calls but what's actually happening is that it's verifying the mercal storage proof within the guest program and remember the guest program is the one that's being uh proven so if it if it verifies you also have a proof that this uh this view call data matches the block has that the RPC gave you which is great but not enough yet and then you do some execution on it and you get a receipt right so now we have some sort of at least a little bit more verifiable State than we had before and

a host program is very straightforward we have a provider RPC URL all used to that and we build this environment uh and this environment in this specific case has a spe specific type excuse me which is the E evm environment next up is a very important line is this pre-flight line and pre-flight is the one doing the uh collecting the RPC data to build the EPM environment and this line will handle and um mute the environment here to give it all the required data including mle storage proof for the guest so now the guest has a way of basically verifying that the view call data matches to the at least the block hash it was given and also in the guest I had these this is the full guest program now so it's not

too long you can see that we've read the input at the top we got contract and account which is useful because we want to know what account we want to check against and the token contract and the input is just smart enough to read based on the types you can just write in. read and it'll read the input from the host to the guest and we've seen this before and we're going to do some committing at the end which is also important which we'll get to in a second so thinking about the like pseudo code for a steel contract a small contract that uses steel we're going to do something and we're going to pass through What's called the general data which is the outputs of the guest program and the proof and we're going to validate the journal and we're going to validate the steel commitment now that

will get get get into that second what you really the meat of this is we're going to verify the proof that this guest program executed this logic of chain based on some view verifiable view call State and then you can do do something else after to do something else is almost always going to be update the state based on what the proof want because at the end of the day you want to take logic off chain and then what you want to use the onchain version for state state that is under consensus so what does this look like on chain without steal you can see a contract here as as an example that checks a balance and if it's bigger than one as we've seen we're now going to increment a counter so that's the state update I mentioned now with steel I appreci that it looks much more

complicated and it probably does probably is but but this is the same every time you do no matter what execution so if this was much more complicated it would still look like this and your execution would be offloaded to the rust file as opposed to ins solidity so here uh is a couple of steps and there's this thing called a journal which is what the guest program writes to you can think of it as a journal the guest program writes outputs to it uh you can write you write your public outputs to it and you can write anything else to it we're verifying that that's fine you but what's important here is that require steel. valid commitment line which we'll get to in a second and then we're just going to verify the proof and only if the proof is verified we're going to get the

counter to increase and remember this is basically the execution we have the guest program let skip F that so steel commitments are very important so if you remember we now have a guest program that has some verifiably is state it has a Merle proof that it's proven and it has that against the block hash from an RPC but when we're on chain we don't actually know if that block has is valid or if that state existed at the Block so in Ste when you request the information from the from the host it usually just goes to the latest block but you can pin a specific block so in this bit at the end here we saw this thing called a commitment that was written to the journal and this is

boiler plate from steel end into commitment you'll always see that when you're using steel and steel retrieves new call State at a specific block and you can pin it if you want and so you can say I want block X the relevant block data is committed to the journal uh for validation on chain so the general will commit will contain that commitment we call which is just a struct and that steals trust and carries the block hash now actually what's actually happening uh on chain we're using the steel Library so you saw that like steel do validate commitment that can be we have templates for that you can uh they'll link into your compiler and S C and you can deploy those but what actually is happening when you're validating a commitment is you're validating the block hash from

the context of onchain so basically we have a block hash and we we made sure that the view call State matches to the block hash with that meral storage proof but we don't know on chain if that block hash ever existed or if there was consensus around that block so what we're going to do is we're going to use the global variable from solidity block. and actually match against that and only if they matched can we verify the proof that okay this information has this information that we pulled from A View call state did in fact live on chain so in the fact this proof is valid that view call state was at block X and we're ready to ready to rock and roll with the state update based on the proof verification of this small contract execution proof now one thing here is of

course block. has the global solidity variable block only has context for the last 256 blocks so you have about a 50-minute window before your block become before your execution proof becomes invalid that's in most cases reasonable U but it's not ideal so there are ways of uh if you're an optim ISM or an L1 there are ways to access the beacon chain which is the after the merge where it has a block rout information which stores the block header for around 24 hours um there are actually ways of doing this where you like bookmark and pin the block and we're actually adding that to Steel but for the purposes of this we'll leave it there so 50 minutes and 24 hours depending on the Chain you're using so to summarize uh we need smart contract execution to be verifiable uh we know

it's very limited and we know that steel allows us to do execution proofs within the zkm remember the zkm has no network access so we have to Steel manages this all and abstracts it all the way for the developer like yourselves still uses RM to use like minimal evm environment that can make sure to verify everything and and do the calls against and we PreFlight all that data and check themal proof within the guest and the execution proof can be verified on chain without also those uh commitments that's validated so that's everything for me today so that's Ste so thank you very much for listening thank you very much s uh big Applause to Sasha please okay