Where Aligned Layer Fits in The Modular Thesis

Transcript

good morning welcome back to another episode of the rollup today we are talking to aligned layer and that's right you guessed it aligned is ethereum these guys are launching an ID layer ABS totally for ZK proof verification and in this episode we're going to be talking about ZK proof verification as well as ZK generation and what it means to accelerate the road map of ethereum horns a Universal rollup Centric road map ZK plays an important piece of that as does aligned as ethereum's verification layer for ZK proofs so we're going to be talking to Maro and RJ about all of this and more stay tuned for today's episode

but first word from our sponsors that helped make all of this possible enjoy [Music] it cartey is your home for app specific rollups at the Forefront of developing new tools and platforms that enhance the capabilities of blockchain Technology cartey enables applications that are flexible and built to scale build on a full Linux environment and use traditional software libraries but in blockchain development go to cy. that's cy. to learn more about building your own app chain today welcome back to the rollup today

we have another good podcast with some leaders in the ZK realm these guys brains are bigger than mine but I'm going to expand mine today and we're gonna do it and we are gonna have some fun today we're gonna talk about the landscape of ZK the rise of some ZK VMS um the the presence of aligned um some a layer stuff and generally just get an update from some ogs in the space with regards to the progress of zero knowledge technology Rob has a math degree and philosophy quite an interesting combination so I know he's going to enjoy this one Rob good good morning and uh yeah how you doing I'm doing well man good morning good morning uh yeah I'm pretty stoked to get into ZK

it feels like uh it feels like ZK was like slowly then suddenly and now all at once and so uh tons of ZK proofs being generated verified we're going to dig into what all of that means and what the landscape looks like today and also where where we've uh where we've been and where we're going so pleasure to be here with a true OG in Maro um and RJ from aligned uh guys welcome to the rollup thank you guys excited to be here and thank you for taking it Taking us into account uh to explain what we're doing and some of the opinions we we have around the space it's in a very

exciting time bunch of stuff going on yes thank you for inviting us let's hope that we can make a good conversation so people can learn more about CK online and everything that's going on these days on the on the space yeah fantastic so arj you are uh one of the original um parts of Lambda and also now the co-founder of align and we have Maro here as well head of engineering and also co-founder of align um you know quick introduction about yourself your background um from from working with Lambda RJ and then we'll go tomorrow and then we will just start to unpack some of the landscape of ZK yeah

sure um yes so both of us actually come from Lambda class that is a venture studio uh focusing engineering work especially in software and in the last couple of years he has been focused mainly around cryptography and helping ethereum in different parts of the technology stack so I used to work for Lambda class as a software engineer I worked there for uh yeah almost two years but only always in mind with the idea of something doing something on my own in the future so I joined already with uh with this mindset and fed the founder of Lambda class tried to incubate me and teach me a bunch of stuff so at some point I could do something on my own and I consider

myself a crypto native I like crypto we're argentinians so for us building in crypto is also very meaningful because we want to solve some problems we have and we know other people have as well so I'm extremely passionate to try to solve some of the core issues I see and we decided to build yeter company that is the the company incubating aligned H with this mindset of solving different issues within the space in particular because we have a very strong background in sish proofs we saw a bunch of issues across the space and we realized okay we know very sure what's going to be the next botton like in the future and we want to start building toward that future so we can help any developer to build using verifiable computation in

the future so um we are very engineerm minded but our goal is to make things simple and very fast and cheap so we're building a line with the mindset of actually offering developers and infrastructure to access very cheap and fast verification awesome uh Moro maybe you could uh pick up where RJ left off you know tell us a little bit about your background and your experience in ZK and maybe you know RJ alluded to some of the problems uh that ZK has faced in recent years and so you know from a firsthand perspective what are these problems and and how did you see them when you were working in ZK yes so I have been working in cryptographic engineer uh a Lambda

