Modular March EP 10: Endless Modular Application Possibilities with Lagrange

Transcript

welcome to modular March I'm handy this is Robbie and we are the rollup modular March is an educational experience about all things Moder [Music] enjoy [Music] [Applause] [Music] welcome back to modular march today we

have isma from lrange Labs talking about bringing ZKA processing to co-processing to the modular stack isma GM sir gm Andy Robbie thanks for having me again excited to be here yeah for sure it's always a pleasure yeah it's good to have you on man and I think uh now now uh and uh continuing on we're gonna see some very interesting developments things are G to get really really weird so before we like dive into like exactly the architecture and what you guys are doing co-processing ZK proving um could you tell us like generally and this is going to be we're

going to get memd by the end of this but generally like what what does modularity mean to you when you look at the landscape and how it's evolving I love it modularity for me means customization it means you want block space you want your application to have its own block space and you get to customize that as you see fit you get to pick your da you get to pick your execution environment you get to pick your sequencing and very soon you get to pick your co-processing you deploy your chain you configure your chain you get your chain however you want awesome okay and that leads right into co-processing so right now we can't pick our own co-processors like what is the what is the current landscape why are they currently bundled and and why

are you guys trying to unbundle that from the monolithic stack and and provide some more optionality um kind of like what what are what's the state of co-processing when it when it comes to these chains yeah co-processing is early I like to think of co-processing as a thesis like what da was or shared sequencing was a year ago it's a new thing it's an exciting thing there's a bunch of use cases and people are just figuring out how to use it and so right now on ethereum we have a few teams like lrange that are deploying co-processors but a lot of the infrastructure is tightly baked into ethereum it's not designed to be flexible or malleable or or modular any capacity and so what we're very excited about and what a recent announcement in fact was with us

and and one of our partners alt layer was how do we take a co-processor and start having that deployed on the modular stack how do you spin up a rollup with with your own with a DA that you've chosen a sequencer that you've chosen and now with a a co-processor a series of co-processor that you've chosen the Grange has some some very interesting ZK technology that we build and when we can deploy that on the modular chain it really expands what you can do on that chain awesome and and one more here is like co-processor is the solution so what what is the problem that co-processor Sol yeah so the problem that co-processor solve is that there's something heavy and intensive that I want to do in my

contract right I have a rollup that's building a game and my game wants to be able to querry the pudgy Penguins contract of ethereum it has the ethereum block header from its bridge to ethereum but how does it say you know does Andy own a penguin how many penguins is zy on what are the traits what are the properties of those when you want to access that indexed expressive complex data on chain you can't do that today because that's heavy and computationally intensive you can access it offchain with an indexer but your contracts can't access that data so what co-processing lets you do is to take that intensive computation lift it out of your contracts prove it in ZK and then verify that back into contracts think of an

asynchronous program that you can that you can lift off chain run and then verify back down on Chan gotcha yes so yeah so so even even even taking a step even even further back the the idea behind the desire to index or to core data to use more data like like why like why why do you see this as something that we're that the space is going to need yeah I think it's a question of maturity of the applications you wouldn't build an application web to without a database right if I was to I'm going to build a web app the number one

thing you think of is what's the FR what's the the front stack going to be and then what's my database stack going to be am I going to use am I going to use uh postris how are these things going to be tightly coupled together but with blockchains we typically aren't able to think about our data on chain like a database we can't Define a schema we can't Quarry the schema we are just really constrained with what you can store in a state machine that's not optimized for storage and so what you get with with co-process specifically what we do is is the ability to have a lot more data Rich applications that you build got it so we can build like apps that that we we would see in traditional world and in on mobile on desktop which

is kind of being limited currently in the yeah you can build fun stuff you can build cool stuff you can build better defi you can build richer game experiences you can build incentive programs that are continually issued VIP Trader programs you can build blur but verifiable verifiable and and the verifiability I think like I I even in my own Journey kind of like through learning about blockchain applications I've kind of like Tangled with like what is the core Innovation here that that takes like a ledger and makes it into a blockchain and I I'm I'm continuing to converge to this verifiability concept when when you look at a database and you look at rows and columns and then you

look at a general ledger like a blockchain like again rows and columns is it the verifi the verifiability that makes these blockchains special that it what if if so like why do you think verifiability is so special about about blockchains yeah that's a great question so you think of a blockchain and you think of just the data structure just let's say the marel Patricia try that you have within ethereum it's a giant key Value Store you have your contract address you have your memory slot then you have a value and what you have is is a giant data structure that encodes a very very large uh basically mapping and so what

