Workshop on Risc Zero Products

Transcript

Hello guys, welcome to today's session hosted by the D learning opensource university. Today's topic is about risk zero products. They will introduce their products. It's a kind of workshop and before we start please allow me to introduce the D learning community. So that learning is a kind of GitHub open source community is kind of tutorial which targets to uh different levels of developers. Uh we like to help the junior developers with basic skills and understanding about blockchains and we also provide a big or a friendly platform for all of the developers

including advanced developers to communicate and cooperate with each other. So now let's welcome to uh today's present presenter um Angela um he's the senior uh engineer from the risk zero um yeah so welcome Angela nice to have you today um could you be give us a short introduction and tell us uh what you want to uh teach us or present yeah absolutely thank you for for having me can I start sharing uh my screens so that Yeah, definitely. Yeah, as always.

All right. Do you guys see everything already? Mhm. Pretty nice. All right. All right. Perfect. All right. Um so, um I'm Angelo. I work with the riskier and currently mainly focusing on boundless. Uh I'm Italian. I guess it's easy to recognize my accent. Uh I do you know as as most of the Italian I do like pizza uh pasta and also zero knowledge. Okay. So right. So actually you know my my

passion for for zero knowledge was was the main driver that led me you know decide to to actually join risk zero and uh as most of the new shiny uh things right uh you get excited very very easily right with such a you know uh amazing technology and you know ZK uh is is also very along these lines uh and made a lot of promises especially when it comes to web three and blockchain, right? Because of course the applicability of ZK technology spanning across you know not only web three but also web two you can basically use it everywhere but specifically when it comes to to web three uh in the

blockchain typically you know when when when you have to deal with consensus you reach consensus most of the case uh why by re-executing right all all the nodes right they need to reexecute you know the transaction the whatever computation to to basically reach an agreement and that is basically very expensive. That's why you know you you you have these high fees most of the time, right? Uh and so ZK uh kind of you know promise that uh this is going to be the past uh and then you can basically you know just execute one and verify the the proof once and and you know offload the computation of chain and then that also uh allows for uh you know enabling uh finally

trustless bridging and we have seen uh and we are seeing also you know today and you know tomorrow a lot of uh ecosystem them uh really uh pushing for for ZK adoption and Ethereum, Bitcoin, Solana, but many many more, right? However, uh not everything is perfect, right? Especially at the beginning of of new technologies, right? So if if we look at you know the the current uh deployment and and use of uh of of ZK most of the time uh you have you know uh the prover that is you know relies on single parties uh buying the the infrastructure to to prove is is is also very expensive right because you know

most of the proof system they have really high requirements when it comes to hardware. Then uh also from the developer perspective it's not the easiest technology to understand and integrate yet right you you basically have a very uh long deployment times and and also uh especially when it comes to writing uh you know specific circuits that that's definitely not a really uh user friendly experience. So one of the goal of uh risk zero and and specifically boundless is to fix right this these shortcomings and u basically boundless is is a universal uh

protocol that his aim is to bring zero knowledge on every chain right and so with uh with with with this in mind uh what bundles is trying to achieve is uh uh is to basically give you the um the ability to to not only focus on your application deployed on one chain, but you can actually embrace and benefit from you know a more broader ecosystem uh by you know easily uh deploy your your application on any chain right and still uh being able to benefit from from from zero knowledge magic right also uh uh no bringing in uh in this way zero knowledge allows you to basically have

boundless execution power so that you can unlock new new application and also save a lot of uh money in gas fees, right? Uh it it's also one of the goal is is to be very easy to to use right and adopt. So so that will give you a very low go to market time and also uh decrease the barriers to to entry. And with this uh we can unlock very nice properties especially when it comes to let's let's think about rollouts right uh having the ability to use ZK to secure their protocol uh is a really a good push uh towards uh more ZK adoption but that also applies to you

know application and and and and other protocols as well. It is also very high performance that's that's important because uh you know we we are moving in in a in a world also you know you have seen discussion happening I want to basically increase you know the the speed the speed at which things get that confirmed and you know things in general uh works on on web three right so speed is also very important uh and again as I said it's a universal protocol so that basically gives you access to an entire uh set of ecosystem and you don't have to basically be locked in into just you know one chain or or or

