Modular March EP 4: Modular Appchain Design Choices with Cartesi

Transcript

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

modular March building the modular mindset today we have the pleasure of speaking with Felipe Argento from the cartei foundation about modular execution layers Felipe thank you for being here and welcome to modular March it's up pleasure man and I love the initiative so today I'm going to speak about uh modular execution layers and we're going to explore a little bit the the design tradeoffs around that um so the the idea is to convince you guys of two things the first one is that execution layers have a big design space right so I think it's a shame to explore modular architectures and and

nap chains and rollups without exploring uh the design space around execution environment uh luckily that that is changing recently so we have a lot of themes uh exploring that design space which makes me super excited and the other thing I want to convince you of is that uh execution layers are very much context dependent right so there's not no single uh go of execution layers it all depends on what you want to achieve and what you want to do so it depends on to so many factors that I'll go over some of them in this presentation a quick intro about myself I'm Philippi I'm I was actually the first Dev lead of the rollups

implementation of ctei now I'm a happy adviser at the cartez foundation just random information I'm Brazilian but I'm very bad at soccer and I'm also very bad at designing slideshows so this part you guys are going to be able to to notice probably and these are my socials I'm always down to chat so please reach out it's I'm on podcaster Twitter and I also hang out at the cartasi development Community Discord Channel always there answering questions and so one I was told that I need to speak very slowly this time because I'm a fast speaker so I hope I'll be able to do that throughout the presentation and please don't stop trusting me because of my

headphones I'm gonna buy new ones in Denver I hope so all right let's get into it so really quick uh brief update on the modular layer just some understanding on the modular layers I'm sure you're all watching modular March so I'm kind of preaching to the co CER here but uh this is the basic depiction of the modular stack right you have the classic execution settlement consensus and data availability and the idea is that these layers are presented are solved by different themes and different solutions and can kind of uh play le Lego on it so we can try different uh different architectures of course all

these definitions they change uh very often and we have so many new uh layers appearing uh right so have the aggregation layer coming up already have governance layer uh there's the meme layer which I I try not to underestimate because like things like like ultrasound money and 20 million Bitcoins they are memes they're super important I guess you guys are very much into the meme layer right this forms the basic culture of the the protocols which is not to be under underestimated and you'll have like convenience layers service layers and and so on but uh well I'm sure you guys already know a lot about the model stack so we'll focus on the execution layer

there is the current plan uh and the execution layer looks very simple when zooming out it's just basic basically a state transition function you have an input you have a state you get that state apply the input to it and you have an output right so it's on ethereum you have a block of full of transactions you apply a state transition you have a new state of the blockchain after processing all those transitions uh transactions sorry but also transitions it also also works so but the difficult difficult part of it is that this state transition here the execution layer depends on so many factors

factors so here we have a this is something that we use a lot in cesia uh to try to explain the power of what we're doing and it kind of shows the interplay between execution layers and data layers so in a sense we're talking about we call this the cone of innovation and we're talking about the the expansion in the design space when you combine solutions that can that have high comp computational capacity and high data availability capacity and of course this is just an intuition but uh what what is interesting here is that you have as you can see some some places are are black and those are the places in which uh you're kind of wasting of

resource right so let's take uh the the the far right bottom bottom right side of the of the graph you have here etherum L1 so we have the processing capabilities of ethereum L1 and you have a modular da layer so basically what you have is like a ton of data oh can I swear I just did so you have a ton of data uh I blame the movies I learned my English on the movies so so you have a ton of data but you have a very low computational capacity right so what what are you doing with that data you don't have any enough computational power to uh to really work on it so it's kind of like a that design space right same thing with

uh if you have app chain rollups but you're using the data capacity of ethereum so like you have this machine that is able to compute a lot but you're stuck to the block size of ethereum and you're paying ethereum prices so it's just like having a super computer of a single input not that useful but once you start to to grow both together you start to expand uh the possibilities of of use cases for the blockchain right so again this is just and intuition these are not real applications like not where they actually fit but say if you have a evm roll up with EIP 4844 maybe you have more complex dolls if you have achain rollups with e 4844 maybe you have like