class uh was working mostly with Lambda Wars making provs we build a star Pro uh BL Pro different types of rers and we have also bu things of to of them so we we were actually using them so there there are things that change uh for in in one side like proving systems improve a lot so now they are becoming really really fast and we can do things that we weren't allowed to do before um but also sometimes like the Integrations with ethereum is is not there yet so you get like this new Pro System inside okay aome I can prove a

thousand hashes in one second this is really fast but then you want to actually integrate with ethereum and it is impossible you cannot do it so align in some sense solves that um so now you can prove it whatever you want use the most efficient solution you want the one that is best for your product and then integrate with ethereum that's kind of where we are now and what we are providing as as a service in line right to be able to Pro what you want and use it in awesome so I think it would be super helpful for our community to have an understanding as to like where we are in the ZK landscape today you know I

think a lot of us have have heard quite a bit about ZK as far as uh it being kind of the next big thing in crypto uh technology and obviously we at the RO have done a lot of uh conversations about Mo about modularity we had a a guy come on from equilibrium to to discuss uh ZK eating the modular stack and so I think that there's been a lot of conversation recently but I'd love to get us and our community caught up as to the state of ZK today um and we can kind of break this off from there and set a foundation for the rest of this conversation yes of course so what we are seeing now probably is like all these ckvm starting to Wing ground like

to become the thing every developer is going to use I think five years ago we had like these other Alternatives that were more ciruit Bas when you had to go your own circuit in a language that was kind of complicated for users and then your solution only work for one program and it was kind of messy it was hard to use uh then this idea of ckvm started like think uh Star War were like one of the Pioneers on this they build their own ckvm that was uh Cairo uh and it worked really well for them but at that point people were still seeing okay what should we use uh ckvm or more this uh

circuit specific solution uh and now that things go faster uh maybe like the difference uh in inefficiency is not that much so you can have a very efficiency kbm that goes really really fast you start saying okay maybe maybe we don't even need this H St CBM that was Cyro before and we can just Pro prove R just prove any code that you have so programmers no no longer need to learn anything they don't need to learn any new language they don't need to learn how to build circuits they show right R they prove it it's really efficient they use every tool they already know uh and it works it was really really great uh we are seeing a boom of

of these thr systems and we have like sh we have sp1 we have Nexus like a really big boom of CK VMS and of course CK EVN for rollups that instead of proving R sometimes they try to prove like ethereum an node or things related tol2 but they are at their heart is kind of similar it's always trying to prove a VM no longer a genetic CID so that's what we have been see in these days I I don't know Andy if you have any other specific question about that yeah I mean you guys put out that that piece about why all proof

aggregation will effectively use uh general purpose ZK VMS and you know we were speaking to gem from Sovereign labs and they designed their kind of rollup framework with the bet on generalizable ZK VMS coming to Market I mean just a couple years ago it was all you know writing your own circuits there was there was idea of of of generalized of buy kvms but it wasn't really there um so why is your thesis so strong now as well that all proof aggregation systems will rely on basically risk five zkm or some sort of rust based ZK VMS and perhaps you could also allude to kind of

what the alternative would be for these proof aggregation systems if they didn't rely on generalizable ZK VMS and kind of why that is isn't uh Superior to using ZK VMS okay yes so that's that's a problem of aggregation so let's see at the beginning like when people try to to do agregation I think on uh Star War probably did it first with Starks so they designed the Stars to have a really good system of aggregation like stars are really good for recsy proof a recy proof is proving to people that you have verified a proof and why do you want to prove that you have verified a proof because if I prove to you that I have verified two proofs or eight proofs then

you only need to verify one that works for many and you can do maybe a tree and do a proof that have verified proofs that have verified proofs and it's it sounds like tongue twister or something but at some point you have only one final proof that is really efficient because it has proven to you many many things so and that approach for example with Starks were really well it work really well like you can use it but your problem there is then you can only aggregate a star proofs and probably star proofs of what of one kind like of one proving system or of one machine and what aggregations layer uh will need to do uh is to actually say Okay I I don't