you can do when you have that data structure is you can build computation that sits on top of that that lets you access and play with and manipulate that data in new ways and so what the blockchain's really really really good at is authenticating that data we know that if it says that you have some asset balance or you have some nft it is in fact correct that there's a provenance that there's a a chronology of transactions and transfers that are indelible that can't be falsified but you can't interact with the data you've authenticated it that you know it's true and real but you can't manipulate it the way you'd want to in your applications that's why it's synergetic ZK and and

blockchain yeah we call it ZK magic over here um I love that and yeah I think that I figured that and so you guys are are kind of pushing the boundaries with with I layer as well in some of these kind of avss actively validated Services how does co-processing align or how is that intertwined with this idea of actively validated Services that's a phenomenal question and so we think about co-processing and ZK what does that give you it gives you safety of computation I know that the person who gave me this computation gave me the right result because they gave me a proof what you

don't get from ZK is liveness if I ask for that proof tomorrow at 2 pm how do I know I get it back by 203 how do I know the guy I'm asking he's not on vacation is going to never give it back to me because he's tried his computer off that is what you get from a a protocol that is what you get from a network a guarantee of liveness that you can get the proof the computation and the data that you need when you need it and that's where where where Network building infrastructure things like I ler plays so well with with safety of computation so by being able to take the things that the Grange builds or co-processor and deploy that as an AVS what we're able to do is to have a very

high degree of liveness over how you get those proofs so you can build things that have tremendous value secured by these proofs with a guarantee that if you need that proof tomorrow at 2m so if you can rebase your LRT or you can compute some really important action some game you'll get your proof on time when ether is going with a $500 million commitment to use lr's uh basically co-processing for for their abs what they're trying to enable is this livess is guaranteed liveness is is that correctely like so like how does that look like from under the hood like so

what's what's going on there under the hood we build a network just like you would build a network for a proof of stake blockchain but instead of it being a proof of stake blockchain it's a network that can compute hyperparallel proven and so what that network is able to do is it's able to distribute requests for proving across tens of thousands of nodes potentially and is then able to take back the partial proofs and compose those into a final proof and so the liveness is a product of all the nodes who are independently Computing parts of that proof instead of a single actor who's Computing it and so what ether fi has committed to to what you mentioning before is is a $500 million delegation commitment to delegate Capital to secure these nodes

who are doing the parallel proven and this is a first ofit kind Arrangement where where the operators of lr's core infrastructure who are obviously unaffiliated with lrange decentralized operators de centralized nodes they will have many of them an incredibly High degree of Economic Security guaranteed by Forward Thinking LRT protocols the first that we've announced is ethery and these these nodes that are contributing partial proofs to the lrange network the network of these proofs ultimately combined into it into a single proof we've seen prover networks start to evolve from kind of

like this ZK proving space is there is there an element where these these nodes are competing against one another or are they really kind of on the same team and collectively building these proofs together in our architecture they're on the same team they're not necessarily Computing against each other on speed um what what they are effectively trying to do is to orchestrate a very large computation in distributive fashion and I think the best thing the best way to think about the architecture is is that you have general purpose proving networks that they build proofs for their own applications or sorry they build proofs for general purpose application where you say I want a plunky to proof and I want someone to compute that for me and then you can

deploy your circuit on that proving Network they can compute that proof and they can give you that proof what we do is we have a very tightly baked together stack we build the proof constructions the proving systems and we build the architecture required to do hyperparallel proving and we bake that together into what is LR got it yeah not to uh take any shots at at some of the other ZK proving networks out there but from what I was learning they are running the only prover on their Network so you don't really get that same competition you know if there's only a single prover and it's a very small a small set of uh provs that are running on on that Network okay so so could you kind of

like talk us through the modularity aspect of yeah of of lrange and kind of like how you're able to separate out uh different jobs to produce these ZK proofs um while also kind of like pulling them all back together so that they're all very succinct yeah so so the two parts of that question where does this touch modular I think that's the most exciting question that I that I love talking about with this I I think the core of modular as I was mentioning before customizability that you want to deploy your rollup with your own set of requirements maybe it's for a game maybe it's for a per deex maybe it's for a um

