Why ZK Verification is Ethereum's Final Frontier with Aligned

Transcript

welcome to another episode of the rollups igen layer Series today we are here with Diego Kingston from aligned layer welcome to igen layer unlocked an interactive educational Journey Through the igen layer ecosystem created by technical Founders and builders for the entire crypto Community a special thank you to our partners all Lair polymer authentic skate and lrange for helping to make this happen our goal is to raise the collective knowledge of the Igan Lair ABS ecosystem and unpack the technical designs of the top teams in space welcome to ig layer unlocked what's up guys welcome to

another episode of the rollups igen layer Series today we are here with Diego Kingston from aligned layer to talk about ZK verification past present and future thanks a lot uh Robbie I am as you said the co-founder and head of research at aligned and we are dedicated to verifying zero knowledge proofs and so I am going to make a brief presentation on on the topic please feel free to interrupt me if you have any questions so let's start with the problem we are trying to solve this is the problem of building the centralized applications and it will be clear why we

need this technology in order to help for example blockchain scale or solve some of the problems we encounter when building this type of applications so let's start with the beginning blockchains remember are verifiable computers okay they coordinate among different parties and the way we uh ensure that things are done properly is via re-execution so everybody has to redo the same work and then reach consensus okay the problem we have with this is that uh all the parties have do have to do exactly the same amount of work and the problem is that then the weakest devices in the network uh become

a bottleneck so if you take a look for example at ethereum currently it can process around uh 10 to 15 transactions per second and if we want this to to scale to bring like millions and even billions of users we have to make the amount of transactions go up so how can we solve this uh luckily we have succinct Integrity proofs or sometimes we will call this like CK for um it's aing zero knowledge proofs but we care about this property of SX synness which means that the proof is short and with them what we can do is

show that we did a computation right um in a in a manner that is both time and communication efficient okay so the idea is that I as a party can generate this proof and all the other notes in the network just verify this and they spend uh less work than I had to do to run the computation so this helps a lot scale and um the good thing is that we can create uh proofs of very complicated uh computations for example we can prove an entire block of transactions and then the parties just

have to verify this very short proof that they can do it in maybe a few milliseconds even on for example cell phones and we don't need to give them all the information of all the transactions and everything that has happened we just need to give them some information maybe on some public inputs and for example the output of the program and then they can just verify everything okay so this uh solves the problem in the sense that what we can do is then delegate this computation to another machine and then it can submit to the network the proof and the rest has to do work in that sense um we can then make

blockchains more powerful by adding other computers doing computations of chain and sub submitting them on chain for verification um so we are solving the big problem that you had in blockchains that if you add more computers the blockchain isn't faster because every node has to reexecute but with this you get to scale up uh without losing any of the guarantees that you want okay so if you want to build the apps CK or this proofs are a core primitive so how do these uh proofs work the idea is that um if we have a way of

proving what we call an NP complete problem that is to say a problem which we can verify its solution in polinomial time for example that can be proving that we have a valid assignation for example of a Boolean circuit or um for example knowing that we we have the solution for example for a Sudoku okay solving a Sudoku may take you a lot of time but if I give you the solution to a Sudoku you can do it with just a few checks and and you're sure that that we did it properly and the idea is that if we have one of these NP complete problems then any other problem in the class NP can be uh reduced to this um NP

and if we have this the proof then we can generate the proof for this uh um reduction okay so we have to choose which um proof technology is the best one for what we are trying to do and the problem is that um or the good thing is that you have like different tradeoffs so for example you can have proofs that have larger proof sizes and so that may have an impact when you want to uh check them in the blockchain because then you have to pay for a lot of space then some have like higher verification times others like higher proving times some can be for example post Quantum

secure and others are good for example have like easier properties of for example what we are going to talk later which is proof recursion okay so we we have like a set of Technologies and we have to choose which one is best for um our purposes and it may be that for our application there is one that is like uh a lot better than the others and we would like to use it so here there are like some popular um design choices uh that you have for example you can build uh your proof system using hash based uh Primitives or maybe you can use elliptic curves then you have different

