AMA with Andrew (Ipsilon) | EPF5 Office Hours

yeah awesome we got the recording and now we get 20 people so that's perfect yeah so again thank you so much for being here Andrew really appreciate it um because uh yeah thank you so much because it's very special for us it's the first time we actually have someone from Aron at these amas uh it took us a while to finally get some one and of course every go this very interesting project a lot of innovation coming from you guys so um um I'm sure gu uh The Falls are curious to learn more about it but uh before we get into the Aron and all the core development I would like them to I would like to get to know you a bit more and do you like just to uh just to learn about your background like can you maybe tell us a bit more about how did you start working on ethereum what did you do before how did you how did you get into the core development in the first place yeah right um yeah so um uh I joined the blockchain community five about five years ago well more than five years ago in the beginning of 2019 and it was uh my friend and colleague Alexi akuno the original founder of Aragon who actually invited me into this uh space uh and um uh before that I actually well of course I had heard of blockchain but I I hadn't worked on it uh I've been a software engineer throughout my career but uh before that I worked in Banking and uh uh around 2017 2018 I tried to work on my own startup uh which involved augmented reality uh and uh I wasn't able to secure funding so I had to shut it down but Alexi suggested this opportunity to me to to work on what was called toath back then uh so yeah I decided to uh jump in and um um to be fair to be honest it took me quite a few quite a while to get up to speed and it was difficult to for me to switch from working in the office to working remotely um and also to to blockchain has a steep learning curve But like after this initial period uh uh I'm very happy that I'm in blockchain and working on ethereum U because I think for uh for talented software programmers it's a great place to be a lot of you can there are many many rabbit holes that you can go down and yeah and uh go go you can go really deep if you want to yeah awesome thank you so much Andre yeah that's interesting so so you knew um alexe before uh because yeah that's it's interesting it's awesome so yeah Alexa is the is the creator of turboat which then which Fork G uh turned into Aron under its own branding and I still remember Alexa being in EF in like 2020 first time I talked to him and uh and then like it evolved so and now uh it's actually quite big like there is so many efforts so my next question is more like what is actually Aron right now like it's not just single client I mean there is the you already mentioned Aron 34 before uh there is silk worm uh there used to be AA so may give us a bit of an overview of what is happening now like what the Argon team does uh uh right yeah uh I think we've had quite a few projects maybe too many for our own good but uh yeah I can give an overview so historically we had uh projects in in three different languages in in go which is Aragon the originally toag H and then uh I think it was 2020 when I I I I was actually uh so I was a little bit uh pissed off by what I perceived as over engineered code in in in Aragon so some of it was inherited from G some of it was because of our own kind of over over over engineering or hecky code and I I I wanted to uh write some some clean implementation and uh I knew C++ at the time and I liked C++ and I still like C++ so and Alis the original C++ client was kind of dying around at the time and there was another project called evm one uh well and it's still going strong um it's one I think I believe it started as a hobby project but by one of of the ethereum foundation developers pav bit so it's a very fast evm implementation in C++ so srum uh started kind of as a rapper over evm one and uh uh the scope of that project has been um morphing throughout the year years and now we want to use it as a library for in Aragon our goang client for computationally heavy bits uh and also we want to switch our evm execution to to evm 1 plus silcr completely um because evm is one I guess one of the few bits still relatively unchanged compared to gu so switching to evm 1 plus silcr will increase client diversity um and it will re re architecture and redesign one one of the last remnants of yeah of GE in Aragon's code base um and also uh maybe it was 2021 I'm not too sure but we had a developer who was uh who liked our designs like our dat dat models uh uh and who uh who is very passionate about trust so he started this project akula in Rust uh but then uh at some point when when R start uh began and uh they they they started in like in Earnest and uh they also we on the path of open sourcing it he he got discouraged because uh uh uh didn't want to compete with them basically um and uh yeah then last we closed the akula project but I I think like trying to develop three clients is a bit too much so maybe two or one and a half is is already a good Target um in terms of our of our other project and and strength I think like historically the strength of Aragon was as an archive node uh we um when we started uh using guess and as an archive note was painful and I'm sure that they've improved since then but it was taking forever to sing gas and the dis foot print was uh very high um and um uh yes so like I guess the original core innovation of Aragon was to optimize that scenario the the archive node and we we are still not done with this task one of the projects that that we are delivering right now well we still haven't delivered it yet but it's we have released an alpha version is is Aragon 3 uh and it introduces uh introduces the transaction level granularity of State history which means that you can do uh like uh tracing historical tracing of a transaction much faster because like if you're State history Gran granularities on the Block Level then in order to trace a transaction you first you first have to have a view of the historical state of the beginning of the block and then reexecute all all the transactions from the beginning of the block to the transaction in question which can take a while while with the transaction level granularity of State history can uh jump directly to the necess required state so that that that's one Improvement of Aragon 3 and another Improvement is that we are actually put putting a lot of data in uh what we call snapshot files which are are IM mutable or virtually mutable and because of that uh you can download them over bit torrent and uh now like in order to sync Aragon 3 you can download State plus State history pretty much over bit torent and with with our current uh production version which is Aron to you download uh State uh you have to reexecute all the blocks from Genesis in order to arrive to the current state which you can imagine is is quite slow uh and uh yeah what else uh what other projects do we have um we uh maybe a year ago or so we started a project code named captain to implement the consensus lay um what we we call it internally the real merge so it's uh it's like merging two two pieces of ethereum into a single piece of software uh and uh we are also um we are also a multi blockchain client we support besides ethereum we support nsis chain and and polygon uh I think those are our our major Pro projects yeah thank you so much uh yeah it's a it's quite a lot I mean the arons and silk worm and uh and uh also all Kaplin uh integrated that's very useful to be able to just run a client like we used to just a single binary so yeah um yeah thank you so much adrew and we already are getting some questions in the comments before we get there I wanted to have one more question just specifically more about your focus what do you focus on what are your tasks what kind of uh work are you dealing with these days um so uh yeah I I have I have primarily two roles uh I work on the ethereum E side of of Aragon uh so I participate in the in the e oo def calls and keep track of the progress of of ethereum's road map and uh I with my with my colleagues Implement some of of that uh and uh to to some extent I'm also the uh CTO of of Aragon so I have to do some kind of man managerial or admin tasks awesome so you have also the organizational role I didn't realize that that's interesting thank you so much Andrew yeah awesome uh yeah so folks if you have any questions always feel free to raise your hand or we got some in the in the comments so I'm going to start with that um the one one that I find interesting is whether you guys are thinking about getting history data from Portal Network or whether you are thinking about integrating with portal because you already work with the torrent so I think that like it's could be another module there yeah um yeah we we thought about it and uh I think um for us it makes sense to to be a to be a provider of uh of data for for portal network uh because probably like like uh like portal network is essentially a distributed hash table and it might be not optimized for our use case which is to sync like a lot a lot of data so ter terabytes of data of if you want a a full if you want an archive node so I don't think I I I haven't run any any any tests or I'm not aware of any T but I imagine that it would be quite slow with the portal Network because it's just simply it's not the use case it's been optimized for but because we actually have all the data we can be the the provider yeah I'm looking forward I I'm actually asking because I'm kind of looking forward to see the portal with my Aragon node so um I i' love to uh I'd love to contribute this way um we have question from Kya yeah I check Dr was first uh is here okay yeah he head is down so yeah yeah yeah hre I have a two questions thank you for coming uh I have some confusions about interaction of um execution layer and consensus layer and this is my chance to make it crystal clear so um uh could you like quickly make an overview of a transaction flow um how it switches between execution and consensus layer and what's the time time window of execution layer in the slot when a transaction is executed um because later it goes to the for attestation and um this period in the slot uh I wonder uh right yeah uh to to be honest I I know a little about uh the consensus there and I I don't remember the the exact timings but overall like how how the flow works is that uh now blocks um uh like we have we have uh bacon chain blocks um that are superet of execution layer blocks uh so like the execution layer blocks inside the Bon chain blocks are called execution layer payloads so those blocks are pro are propagated over the Beacon chain Network or or the consensus layer Network and when validate receives a new block it asks its uh perer execution layer to validate the blog because the E uh client it has all the state like the the well the kind of the E State the main state of ethereum uh and um CL C clients they kind of they have some state but it's a much smaller state in terms of so they they have things like like valid data sets things like that uh but the the bulk of ethereum state is on the El side uh and and in order to execute an block you need to access to to the state at least until until vehicle comes along um so yeah so it has to uh CL has to has to ask ask and does ask the E to execute that execution payload and specifically among other things verified that after execution executing all the transactions inside uh the El block the resulting uh State root matches what's there in in in the in the header in the block header it's kind of because the state rout is is a commitment scheme which guarantees you that your Comm meting to to that specific State uh that that's uh that's the most time consuming verification bit um yeah and uh then um um that can be a a reason for missed attestations if uh the Y is quite slow in terms of block execution then the CL will be slow to actually uh to uh uh uh to to to find out that the E block is is valid uh and and the Aragon uh probably right now is not very good at it because uh uh it's uh so it it kind of works but uh we we still haven't uh optimized the this performance on the tip of the chain fully uh and that I believe we have potential in the in that area um yeah so does it does it answer your question yeah so um at the beginning when uh the validator even has not yet propagated the block the transactions go to the mle rate it's and it's on the execution CL yeah okay so there are there are kind of two okay there are two two scenarios so uh when there are there are be if if uh if a validator is uh each slot a validator is is uh chosen randomly or sud randomly to to produce a block and uh that's one scenario so for Block production it actually it has some time to to to produce a block uh and it asks uh the uh elel to to do so and and uh what what El does um is uh it looks at at the transaction pool uh which essentially or the theand pool which has a pending transactions uh and start starts adding new and new transactions to to a block and then at some point the C might might say might might tell the E okay time is up like stop now wrap things up because uh like you need you need also to to final uh the the a block like you need to calculate the state route and do some other small small uh things at the end of a Blog uh and then the L just returns that that uh execu that e block I the execution payload and cl wraps it inside a bon bacon chain block and uh propagates it over the network so that that's one scenario when it actually is uh is building a new block and what what I what I talked about previously is is uh uh the attestation scenario when someone else produces a block and uh all all kind of all Network participants have to attest to the validity of of that block but both both cases in like the there might be in terms of like slowness and and timing uh there might be different bottlenecks so the network speed can can can clearly be a bottleneck the the the shear like speed and and latency of of your network because you have to to propagate potentially large blocks uh that that can be a bottleneck but also e performance on the tip of the chain so how how fast you can either verify or existing block or build a new block by adding transactions are uh like start you add added transactions until you're told to stop thank you that that's the topic I would like to add to EPF weki because we have the general scheme uh how layers um interact but there would be nice to add a flow yeah like Mario where it starts and how it goes between the clients thank you yeah like the closest to this is the Daniel's documentation from uh uh uh Daniel from the previous cohort on the engine API Guys somebody knows what I'm talking about if you have it uh it's a secondly dog I can share it here later but uh definitely this could be improved yeah yeah and thank you so much for the answer Andrew um folks um yeah if questions yeah I'd I'd like to note on that that theme uh it's it's a related discussion that that we had internally uh in the team uh is that before the merge well uh Block in the proof of work World um like e e nodes were self-sufficient and they relied on the E uh peer-to-peer to to propagate new blogs to gossip new blogs and so on but effectively after the merge the the only use case like like and some of it still still is is still uh is still there uh after the merge but by and large if if you consider uh e peerto peer we can probably well we can perap uh bypass it uh it's only really strictly NE strictly speaking it's only necessary for transaction propagation for for the M Pool but for Block propagation uh we can rely on on on on the beacon chain on on the beacon chain on the C peer-to-peer uh and uh we we thought about actually switching of e peerto peer uh and using using or like keeping it only for the the mempo but I think there are kind of um maybe C clients are not fast enough in terms of retrieval of historical blocks but but but conceptually conceptually now blocks uh live on on on the CL side and E like e top doesn't have to to uh propagate them it still does but but conceptually that that's redundant anyway sorry it was a side note now thank you so much for adding that um we have uh we have a question on uh uh the uh design from JS Visa I'm not sure if you want to read it JS Visa feel free to uh open your mic otherwise I will read it um uh the AR E3 will store the stateus transactions instead of uh blocks so uh it will really increase the performance of transction related apis but as a disadvantage uh will the storage and uh times bigger blocks will I guess whether this is the is the storage size yeah uh uh right so so if it depends on um on the state history on how the state changes and how how you store it because if on on like you can imagine two extreme scenarios one one scenario is that uh inside a block all all transactions touch the same the same data the the same say the same account and the same storage then um if you compare the two granularities that that that that clearly uh like switching to the transaction uh level granularity will make your State history end times bigger right if you because there will be a lot of a lot of changes to the same the same State and the on a on the Block Level you you can collapse it into a single change but most transactions are not like that uh they actually touch different pieces of the state and if you imagine the the opposite extreme case where each transaction uh touches different accounts then there is no change in in in in in the footprint right because uh you you can if you are clever about storing the state the state changes you only store what's necessary then um yeah you can you can switch to to this transaction level granularity without any any increase in the in the footprint and of course the the real situation is is somewhere in between but uh What uh what we did in in Aragon 3 we also uh used like better comp compactification algorithms uh and especially like like what we did with with the state history that we have a system of overlays uh such that um you kind of your your and and also that's true not only for State history but but for the state itself kind of uh split your state into state that was touched recently and state that was touched a long time ago and if that partition like partition is stable in time IE you have that system of of overlays but um um maybe you do say like your time partition is say every uh one every one million blocks or so on um and that stable that partition stable in time implies that your your old files they never change and if you have some immutable um set of data some immutable Maps some immutable hash table you can use uh you can do some pre-processing to compress it even further to compared to the case of a of of of a hash table that you can change dynamically so we you can use techniques like the perfect hash table for for better comp compactification o of the data uh and yes so that's that's what we do in in Aragon 3 and uh the the end result is that it depends on on the blockchain but I think in for all blockchains so for for both ethereum and polygon and and also for nois chain actually the dis footprint is is reduced in Aragon 3 despite the switch to the transaction level granularity awesome that's very interesting optimization thank you so much Andre um yeah awesome uh churk do you have a question yes I do have a question uh sorry yeah I've been having troubles with my mic but um in uh like when you were introducing uh your background uh you mentioned that um you had to fix a lot of over engineered code and I think ethereum in general right now is plagued with over engineered code in many places uh in most clients uh do you like first question is what would you attribute this to uh and would you necessarily like attribute this to like a uh a scarcity of uh product managers in the ethereum code development itself uh I'm not I'm not sure of that yeah uh right uh okay that that's a good question what's uh yeah uh why did do we have over engineered code um I think I think uh one well uh one one reason is uh some some of the complexity is uh is intrinsic or or or is uh is due to the protocol and uh kind of if you if you consider the the ethereum protocol itself then some of it complexity is historical and some of it is Justified uh uh and U kind of i i a big fan of making things uh simpler but it's not it's not easy like making things simple is is very very hard um but yeah so the some some of the complexity of of the code base is due to the fact that that the protocol itself is complex but uh some of the complexity is probably due to of of Aron's code base is due to two reasons F first we inherited uh uh we started as a fork of G and uh you know that reading others people code is is hard so sometimes if you're not part of the original team you you don't have the full context and uh you kind of you try to to work with the existing code base but uh because of your lack of understanding or context you make it even Messier uh than it used to be uh that that that's one reason uh and another reason that I think sometimes we were in in a hry uh to to prove uh something like to to prove that our ideas about the state representation and the data models they actually work and I think we've proven that um but um because of that uh because of the the time pressure we we had some technical debt uh also I think I think um maybe in in in the past uh we were a little bit too ambitious and I'm not sure it's it's it's a good thing but when you try to uh to when when we had what what we call internally our our trilemma so we have to pursue pretty much three goals we have to keep up with ethereum's road map and ethereum it hasn't aifi yet it has uh I think quite significant Innovations and changes so we have to to implement those and participate in the discussions we also have our own technological road map which I think is quite ambitious we have to to do that and and then we have the product quality and the users and the user experience and so on and support so which is also takes a lot a lot of effort and uh yeah I think maybe we were not good at achieving all all of our goals because there were too many of them uh I but how how can we solve or those issues or how can we improve I think um delivering Aragon 3 which is uh which is well maybe not around the corner but I think it will happen in a few months time and maybe it will give us some some uh breathing space in terms of uh the our technological foundations so we don't need we will not have to uh rein reinvent the the the foundations uh again and again because it's it's quite costly to to you know to uh uh to change the found Foundation of your house uh and also uh I think we uh we will continue on enhancing our um test Suite so all kinds of of automated test so unit tests integration tests end to end tests uh because uh I I think if you have a um a liated code base and you want to evolve it then the only way you can clean up technical data and do refactorings is to have a really decent test Suite because other otherwise you make a change and you don't know whether you break things horribly or not yeah um um yeah yeah feel free to follow up here yeah it's it's not uh yeah sorry uh it's not more of a followup per se but uh I think I've just like uh mostly heard uh Team managers say that uh there are lot of uh short-term contributors more than long-term contributors in the open source Community uh and that causes like a code to be not maintained for longterm by one person and then like just multiple authors coming in but anyways I had uh another question uh regarding uh EIP 44s uh for a client like Aragon which is uh focus on archive nodes uh and there being uh a one out of end trust model uh for EIP for like after 44s that is um sorry I missed the second part like the first part was Aragon is is like um is is focus on on the archive now what was the second part uh yeah with with 44s uh like e 44s um pretty much like um there's only going to be uh one year of History maintain I I assume uh and like how will Aragon fit into like a post four 44s world that is right yeah uh okay yeah that's a good question um so yeah I think like historically um the the strength of Aragon has been as an archive known but we believe that with Aragon 3 that we have the technological Foundation to actually improve uh our performance as as a as a full node uh or even I don't know maybe it's some kind of light light node but yeah that's that's mostly uh about the future uh how uh about 44s so like the way we we it was in Aragon one it was it was problematic because uh Aragon one had to reexecute all the blocks uh from from Genesis to get up to the current state uh but um uh those blocks had to be obtained from somewhere and from from from the e peer-to-peer Network th thus it wouldn't be possible in in in the four fors world but with u in Aragon 2 what we did we did uh snapshots not of the state but of the of the historical blocks and put them on on bit torrent and we we did them uh the partitioning of of the the historical blocks is stable in time meaning that files containing all the all the blocks they um never change or or like or change very rarely uh which actually means that even Aragon 2 is is compatible uh with with the for for world like it's kind of it it can live fine in that world because it has its own mechanism of Distributing historical blocks um uh and um Aron um Anon 3 uh can actually sync the state itself so it doesn't have to reexecute all the historical blocks which means that it can actually benefit from from the uh for Force world because it it can also um Amit some older blocks and U we already have of three three pruning um modes in in Aragon 3 so the no PR prune mode is for the archive node where you don't prune anything then uh I think the prun mode for maybe it's it's called the full the full mode I'm not too sure but it basically corresponds to the full node and uh without four force and we also have this mode Min which we call minimal but it's essentially four four fours where we prune historical blocks um because those are not not needed for say for the validator um and I think um we we also in terms in terms of all nodes living in in the four four worlds I think that's a bit inaccurate because you still want some archive nodes or you want some entities to store um historical blocks of ethereum for research purposes or for uh like if someone is uh super paranoid and wants to reexecute all the all the historical like do the this Genesis thing then there should be a way uh to to do that so I think we are offering uh our own proprietor like at the moment it's it's proprietary in the sense that it's not well documented solution in terms of our um snapshots and we want to document it uh uh and and make it well specified so that others can join but what what I'm trying to say is that uh there is actually value in having things like like Aragon archive nodes or re archive nodes or the portal Network that provide some means to for of of retrieval historical blocks but Mo most of in the 44 world most validators and most ethereum uh noes will will not have old blocks yeah yeah thanks for the answer thank you so much thank you so much also JS visa for uh quickly sharing the the documentation um yeah folks any questions uh feel free to raise your hands and we have Kya again yeah go ahead yes so Aragon has embedded uh consensus layer yeah could you tell yes so that that's the um the project Kaplan in in Aragon 2 uh it's off by default and in Aragon 3 but but it's still possible to to uh uh switch it on in Aragon 2 and in Aragon 3 we want to make it the default um it's and currently we are working on on implementing um Spector changes there um do you have the plan to make like a full validator embedded into the Aron we I think uh we maybe at the moment uh we don't have plans to implement their kind of that relatively small process that actually the valid dat keys I'm not sure the official name for it but that's official term but I would call it the keeper right but that that's a very light lightweight process that that actually and when like for the moment we are happy to use light house or another seal implementation uh for for that that small small uh bit but for the bulk of the C logic so for uh the beacon chain note we uh we are working on its full implementation as as project cap inside Aragon's code base um and yeah we want to it's uh it's kind of not super polished yet but we will keep working on it and keep improving its performance I guess not only keys but 32 e also right right so okay uh good it thank You2 is uh yeah but I mean uh uh probably access to to that bit is uh controlled by the keys right yeah and of course like you can run uh the client with some pool which lets you do much less than that so um uh yeah uh thank you so much guys uh Bulma has a question okay good afternoon I don't know if this is out of proportion but I have a question in regards to um trying to um do something related to minimum validator participation in etherum bcoin chain like do you have like um pointers on how to go about this um I'm sorry could you repeat it I didn't quite get it okay I said I don't know if this is the right question for you but I feel like you might have an answer or something um do you have any poters on how to check on minimum validat participation on ethereum be chain but what do you mean by the minimal validate participation like like do do sorry is it related to to client diversity or again I'm I'm I'm not very knowledgeable about about Sal so maybe and I'm just misunderstanding something I'm care to elaborate bu I also do you mean the like the 32 is uh requirement to like the I think maybe we lost yeah we lost her I was a connection problem I'm sorry about that uh but we still have enough time she will be back hopefully do have any other questions meanwhile um [Music] yeah um yeah U Che yeah so it's it's also following up on uh eiip 44s uh like I really just want that EIP in ethereum so that I can uh rent out uh better vpss for lower cost but anyways um so uh since Aragon has already uh worked with bit torrent and uh also tested uh the reliability of bit torrent for storing history blocks and snapshots um there is this ongoing debate of whether they should uh take in Portal Network or if they take if if they should take bit torrent in for for storing the history uh generally it does not really matter but uh uh you know like which ST which Step would arigon take and like has arigon already formalized any analysis uh in this respect uh you know bit torent versus Portland in in general yeah uh right so uh I kind of I I haven't been uh involved uh I haven't looked into the portal network uh in depth myself I know that some of my colleagues looked into it and there is some some interesting cryptography in the PTO Network um or that that might be beneficial it's it's kind of what uh with with currently with with with uh the with our current model in Aron we um rely on social trust a little bit we produce uh the um we run a set of uh of Aragon noes to produce uh the what we call this the snapshots so like like files containing State State history and historical blogs and we publish hashes of those files on on a GitHub repository uh and um uh um so we we and we have some kind of mechanisms and tools to check that um the produce snapshots are are all right but it's not very decentralized so um like ideally we would like to use the blockchain itself as a means to uh to publish uh to to commit to to the those hashes and I I I don't I know very little but maybe that's something that that the portal network has done or or at least looked into it um um I'm sure that some something similar is I kind of heard that some something similar is done in terms of IG beon uh on on the C side you have some cryptography some aggregators where you can commit to a range of you can verify maybe a range of blocks but I I'm I'm out of my my my depth here uh but but basically what what what would be interesting interesting is to uh via a smart contract or some other means to uh um um actually to publish commitments to um blockchain history on on the blockchain itself um in in a secure manner that would be cool uh and uh but I I I don't have concrete ideas uh for that yet so but but I think I I think ideas from the PTO Network might be helpful in terms of of practical uh implement uh as as I mentioned in the beginning uh we can probably be we can probably provide data for the portal network uh I just have suspicion that it's not optimal for us uh to to syn from it just bit too slow um yeah like we had we had uh Colby from Portal actually at this AMA like few weeks ago and he was very bullish portal of course but honestly like I feel that Aron get us even closer to the 44 like so the uh requirement for the for force is to have some reliable alternative to uh peer-to-peer Network to Ser data and Aragon which is um which is integr think with the torrent works really well uh like that's the the torrent is like we have the Sol like portal network is like torrent with extra steps right we already have the the torrenting solutions for a couple of years years and now um like I think the the one big problem is compatibility or standardization here because for example um for example uh get has the error files I'm not sure if you've seen that so uh there is a torrent for like all the premerge history era files and you can easily verify them and uh import them to get but it would be nice to have this sort of torrent for The you know which can work easily with all the clients and then also like portal like have multip Solutions but but I think that like Aron really did a great job on this uh yeah uh T tet without those extra steps um yeah anyway uh we had we have BMA back maybe do you want to repeat your question because we lost you um otherwise we still have few minutes for another question uh yeah okay Kya go for it you're your Le just if anyone doesn't have any questions yeah I just I have some confusing Parts in the work of execution layer so the another question is about storage because uh I know storage from the smart contract developer perspective but from the peer-to-peer network uh is it just like database and it's and it it is on the consensus layer um H um so well no storage is actually is part of the kind of what I consider the main state of ethereum and it's on the E side so it comprises like accounts Plus Storage they comprise the uh the bulk of of the state of ethereum so there is some state on the C side related to to say valid data set and so on and also blobs which are Emeral but still like you're supposed to store them for for a while uh yeah but but that's smaller that's smaller than than the El side um so you can think of it as a key value database essentially yes um the uh the key is and you can have like different uh key schemes and an interesting like if you are into the the the key schemes and you want to go you want some advanced stuff then you can look at veral and how the key scheme is done there um but like for currently like for for like one simple way is like the key is the the account address and the the the the storage slot address you can you just com combine the two parts into into this composite key um and and the values is the value uh which is a a 32bit u 32 byte number um and you can encoded compactly so that like initial zeros are left out in the RP encoding but essentially it's a key value database um uh and you commit you commit to that state currently VI the merco Patricia tree um but going forward with veral and from our perspective from from Aragon's perspective what's interesting is that the keys like when when you consider the evm itself the evm execution it operates on the plane Keys um but when you calculate the the commitment the mro Petri root it actually hashes the keys uh and it introduces uh kinds uh some kind of inefficiencies in terms of data access which we're trying to mitigate in N 3 but that's I guess that's a uh a different discussion um yeah my main question was about the database stored in execution layer yeah thank you and the blobs they store the data from l2s right yeah yeah you thank you so much for the answer and uh that was the last question because we are at a full hour we got to wrap it up here uh but yeah thank you so much uh again Andrew for being here it's been it's been a great hour great AMA um and uh thank you everyone who asked the question thank you so much for uh for the great session yeah I think we learned a lot we get inspired uh really appreciate it man thank you for hearing me and thank you for the great questions yeah of course of course yeah I really appreciate it and uh yeah