care about which proving system you're are using I need to aggregate them all so you have some solutions that are specific for some proving system for example you could do some one for stars you could do one for grossy as other layers are using you can do a kind of good solution for each PR system but then you you cannot merge them together at some point if you want to merge all the proofs of all the proving system you you need to find some common mechanis so if you have a a Ras Pro then this becomes really easy because the only thing that you have to do is to run the native verifier and you generate the proof that you execute the the native verifier verifier that allows

you to kind of unify all the proving systems uh into one so that's a dis is like there are too many bring systems you can only Mery conventional means some of these proving systems and with themselves usually you cannot mix them uh by using these new Ras provs you you are able to just MCH any proof make a recursive proof or an aggregation proof of whatever you want and it works it's it's really awesome so to give like a a perspective more from the business side right what Maro mention is okay we have this thesis we have this trend that

CK BMS are getting really good verifying proving rust so why do we believe that trend is true one of them is pretty simple you can check the benchmarks of rck s sp1 uh we now have also Nexus and ucbm in the market all of these teams are working and improving a lot the technology they have been developing for the last couple of years and the trend is pretty clear that CK is accelerating not only in software where we have a lot of things uh that are improving a lot so usability and of course proving times but also we are seeing a lot of Hardware um how acceleration improvements as well in the other in another part of the ecosystem so taking that into account if we know the rust proving is going to get

way better is a significant advancement when you want to create new software so we believe for this type of variation layers is not only useful for the technology in itself that is solving a problem as Maro mentioned of hey I have a lot of different type of proofs I need to arrogate them together but they have different properties the best way to do so is I verify I do I prove the verification of uh the different type of proven systems using rust so for us it's obvious this will be the default because you can go to a market way faster you can actually use and developers that maybe they're not cryptography specific or they have a good math background but they don't need to know about C in

particular that means the space is more scalable and you can start developing these Solutions more similar to what you used to do with other type of software products in the past so from a business perspective this also makes sense because now more people or more teams will be able to start developing this type of stuff and this is the best way to make this um to to actually create an aration service that is one interface for all proofs so this this is why we are extremely confident is going to be the default solution because of technical reasons and because of business organization reasons it's easy it's fast and it's going to get better totally

that that makes a lot of sense I think you frame the problem well of aggregation which is easy to understand in theory um especially once you understand the the recursive nature of these proofs um but in practice um when you take into account that all of these different proof systems run on different algorithms they're all ZK proofs but they're different kinds of ZK proofs that's when it gets quite hairy um and so Maro you mentioned this idea of a native verifier could you can you unpack with the native verifier means in context of aggregating proofs for multiple different proving systems yes the native verifier is just like the verifier that you usually

provide for the library does IDE aggregation that's the same we use in align in fast mode we run the native verifiers this is just it's just the verifier but let's say that maybe you can have a solidity verifier maybe you can have some uh other types of verifier sometimes you you find around but this will be like the the standard one the one that the library provides and and how do you make sure that this this the verification of these proofs is compatible with proofs of all different types of proving systems because essentially this verifier is usually written in Ras or some programming language it doesn't matter if it's not

Ras if it is Ras it just makes the work easier but uh if you have RAs then you can run the verifier like let's say in your machine and now sp1 comes or any R prover comes and says okay you can prove any Ras code that you have in particular if you can prove any Ras code that you have you can prove the code of the verifier so you can just use the verifier of any any CK product and make a proof of it and that's essentially a recursive proof uh and there is no reason why you cannot do that with two verifiers of different types or three or as many as you want as long as you have

the native code and you can compile to r five or some other architecture you can prove it's okay you can make a recursive proof you can aggregate the proofs and it show Works awesome so you guys were able to reduce this like really complex problem of trying to verify multiple different types of ZK proofs you're able to reduce that all the way down to just verifying rust proofs because you realize that once you verify rust proofs you're you're able to verify all the other ones via rust exactly yes awesome and that was the key innovation of the ZK VMS correct like that's the that's the big aha moment for the ZK VMS of course like this is only possible

