DeFi by Design EP#98: ZK Scalability, Nested Rollups, and Blockchain Architecture w Langrange

Transcript

foreign [Music] by Design where we talk all things blockchain and cryptocurrency while striving to educate Empower and generate [Music] what's going on guys welcome back to the D5 by Design podcast this is episode 98. we are here with Ismail uh we're gonna be talking about LaGrange Labs LaGrange um we're gonna hear more about it I believe it's a mathematical term um I remember hearing about it uh throughout classes so we're gonna we're gonna talk more about that what it what it is doing in the ethereum space

um and uh Ismail I mean you know it's good to have you on could you introduce yourself and yeah uh tell us what you do with LaGrange thank you Rob I'm excited to be on and you're correct LaGrange is a is a Frenchman competition and he's he's responsible for a number of the a number of the the constructions that are highly important for zero knowledge proof systems so um so you know great to meet everyone here um I'm the founder of LaGrange Labs we build types of cross-training operability State and storage that is more performant than messaging protocols and bridges for certain D5 applications

the way we like to describe it is that if you deploy n instances of a defy app across n different chains there are implicit relationships that exist some of which are one-to-one like what messaging protocols and bridges handle and some of those are more complicated and depend on more more Dynamic data relationships and those are some of the things that we've we built and and the argue The Arc actually you mentioned is ZK yet the user experience I I Envision when you say n app instances Over N chains sounds inherently cross-chain so yes could you explain the the relationship between the ZK architecture um and and still the compatibility among

shanes that's a very good question you know the way we like to think about cross-chain interoperability is as a fundamentally modular proct there are in our view three principal components the first is State validity so how do you prove that a given block header is in fact valid for a given chain in traditional bridging this is done through intermediary nodes or k of n assumptions over some protocol responsible for a testing the state there is the second component which is transport which is what actually takes that Blockhead or that proof or that attestation estate and writes it somewhere else and the third component is what we think of as computation in other words what can you prove within this block header and what type of data

schema manipulations can you do to the underlying format of the message and when we think of cross chain we think of these three components as in the final State very independent wherein applications can potentially grab different computation layers different transport layers and different validity layers in order to properly build an application that can handle whatever the application specific requirements they have for their multi-chain dap and so what we focus on is twofold we focus on building novel computational models to prove expressive computation on top of blockheaders and this is one of our products that we refer to as ZK

big data and ZK mapreduce so how can you take a given block header and prove these arbitrarily large for example pricing relationships on it um moving average the price t-wops V waps Etc and the second component of what we build is what we think of as state committees or state proofs so how do we allow for certain chains applications to prove or consume proofs of the state of that chain without requiring insecure intermediary attestations so entirely zero knowledge there's a lot to impact there um okay when you when you talk about block headers and information in blocks before

we get to what you guys do with a block and could you kind of flesh out like the the components of of a block with respect to how you then use this block that's a very good question yeah so within a block header you can think of it as having a number of properties metadata associated with that block as well as multiple trees that can be used to determine the state of various aspects of the chain at that point in time or that Block Hunt that includes the state tree which encodes all contract States in that chain and all account state in that chain the receipt tree which is all execution traces and the transaction

tree which is all the transactions including that block both all three of those are our particular tries and encode different aspects of the chain with respect to that certain blockhead so when we think of computation that you can run on top of a block header it's how do you leverage these existing data structures and zero knowledge computation on top of them to be able to derive relevant properties about the chain at that block height from that block header for example all block headers contain contract state which means if you want to determine the price of unib3 the spot price for example you would need to run a Markle inclusion proof on two Leafs of the tree at that height to determine let's say both volumes of Assets in that pool if

you for example now want to do a moving average of that price you would need to do multiple blocks in a proof which should be done on multiple block headers or it could be done on a single block header where you prove what the the historical block headers were with respect to the current block header since they're all linked and this allows you to have these yep can these block headers synchronize across chains you have a block header on an Avalanche can you sync this block header in as in a in one Merkle tree with a block header from arbitrum so someone could relay them over but you know I I the block headers uh is a inherent structure to Every Chain um and as such they're not they're not