something like that. Now, uh, this presentation is going to be kind of big, right? I try to put so many slides. I I think I I'll try to skip over some of the details. But the the the aim uh of giving you access to this presentation is also because then you you can you can basically uh stay with something, right? some some point of reference to basically you know help you uh understand and maybe get more details about the the amazing technology technologies that that we are cooking uh here at at risk zero and boundless right so if uh we think about boundless as a say dividing in a set of of components

we can think of it as basically the the demand side right uh that is basically driven by one and two's protocol you know application and then we have uh on the other side we have uh uh the supply right the prover so the basically the the centralized network that uh uh gives you access to to to the ZK right and in the middle we have this decentralized market that uh basically does the matchmaking right between the tools uh I I'll start by um basically give you an overview of of you know how uh develop ers can can uh uh leverage uh boundless and also all the frameworks around boundless and then

we we will go uh to see the others in in the rest of the presentation. Right? So just to basically have some uh common terminology so that we sort of understand what we are talking about right. Uh if you think about a virtual machine right the aim is basically you you have a program that you want to run you also have some inputs that needs to be basically fed into the program and the virtual machine runs execute this program and spits out some some output right some result. Now it's very similar when it comes to instead that zero knowledge virtual machine right with the only difference that while executing this program with with the you know the

inputs uh not only spits out the output but also a proof of correct execution right that's basically the entire magic of ZKVM that you can then uh verify the proof without the need to execute the the original computation right you can trust the proof and uh uh This applies in a slightly different terminology with the the risk zero virtual machine, the R0 VM, right? Where the program is basically we call it a guest code, right? That uh typically is written in RS, but we support also other languages.

It then gets compiled down to an ELF binary targeting the risk 5 uh architecture. uh and then together with the with the inputs right it goes into this R0 VM which is you know our ZKVM and uh the result that uh before you know I called output we uh call it journal and the proof we typically call it receipt right so that just to give you an understanding of our terminology right so uh we were talking about you know uh developers and how you know we can we can write this program so this is example taken from the boundless bundle template. I'll um I'll basically uh um I I wrote some links throughout to

the entire presentation and if there is like one thing that I'd like you to to basically uh take with you is is those uh links because it allows you to to basically you know get even more information and you know stay up to date with what we are doing. So no worries if if you know you don't read everything here because uh all the content is taken from all of the those useful resources I I'll share in the in the presentation. Right. So let's get back to our guest code. This is a very short uh example uh that um the goal is to basically take a number and uh uh you know say whether it is even or not. Basically it will commit

to the result only if the number is even right. So if we uh split up uh the the part of the code you can see that we have an initial phase where we basically read the the input right and then we decode the the the number. uh then we we basically um you know we check the number we check whether that number is is even if if so we we commit uh this is like another terminology we we basically uh we write the result into the journal it's just basically committing to the result right everything that you commit uh is basically going to be part of your output of or the journal right

uh then let's say that uh uh you have run this program uh and you basically have your your journal, you have your proof and then you want to uh consume this into some smart contract, right? Because that's a really uh let's say one of the most uh useful uh use case when it comes to integrate ZK and and web three is to basically use uh the the proofs right in your smart contracts. So in this case we have a set function right set method that takes the the the number right the journal in this case uh and uh some cold data called C which is basically the proof right they received

uh um so what it does it decodes the the the number right and then it verifies that the basically the proof is is correct and then only after the you know successful verification does something else in this case it just updates a number right to to the value of that uh uh even number. This is like a very stupid simple example just to give you an idea of how things are connected together. And uh here are you know I was talking you about these uh these you know links uh here it's the first set of links where we have the risk zero docs which basically explains all the fundamentals

of our zk uh R0 VM right uh and then also uh there are some more related with the boundaries right so how to build the program uh and also the the repository of the boundaries foundry templates that I I show you right now Let's go uh to some things some example even more interesting right so before we saw how we could run Rascode right native Rascode now when uh we are developing uh let's say in EVM right one thing that will be super super useful uh will be to interact with solidity directly right and uh maybe even access the state of the of whatever chain right so for that