choices regarding for example the finite field you're going to use if you are going to use for example binary Fields as in Venus small Fields as in Starks or even uh bigger Fields because you're going to work with elliptic curves then you have different ways of representing your computation so this is more or less what happens when you write a computer program okay when you write a computer program in general you write it in a higher level language then it gets compiled into assembly and then it gets compiled to bite code and that is what the computer runs so in this case to be able to generate these proofs what we have is in general we have a program that we want to prove but the problem is

that is not the language our provs understand so what we have to do is that some kind of compilation which we generally call like uh building um arithmetic circuits or arithmetization okay expressing our program as a set of algebraic constraints and the depending on the choice it may be easier to do some things it may be more efficient less efficient and so we have to think a little bit what we want to do then of course there are like some choices for example you want to use Univar polinomial multivaried polinomial you want to leverage something called the subject protocol you have like plenty of options then you have

some um proof systems that need a trusted setup okay in general they offer shorted proofs but at the expense of adding this extra security assumption uh then of course depending on the curve or the hash you use it also affects uh the performance and then you can for example use different lookup AR arguments which are just specialized operations where you can go to a pre-computed table of valid input and output Pairs and then show for example that your result is contained in in that table and you have also different typ typ of uh lookup arguments and so what you see is that you get like um large

variety of proof systems and you have to choose which one suits you best so here is an example of what um proving looks like okay this is just for what we call Starks using uh CK virtual machine the idea of these Primitives is basically you write your code in some higher level language for example it can be Cairo or it can be rust then the idea is that code gets executed on a virtual machine and what it's going to Output is for example the trace and the memory of of the execution okay then you have to do

like some pre-processing you have to do some conversion or encode all that information using polom and then you have a series of steps that depends entirely on the protocol but as you can see the prover has to do a lot of work and whether it's easier or harder depends a lot on the kind of Technology you're using and some of the Primitives that you add for example different hash functions can lead to dramatic changes in in performance and finally after all these steps what you get is a very short string that then you can check it by by doing some very simple

computations okay so then once you get the proof what you have to do is verify it and that is what for example the nodes are going to do and then for example what you do is you check that the proof is well formed that it contains like the type of elements you need and the length it's supposed to have you have to also check all the public input okay check that um they used for example the right initial values and that the output is is correct you may have to for example recover some verification parameters like a verification key or some information on the program you're

running for example it can be the hash of the program or even the the program's uh code and after that what you do is you run the verification algorithm which is is more or less like the previous case maybe you have to compute some functions and then do some basic checks and the good thing is that verification in general is very fast okay it can be in the order of milliseconds or even less and no matter if your computation was like super complicated or super hard to prove the verifier has to do a lot less work than the the pr

so let's see what happens when we want to verify these proofs in in in ethereum because what we want is to again move the execution outside of ethereum for example to a rollup then the rollup kind of submits um the state diff and the proof showing that uh it is valid and then each of the nodes in ethereum re-executes the computations they all reach consensus on the validity and then they can update um the state so quick question the theoretically does the does the execution move off of ethereum L1 onto a rollup could or could could ethereum

L1 instead of re-execution between all of the ethereum nodes could could ethereum L1 just execute once and verify and submit approve and then verify amongst its nodes and arrive at consensus that way yeah I think that that that you can for example the one proposing uh the block or something can generate the proof and then the rest just have to verify because the the proof what it does is uh it replaces re-execution I can give you I I can say like okay I'm going to take all that heavy verden from you you get this very short cryptographic string and then you can run it and it is the same as if you

had um re-executed uh the computation so it's it's very promising because then you can uh remove all these instances of re-execution to just re-execution of the verification which is much much cheaper and I think you're going to get into uh the gas efficiency uh for proof verification here yeah so when when we want to verify in ethereum we find that we have like some constru R first we cannot exceed the maximum gas that we have for block and that of course limits the amount of proofs that that we have then we don't have parallelization which is something

that we could would love to have for example then if we get like millions of proofs from different like rollups or applications or whatever and we want to verify them if we can parallelize they are like easy tasks and and we can process like maybe millions or at least thousands of transactions per second then we don't have like any kind of Hardware acceleration or anything we cannot leverage gpus or whatever because again the the upper capacity is bounded by the gas per block then of course another thing that we have is that we have to optimize the code for verification for