intrinsically linked and that's where I think looking at it from a meta perspective that's where cross chain really comes in it is we have all these disparate data structures which we can almost think of as independent databases where every block is a version of that database on top of this we have one giant asynchronously updated data Lake what with all this information can be built right now we think of cross chain as this one-to-one relay we take the current state of one chain and write that to the next chain but as we look at it from a broad perspective and we see all these settlement layers and all these updates these inherent data structures what are the things you can build on top of that aggregate proofs of State yeah you thought about this question much more than I have how do you at LaGrange address this question

so we build computational tooling that allows you to efficiently prove properties across all of these heterogeneously updating independent settlement layers independent block layers where you could have computation that you can verify that runs on top of State across a series of different chains concurrently um and the question of what you can build on that we're on opinion on what you should build but there's certain use cases that we think make a lot of sense you know I think most D5 apps that we've spoken with have issues and concerns over how they're pricing collateral options protocols lending protocols derivatives Protocols are all dependent on off-chain price

feeds in order to price assets and these off-train price feeds generally don't account for liquidity of an asset pair they don't account for how much lipids you get at the point of liquidation and they don't account for where that liquidity is located so if you're on arbitrum and someone gives you 10 million dollars of rap algorithm collateral there's a question of what you could actually liquidate that for in the event of liquidation event and so this is why a lot of protocols struggle to support long tail collateral as you now start being able to unpack and unfurl some of these more complicated data relationships you can remove the dependence on these static off-chain price feeds and instead price collateral natively based on how much you could actually liquidate for realistically on the settlement space on the execution space where your

application is deployed okay in terms of the user experience from a user perspective this looks like uh lending on on Avalanche um I can I can collateralize my chicken nfts on on Avalanche in an nft lending protocol and I can take out a borrowed position to buy things on arbitrum natively make that borrow on arbitrum and then when my uh so I would I would then need to repay my loan or get liquidated in which uh I would need to know how there would be a question of

how much to uh liquidate my my nft for on on Avalanche right so um the liquidity circumstances on Avalanche would need to be they would need to tell arbitrum when to liquidate my position is this you see that that I love this this is what I love about this type of Technology because that's entirely different than the use case flow that I was thinking but that's also a completely valid one that's actually a very good use case when you want to lock an asset on one chain and lend against on a different chain without requiring it to move or be wrapped and that's another very very interesting use case um the example I was saying was just very simple where you have one asset on arbitrum and you want to lend that on

arbitrum for example and the protocol wants to know how much it sells for on just arbitrol without worrying about any other trans price but the instance when you're talking about trying to price something cross-chain is another one with this type of functionality is very important especially when you consider price to be a factor of multiple dexes concurrently to say arbitrum needs awareness not just of you know what Trader Joe is on Avalanche but it'll need what Sushi is an avalanche I don't I don't know if univ3 has a deployment in avalanche but if it does at least know that too you don't need to know where to look away the two it needs to know when to liquidate it needs to know all these properties associated with that with that um state of the chain and that is that is where you know some

of the the more Dynamic computation more Dynamic cross-gen relationships that aren't necessarily handled by Bridges and mastering protocols become very relevant okay so you were describing how LaGrange uh interacts with the state of the chain and uh it's it's block headers yeah um that I interrupted you and asked asked a question so so could you now that we know like what what a blockheader uh yeah is could you describe what LaGrange does um with these these block headers and these uh and and how it yeah could you could you kind of explain

the the block headers role in the state of the chain yeah so every new block has a new block header and when we think about block headers in the context of cross chain we really need to think about kind of The Logical flow of what one does with a block header so if you have two chains ethereum and Avalanche let's say and you want to use the state of ethereum on Avalanche Avalanche can't make an external call to ethereum and figure anything out so Avalanche needs to be able to verify things just natively within its execution environment so what does need to verify that some random group of bytes that correspond to a block header are in fact the correct block header at a certain high enough theorem right so