we have one of my favorite library and you know piece of technology we have developed uh at risk zero which is called steel uh and it's uh basically a co processor right for EVM apps right it gives you access to an unbounded computation in a very simple way right so uh basically what it does it pulls state uh from any EVM compatible chain right and then it performs verifiable computation also across multiple blocks you know of chain and then generates this very you know compact to proof that is very cheap to to verify on chain so that you can basically have access to a boundless amount of computation now right so you can think of of your

application not not anymore with you know the constraint of you know how big is the the block uh how how much gas can I actually use in fit in one transaction but that goes away because uh you can uh offload everything of chain and then just bring back on chain the the proof and the result. Just to give you an example, right, with this deal, you can easily um use it to generate a proof for a computation that is equivalent to 38 million blocks, right? When when in terms of of gas, right, which is basically 1.2 billion, right? And you can basically uh just pay under $10 to to generate this uh this proof, right?

uh and then get that verified on chip which is is basically a massive massive save. Uh now let's uh again let's uh also uh give you an example uh you know very basic just to to understand the the the main components here. So this example is basically a very a very simple um idea to to basically increment a counter uh if only uh a given uh uh address right a given account has more than than one uh balance right in in a given uh in a given ERC20 contract right so this uh would be implemented by implementing the check meaning the logic

right the computation to to check that the the balance is is than one on chain. So the are typical standard um you know Ethereum contract. Now with steel instead what we can do is that we can strip off the uh the the main contract the onchain contract right the the the check that we perform uh on chain. We can offload that and then we can just bring back the result with the proof right. So we we can decode the the the result. we can run some checks on on the validity of the result, right? And then verify the proof and only after that we can you know perform our operation in this case was increasing the counter,

right? And how you know how does this this uh uh steel library work? So basically um what we we do to make it easy to to work is we let the developer just uh use uh you know normal solidity. Luckily we we have this nice uh uh ras library called alloy sol right it's a macro that allows you to literally copy and paste right uh solidity code into your your ras program. It also, you know, allows you to u read the the the compile JSON or, you know, whatever uh um interact with the with the solidity in a very easy fashion and then uh you

can basically uh use uh all of these uh to write your guest code, right? So this is an example. You you basically read the some input, right? first and then you can basically construct your your view call using uh uh these these uh uh bindings that alloy uh give you give you for basically for free and then you do your checks right that you you want all the checks that you all the logic that you want to offload chain and then you commit to the to the final result to the journal right so it's it's really easy to to basically use and uh it's it's super cool because before steel

The only way to do something like this was to literally go manually find the the stock index where the you know the the state was stored in a specific contract and that was very tedious work because uh you know you had to use some additional tool to to find you know what the slope index was for a given contract what variable you wanted to read. Uh so uh this massively improves the usability of uh TK right in terms of accessing the state um of um of a contract uh on on EVM chains. And now behind the scene the way

we can pull this off is uh we basically part of the input that goes into the guest uh are basically uh coming from a a phase that we call pre-flight which basically what it does it queries uh right the the call that you want to to perform right the method the function you want to to to run uh calling you know some RPC nodes and then uh together with that it also calls the uh ETH get proof uh which basically gives you for each of the you know the the slot index that you have in your state while interacting with this view call it basically gives you the proof of inclusion right against uh a given you

know block route right uh and so you can gather all this information so that you can provide the guest with a very minim minimal uh amount of information that is you know uh um required for the guest to actually verify that he's going to run this uh function, right? Uh from a verified state so that all the uh you know all the variables are actually checked already against the root and uh and that is that happens all under you know under the hood. So the the developer doesn't need to to basically care about this. And so the the general idea here is uh is really uh you have a very heavy