some kind of decentralized social network which is impossible in the lower quadrants right because you don't have enough data or computation on it and uh I think the best place on the design space is app chain rollups or app chains plus modular da right so we can have like machine economy and and complex metaverses and so on so this is a little bit of showing the interplay between computational capacity and data availability and and therefore also showing the interplay between execution layers and and data availability layers just to double click on that so this this kind of shaded region here that showing this cone structure it effectively starts from fum L1 in this bottom left corner all the way up into

app chain roll and modu da in that top right corner and basically like the argument that we're making here is that with for computational capacity and data availability capacity the scale effectively goes from ethereum L1 all the way to like app chain rollups with modular da in terms of the amount of of compute and the amount of of data availability that these types of designs can make and and basically what you're saying and this is something that's been kind of echoed I think amongst the space that different use cases require a different design Choice when Builders who are watching this are trying to figure out which solution to kind of

launch their application on you know this is something that they can kind of consider with regards to these tradeoffs yeah that's a perfect summary actually so that's exactly it of course this as I said it's a a limited view it's more of an intuition you could add for instance uh zaxis talking about privacy which is also a big design space expansion because some applications they require privacy right but then I I didn't know how to make a 3D uh graph it would be very complicated to make so I didn't add privacy there but yeah but that's a perfect summary yeah yeah just wanted to

understand that all good perfect yeah so but it's not only about data layer and and computational capacity right so now we're trying to zoom in a little bit more into the execution layer and the execution environment themselves and uh I'm going to mention some factors that you you would uh count on like you'd think you'd have to think about if you're either designing an execution layer or choosing an execution layer to launch Your da or your smart contract right because you can be on the both like both sides of the issue I'm on the side of designing an execution layer though I hope that very soon at Denver I'll be able to Cote something for for it but yeah so I'm

just going to go over some some things to consider so first we have what kind of D are you doing right so we have some execution layers which are specific for gaming for instance but uh are you trying to to build smart contracts are you trying to to host complex deps what kind of dab are you going to optimize to because everything comes with a trade-off right so if you're optimizing for high composability then you're going to have a a lot of other problems or like things that are going to get limited because of that choice so how computational like how how much computation intensity are you planning to host uh on your on your execution layer do you want DBS that perform lots

of computations or like ethereum you just want like simple State transitions which is the case of most smart contracts right what is the preferred programming language are are users going to code in in solidity are are they going to do Cairo Russ python are they only going to use the syntax of those programming languages or are they they're going to be able to actually import uh the standard libraries and the open source code that was written beforehand right uh what are the developer resources that that developers are going to be able to leverage are they going to be able to to have introspection containerization right what kind of

tooling will be available to deps and if you look around the the design space of of execution environments you can notice like the different choices on regards to all of these another big one is uh latency latency tolerance right so is composability instant composability a must for your application or are you okay with latency outside of your dep domain right if you're a defi application uh that's talking to a bunch of different protocols at the same time maybe you don't have a high tolerance for latency so you're maybe you're going to focus on say a shared execution environment with instant communication

but if you're a game do you really need to to talk to to things outside your domain that often do you need instant communication or can you have some latest tolerance right is it a shared environment or an isolated environment so because uh when an execution layer uh caters to more than one D at the same time if they have uh if thats shared execution layer there's so much that you need to think about uh and ethereum has done a great job at at thinking about it and that's why a lot of these rollups and and na chains they they choose evm uh but that's a a big question as well I'm I'm almost done please don't get bored uh so we have the proving system right

are you going to use validity proofs are you going to use fraud proofs and what kind of fraud proofs what kind of validity proofs as well right and and this one this is one of the most tricky ones because a lot a lot of people they promise these like crazy execution environments and they say that they'll be able to prove them after but this is actually one of the hardest uh steps and the and the ability to prove is is related uh to all the things that were me that we were mentioned beforehand right so your execution environment every choice you make has to be compatible with the proving system uh that you chose there's also the financial model