not just a block here I made up it's not just a block header you made up but this is in fact the the correct finalized canonical block heterotidext next it needs to verify some computation that's done on top of that block header unless it runs all that computation natively on chain which is going to be expensive you would ideally want to run that as your own alt context to verify it succinctly so you need to prove almost two properties in this case what is the block header and what am I doing on top of the block header and so LaGrange has a few different mechanisms to handle each of those components for chains that have a block header structure or finality of consensus that's provable right where you can generate a proof for the consensus of

that chain we we generally use that because there's no reason to have anything else that we can just prove what the block header is based out of chain executes for chains that don't for example think of an optimistic roll up where finality is defined by Game Theory and not by a provable mechanism over a short period of time then we have what we call State committees which leverage restaked or rehypothecated collateral to execute verifiable attestations to state that we can generate recursive proofs on and once you now kind of take it for granted that you have that block header that you can prove is valid you can run computation on that and the computation that we most natively support is distributed documentation so highly efficient Big Data scale computation

that can be run on top of these on-chain State structures right which is anything you could run in rdd distributed SQL mapreduce Etc you can now run in the zero null of context on top of our ZK Big Data frame okay and this allows you the pricing and all these things we talked about before got it okay and yeah they're they're is some technical components that are they they sound like um they're very they're very abstract but they're very Advanced like you guys have spent a lot of time thinking about these block

structures and their uh their current like mechanisms right which are all mostly Game Theory secured like proof of proof of stake secures the um ethereum blockchain obviously yeah and then and then the idea there is that the uh validators are proving the validity of the chain and each time they they make that proof they uh post a new State uh of the chain so then there's all the ZK ZK kind of computation on top of the game theoretically secure chain

um what's your opinion on on ZK at the base layer do you have yeah you know do you I could kind of anticipate but I'm curious what what you think of uh ZK sank or the other the other ZK native layer ones yeah we think we think very highly of any chain that uses zero knowledge to prove its state transitions as a role of one with you we also think very highly of optimistic Roll-Ups I think they both have use cases that they're very well optimized for and very distinct advantages and disadvantages I think that being able to prove an arbitrary State transition um

on a evm for example as a ZK sync with you or a stark net does um allows them to leverage efficiently the existing collateral that underlies ethereum potensis in order to secure themselves and I think this creates a very interesting structures where you can Nest these roll ups on top of each other and create increasingly increasing increasing amounts of scalability and ideally Atomic transactions between each of these layers um that have really only an increase in settlement time rather than an increase in for example um a draw sorry rather than the drop in security to try to increase block space and throughput right where you can you can keep nesting roles on top of each other and all you

do is increase computational cost of having to compute all these these State Transitions and all you do is increase the time difference but you don't decrease security and that's I think a very interesting property of nested ZK Roll-Ups so we're very very big fan of those I'm a big fan of fto we're used to got it okay and and LaGrange is not at the at the layer one level it is the main application to create Merkle trees of the various chain States yeah so so we're not a layer one so our goal is to help CrossFit interoperability be as

functional and expressive as possible so the question is what can you do between chains and that's the question that we're answering and the technology that we use to answer that is entirely zero knowledge proof based so we're not on the L1 we're not um uh like a mastering protocol like a layer zero and axler that we have we do work with some of these protocols to help to help with security and to help with expressivity of computation um we're very much you can think of us as tooling for building dapps that are more functional and are more Dynamic right so if you think about a defy app yeah pardon is it fair to add scalability into those other ways you describe a more useful

overall app yeah I think scalability is very important and the way we think of it is that if you are building adapt today you might just be able to build it with very close simple State transitions of one chain but it's very likely you're going to need awareness of two things you're going to need awareness of other applications on the Chain you're on potentially awareness of the historical state of those applications and you're going through the awareness of the present and historical state of Cross Street applications as a developer of a defy app right lending protocol apps need this options apps needs this derivatives apps need this yield ads need this winter routing asset allocations most modern DFI apps need awareness of external applications Beyond themselves