with fast ckvm like before it was impossible this didn't make any sense right and does that have to do with the this half based proving system being Superior to these elliptical curve proving systems or is like it I from what I understand like these like these zkm employ more of a hash based model which is theoretically Superior to to this elliptical Curve Model or maybe I'm dumbing this down too much but maybe you could shed some light on that it's it's actually funny that is it's not that they are theoretical Superior it's that in practice they tend to be faster in fact there was a huge discussion because in theory the other ones look faster like the non hash base but in practice

they usually the hash Bas are faster so yeah most of the new cbms are hash based like they either using Venus or fry those are commitment schemes we can talk about them later but they use a lot of hashes internally and Sh I think is the only one using lookup tables on kcg that is elliptic BAS um they have in the room map uh this idea of changing to vus so if they change to vus it's going to be once again uh a hash Bas uh VM and what are the economics of this uh these systems because the zkm are are mostly concerned with proof

generation right and so you guys are are entirely focused on proof verification and so H how do you at aligned work with some of these ZK VMS to verify the proofs that they generate what are what is the economic balance between those those two systems the in first mod what what we do is just verifying their proofs um our idea with the line is that you you should run this this Pro and for example one thing that they have in common they all make really big proofs we manag to generate proofs of that wait one gab with s sp1 and it was a real application

and it's one gab there is no way we putting one gab in it right and they usually have an alternative I it's not like they don't they have a compression mode they use recursive proof to change to gry thing and you can do that but that's more expensive like it takes bigger machines suddenly you need to prove smaller programs because you need to add all these extra steps and it has latency latency like it takes time I could have the the proofs now but I have to wait 10 more minutes one hour more maybe more than one hour just to wait for the final compressed proof and in a line you just send the proof like just as it is it doesn't matter if it is weak

it doesn't matter if it is more expensive to verify because the problem is in ethereum verifying even things that should be cheap is expensive uh but for a computer they're actually cheap cheap there are some balances that Bings are very cheap but maybe hashes are not but for a computer a normal computer the hash is is cheap it's not expensive so allign leverage that so you can actually verify whatever you want uh really cheaply and well then we have some mechanisms to actually get the results to to etherum I don't know if that answers the question feel free to yeah to ask me back I think like unpacking the architecture and taking a

quick step back is is going to be helpful here RJ we've talked at length about kind of why a line being focused on just verification would be almost an incomplete stack um where not focusing also on aggregation doesn't give you the the whole experience that we that that you can achieve with a system like this so maybe we can just understand the architecture a bit deeper here and why just having a verification side of things almost leads you to an incomplete uh stack for this broader aggregation and verification component there yeah so I think it would be helpful if we give

an intuition of the problem we're trying to solve like understand why are we focusing in verification because agregation itself is also focused on verification right it's just a technique so we believe that the next bottleneck for actually the adoption of CK is verification because as what Maro said before actually verify improves in in ethereum is super costly if you want to run for example a c rollup you need millions of dollars per year I don't think any developer has millions of dollars per year if they want to start a brand new H startup or they want to start playing around with different ideas so we are 100% sure that after the CK BMS and all of the CK systems mature

the next big problem to solve is actually verification so we can unlock more use cases and more people actually using these systems so to solve this problem you need to understand okay which are the options I have in order to offer cheap uh verification on top of ethereum there are two ways one of them is the one Maro described and we talked before regarding a proof of aggregation and the other one is we have now some brand new tool to explore different designs that is I layer that allows us to create brand infrastructure so what we are building is a CK verification layer that is decentralized from the beginning and we run in multiple notes the verifiers of all of the proof

systems we want to support and we receive the proofs the sent by the developers we verify them and we can post the result on ethereum and we can do this with an incredible high throughput and offer prices that are extremely cheap and actually this design um because we are thinking it from the beginning to solve this problem of verification we can have a very scalable system and it's designed for the future of CK as because we can integrate any type of proof system that exists in the future so we're offering both approaches because what we want to do is offer developers more options so they are the ones who can decide which one is more suitable for their needs so more some developers would say okay I need