aspect of it who's going to be paying for ex execution who who's expected to validate the results um so there's a lot here as well right cuz there's always the the attention dilemma right the attention economics which is if no one's cheating then validators are not like if if no one's if if cheating is impossible then no one's cheating and then if no one's cheating then you lose money just by validating right it's better for you to accept everything because you're sure that no one's cheating and then validators are not checking anything anymore so then people start to cheat so

it's a a very unstable equilibrium actually uh the guys from arbitrum they wrote a paper on it uh about this idea of how to properly reward validators uh it's quite interesting I I should have linked it here but anyway I'm going on a tangent here so privacy how how important is privacy uh is it privacy for inputs or just privacy for States so I have Aztec for instance Aztec is a an evm rollup if I'm not mistaken but but they are they they are built with privacy enabled from the GetGo right so it's a private ethereum in a sense it's a quite interesting project as

well so the last one but it actually ends with a an infinite least because there's a an infinite Choice infinite tradeoffs of course in diminishing importance right so just like everything like you have these basic choices that you need to make and then the choices differentiate less and less but uh what kind of inputs like how what is an input like uh because this defines if you're connecting to ethereum or if you're connecting to salaya or if you're connecting uh to to another data layer and so on right what kind of met information will will enter because remember the execution layer receives an input that can be a block right an

etherum block but that can be another kind of input as well what what does your output look like is it like can you communicate how do you communicate with the external world do you uh do they just have access to your state or can you just send messages to different protocols can you send a message to Unis swap on layer one can you aggregate outputs or like each message is a single transaction like is a its own transaction or can you batch outputs uh how do you prove those outputs right anyway I could keep going on and on about uh about these these different choices right yeah but but these are all choices

that again that um if if if a builder is trying to choose the type of uh execution layer that they that they want to to kind of build on you mentioned that it was kind of going in diminishing order like you know it starts with what kind of dap are are are we trying to build um you know how how much compute power kind of H how much um Trans State transitions and and what kind of type goes all the way through languages and Dev resources and basically speed and composability what kind of uh um uh in environment do you want um you know do you want ZK optimistic or other or hybrid uh how do you want to basically monetize and incentivize privacy inputs

outputs and then it it begets us to even keep on going but again these are all kind of thoughts that a builder is is going to have to answer um before even building right this is how you this is how you go into the landscape of all the possibilities in the modular execution layer stack and and and kind of pick you know what it is that you're looking for exactly yeah that's both for Builders that want to build adap and and choose uh what execution layer they want to to build on so like what do they want to build and then they they match what they want to build of these choices and figure out what uh execution layer is better for them but it's also for people people who want to build execution layers themselves right because uh

sometimes you think it's like oh I'm just going to build this kind this perfect execution layer and then you start to to bump into these trade-offs and it's better to have a good mental model uh beforehand so just uh I I I did say that they're in like di diminishing orders but they're actually not uh these are the like the big ones that came to mind when I was uh defining the presentation um the argument is that you could keep going on forever but you don't really need to right otherwise you you'd never be able to choose so you I guess you have to figure out what's important for your use case and just mix and match there right uh when I myself am analyzing execution layers I like to to split them

into two main categories which I think uh in a way are appr proxy for many of those choices that I was mentioning before and now like look I threw some logos here it's very incomplete this is by no means a a a good depiction of the landscape if you want that go to Andy's Twitter he posts a lot of cool projects there uh so I just threw some some around here right so you have the Salona VM which is a a shared rollup or a shared execution environment right some people are trying to make the salon VM into an L2 and settling it on ethereum but if even in Solana itself is is a it is a a shared VM right uh same thing with

cardano and so on and toana makes some interesting choices uh so they have that lcal Fe Market which which ties into the the financial model that we were talking about they also have um High computation right because they they parallelize the evm so they are trying to tackle applications with with high computation again that comes with huge tradeoffs right if you take a look at the the size of Solana nodes uh anyway so I'm I'm I'm going to try to be positive about all the projects so but uh you can see there's a lot of tradeoffs in execution environments and they all make very different choices you have Stark net which is the the other symbol there uh