what we do is we build tooling that makes that more efficient and in the traditional Financial world this is common like there's multiple exchanges and there is interoperability of price feeds from from multiple sources exactly does this occur when and you may not know the traditional Financial uh format of how they share these data feeds but on the on the blockchain no matter what traditional Finance comes up with it it seems more efficient because it's almost like we're all interacting with this uh interoperable database whereas I

I doubt um traditional financial institutions are sharing databases with one another but it's a it's not as um it's not as as a cohesive um because they're not sharing that information so two-part question how does um how does latency work when when you're sharing um data from uh chain to chain and how does this this relate to a traditional Financial architecture

um database or otherwise where they where they share price feeds yeah so that's a that's a good question right because you still need to share price feeds in traditional Finance to your point because if you're if you're a lending company and you allow someone to post a stock as collateral to take a loan on that you're going to need to understand the price of that stock spot price and whatever price you can liquidate that for in the event that someone's margin and even if someone gets margin called so I think that's that's a very important aspect of trying to build any system right where if you had to liquidate a stock to a certain exchange or a certain order book in the event that someone was margin called you would need to know the price that you can

liquidate that for to understand when to make a margin call and when you think of these kind of atomic liquidations on chain in these over collateralized lending apps there is really no ability for them to understand a priority to a liquidation how much they could liquidate that for they have to rely on a secondary price feed that would feed questionably accurate data back in derived from opaque sources that they're hoping that they can liquidate for that amount right like a chain link price feed does not accurately say how much you could liquidate E4 on a ZK sync L3 it's a uniform single price of what they believe ethereum trades for everywhere

there's no context in the location for that price information price discovery so that creates some somewhat problematic Dynamics when you think about building these defy apps that have to be anti-fragile and able to run atomically without user intervention and so when we look at web 2 movement information it's very simple to transact between two applications we're just call an API and they return new data in some predefined format in web3 it's a lot more complicated because these chains can't call external so you're generally constrained exactly exactly generally constrained by data you can access and so with this type of functionality

allows is for people to build more Dynamic more expressive more anti-fragile more secure defy apps by really being able to leverage these inherent data lakes that these applications sit on top of okay so the current architecture of uh interoperability across chains puts the the uh State channels of of one chain into this cloud like this very web 2 term but cloud-like structure above the chain and then to access data from another chain this other you know chain B over here would have to pull that data in from that cloud like data sharing structure whereas this GK technology could share State channels directly to

the chain without uh uh intermediary albeit maybe decentralized yeah because I think that's a very good framing I think I think when you think of how we would feed multi-chain data to a chain right now it's going to be between Oracle right where you know you run a bunch of nodes or I run a bunch of nodes and we see data back onto one of the chains you can't have a chain that or an application on chain that dictates for itself what data it wants to consume from what block height from what formula for how they want to derive these properties and run it themselves right so you lose the agency as an application developer to really be able to customize how you would like to consume multi-chain data and if you were to

Consumer client for an off-chain price feed you lose security right because you're you're inherently building a trustless application with a heavy trust assumption on your data source um and that's a limitation that we have today yeah and chain link always has these these uh honestly it's about time you know that like there's a project that kind of calls out not not that you're saying doing it specifically but your product calls out the inherent centralization weaknesses of Oracle systems in general like chain link specifically who's always kind of been called as you know a relatively centralized uh service

um you know in in blockchains in general decentralization is is normally an advantage and and this is decentralizing Oracle Services as a as a product in you know in in general is that is that a fair assessment yeah I I think I think that's a very fair assessment when we think of oracles you always have the need to feed off-chain data that's inherently off-chain on chain right like if I want to determine how much a square foot of real estate in SoHo is priced at to issue some on-chain equivalent to that um we always need an off-chain feed but for for data feeds that don't rely on