something extremely cheap and fast I will use what we call the fast mode that is the ABS we're building in a or others can say hey I don't have a agency issue I could have H the proof settle in a longer time period I'm okay with that but I would rather have that with the full Economic Security of ethereum so our approach is let's give the developers more options kind of like what other people building in the mod St are doing and let then decide which one is better for the needs and the good thing is by building one product that offers the two of them it's super easy for them to build new type of protocols that merge the two of them or in the future if they want to switch it should be very simple they don't need to

upgrade their smart contracts they don't need to redesign everything completely it's only one interface where they cancel all of their proof and they decide which one uh is better for them and Maro for example if you want you can give a better understanding of the architecture in itself but the the problem we're trying to solve is offering cheap verification by offering the two methods so the architecture is really simple that's what allows us to kind of verify all the proofs that that we want uh sometimes people ask me how many proofs we can verify we can verify as many as we want right now we are doing like 200 and 500 uh 2,500 per second yeah so that's numbers

go up really high like that's batches of uh 100K proofs so the real problem becomes a ethereum one can't handle that capacity so what what we're trying to do is to extend the capabilities of it eum right now if you want to submit your verification even if it is cheap yeah and you can pay it like I don't know we are using a gr 16 proof is cheap okay how many can they fit in a block 100 that's not enough to scale eum it doesn't matter like we we want to put like one two orders of magnitude more proofs in eum per block so that will allow you to build like this new kind of

application I don't know which kind of application people will build with CK you kind of can you are kind of sending ethereum to do whatever you want like you're doing a lot of processing and then you put a proof and you get the results do you want to run a machine learning algorithm some AI program that runs for one hour and gives you a solution and you want to act on on that in etherum you can do that I don't know I don't know what's the feuture but what but we are really sure that right now it doesn't have enough capacity it needs it needs to be proove so uh how it works as I said before it's really simple we are leveraging like reaking of Aon layer so the idea is to

let people who are already staking in in eum to use their same stake to to stake in our services and EV validator set is going to sign all the verification is going to say okay I have verified this 100,000 proofs and they are all okay and they all sign together and when they reach quarum we send an aggregated signature to ethereum and then you have okay the the result in eum like this batch of all this proof is verified and is correct uh and then you to access that uh the more common way will be like using a markerry uh uh and proving that your proof is including americ Tre and

doing some extra checks so that's the only cost that you see as that the user Bas in ethereum like leaving aside our system is not much uh and we will we will reduce it like we will change that architecture too so so it can be even less so that's how it works a very high level overview I don't know if you have any questions yeah I mean from what I understand based off that using ethereum's validator sets uh via a lay you're very ethereum aligned and like that you're trying to accelerate ethereum's uh kind of road map if you will but like there's also this this

idea here of like State minimized nature of aign itself where like aign is is almost like this like stateless architecture unlike other blockchains which I I'm still trying to wrap my head around whether I agree with this design choice or not why it's a good thing or why it can be kind of more centralized maybe you could give give me the community uh some idea as to why this kind of state minimized design was chosen and how it's not going to lead to a more centralized outcome yeah it's funny because sometimes people ask us if we are a blockchain and I say to them we are not a blockchain we don't have blogs and we don't have a chain so we we cannot be a blockchain so maybe do you want to to maybe answer from the

business perspective a little bit I think it's going to be better for this question yeah and actually it's funny because one of the first things we were discussing internally when we got the the idea back in January or February was we're defining the the first architecture and we spent some time discussing this because uh some people in the team wanted to go into a more traditional approach but we ended up with this stateless design that what this means is aligned in itself doesn't have blocks as Mar mentioned it means it's a decentralized network of nodes but the computation they do or the framew they agree on is the outcome of a specific computation in this case the verification of a proof so for us what we are receiving the