just had a a la an air drop launch recently they are ZKA shared rollup uh so they have their own VM the Cairo VM their evm equivalent but uh it's another programming language uh it's made for generating ZK proofs optimism is just like an evm right they they do have the ovm but it's just a their idea is to to offer evm capabilities and which I'm going to go over in the next slide evm is very good for shed rollups so we have to be careful when we explore the the design space of execution environments to try not to be be harsh uh to anyone because

of the tradeoffs they chose right so I see a lot of people talking about the limitations of the evm but uh the AVM does have a very important place in in I believe in the settlement layers especially the other symbol here is ztec which is also a shared rollup with privacy enabled so trying to tackle those those uh uh those applications and uh you can see in the middle there's a division line and I have their fluent and arbitrum because from what I understood they're both tackling Shar rollups and app chain rollups so you can uh launch a single

chain for your app or you can have uh you can have one chain for many apps and that's a very interesting choice um because in a sense it it's it drives the it increases the potential size of your community uh the question that remains if is if you you're going to be able to reach uh a good balance because usually you like to optimize for a use case right right and you try when you try to cover too many things at the same time uh maybe you cannot choose the the optimal path on a on a on an optimization uh route right on the app chain rollups I put here cazi

and and dimension uh they're both targeting specifically app chains uh I'll use cesia as an example later to explain some of the choices but uh but yeah so I I think this is a very good way to first split uh the execution layers because when you have like uh a bunch of layers a bunch of deps sharing the same layer there's a there's a security risk there right anyone can deploy code to your execution layer so you have to make sure that it your execution layer can handle um malicious applications right even gas metering attacks and applications trying

to mess up with another application and in a way we've seen some like defy exploits in the past because things were coded in a way that they couldn't handle uh this kind of crazy application on top right so the classic thing was like flash loans so a lot of applications were coded without uh taking into account the massive amount of money printing that a flash loan could produce and then someone deploys an application and just like straight up uh breaks uh your your application so this usually like shed rollups versus AB chain rollups I think the major tradeoff is is that uh on shed rollups you have instant composability

right uh so applications can talk to each other very quickly uh the this bad side effect of that is that they all share the same block space so you have a competitive fee Market you you're limited in the size of the computation that you can perform um you cannot have a a different level of decentralization because everyone inherits the decentralization of of the whole and so on but the composability is great on the app chain rollups on the other hand you gain a lot of computational power because in a sense you have uh this idea of the entire block space a single application and there's no one else uh mess messing with the demand for your block space

other than your application itself uh but you have a problem of composability right and then the argument is that if you have a complex enough applications then uh the need of composability goes down by a lot right so I chose here uh two examples uh I chose uh talk about ZK sync and the question is is why does the design choices of ZK sync make sense right so ZK sync is a shared ZK R up so they have this irra VM which is their execution environment and uh it's basically an evm that knows how to deal of uh zero knowledge

proofs and AVM was as I was talking about uh it was made to support competing applications uh sharing the same layer right so they have battle tested adversarial metering so this idea that uh metering can be under attack U there's Prime composability but1 so applications can talk to each other uh super quickly and the ZK Choice adds even more composability right because it's very easy to prove the execution of uh your execution it's is very easy to prove to other layers and other apps and so on the computations are small enough uh that ZK proving is reasonable because ZK is has a a big overhead when proving

computations but they're targeting what's going on on ethereum right and ethereum is not a very high computational chain so I mean the the the type of proof that they chose the type of proofing proving system they chose is compatible uh with all the choices they made beforehand and uh it's optimized optimized for hashing operator operations just DVM in this case which is a 200 so it has it has 256 bit words is a very odd choice for anyone that is building anything other than blockchain applications uh but it's apparently great for for optimizing hashing operations right I think this for a very very similar reason makes it a very