off-chain data the use of an off chain set of nodes to feed that data on chain today is a limitation in infrastructure and architecture because we don't have these types of computation to allow you to do that right now where you can't prove you know these end-to-one relationships across a series of other chains and a series of historical blocks in one proof somewhere so you have to rely on the off-chain actor to go aggregate that data for you and tell you the result and this is why all of those Oracle systems are game theoretically secured because they they don't okay they don't have the the compatibility uh chain to chain

um to secure them uh based on a proof exactly proving the validity of State channels on one chain um so that the other change shares that proof exactly and then as you kind of think of the derivative of this and you start going to level deeper one of the advantages you have is not just the security but the expressivity because now that you don't have to rely on some off-chin actor to feed you data every so often you can build applications that consume data in novel and personalized ways of that application the same way they would if they're building data infrastructure in web 2.

and so you increase security and by extension you then increase what you can build yeah yep security as well as as well as scalability which is is yeah what we I are at least I'm on of the understanding this is preventing a lot of um applications at scale but when we think of web 2 applications it's the user experience feel when you use it the smoothness of it but it's also the the scale at which these applications can operate and we heard we had a podcast with uh the founder of connects yeah cross train messaging protocol um the other day and he he mentions these these um web 2 Monopoly monopolies which he

believes are going to be decentralized by web applications but web3 is not at scale where it could support these decentralized applications um exactly and and we've talked about security for most of this conversation but um there is also a benefit of throughput and scalability um which could bring about these web 2 style applications at scale exactly exactly and you know the way the one of the ways we like to think about it is when we think of building web3 Stacks you're trying to build things on top of each other that leverage the same trust assumptions as the underlying layer that they're built on right because if you

start adding weak points into the stack it's very hard to build applications that have the the requisite security required to really function in the centralized world where ideally if you have your your base layer of ethereum you want all of the scalability solutions that settle on ethereum to leverage security of ethereum you want all the middleware that those applications to consume to leverage the security of ethereum as well or to be able to be you know zero knowledge and leverage the security of wherever they set it and so this is how we sort of think about scaling effectively and scaling securely and making sure that as you build these applications on top of each other you're able to build things that stay as anti-fragile as the simple applications right because the reason we

still use dexes instead of you know the order books is I would argue not because you can't build a crypto order book that is quasi-on chain it's because if you're going to rely on something that's on chain you want to inherit the security that's from the chain and if you want to rely on an off-chain order book you're going to rely on an off-chan order book as you think about building these these more Dynamic applications on chain like building a central order book on chain it has to leverage the underlying security of the chain for there to be a case for settling on chain and these chains have different security models like if you were to build this between Bitcoin and ethereum a central order book How would how would you uh reconcile proof of work and proof of stake

exactly I I I I don't know how you would actually even build a central one order book between those two I'd imagine you'd want some kind of drive chain or some of the the new Bitcoin constructions that that I am not an expert on but okay okay well I think those who are still with us are relatively technical so I I'm curious about lagrange's influence on on ZK um yeah proof constructions um yeah so we have a number of proprietary um uh constructions that are very very performant for our use cases and the use cases that we are optimized for is very much this distributed computation on top of on chain State

data you know I think you're maybe familiar with some of the the sequential execution models for zkvms right that's kind of the risk zero the nil Foundation um as well as the zkvm work what we focus on is is distributed um computation so things like spark Hadoop rdd distributed SQL and some of these more paralyzable execution models that can now be run on top of large on-chain data sets and as you're on all context which we think is very viable when we start talking about these these highly fragmented on-chain State layers and being able to synthesize all this data analysis and alphabet could you talk a little bit about how

important SQL is to the um non-blockchain applications now um yeah um so I would say distributed computation broadly is the dominant Paradigm in web 2 for processing larger data sets and there are different ways that can be run and distributed SQL is one of those that that's very viable as well as things like mapreduce and or rdb which are ways to process large amounts of data in parallel execution formats that can scale with log and what that enables is is for you to run these very large computational jobs