network receives is proofs the notes check that received the proof and run the computation the verify the verification of the proof and they sign hey this computation wasn't the verification of this proof is actually true or false so we don't have a block we don't need to have transactions on top of this the only thing we need is these operators to check the the verification of this proof and sign that the output they receive is actually true and this is important because it allows us for more flexibility when we canate when when we're designing the architecture of this system why because we can paralyze stuff proof a proof um a stet proof is the same we can verify in

parallel with a CK sync proof If we have in the system why because they don't touch any state the problem with blockchains when you want to paralyze stuff is when you want to access the the same memory right when you want to have transactions that actually um touch the same state in this case we don't care we just receive proofs we verify them we have no idea what they have inside of them if they have transactions that uh have a conflict or not so this stess design is super important for us to allow us to actually scale to the numbers Mao was mentioning we can have these numbers because the whole architecture was designed with the only specific purpose of verifying so we remove a lot of the things that we have

in normal blockchains to focus in the main feature we were offering right and again I'm bullsh on this idea and I'm just picking and prodding here so just bear with me but how does not having a chain not end up in just a very centralized Whoever has the most whichever operator has the most metal or Tech gets to basically make the decision on what on whether these proofs are verified true or not like how does this not just coales into centralization how do you breed decentralization I don't know if it's token if it's if it's needing to do like a permission operator set it first and expand slowly or like how do you kind of approach this from from like the the ethos perspective of

crypto as a whole um and also to to keep censorship resistance in your system yeah we we do keep all of these properties because we are actually decentralized so we do have a decentralized network of nodes and for that we are using as we mentioned n layer to bootstrap it so even if we don't have a block in itself or a chain we do have uh all operators or validators reaching a consensus or agreeing on something that happened on on the networking itself so um the staking itself is done by reaking so of course we have like a similar Dynamic to other abss but in the future we're exploring the idea of introducing a dual

sing model so we can minimize some of the risk having only one asset in a sing chain can bring if I'm wrong Maro but the Quorum situation is similar to other proof of stake systems welcome aboard on our journey into the singularity this is the endgame road map for fra and fractal the new L2 out of the frax ecosystem that is totally based on fractal scaling fra St the modular L2 blockchain built by fra with modular and fra scaling in mind fractal scaling is based on the mandal BR set of fractal images and it explains how l2s become l3s and the entire app

chain life cycle goes through its Evolution the frax ecosystem is made of some of the top builders in the space and has stemmed from its OG days of the frax stable coin it is now in the LST space the LRT space and this frax L2 joins the existing Suite of fra products including fra Swap and frax lend you can see frax fairy the bridge to go from any chain arbitrum optimism or main net into the fraxel main net Bridge your tokens and bring your FRA assets into the fractal ecosystem join today to get the

best out of fraxo you are still early join today take part in our Expedition into the singularity yes you we need for for a v to be considered uh correct with all the proofs verified you need to reach a quarum like I'm that quum is switch with when enough state has voted that that b is correct so it's really decentralized like it's the the requirements of the machine are not so high uh and I don't know if one note goes faster they can send in

signature but the blockchain won't uh advance I mean the blockchain the system won't advance until it reaches aarum so it it's just yeah it's not a problem and in the task they don't have any they don't depend on each other you can verify the batch number 10 U maybe another can be on batch number eight it's not optimal because that will mean that the things could go faster probably but that will happen and it's not a problem like because there is no correlation between each V understood I think I think I'm being a little silly as well considering that using avss means that you get to basically inherit all of the decentralized nature of

ethereum stakers itself however I think the concern was more about what is built on top of that um but thank you for the clarification Rob yeah I I mean I have a a different but related question uh related to the igen layer stakers and and and node operators that you leverage by being an ABS on igen lay um you guys are using the the economic stake of ethereum and the stakers and validators of ethereum to to verify these proofs like I I I heard earlier that you know some of the nodes in the system are using grath 16 some of them verify plony some of them you know you guys verif you