gas consumption because that's the relevant metric here not speed going faster isn't going to make more proofs fit into a block and then the other problem is that uh the cost depends on the availability of uh pre-compiled contracts so there are like some operations that um cost less because you have these um pre-compiled for example uh pairing based um proof systems are way cheaper than others because the has like a fixed cost you know it's going to take more or less um 100,000 gas or something at least for

the checks you have to do and so that may be way less than I don't know other things that you have to do for other proof systems of course the the main problem with this is that then you are limiting the kind of proof systems and Primitives that you can use in ethereum okay and that reduces uh your choices as a developer to choose like the best proof system for your application so this for example has led many rollups to use a proof system that is very efficient to prove their blocks and everything but once they get the the proof then they have to do another

transformation build what we call a recursive proof and generate a new proof in another proof system that can be verified very cheaply in ethereum and that typically is some of the pairing based proof systems of course you are doing that at the expense of like uh additional costs and additional latency and also you are like um abandoning some of the nice properties that your proof system may have okay so just to give you an estimate of the cost of of uh proof verification here I have like some popular um proof systems their are gas cost and just to

give you like an estimate of the amount it is in US Dollars of course that depends on network congestion and then also on the relationship between ether and and the US dollar but as you can see the cheapest uh proof system is gr 16 it cost around 250k gas which is more or less like $6 per proof it can be less more but it's more or less that number then if you want to use something like Halo 2 it's nearly double if you want to use Starks Starks are really efficient for proving but they are like super expensive in ethereum they are like 20 times a gr 16

proof then if you want to use for example kimchi which is the proof system you have in Mina which is like very useful to to do proof recursion and to have like a very succinct uh blockchain it works really well in in Mina but in in ethereum it's super expensive so if you wanted to verify a Mina proof in ethereum it would be like super costly and then for example there are others that we don't know their cost for example vus or others because I don't know if we try to write down all the verification and all that the cost might be even higher or even not fit in into an entire block

so as you can see we have like many developments many excellent ideas in improving technology but we cannot um use them in ethereum because we may lack for example some pre compiles or um simply ethereum is not adapted to to this type of of of Technologies so the thing is can we can we do better than this and um also we see that the cost even the cost for graph 16 is quite High okay so if you wanted to use this and um you would have to pay a lot of money

for example for some some application we we have this um story from from be telling saying who would pay like um $6 to hide or $10 to hide uh information on the transaction of my purchase of a coffee or something so um what we see is that verification costs remain high and that if we could reduce uh them then of course we could begin unlocking uh several new applications besides this is one of the main uh operational costs rollups have if you if you take a look just in verification

costs rollups can have over a million dollars per year and that of course limits the the prices they they can offer for for example transactions so targeting uh proof verification is uh very important to help ethereum scale okay okay because then we can process maybe more proofs uh onboard more users offer lower costs and also like start developing new new applications so here are like some of the factors we we mentioned of course um to adopt CK uh one of them obviously is related to proof

generation okay uh in the last year or so we've seen like many new tools that um help us write uh provable applications more easily and um and faster okay but in general the problem with proof generation was that in the beginning you had to understand a lot of the details of of CK you had to write these what arithmetic circuits okay so it was more or less like you want to code your application but you have to do it in Assembly Language okay you can do it but it's going to be uh

very painful back prone and then you also had like very limited expressivity the kind of things you could do was pretty limited and then we have the other like half of the problem which is verification you have very high costs these um the verification tasks compete with other applications on top of ethereum you have like low throughput okay so if we want CK to be used on on a massive scale then we have to solve these two problems the first one okay I think is solved with ckvm Prov networks and Hardware acceleration okay so the idea is right

now you can write uh code normally for example in Rust feed feed it to some of these VMS and the VMS handle all the problem of proof generation they are getting better and better we have like some new exciting developments related to for example Vu or Circle Starks so we've seen that for example it is possible with circle Starks in a macm 3 to prove like 600k hashes per second which is like a lot that's more like uh over like two orders of magnitude more than uh what we could do before these new proof systems

um and then of course Pro networks um give us the the chance to offload proof generation which which can still be uh computationally expensive um to other parties and there will be like some competition and then we can get like uh lower prices and of course then we have like new tools related to Hardware acceleration so uh I think that we will see like consistent improvements in improving and so then we have to look at the other half which is um proof verification and there we have like