that in parallel and highly efficient instead of sequential which would then scale the amount of data increases right because if you had to run a giant Loop for example right if you're familiar with like loops and computation computer science where you're just running through everything one by one as you grow the amount of data that Loop gets longer and longer and longer and longer and longer to the point where it takes forever to run you don't really want to run it anymore well the question is what if instead of running at all independent individually you ran each Loop instance one by one on a different machine and then merged them all together you could in theory run that as a function of the time it takes to run one of them independently and then the top because you're doing them all in parallel the time it takes the merch and

so you can run these very large computational jobs and SQL is one of the examples of what you can do with this very efficiently and you can do very expressive computational scale and this is very common in web 2 and very common in the Big Data Stacks to leverage by most large web 2 companies right you know Facebook Google Amazon all have huge data likes and huge data engineering teams what we do is we allow this type of analysis to be run from adapt trustlessly on multi-chain fragments to take data and and this is um be before it translates to web3 these web two companies are still using AWS Microsoft Azure these Cloud compute services to provide parallel computation

yeah they do they run that you can you can generally spin up parallel computation jobs in all of this but in web 3 if you think about it right let's say you're adapt and you want to price something based on moving averages of multi-chain deck States so you want to determine where to allocate assets to from a yield aggregator by running a series of analyzes on lending app performance across a few different chains and then you want your deck you're going to adapt to be able to independently decision where to deploy assets to based on lending rates that are across three different chains in that example you would need to be able to process all of that data rapidly so your lending app to analyze it incision or your yield ad can analyze it in the decision

in that case you need efficient computation and you need to be trustless in a zero knowledge context and that's what you can do with this type of computational model yeah and it benefits I I think of it as these kind of four steps that you would need to go from chain to off chain Oracle to then computation of the data on in this Oracle database and that's each step you know is is um uh it's just it's just you know yeah further away from the inherent security practices and the uh latency increases as you take more steps away from your

ultimate exactly destination which would be you know taking it right now web 2 uh goes to these clouds the cloud pulls them down so it's like one-off um from each of their internal uh data computation engines but the the security practices if you just go directly as well as the scalability uh the security benefits and the scalability benefits are are greatly increased from from a direct communication um between those chains or the or those web 2 applications or those financial institutions um

um or the Integrity of that data um and the scalability of that data and I'm I I see like the the inherent Security benefits you know the uh the scalability benefits um and I really I really enjoyed the idea of scalability benefits I think security is like so important but it's boring sorry yeah but like scalability is so exciting because we can think about all the possibilities of what we can do with um more technology more you know yeah just more real estate you know to to kind of think about these applications that are now possible with this this Innovation um and

you combine that with kind of the idea of the nested Roll-Ups it doesn't just have to be ZK you know we can we can increase scalability by nesting these Roll-Ups uh Nest uh uh arbitrum and an optimism you know ethereum sharding could just be a series of nested uh shards so the opportunities uh like to innovate further in scalability are greatly Unleashed with a uh direct channel to share uh the state of the of chains um uh it was this a was was this a LaGrange theorem like which which theorem is it that kind of like you know opened this

whole uh this whole field up so so you know I think the way we see settlement layers is that in execution layers is that we're we're increasing the amount of blocked base but we're not increasing the amount of tools that allow you to interrupt between block space in other words you have you're gonna have thousands of apps Roll-Ups um likely the next few years with all these these new app roles and service providers that are launching you're going to have l3s and starknet l3s on on um uh on you're going to have orbit rollups on arbitrom you're gonna have opt stack chains you can have all of the opt stack Roll-Ups you have all these different Roll-Ups that are being created that are

all settling on um different settlement layers and all have their own independent execution States and so what you need to do is to have cross-chain models that can properly interact with all of this different state safely and when I say safely in security like I I agree with you that that in the purest form security can be very boring what I think security and scalability where they become interesting is when you think about what you can build on top of them like think about just a very simple yield aggregate like a urine or a beefy right well how does it allocate assets every so often there's a tend or a harvest function call at which point these yield aggregators rebalance allocate assets across a