a order book and you want to ensure that it has everything pre-baked day one for you to be able to deliver your application you want to pick your VM you want to pick your da you want to pick your sequencer and in many of these cases you also want to pick a co-processor you want to pick how the database would work you want to pick how the schemas work for how you're able to manipulate and that data you're able to customize things when you get the option to be modular not just in your sequencing your execution and your da but also with your proving your co-processing think about this as just another Vector that a developer in the modular ecosystem can play with another lever they can pull to customize their rollup so what kind of permissions are required like like like obviously you

guys have done a lot of extensive work with ethery and ALT layer to get these over the line but to see lrange go and be able to interact with you know hundreds of acific chains say dozens general purpose rollups and a variety of chains like like is there a bottleneck like what is the permissions required to interact with lrange from a builder's perspective yeah so there there there is in fact over time no bottleneck the beautiful thing about ZK is that it's super light to deploy where in the event that I want a a node to be able to serve computation over an arbitrary rollup I

only need in theory one node to do that to be able to get that proof eventually if that's a popular rollup and I need guarantees of liveness you can have many nodes doing that um hence why we're talking about the hyperparallel and distributed proving and the decentralized proving but at at the absolute limit if you want to co-process with L grange on your chain you just need to deploy one prover or someone needs to deploy one prover super light or the prover is heavy but the the the operational overhead of getting one person deploy one pro for you is pretty L right there's no need to come to me and Lobby me to come and deploy something for you you can just do it yourself out of the box day one that's a little bit longer term shortterm our test time that's coming out very very

soon might be out already by now um that is going to have a little bit of permissioning around it to make sure we can ensure everything goes great day one but but over time everything is going to be fully permissionless and fully uh fully aligned with with our belief and I think the Mau space's belief in permissive deployments yeah gotcha um one thing about ZK currently while I think the entire space agrees that it's at unlike ZK magic is the future of interoperability of of verifiability of many different spaces within the uh ecosystem it's it's quite expensive and sometimes slow to prove now

how are you guys kind of handling the the cost and speed of of um proving with regards to the applications that you're working with yeah that's a great question so ZK is going to be more expensive by several orders of magnitude compared to just outright computation so what we think the future is is twofold it's find the applications that have an imperative on secure computation where does the computation that's intrinsic to the protocol be the things that exist today Oracle the indexer underwrite so much value that they're willing to pay more for security think about if you're a def5 protocol with 10 billion in assets would you pay 5,000 a month to

make sure Oracle doesn't get wrecked yeah you would it's it's pretty much of a no-brainer in that case um if you're a gamey application and you have four users you're trying to bootstrap then it becomes a different question and so that comes to the second part which is how do we make this so cheap over time that it's a no-brainer and that's the research the the the cryptography engineering all the the nitty-gritty detailed stuff that go into building L gr and other ZK companies um and it's twof full find the people who need it today make sure that they can use it and then try to make it cheaper and cheaper and cheaper for the rest of us we we talk a lot about like the modular stack and the topography right now for that is like execution

settlement and then this security piece which often times refers to da and consensus and you're talking about making things more secure which I think is always very very very important when we're securing billions if not trillions of values sometime soon so how does the the consensus in the da are you guys arriving at consensus by creating these proofs um how how do we relate kind of like these more maybe traditional aspects of security in the modular stack with the enhanced security of co- ZK processing and distributed ZK proofs that's an amazing question this is why I love being on here um the the

concept of it that I think is is is one of the most important things to kind of think through is the difference between the consensus that you need for the function of your rollup or your chain and then the extrinsic computation that you want to run on top of or feed data into your chain and so I would look at the example of ethereum and chain link right ethereum if you deploy your dap on ethereum and all your dap is doing is it's a univ V2 pool you have no external dependencies you might not need ZK and you might not need ZK for your core application function you can build simple things on chain that don't need ZK and then there is a a tier of applications that have these extrinsic dependencies they say I want you to give

me the price of eth I want the volatility of this asset on ethereum between two intervals I want someone to feed me user activity so I can decide if they get rewards that's the stuff that has a dependency on additional and extrinsic computation that's not enforced by consensus that's enforced by someone else coming and saying this is my computation over the chains data that's the stuff that ZK most easily solves and most readily solves it is how do I take that tier of things where someone feeds something in someone computes over the data and feed something in and how do I make that more secure by putting it on chain exactly by putting it on chain or by putting a proof of it on