um computation that you don't wish to run on chain right whether it is because you want to save gas whether it is because actually you couldn't fit this computation on chain right so you can basically use field to do that for you uh and then you verify the proof and then you can basically perform some action that is is maybe going to modify the state uh based on you know the outcome of that right so this is basically the uh the same increment function I show you before just to basically you know uh remind you that that is basically the way to do it right uh I mentioned that uh when we uh run steel right when you verify that

the state is actually correct we need uh a trust anchor basically right typically ally is is the a block root of a given block. Right? Now, we still supports two uh different commitments modes, right? The the the first one which is the the block cache which basically uses the the the block route, right? And then and then on the on chain you compare this with the block hash of code that gives you access to the latest uh 256 blocks which is about 50 minutes, right? in uh in in Ethereum if you if you consider like every 12 seconds a block, right?

And that uh is basically the time that you have uh for generating the proof and then consuming it meaning verifying on chip, right? If you need more time uh still also support um a beacon block root commitment which instead of using the the block hash it uses the the beacon root contract, right? And that extends the time window uh for basically about a day. Right now also supports uh uh other features. Uh so we uh we also support steel history meaning that you can actually uh extend even more uh what you want to to prove. So basically uh it allows you to

query um state older than 24 hours. Right? So it basically uh does that automatically. And then one of my favorite things is also the steel events which basically you know you know that uh sometimes uh you might have an application right that uh needs to uh take some action based on some events generated by some other contract. Right? And typically the way you have to do it is to have complex event middleware that basically listen and then you know push stuff. So with steel instead you can just use uh to give uh to the to the contract to the some method that you want uh the proof

that some event has been emitted right uh and that that's super powerful and super useful and is unlocking already uh really new use cases in an efficient manner. All right. So these are the resources for steel. Uh I really uh recommend you to have a look at at those because steel is absolutely uh amazing. And then uh what about instead rollouts? How can we actually you know uh use uh some decay to to improve the the life of rollups provider. Right. So we have developed op kyua which is an hybrid zero knowledge for for op rollups. Op stands for

optimism right the op stack and uh it's a a suite of you know software for for uh for upgrading you know the the traditional optimistic roll apps to hybrid ZK rollups right which means that you know you you can use a little bit of ZK to improve many of the of the aspect of of an optimistic roll apps right uh so with with this what what you're going to get is basically a set of contracts for for dispute right in zero knowledge uh which is currently only compatible with with the op stack roll apps but you know we have planned to also support more and then we also provide you with a CLI tool to automatically integrate

rollups to ZK fold proofs uh and then also important you know state proposer agent uh as well as a rollup validator agent right uh now this is also very cool because it solves uh core core for rollup problems, right? First of all, it saves on proving cost uh then it lowers the participation uh requirements. So instead of you know need uh having the need to to to spend and invest a lot of money to to set up proving infrastructure opkua uh you know can can can just use the centralized proving market markets right so you

don't have to basically you know put that initial investment and uh it also reduce exist existing rollout collateral cost which are you know one of the things that I dislike the most about you know the the traditional uh optimistic roll out. So instead of having a linear of being a linear in the number of of proposal challenges, it's basically constant. Oh, that that's really cool. Uh I also share some um resources here. I uh highly uh recommend the KAUA book because KUI is is basically in in a very active development phase. So the reference that is then more up to date with the current

design uh you can find it there right and of course the repository and we also have a quick start on the boundless uh documentation on how to to basically use it then we also have something about you know proving ethereum blocks right that that's basically I think I would call it the the father of kyua it came before right it's called z and it's basically an execution layer block prover right for both Ethereum and and optimism. uh and with that you you basically have a way uh to prove that a given sequence of of block is valid by you know applying the the given list of transactions starting from a parent block and you don't need to to rely on the validator

or the sync committee because of course everything happens within the zm right so the operation that that happens while verifying a block are you know you verify all the transaction signature the you verify the account and the storage state against you know the parent block and then you apply all the transaction, you pay the block reward and finally you update the state route, right? And uh and by using this you can obtain a ZK proof of a valid block execution, right? Again here uh uh you can find the repo and also we have uh an Zestbased order generator in our boundless market uh that basically every now and then it uh it uh submits an order for uh you know