series of different yield bearing strategies these function calls are called whenever someone deposits assets or whenever um there's a regular interval that passes and they're constrained by only being able to access the data that they can directly read right and now you talk about all these different applications deploying all these different chains are we going to have thousands and thousands of independent yield aggregators at some point it doesn't make sense what you need is to be able to have yield aggregators that can compare multi-chain state with the exact security mechanisms they use today to be able to now take a single chain of yield aggregator and make it capable of deploying assets multi-chain that's the kind of things that we think

this type of Technology very naturally unlocks to take a defy app and then to expand what you can do with it yeah wow this is heavy and I I expect that there's like um you know this is gonna seem so obvious to people like in the long run but then it's gonna people you know just developers are gonna have that moment like be like why didn't I think of that you know like um I think it's what what we all think of you know as like an idealistic interconnected um blockchain which is also multi-chain with like kind of a diversity built into it for uniqueness competitiveness and and

choice where you know you can still choose to operate um on one chain or another um an app chain you know actually Infinity the nft game has its own chain layer threes and fours and five ultimately are are app change depending on how how many applications are deployed on that particular chain and and the interconnectedness of all of those applications um I think was a aspiration to a lot of developers and yeah has not been executed on yet until now I think we're I think we're at the precipice of some very exciting Innovations in scalability security and cross chain functionalities

and I think to your point it's going to unlock a lot of new application layer products that were going to really be very excited about you know like I think I think blur is one that we're very excited about as well I think with what we've seen with the blur airdrop smart tokenomics and distribution strategies can really Drive interesting adoptions and as you now start thinking about being able to process large amounts of data you can start building things like blur that are not decisioning off chain but are in fact decisioning on chain like autonomous trustless airdrop mechanisms liquid blur runs and so what you can create is some very very exciting applications that were

otherwise infeasible before yeah the the classes of applications out there are so I mean they're endless right like um which is really really cool to like let your imagination run about what you could build uh with just frankly way better security way better scalability exactly there's there's all the New Primitives yeah you know spoons if you will whereas you could Fork a traditional Finance institution you know architecture all the web 2 applications that that people know and love you know to call them Forks is maybe a little bit uh you know disrespectful but like people you know like using these

applications they spend time on them build relationships on them um could could pragmatically choose an architecture of a distributed compute um and and provide a better product um arguably you know at kind of just the behind the the uh behind the scenes under the hood components that aren't really facing a user per experience and and the majority of users would not notice um except for the increased performance yeah I think that's that's very that's very exciting I think we're very close to converging to a point like that with

with the growth of ZK VMS with the growth of scalability solutions and the growth of tooling for interoperability like some of the stuff that we're building I really think that it's going to be this kind of aha unlock moment for a lot of Developers who can now build things in web 3 that they couldn't build in one three six months ago where you know six months ago you were you were constrained to very small function sizes on ethereum with very limited data access no historical data no real trustless cross-chain data static price feeds with with complicated and opaque risk assumptions associated with them and now you'll be able to access data from anywhere you'll be able to access derivatives and Analysis of data from anywhere and you'll be able to build far larger and more expressive

applications that are more secure more fault tolerant anti-fragile and are actually a lot more fun for the end user to play with yeah right yep and that that's what that's what like the majority of users are looking at is like how much fun it is um but then uh yeah that that that's great I exactly for Mass adoption and and uh all these types of applications um this has been a blast I know we're closing it on time um I'm I'm still curious which LaGrange theorems impacted the uh the construction of uh you know not necessarily LaGrange uh yeah

Innovations particular but just like um what kind of mathematical you know theories did you incorporate uh when thinking about ZK proofs yeah um so do anything else you'd like to share yeah so twofold LaGrange interpolation is a component of zero knowledge proof um and it's important a lot of things in mathematics cryptography also we loved the kind of the mental model of the LaGrange point right this this point in space between two large celestial bodies where an object sitting there rotates on its axis and instead of being drawn to either the the large massive bodies because it sits at a point of of equilibrium between the gravity of these two these two large objects and I'm not

