AMA with Mikhail | EPF5 Office Hours

uh just to just to learn about your background and and uh uh what you've been working on in the past so uh please just uh start by telling us with yourself uh if you can tell us maybe a bit about your journey what L you to ethereum how did you start working on the core development yeah what was it like for you um yeah is it yeah thanks thanks Mar is it is it fine now I mean like the audio um I for some reason can't turn on the video yeah sorry I can't turn on wor I hear you Chris that's important yeah great um okay yeah thanks for having me here and uh yeah I'll I'll I'll be short on my journey um in ethereum so I'll I I'll just accidentally join the ethereum community into 2015 um as an engineer we've been working on one of the mentioned um ethereum clients so yeah after some time yeah it was really exciting to me um to to be a part of it was great um early days you know um so was really um rapid development of every everything around and was kind of like um very excited by this um new blockchain um that just recently uh sorry the main that so was very excited from from the first day uh literally uh and uh yeah before that I was not much involved in crypto and not following much the crypto I've heard about Bitcoin but that was just you know something like uh the price of Bitcoin uh following and a bit of the technology and uh yeah after that after after a couple of years in in the space um um even yeah it it was like more uh maybe three years after the ethereum 2.0 um effort started and then joined the R&D part of it and uh kind of like we were working on the Bon Chen client um basically with the the guys from from the team we worked on the those the the CLI that I mentioned at the beginning yeah and that that was my journey to R&D um and slowly started to do more research work but originally from the engineering world now working on the SPs and engine pii consensus specs mostly and one of the biggest project I was involved was the merge uh where we basically design a lot of uh things that we use today um in terms of the spec and spec to in mostly so that was awesome um that kind of my this is kind of like my my part to to to the core development to where I am now participating in Electro now and yeah looking forward to um some new stuff like single slot finality and other consensus related things problems yeah we'll definitely get there I also want to ask about like what you're looking forward to uh but yeah just to reiterate you've been you started working in 2015 on alet the C++ client h no it was eum J um Java client ah ethereum J the Java client oh because I heard something like so yeah Java Clan that's that's anent history that's uh I wanted to highlight it because people here have no idea that some stuff like that exist a few years back so um uh that's real interesting and um yeah uh yeah it's been it's been a lot of stuff like you mentioned the merge and you've been working on this spe the agent API can you maybe tell us bit more about your projects like so people have better idea what you've been dealing with recently or right now it was the 6110 uh I believe the Maxi B staff uh yeah we you have going on uh these days or or recently yeah sure that's a good um topic to expand on so yeah what uh I've mentioned that I'm kind of like um involved in Electra now and Electra uh it's comprised from the a number of changes number of VIPs and uh those that I have been involved into development of R 6110 uh 7251 which is the max effective balance increase uh 6110 as deposit request and uh what actually made me to the CIP is the um some technical depth that we had since the marriage um so basically uh dep deposit uh still made um why e one Bridge which is completely redundant after the merge so the C fixes this um this technical depth and uh uh yeah the nice story about 6110 is that uh from a couple of guys uh from the um um cohort number three if I'm not mist taken uh from the EPF we we did the Prototype um uh of like basically implementing the uh thec in in a one in bazu and Lighthouse uh and run several Dev Nets and did a great project on it uh which actually uh which actually impacted the inclusion of dcap into Electra so it was really awesome uh time it wasn't a year ago and and yeah at the same time I was involved in 7259 uh some basically design stuff um of of the of the spec and how it can be implemented um within the existing protocol yeah so also do an engine API support by by default awesome thank you so much Mel um yeah it's it's all of interesting all of important parts of the client and uh um I believe if folks have any questions about I know engine API specs feel free to lose your hand um otherwise I can also continue following up oh we have some questions okay uh let's let's start with you guys uh I think that was like split first hey M so I'm um can you hear me okay I got some noise yeah I can hear you I'm curious about two top your opinion on two topics that were discussed uh in EPF either in our uh weekly standups or in other amas uh first being uh in the context of uh 61110 U because you're um you're actually removing it uh the bridge from eth1 data U would it be hard I mean what would be what would you recommend adding new fields to the deposit contract in order to add new Logic for example delegations because I'm working on that project uh and my mentor said in an uh in a discussion in a previous discussion that it would be maybe very hard to add new lines uh to to the deposit data structure or basically it would be better to add like a new delegation contract that would constitute another eth Gateway into the system that's uh that's the first question and do you prefer to ask the second or we switch to the second later yeah I just want to clarification uh what's this delegation is about probably to answer the question I need more a bit more context yeah so the adding delegations would be uh basically to uh to let the protocol see if holders uh on top of validator so now the ethereum only see sees validators does not see the source of uh the capital provider so the project would be to add in the beon state another class called delegators that can actually uh represent the eth holder that can delegate to validators and that would need another Gateway for actual ET into the system yeah that's that's interesting and the delegator is is it explicitly specified to the deposit call or is it just the owner uh the the originator of the call of the transaction making deposit it's the is the originator of the of the trans of the transaction so is the entity that generates the deposit transaction okay I see yeah it's interest interesting I I don't know I need just you know yeah let's bu the chat uh fine after after the call about this but but yeah my intuition would be uh to not change the deposit flow that we already have and attempt to do something aside of it because this is the critical critical component of the system and um it's it's quite hard to to do the change and you have to reason about it that it just doesn't break anything yeah probably probably it's not that complicated though okay sure we can we can chat more on that okay uh and second uh yesterday we were discuss actually I raised up a topic and we we said uh it would be good to ask your opinion on this since we have you today here uh is there a reason we do not have Consolidated consensus specs because for example I I realized that it would help me so it was like for for my own uh um you know m process I was thinking something along the line I kind of need it so I would like to build it and then the question was why don't we have Consolidated consensus effects is there like a clear like a clean reason why we don't or just it was not a priority what do you think or and and did you ever had to you know to discuss about this or to think about this um so you the Consolidated speack would be the back that has all the changes right I mean like it's like literally the last version of of the protocol yeah cuz we just have the diff you know in the consensus P we just have the G diff between the last fork and the current fork and as a researcher I know I'm sorry sorry sorry yeah yeah go ahead just a short note aside uh as client as implementation as a client uh you know develop Vel ER it's probably not that important because each client has its own way to implement the state and the and the the specs but as a researcher for example maybe it would help you or a researcher in general to have like the full uh view of the current etherum specification in front and not have to jump from one fork to another just to you know get to the to the bottom of it to the main View yeah see yeah that's that's interesting question so I would say this is historically um we use diffs uh for this is very convenient for um introdu for the introduction of the new uh changes and um basically assembling a new Fork scope out of those changes so it's kind of like uh quite important to keep everything clean um on that front I guess um and the actually do you have uh you can compile the python part of the spec and get the most recent SPC representation um this is done by actually making the pice pack this compile pice pack but probably this this would not be enough um because this pack has some English uh in it as well English statements um so I'm not sure if U yeah I I can understand the problem so you you want to look at the um at this back um like just you know at at the holistic spec and you knowon about some some calls and and the outline uh in your mind or what whatever else the whole graph you know yeah yeah yeah yeah so yeah I can I can understand how it's um uh the problem here but the other problem of this pack would be in this case so you have you can have you can get python right so but sometimes the rational behind some changes is not um is is quite uh is hidden behind you know a number of changes behind some conversations um so probably U if you're starting to look into this pack and trying to uh learn the spe now the best way would be to if you have this holistic compile five pack also look at the underated speack which is not yeah which is which is uh built on a diff basis so um but yeah that's that's that's quite hard there is also a book by Ben enton which is called E2 book which is a great source of you know yeah everything is probably one of the reasons why why one of the reasons why this book exists and uh one of the utilities to have this you know um kind of like description behind the lines of this spec I don't know if it provides the holistic view though I mean like on this spe yeah that's a good question but it's probably that uh when you start being uh familiar with this pack uh it's hard but then it's kind of used to you used to um just this this representation of this spec I don't know it should be at least it should be a separate task to maintain um um the spec within the English statements and you know that's that's kind of the overhead somebody will have to take and you don't uh you didn't uh so there were no formal discussions on this uh Mario said yesterday that the the execution guys had something something like that uh compiling all the all the changes on consensus there's no I'm sorry Mario Yeah Yeah Yeah just they had a discussion more about how generally how to structure it like they didn't come to any conclusion but you're asking whether there there is something like this on cons consensus yeah if you actually run the uh make by SPC um in in the spec repository you you'll get this uh spec compiled there will be different versions of the spec for Electra for for the NAB and so forth each each of them will contain uh the fork U yeah which will contain the the protocol version up to the fork interesting and that's for test uh for test cases okay yeah yeah that's for test cases and sometimes it's really useful you know to have this um to just to to to Bros across the different and different methods okay thank you and uh I'll I'll look you up on the chat for the other discussion thank you m thank you guys um Dan you shared me the overview document for the eods you mind if I share it in the chat I think it's like a great uh overview if Mikel is stand up to speed uh Mikel if you heard about what partab has been working on like the rainbow taking and making this delegation it's uh uh it's elaborating this research space so this is Dan's overview um yeah we can move further um Kya do you have a question yeah hi M thank you for joining us today um just to make it clear so you do both uh research and core development or you more invol involved in the research for now no more more the R&D uh we definitely do some engineering stuff like um working on prototypes you know and um yeah and writing tasks for the spec and other things um yeah like that but yeah more more on the research side of things then I'm not involved in the C development yeah so my question is uh what do you think of Spectra split uh do you agree or disagree and uh what dips do you think should be delivered first um that would be interesting to know uh that's that's a tricky question um and more like on the side of the coordination things but I yeah I I actually agree with the split and in favor of this plate U because I think that we it's been already uh quite um quite a while we're working on the on the fork on the pack Trend actually um if we were not making a split uh the the upgrade will be delayed uh which is but yeah by there there are to my understanding there are some uncertainties and we just want to uh to deliver what is already uh kind of ready to be delivered uh there is still some unknowns when we finished the dev Nets and uh all the things but at least the scope for those features that are included in the first Petra subor uh are kind of like uh settled down in terms of the design uh so it it just makes sense I think it's natural to to Del it first and um and do the work in parallel on the others on the other the one that that that are pushed to the second part yeah thanks you thank you um by the way um POTUS from Prism had a good article on this uh pectra split this opinion I'm not sure if you saw that like it's um uh just uh if you want to if you want to hear his thoughts or like generally like it's an interesting overview on how this stuff is coordinated and maybe how to prevent this in the future um yeah so I agree with Nel like it's uh I think it's overall good it happen like from the world perspective but it shouldn't have happened in the first place like we could have avoided it but uh I don't know coting maybe um we have question from ra do you want to read out loud or should I read itad Mario yeah okay um yeah so so it's a question about uh using the engine AP over IPC instead of RPC uh whether AP over IPC is possible uh because it's like the idea of engine API you have it on the same machine authenticated so it would make sense to use IPC and uh I think get and prism even allow that but like yeah when you think about this like whether you know some more details on the performance or maybe implementation complexity or soon um yeah I so um I don't I we did not do the comparison of the performance of these two things um so but the general idea was just to leverage on the um on the interface that the execution layer clients already have when we were introducing the engine API just extend this interface uh and uh sometimes potentially yeah probably those calls can be yeah really um but I'm just trying to understand whether there can be any huge communication overhead um with respect to the um to to the operations that have that are being called on the E ycl so I don't know really we did not measure the performance and yeah if if there is the appetite to do this it would be which is great you know to to see uh uh but the main idea was just you know to leverage on the jrpc API um and U make the this interface that can be run uh on across different machines and uh yeah that was it and there is also an idea that we should not use Json because uh the the size of the the amount of data that uh is being transferred between CL and DL clients uh is growing and probably we should switch to some binary encoding to reduce the size um this is the other uh you know this is the other direction uh to explore uh this um yeah to explore the potential engine Epi Improvement but uh here uh the core principle uh behind the engine Epi is that uh it can uh it provides the communication interface between CL and El uh for instance uh it uh it kind of like encapsulates the complexity between different uh encodings that both layers use you know that you probably know that El uses rlp encoding CL uses access Z encoding and uh but they talk to each other why engine API and understand Json so this complexity is quite important to um to to get rid of uh unless we have El switched to ssz uh and there is there are proposals on that front uh and but that's kind of like quite hard to do because of the Legacy so um yeah I think that the this measurement and thinking about reducing the size of the payload by leveraging on the binary encoding yeah it's a good things to explore and thank you Mel um yeah uh I mean that's another important thought here that like the Json format in itself is not very effective uh here and uh yeah yeah I see it totally makes sense that like the engine runs over RPC when that was when when the clients already have the interface they can just create another um user s code path so it's it's uh uh pretty easy to implement uh folks do you have any more questions uh feel free to raise your hand um otherwise I want to uh come back to what we discussed before and uh just look forward to the future a bit uh you mentioned some things that you are looking for already can you maybe elaborate on that what uh what things are you most excited about what uh what do you maybe hope for looking working on in the future or uh or maybe other hand what you're scared of what what is your vision yeah um yeah thanks um for for the question so as I mentioned I'm looking forward to uh the further uh consensus uh protocol improvements uh one of them is a uh is is coming under the name of ssf which is single slot finality and uh there is the great work by um um EF and EF researchers and consensus ser research as um uh which is actually the um 3sf protocol there is a paper of this protocol uh which is three slot finality um and it's quite rigor uh it's quite well very well designed uh and uh um it's kind of like ready to there is already a spack that people started to work on uh for this new protocol so the basic idea is to reduce the time to finality which is very important for for many consumers of of ethereum protocol um for all Ops and uh for regular users um that's that's very that would be uh what excites me is like being a part of of of this effort uh so I'm looking forward to you know to to start involved into it uh it's it it it's going to be a quite long journey it's not like the next year we can shift this maybe two or three years uh to my understand standing and requires a decent amount of you know spec work design work uh and coordination as well uh there is one underlying problem uh uh there is one problem underlying this you know um the this new modern consensus protocol um and there are different approach to solve this the problem is basically uh if we want a fast finality we will have to um process and aggregate um much more signatures uh much more attestation signatures that uh we actually do now and uh there are different approach to this problem like employing a ZK circuit uh like doing something uh on the network some more optimal uh adastation aggregation on the network or basically sampling a subset of validators um for which will be assigned for certain slot um so there are different approach um to to this problem as well so yeah and it will be great to to explore um and to find a solution actually and yeah to deliver this um thing this massive thing um the other like uh more midterm stuff is uh uh one of the things I would like to take a look into is the confirmation rule uh we all know that uh um we have to wait for finality uh to to ensure that uh the block is not going to be reor uh from from from the chain that is finalized uh but uh we can do much better than that and uh actually wait for for a slot or two uh and under certain conditions where the network uh is fine and the um the the network synchron is not broken so we just assume that it's not broken you can actually confirm blocks faster um there is the work uh began by EF and consens researchers um uh that uh yeah there is a paper and there is the algorithm for this confirmation Rule and it requires outlining it into this spec and you know actually there is already a spec PR a PR to the spec with this change but it needs to to be finished uh and to to be caught up with the most recent uh changes uh from from the design part so that's that's kind of things that I'm looking into and yeah those are big uh and also I will be keep I will keep the help and supporting the uh thisp development um in the meantime um yeah thank you D you have a question I I live B and then if there's time I'll have my question okay that's fair B go ahead first hey thank you uh okay so my question is that uh well you've been in the space for a long time now like since the beginning and you probably like uh have knowledge of uh like most of what's happening right now but uh like for who are starting uh now or like just a couple of months uh there are a lot of areas uh in research and in development that are ongoing in parallel and uh like understanding all of them and keeping up with them it's like almost impossible uh but like it always feels like uh you're missing the some topic you're missing the hot thing that's happening so my question is basically like uh how much do you think it's necessary to keep up with all the uh things all the research all the new stuff that's happening or uh like how do you uh handle this situation yeah that's that's a great question um actually yeah since the beginning if we get go back to the beginning that was much easier because there were less um kind of like things um to to to get familiar with to start any core development and yeah but but now there are a lot of tracks of research which which is really awesome and uh obviously um one can can be expert in everything um at the same time so I would uh um I don't think it makes sense and I don't think it's really uh possible if you're trying to chase uh every every track of the research uh in the apperance space now so you can be um kind of like um successful in any of those right so you have to be you have to focus on something to to reach some uh success to reach some results and uh so my uh uh my kind of like uh approach to the is to try attempt at least to to follow what's uh what's uh like most important Direction and uh in in in your space for for instance I'm working on the consensus layer side I I really don't know what is happening on the execution layer side I mean like in terms of up updates in terms of like new proposals I don't follow them I just uh understand in general how the E work um uh how the outside Works how the client uh clients work uh and sometimes when I need uh like you know some um more deep understanding I just reach out to one of the client devs that I can reach out at this the moment time so this is this would be the best uh approach you can do so say I'm focused on the sales side so I can reach out to you all guys just to double check whether I'm not mistaken and or just to ask how does this thing work um yeah because I have some idea that might uh might be you know easy to do or might be hard to do because of of something that is of some specifics of the El design so um this is uh the kind of like the general approach but it is good to on the yeah and and in your area you just want to follow different proposals and understand what is happening there because sometimes it is important that uh you're working on on feature a and you want to understand what impact it has on feature B Because definitely obviously if you're working on uh some feature on the C side it can impact the other one so you don't want to break anything right so you just uh either reading the spec either reading the E research or talking to people um could be uh yeah would be the the way to go here so just uh um focus on on on some something that really excites you so what excites me is the consensus protocols really um and U reading papers reading like some side things and uh uh being uh involved in into the protocol development and you know following other cryptoeconomics stuff for instance I'm not an expert in cryptoeconomics I'm just reading the papers and asking um uh EF researchers uh who work on it uh asking some questions sometimes uh don't don't don't uh uh don't think that you're asking anything stupid so it's it's every every everyone uh especially regarding the their research and the area they experts in everyone is appreciated in any questions and everyone is happy to talk on the stuff that they work on uh so don't hesitate to ask questions that's the way to go in the decentralized development space thank you amazing thank you so much M yeah it's it's a really great uh very good question very good answer like in also like the way the theerum works that it it's modular and encapsulate complexity like that's that's what happens when people are experts in one area and it you know it's the same like agent API like just you know talking to different parts of the the client like say when you need to communicate your work uh anyway uh glor has a question yeah so thank you very much U my question is a little bit close to B Bing question then um I was I'm curious to know how you navigated or how you actually like started contributing to spec because you mention started in 2015 and as at that time you had uh you were not really into crypto so um and I'm sure that was still very hey at that time so how how was the thinking process like how did you manage to like start coming up with spec and how do you know this is the direction or this is what spec should be like and since a lot of things still pretty much that time or was it like starting something from scratch or probably I don't know there already something around that spe but then I think for most of us beginners it's pretty much difficult to think about the process of maybe even starting a spec or even contributing to an existing spec I believe it comes with some level of understanding of the protocol or so even know what is missing or what should be added and things like that so I'm sorry uh the audio was a bit um um a bit unstable uh and uh yeah just is the question about like um how the start to contribu in this back in terms of understanding of uh what to work on what is the kind of like relevant things to that you can contribute with to the spec yeah yes so still pretty much in that direction I just thinking like for somebody like you you mentioned you started in 2015 as and as at that time you were not into crypto so I was wondering how you were able to like find your way or navigate your way towards contributing to spec and creating IPS and things like that oh yeah okay okay yeah I I I I can describe my uh my way and just you know probably give some you know understanding if if I were joining now what I would probably do uh so my way was just basically uh I've been working on the it it it happened that I've been working on the El side in the past I've been working on the CL side as well uh so and I was just yes stumble up on the um the idea of the merge and turnning the etherum to proof of stake and uh yeah was it just excited me and uh um given the experience that I have working on both th I was like thinking that okay so I probably can do something um can contribute by you know by by can contribute some work uh to making the connec between these two uh things and yeah this is where I started from I actually try to you know to to think about this problem and uh try this and that and start prototyping so this is how it started basically the idea uh that was in the space the idea was really um kind of like the problem uh was not completely solved uh we had some ideas I started to explore started to explore from the ideas that already were in the space and then we started to to do something some engineering around you know prototyping the merge and all this things and then figuring out bit by bit how it the end design will look like so that was the um um there was the the work on the merge uh I think that which is a good show case on how to get involved into the spec development and you know the protocol development uh from from what I can say from now is that you actually uh first of all need to be familiar with the existing protocol and actually most of the uh problems most of the hot topics and most of the hot problems are published on E research um usually uh or just you know following the some other Ed like I don't know some sometimes people just posting sharing H and D with some design Solutions and uh uh yeah uh I would just follow I would probably follow this research and uh see the most important uh like like see the the um the most recent post and you know trying to understand what the problem they solve um and you know um trying to to and and finding something that really excites me and that I want to look into whether I'm an expert in or just you know the thing that excites me the most and I want to dive deeper into it and yeah that's that probably would be the good start starting point in the in the space and in the protocol development or the other approach would be you know to to to start from the engineering um from engineering from implementing some proposal and then slowly moving towards the spec um or the protocol design that also the viable part I think it's it's great part all right thank you very much thank you guys um we have a we still have enough time uh question from BMA hello good evening everyone can you hear me y yes than you okay so so um my question is more like um your view on okay I just wanted to know your view on this so it's more like um considering your work on the merge engine API like how do you see the future development in validator incentives and the station balancing like in terms of security needs of ethereum consensus layer so is the question about the then the valid economics and the security of the consens ler related other um okay so the question is like how do you see the F how do you see future development in validator incentives in terms of um balancing security security needs of ethereum consensus layer especially like in light of scalability challenges or other Layer Two Solutions I don't know if it makes if it makes sense is better yeah I see okay um um I I can try I I just can try to answer this question this just my basic uh Vision to that because I'm not much involved into the crypto economics part uh where actually the economic security is uh residing so I I I think that um uh one of the major step towards um the more flexible um uh approach to to managing Val balanis is the max effective balance increase stuff um and the next step I think there are some proposals on it research which are called rainbow staing uh and which were mentioned here uh also uh there is the um the orbit s ssf proposal um I can just pass the link into the chat I mean like this is something that um yeah the last this um orbit ssf is actually um or bit it's it's I don't know if it's uh yeah this is about this actually allows to to reduce the effective balances and have like one e staked um and yeah which enables um solar Stiers um like really with small amounts of e to to become a stickers and ethereum and stake on eum protocol so I think that that moving towards the solo sers friendliness is uh um the one of the things that uh the eum should do and also the other the other part of it was to yeah there is some there are some proposals to U change the issu issuance curve uh to make it also Sol Staker friendly uh which I think which I really appreciate this uh you know efforts on making this this ethereum more Sol friendly and yeah though I have said that I'm not that much into the crypto economics part so can't you know speak much on it um yeah thank you so much M and we have last four minutes so Dan need the promise me it's going to be short this time very short and it's in the same U topic uh do you expect with Max CB to have a good uh you know com reduction of the validator set as in numbers not in uh as in validator numbers not in validator weight uh and because I read in orbit that uh there are some ideas around incentivizing uh consolidation and uh since you worked on Maxi EIP do you expect to have a good consolidation after maxb yeah um we expect uh from the conversations with the staking polls with some steing PS we expect to see some good consolidation levels but uh nobody knows for sure so we'll see and I would say that yeah higher consolidation I mean like higher consolidation rates would mean that the stress on the network is going to be reduced which is great and also it kind of like makes it easier to do this single slot finality stuff uh by um by like eleviating the the size of the problem uh with the network aggregation station agregation in the networ do you know of of some actual measurements to incentivize uh consolidation or punish not consolidation and not not punishment that I think that that's not going to be implemented is it it's going to be left with the with the stakers to either consolidate or not yeah yeah yeah yeah but I think that I believe that it makes sense for up to a certain extent it makes sense to consolidate a stake if you're a huge big po there were some concerns about the slashing increased slashing risks like uh increased penalties from slashing if the consolidation rate is high uh but uh at some it's been kind of like shown uh by small uh by the analysis uh that uh some that consolidation rates at 128 or 256 e is kind of like not that much increasing the the size of those uh penalties that yeah that was related to the um slashing uh due to some you know um infrastructural problems like when you deploy to when you deploy the keys on two different machines this kind of stuff yeah so I think that makes sense for operators to consolidate um it's just easy and yeah considering that the stress in the network will increase uh so which is very important for the leness of of the main ad I think this is very good incentive also they have some some features like compounding uh withdrawal credential compounding credentials which will mean that these they will not have to reenter the balance into the um into the stake so they will just you know crew to the same balance and start working like start securing instantly securing the the main and that will work with all3 credentials and sending a message on the Bon chain or how how it do work actually how uh yeah so if you consolidate yeah if you consolidate you have to send a message that uh will run in protocol consolidation and target of the consolidation will switch to compound and credentials there is also a separate message that we should do compounding credentials um um so you can do it op in to to compounding and yeah op into in protocol consolidation rather than like reentering the other set great thank [Music] you thank you so much Mel um I'm sure there is 10 more questions I I I have some myself but we have to carry it up here because we already full hour and there are more meetings to attend so yeah thank you so much M for the AMA um yeah I appreciate all your answers all the time you dedicated and uh yeah we already discussed like folks if you have more questions I believe you can reach out to M and uh in Discord we can open a thread in uh in the fellowship Channel yeah uh yeah thank you so much it was great