uh approving either a block or a set of blocks. Right. So now we talk about the market uh the decentralized market of blocks. So this this um uh diagram is is very useful to understand you know no know to to have an overview of how this uh decentralized market works. So basically you have uh you know the the application there the request of let's say side of things that needs to uh have some some proof request to be fulfilled right uh might be you know coming from from a Zack uh block uh um that that wants to generate a proof to to uh to validate a

block or it might be a roll up or might be your application or might be something else. It doesn't really matter. And the and the request submission can happen both onchain but also offchain if you want to save any more gas. Of course, if you send it offchain, you have less guarantees about data availability, but you know, it's it's your choice. And then uh uh this um the market is basically based on a reverse Dutch auction, which means that the request contains you know some some prices there, right? I'm offered that then the the prover right uh which is part of you know all of this is open and the centralized so anybody can actually you know go there and and and uh listen to to new uh proof request submission

and then can also judge whether uh this is a profitable request right if the price is okay um if uh you know all the if the program can actually be executed right so uh there is also the option uh since It's a reverse such a option for the prover to basically acquire the right to be the only prover um to be able to to fulfill this request for for a given period of time, right? And in order to acquire this, the prover also of course needs to basically put some collateral, right? So that give the the requesttor some guarantees that the proof will be fulfilled, right? So if everything goes well uh the prover uh

will generate a proof and then submit the proof and the results to to the market uh and the the market will verify that everything is correct and then we'll settle right we we basically transfer the the the fee right to to the prover and then the the uh again the original requesttor can consume this uh this proof by you know using it in its uh its application or whatever needs to be consumed. uh and uh and yeah so basically that's the idea of the boundless market. Now it's uh it's super nice because uh it gives you really nice properties. So it's it guarantees uh proof delivery uh uh and uh of course assuming you know

that the pricing and all the parameters are are are correctly uh set. uh it is also you you have some guarantees about you know getting the the best latency and price because of the reverse auction. So so that means that uh the first prover that you know promise uh to to fulfill uh is also the the the one that will basically give you the best price because the price goes up over time right from the minimum to the maximum price. Uh there is no redundant work in this way because uh uh you have this lock in mechanism that uh basically you know allows um openly each prover to

you know uh acquire the right to to be the only one for filling. So there is no race uh but you know there is also an option to to have that open. Uh there is no single point of failure because you know it's a centralized network and you know that those are really nice properties. So [Music] um if we look at you know the interface for submitting a request in the market uh we can see that we have the proof request uh and then we have the the signature right of the of the request.

So basically uh signing that this request is legit, right? And the request is basically uh composed by some some you know some information. Of course, we have the identifier. We have some the requirements that basically specify, you know, uh some constraint that the the the output right should should contain uh the image the the URL of the program basically the image URL the input that needs to be run against this uh this program and then also the offer. I will show you a little bit more details about the offer because it's interesting to understand this to also understand better how the market and the reverse touch auction works. Right? So we have a

minimum and maximum price uh that is basically you know the lowest and highest price the requester is willing to pay. Then we have the uh a time stamp defining when the bid is going to start. Right from from that moment we define also a length of ramp up period which is basically the this defines how fast the price will uh go from the minimum price to the maximum price right. Uh and then we have a timeout which uh express basically for how long uh this uh uh request is going to basically still be considered uh alive, right? And then we have a lock timeout which is instead is the time given to the prover that wishes to acquire the

rights to be the only one right and able to to fulfill the request. And if the prover doesn't respect this time out, it gets slashed of the collateral that instead is defined in the lock stake. Right? Uh we we have an indexer uh of the boundarless market and one of the uh stats that basically you can have access to is also you know the average price per mega cycle so that you can you know have a more uh a better understanding of how to to price your your request.

Uh then uh we also provide uh obviously a boundless SDK that basically is a bunch of you know utilities function to help you uh uh construct and interact with the construct request and interact with the market right in this case we show how to build a client right specifying all the you know the addresses for the various contracts of the market and uh you know the private key and uh uh what the RPC URL you wish to use. Um and then the same SDK, you know, uh the same client has functionality to help you with uploading the the program, right? We support uh S3, we support