guys have nodes to verify each of these different ZK proof systems no maro's shaking his head so maybe I misunderstood something earlier please please jump in because I think no it's it's almost the same but it's like a minor subtle difference like then each node is verifying all kind of proofs like the batches are like they we don't have batches of one type of proof that's the other Advantage like I don't need for everyone to be using sp1 or e z or sharar they can use whatever they want they all get group together so the the price is split between all the users no matter the proving system got it and then you're and then aligned generalizes

this verification method so that it can verify all of these different proofs no matter what kind of like proving system they generated from The Operators need to be able to run the cod with the verifier so they should be add to the network uh if you make your own proving system this night and you say I want it not to verify it in a line you I will tell you no you cannot like but you can uh we will Design some upgrade mechanisms to Define which verifiers are in in the network and if the operators have them available they they can run them um verify them and it works so so when we're thinking about the economics

of this system and how you guys are uh coordinating these these proof verifications um igen layer is committing economic or I layer stakers are committing economic stake and and when you commit economic stake you put it at risk of slashing right so could you just as a helpful exercise could you kind of walk through you know what would cause some slashing of an of a validator you know if they misbehave what would be an example of a validator misbehaving in which they would get slashed um in in case of aligned ABS sure so we have an advantage I think compared to other designs is

that what we do computational wise is simple we do only one thing run the verifiers of all these proving systems so if someone misbehaves in the system what they will be doing is saying hey I got a proof for example that it's false and the outcome I'm saying that that that I got after verification is true that will be a slash event uh that we have in our system and is easy for us to understand which are the risks or how we should um Design This the the scenario because the only outcome we can have is true or false when we receive approv so what we are thinking but this is the

beginning of the of the design for for the slash offenses is in case about validator decides to put that an outcome um is true when the proof was false you can trigger an onchain computation where can you can actually check on ethereum that for that particular proof a validator said that it was a true that it was false you can prove OB objectively on ethereum that that was not the case so you can slash it pretty easily um that being said slashing in abss is still something new we don't have that live in our testet and one second layer has that feature available we will work on this um but there are some subtleties that we need to take

into into account into the future because not every single proven system can be actually verified today in ethereum some of the ones that Maro described before that have big proofs is quite difficult so we will need to analyze very carefully how we can administrate all of them um but the general intuition is someone misbehaves in the system you can check and do the computation on ethereum and eum will decide if he's wrong or right and if he's wrong and he misbehave we're going to slash him gotcha um now on the test net side of things obviously still on testnet here but we've been seeing some LRT projects start to delegate or make commitments to certain abss in the space

um probably more of a question for you RJ like what's the what is the current situation with regards to uh potential commitments or or like even how does how would commitments from LRT providers help to help align uh Economic Security model yeah so right now we haven't dis disclosed or had any partnership with any othert so far because we have been focusing the test net and we are on boarding our first operators who they have many of them because they are operational they are professional operators they have their own stake and their own business behind it uh but they have a lot of ethereum to actually delegate and secure system so yes we are

planning to work with everyone in the ecosystem in IG layer so we can boost up the network pretty fast and we can get to a very high amount of Economic Security like most of the abses we have been seen in the space they get at least one billion dollars of Economic Security and we are pretty confident with the conversations we have been having with many of them that we can get to these numbers so um the allergies in specific we haven't done any work with them just now but we are planning to work more and work with anyone I mean we are pretty pretty pragmatic and approachable so uh for us it's just having more people in our system and actually offering

something that is decentralized nice and and just to close the loop on on kind of my previous question about slashing and and also to bring in in these LRT operators um so the other side of Slash casing is is yield right that's why these stakers put up their state and so uh I imagine the idea here is that um for each verification that a line does there's some small Commission of value that that is acred um and then that in turn pays the yield to these operators and stakers for committing their Economic Security to the to the system and so could you talk you know again it's very very early days so maybe you