powerful powerful U settlement layer just because I mean it has enough computational ability to to verify ZK proofs and to play fault proof games right so in a sense you have this one spot in which every layer or every D app can ride their truth and that can be uh queried by all the other uh players in the game right so you don't have to just keep asking someone about their state you can just check at the settlement layer so I wouldn't sleep on the settlement layer I know that there's some some modular folks who don't like the settlement layer too much I'm still not convinced so if you don't like the

settlement just maybe come talk to me and we can debate it and maybe I'll be convinced but anyway so yeah so ziki think is a you see that their choices make a lot of sense right uh they thought about what they want people to build on it and they built an execution environment that uh targets that and uh cartesia which is the project that I contribute to uh the cartas rollups uses the the Cartesian modular execution layer uses the Cartesian machine uh not just because the name is the same but uh but because the execution environment makes sense to

what we're building the C Machine is u a risk five based architecture so the whole idea is that with the extra computation that we get from being isolated right so so forming a nchain you gain this entire block space for yourself you gain this extra computation so we chose to use part of that computation to put up this uh Linux operating system and the idea is here is to give expressiveness to to dep developers right so we focus on the tooling part of the execution layer uh so we are optimized for computational power so in order to take advantage of the modular da right so if you have a

lot of data then it's hard to to to make use of that with the evm so if you have a lot of data maybe you need a very com a complex execution environment to to take advantage so we we're aiming to allow fairly complex applications so that's why I have like a file system and you can use uh the the tooling that a complex app need right even like files and even databases if if you want uh it's kind of interesting that the applications can be initiated of an arbitrary amount of data right uh since it's an app chain uh it you get to to to choose how decentralized your app chain wants to be right so say you're uh

building a I don't know like high-end car uh Marketplace so people selling like Ferraris and and and like very expensive cars maybe you don't want the normal laptop to be able to validate that you can like assume that people who are browsing a a expensive car Marketplace can Will have a a very decent computer or can pay someone to have a very decent computer to validate that application though it might be a numb application I'm just using it as as an example so you can uh pick and and choose on those uh requirements right and we also have it so that outputs can be aggregated and outputs are also gener

generic enough that they can Target any smart contract which is a way to deal with the this composability problem right so since there's a a latency on this communication we chose to have a very generic type of communication so that you can actually like send what the message you want in whatever way you want to other layers or uh to other applications and then the the proving system uh for what I'm describing is actually quite uh tricky to to to design so we designed this uh protocol name uh Named Dave which is a fraud proof system uh it's based based on optimistic games just like verification games and so on

but uh it's it's specialized for application specific right because you have like for instance arbitrum has a their fraud proofing system called vat which was a solution for for the delay attack on rollups which is a very common attack on uh on optimistic fraud proofs but uh in their solution the computational power that you need to fight the attackers grows with the number of attackers which is very bad if you have an app chain right it's okay if you have a shared layer because then you can assume that you have enough uh computational Power across the honest nodes in the layer to defend yourself

against an attack but if you have an app chain then maybe it's just you against the world right and that's why where the name of the the algorithm comes up so I'm just trying to uh to convey the point that uh the fraud proof system has to be aligned with all the other choices right because if we were to use a very like a outof the Box uh fault proof system then would' be subject to this delay attacks or if if you were to use ZK in its current state then I mean you need a very very big computer to be able to prove a single state transition of an application uh so I guess that did I

hope that I convinced you that uh there's a lot to think about when you're thinking about execution environments uh we do have some in-depth explanations of our design choices that I can share later but there are so many cool ones around right so there some so many like very good things uh attempting attempting stuff it's a vertical that that is worth following man so yeah I'm open for question I'm I'm certainly convinced thanks uh thanks for coming on Felipe I see Andy has a question I'll let him start and then I've got a couple questions myself so Andy yeah I mean I just like I'll just do one briefly um which is um could you