IPFS. In general, any any URL uh uh is also good. And then um same things for the input, right? you need to basically find a way for uh the prover since this is a decentral decentralized network to have access to the program and the input that you need to you want them to run. We also have a way for for this to work in a more private fashion with the leveraging on uh AWS, right? Uh so that uh only the prover that have access right to to these uh uh links of of S3, they can actually have access to the program and the input. So you can basically have some more privacy in this

way. uh then uh you know this is just an example to show how you could use uh the art zero VM tool to know more about your program. In this case, we basically run the execution which is basically just uh you know running the program without actually proving it. And this uh gives you access to some useful information such as how big is your program in terms of cycle, right? In terms basically how expensive will be to cook, right? As well as the journal, right? So you can use this to both ensure that your program is actually correct. You know how much you should basically price uh this request and also define some

requirements regarding your specific journal. And then uh you have you know your builder for the proof request. So you can basically uh create easily uh the the proof request that you can then submit to to the boundless market. Again, you can send a you can submit a request both onchain or offchain, right? Uh you have different guarantees whether you decide to go chain, but of course you're going to save uh you're going to save some gas. Uh then uh you want to maybe wait all right for the request to be fulfilled. So we have both blocking and non-blocking right uh um methods for this. Uh but basically the goal is once

you get back the the proof and the the journal and and the basically the receipt right you can consume it uh and basically fed into your uh application. We also have uh I haven't put the slide here yet, but we also have um um a detail in the in the request requirements that is actually going to uh specify you a call back so that the consumption of the proof is actually going to be made directly by the market itself. Right? thought that use the request doesn't need to even you know uh use the proof because it will all be part of the proof request life cycle and uh yeah going back to and

trying to connect like the example that we saw before about the even number right uh here the the idea will be you create a proof request try to prove whether x is is even right and then you can uh uh call the um you know the wait for request fulfillment so that you you get back the the journal C and then you can you know use the S macro to again to create your instance of the event number contract and call the the set uh uh function with using the uh you know the journal and the uh proof that you you got from from boundless. So basically this is to to make the circle right. Uh right. So that means that you

know the set function will verify the proof uh and you know the verify call will revert if the proof is invalid which will not happen because otherwise you know in general what what you get back from the market is only valid proof because they they have been verified already. Uh and then you know your your uh program can uh basically do whatever the program was supposed to to do, right? Uh here are also really nice um links. Maybe I can actually let me see if I can so we have um we have some tutorials here. Uh so basically this is the the the callbacks

uh that I was mentioning. So that uh you know automatically the the the request also the fulfillment of the proof will also call some method that you want right. Uh we have a decentralized way so that also smart contract can be requested right we also have a way to specify what type the type of the proof that we want to get back either a a cheap you know proof of inclusion or maybe we want the original grow 16 because we want to use it somewhere else. Uh we also have a proof compos composition support meaning that you can uh prove first a program and then you can basically use the proof of this program to prove another program right so that you can basically build um in

composing proof together to to prove something else right uh we also have a CLI to interact with boundless but what I wanted to show you now is actually uh yes this other page where at the bottom We we have the link to the of the indexer which is it's basically something like this right where we basically see uh in our current test net uh some orders right that uh have been submitted either offchain or onchain their their current status whether they are fulfilled or just submitted right uh and then you also have you know some other information if we'll click to to to an order you you basically get some

more information you can also have more details about that about the the uh the offer and every everything and we we also have some stats page where you can basically see how many um orders have been fulfilled. I I think somebody raised a hand. Yeah. Yeah. Yeah. Yeah. Uh I just want to let you know there's a question from Victor in the uh chat box. What's the requirements of running approver the minimum recommended configuration? Yeah, sure. True, true. I I'll get there in a few seconds. Thank you for the question.

