EPF5 Project Presentations - Session One

my screen yeah yeah yeah we can see we can hear you all good yeah thank you so much for uh taking the first place man uh it's a it's a courage so we appreciate it and uh thanks everyone for coming it's our first round of the presentations L by chz are here so yeah uh feel free take it take it away man okay so let's gu start uh hi everyone this is J visa and this is my U project proposal for S I want to do uh s project to enhan abilities in gas and is typically basically for ADV Tre and transation query okay so uh this is my agenda so first one is modification and the second one is challenges and third and four one is project and lo so let's get started with some modification and modification let's say something about why uh current only the CH transition or Dev blockes are available in gas to features in executions of a transition and uh I think some some people are also familiar with eum when your departure transition to feature some internal transition for one transition especially this is useful for def security audience or us an that they want to to me someone to Fe more details about a transation but since IPC has some limitation limit uh so first is this IPC will will rely on on a C note but the Cur on C node for the gas Manet is 18 T this is a lot of disk usage I think not every uh user or every cons consumer can can handle s large large size of disc and the second one is uh this IPC will rely will repace uh some formal transitions to to reconstruct stb and the S repli the transition for Set stb uh set well require uh actual CPU and memory sources um so for this limitations since debure transition for gas is not very reliable and might use more resources but the guas is mainly adaptive by other chance such as optimistic uh or B or something l two CH or such as BMB smart chain and other chains so if we can adapt uh if if if we can we can set up chest for gas in a low cost and or as L to chain can also benefit from this uh from this p and for the second one about um current the wet of app Prof need to record each transition which ini by S iust said uh is by local story local store in uh in in local St Chrome storage or sa it into a Cloud Server in order say can they can say in order to enable uses to F their transition piure or check the transition Studios such as they need to know if this transition is that or not or and also needed to check sance but I think this is a more common requirement uh and then and then each white do not need to uh individually imper them and so if we can imp a a more a more natural IPI to perfect such uh such features it will be more standardized and uh and block the wall or dep per can impermanent more convenient and more useful so uh here's my modification for how uh for for the CH place or just Brock RPC we can generate CH results along with Brock um Brock new blocker minor and S results into local DB maybe we can use go first DB direct or any or something else then C can direct results from an DB and no need to rep anymore so this is more fast and the more resource incentive and for et get transition by SN IC we can build on index for each transition I think this is similar to the transition look up uh so uh and since API also need to consider about paining transition for for s for the pain as this they are not ctive uh with we may need to consider more about them uh yeah and this is the challenges I think for the first one CH and chock is if a chain is we need to update or delet all the all the new uh all new blocks and s s new blocks in DB so we need to uh we need more more concern about and second one is performance in pension if the transition exing is too large such as this transition this transition is very large it's about 10 G bet more so if if some like transition we need to take more about it course it get transition by not IC we need to consider more about data consistence between de is under L and DB because we need uh we have two uh two two DB St there separat okay so uh so below is my project of F this is uh first one is I need to add the CH name space for in go and second and third one is uh is M Implement Source IPC and the fourth one I think also need to add trans to exclusions so C can also imp St and IPC IPC but for CH IPC may be different CL such as b or they might be impl so may be um maybe maybe two two uh maybe have two more with gr okay so uh below is my load map so first month so first month I need to complete the research for this project including the Des do and the to speci size format of the request as response also the request uh perment validation and the DP data structure and asense and the second s mon I uh is the time for coding uh we need to improve Sour App independent and the M four and the M five is beachmark and faes uh after after month five I can finally releas the final fishion and also add document and test Cas for those uh okay thank you this is my proposal is the question uh maybe you can live thank you yeah awesome thank you very much uh yeah it was great uh anyone has any questions comments anybody yeah okay um yeah I think I think it was great thank you so much J Visa yeah great presentation and overview yeah I think we can we can move on if there are no questions comments free to ask thank you yeah thank you so much again awesome okay [Music] okay we will next one Maxim are you here are you ready yes I'm here uh yeah also I think that someone else is going to share his screen K if you are you here yeah yeah see my screen yeah yeah all right uh awesome yeah go ahead okay yeah let's start um yeah so our project is uh a custom Li P2P library for prism uh yeah it's mentored by uh Manu LP and like we are like four fellows working on this project Rich maxdale me and Rose yeah so our primary motivation is uh building an in-house custom implementation and potentially replace uh most of the components that uh that currently uh currently dependent on Li P2P um and like we are doing this for prism client right now um yeah also like currently most of the clients use Li p uh there are like multiple variants of liop uh like in all kinds of language like go JavaScript Java even Nim and all and like are kind of dependent on that um so this project would enable the prison team to have uh an independent uh an independent Le P2 Library uh that can act as a like integral component and like not depend on uh some third party to maintain that this will also eliminate a lot of redundant components since Li P2P is like a generalized library for peer-to-peer communication a lot of components are not actively used in most of the CL clents so yeah uh this will also eliminate a lot of this redundant components uh and like also not compromise uh on any kind of performance issues and and finally why not um this will help me and other fellows to develop a deeper understanding of of the networking layer and understanding of Li P2P yes Max can take one now so maybe I can give you some more context about Li P2P so Li P2P is a networking framework it it aim to to help developer to create P2P networks so it provides lot of building blocks to do so like different transport layers stream multiplexers and so on contrary to Def P2P it was not designed to to to build the ethereum but uh it's a more General use case and it's owned developed and maintained by protocol labs and it provides multiple implementation in different language and their uh each implementation is interoperable with other one and it's also used in every consensus Cent uh okay so uh now a brief walk through of the components of the P2P Network which are as a part of L P2P and which we would be implementing as part for the in-house implementation for prism so majorly there is a transport module handshaking module protocol negotiation multiplexing Discovery and messaging and the right side image shows what are the uh features in lip P2P and a filtration of what is used by Prism and what is not uh next slide please so yeah first one is the transport module which can be regarded just as a road or a bridge connecting two peers on which data is exchanged so there are several internet communication protocols there are we sockets web RTC also used apart from TCP IP or quick but as part of the project we would mainly be focusing on TCP and quick since these are what is specified by the P2P spec um there is dialing which is the process of opening and outgoing connection to a listening peer and listening which allows to accept incoming connections from other peers so using whatever facilities provided by the transport implementation uh yeah uh one of the components which we would be implementing is multi- addressing also as a part of the transport module and the next one is handshake so before two peers can transmit data the communication Channel they establish needs to be secured and this is what is provided by a secure Channel handshake and the protocol we would be uh the protocol which does this is noise and this is completely a pro uh complete library or a codependency in itself so this is not something which we would be implementing but using as it is from the already implemented version and why do we need handshake is basically because we need to ensure that the peer which we are talking with is really who he is claiming to be and there is confidentiality of data so that there's no e dropping or such things and the integrity and reputation is avoided next slide please yeah the next one is protocol negotiation so uh this is basically when uh a PE is dialing to initiate a new connection the protocol ID which basically specifies the details of the transport protocol in use is sent along with uh the stream connection request and other peers to which the connection is initiated just check the compatibility if they can accept the connection or not so as part of this module we would be working with multistream select or multi- select which are uh the P2P which are a part of P2P spe and yeah if the listening peer uh uh the dialing peer sends the protocol handles and all the details and if the listening peer uh uh does not support the requested protocol it will end the stream and if the the protocol is supported the uh eing back of the protocol ID would be done uh so this is what needs to be implemented as part of the module uh next is uh Stream multiplexing So it allows to exchange different types of data within the same connection so there are uh there uh so how this helps is a single stream would block applications on one another as uh one application would need to wait for another to finish utilizing the connection before being able to send and receive its own messages so multiplexing allows creating of something like virtual connections and this allows to send data maybe parall so that there's no blockings and it's it's like having many lanes on a highway so many vehicles can travel at the same time just for an analogy and as part of this mlex and YX are something which are specified by the P2P spec and we would be implementing for the pris version next is peer discovery which is uh as the name suggest identifying the peers with which the communication needs to be done and the protocol which is specified by the P2P specs or is used by Prism is dis V5 but uh it is something which is not a part of lip P2P but uh de P2P I suppose and is out of the scope of this project so this is also something which would be used as it is I guess next is pups up or the messaging so it is it is a scheme for allowing the peers to receive messages of a specific type just like if we have a chat application where where we are just subscribing to let's say our game topic and we are only receiving the messages of that type so it is analogical to that so there are several implementations which involve broadcasting or bootstrapping notes but uh as part of our project we would be following the gossip scheme uh so yeah of in this there are several methods in which there is subscribing to full messages or only metadata connection this is in internally for the these are the parts of the internal implementations of gosip and yeah it helps with reducing the number of duplicates that the messages the peer is receiving so yeah these are majorly the components which we would be going through uh next Rose can take over um hi so moving on to the road map for our project so like for the first month our first step is to thoroughly understand the specifications outlined in the read file of the P2P interface from the ethereum consensus specs so like this involves a detail an analysis of the components involved in the lip P2P networking within the ethereum beacon following the second month we'll use existing lip p2b implementations as references to guide our development and uh we'll Implement lip B2B for uh the prism so like our Focus will be on creating a package that includes only the necessary components as the existing go implementation of the lip2p library includes many components that pris does not use so like for the then moving on to the third third month we'll develop a comprehensive testing plan to ensure the reliability of an implementation so this will include uh end to test unit test and the performance benchmarks so like we'll refer to the pris documentation for the guid lines and moving on to the fourth month uh once our implementation is Thoroughly tested we'll replace the goal to be implementation in the pris beacon node with a new in-house version and finally the fifth month we'll compare the networking performance of The Beacon node using the external goal l2p implementation and our new hanous implementation on the holisky testet so yeah like we are open to the questions now okay guys thank you very much um yeah it's been it's been like 10 minutes so we let's let's see let's question CH did you have any questions um yeah uh I I just wanted to say folks a great presentation thank you so much uh thank you so much first of all um yeah I think it's great because also we know like protocol laps kind of uh spinning down their their uh development po so now having your own Li which is not uh maintained by them is very useful uh excited about the project thank you so much yeah I just wanted to say that like in these presentations like uh you don't have to go to very details of specification of the existing protocol or like uh go too much into the weeds because we have we have a limited time uh just wanted to highlight that but yeah so if there are any questions comments uh CH you had your hand up uh so I was just wondering if there was any initial analyses done uh for uh for comparing What U um you know a inhouse development uh would like bring to the table also like I think um I so I also have a follow-up doubt on that um which is uh like would it like you know would it make more sense to uh take the existing implementation and kick out or why we are not going for that kind of a strategy did that me sense yeah so like why to start from scratch and not to stri yeah exactly yeah yeah yeah uh guys here I can I can answer for that uh so yeah the idea is is not especially to write from scratch but the current P2P from protocol lab um go P2P is very huge there is a lot of function and modules we don't need and we don't use uh so we what we want it is a slim down version of P2P really just uh which fits our ethereum needs so of course if we can take um given function from the protocol lab go P2P implementation and reuse it uh in our own implementation is perfectly okay we don't have to reimplement everything from scetch okay that makes sense yeah uh thank you so much Manu for answering and thank you so much for being here for mentoring it's yeah really great to see some mentors here thanks a lot you're welome yeah uh yeah thank you so much the whole team uh yeah it's great to see a team effort and uh quite an important yeah uh go ATK lights of code yeah I think it's that's pretty unnecessary complexity for etherum so better to um uh take away some dependencies um I see Richa is next sign up but I guess this is was the presentation of the previous team so uh we should move on to the next one uh Rory if correct me if I'm wrong but I feel we can move on ready guys yeah I think I'll go ahead and get rid my screen ready awesome thank you yay see my screen go ahead yeah awesome okay cool yeah so uh this uh for this uh project proposal will be uh uh graning support and documentation so as some of you may may or may not know I'm fairly uh you know new when it comes to developing so I thought this would be the best way for me to contribute uh to the uh to the uh uh protocol but um this project is basically focused on building out a more comprehensive support and documentation book for grandine through a lot of research and trial and error um and then the uh the motivation for this really is you know grandine is the newest consensus of your client but the documentation is on the lighter side and I think it's important to have more comprehensive documentation around grandine and its capabilities um and I ALS I think this is important because it'll help attract new users to the client which would increase client diversity among C clients um and this to me is also just really a perfect opportunity to kind of get in on the almost ground ground um ground level because it's so new there's a lot of bugs to be worked with and Kinks to be us figured out so for me helping to do this I think would make a lot of users they're uh going to use gring in the future much more easier and have a much more easier time to just really work with the uh with the client um so yeah so the future State really is uh currently I have um some several sections I think could be useful for for grandine um these are the following areas I like to be addressed but I think it's likely to change as I begin to make my way deeper into grandine um I'm taking a lot of inspiration from the lighthouse and prism documentation books so whil it's not everything that they have will be applicable to grandine I think this is a good base to work from and really a lot of it does come down to I think what users would really like to see where the interests are are and uh what um you know what the what the motivation is for people wanting to use grandine in the first place um so I imagine that this as I continue to go down uh deeper deeper into this that I will come across other bugs or issues that may also need to be documented that were never addressed in the first place um so whatever I think whatever Sally is in the team need help with the most that is kind of where I begin to to dedicate my time but ultimately really it's just a matter of presenting giving this this documentation book as much information as possible that anybody could pick it up as just as easily and you know begin running with it um as far as a road map you know I kind of broken it down to like have the insulation completed by the end of this month have e talker integration by end of August and it goes go on so on and so forth and then for any other section are identified you know have them updated before before Devcon 7 basically um but yeah so the other thing so as I kind of mentioned earlier you know client diversity is really important uh amongst elcl clients and so this is from client diversity. org granden because it's fairly new you know doesn't have as much market share as the others I think we're it's by granding coming on board it's helping to offer uses more diversity but um there's you know I think the missing aspect of this really just comes down to the documentation piece um so even when I first started looking at grandin's um information it just wasn't that too much information to find you really have to do a lot of your own research trial and error and debugging U which is a lot of fun of course but you know I think if they want to really make an impression within the community uh and in users within ethereum that there needs to be a much more stronger effort for uh for documentation so again this kind of all comes back to my motivation on what why I want to want to work on this um for for the uh for the project and then this was uh actually a media and blog post that Sally is had posted back in March I believe this was their first blog post when grandine basically you know just went um was open source so again even for them you know this client diversity is a big is a big uh you know goal for them um and they have a lot of other goals to go that they want to achieve within the next couple of media goals with the next couple of months to to a year um but this is the big thing and so again I think just from experience working e Global and seeing hackers work on other uh Partners in their documentation or lack thereof the more documentation that there is the better um and then selfishly again this is just my opportunity to really make sure that I am understanding what is going on at the at the protocol level um and then I really do want to get more exposure to uh to something just kind of all as much as possible and I think grandine offers that opportunity for for me and anybody else that wants to join uh to to do that at the ground level so um this is my uh presentation any questions aome thank you very much any questions any comments um yeah thank you so much is it really great I mean I really appreciate your work like the documentation is something that I was starting with in other projects and and you know documentation is Heth of the usability of the of the system like especially uh gring starting go soon uh recently needs there's there a lot of things to to document and it's missing in all of the these like tutorials for people and so on uh I think it's important for them to have a really user friendly dogs um also we started the EPF Wiki uh without Grand and really in mind I think it's mentioned there but also there could be some more information on it um uh Missing yeah aome cheers yeah uh thanks s guys any any comments questions last last chance before we move on okay we get red to happy next are we are we ready hey happy no if red too happy is not here there is Rose uh Rose did you already present with the team or uh do you have pration on your own um yeah just if there is a team presentation you there should be just one person sending to present it's always one more project or one more team um yeah happy and Rose if you guys are here please yourself known uh otherwise there is CA yeah I think Rose was in the L PDP uh presentation as well so and I don't see rat in here so I think we'll move on to cat yet yeah yeah so got if you already okay yeah I'm ready just sharing my screen can you hear me yeah yeah all good um yeah awesome yeah I thought it's 10 project but but now we we are actually on time I think that's great okay screen yep perod metric yeah so this is my project peras metrics um uh so my motivation uh I got my motivation during the dev connect Istanbul where I um I was um I presented on many um talks and panels about scaling ethereum what current issues we have with it and uh so um and there was a secret weapon there so um uh then I started to um apply this knowledge uh participating in scaling heatons um um in particular uh I I took part in the circuit breaker uh working closely with avail team and aail is the data availability project uh so um I I just dived into it uh that's why I chose this um topic um during my fellowship uh I decided to focus on data um I won't go um into the um technical um moments you know everything about it so just the main uh issues uh is um that we can solve through P do is increasing the throughput uh lowering the resource requirements uh it's kind of the main problems so currently um pias um pias has three stages uh um so uh currently we have uh blobs already implemented uh then goes First Dimension per perod do and then second dimension peras um the current state is we are on the one dimension perod as so we work with Columns of data um and um when I joined the program uh I could see that um the clients uh consens consensus clients are going to test um the implementation uh on using CTO uh mostly and U on the deet one currently deut 2 so um I uh I choose to focus on metrics uh because uh this implementation has a set of metrics uh more than 20 for now and probably it will be more uh these are the examples of metrics like total count of reconstructed columns and Etc so my project is all about pus metrics um I will start from analysis uh what metrics we have um what what metrics we need um then I'm going to visualize uh some of these metrics using grafana and probably if uh we decide that we need um API for some metrics um uh so I hope we will discuss it with the clients um and uh probably uh I will take part in the implementation of API and having API um I will have an opportunity to build some of the metrics uh on Dora and uh yeah um though Mario uh gave an advice not to spread over the topics but I would like to collaborate and to contribute into Teo metrics so um I'm going to build metrics for Teo and I also um going to collaborate with research team and um consensus client teams uh all all about metrics uh um the results uh I have the issues I have with it uh so probably we will find something interesting because it's at the very beginning of testing so um yeah I hope it will be useful uh I'm I also going to collaborate with uh fellows who work on gring they are Implement peras part um so maybe testing or the part of metrics um the the way we can collaborate and yeah I've already mentioned u c clients and research teams and uh my mentors are pro are mostly devops team so I work uh closely with Barnabas and um uh the the whole team supports me as well thank you and um I work also with MRI from te Team all about um metrics uh implementation on te and probably if I have um any questions uh about piras itself I hope danr will support me and I also can see Manu here he's active about pus testing as well so um Manu if you have um any advice you can DM me uh I'm not sure we have time for it right now but yeah I would love to have some feedback or ideas for testing um concerning metrics thank you awesome thank you so much um yeah awesome thanks guys any comments questions yeah the monitoring the metrics are are great um so also a very important part so looking forward to that and uh yeah if there are no more comments questions we have yeah thank you let's look at we have uh yeah yeah let me know if you need to connect with Manu um and next is a Caleb hey uh yeah are really can you share your screen yeah okay yeah uh we get it awesome to can you see my screen yep go ahead yeah okay hi everyone I'm Caleb so I'll be working on um EIP 7732 implementation in nimos basically EIP 7732 has to do with um ensuring proposal Builder separation so my motivation for the project is that currently about um about 90% of um blog proposers Outsource their construction of the of their blocks to external Builders and by doing so they able to like maximize um maximize extractable value as um those block as those Builders have um specialized algorithms for like ordering transactions and stuff like that um by doing so also um it enables validators to be able to like run consumer grade software without like bothering about um um building the blocks the execution pillows so this is just like an overview of the current landscape so in the current landscape um the validator the validator has been chosing to propose a block that's called The Proposal um runs an external software third part third party software the most common one right now is me boost by flash Bo by flash BS so um there is a need for a third party which acts as The Trusted system then both the builders and the validators interact through the relay so the whole purpose of me boost is to like of epbs sorry is to like abstract the way this um this um the abstract the way the relay the relay and create like a trustless system so basically like yvs um security um security wise ensures that um block construction follows the same security rules as the rest of the network um decentralization it reduces Reliance on centralized release as we have about only like fewu Release Control controlling about the majority of the market then um it it helps um M distribution to be like um transparent and Equitable and it makes it accessible for almost everyone and it creates a fair fair market so what um epbs aims to do is like abstract the way the whole purpose of the relay and create a trust trustless system as I said so it just involves like the consensus layer it does involves implementing um proposal Builder separation at the protocol level so yeah currently different designs of epbs that that been researched but what I'll be working on specifically is the slot auction epbs model and in this model um from this diagram basically in the purple face the the block proposal um the block proposal the block proposal proposes is become block then the second phase we have the execution payload from the external Builders basically so we have like different observers um the testers the Builder observers that like that helps to ensure that this system the system um Works according to like the set down R so basically n slot we have a proposal block and a builder block Each of which receive attestations and these blocks are bonded together for like the final for the final block that is um proposed so like a as I said um it also like um so the aims of this model is basically like create a system where there like unconditional payments to the builders then creates like a trust trustless system where we have um where all parties have to play by the rules set by the protocol then we have we are decoupling the execution validation from the consensus validation basically which helps to improve decentralization also in a way so the main participants we have the proposers we have the validators we have the builders we have the PTC the PTC is like is the new innovation in the system basically this are validators that helps to like attest that the Builder actually like revealed the execution payload timely the specifications I be these are specifications all the specifications actually um they've been like designed already by the EIP documents so has been specified already basically so that will be following this pattern then this will be my my road map currently I'm understanding the nus the nus architecture I have a following week out e all right seems like we've lost Caleb um so it looks like maybe he just rejoined Caleb are you back in Action here yeah sorry cool sorry do you mind that again oh I it was just my problem uh yeah go ahead share share your screen please we cannot see you oh sorry can you see my [Music] screen uh hi can I see my screen no we just see the same screen that you had up before yeah now it works yeah oh sorry hey sorry I everyone I'm K well let's I don't think we need to start all the way over again we got most okay yeah just continue just just finish it with the road map and uh yeah yeah yeah just the just the end basically oh okay yeah so the road map um this I'll be following this road map then challenges that I basically have is that I am new to the I'm new to n so basically I've been trying to understand the name language and all um then trying to understand the name code base my mentor has been helping me T then and then um creating a creating trying to like look for trying to integrate it into the current um name code base so that it works function properly then my goal be to have the working and tested implementation of epbs before before def con s basically so that would you yeah would you go back to your road map and talk a little bit about your timeline I am curious to hear a little bit more about how you plan to implement this it seems like a big project to do so quickly so I'm curious so I'm Bally taking it um um I don't know by weekly to two weeks um since it already has like an implemented spec already so basically it's just like looking for the appropriate um it's going to probably be like a plug and play for most Parts I think it's going to probably be like a plug and play for most parts so it's just um taking those um specific design pieces and integrating it into the nimus SCH be basically so I'm just basically like following the specified specs already that already in the hiip basically so like implement this Implement that implement this Implement that and write test for them cool and uh who are you working with in terms of mentorship T from yeah um and no other follows um okay um kir K is working on epbs to but working on it in prison not on nimos yeah right right yeah like for example because in prism the epvs was an effort which took like longer than EPF and there were multiple people working on it so also Nim I can imagine at the scope even if it might seem like all specified there is still a lot of uh things to figure out and uh and uh it might be a bigger scope imagine but like you know if definitely like if you are uh confident to do this you should go ahead and uh even if you do just off the work uh it's a great contribution to members yeah I agree I think if I were you especially after the first couple of weeks of actually doing some of the implementations and looking into Nimbus client uh maybe revisiting your your road map and seeing if there aren't some uh you know more like seeing if if you feel like the timeline is going to change at all and and sort of keeping that a little bit more up to date as you uh progress through the through the program yeah yeah but thanks a lot Caleb um yeah uh we should like that it's it's a of work of Courage uh I think it's great that you're deing this uh any any more questions comments on Caleb guys anyone yeah thanks for the presentation yeah we have a last one signed up here hang langang but we also skipped the red too happy didn't yeah go ahead hang GL if you can share your screen and yeah okay yeah aome uh do you guys see my screen yeah all good go ahead okay okay so hi everyone so um for my project proposal is uh to improve um P implementation and cring and so why choose a p in the first place so so uh because p is a I believe that P is a part toward the full D because u in order to scale the etherum uh uh we cannot uh rely on the um no storing all all the data so it currently around like one and a half to two terab to to store the data and for the second is uh involve many interesting component like uh gosip sa and um kcg commitment cryptography so before I joined the fellowship I interested in cryptography and specifically on the um Z Cru and sure that after the uh Fellowship I we um more worly on the cryptography part and it also um uh include in the Petron upgrade uh Network upgrade so it it it has some like a specific deadlines and it it is also an interactive development which it have a byly breakout room on uh every Tuesdays and and so why we choose a grin to work on so grin is a r implementation of consensus layer so it is R using like a memory set and it it offer like a C++ performance and also we I might say if a bit familiar with the R so it it is quite challenging for you that is like don't know don't understand uh I done learn Ras before so uh that's why it is a a good option for us and also um it actually uh there are other the client implementation uh that risen in like T script or uh go that also uh I famar but uh see like grin also uh have a small team like only um three to for contributor so it need uh more more support on more help on the implementation that's why we choose ctin and on the road map so uh so first um we have to B part the LI to peer from light uh from Lighthouse so um this part a uh rahu from uh uh my my fellow also uh did Implement at that point and currently we we we are doing uh update uh Pedas implementation based on the latest PCH so we currently uh uh working on that and also we at the same time we uh we try to test the interop with other clients uh so actually the road map is uh it's not like a straightforward we we have to like uh spend a lot of time on the in and a testing because uh when we uh first start to test the work chain we see like a lot of uh bu and a lot of so we have to move back and forth back and forth so the road map is subject to change the future and but the goal is uh is to make sure that uh we uh compliant on the pp uh and also we ensure that uh uh the client with inter with uh other Implement uh client implementation and also ensure that the performance and security is uh meor and what the challeng is that uh like Rory Implement uh mentions uh previously on his uh proposal if grin is because a grin it just uh open soft uh like a few months ago so uh it doesn't have have uh uh a lot of resource and document so it quite uh hard for like a contributor external contributor to uh contribute into the project it has a limiting on the documentation and also we uh new to the uh client testing and debuging so it is quite hard for us like do like an interop thing so we need to learn Lear on that to identify what what happened and what's wrong with uh like the lochain something like that so and also the Benchmark and the metric to ensure like the performance and the Securities of the our implementation so he is the uh me hling and uh rahu a my collaborator and with support from Salo uh from gr grin team and yes that's all thank you thank you so much awesome yeah uh a lot of work on grandine they need they need help they need contributors I'm glad to see all of this support very well yeah um case any question uh on this anything you'd like to comment or question on yeah thanks all for the presentation I think it's great um and uh yeah we have we are doing pretty well on time but I think we are out of presenters for today uh is there anyone here who have not present yet and would like to uh was to have you signed up who I didn't see here yeah Derek I am able to present I was just holding off not sure if my network is great there's no one else I'm sorry can hear you oh maybe that's I was saying I I am able to present um but I'm not sure if my network or microphone is good where I am right now uh if I should hold off but if there's enough time I can go ahead have you been have you signed up for for today or uh not today I didn't if I was going to be able to given Network situations but I seem to be luy correct yeah I would I would I would leave it for the next one then uh since you don't have the I hear noise in your mic so I think it's not for sure then uh just sign up for the next one yeah and yeah everyone who's here and hav't presented yet yeah awesome uh so yeah everyone who haven't presented yet please sign up for the next one I will open the issue uh soon um so this week please sign up for for the next week's presentation on Tuesday and I believe it will be the maybe even the last round that we need because now we finished in an hour uh which is which is pretty good um yeah awesome thanks so much everyone I think I think that's it then um we saw many great presentations I'm really excited uh it looks uh I'm I'm always personally surprised about the the quality of work uh for um that you were able to put together the research that you did in just like four or five weeks uh yeah it's really great um Rory yeah of course please uh send send the pr as well if that you presented the project doesn't mean that uh you don't have to have the project proposal or anything like that the project proposal is what actually defines the the project initial presentation and the final presentation uh and the project uh project um uh uh proposal markdown document in the repo is what defines uh which you did in your uh in the EPF so please uh uh write it down yeah yeah using the template you can uh you can write down the project uh so yeah open PR for that if you have any questions feel free to reach out uh feel free to open a draft PR and ping me for a review if you'd like to if you'd like some feedback yeah and again huge thanks for all the presenters today um yeah uh the Trail Blazer who managed to manag to uh start presentations today I I really appreciate that respect that um