chain okay and right now there are there are service providers like oracles that are relatively again not trying to take shots but like different design choices right so there's there's design choices where um you even look at the rollup landscape and you have data that's being put further away from the L1 in order to make it more cost effective at the at the sacrifice of security they they do that for transaction to lower transaction fees and then we have the same thing with data providers like you mentioned chain link they provide data from external sources that is not data that's inherently on chain so the core

principle of lrange again making like strides in the verifiability of this data because we're I think we converge where verifiability is one of the core Innovations Beyond on like just a database lrange takes things that are currently offchain and not verifiable and puts that data on chain so that it is verifiable therefore more secure yeah what what I think the best way to think of the co-processor is is verifiability of additional computation the computation you don't want to do in your contract it's too heavy that's too intensive we lift you can lift it out you can do it off train and you can prove it back on train no need to trust

an oracle no need to trust you know an indexer or your friend who's going to build something that's going to feed the computation back on all you have to do is verify the proof I think the the the core of this is an extent extensible verifiability of computation we talk about paralyzation now of of blockchains you know some of the great work that monad is doing for example but what if you have a normal blockchain it's sequential that's not paralyzable you still want to do some things that are asynchronous you want to run some computations that don't run within the single thread of the execution of all these transactions that are intensive that would block things right the same way you would in other programs this is a reason why your database call in the

front end is asynchronous for your for your your web 2 app for example that's the type of stuff that you want to start building on chain or the developers that we we interact with start wanting to build on chain and that's the type of stuff that you can do with this yeah sure and and so if we can if we can integrate this into new basically modular chains being launched on R providers or other you know we get to a world where it's somewhat permissionless or very permissionless as you say kind of moving through different interations like is it something that we can see be uh a part of like you go to um conduit or gelato and you're looking to deploy a rollup and and there's an option for

select your co-process or select your proving system and and do do you see that level of integration being possible yes we believe that's the future we believe that you're going to oneclick spin up and you're going to click a bunch of boxes and those boxes will say everything from your da layer to your execution environment to your interop protocol to your sequencer to your co- processor and as you start going through those you start picking the things that are best aligned with what you buil the same way would in web 2 if you're spinning up your your back end or your server and You' be able to configure your one your deployments you'll be able to do the exact same thing but with your blockchain and your modul upon so it may a spicy question why did

ether fine alt layer choose you like what makes you guys so special maybe you can shill a bit Yeah I will I will shill all day um you know I I think there's a few things that we feel very proud of our team about the first is that we have a very deep R&D fundamental and research fundamental as a team we're we're very close in the AC to the academic Community we have a lot of our teams actively publishing research and Publishing research and conferences and is pursuing the publication of New pieces and conferences and so we don't just grab off-the-shelf Tech and say hey can I sell this to somebody what we are what our team fundamentally does is try to push the state-of-the-art to move the space forward and to build things that are an order of magnitude or several

orders of magnitude faster at what they do than was possible before and I think that's something that really resonates with a lot of our partners because it gives the capacity to make sure that you're working with a group who prioritizes the right things and secondly we've been really you know we've tried to be very aggressive on prioritizing the fundamentals from a engineering and deployment standpoint that we think matter and that is permissionless that is eased ease of use and that is that is compatibility with architectures that we believe in and we believe very heavily in the reaking in the ABS space and we believe very heavily in the modular space and that gives us the opportunity to work with

some of the best and the brightest teams like alt lir and ethery that we think are also pushing a state-of-the-art in those capacities um and it just it has been a very fortuitous opportun a very fortuitous situation that we we've we've made those decisions because now there's a whole bunch of teams that I think are rising very quickly in each of those respective verticals that we can now work with and that we enjoy working with gotcha good show um now kind of when it comes to ethery and ALT layer are they connected to the same network of of lrange provs in through in code processors like are they like interoperable in some capacity with like

like like can an e can an ALT layer restake roll up use ether 5 because of lrange like how does those how does lrange facility convers like collaboration yeah yeah so we don't actually facilitate maybe maybe I should chill a little harder but we don't actually facilitate conversation between the two like an Inon protocol that would be cool maybe we should think about that but we don't currently what we do is we build a network that gets more efficient the more people use it which means effectively you have computation that's likely overlapping which what ethery restake rollup users will need and what ethery will need um after alt layer restake robs what ethery

will need and as each of those groups independently computes over data there are these things you can think of them as partial proofs that are created within within our our proving architecture that makes it more efficient for everyone else who's the next person to use it to to use our approving Network and our and to use our proving architecture and that means it's highly performant and highly efficient to work with lrange as more people use lrange and that's something that we're very excited about so while there might not be a direct interoperability there's a shared efficiency Improvement that everybody who opts into using our type of ZK co-processing is able to benefit from it's a rising tide if you will I've got a a short first question