Right. So now now it comes to to provers, right? So uh we already have like a um a very good set of provers uh that you know they have experience securing and mining those you know billions uh so they have experience in bring accelerated hardware and some example TK pool P2P rock way uh but it's a open network so anybody can actually uh go and participate uh we provide uh set of software like that that composing stack basically have two piece of software is bento which is this multiGPU multi-achine uh prover right that is open source you can you can run it and uh we also have the broker which is

instead a piece of software that basically sits in between the market and and vendor right so it's the one responsible for evaluating request uh bidding on request issuing proving requests and so on and so forth right and when it comes to to the requirements we do recommend uh uh this type of requirements that they are don't crazy. It's a it's uh commodity hardware. However, uh that doesn't mean that you cannot basically participate as a prover with with way less hardware, right? This is just to remind uh that the expectation of being profitable of course needs to be set

according to the capacity that you bring into the network, right? Uh so that means that uh you know if um um if if you if you come with just let's say uh a GPU right uh and you know a pretty even just a laptop you can participate right to the to the market uh but you might be slower right so that means that you will be able to accept less orders right with respect for instance to to some bigger proofer right so that's basically the the The point is you can participate with any hardware. uh but when it comes to be profitable in this competitive market then of course uh you know uh it

makes a difference uh the you know the amount uh the power that you bring in right so that's basically the point and then know the other requirements are really just you know Ubuntu currently we support only that docker compose everything is done via docker so it's not really that difficult to run a prover uh and in the current phase we also uh have a requirements for the stake collateral. It's basically a a toy token. Uh it's it's called HP. Stands for uh health points. The idea, right? Uh so if you wish to participate, just fill out that form uh link in the presentation and we we'll give you access with with some HP tokens. So it's a completely um doesn't have value,

right? Currently, it's just a toy token just to make that clear. Uh right. So these are other uh important resources for uh for the filbert side of things. Uh we plan to you know have many in Q2. So so really welcome to to come with with us. Uh and that's basically it. But um I'll go back to to the maybe stop sharing for a second so that I can see the project. Now I see you all right.

We also have a friend asking what's a commitment but I don't get uh which slides. Uh yeah, I think it's it's for the for the steel com for the steel library, right? So basically a commitment is um imagine that you want to read some uh some storage slot on on you know some some some some contract right let's say and uh that uh uh that value uh is only let's say verifiable uh uh by using a proof of inclusion right using the ETH get proof that basically attest that that is the value correct value assuming that the block uh

root is uh whatever block right let's say block number 10 right so commitment means that you you are uh committing uh to that block number right and so that you basically have applied the verification against that block so that once you basically verify that onchain you can make sure that that that block is actually a a valid block is this true it's not just a fork or you know some some other shenanigans block so that is a commitment, right? And you that's an a type of commitment using the the block route, but you know there are also other type of commitments using maybe the beacon uh roots.

Yeah. Okay. Any questions? Hello, I have a question. Can I use steel to get a API from from web two website you know then can I generate proof uh for it? So you your question is is if you can use steel to generate a proof for a web two API right response. Yeah. Okay.

No, meaning that uh steel is basically meant to uh run EVM. So basically literally just um um you know say something about the state of of of uh I give an EVM chain, right? Uh so that is the the short answer. Uh the the better answer will be that techniques similar to um to steel could be used uh right and could be built to to prove uh you know the the correctness of the response of uh of a given API in the web tool but that is mainly going to

be focused on how to prove that a TLS session right HTTPS session is actually you know correct that is is is kind of tricky for for various reason. The main reason is that uh um in order to be easy to to to achieve such such you know such a primitive uh the TLS should be slightly modified or at least you know used in in a subset of it what's it's available right because TLS can be you know upgraded to different um key mechanism so there are some caveats about securing at let's say proving the

the the exchange but there are also already a few solutions out there uh I don't uh remember on the tip of my uh tongue the the names of this uh uh solution but they they are if if you look DLS yeah something something uh along along those lines uh you can definitely have a look at that we are also interested in in exploring a little bit more this uh uh but yeah definitely it's it's a super interesting topic. Yeah, you are right uh ZKTS may be the solution. So I wonder whether I can use risk zero uh for ZKTLS. No, absolutely you you can you can use risk zero for for basically

