EPF5 Project Presentations - Session 2.2

um so uh firstly I want I will uh just briefly mention that uh uh why uh maxb is important because uh this uh constant has been set up um from from the beginning of the uh uh the beacon chain uh from the face uh zero uh and till the um Danon uh upgrade uh is still uh kind of being you uh used and also being fixed to 32 uh is uh right now um this has a um I mean the the the capping of this uh constant has been significantly uh increase uh the the valid data set uh the size of the valid data uh is is very large right now um but we uh have a imbalanced uh node uh s uh connected so uh so this leads to the sustainability uh and the question you the EAS Network and also bring a lot of pressure particularly the network pressure like for the gossip and also uh will uh causing some challenges uh to GA the finality there a couple of instance happened in the in the history because of the large validator size uh so the idea is um uh is using this EIP uh 7251 uh to increase the maxb from 32 East to uh 20 48 uh years uh and this also bring the uh compound uh compound rewards benefit and encourage the Solo solo sters so there there are many kind of benefit uh will come over but also uh bring some challenges which is the uh six features has been listed uh in the uh in the in the EIP uh so I will um um so I will um um probably um just Skip and then com to uh what we going to uh what we what I want to focus on so uh without uh this uh the implementation of this 72 uh uh 51 uh which is the current uh uh uh story uh so uh for stum uh if they want to set up a validator um in the Bon chain uh they have to deposit 32 years and then being to uh to be activated uh and the currently there is only one uh variable called the max effective uh balance being set up in32 is kept uh so any kind of rewards being received uh will automatically uh pushed um uh to the partial withraw uh credentials uh so the the validator they cannot have more than uh this number of uh years to be Stak if they have more uh they have to uh accumulate another 32 years to come up with another valid dator so that is the reason why um we have a small relatively small number of uh node operators but we have a very large of number of uh Val uh validators uh in the uh in the in the Bon chain uh uh currently is there about 1 million um validators uh in the in the beacon chain uh and uh some of the study being studied uh already um from the testing team that if we have about 1.1 million uh validators uh is going to U make the um make the finality uh consensus uh to be very difficult the the whole network could be uh possible to uh to crash uh so that is the reason why we uh want to increase uh this uh uh this constant uh to be a relatively larger number but still uh require that uh the the minimal activate activate balance to be 32 e to maintain the same uh security uh uh level um but by bring these uh variables uh it bring uh a few other uh use experience and also the uh the scenario in the complexity into uh into into this case uh so the for example the first one is um um um the effective balance um um has been in increased uh uh so how the us are going to managing and also the the uh either the solo or or professional uh stakers uh they going to decide um to um to to maintain this active balance uh even though they can receive the comound uh comound uh rewards uh then they they don't need to uh wait uh for the 32 uh years uh and then set up not valid they can just continually to have so the so the efficiency has been uh increased significantly but this also causing uh other issues U for example um and the the first one is the the the slash penalty uh risk has also been kind of a proportional uh increased um because the current immediately uh Slash penalty is one of 132 uh if the maxb has increased uh we need to time that by the number of the the the larg E being being Stak so the potential loss can be can be higher uh so there's one research uh which is one one feature is to talking about how we're going to managing uh this uh this immediate SL penalty uh another one is the customer saing and this customer saing is for user to set up um based on uh uh uh many reasons for example whether they want to U maintain their uh um um asset Financial efficiency uh they want to have the flexibility or they have a geographical geographical uh tax uh reasons so they have to set up a kind of customer uh cing this is currently not available uh in the uh in the in the spec uh so this is something you we have to care and also whether this will impact to the uh security uh model or not that's another question we need to J um by by by having this and uh the protocol also designed optional um approach which is to allow the the valid dator to be Consolidated uh so we can have George uh can can we move from like general info about the maxb which is like you know the known specs and so on more to like what are you exactly working on just so you can yeah walk us through yeah okay yeah so talk about the pathway uh so the pathway is uh uh there there six feature has already um been clearly uh declared uh and I already uh verify check and also study uh four of them uh and I'm going to work on the the the rest the two uh so if you look at the the survey have been done over here U for the features and by talking about the EIP uh some of them they already been specifically focus and mentioned uh and for the electure specs uh four of the feature also being be mentioned and the test case is already come up with um but the topic I'm going to uh working working on is not uh is not been written into the spec uh yet so I have already contributed to some of the uh did some of the PO request to the EIP uh to to this particular EIP is currently waiting for uh uh to be to be approved uh and for the specs I will also contribute p and then I will complete and the security and other uh test in the rest uh uh uh time of this uh this program uh so uh who going to work with uh so I think the people who are currently working on this uh uh this EIP uh I will uh talking to them uh and also Consulting uh from from them I will particular working with the uh the testers for the for the executive uh execution layer and also for the uh uh the consensus uh uh there uh and then and to uh make sure that uh the CIP uh can be uh delivered uh before the upgrade as expected upgrade time so Maria I I think I can uh stop over here and I think I spend a lot of time okay awesome yeah thanks a lot um yeah I think it's great I think yeah maxb is important uh uh than for the presentation yeah we got few more in the list so let's uh let's get it going um ab ab Manu heting if you are with us yeah maybe uh are you are we here I can see your screen but can hear you how about now can you hear me now yeah yeah now Perfect all right awesome guys okay so today I'll presenting a cross chain attestation for tested execution environments so the first question arises what are basically the is so they they can be understood as sort of like black SPX units that secure any computation that you throw at it meaning as a client you encrypt your data you send it to this tested execution in environment blackbox now this blackbox is going to process it and then in return it is going to give you back the encrypted output that only you can see and how can you trust them that like how we establish this anchor of trust that hey I'm sending this encrypted data to this sort of uh blackbox so this whole process is called as attestation so basically there are a bunch of certificates to prove that the current execution environment and current execution environment meaning the software or the binary which is actually running inside this Enclave is something which is uncompromised or has has not been altered with so from this figure you can understood it as like if we have to host host X and Y and inside that host there is a certain like a specific area of trusted execution where you send transactions and they get executed but to attest these enclaved area what to host or any sort of two environments can do is they they make a process of attestation in this attestation process so there is some some sort of quoting is done this process is called as quote Enclave so in which uh they take sort of like a hashed encrypted screenshot of their whole TCB their platform their boot trapping code uh and encryption Keys as well and this data is encrypted and this encrypted data goes through this Intel attestations service called as IAS and this data is actually verified by this service and said hey actually this is running a binary that you ask for so if you are running an ethereum client or or if you are running a smart contract inside that you can actually check hey can you give me attestation that I'm dealing with the right binary or not now how blockchains meet tees so basically what happens is inside blockchain networks these tees works as Pro like Processing Unit meaning they execute stuff so when you input the transaction they reach to the safe enclave and then and over there they are processed and the state is generated and that state is basically outputed but here the state mutation is also encrypted meaning there is a mechanism behind where for every let's a smart contract a sort of this symmetry key is generated using which the state is only decrypted once it is inside the enclave and no other process even the host process no matter what the Privileges that process have cannot look through this data and after The Enclave is done processing that mutated state is made persisted inside uh the unencrypted area or let's say area outside of enclave and this encryp state can rest there as well so we have a a few examples live who are actually running this like we have uh secret Network and OSIS so these are just base chains uh in which validators are running PE nodes meaning every validator node inside secret Network needs to run this sort of te unit and transactions over there are encrypted and process only inside those and enclaves and like we discussed earlier all those states are encrypted if they are outside the enclave and similarly OSS the network is is sort of like a bit more modular in that sense that they have these par time units which are like an an isolation of consensus client and execution client where execution client is running the trusted unit or enclaves and the state is basically again encrypted so the goal of of my EPF protocol is is basically I imagine a world where there is a cross chain application data and compute which are trusting each other and in this case that data and compute is actually originated inside those te networks but the problem comes when different te networks are running and you need to have some sort of composability so but the problem is those networks or those chains they are running let's say different consensus mechanisms different execution in environment and different ways possible State decimation but what we really imagine or what we really want is a te data and computation in which on one chain Enclave present there can send some data to other chains enclave and this Pro process can be trusted like there should be a base trust that can be input on that and for this project we are going to take uh chains which run solidity code and we make sure that these chains running those entities should be able to bridge data and compute across them so in a way actually it's your application which is which is going to have this uh interc composability in intact so this whole process can be understood in like this uh on left and right we have a secret Network on right we have OS chain and there is some confidential data flowing across okay now how can I be so sure that this confidential data I can put my faith in like if it's valid if it is following the rules or not in this case uh comes autoa so basically automa is a ion layer AVS that helps with this validation of trust like we have seen in the previous diagram that there was Intel attestation service now in this case automata has replaced that so it has cut down this Intel centralization with this automata AVS in which the nodes are running this provision Pro like provision certificate caching service called as pccs in that any Enclave when it wants to attest something so those certificate can be used by the automata nodes to validate that if some node is running the right binary or not and on top of this since uh these chains have different rules and consensus mechanism things like that so all these things can Al can also be intact inside this cross-chain rule base AVS and this AVS how it works is it uh it it actually uses this uh onchain like ethereum onchain mechanism to make sure that the attestations are George we are running out of time uh can you can you maybe move to yeah yeah yeah so basically next setep is phase one we we are we are going to investigate the tte chains and attestation plus the Conor rules and then we are going to put them into an architect in in into an architecture that we can actually develop solution so that we can develop a POC at the end to make sure that those uh State and data is actually intercomp posible for that we will use uh we'll take the help of automata AVS with decentralized attestations and my matter is Andrew Miller from flash BS and ic3 and uh yes I just to quite sh thank you so much and if you have some questions please feel free to ping me thank you so much AB um guys are there any questions or anything feel free to raise your hand uh well my question is like how does this actually help core ethereum like you talk about chains using the trusted ex so the trusted execution environment currently is in like dependency of ethereum or any clients or any validators as far as I know and personally I'm not really fan of the trusted execution because I find it just like proprietary way of doing security by obscurity um I don't think that like blockchain relying on this can can uh be fully open and permissionless I wonder like how does this apply in ethereum uh because you talk about some layer 2os about secret Network like alternative layer one so I wonder like how this is work in eum yeah yes yeah so you I'm sorry I just hear a noise from your mic um are you with us hello yeah yeah yeah okay cool yeah so we are going to use OSN secret as an example and we can actually use any solidity based chain we can also use this uh s uh thing as well like it has like a side wagon to make sure that you are running the flash bot auctions and eventually using the ethereum based a AVS you can put the same functionality inside certain cater made ethereum clients which will be very helpful in the future and this is like like the most Cutting Edge thing and this Auto meta has also launched it stuff like a two three weeks ago that's it um yeah I mean the the connection to ethereum is not really obvious there like it's not directly uh I mean it's interesting project I'm happy that you work on this I think um Miller is a great mentor as as well uh but uh yeah I I'm not sure if it like fits the protocol fellowship if it doesn't work directly on some you know handson core protocol work although it's interesting and somewhat related I I have to give you this feedback um yeah yeah thank you so much for presentation I think I think it's I think it's good uh again like I think it's uh just a to all right thanks just give me some time and I'll try to make it more it's it's so yeah you can you can just you know highlight the parts that touch theorum in The Proposal but yeah I think it's I think it's okay uh let's let's move on because we have we have three more people to go through we are currently out of time we are at 90 minutes do we want to finish it with a three people or save them for later I think we can just go ahead and do it now um any inputs Josh I would say actually let's pause them until next week I imagine there's going to be a few more people that are going to want to present still and um yeah that would be my opinion but I'm not opposed to trying to finish it up right now but I think probably pushing to next week would be best going to take one more one more day yeah it's been it's been a while it's um it's been a lot of projects I was hoping it we can fit it to 90 minutes but um here we are out of time again and yeah we have three more people for next week I already hoping to have some AMA I was talking to some mentors for next week but if it's uh uh yeah uh we can we can just move it move it there um and uh okay uh San wants to present now just three minutes I would if we are if we are cutting it off now I would just leave it for next week if that's okay okay you guys want to present okay uh if if we yeah let's let's go ahead Den um I guess if we are um uh if you're ready now and you want to you want to get it over with um yeah all right let's finish it up and please try to keep your presentations to only the pieces that are about what you will be working on again you know remember that people here have some technical understanding try to just kind of Breeze over some of the motivations and stuff and and just focus on what you're going to be working on so say you're up let me present this just okay yeah uh can you guys see my slides oh yep go ahead okay U uh so uh I decided to take on two projects I know it's not recommended but the second one was partially related to the work that I was I was doing for Lighthouse with ination so we'll try to end it quickly and So currently we have to run El and cl client separately and they communicate by engine API methods which are exposed by El client and are consumed by C CL this is done over HTTP RPC you guys know it already so I won't go into more details and so my project is to do direct integration of Lighthouse and R uh the plan is to have a single repo with Lighthouse and in it which will be easier for a user to set up and run and to connect them um we'll just replace the htpr RPC by regular function calls and to do so we'll abstract the execution layer back end in Lighthouse by using a f and then we'll Implement that F inside with for the direct back end and uh we'll change the definition of engine to something like this uh in Lighthouse Upstream here the execution uh back end is the neutr and the H3 pages on our PC is the default back end so most important methods uh to get working will be new V3 and four Choice ofed V3 and once those are working we are hoping that we'll be able to sync the chain using this Bing so that's just the rough plan so far and there are many things that are here to be charted out so for tracing integration Lighthouse uh the work is going to be pretty straightforward and simple um the lighthouse currently uses slog for most parts so I'll just replace wherever they using SLO and log in their code tracing and what I've been told so far the S log streaming is going to be the hard part most probably other than that it's going to be pretty simple and challenges that I'm expecting are basically just skill issues is out of touch from developing anything major for quite a while um aside from doing a small contributions here and there was mainly into security and auditing side of things for last one and a half years uh so I'm expecting to have some travel initially and by the end of uh the fellowship I want to get the pr for tracing uh integration and back end obstruction merged in Lighthouse and also we want to have a single with Lighthouse and integrated together and we hope to syn a node using the direct back end by the end and uh here's uh the rough um road map for it uh so most of the time we'll go into the actual integration uh and the last two phases will take around three weeks a piece and uh I'll be also writing test continuously during the phase one uh but the second phas is dedicated to more thorough thorough testing and I haven't uh made a separate uh road map for the tracing integration I will just be continuously working on that parallely and mentors so stra is helping me with the lighthouse integration andan is helping me with the tracing integration uh thanks to them for tolerating me and that's all thanks for sitting through and thanks thank you so much yeah awesome uh thanks a lot uh so yeah uh next is Gloria while we get ready I have a question for you actually San uh because I'm wondering like so this project uh maybe you didn't elaborate much on it like what is the motivation or who proposed this integration project between red and Lighthouse like what is the actual goal because I find it like a lot of work for like not much of a benefit and uh also like you know many problems coming with having like a third Co code base which needs to be maintained which needs like yeah yeah so this project was proposed by the lighthouse team and they wanted to have a third repo with Lighthouse and R integrated that uh is owned by both of their teams and so we want to have a like uh we want to make it easier for the user to set up and run a single binary as you have said in my uh project proposal and thanks for the feedback there I that as well yeah it's interesting because like uh this is what Aragon does in K with kin uh the problem with their approach like I mean they are doing the other way around like building uh their own CL within the El and uh uh that's also like not ideal because it's it's hard to use it it's hard to configure it when uh you don't have the features of you know Sone binary with all all its all its options so um yeah it's it's interesting project um thanks a lot uh again Gloria are you are you ready can you share yours uh screen yeah awesome awesome yeah I think we can we can move on uh hello everyone can you see my screen yeah yeah go ahead okay so I'll be working on Native support for infer test Nets so basically I'm going to be focusing on implementation on the client Bas uh specifically B and te clients and the motivation for this project is um basic first of all I like the idea of um a disposable test net and possible ability of automatically resetting the Genesis function and all of that and um another thing another motivation here is the ability to integrate with more clients right now we just have um and lar implementation done by OE and I think she's still working on finalizing that and then another aspect is focusing on client Genesis um generation and to streamline the client reset function so and very importantly I'm also very much interested in this project because I see it as an opportunity for me to learn more about the ethereum CL and L El clients so for road map um for this I think the month is almost ending so for the next couple of weeks that we have I'm going to be focusing on client architecture and visibility study U draft deta implementation plans then for August to develop the infer live for Genesis handling and both for yeah for the Techo clients and in September I hope to start the actual implementation with the in such a way that um we could not use the flag theer flag in Te because right now that's not possible and also test out implementations or work that is been done then in October I also hope to do the same for the best of clients and in November I want to work on the proper documentation and tutorials and also the website creation for the projects these are some of the important road maps as outline in the project repository then what are possible challenges so um basically ensuring reliable And Timely Genesis calculation or retriever because this is one unique aspect of the emper test net and handling potential synchronization issues across clients so different clients with are different specs and uh they might be issues when it comes to compatibility in terms of trying to integrate with the the reset function the automatic resetting of the Genesis function and all that and so this is development Anything Can Happen along the way so development delay is due to unforeseen technical complexities so the goal of the project is to get Tech and B client to be running using the flag hello can you still see my screen yeah yeah all good go ahead yeah so and then clients can dynamically handle Genesis block resarch every period without manual intervention so that's one of the important goal of the project and also a more user friendly website documentation and tutorials to help anyone that wants to come in to probably to properly understand what's going on in the project and currently uh I'm the only one I don't know if there's any other person at the moment but only from previous courts I think she's still actively working on the project she still trying to like finalize and work on other aspects of the project and Mari is also there to help out so these are all resources thank you very much yeah awesome thank you glory yeah uh thanks a lot it's great to have you working on our family I really appreciate it and I think it's a great way to learn uh about clients to slowly get into the client development yeah awesome um um yeah uh any questions any comments we have last uh one yeah hey share my screen seconds [Music] um all right are you able to see yep all good perfect um so my uh project for the cohort is developing a Basu portal client um I have a brief overview but I'll kind of just skip over it just for time but basically it's a like client solution it's really scalable and also very user friendly and the way that Portal's designed is quite protocol independent so it benefits the protocol but does not actually have to modify it to work properly um so choosing bzu uh as a as a um choice to develop portal client not only because uh they are looking for a portal client but also just because um I wanted to increase user choice and kind of the same thing we're adding client diversity uh there's always a benefit to having different client options um and uh I can use Basu existing implementations of different protocols so uh to help speed up the process something like Discovery V5 and their Json RPC um is is useful to have as a a starting point um and then because it's designed specifically for BAS it's also easier to implement a bridge client and allow uh to to uh a full note to funnel more information into the portal Network um the way portal is designed is very modular and so it's split up into six different sub networks um each of them are able to operate independently of each other and So currently the main ones are State Network history Network and Beacon chain Network and there's also the three remaining canonical transaction index and then transaction gossip and veral state network but these are very prelim preliminary and so I'm not going to focus on these for the duration of my project just because they're still uh quite in developments and it also would be outside of my scope during that for that time um but uh in terms of actual implementation I'm Imaging that create a Java implementation of Porta wire protocol take approximately four weeks um just to uh mirror the Discovery VPI protocol uh Implement UTP um and get like a Json RPC capabilities just so I can start working the sub networks um but I'm imagining about three weeks per sub Network to work on um for all of the processes along the way I'm hoping to get a thorough test bed um and especially work on interruptibility with existing portal clients just because that's kind of the the main thing is this and also probably the most difficult portion is just all the different moving Parts um um and then as well if I do have available time I can start working on PR preliminary sub networks like the three that i' mentioned and then as well Bridge client functionality um but that's very very big if if I have enough time um and the main goal uh is to of course get a portal client for Basu and uh Bas design off lower level Network designs uh existing and Bas already um and primarily uh be able to interrupt with existing portal CL clients and hopefully to get uh the three main specification complete sub networks all up and running at least to the um the same level as the existing portal clients are very close um and then have a good testing base and that's about all thank you wor well thank you so much awesome another portal client in making that's that's great to hear yeah yeah very well and I think we made it guys uh almost two hours but we are in uh we had all the presentations did we forgot anyone yeah we get get we get all of them right K know um yeah yeah we made it I really appreciate uh appreciate it guys uh many great presentations today I'm really looking forward to see all of your projects and uh yeah uh