just kind of um walk through again with regards to this cone of innovation and then back coming back to the differences in the design choices was like like basically a general purpose rollup or execution environment shared in this case is kind of how you uh how how you named it versus like basically like an app specific or like a isolated execution environment yeah like generally speaking can you give us maybe like the top three or four design choices that you think make the most sense for a general purpose or a shared execution or yeah shared execution environment and then like like an app specific now I understand kind of specifically with ZK sync and ctez but perhaps like broadly speaking like what

design choices are are generally the right ones for a shared or a general purpose execution environment and then what which are typically the right ones for a app app specific uh or a isolated execution environment yeah sure that's a that's a very good question um so uh the when you're talking about like some execuive environments they kind of tell you what what they they're here for from the get-go right so for instance the evm was clearly built uh to allow this shared uh environment of many deps there are some teams that they take the the evm and they just just disable the

permission for you to deploy a new new smart contract right so in that sense they're making an evm for a single D app or for for a group of D apps uh but the the general case is for you to have an evm for a shared for shared execution right so what you need to to be able to to do when you do a an execution environment for shared is that you need uh to make sure that have very good metering because when anyone can deploy a new D app you have to make sure that the other D apps or the other validators who are validating all the D apps are not losing money by validating uh your the Malian D app

right so say take it as an example if I were if I was able to discover that say the ad gas instruction so so the ad instruction costs $5 for me to send a transaction that Target this this instruction but cost $7 for the validator to to to run that instruction right I just found a bug in the metering system so now I can create an application that just like does a lot of like add instructions and I'm basically attacking every dep at the same time right so so uh so this metering is a a very big uh thing I call it adversarial metering uh which is this idea that like one can

actually come and attack your meering yeah a very important thing is to have a very good like the apps to be self-contained so like when you're running Linux it's it's kind of hard to to control one code of touching another like place in the the memory space right there are solutions like we're exploring hypervisors for that in Vero but on the evm or the shared environments for the Solon VM even cardos U they are built in a way that when you deploy a code that cannot touch the storage uh of another contract right so I cannot just like launch some code that goes and still un swaps money right so

this like self containment is quite important in shared layers I think Simplicity like not Simplicity but the if you have a shared layer you shouldn't try to cater to computationally intensive applications uh just because it's same same problem right as soon as you have a application that is requiring a lot of resources from the validators either you centralize the chain a lot because now very few people can validate that or you are paying like a massive price for the block space uh on the other hand for app chain um I I I guess uh for app chains well first you can do this more

computationally intensive applications you have to cater for applications that are try to cover more ground of a domain what I mean by that is that say like when you launch an rc20 token you have to compose that of an exchange right because that's the way like the only usefulness of of like the itself has no usefulness by by itself it has to talk to other smart contracts to be able to to be used say it's a governance smart contract or an exchange or a landing platform and so on when you're doing app Chains It's ideally you try to cover a whole domain of uh functions right so if you're launching

an exchange on an app chain then maybe you should do leverage uh leveraging there and you should do Landing there and you should do like staking there as well so you don't go to this uh problem of uh the friction of communicating with other things uh but I I guess the main benefit of app chains is not only the comput computational intens intensity but also the the tooling and the dep resources that you're able to give right so now we're seeing just as CES is experimenting with risk five which is like this pedal tested uh General architecture right that has actually been built by people who are special LS in

building uh instruction sets there are some projects that are experimenting with was as well so web assembly which also has some interesting uh tradeoffs I think app chains is the the best place to experiment with that uh experimented experimenting with that for for shared rollups is kind of tricky because of these things that I mentioned before right like adding a metering adding a metering system to was it's gonna be like a a very interesting research project and it's so is like ZK proving ws and so on y yeah just uh it's it's this idea about like uh customizability and sovereignty from a

app chain approach with regards to having that control and over your execution environment and not being subject to you know different team's choices which is basically like the the land if you can compare it to like a like a on Earth it's like rather than being uh you know subject to your nation states decisions as to where your office building resides you just put some put a big fence up around your your office building and call it your own place your own country you make the rules and then you know there's trade-offs with with the isolation with that as well but um yeah I I appreciate that that answer and