two options one is this idea of um proof recursion okay the basic idea here is uh remember that I can prove let's say any kind of problem uh program one one program I could prove is for example that I verified a proof or that I verified two proofs so what I would be doing then is taking two proofs their public input feeding them to my prover and generating a proof that says that I verified those two proofs and the two proofs were valid so now if I verify this new proof this is exactly as if I

had verified the two older proofs so what I do is kind of bundle a collection of proofs into a single one and then I post that to the L1 and the L1 just verifies one proof uh but that proof is equivalent to maybe I don't know a thousand proofs and so the verification cost cost get split uh among the the different proofs and the other option of course would be to build a dedicated uh blockchain for proof verification okay so this would be like your two options either you move

verification of chain to another chain that will only handle Pro verification or you use this um proof recursion and or or you can do both right you could you could bundle and submit to separate blockchain and then you could and and the proofs that you submit to the separate blockchain you could bundle up a bunch of proofs together and then verify all of those at once and so I think you mentioned you know Groth 16 was like $6 um you can amortise the $6 across maybe thousands how many you know just if you know off the top of your head do you know how many proofs you could bundle together is it well right now uh and this is one of

the problems you have with with proof recursion you have remember that you have to prove that you verified like two proofs and uh even though verification is very fast proving verification is rather expensive because we have to prove all the operations involved in the verification which for example can in can involve um hash functions and so we have to represent um I don't know the ketcha cash function which is not that easy to to arithmetick uh normally or you have to do some things like uh field emulation if you're using

elliptic curves so of course there are like some of these let's call them aggregation layers that what they do is they do proof recursion um but the problem is you you can add like many proofs together because you have to prove that you verified proofs okay so uh I've seen some examples that maybe they can do 30 50 but the more proofs you add the slower it gets and so what you are doing is kind of trading cost for latency okay you say okay I'll have to wait more but then I can reduce costs

and so you have something where of course you get you reduce costs but maybe your application needs low latency and so how can you do that uh there is like an an Optimum but the problem is you see that for some applications then that you need low latency you're going to get higher costs and if you get like lower um uh low latency and higher cost so we there's a tradeoff we're crypto people are very picky we want both both we want both we want it to be cheap and fast and secure yeah everything and that's the problem we we're always facing blockchains you you can't always

have everything but we can come like pretty close to that if we accept like some basic changes or a little trade off somewhere else so as I was telling you you have this problem okay proof recursion uh you add latest but you reduce costs it may be useful for some I don't know rollups do this what rollups do is for example you want to prove the transactions in a block and instead of like proving the whole block you prove it it each transaction separately and then you use this idea to combine the the proofs of two

transactions into one and so what you do is like a binary tree of proofs and you get one final proof which is basically the proof of the block okay so that's one of the ideas with the verification layer of course then we are free to build our um own blockchain be like remove all the constraints from the evm we have like more design options we we can verify proofs like natively but then we face like other problems we have to bootstrap the econom iic security of the network we have to build a new community get operators and the problem we we have is

that in the end what we are trying to build is something that a new like like a new ethereum and something that is going to compete to to with with ethereum what what do you mean by direct verifications of proofs or or native proof verification the idea then is that we are going to run the verification using for example the RAS code directly on the CPU we are don't we are not running it on top of a virtual machine like you have in ethereum okay so there is no like emulation or or anything it's just the code running on on the CPU so of course then you get like several advantages compared to running them on top of a virtual machine and you can start leveraging for example

parallelization or some optimizations so that's the the whole idea so what we can do then is uh try to get the best of both worlds and that is where ion layer uh comes in okay so one of the main advantages that um we have with igen layer is that it allows us to bootstrap the security of an application thanks to raking and what it brings us is the possibility to get programmability on top of the evm without being constrained by it and competing for blog space okay

so uh we know that DM is good okay so this is where igon layer comes in IG layer allows us to bootstrap the security of our application thanks to restating so we don't have to build everything from from scratch and what it gives us basically is to have programmability on top of the evm without being constrained to it or having to compete for um blog space okay so the good thing is that then uh we can combine The Best of Both Worlds to build a decentralized um Integrity layer or