and then a longer second question first question is that when ZK proving starts to become more embedded into these rollups does do are we going to see that proving cost just kind of baked into the transaction fees from the end user perspective oh I love that I think it will yeah I think that would be the right future I think you'll have either an emission schedule from a from a a protocol's token that's used to underwrite proving on that Network for the users or you'll have inbig transaction fees that'll be used to um to pay for that and I think as you start amortising those costs in interesting ways you get to a future or provings common place where a user might not even

know they're using a co-processor they might just think they're calling a pre-compile or they might just call some contract and chain that they've been you know they've called for the last six years because that's how they build their applications right whenever I want to query something I call this contract um and then what they're left with is is a much more fluid developer experience right the same way that when we use pre-compiled on slity engineering most people don't think like hey you know have I actually inspected the source code this pre-compile do I understand how the catch Haack pre-compile works right do I understand how these different components of solidity engineering work they just deploy their application Vibe they know how it works and they build cool stuff cool okay and then second question is

we've got this proof of Supply proof supply chain uh Twitter space coming up this Thursday this will be out afterwards but I'm extending the invitation to you now if you'd like to join and and also awesome and and like is in your perspective the proof supply chain from the moment that like someone needs to generate one like could you just kind of take us through that that supply chain life that proof life cycle yeah that's a great question so I I think that there are or I can speak to lran just developer flow and then I can speak more broadly to how I see the ecosystem so lr's developer flow a user defines onchain a data schema for their

contract they say I care about these storage slots these transactions and these receipts and then every single block what is thought what can be thought of as a verifiable database is just built from all of this data and whenever they want they emit an event from their contract and they quy it they say select all users who own a pudgy that has gray the gray skin property between block X and X Plus K and they get back the result of that query maybe they want to iterate through that query like they would in SQL So What it lets you do is Define your database qu your dat database verify the result and that database is formed directly from Smart contract state so we can think about that as kind of a very natural we think extension of what developer experiences on chain for

asynchronous calls now proof supply chain more broadly I think there's a few levels I think there is the proving system there is where that proving system is deployed and how that proof is served and then where that proof is verified and I think those are the three components proving system uh what could be thought of as as where the proving is done and then where the verification is done and different teams focus in different areas so we don't build general purpose proving right there are teams that do and I think there's a great business for pro building general purpose proving but that's very removed from what we as a business currently focus on or weever focus on we focus on proving the exact things that our proving system does but there's you know the G lots of the world for example that

are general purpose proving networks and that are incredibly dissimilar from us um then you have within the proof supply chain the proof verification layers you have the nebras of the world a team that we think very highly of and will likely work with at some point um where what you want to do with with with these proof verification layers is aggregate a bunch of different proofs together to make the single verification cheaper um and then you have the proving systems you have the teams like Risk zero who say my business is going to be building a general purpose library to do proven um and that's another component and

you okay you mentioned like you you're G to work with like some of those you're not going to work with others like the the pieces that like are important to pull out of like Risk zero pull out of ne ne neeva or nebula and and like why why why why are why are those like uh like good uh like value additive pieces of infrastructure to the ZK proving uh landscape and that that whole supply chain why are those additive um and some of these more general purpose ones are more like uh dissimilar from the the uh the landscape that that or the vision

that you guys have at LR yeah so for the type of proving we do what we care about is we build own proof constructions and then we prove our own computation in a highly hyperparallel fashion that's what lrange does as a business and so the people we work with from a proof supply chain standpoint have complimentary areas and so we generate proofs but we don't verify proofs someone else has to verify that it can be verified in ethereum or it can be verified in somewhere that takes a bunch of proofs and rolls them up into a the and so that's just what I was saying about kind of some of these proof aggregation players being very interesting to us um there are other areas like people who build proving

systems people who build proving networks that I think are very useful and very valuable pieces of technology that will that will exist at the same time as us but just aren't things that we integrate with despite the fact that we like your themes because they just aren't aren't part of what we do we build our own proving system and we build our own way to kind of compose and create those proofs so quick side note which is that I think Satoshi would really love this like I don't obviously don't know him but like he's told don't trusty thing right like and you don't need to clown me for that we none of us know Satoshi so so the whole don't trust me that was not me Andy and Robbie are Satoshi you