don't have concrete numbers but you know how do the economics work and kind of trickle down from the people who are paying for these verification costs ultimately gets into the hands of the lrts and The Operators and the stakers in in the form of yield I think to give an analogy on how we are thinking about um fees and revenue for the network itself we have a similar business of what other C Co processors or LS have meaning we're offering a more efficient way of accessing uh posting results or consuming block space in ethereum right because what we're doing is we are improving the amount of proof that you can actually verify on ethereum by using

the economic security of them so the phe that we will be getting it will be a premium on top of the H cost that we actually have to operate the system so it's kind of similar to what a sequencer has but in a decentralized manner because it's an actual Network so we with the numbers we have been getting we are at least 90% cheaper for almost all of the proving systems and that will depend a lot on the amount of proof we receive because the more proof we receive and the bigger the batch that we can create the cheaper it will get so we have a problem that is also kind of similar to what Solana had or many of these uh very performant blockchains have were so cheap that it's hard to put a very good price that can

start making uh some sense the good thing is that if you build something that is scalable and you can get all of the proofs or many of the proofs that today don't exist because what we are saying is hey we are not only helping people who are building today but most likely we are creating a new market because now everyone will be able to verify proof on on on ethereum they couldn't do it before now everyone will be able to do so so the the model we have in mind is taking into account this true properties right we we are offering um a better way to access blocks space on ethereum and at the same time we're so cheap that it's going to be hard to price it correctly so we are going to start with

a very Primal approach on yeah having for different proving system different prices depending on uh how computationally heavy they are and compared to what we should charge on ethereum so we always be way cheaper on ethereum but at the same time um the system and The Operators can actually gain fees um but the good thing is their revenue will come from the amount of proofs we receive gotcha good uh interesting race to the bottom dynamic in a sense where like you build Tech that's that's helping the user experience that's helping the ecosystem scale y but then the revenue question kind of comes in and it's it's an interesting rent seeking versus public good it's always a question so curious

to see how you guys kind of play that one out last thing that I have for you Maro um for you actually what's the amount of proofs per second on test net if you can share where do you see us being at the end of the year for proofs per second and also what are the other development hurdles in the next couple months the max amount of proof we verify per second is 2,500 like we didn't push the limit of the network uh like it could be higher so that's was around 100 K per batch uh or and I think that was over 30 second more or less so as you can see the amount is extremely high so in in fact

it's funny we are we are now solving a problem we created because we verify so many proof that even if imagine that that consuming a proof using this proof is just sending one transfer of ethereum how many transfer can you fit in a block you cannot fit as much as we can fit proofs so like so even if if everyone try to use those proofs then we will collapse ethereum so now we well this is in the RO map uh what we need to do is to do a lot of upgrades to actually reduce the cost of actually reading the proofs we have some ideas um and and that's probably the most important uh number because even if if

we do more than 2,500 like you wouldn't be able to actually use uh so yeah I don't know if that's satisfactory like the other the other answer why I'm confident that we can put as many as as we want it's like the this problem gets solved with a bigger machine right you just put a bigger machine you can do more proofs for second let's say that we want to do even more okay each each node can be many machines we can do it a really Web Two approach you run into the you run into the centralization problem always yeah you you run as far more phones you want like it doesn't matter it doesn't even have to be the same device as long as the stake

signs the The Operators sign with their state that is correct so limit how can we aggregate how can we aggregate 2500 into one or 10,000 into into one yeah this is this is a fast mod the aggregation is more tricky like uh it's probably going to be more bottleneck I don't have the numbers on that uh I think I I did a simplification before saying that we will just use one way of agregation of aggregation we will probably have to mix systems and do something SM smarter uh as soon as we have some Open Designs I'm glad to share with you and we can come back and discuss that part

awesome thanks guys for coming on it's been a pleasure RJ Maro Rob of course um learned quite a bit and excited to see the continuous acceleration of ZK cheers thank you guys thank you very much