verification layer on top of ethereum okay so what we can do then is have our network of validators or verifiers which is secured by risk taking what the validators do is they receive the proofs they run them on top of their CPUs not on top of the evm okay and then they reach consensus and they post those results to ethereum ethereum then verifies uh their are signatures and everything saying that the results are valid and then ethereum can update the states so of those proofs so what we can then get is for example a cost um

reduction by having like uh efficient batching techniques so what we can do is for example uh create a task where we say verify these thousand proofs and what they do is they verify the Thousand if all all are correct and the majority of the validators say this is okay then they are sign the message saying this patch is okay they post it to ethereum and ethereum says okay these signatures are valid and everything so I have to update this and and so you can reduce here the cost by by a lot uh because you can in principle bundle as many proofs

as as you like and another Advantage is that you can easily incorporate an improved system the only thing you need is of course to have the verification code written in some language for example in Rust and then you just receive the proofs the public input and then you run the verification algorithm it's going to say true or false and based on that uh you reach agreement with the rest and everything so it's it's pretty efficient and the good thing is we are not building a new network from scratch and having its own like consensus algorithm it's here it's very simple simple it's just operators checking and signing messages and then

having like an an aggregator that just gets all the the signatures and produces the aggregate signature so we are then not competing with ethereum but we are getting all the advantages of doing things like in a separate uh network uh couple couple questions um on the yeah so um first one here is is on the uh the recursion or the aggregation of of these proofs um you know you mentioned before maybe 30 or 50 proofs uh at which point you know you you have an increase in latency um is there any increase in latency by by aggregating

the proofs this way you practically don't have latency you just um wait until you get maybe several proofs but once you get the batch it goes directly to the validators they just have to run this verification remember verifying each proof is uh very fast you can also use parallelization and then what they do is just they sign a message saying uh this batch is correct okay and then it gets sent to an aggregator the aggregator then checks that it reaches like Quorum that at least the majority said okay this is

correct and then the only thing it does is it generates this aggregated proof post posts it to ethereum so it's really fast maybe in a few blocks it it it doesn't need even a block but for example in in our case maybe you wait two or three blocks to give like some time uh why is why is this one much higher scale than the other proof systems that only you know they can only verify 3050 because here you are like not doing any complicated operation you are just having uh computers uh reexecute the verification in on top on top on top of

the CPU and get like true or false in the other case what you have to do is generate a proof of a verification which is way costlier than just running the verification proving adds like a lot of overhead on top of running a program so here you just do it in few milliseconds you can verify many proofs and in fact here we've tried it and you can maybe verify thousands of proofs per second uh with not so much effort and that's because um with igen layer you can utili you can uh reuse the consensus

mechanism of ethereum and you don't need to build your own consensus mechanism that's how yeah there is like no no consensus here or the only thing is each operator says signs a message with with with the root of the batch saying this batch is okay if at least two thirds agree on that then it's more than enough to generate the aggregated signature and then we post that to to ethereum ethereum then gets this signature and says okay this BLS signature is it valid or not and if it's valid then it knows that the batch is valid and can update the state of the batch to verify so that's the the main advantage you don't

have like any overhead it's like uh running the verification with like fewer nodes got it okay and then um you know you mentioned that you're uh you're not constrained to the evm which makes sense uh and then you also mentioned not being constrained or competing with block space but you do have to post the result of the proof onto ethereum so so how do you reconcile like not competing for Block space but posting the result to ethereum no but the amount of um of gas that we we spend is not that high and for the time being

we we send one batch every few blocks okay because there is not no not a very high like demand of course as it grows we can easily accommodate and send batches like more and more often uh but that is like just sending maybe one gr 16 proof or something a little bit larger so in the end think that compared to sending these uh millions or thousands of proofs together you're are just sending one so you are like compressing a lot yeah so that's the main advantage of course in our case we have at some point

to use like some block space but the the amount we have to use is negligible or very small compared to the one we would have to use if we wanted to do this on top of ethereum directly so that's the the main advantage and remember that uh we can make batches as large as we like so we we've tried making like very big batches and it works and you can do maybe 4,000 proofs per second at least that's what we tried on on testet so cool it's it's it's really cool and of course ion layer then lets you build other services which you can

then compose to build um decentralized applications and since one of the core Primitives to to have um decentralized applications is uh ZK okay because it allows you to compress uh computations and move them offchain and then check them onchain uh we think this will be one of the most important blocks for for many applications of course then there will be others that will be as or more important than this but this is going to be one I think core building block having these um decentralized

