EPF5 Project Presentations - Session 2.1

thank you so much for all the submissions that you did to the repo all the presentations um and uh yeah we are following the agenda in the repo in the in the issue um the first person there is red to Happy who was uh moved up from the previous meeting because he wasn't available a week ago so the question is whether you are I see I see the red to happy is here yeah are you are you ready yeah yeah okay awesome so then we can start with with that uh feel free to share your stream uh just we have uh recording ready okay we're recording okay awesome um yeah uh if you have slides please share your screen and uh the stage is yours okay can you see my screen uh no well uh how about this um does this work nothing yeah I I don't see you sharing it all now now it okay awesome yeah yeah I thanks everyone uh my project is securing grent by fing and I'm I'm happy and my proposal is work along with the B maps and let's start with the motivation and why we are choosing the the Gent as the target uh for the two main points is that the first the Gent is a high performance uh consensus client with parent lasing and efficiency and it is very promising in the is own man network and it is permanent um since it is used in production like the Holly Sky Tes Network and there many security concerns of the gradient is not complete uh so far uh we need some Soro testing and fing techniques to secure the gradient and Implement and we need to find some implementation flows between the Gent and Lighthouse uh this is not fully researched since we we currently only has a single audit performed by arist and that audit is performed several months several months ago and we can see that there's no no automated CI testing or fing method for the for the new updated code and since the since the CI infrastructure is lacked the newly updated code is not being scanned and is not secured as well so the main challenge is that uh there's many complexity of understanding the differences between the gadient and the louse and due to the lack of the documentation and the environment configuration is also hard for us since setting up the setting up the live Deb B environment for the consens layer is challenging and we need to choose some f we need to choose some semantic award fing techniques uh also we are need some welld designed sanitizers and concurrency detection tools uh is also to be considered in the rust environment finally some pars may be deep heading the complex model and we need to uh we need to identify the root cause and we do not have many uh experience in the consensus issues and we require more knowledge to deide so uh the our our project goals is that we will uh demonstrate a detailed compreh comparative report between the Gent and the lighthouse and we also will perform the enhanced finding techniques and recommendation for the Gent projects and we will integrate our fing into the modern CI Pips like the osss fils and we will explore and identify the most promising te testing techniques among the property based testing and sanitizers and the currency testing tools our solution uh includes uh uh comparative analysis and also the property based uh testing infra and we will apply the state of the art following tools which is most compatible to the gadium and uh we also will develop many small individual fathers for the independent models implemented by the Gadi and we know that many models are shared between the ging and the that house we will finally integrate the F to the Upstream fing framework like OS is f which is which is f every day by the Google and that's my project proposal thanks everyone um thank you so much um so you work on this with Bulma right yeah uh yeah uh haven't haven't heard from her so just checking um yeah I think it's great I think it's interesting um just to uh just to check whether you've been uh following um Mario and his fuzzing work which is mostly goang uh but like there's a lot of existing fuzzing infrastructure that you can um that you can take expiration from and the main cross client testing being done is using hi and crosis so it it's it's it's like just want to say that it's there this cross client tests um and uh it's on a different level like the fuzzing is mostly uh mostly for something else so so just just checking whether you've looked into the these other uh or existing efforts yeah and we work closely with the maintainers of the radio yeah like I would yeah that's great I would recommend just you know checking with marus for example uh who's did like extensive amount of fuzzing uh so he might be he might have some good insight there as well just uh okay s for your suggestion yeah awesome uh yeah thank you so much um any other comments questions okay uh yeah thanks thanks a lot um next up is hammed first one who commented under the issue yeah hey hey do you hear me yeah yeah all good great let me just share my screen yeah looks great see my screen great great hey everyone I'm happy you're finally presenting my project my project title is inclusion list with plaus deniability what that means and why it's important and why I choose this one just before deep diving on the project itself I want to talk about the flow I just decided this project and let's start uh in the starting of the program I just have a two Topic in my mind privacy and sensorship resistency and I just checking the different idea different EIP to choosing one one of them to implementing and after few iteration I just figuring out something important censorship resistance in base layer is a prerequisite for most of the Privacy approach we can't have a censorship resistance in our base layer and and after that we just developed the Privacy approach the just validator or the proposer could just simply the censor all of the Privacy related transaction and because of that this is a really important prerequisite and because of that I just dropped working on the privacy and I just focus most of most of my attention to the sensorship resistance idea and before deep diving on the solution let's check about the cor current status of the sensorship resistance on the ethereum base layer this this diagram is from the sensorship racist. PE website and its website just monitor most of the validator and the relayer they are using and the Builder they just posted their execution playload in that relayer and the statistic says near to 60% of the builders uh Builders just censoring some certain C type of transaction this site says the ofac related ofac non-compliance transactions and after that we can see uh this could affect most of the network this 10% it's not correct why it's not correct because most of the validator if they want to be rational and earn more money and doesn't involved to doing meev res Mev searching and block building by themselves it's really logical decision to using one of these relayer and when they are using this relayer they connected to 60% sensoring Builders and that affect the whole networks and that make it really bad and let's see what but why the sensoring could happen in here before the proposal Builder SE I'm not going to talk about the PBS because I'm sure most of you you know about the PBS and let's just check this before the purposal Builder separation the minor and validator they they are responsible for selecting the transaction from mempool and after that putting that transaction in the block block body and executing those transaction and let's say if we have a lot of validator we have a lot of solo Staker in our Network this sensorship resistency happens by itself automatically but after the PBS most of our validator and proposer have a really big incentive to using these Builders and these Builder are kind of dangerous for our censorship Rens power in the etherum so what is the pro what is the solution and H what what type of the things we can do to solve this problem the things in here is that we can have a two two approach one of them is the active actions to fighting back for the censorship resistency and the second one is a passive approach what is a passive approach the bunch of idea that helping to helping to the ethereum to unboarding a lot of new Staker a lot of new solo Staker to the networks if this un happen the sensorship resistance assus also get better but what is the are we can have kind of active solution yes just like check the problem statement in here our problem statement is that was that that the purpos our proposer just lose their power and delegate that power to the block builder for selecting the transaction and they they doesn't have any power on this transaction selection can we have can we have a kind of solution to take part of this power back and we can say yes the inclusion list is kind of idea doing that and how they are working the inclusion list in one sentence we can Define the inclusion list like this one approach that's allowing one verifier or set of verifier enforcing the inclusion of one transaction or some certain of the transaction some certain sensor transaction to the builders and this idea get started from two years today two years ago and it's going on and it's really have space a lot of open question in the design side for example let me just elaborate some of this design space should should the inclusion list uh get applied on the current slot or the next a slot forward they call it the forwarding forward inclusion list or what what going to happen in our what happen if the next slot proposer doesn't propose any block are these are these inclusion list get accumulated for the next slot or not these are the type of the questions uh open question in the inclusion list and as I mentioned there is a really huge design space in here and as you can see from today two years ago till now we have a more than 10 designed for the inclusion list so which one I want to implement it the before before doing that I want to tell something uh in the middle of the June I just start talking and have dis having discussion with the one of the original EIP author of the inclusion list and I just figured that the inclusion list are not going to happen for the Petra because of because the inclusion list really have a lot of conflict and a lot of a lot of uh same related architectural question to the epbs and we need first to the first that epbs get implemented on the network and after that designing the inclusion list and that was inspired me why not I'm just choosing really experimental idea on the inclusion list instead of the choosing the fully ready to implementation idea for the inclusion Le and because of that and also having the privacy and anonymity in mind mind I just find two idea that got my attention one bit per attester inclusion list and another of them is anonymous anonymous inclusion list what are the shared things these two idea we have but these two idea are caring about the anonymity or plausible deniability capability for the validators what are these and why they are important let's say in future we don't have any kind of anonymity or pla deniable for our validators and this validator or proposer just just really just is a just normal legal entity and everybody knows that legal entity and everybody knows their addresses and everything is public and someday this legal entity and proposer just put some transaction in the inclusion list and they going to have a really big problem with the other legal and restriction they going to have the their legal entity and this is a really big important problems that can prevent from the adoption of the inclusion list and because of that I really like these two idea because these are adding some layer of the Privacy for the validators and adding there and giving them some plausible deniability capability and if someday they have the some some legal problem they can just plausible denial that's problem they said it wasn't me I just sent a wrong bit that my bit doesn't belong to this transaction you mentioned because in the one bit per attester inclusion list every attester is only responsible for one bit of transaction and you know one transaction could have a 200 bits more 2,000 bits or more than that and let's say you nobody can just accusing this proposer for sending that transaction to the in inclusion list and because of that I really like this idea and another them another idea was that Anonymous inclusion list this idea using the ring signature to adding to caping the private private committee for creating the inclusion list and that was a really interesting idea but I just drop it because it needs some some sort of the central component for performing that that and because of that I doesn't like it and because that I just dropped this idea and choose working on the one bit per attester inclusion list and let's oh sorry and choosing work on the one bit per attester inclusion list watch oh sorry I think I'm gonna have the two minutes that's right yeah go ahead just yeah don't take too long yeah okay so I'm going to drop the rest of the thing I want to mention in here and moving forward and what's going to happen in the implementation side I'm going to implement the this idea that vitalik just published it in the middle of the June on the for the one bit per attestation it's work based on the error correction codes and in parenthesis binary read Solomon codes um first of all I'm going to implement the re binary read Solomon for attesting for single bit of the sensor transaction updating the fork Choice updating the to add a new capable Neo API to our uh execution client to returning some sort of the sensor transaction based on the predefined logic and create the test for new specification as I mentioned the the one bit per attester is just the idea it's not a fully ready specification for implementation and because of that I need firstly to define the a specification for myself because one bit per attester it just uh have a idea for one phase of the protocol construction of the inclusion and it doesn't talk about the rest of the protocol we need and I'm going to define the rest of the protocol by myself I'm I'm going to write the test for that and I'm going to use the Rando for creating the new commune par slot for creating the creating the inclusion Leist and rest of the things I need to implement for example I need to create the detect detecting the ti invalidation with use with are the native account abstraction in the execution layer because let's say one validator just put the transaction in the inclusion list and after that that transaction get invalidated via the native account abstraction that we are going to have the in future and this proposal going to get failed because of that we need to kind of design a solution to preventing that uh also I need to attest doing the attestation aggregation over the P2P layer this is the one of my challenge because there're going to be really huge amount of the attestation object that I need to aggregate them per a slot and this is the one of the challenge I should solve and that's it please just Reach Out me if you are interested to the idea and uh these are my contact and please just check out my project proposal if you want to know more about the project description and road map and specification and also I like to join the for seal working groups that the Amin and lenov on it because both of them are working on the inclusion list and I also going to work on some variant of the inclusion list and I really like to have a communicate with with there and having some feedback and giving some feedback to them and that's it that was my presentation any question any comments sure sure then please just open up your mic and talk yeah any any questions hey uh so the the project is mostly on the experimentation part do I did I understand correctly you're just going to do to work on the specification during EPF project or you also have an implementation or a PC or no I'm not going to just working on the a specification my a specification should get ready by the middle of the August and after that I'm going to work on the uh PC with using the lighthouse and also the rest as a execution client okay thank you it's uh intersecting El with epbs is going to be a yeah not yeah okay good luck but I'm not going to implement the epbs part because because I'm just doing this for experimenting and having checking the network operation and checking that one bit per ATT could work or not any comment any question thanks K yeah anyone um yeah thanks thanks a lot hammed think it's really great I really appreciate your your work previously you worked on the um uh private transactions EAP and it's great that you continue uh continue on with uh uh I I really like your motivation there like we need the censorship resistance to be to be to enable any kind of privacy or really anything so and more more privacy more um more plausible liability for validators I think it's really cool yeah I wish you thank you for feedback um awesome yeah uh if there are no more questions or comments or anything let's move uh further uh with Kira yeah hey yeah let me share my screen go ahead can you guys see my screen yep looking good okay right right uh yeah uh so like there's one more teammate of mine like and Aman is going to start yeah so hi everyone I am Mohammad Aman A permission uh permissionless candidate so our project Implement project is basically the implementation of EIP 7732 which is enshrine proposal Builder separation uh our current scope is for prism once we have done implementing it on prism we will possibly go to a Nimbus Nimbus client so uh currently our team consist of Caleb Kira me and jihun and uh mentors who are mentoring us is poos teren and Turk so yeah current motivation before going on the motivation let's get some context on epvs So currently the proposal Builder separ The Proposal Builder separation it is handled out of the protocol by third party software such as MEAP boost as mentioned by Hamid so that is that is uh reliability we have to rely on the intermediary software for propose for broadcasting our blogs as a proposer and as a builder it is much of a pain as this is a critical issue for censorship as well as there is a risk that is uh associated with it that is the centralized concern that is 94% of the blocks uh are are handled by five relays as per last 14 days data so here the actual problem is that the propos want to sell his right to build a payload to a to a builder and a builder also wants to buy the right to build the payload but they both need to trust a single intermediary that is a relayer in our case uh so we need to remove this trust barrier and make a trustless uh intermediary which is a inbuilt protocol something like epbs and uh this uh this issue is not small because uh due to this the whole concept of decentralization is getting denied so yeah this is what what uh we are going to solve through epbs and the project specification and description Kira is going to discuss and yeah over to you uh yeah so to describe more on the solution and problem the project is fundamentally about solving a trust issue and it's not about transaction ordering or me uh so like me consideration such as me stealing or and for attacks are not the core issue here so currently uh most of the beacon block uh Beacon blocks are uh most of the beacon block proposers in ethereum rely on third party Builders to construct the execution payload for the blocks the request uh has t root from the Builder and submit uh submit their signed blinded weon block to a trusted relay which which would then uh eventually replace the H rout with the full execution payload before broadcasting it to the network so yeah as you can see like this uh this process requires a trusted intermediatory in this case relays um so solution for this is um vators have a short window in ethereum like 4 seconds of uh window to validate both consensus and execution state transitions check data blob availability and evaluate the new head of blockchain by separating this validation tasks vators only need to perform the consensus State transition immediately and like this way like we can defer execution uh execution and data ability validation to later uh this will uh like result in Faster Network propagation uh reduce reog that were caused by blob transactions and also like avoid uh valers missing their attestations uh and the main thing the it will El it would eliminate the trusted intermediator uh so on the spec side uh the implementation would follow yeah the implementation will follow the spec mentioned in EIP 7732 the spec introduces uh a new stake participant called Builder on uh like it also introduces Hest Val duties called payload timel attestations and the concept of payload boost re boost withle boost I'm not going into details of all of this but uh I'm just going through that uh it will also introduce a payload timeliness committee for checking the timeliness of uh the Builder execution period so yeah this is what an epvs slot would look like uh in our solution so the slot in the ethereum protocol would be divided into four intervals as you can see like uh in the first interval like from 0 to 3 second honest variators will gather signed bits from Builders and then would commit to the commit to one of the bits of their selection and they would submit assigned beacon block with this bid so at this point they don't know what what the payload is payload for the Builder is they only know what the value of the bid is uh and the sign uh and they have like sign bid from the Builder for the second slot uh second slot from 3 to 6 second honest vors would submit their attestations uh this is similar to what happens right now uh for the third interval aggregators would aggregate uh this attestations and the Builder would broadcast either the full payload or uh if they see a we block from the proposer that has like low weight Builder can also choose to like send a message that they are withholding their payload uh through signed execution payload envelope uh and finally for the fourth interval uh a new PTC committee would be formed uh some of the validators in this case like 512 validators would be selected from the set of uh present validators and like they would attach to the presence and timeliness of this Builder payload so more on the road map uh for the month of July we are trying we are implementing the helper functions mentioned in the spec this will also help us to get familiar with the prism code base and how uh how the flow Works uh for the month of August we are planning to implement the packages that are mentioned in the spec and have like a running version of like have a running initial version of POC uh in the month of September uh we will do some functional testing and like there are there's like two weeks of buffer uh if if there's like any delays or stuff for the month of October once we have uh working POC like we would Implement networking modules uh that will handle blog auctions P2P bits U goip protocols Etc and for the month of November like we will finalize on some touches and end the presentation at Decon um yeah thank you that's it like any questions very well thank you guys um yeah do you have you have any questions to anyone yeah I'm wondering like scopy is that a question or uh it's just by mistake sorry for that oh yeah sure yeah I was just wondering like what is the IDE a behind like switching to Nimbus like how did you decide focusing on prism and have Nimbus as a fallback like why even have a fallback and then why nimus because like Nim is you know kind of weird language that you get have to get into and uh understand you work with pus from from Prism so yeah so the idea is like once we Implement in prism like we need like more support from other client teams as well to like uh have this in production or like on Main net so that's why like we are also trying to get as many teams to implement this okay okay makes sense yeah um yeah cool cool thank you so much again uh it's great yeah uh yeah look forward to see more of you guys um and if there are no more questions or comments or anything uh we have P next let me so is it visible Yep looks great yeah U yeah I just wanted to say one quick thing like uh so yeah we are bit time limited don't take too much time on the motivation or like explaining the concepts like what is PBS what is a light client like mention some Basics but assume that people who are listening to this presentation are aware of all the like fundamentals and research areas protocol so just focus more on your work yeah awesome go ahead yeah yeah uh so hi everyone rupam here and uh I'm working on this project like C supporting prism I got two other fellows working with me like basan and uh with our Mentor Mr radic so yeah moving forward currently the uh beer Network looks some something like this uh there is there are uh few some Beacon full notes some of them are validators and some of them are not and like uh they and all they have to they have a block and uh the block the block has blockheaded transactions attestations and other payload and the work of a full node is to like of verify this header verify transactions and state changes and check attestations to check other payload and other proof of State mechanics uh checks so all of this is a computation heavy process especially the state changes it takes a lot of computation power uh in terms of both memory and like uh like in terms of both memory and storage in uh you need a 2tv SSD and decent amount of ram to run a full notes so what light line fix fixes is that it uh it removes this Hardware Necessities for running a node so what does a light line get that Beacon like a light node will just connect to a full node and then it will get a block like this it will have the block header a sync commit signature field a sync commit bit field and next sync committee so what the like line does is the it verifies the sync committee and the sync commit bit field and based on the verification it accepts or rejects the blog header now one thing to notice is that there is no State related computations here so uh obviously the computation power is much less than running a full node and if any state related information is required you can just query it from the full node that the like L is connected to turn uh you can just check it if it's correct or Not by just having because you just have the block head you can just check against it so right now like C support is present only in loar and numbers and we plan to add it to Prism 2 the road map would be something like to read and understand like lines and then compared to uh CL specs and uh there are and we we have gone a bit outside the project details like the project details only uh specifies full note but we have decied to full note for alter and we have decided to implement it for capella and denp to so we will be implementing some new features from Capal and nf2 so that's what uh that's what for the road map uh there there is a more detailed road map posted on uh GitHub the link is in the in my project proposal you can get it from my development updates uh and yeah that's it for the road map and last but not the least I'd like to thank the fellows involved Rahul and B Bas and like our Mentor Mr radik for the help so yeah that's it any questions awesome thank you so much um guys uh any questions or Rah Bastin any comments or anyone yeah it was great uh I really appreciate it like uh pretty like suent um presentation uh like short and sweet well well well said uh all the all the details of the light clients and uh I think it's important project because the AL tire has been around for like what is it 2020 for like three years and these these clients still like don't support the light CL protocol so yeah it's great yeah by the way the detail road map I was speaking out I will just show it it's this like it's a very detail one one like a very technical one if you want you can like just check this out it is like uh linked in my project proposal and the first thing the Implement is better update I am kind of working on that right now and uh also like this is kind of out of the project scope because it implements the helper function from the sync protocol markdown file and not the full node file with and only the full node file has been uh mentioned in the project so yeah that's okay awesome uh yeah thanks for elaborating on that and um if there are no more questions or comments or anything uh aan nikin is sorry if I name uh um yeah yeah is the is the next list yeah um yeah feel free to share your stream go ahead you my uh no I can yeah it's all good go ahead can you see my screen uh yeah I can I can see uh but I can hear you a bit worse maybe the when we just limited yeah yeah I can see the whole screen now go ahead okay uh hello everyone uh Michelle uh known on on Discord online and my project for ep5 is uh that specific cryptography in Grand D Ros kg and um my motivation for this project stems from U should I say all the interesting about ethereum scalability you know Shing cryptography all this stuff you know and uh and you know on D specifically we all know how d as a technique you know allows node to verify uh the availability of blog data without having to download the entire blog I mean and you know and all of this sort of helps to lower uh the resources there and increase put uh which which is believed to be very crucial for scaling ethereum right as it reduced the Bing on you know individual nodes and the the kind of the amount of of data they they get to carry and store uh but however there's no that specific cryptography uh currently implemented in grandine which I like to pick up and uh I think it it also gives me an opportunity to and hopefully others you know learn about D have a better understanding of it and it's cryptography it's smart because it can be can be quite it can be quite a lot with my project description uh the the project itself uh involves implementing uh some critical uh cryptographic functions that are you know uh outlined in the in the consor specs uh in the specs and uh you know um I implementing this in in Ros G Library you know uh the the liary itself will be able to do some interesting uh things polinomial commitments which I'll talk about briefly uh in the next slide and definitely we hope that it is lightweight efficient you know user friendly all this stuff it's and more importantly Grand can use it and hopefully other Ro implementation of the consensus client can also make use of library the the specs you know uh outlined in in this cons specs uh you know the EP EIP 7594 polomia commitment they are majorly divided into these three functions uh compute cells and kg proofs uh which helps uh compute all the cell proofs uh for an EXT blow there also it verifying the cell kg proof batch uh this uh you know helps verify that the cell belong to their corresponding commitment there's a lot of commitment going on and recover Sals and kg proves which I think the major idea is that like if given at least maybe half of the celles say 50% of the CES for a blob uh then you can be cover all the celles and and its corresponding proofs right um so on the road map uh first is just uh deep diving into the cons specs itself and and it's uh you know its commitment the math behind it and a lot of the uh should I say resources or documentation on kzg and it's uh uh and it's uh the the top the the Mathematica uh concept behind it and and making good use of it there's also you know referenc existing d implementations uh some of which I think ckg has some minimal implementations we taking a lot of explanation from that and uh then uh hopefully start doing this implementations in those kg some of which have started uh you know very B bones cly uh then afterwards uh we can you know develop and Implement uh some testing plan so at Le test out everything and make sure it works and ensur some compatibility with Grand and uh and other implementations of the consist clients so uh my possible challenges definitely knowledge Gap uh some of which I'm trying to close currently uh uh and this knowledge gaps regarding maths cryptography uh you know implementation as well also rust you know a lot of things that are involved and also limited resources and docks uh there's no I mean I think it was someone mention of it that uh Grand US is because they need to just open source there's not a lot of resources out there on on grinding and um but um I think s has been of Good Help and uh and definitely I'll just rely on the uh consensus specs uh you know outlined in EIP as my as my dogs and my resources and definitely client testing and debugging uh standard standard challenge um so the goal for the project would be to have a fully working and tested implementation of uh D cryptography uh in rosg library and make sure that it's working and also be able to provide some comp documentation for anyone who would like to use them and I have some benchmarks showcasing this enhancement so uh my collaborators uh myself and working with Village farmer and uh we have S mentor and I think that's the end of my presentation thank you very much everyone any question yeah awesome any comments questions yeah I think it's a great project um yeah uh grandine being a young client definitely needs help so um it's awesome you contribute there and I'm wondering maybe like if you looked into lighthouse in a way like is there work reusable in gring like can you make your job Easy by uh using the libraries uh or or so uh I very ear on I spoke with uh d lion on trying to do this but I think I'm going to so it gave me uh some things to check out uh tracking all of these issues in Lighthouse so I I think I'm going to look deeply into that as well and just you know ask him questions if I if I have any but yeah I think I should look into that yeah yeah that's great yeah I mean makes uh makes much more reasonable project when you have something you can uh rely on and somebody to ask yeah it's great awesome okay yeah very well thanks a lot again and uh next on the list um addit cryp yeah yeah uh go ahead so is the screen visible yeah yeah all it's good so I will be so mym protocol Fellowship project will be on the stess execution with witness uh which I will be implementing in R uh so yeah so yeah so about the project description uh this project is currently implemented in G and was made live in the recent release of the git so the concept of this project is like uh basically focusing on the client diversity before workes so currently client diversity is very very very much important in the ethereum uh to uh to explore the problem to more depth I will just explain some few con for example to the client di is import important because of the aggressive slashing presented theum Network so if slashing is done to a large extent then majority of validators will face Roop percu and this will lead to a major vog in the chain so this is not favorable and it is totally not accepted so to enhance this so to uh prevent this we follow the concept of client diversity so the consensus layer of proposed solution was to enhance the so that the every client should have a say of less than 50% but uh this cannot be implemented on the execution layer side execution layer side we have few Solutions such as using a minority client but using a minority client have its own consequences of new computer architectures and testing and Metric locations and all another approach uh would be to run multiple clients at the same time but this is not favorable for solo validators but it might be favorable for large validators so we introduce A New Concept called as we produce in one client but we verify the same payload using multiple different CS to understand this feature to more extent uh let's just get the overview So currently the block transaction is done in ethereum such that uh payload is uh received by execution C and it just execute all the data in the payload and just it just checks whether it is correct against the block data block header data but instead of just accepting this result we can do a cross validation with other clients as well for example we can just propagate a witness along so actually the problem with with this will be that there will be a problem of State maintenance so even if we do a cross validation with other clients other client have to maintain a state and repeatedly update their state and use their own local chain this is not favorable and we are we are back to our own problem again so we introduce a concept of uh stateless execution with witness so what is witness so instead of using a state uh their local state uh the client will be entirely relying on a witness witness will contain all the data needed to execute the transaction uh in the payload so yeah this is really the concept of execution with witness yeah so yeah so what will be the things which will be which are required to be implemented in this project so first of all we will be required to define a witness bundle so content of the witness bundle will be all the account nodes and the storage nodes which were accessed by the transactions in the block all the bite codes of the contract which was accessed and all the accessed block hashes uh and then uh we will also have to see that uh the reading and the writing of the witness are done at the same time so this might affect the witness construction due to the different structure of the trodes uh yeah and there should be a solely different mode so that the client are not dependent on the local state but they will execute the block entirely on the data provided by the witness this few things need to be implemented so that this feature is currently so that we can make this feature life in the execution plan there are some cavates in this project first of all the I will we will not be using veral Tre for providing this witness proof we will be modifying the existing medical Patricia tree for this only so due to this the witness size will be large so that the latency issues will be introduced in the witness propagation because size of the pad will be increased there was some research which showed that currently we are using rlp encoding for witness uh proof encoding uh but if we shift then there might be some improvement in latency but still it not be uh not that much good so that the users will be using because uh already there is very very few time for the slot uh plot production so ultimately this thing will be corrected by work Petri tree only by Shifting the proof top proofs so yeah this will be the project cavat so what the basic plan is that uh I'm thinking of implementing this project and testing it uh and creating a full Benchmark project within a month or 1.5 month and if this project gets completed according to different according to this specified tring I will shift to a new project called as the r work p I am currently in talks with the red team so this red work P3 will require me to completely scrap my whatever thing I did for the for this month and then shift to work so currently few clients such as nether mind get uh eum GS already have implemented a fully fledged work PC but the r has not so for this project I will be using the rust mle the also theum just has already used the rust mle more some Bings in the project so that might prove to be a good reference so uh this will be a very long project uh and I will be taking this up once I have completed the execution with withness project and the ultimate goal of this project will be if the r is able to join the latest iteration of the constant devet which is the dev for the m prace so uh this will be the expected timeline the first month till the end of August I will be completely focusing on implementing the execution with witness feature in the red benchmarking it uh and testing it completely parently I am deep diving into work p i reading all the Articles and the associated lectures and everything related to the cryptography I have taunted my contribution to the rust worker uh basically most of the bindings are done in the rust work but some optimizations can be performed such as the uh the pre access of leaf nodes is not optimized we can use recursion there to optimize this performance so this type of things I'm contributing to enhance my knowledge once this project is completed I will be uh starting with my proposal on the work POC uh work p will be a long project so this will go on testing itating connecting with the mentors uh and different things will be done uh my estimated is that a basic working PC might be ready by the defon but even if the project extend by few months more I will be happy to contribute to it so yeah this was from my side thank you thank you very much any comments questions yeah yeah thank you very much um it's a great project oh we have a question from Dan whether are tradeoffs for implementing statelessness on E uh each will building the witness be permissioned uh mostly the trade off is with the latency only there will be no permission or things like that everyone every client has the feature you can think of it as a flag for example if you are while starting your client if you just pass a flag like for example DH Das stat list there will be stat mode will be enabled and all the block and along with producing a payload a simple witness will also be added to the payload and everything will go same but uh instead of just relying on the local state the client will be able to process the blog uh upon the witness also so there is nothing like permission or something like that everyone can produ yeah thanks a lot man uh yeah thank you awesome um next we have hen Heimer and the true I guess yeah let me just share the screen great go ahead cool um so hi guys I'm uh open and uh we are working on this project called rated list DHD um let me give you some uh brief you know background based on which we have come to a conclusion that this is a valid project to work on um so let me give you a brief introduction into what Das is uh so data availability sampling is basically a scheme where uh a node in the network can probabilistically identify if the data is completely available in the network without even downloading like the entire blob uh data so basically uh column datas can be sampled randomly right now it's uh being sampled from net gossip and uh am I audible I hope I'm audible right yes so good yeah uh so uh the samples are basically taken from uh subnet gossip and uh randomly sampling from other uh nodes based on which uh on a re construction the node uh identifies if if the entire data is fully available right uh so now why is Das uh in uh coming into the piure is because it's one of the parts that needs to be included uh as part of full d sharding uh so F dang Shing is basically trying to integrate the entire uh fully integrate the data uh sampling into ethereum sharding design uh which eventually will lead to independently verifying if the data uh is available while maintaining the overall security and efficiency of the network so uh now where does the DHD uh come into picture in this uh thing so right now uh the current implementation of the dstd that is being used in uh the client softwares uh is pretty aric and uh was simply not built for a a large scale implementation such as uh ethereum uh so kademlia DHD which is currently being used was basically for uh for um starting from 1 to 2 to about 100 node thing uh but right now if we see uh ethereum has a lot more nodes than that uh so basically it has no Cil resistance and uh that there are basically problems like key uh key space flooding and things like that so uh we basically attempt to try to to solve that those problems in our solution uh in rated listd um so yeah uh yes so um regarding the project uh description So what danr had proposed was uh constructing a list of all the peers in uh in the network uh and rating them based on uh based on uh how you know them basically basally so it's a friends to Friends Model where uh you take your current peers uh you add them to level one and uh then you take their peers and you construct uh a routing table like that of the entire network so that's the catch about the rated list DST is that you have a routing table that Maps the entire network I'll get into the technical details of it later but uh supporting research source shows that you know creating a social network as such has a greater Cil resistance and uh the best benefit it that sample disposal gets easy there is uh there is not one routing table that affects that acts as a bottleneck for uh seeding the entire DHD which is the case with cadmia which is used in this V5 so uh what we will be doing is that um we will be first Ashley will be drawing out a formal specification which serves an extension of the dash specification uh uh written down by I forgot um Michael simin is it but yeah it's uh it's there in The Proposal uh secondly we'll build a PO and uh the most important part uh would be to simulate and draw analyses for the security and uh the network uh parameters next slide um as I told you I'll get into the technical details is that when when these uh when the rated list or uh the routing table of one note is filled with all the notes uh the most immediate doubt we get is that how is it possible like how is it possible to have a routing node of the entire network uh in in one noes table this is actually the biggest myth uh about cadamia is that this like cadamia in general uh they call it an archaic technology because it was really for resource constrainted uh machines because that time we did not have like B machines like now right now in ethereum there are probably about like uh 20,000 uh 20,000 to 20,000 on on the El layer and they have 500,000 on the CL and uh a routing table for them is a piece of cake for current day machines so it's not a very big uh it's not a very big chunk of your RAM that will take for maintaining the routing table but it'll add a significant amount of uh security to the uh sample disposal um however right now as I said we all we have is the blog written by danr there is no formal specification so Ashley will be helping us with that uh but we know a few things about uh we know a few things about um the rated list itself is that it would sit over existing pure Discovery protocols like this V5 uh it might seem unintuitive that I just uh like lashed out on cademia and I'm saying that I'm going to use this V5 now but there is a significant difference between using something for discovery for bootstrapping then using it as an overlay Network for sample disposal so uh the layer is what matters so um yeah so the rated list would come over this V5 um we also know that we would be using deterministic selection as uh any query requires only one hop in the network and additionally we also know that the proposed DST would maintain a liveness index on a per slot basis so it would calculate all the network parameters of the pr scores for for the entire table on a p slot basis uh next slide this is uh uh so our road map is as we said uh we have to work on the formal definitions first so that we have a clear uh view of what we are going to implement then we'll Implement and then we'll verify which is like a very rough plan and it's the most same plan that we have right now uh but things might change as we go uh and find new things on the way thank you any questions very well thank you guys okay um any questions comments yeah I think it's uh it's great that uh uh that you help uh yeah uh we had presentation from dun in the EPF day where he explained the propose so I'm very happy to see that somebody actually um started working on it yeah okay um we have George here hi Mario can you hear me yeah yeah all good okay so let me share my screen a uh let me know if you can see my screen yeah yeah yeah okay uh yeah so uh I'm going to focus on the uh Max CB uh which is um uh which is talking by the EIP uh 7251 uh so um the tldd uh for my project uh is to uh focus on this uh LPR uh focus focus on this uh EIP uh because uh EIP 7251 uh they try to uh managing the maxb which uh the current implementation of this uh has been some um problem I will uh briefly introduce later and also more importantly is uh um this Pro uh this EIP has already be scoped into uh electure upgrade uh which should come um mentioned by um Team uh in 2025 U uh q1 uh or or around that time uh and the benefit of this uh EIP is uh they has the mission to control the validated size uh and that will uh uh contribute to the ssf and also the epbs So currently it has uh for future uh is already working in progress uh given the uh urgent timeline there's still two features remaining to uh to to start uh so in uh in uh in this program uh I will focus on uh to working on the remaining feature uh which is on the customer uh sing um set up the customer saing uh for the s