you know uh proving right what ZKTLS implements. The problem with ZKTLS though is that there are still some assumptions, right? That uh uh you know might be good for your use case or might not be good enough, right? So have have a have a closer look at what ZKTLS uh um is able to provide, right? because it's not I I personally I don't think it's still like the you know ideal solution to this use case unless of course you know there are some assumption that you are okay with it.

Oh, okay. Yeah, thank you. Um, any other questions? You can type in the chat box or just open your microphone. I do have a question. Is it possible to share the presentation with the, you know, all the attendees so that they can basically have access to the links? Oh yeah. Yeah, definitely. Uh yeah, we will um send the links to the yeah community chat or something. Thank you. Thank you. Yeah, they can get from our official website.

Yeah. Um I think I got a question from the community. Uh it's a gen it's a very generic questions. It's a uh I mean what types of teams you think uh will get the benefit from the bundles? Uh yeah like I mean what type of teams like the team working on the Ethereum the team working on the decay sync or yeah generic I well I I the point is uh I I'm not sure right but definitely uh one of the goal is is to be you know as universal as possible for us because

we do believe that you know ZK uh shouldn't wear any any flag right should really be applied any any sector any any chain. Uh I do believe that uh uh the way and the pace at which CK will be adopted will uh will be very dynamic uh in the near future. meaning that we will see a massive increase of uh of demand for ZK uh especially especially because you know some project like this zero but also others that are really pushing and improving the UX experience for for for you know enabling this uh and then also you know we have to see how the

protocols the core protocols will evolve right they might also think to actually embed ZK within their um uh you know uh the the native natively protocol. So that will also play play a role. Uh then yeah, I guess uh I guess uh uh definitely the the Ethereum ecosystem uh is uh is well suited uh especially because you know it's expensive right to to to to run stuff on Ethereum. So everything that can be offloaded is good. But I I saw a lot of interest also from from Solana ecosystem. Uh even though there is already kind of you know faster and cheap I think uh you know it's not only saving gas it's also

unlocking you know application that still cannot fit in one in one block right on one few transaction. So that is also important. Okay. Okay. Thanks for your answers. Yeah. Thanks a lot. Uh any other questions? Yeah, I have another question. Can you briefly introduce the difference between risk zero and SP1? Yeah, sure. I mean uh absolutely. Um so risk zero kind of you know um created uh the the first ZKDM based on risk 5. uh and at that time and everybody would

were kind of surprised why you choosing this five over some other architecture right but and and it was also the period where uh it was very common finding uh teams developing specialized circuit EVM right rather than ZK uh VM uh so we kind of show uh to the world that can be done uh can be done really well so then obviously other you know capable team uh kind of you uh like the idea and you know start to base their their work off of it. So we're really happy about it. Uh and um and and and and now I guess uh it's not only risk zero right also also SP uh they they provide a really good um good

solution. We we do differ uh mainly in the way we approach security. Uh meaning that if you really care about security and if you look at the you know the Bitcoin space uh I think we are top-notch. There is there is literally no no comparison. I mean no no game with that. Uh the when it comes to speed it's it's like a topic that has been you know I I I I get it but the development in the space is going so fast that by this time next year nobody will ever talk again about performance because things will be so fast that nobody really cares about you know the minimal differences. So you know it can

happen that one week uh risk zero is faster doing this type of computation another week speed is faster doing this other you know there is also other uh ZK that are faster it's like moving very very very very fast right and things are changing so I would not put the current performance to be the only deciding factor to choose a technology rather you know I would look at you know how the the the project is is is evolving, you know, security uh and you know, decentralization and all of these things. So, yeah.

All right. I see. Okay. Thank you. Any other questions before we end? Okay, I think that's it. Um yeah thanks Angelo thanks for your excellent and details presentations. I think we all get the basic understanding or uh intensive knowledge about the lick they can sync and bundles. Thanks for presentation again and thanks for all of attendees uh to show up in the dep learning. Uh yeah we will see you next time. Thank you. Bye. Thank you guys. Have a nice

day. Bye-bye.