I'll I'll pass it to Rob can I can I just add just one thing that you made me think of now so I guess it's interesting to think about this like defense analogy cuz all these things that I said that we should like consider when thinking about uh the execution environment if you're doing a shared rollup then every choice you make on these boxes they apply to every other uh application on on your nation state as you put it right uh but if you have a fenced real state then you can actually make these choices and slightly tweak the execution environments to appease your specific user case so this flexibility is it's

quite big on that right so like you can subsidize specific interactions you can uh do like this crazy compression tricks and so on you have control over taxes HR policy governance voting and then you can kind of uh decentralize and do these types of things based on your own preferences which is yeah I think builders are going to opt for that choice quite a bit in the future yeah I hope so too you uh you answered my previous question so I uh I appreciate that um there was a couple things that I I found really really interesting about the

presentation um and one thing that that you mentioned now is as uh Builder developers looking at at these considerations um if they're building a general purpose or shared environment when they go through each of these considerations they have to compromise on every single one because they have to think about all the different types of daps that are launching on that environment whereas an application specific environment can think about like very uh specific use cases they don't compromise for like the middle approach on each of these they can go you know lower latency or more privacy depending on on the parameters that they're optimizing for so I found I found that really really interesting um

and then the other uh element that I found interesting was um on this cone of innovation which I think is it's a great it's a great image and it's also a great uh a great Meme and I think one thing that that occurred to me was uh the shared environments are in the bottom left hand corner uh because they are optimized for the general purpose but they have less capacity and uh less data availability and then the application specific environments optimized for the outer edge of that cone like the more Cutting Edge daps because they have more capacity and more comp they have more

computational capacity and data availability capacity so I found I found that interesting in the the last point is that you mentioned if the if the PowerPoint skills were really on point you would add a third axis of privacy and and I think you could add you know assuming the privac theuh PowerPoint skills you could add you know eight nine 10 an infinite amount of axes because you really have each of these considerations here where you're going to where you're going to land on on this graph so I found this map you know really really interesting and uh it's going to be really really fun to see how the cone of innovation continues to expand so I I really like this uh this

illustration so Rob you're saying that like basically all of these different things could somehow in some capacity no pun intended be a uh be part of these of the access here I think so and and Felipe correct me if I'm wrong but if you look at if you look there at the at the list the second uh consideration we have is computational intensity another consideration think we talked about is data availability and then we've also got uh privacy is is one of the ones that you mentioned as far as another another consideration so yeah I I do think uh that each of these considerations and Felipe I'm curious if you if you agree each of those

considerations could make up an axis on this graph yeah so I mean I love your comments I'm not sure if the designer that I'm friends with is going to love uh that thought got of adding seven or eight more more xes there but we do have a very good mathematician maybe he'll figure out a way to like the topology aspect of that no man I I fully agree with what you're saying I think uh I would probably choose to to tackle the ones that most impact the design space so privacy is one that I really do think impacts the the design space a lot but as you correctly mentioned uh there are

some other ones that I mean composability also impacts uh uh the design space exp exploration a lot and what I I find uh very nice about this this cone of innovation is that as you see the darker part of it tends to be true about most things right so if you had a privacy access like what are you going to use privacy for if you don't have data ability or computational capacity yeah you can maybe like say you can put a eight bytes of private data on a blockchain like you can can't do anything with those eight bytes so yeah feel free to to help me out guys to

expand this and make it into a a real cone because I guess right now is a triangle of of innovation and that's the best part about this series man is that we're GNA be able to look back on this in a year and it's this cone's going to have tons more of different sectors you know I think generally we can expect to see that modular da category be separated into specific da layers I think then we can will see the app chain rollups category be separated based on WM VMS svms Linux VMS different types of kind of stacks you know and then also different settlement layers like Dimension ethereum uh salana will have its own rollup soon and various other

ones as well Anisha and different ones so all in all thank you so much for uh being here and a part of of this modular March series it's been a pleasure to have you on sir and really enjoyed the presentation thank you man it's a pleasure and uh I'll see you around yes sir