heard it here um so so like don't trust verify means that like someone can create the proof but then like all of us can verify it and I think that that gets back to like you know all of us running a Bitcoin node all of us running whether it's a light client or a full node like all of us verifying the state of the chain and and verifying the proofs that that make these State transitions um so that that is a as a side note um I want to drill down into like you mentioned that like you guys are doing the proof construction but you're not doing the proving systems so could you just kind of like again like separate that for us yeah yeah so so we we we we do build proofing system sorry

we we don't do proof verification okay okay so that's passed on to like maybe the end user or maybe the chain to do the verification the chain usually yeah okay isn't proof verification still very tough right now like cons verification is like the current status quo right it is it is that is completely correct the consensus verification is the current status quo on ethereum or on a modular rollup but you know there there's teams who are doing cool stuff to build architectures that let you verify proofs um and those are obviously things that we find very interesting because that drops the cost for for some of our some of our customers yeah that's like the end game right it is proof verification or state

ver or state verification is that what it's called proof verification I think proof that's like that's like the end game that's like the single slot finality one proof to rule them all everything's connected and verifiable and ZK magic people are excited a rollup of rollups of rollups of proofs nice that sounds as we kind of wrap up what parts of the stack are going to be uh eliminated because of ZK proofs like what types of technologies that are prominent today are just gonna just fall short in the a future of ZK I think we'll see a hyp specialization and I think we'll see things that don't hyp specialize fall

apart so you're not going to see as many general purpose Oracle networks that serve you offchain data do random computation on data you won't find random indexing solutions that have the ability to write the data on chain with a really insecure guarantee over that data you won't see a lot of these economic based um uh like side networks that try to compute over over like the economic C processors that have existed and have called themselves oracles you'll see a lot of these go away what you'll likely see is a specialization compute will be done in ZK or will be done optimistically in some capacities but with a very transparent set of assumptions where the slashing on the

optimistic guarantee will likely be done with ZK you'll see offchain data providers whose entire business is writing offchain data onchain where there's a slashing guarantee over that but they won't be Computing on that data they'll just be anchoring some commitment um and there's some teams doing cool stuff with that as well but we'll see a specialization if you want compute that compute will be ZK if you want offchain data that offchain data will be likely from some trusted party or some economic based party who'll then write it on chain there's a lot of mechanisms there that I think become very very specialized some of these like loose conglomerate companies maybe like chain link will start losing market share and we'll start losing market

share fast as better technology specializes to beat them in vertical and what is the limitation right now for proof verification my understanding was always that proof construction is very very hard but because proof is very succinct it's easier to verify so what is what's holding us back in the verification right now so verification and modular context is not that much of a bottleneck if I deploy a new rollup with a cheap gas cost I can verify a ton of proofs like there's no bottleneck for a high TPS rollup to verify a billion proofs billion Maybe you know hundreds of thousands of proofs more than it likely needs to the applications building on it

where there's limitations on proof verification is L1 ether where it's expensive gas is expensive and it costs $100 of proof $200 of proof that's where you see bots that's where you that's where you need proof aggregation yeah but um in the modular context you don't necessarily need proof aggregation I I would say you in fact the biggest limitation we think that there is in ZK right now is not the the proving or not the aggregation it's the developer experience it is is there a developer who is going to be using these interesting Primitives and there's a new tier of developer that we feel like we start meeting at conferences nowadays or at hackathons who was kind of brought up

in crypto having had ZK as something that they've known they weren't brought up in crypto in 2017 2018 where economic guarantees and and Oracle networks and only solidity they were brought up in 200 22 when people were talking about ZK and this is the tier of new developer who will build applications day one that fake in these new these New Primitives and the cor lary of that is when they build those applications they'll start needing infrastructure around them that enables them they'll need the fast provs they'll need the decentralized proving and they'll need the verification networks or aggregation networks well inshah to that new tier of developers yeah I love

it be drawing Merkel proofs by hand like thank you Ismail for um coming on today and discussing ZK co-processing for the modu future I think that's something that uh We've now opened up to significantly so I'm I'm looking forward to seeing this more and more we are too we're uh we're very excited by the reception that we've been seeing in in the modular community and I think I think a lot of the teams that we've met and you guys as well are some of the most Forward Thinking people in crypto right now appreciate that congrats on Magic congrats on the recent Partnerships and thanks for coming on thank you so much