verification layers so some of the things we we can get is of course then provide for example fast finality for rollups on and app chains or even like some kind of pre-confirmation it also works to build like very fast Bridges develop new settlement layers make l1s interoperable with ethereum uh of course then you can also have verifiable machine learning onchain gaming okay and another important thing is that you can easily support multi prooving okay so right now most of the rollups what they do is they have the

their proof system they generate the proof with that proof system send it to ethereum ethereum verifies it and then they update the only problem that you have with that uh is that for example if your proof system has some buag uh or or some vulnerability then what may happen is somebody may take advantage and completely break your security Now if you're using two different proof systems and in order for the transaction to be valid re Rees that both um proofs are valid okay and then they depend on different uh assumptions and and techniques then it is much harder to

Break um the security of your system okay because then you have to produce two different valid proofs using two different proof systems and that may be uh very time consuming or even you could use something like tees for example to to provide like an alternative and the good thing here is you can verify them very cheaply and and very fast and you can easily add the the proof systems to to the verification layer as opposed to the case of ethereum where you have to use one of these not so expensive proof systems like gra 16 or or plun with kcg

or something like that okay and so what we think then is that we could be in the Broadband moment for for CK so as we said proven costs uh have been going down it's easier to write verifiable applications and so what you can build then is decentralized apps in a much easier way with increased security and so if then you remove the the main barer you have to use these applications because you want these applications to be run on chain uh then you have to tackle

verification costs if this is like really low then the cost of adding ZK to any application becomes negligible uh and so um what we can then do is um start building new kinds of applications people will find ways to use this technology that offers us increased security uh and it's it's really nice because it's like many other things that we had before that maybe we didn't find like um a a good use case or something but suddenly when it becomes like very

expensive and easy to use then people start using it like everywhere and they start having like new ideas the same that happened with internet before having broadband and after having that so people might have said like why do I need like more bandwidth if I am already okay and then you have of course all these streaming services YouTube social media and other things that were Unthinkable before this so I think that we may be close to a moment where CK uh can be used in many different places even outside blockchain because the main thing that it offers us is integrity showing that things are done correctly

without even having to uh look at it so here is an idea if you want to see of how uh aligned is is working so basically what you'll you'll have are just um users using the C Al to send their proof and some data to this uh verifier task Patcher okay that is going to receive the tasks and then create uh a batch okay so what it does then it once it gets like enough proofs it posts all the the data to to ethereum in fact what it posts is the the root of

a miracle tree containing all the data commitment to the data and with that it creates a a new task okay then the ABS operators what they do is they receive a notification that there is a new task and what they what they do is okay they go fetch all the information from a data service they download all the proofs run all the verification and then each of them if they see that the proofs are valid they sign a message with the root of the batch this gets sent uh to the BLS signature aggregator it sees that it has

quum Aggregates the the signatures sends them to the service manager and then the service manager just updates the state of the batch to verify it and then the only thing you have to do is um use your data and an authentication path to show that your proof is included in the batch to check that your proof is valid and then you can do whatever you like and here of course we we had like some information on how the payment system is going to work but overall it's um a nice and clean construction that you can use to verify proofs and as I as I was telling you you are not running on top of the

evbm or doing costly operations it's pretty easy and and then maybe some other moment I can talk a little bit more on how the payment system and everything is is going to work which has been one of the uh main focuses we had the the last weeks yeah yeah that sounds great I think this is a great overview of the the cryptographic uh system as it works um but would love to hear more about the the economic system and the incentives at stake okay um so of course then there are like some things that we are still thinking uh

related to uh the ABS and and and all that that we have to talk with with Ian but um the payment system is uh pretty straightforward the idea is that what you do when you send a task is um say how much you are willing to pay as a maximum for your proof to get verified and then what the Batcher does is it tries to build the biggest batch possible Trying to minimize the cost and for example if it sees that maybe bundling a thousand proofs it gets like

a a decent cost to include those thousand proofs and your proof and you offer to pay less than that of course then you are not going to get inside that batch and you'll have to wait um longer but for example if you said Okay I want to pay more but then we make a bigger batch then you are only charged for the cost of the batch and the idea is that you just make um a small deposit uh you have an account and then when you sign for the task and everything if then we send it the the Batcher is going to um take a small amount to pay for all the costs and then