a physicist so I might have butchered that explanation but that's roughly speaking what it is and we've loved that concept this is the garage point at the at the middle of these other two celestial bodies exactly caught up in their magnetic fields it's somewhere it's somewhere exactly instead of being drawn towards either it sits in the middle and rotates on its axis and we've loved that concept cross chain because we think of these chains as these two massive settlement layers with huge collateral on the Violator steps huge security huge communities in Cross chain and our view should fundamentally be this very light piece that's strong on towards neither that doesn't have any influence or effect from either and just sits there exists in the background and

allows for things to happen like a revolving door just chain and just kind of you're just passing through cool and and okay so that's a little garage point and anything else you'd like to you'd like to share about um your build process so far or your journey kind of up until this point we um yeah we're we're you know we're very excited about having a test net launch that's going to be this summer for our LaGrange Point uh sure sorry our LaGrange State proof uh infrastructure which we'll be integrating with some some very early development partners that we're excited to announce soon um and then we're also intending to have

a test net for our ZK our first DK Big Data product to DK mapreduce likely later this summer as well and I think I think these are going to hopefully be aha moments for a lot of D5 developers kind of seeing what they can interact with and seeing what they can build with these new paradigms you know our cryptography team has been hard at work um and uh yeah we've been we've been on the we've been pushing forward from some pretty big uh some pretty big advancements recently you're relatively wrong it pretty quickly talk to everybody on the LaGrange team cheers guys yes it really excited to see um the product of uh the research and the thought you guys have put into this

um where can people find you you know if uh listeners want to reach out maybe they work with a project that that are interested in integrating um yeah how could they contact you um so our website is uh lagrange.dev um and our Twitter is all is LaGrange Dev one word we're at LaGrange that have one word um you can contact me we probably easiest on Twitter um at Ismail underscore H underscore r or you can email me which you know I probably shouldn't say my email but it's Ismail lebron.dev it probably wouldn't be very hard for anyone to guess cool awesome well uh it was a pleasure having you on there's one last question um that we ask each each podcast guest

um if you um the analogy we use are hypothetical is if you're stuck in an elevator which is you know let's say you have an elevator pitch two minutes to explain to anyone uh you could explain you know anyone uh Dead or Alive um LaGrange what you guys are building and you know zk's technology and uh you know who who would you choose and why I would ideally talk to web 2 Data infrastructure and data engineering developers and I would explain to them the types of dapps that they could now build in web3 and how they leverage very similar computational models it can be

built very similar computational models to what they can build them up to I think when we unlock this larger pool of developers who are focused on some very specific aspects of the application stack we're able to build things that are that are far more robust and fault tolerant I think as the number of web3 developers can start to become this this pool of web 2 developers too we're going to be able to have some some very interesting things built that are far more secure and far more fun to play with you know I think there's a lot of great developers in the world who've been kind of turned off from web3 development because of how kind of Niche and specific a lot of the engineering paradigms are

and as we start opening up and expanding the engineering paradigms to be closer aligned with what you could build and how you could build in the web too you're going to be able to have a larger pool of people who are building applications that settle on chain without having to understand the semantics of the transmit I think a good application I think a good infrastructure developer now asks themselves how can they take this incredibly complicated Dynamic and Insider focused and Insider specific domain expertise that someone would require to hold in order to build something in web3 and how can I synthesize all this into a simple product that a developer who understands the engineering Frameworks but doesn't understand where the engineering Frameworks are being applied can now

leverage it yeah this goes out to all the massive web 2 monopolies Bezos Zuckerberg if you're listening it's Ishmael underscore h on Twitter reach out to him and um more the more the Developers for working with those companies and who are who are who are interested in starting to leverage some of the cool innovations that they've had in their application level development on Webster this type of application on the development yeah yeah you guys everyone Reach Out Ishmael on Twitter and uh it was a pleasure having you on um yeah stretch this far and wide and and share uh LaGrange with the world thank you rob

really enjoyed being on likewise Cheers Cheers