if you want you can uh keep the funds inside this this account or withdraw them so depending on the amount of proofs you want to send and everything you can keep your balance there or or just withdraw it and then of course from these uh fees and everything we we cover the expenses for um the things we have to pay in ethereum that is the uh batch creation and the signature verification and then of course we we get a little Surplus to also pay for the economic security and everything that that we need to to secure the network

and and the rewards for the um validators so that's the the basic idea it's like um I think like pretty simple and intuitive which is something uh good and so users can understand the full flow and what and what's um going on there um and to give you like an example of of something you can build using this um uh simple architecture and everything is uh a bridge and in particular I am going to focus on the Mina to ethereum bridge which is

something that uh if you want to do it uh right now on ethereum it's pretty complicated why because Mina uses one proof system that is not uh cheap to verify in in ethereum and then what you have to do is do proof recursion in order to to be able to verify it in ethereum and that proof recursion is really costly it takes a lot of time uh we try like some Alternatives using for example ckvm but it takes a lot of time you have to improve the code uh to make it friendlier for the VM add pre compiles try to do things and even if you could like finish all this wrapping and

everything uh the problem that you have is that the bridge is not just verifying the proof because you can get a valid Mina State proof but then you also also have to check the consensus which depends on on on CK proofs in the case of Mina and then you have to also show your account show that your account is included in that state um so this can be like pretty complicated and if you want to do it in in ethereum it's also expensive so what we found found out is that um instead what we can build is a specialized um verifier that uh checks the state proof and the consensus

simultaneously okay and the proof is valid if an only leave the proof is valid and the consensus is valid that happens because in Mina for example what you could get is a valid proof from a previous state uh and then you'll try to update to a previous state and that is problematic the proof would be valid but the problem is it wouldn't check uh it wouldn't pass the consensus checks and then to to show account inclusion what we can do then is also have a specialized uh verifier to show account inclusion instead of doing uh a c proof or or something since the the account

inclusion is pretty simple then you can have like a direct verification of that so with all this you don't have additional proving no latency uh it it's it gets really simplified and the cost of of the bridge is way way lower than you would get if you had proof recursion and everything with ethereum so I think this is a very nice application that highlights the power of what you can have when you use avss or IG layer to build some specialized avss that uh remove some of the constraints you have with the BBM and this is something that um I

particularly am very excited because I was working at some point or helping like analyze some of the things of this proof system and all that and it was like really complicated and um seeing that this can be done in a more efficient way without having to do crazy things to aove system that is pretty efficient for their blockchain is is really nice and I think it will help connect uh two very interesting communities as are the ethereum community and the Mina community and so a little bit about the future then is that uh with Igan layer we will be able to build different

systems that then we can combine as Lego bricks to build new decentralized applications CK is what we need to solve the scalability uh issues that we face B in blockchains and also they are useful for these decentralized apps because at some point you will have to uh reexecute or do something and CK is a way of reducing the amount of re-execution you have to do and so with lower costs and easy to write applications we can expect that developers will find ways to use these Technologies to build new interesting products I think it

going to be great we can imagine also CK solving problems outside blockchains uh for example helping fight misinformation or control AI or making sure that uh the answers you get from AI are from the model you want to use and so we already know that there are like some very nice um use cases of um CK in in blockchain and even outside blockchain but I think that I am a bit more excited about the kind of of things I I still don't know that are going to happen I know that we are building all the

necessary infrastructure to make new decentralized applications and I know that a lot of younger and more talented people will find ways of uh taking advantage of this reduction in costs and development to build the future thanks if you have any questions or anything I think I asked all my questions uh throughout the presentation that was phenomenal thank you very much um I I'm equally excited about the future of ZK and uh all of the all the possibilities that are still unseen I think there's there's lots of lots of

very smart people working very hard and putting lots of energy into into this space and so uh we continue to see Innovations in ZK on the proving side and on the verification side and honestly I'm very excited uh for uh the ZK transition to take place I think it's already happening from optimistic to ZK and I think it'll continue to happen um so very very excited for uh scaling blockchains with with ZK thank you for being a big part of it thanks a lot always a pleasure talking with you I really enjoyed it