EPF Day @ EthCC 2024

let's get started yeah hi uh my project uh proposal is network simulations with shadow um testing sign networking is kind of hard because on local death Nets you usually don't not have any kind of latency or bandwidth restrictions which is just not realistic so yeah test net are also not really nice uh to test this because deployment on tests happens usually rather late in the development process and it's also not centralized so people just don't update their clients so you can't really test your changes also there's no Central metric collection or anything so yeah this um also not nice simulations um are a bit more um are a bit better but usually you have some simulation framework that you have to use like some l that you specifically write code for and then you have like some minimal toy examples instead of full clients which you actually want to test so a solution might be shadow shadow is a software that um originated uh from the tour project and it basically allows you to simulate full software it works by intercepting the system calls that program makes so if the program wants to send some packet it calls um the system um to send that packet but Shadow intercepts that system call and instead of actually sending that packet it just uh simulates some latency and adds some bandwidth restrictions and then reroutes that packet not to the network but to some other uh client running also locally so basically you've got everything on your machine but can kind of simulate um the network and this simulation can run um as fast as possible or as slow as necessary so if we have a lot of uh nodes this obviously um pretty um heavy on the system so we um have to slow down our simulation and Shadow basically tells the program ah only one second has passed if in reality uh 5 Seconds has have passed or the other way around so if you only need to test with a few notes you can simulate very fast and this allows us to basically quickly iterate um on on experimental changes so my project is roughly planned to be in um yeah three phases phase one um there is a project called ethereum Shadow which was developed by pop who is a researcher at the EF in early 2023 and it's kind of a framework for for um um network simulations with shadow in context of ethereum it supports gas and lighthous right now but but not actually because it's currently broken so there have been some restrictions back when Pop uh developed it and so we can't really work use current client versions which is not ideal because we of course want to um test current changes so in the first phase I want to fix um ethereum Shadow uh there will be maybe some changes even necessary in Shadow itself uh support all system calls required and extend it a bit so I want to use rest instead of G because I'm rust guy and uh and also I want to make sure that I can actually uh extract meaningful metrics from the simulation so that I uh you know know if my changes um to the networking code are um are good and also uh like uh the um EF Panda Ops guys have kosis and have some really nice uh features again um I don't know to have attacking noes uh in then simulation which is also really interesting so yeah that's first phase one I guess it will take four weeks or something like that and oops that's too far in phase two I want then of course the interesting part to run actual experiments so there are some um ideas like um pust is really Network heavy change and there are a lot of parameters in p and I want to find out if the specification currently is efficiently resilient and there are also some experimental gossip sub changes proposed so I want to test if those um improve the situation on the networking set of things and then in Lighthouse there are also some some problems to work out so there is like a message cue which um tends to behave not that nicely when there's low bandwidth because then there's a lot of memory consumption and the lious presses so I want to invest if there can be some better message curing behavior and also stuff like peer scoring we want to eject bad pi as quickly as possible but tolerate some Network factu creations of course so this might also be an interesting experiment and there's basically an endless list of experiments you can run so I guess I will find out some of these details during the project and in phase three I want if it's successful so if it's um turns out that this is really uh useful I want to make sure to support every client and also to make this this etherum Shadow thing to be as easy to use as possible so that other client teams can also benefit from it I have two mentors age menning from Sigma Prime offered to um discuss some some experiments with me and also the results of course are pretty interesting to him and pop from research who developed ethereum Shadow uh also offered me to help with all things relating to shadow and Shadow so yeah I'm pretty happy about that and that's already presentation any questions thanks for your [Applause] attention it's really cool any questions anyone online I don't see a chat but uh people we have trouble with the stream but um so you said that it's coming for tour project that was really cool what is it uh use for in tour for testing or I I yeah in tour obviously TOS also distribute the system and and they also want to use this um to have large scale uh simulations running so yeah I guess they developed there are some papers um about Shadow and yeah but it's it's general purpose so you can also use it question is it like for clients for f or also can be implemented for the as well well you can basically put anything into the simulation so you can have some full notes you can have some some light client no that's why this is so nice you can basically simulate a full network with with with full nodes light nodes some some attackers also and you can have anything uh anything you want so I me to make sure to make this yeah easily configurable so you can also test life cents with that yeah currently it works with G or and you going to implement yeah works it doesn't work unfortunately as I mentioned um um bit outdated everything so it doesn't start up but yeah it was usually planned with G because you know majority client Etc in mind and and Lighthouse but yeah okay just short how can you tweak you know parameters to to create different type of simulations modify specs or um do mean specification do you mean um simulation parameters or um um um parameters within the clients both because basically you you say you simulate the network yeah so simulation parameters like the amount of nodes is rather easily tweakable because you can just um when starting the simulation you can just say Okay I want 1,000 of of Lighthouse and 1,000 of gas and connect these to each other and behavior and their behavior well some of those parameters are heavily baked into the lighthouse code so they're basically constants so you might need to recompile it or if you want to test like half of the nodes having these parameters and half of the no having these other parameters you might need to have some like two branches or something and compile those to uh compare their behavior so yeah than yeah awesome all right thanks so hey everyone so I'm Leah we'll talk a bit about myself before presenting what I'm going to work in the next week um so basically I'm a r developer and backend developer I work currently at perer finance and my a with uh EPF despite um already doing uh protocol development M uh was from a very basic um dictate and apply task of my as a developer to move to more understanding eum research but also uh to be able to do apply research so that's why my goal and as working for um a liquid weaking protocol it's very important for me to understand uh to have a validator uh opinion and a validator position to understand what's the best for the validator and we have developed we developed some um some features to optimize as the again for the validator of course when validating and when they're doing the validator duty and one limitation currently is um for the validator if they wants to to earn M Rewards they don't have their words to say about which transaction will be included and that's why uh this topic of inclusion list was introduced and the idea is to for to include certain transaction in the current or next block and in that way the validator can still out to the blog building but have they what to say about which specific transaction can be included um also when I joined the program honestly I don't know you but I was a bit lost uh or from the research proposal to the implementation or does it work basically so I've been asking about the monor it works so maybe you can enlight me about but from what I see you have the eum research proposal then you have the spec then you have thep and then you can finally move to the implementation and for this inclusion list there was a lot of go and back uh and there was this EIP 5 uh 7547 that has been released so we are basically between the third and fourth step so between the IP and the implementation uh also inclusion list are in The Scorch scope so you know they have different pH uh in the road map and The Scorch basically is supposed to improve the validator taking experience to have a more decentralized liid staking experience and improve censorship so the IDE so this IP was released uh I think it was last October October 2023 um yet there was some controversy and not not all concern was where um were solved that's why a new proposal um has been released in June and this proposal is basically when you doing your inclusion list uh there's only a proposal that will be U that will release uh the inclusion list the is to have a committee before that was elected that was selected romly so you will have a validator um committee that will um basically agree on the Engish between it will be broadcast by the proposer and then you have different uh aggregation and evaluation about this inclusion list done by the so you can see at the slot n minus one you have this inclusion this committee that is uh created and that fall basically uh release the local inclusion list that wants to be proposed by the pro BL producer and then you will have these two step two last step about evaluating and validating by so it this proposal con basically free function maybe we can add another one that is a pre function that is election or um creating the validator committee but then we have the agregation on the inclusion L the evaluation and validation so what's the situation about this proposal so as you can see it was released 18 days ago and what will be so if we go back back to this uh how does it work from The Proposal research to implementation we're really in the early stage so the next step is to define the spec and what will be my project basically uh last week we have form a working group with the different people who wants to take part in and uh so the IDE as a r developer I will build a p r for so many Lighthouse is more convenient for me um and yeah we will have this go and back with the different people reading those page so we have the seven people group and anyone who wants to join feel free um so also the nice thing about today is I was discussing with Daniel that was in the lighthouse Discord proposing uh to implement this EIP 75 for 47s and know uh thanks to today I know basically what is the current state of development for Lighthouse so I got more idea um about how much work needs to be done in Lighthouse so yeah so my next uh goals is to reach a lighthouse team and to build together this POC for the fil proposal that's my plan [Applause] um can you elaborate more on the working group like who who is we've been some so I took people in the street and they were no the all fil and no basically it's more The Proposal uh researcher was been writing uh the proposal yeah okay okay um so so so there uh first I wish bab to have more idea about how um what was the current situation on inclusion list and fil and then then he Weir me towards Toma and then we start to speak and I don't know in two or three days a lot of people wanted to be in so we have yeah it's public uh it's it's I don't want just a telegram group but maybe we can move to a more public uh it's all right working group now but you are right yeah um yeah that's great better to have more you say that you're the only fellow working on the project though um I think so in this group right yeah yeah but anyone is welcome to join because I just heard some other people can want to work on fil so I think it's more motivating to have a multiple fellow in the group yeah yeah awesome um any questions any comments um did you Al look into grandine uh client it's also in rest um I'm not familiar with Lighthouse to be honest but I can look also yeah I will keep in mind yeah just because you have the Lighthouse of question mark so I was just wondering whether you're deciding or yeah I'm not sure yet but yeah I can look Al okay for sure I will not do in goong but that's my only opinion but okay okay awesome thank you so much the panel um I mean uh for Choice enfor okay sounds interesting F so uh go ahead yeah yeah um it's afternoon good afternoon everyone uh I'm going to talk about Fork Choice enforc inclusion list uh the second presentation was also like for this one and I was not aware about like the working group so maybe like after this step we could to uh collaborate and uh get get in sync on this project so yeah um [Music] the uh issue we have right now on interior main it is that we have this like centralized block Builders who have like huge amount of capital onchain offchain and they are doing like sophisticated transaction ordering and extracting any uh so and that is uh centralizing the whole process and uh uh and likee little by we are forgetting like it of crypto and blockchains that is uh to have a sensorship resistance system that have uh like like treat people equally so uh and as a result uh over the like past few years like multiple uh uh eips to basically stop this U uh you can see uh right now over like 60% of Builders they filter transaction based on sanction notices and like these Builders they comply with uh uh us uh list and they are censoring any transaction that is related to addresses uh in the stion list on the other hand uh validators they only uh filter 10% of the transactions so we see that uh there's like difference here with like about how validators behave and how the builders behave so what if like we could uh just get rid of all the like sensors basically and here's a design U all the credit to Au of fil U I'm just going to implement this design uh in my project uh this is on each research uh by four authors uh yeah Julian uh and some other people I don't remember all the names uh so basically the main uh idea is to have uh two committees uh for uh uh have committees for the inclusionist one inclusionist committee and one aest uh we have like two slots slots nus one and Slot n in the slot uh n minus one we select a group of validators from validator Set uh with Randal parameter uh in the begin chain and we basically create this group and this group uh every member from this group creates their own local inclusion list and they broadcast it to everyone and the proposal have has to basically uh aggregate all of this like local inclusion list and create aggregated inclusion list and the include transaction block based on that inclusion list the later slot attestors are responsible for evaluating the transaction list and the inclusion list and they are going to basically verify the block based on inclusion list and transaction list and they're going to either like accept the block or reject the Block it's like a very like simple approach and it's like in my idea it's a frame workor that we can like later on build build on top of it like you can like play play around with the evaluation function you can play around like uh this uh how you select the committee of uh committee are you have you select a committee for example u v has also posted another uh proposal about U choosing this inclusion committee B that attest committee right now in this framework there is no hard rule to how you select these committees but uh like for the like SE PC uh I'm going to go with the like random so the specification is U is on two layers uh it needs a changes on two layers both execution layer and consensus layer on consensus layer uh we need to introduce uh any new object inclusion list that is like area of inclusion List local inclusionist and aggregated inclusion list and a function that is aggregating this local inclusion and another function for evaluating the final transaction and inclusion risk like eval function it is taking inclusion aggregated inclusion list that is uh based on attestor view and the other inclusion list that is based on proposal View and the Delta parameter and based on that Delta parameter and the share of uh like basically intersection between these two sets uh decides to either reject or accept the block these are like changes to con layer and uh for the execution layer you just need to add add a new API uh to API engine for Meo to receive an inclusion L from the me so this is also uh uh one of like functions that you can play around with it or you can just go like very naive and just uh select uh random transactions uh from me so yeah uh and this is the like diagrams once again for the S have to be like more uh explain more uh is is like sequence diagram uh we have like proposals who requests uh inclusion list from commit you also meet to introduce uh new uh uh methods on network layer for getting the inclusion from other peers uh then aggregating this and build the block and for the next slot uh a tester is going to evaluate the block with aggregated inclusion list and uh it's going to either reject or accept the block I'm going to make these changes on guas and uh PR uh the goang implementation so that like that's not overlapping with the bu proposal proposal which is going to be on Rust so that to the ideal had like in Bangkok that we have devet that is running both rust and go and they like communicating each other and they working uh I think yeah so yeah thanks a it's a weird screen size you need to either just yeah okay hi everyone and today I'm going to talk about um something that I've been thinking about for years so it all started a couple of years ago when I saw a debate on Twitter where basically the Bitcoin Maxis were saying that it's impossible to to get the total eth in in circulation right uh this was I don't know like August 2020 I know exactly yeah August 2020 yeah it was a couple of years ago and I mean a lot of uninformed people like argue that it's just there's no way to to fetch the the heat Supply so I mean for people that working ethereum you know that like you can like very sucely get the supply by by there's a couple of options that we're going to see now but I just let it pass and in this cohort I saw the proposal of of team last year to to basically ingrain like a like a like a like a correct way in the Json RPC to to get the supply and the motivation is like one transparency I think it's it's like it doesn't hurt to have you know like a like a like a function that just like speeds out the the total e in circulation because right now like centralized providers like I don't know like coo or or coin market cap they do it in different ways but if you if you want to like get the total e in circulation by yourself you need to either modify the node and and do a couple of of of changes or like basically type in like all the all the ISU on rules in since the beginning so uh the the the the project is basically almost ready and how it's going to look is you're just going to like fetch uh the the if total Supply or if get total Supply whatever you're going to input like the blog number as a as a parameter and it's going to tell you exactly how how how much e is in circulation at that block and it defaults to the latest um in order to do that there there are basically two options and to do that two main options so first like after etherum migr to proof of stake the E account ability was was SP into two so you have the e in the in the execution layer and you have the e in the consensus layer so in order in order to get the from from both layers from the consensus side it's simpler in a way like how we have it right now you just iterate through all the validators balances and you just sum up the the total balance it's a little it's a little slow but but you you can optimize it from the from the execution layer um there are two basic options one is that you need to iterate over the entire State and Su up all the balances that's super inefficient and puts like a lot of a lot of burden to the to the node and then the second option that Cena from gu help me device it is H to there's a there's a live Tracer currently in in G where on every block it just tells you the Delta of if and basically you you save all of that in a in a file that's currently on on mainor already and with with with this new Json RPC it's going to be able to iterate over like the entire like the entire chain when it's sinking and it's going to speed out the total balance once you have the the total e in the execution layer and in the consensus layer H you just like sum up the balances and subtract the the deposits this can also like the idea is that is line compatible so you're going to be able to do it with G with ref with nether mind like probably each client it's going to be a little bit different but the the specification needs to be the same so we're going to choose with the option number two then like this like the simplified like mental model of how the things work a user is just going to call the if total Supply like any other you know Json RPC request then once the node receives that it's going to do the execution layer and the consensus layer like in parallel from the execution layer as I said said before it's just going to sum up all the Delta from since Genesis to to the last block but you only do that once because what after you do that request you just cach the the result and then the next cycle is just going to be way way faster and from the consensus side well how I mentioned just some of the validate re balances um and then you just like subtract the the deposits then at the beginning it's going to be like a like an optional flag because we don't know how how how how much extra resources we're going to put on the Node so th those are like the challenges like really measure you know memory disc IO that that's very expensive and and CPU usage because we want to like we don't want to put like extra extra Bor to the to to the node and and and hopefully like the the extra resources needed to to do this are quite low so so we can implement this like as a default and and not not as an optional that uh yeah I mean the the goal of the project is this and again like the main reason is that um I think it's very important you know for for transparency and not so much for the people in the like deep inside the etherum community that they know like how how this works but more you know as a like first of all to eliminate that stupid debate that you cannot get the total lead Supply and second of all because in si so it I thought like it was going to be implemented you know in a year and or or six months but after four years I I didn't see it implemented so I I'll just say I'm going to I'm going to take it so yeah thank [Music] you all right uh hi everyone I'm Ben I'm going to no it's not framing the set frames because it's in PDF doesn't so I'm going to talk about uh my project which is the specification of eods or what uh this is the the acronym I named uh enshrined operator delegator separation so what is what does eods stand for I just said uh it's basically the separation between uh operators not operators delegators and um you can try to speak this way sorry okay this way yeah so again eods it's about separating operators from uh delegators at protocol level so basically introducing an explicit mechanism to have a delegation uh on chain it results in an even further separation than of the validator role now we now have uh epbs uh getting uh PR and implemented and post that eods could be like a further even further separation of or unbundling of the validator role uh why is it important and uh why can it be done of protocol so paraphrasing vitalic we we need to find like a like a community uh approved uh solution for what we do regarding you know the eth the large eth holders that want return for their partic participation in protocol uh they might be lazy so they might just you know if if you if we fail to come up with a solution to this they might just continue uh to put their asset in uh in centralized Solutions like we see today in staking and we do not have we do not have like a meaningful role today for these delegators uh second second line behind the philosophy of enshrining uh this separation would be uh bolstering security because once we would have uh separated the if delegators from nod operators we could actually improve sec security protocol with uh with giving delegators something to do inside I mean uh in consensus like like be part of a light consensus mechanism that could improve censorship resistance uh for example uh like delegates could uh first of all they could be like opinionated so U I'm I'm a large e holder and want to delegate to a certain notd operator based on certain you know criteria and uh and and uh second of all like like a delegator I could like uh input or bring my input into the inclusion list um gadget for example why can it be done of protocol because we're kind of already doing it of protocol and we see the current state of centralization of uh liquid staking so yeah underlining again uh the the reasons behind the why fa failing to failing to have a solution for the L large e holders could uh could uh you know lead to to further centralization in staking uh so the project will be split in two parts the first part will be a more practical uh one meaning the actual writing of the of the specification and the second part it's more of the philosophical research part of the project yeah the research part would be about finding uh and and tuning this uh this role about what could what could a meaningful role be for delegators in in ethereum so moving a bit more into depth uh first part writing uh writing the specs um yeah so today there's there's no way to delegate in protocol everybody delegates indirectly somehow using staking uh staking platforms more or less uh centralized and the solution of the project would be to provide this explicit delegation mechanism uh where delegates would like use the the deposit um U process that we use today but use it to deposit and then actually delegate to targeted uh operators that could be of their of their choice and uh even initiate uh delegated triggered withdrawals I I don't have a real name name for that but basically that's the idea that uh a delegate could ask like for to get its uh its principle back from that certain node operator so a bit of a high level view of the workflow we could add some lines to the structure that is uh now depicting uh that is now the deposit uh process so basically I think we could I have a straw man uh in the in the project proposal I'm not going to get into that detail but basically we can add new Fields like is this uh depositor delegator or or like a buan uh variable is it delegator like it can be true or false we can add The POP key of the targeted validator if you are a delegator and obviously the pub key of the delegator uh then inside uh inside beon State uh there were most likely in the strawman that I'm I'm drafting with Barnaby we have like this new class in the in the like a new container called the delegator and uh basically we would let get like this in protocol delegation constructing the constructing the registry of of delegators alongside with a registry of validators like index and balances uh separate from validators what I see as deliverable deliverables for part one would be the the actually uh changes that needs to be done to consensus layer you know to Bon chain to validator I don't think for choice would need to be modified in the second part there is Arch uh part uh a bit more tricky it's about finding that that that role for the for the delegator already by by doing the first part we would get like opiniated delegators to be able to to put in their opinion by choosing the the actual validator the popy of the of the targeted validator but also there's a lot of work to be done in research ing how delegators can input their view into the those sensorship resistance gadgets I've been uh talking about obviously inclusion Leist multiplicity gadgets but we were just talking today that multiplicity Gadget most likely gets aned by fossil and uh in the in the rainbow staking framework uh there's something about uh even uh you know light validators because that that I'm sorry I failed to to say this delegators would need to run light notes and uh and basically provision light protocols services and uh that could even act as a back stop or alternative uh signal to to guas per participants so we would not get most likely we would not get delegators to be finality participants maybe more uh like on the periphery of of the consensus uh like a light like a light service okay uh I basically talked to talked about this yeah uh after reading the orbit ssf uh these days is I realize that uh there are there are consolidation incentivization uh you know uh calculation or formulas that need to be that uh we need to come up with in uh in the scenario of ssf like how do we how do we design uh consolidation incens incentivization how do we design risk adjusted rewards and I think I'm going to see this during the the project and the research but I think we could the protocol could use the signal of are you are you uh delegated or are you just not operating when calculated this uh calculating this uh risk uh uh these risk profiles of uh of finality participants uh again about uh ators trigger withdrawals this should improve stakers user experience and the whole project theoretically should uh you know uh work on the on on these solutions to find the decentralization uh solutions for for liquid staking short on the road map I'm I'm splitting the project in two eight weeks uh uh for first part eight weeks for uh second part and uh yeah challenges uh like Rodriguez said it uh of course is not similar but its memory cost and computational overhead will will influence the design most likely and uh I've been I've been having some discussions with uh pus uh for him to look over the the design because most likely it would be it would be built on uh the some specifications that would include epbs I'm I reckon yeah I encourage you to take a look at the project proposal and for a more in depth about the project and if there are any [Applause] questions no questions for them anyone on the stream maybe it's not uh I don't see the chat yeah it's yeah have you this no i' I've actually uh I I have like a strawman together with the mentor with barnabi and we're trying to you know actually we have the straw man is drafted and now during the the the project I'm going to build on it but I haven't I just discussed formally with barnab and with pus and they will take a look at the design and you before to uh I haven't thought about it actually yeah it's it it's a bit yeah no it's okay I wanted to ask just what preventing someone maybe it's not an issue they operating a note and they simp use a different address to delegate themselves run that note then they would just be delegating to their themselves is like possible well researching for for the project I uh in and this includes uh this includes like research I've read by you know whomever because everybody has like the same uh idea you it's very hard to impose uh so disruptive changes and not affect you know staking businesses so I think first of all maybe it would be like an optin stuff and some people will choose to do this to improve protocols security some will not pick it up it if it could be like implemented like like mandatory uh I I I don't know it will have to come up during the research uh during the research part and during the EIP I think because introducing deleg delegation it's disruptive somehow because at this point the protocol just know sters so it's the protocol is happy quote byquote to just know these actors which are stakers um so now we're introducing a new class and how how do we do that without breaking stuff vitalic says in one of his post that at the beginning maybe it's an optin thing like we just do it to improve security we'll see how how it plays out [Applause] okay hi I'm gilia and today I'm going to be talking about benchmarking and pushing the limits of SSC so I at first you guys may remember I was looking into rlp serialization after talking to some people in the community I decided to pivot to looking at ssz instead because that's where um most of the community effort seems to be going into and uh possibly more room for improvements and I picked up serialization because I wanted to work on so-called uh nut nuts and bolts of the protocol for this uh core Dev Fellowship I thought it would be a good experience and something I don't usually do um like looking at like I guess lower level stuff in a protocol and yeah so I'm going to move on to the agenda so I'm going to be talking about what is serialization and ssz then I'm going to talk about benchmarking ssz and then a high performance implementation that I want to work on and finally the road map and challenges so what is serialization well serialization is when you transform a data structure into a format usually in a bytes that can be stored and transmitted over a network and so they can't dat structures regularly can't be transmitted as is question can't be transmitted as is so must be serialized on one end and der serialized on the other and this is especially true since in memory representation might be different um from one implementation to another especially because we have a bunch of different clients in different languages so this requires a common encoding format for the protocol uh ssz uh well simple serialize also known as SSC is a new serialization scheme on ethereum 2 meant to replace recursive length prefix encoding rlp on ethereum one um uses a schema to determine how to serialize and deserialize data as opposed to rlp and which is good because schemas are must have in a performance serialization format um and it also allows for some level of direct access it's deterministic like rlp so so when hashed or the the data always serializes the same way um which is important for consensus right you don't want to somehow serial get a different serialized output when talking about the same data um over here have a nice little screenshot from uh the upgrading ethereum book which shows how an index at the station is serialized um going to move on sh on time next I'm going to talk about merization um this is how we create a short digest or a hash of serialized objects in a theum right naturally you could just hash an object um but what happens especially um in a large Network like ethereum where updates may happen to some parts of state is you don't want to have to rehash the entire data all over again when you're only modifying a small part merization is a way to Hash your data into a sort of well Merkel tree kind of structure in such a way that modifying a small part of it um only requires a few updates um and you can just reuse the same sub trees you've hashed before to recompute your root hash so um along with SSC this method for constructing uh hashes of complex objects was devised for consistent hashing across the entire ecosystem and like different clients um yes it's also useful for small proofs for light clients I don't want to hold too much data so now um now that I've talked about what serialization is I'm going to go into the projects two little projects that I want to work on related to ssz um notably uh tooling for benchmarking ssz crates starting off with like rust implementations of ssz um yes so I want to create a benchmarking Suite that can test any create that implements um some sort of encode or decode trait and Compares how they perform against each other on the same data and so this would work with like some blockchain data set uh either just like obtained some not too sure about how yet but obtained somehow or either on like real time blockchain data as it comes in and so I have a few ideas for how we could show um performance uh have some random images here just to kind of show the gist of what I'm going for um so I'd like to use some sort of differential flame graph approach to kind of see what's happening under the hood uh for different implementations to see why one create why why one implementation might perform better than others um I'll get a little bit more into flame grass later on in the talk um obviously you can plot run times against each other like how they differ on speed and then also some useful and insightful reports on performance uh this is something that I find is like missing in the ecosystem uh not so much there's a lot of like ssse implementations not a lot on how they differ what tradeoffs come with which and how they really perform against each other on like actual blockchain data and then next so the benchmarking Suite was a practical project that I could definitely deliver whereas I'm also curious in a high performance ssse implementation um but this is more of like a research project which may or may not pan out but I think there's some interesting ideas here that I want to try and so had some ideas for possible improvements like in um implementing like SD instructions notably uh for decoding little Indian integers that uh SS uses but we can also use it wherever it may sense that's still uh to be decided and then next I want to talk about taking advantage of how we hash uh these serialized objects with the so-called sponge hash constructions to iter iteratively encode and absorb the input in lock step fashion so we can serialize and hash in a single pass so I got I went into earlier about how we serialize and then we meriz so we can obtain a consistent like short digest that we can all that all clients can agree on sure you can optimize the serialization and an optimize the hashing but if you know you're going to do both maybe there's some sort of implementation that's aware of the endtoend flow and take advantage of this so I'm going to talk about the sponge instructions in the next slide um so everyone here is familiar with ketak 256 the hash function did you know it belongs to a class of hash functions called sponge constructions and so these there's even a nice little image here uh these work by two phases an absorption phase and a squeezing phase so in the absorption phase your input is split into these R size chunks that are iteratively iteratively absorbed into your initial State s once all the input once the entire input is consumed then you squeeze it out into your 32 byte hash so I was thinking what if what gains could we have if we start absorbing as soon as an our sized encoded chunk is ready and would that mean that we're able to Hash an encode and hash in a single pass versus encoding and then hashing which is two passes um and I think even a small speed up might be meaningful considering we're doing this a lot in the protocol and so I was curious about this um the timeline not too sure on the amount of weeks yet to be honest but have these four phases where I implement the basic functionality of the benchmarking seat and I test existing as a z crates and then again I'm thinking the flame graph part will be the most difficult so I'm going to leave that for last in the benchmarking Suite next working on the uh my SS crate starting with the encode and hashing functionality and then adding vectorization wherever possible next I would continue working on the crate and then uh test the new crate on the benchmarking suite and see how it performs and then next write a report and documentation and how this um encode and hashing idea might be of independent interest next the challenges there's a lot of them uh first of all scoping issues I might have to tweak the ideas here to make sure that this is viable within the time frame of the cohort uh second flame graphs are typically used for testing how one implementation runs flame graph diffs will compare how your current implementation compares to the last one and so it's not really a tool for comparing two different implementations but I figured there might be some something we can do here given that we're implementing the same traits so it's the same functions the underlying implementation might be different but there might be some overlap thirdly uh adding SD vectorization will make the implementation a lot more complex which might make it hard to maintain an upgrade and then lastly uh a a major concern with this encode and hashing and lock step idea that I brought up is it's possible that the tooling needed to to kind of manage this encoding and hashing sequentially might introduce overhead which would just get rid of any potential gains that could have been gone with this approach and hence why I left the uh implementation to the end of the fa of uh the cohort because it was more of like a research idea I wanted to try some stuff out um yes that's it for challenges um you guys you can find me in my email or on Twitter that's also my Discord username if you want to find me there any questions oh yeah thank you for L yeah Peter I was going to ask about Peter yeah have you seen it I saw him tweet about it did he try new last weeking on as fast as see few otheres M so have a look at that first com okay and second comment if you're looking atar implementations and you want a place where be high impact that's probably a place to put it because the CH that go the future not okay yeah look to the Peter's new implementation like the optimization that he made might be interesting but also like suggestion for him to improve it further and like one one things you can Benchmark against when you make your own for example as well you know and maybe see his benchmarks like how he yeah how he handles it if you have mons I see and I think he put his strategy down there already yeah and I actually quite like the approach as far as I understand he's taking the objects from the consensus T the S objects and then passing the enoder and deod on that because the consensus tests areally implemented by implementation should be able to pass them okay so you can already have like this this thing of actually what is happening in the client and then your okay yeah thanks for the suggestion I like saw the Tweet when it first came up but it was only like two tweets about it I didn't really see much progress yet but I'll check it now GitHub Peter something/ ssz it's ssz repo in his GitHub and you can find it the benchmarks he has like two tables with flow with stream stream of bytes and object so you can you can you can see the numbers and you something to compare to and you have some strategy to do yeah check it out okay I mean it's really cool so I think like uh it can can really help you know him or you if you both do that okay nice yeah I'll do that yeah cool cool um anything else thank you so good afternoon everyone uh so today I'll be talking about what I have been working on for the past uh few weeks and I have been basically looking around uh consensus related research and finality related research and uh that is something that I want to continue during this fellowship and uh uh that is my topic for today so it's going to be how can we achieve secure Speedy finality so ssf now ssf stands for single slot finality I'll get to why I use this uh term later on the presentation so uh before I start out a little bit about myself so hi my name is Yash uh I'm a final engineering student and I'm also so I work at authentic labs and yeah I'm just in general uh interested about consensus mechanisms protocol engineering and Z as well so uh getting into it so currently the consens mechanism in eum is Gasper which takes around 13 to 15 minutes to achieve finality to eox and uh that uh that has a few problems with it so like Gasper one of the problems that Gasper has it has two mechanisms like intertwined with each other because of which there are a lot of there are a lot of like reor related issues and a lot of complexities in the mechanism itself and also waiting 13 to 15 minutes for a transaction to get finalized is also something that is not good for user experience people don't tend to wait that long uh to confirm a transaction so there has been a lot of research done to bring that down possibly to a single slot finality where propos a block and before the proposal of the next block the previous block is already finalized uh stuff like this is already implemented and works in other consensus mechanisms like tender uh but like one of the reasons why we cannot just copy paste is because uh Tender Is Not uh available if more than a third of the total valid s goes offline so it's a it has availability issues it ethereum does not want that ethereum wants to be available even if like the majority of vals go offline so we need to come up with something new and uh uh that is basically what FS ssf research is before going into that let's very quick overview about Gasper I'm sure that everyone here is uh highly familiar with this but basically yeah there are two mechanisms lmd ghost uh which uh basically is like the availability availability prot protol it tells you like which block is part of the canonical chain based on like votes the weight of the votes on each sub tree and then there's a Casper FFG which is which basically finalizes blocks in like every two EPO so what happens like the main thing here if anyone is unfamiliar is that there is a link from one block to another block uh in Casper FFG when like basically when you vote in an Epoch you are basically saying that okay this block is correct uh so basically what you're doing is you're justifying that block like when someone links to your block that block is Justified and then in the next Epoch if someone links your block to justify another block that means that the previous block has a like the justification has been acknowledged by everyone in the network so this blog is finalized so like this is a rough a of Casper so like the important thing is that in order to achieve finality you need basically two rounds of confirmation one to understand that the thing that is propose is correct and the second time to ensure that everyone in the network did uh uh have that same opinion as you uh and yeah these like the problems that are with gas like the reor related issues uh interaction related issues between the two mechanisms and another thing Rel to ux is the time is quite huge so this is a proposal that was put forward by franch Esco and Luca I think sometime last year uh where what you do is that uh you divide the slot into four separate Subs slots so I think right now there are three separate sub Subs slots you add another one uh and as you can imagine the other one is like the second attest station inside that slot only so like you have the proposal then you have the head word which is like kind is there then you have another thing called the FFG V which is which is used for the fast confirmation uh of that block and then you have something called the acknowledge and then you can go and propose the block again uh so uh like the current problems in this uh like potential problems is that uh doing two rounds of voting inside a single slot can uh cost a lot of overhead you cannot just have two slots because like since the validate ass sets are also uh increasing what happens is that uh aggregating the signatures and like collecting it gossiping around around in the entire network gets uh really costly and it takes a lot of time so like the timings of the slots and like the subs slots will increase a lot if you use an architecture like this so there has been more research into this uh and algorithms like orbit ssf which was quite recent it was like legit the orbit ssf e Forum was released I think last week or like in the last two weeks so it's quite recent basically what it says is that you either like have a cap on the economic security or basically you have a cap on the validator set so you get uh like currently in gas what happens is that whenever you like propose a block like so like because of the theum consensus it's kind of understood that okay most probably this block will be finalized because like if it's not finalized then something has gone wrong which is not probable but like yeah until finality there is a there will be no slashing so like uh if there are any reords before finality there will not be any economic loss to anyone and then after finality there will be you have Economic Security after two EPO so what orbit ssf does is that it breaks the uh breaks the committee sets so like after each slot a small committee can attest to attest to your block and finalize it within that same slot it's like a very small committee so that you don't have problems like uh like how do you handle such a large valid set and how do you aggregate so many signatures and stuff like that so you have small small committees which keep attach to it after every block and then slowly slowly towards uh after a few slots you might have the full Economic Security so this is uh like the current state of research in the space uh so what I have recently read uh is that vitalik recently published a Blog I think a few days ago uh which was the about slots and EPO in which he mentioned uh what can be done to increase finality to like improve finality on ethereum and on l2s and uh there are there are a lot of slot and Epoch related architectures like there the original ssf architecture there is this orbit SF that's new uh a talk given by Francisco in the eth study uh group if someone uh knows that in that talk also he mentioned about another proposal that they might be working on something like a three slot finality so like you achieve finality after three slots like a there's a proposal in one slot there's a head in the other slot and then there's a uh confir in a third slot so there's a lot lot of different algorithms and models out there and uh even vitalic in that blog that I was talking about he mentioned something that like the L2 pre-c confirmations if you make the pre-con if you make pre- confirmations committee based uh then that is also somewhat similar to having single slot finality but on layer twos right so there's also so basically this entire space is quite raw and uh what I hope to achieve uh during the course of the next four to five months is basically understand uh all these new design patterns that are popping up that have popped up in the past few months and like whatever work is currently going on uh and understand finality architectures that are like not related to single slots like you saw that orbit s gives Economic Security like it it steadily increases Security in slot by slot so it's not technically single slot finality but uh it is better than I guess what the current implementation is and like the orbit paper itself is quite recent so there are there could be security issues in that there could be uh some other problems that haven't been thought of yet so like there needs to be a lot of due diligence and research to even ensure that this uh proposal is also something that has a chance to maybe uh See the Light of the day and uh another thing I can work on is basically compare SL and architectures on l1's and l2s like talking about uh committee committee brief of confirmations on ler twos and how those could be different from ssf on ler one and what could be a better road map for ethereum and uh yeah I guess that's that like yeah the uh the title that I had at the start like secure Speedy finality that is something that vitalic proper that is like a new acronym for ssf that we propos in that blog uh because as you can see there are so many architectures that are not particularly single slot so it's like a renaming from me like from minor to maximal because of the switch from P to p s uh and yeah that is uh it about presentation thank you for listening does any have any questions other CH sub and it's not problem any I guess like we are trying to like reinvent the it's like problem like PL or like St like shade and why not just use yeah so like uh algorithms like hot stuff and like tender basically what the problem is that they're not available if more than 66% of the validator set is offline uh no sorry if more than 30 33% of valid is offline if they go offline you don't reach that super majority Quorum and if you don't reach a quorum then you don't have finality ethereum does not want that eum has made like a decision that it has it wants to be available like the block production must never stop it should go on that's why eum has lmd ghost lmd ghost basically uh whenever you whenever like validators propose uh like sorry not propose ADD test on blocks these vs basically add weights to those blocks so like if you have a block and then there are like two conflicting blocks and there like two blocks after that so like let's say there's a finalized block and after that there are multiple blocks just uh yeah so like let's say that this is a finalized block and then you have like sub trees there are like trees so like you don't know where how to choose so like lmd goes an algorithm to choose which uh is the head block that you can get the canonical chain and uh it is done by like okay how many vs does this have how many vs does this have and then you basically P them all together and understand what is the like the most valid block but then this is a probabilistic mechanism this is not finality finality achieves when there is a vote on a block and then there is a link uh of justification from that block to another block so like when you vote on something you justify it because a previous block has a link to it and then uh when you justify another block you basically draw the link from the Justified block to the new block that is when finality is achieved and in order for this to happen there has to be more than 66% votes uh on that block so if I'm right now prioritizes availability and this existing sling single slot architectures they do not provide uh availability that's why anyone else did I answer your question right I think thank you hi everyone I'm Bastin and uh previously I worked at bride ID on on chain identity and Ubi distributions and since two months ago I've been focusing on two three months ago I've been focusing on core development and I found out about the EPF the key on a random uh comment on Reddit and yeah I've been uh here so what I'm working on is uh adding flying support to prism and yeah so right now the network looks something like this there are a bunch of full nodes uh the consensus the beacon full nodes and some of them are relators and some of them are not and what these nodes have to do is that each of them gets uh at each like for each block each of them gets a block header uh set of transactions uh set of attestations and some other payloads about maybe uh slashings or withdrawals or deposits or other stuff and what the full notes have to do is that they have to verify the header they have to verify transactions and verify the state changes they have to check the attestations they have to check if there is like other payloads they have to check that as well they also have to do the uh PR fake uh C checks like if is the blog proposer valid or something and then uh after all that they have to actually apply the state transition function on those transactions and keep up with the chain and this is a very uh well computation heavy process so you cannot right now have this on your phone or some low-end uh device uh so the concept of light clients has been uh introduced and this is what the network would look like with like clients uh a Beacon Light node would connect to a full node that supports light clients right and yeah in that way and what happens here is that at each block uh what the light client gets is these it gets the block header it gets a same commit signature it's one field and a same Community bit field it's another field and uh it gets a list of the next s committee public keys and what it has to do is that verify the signature and check the bit bit field to basically verify the header and accept or reject that header as part of the chain that the full node is Flaming uh it to be and it just needs to hold on to the next thing committee for uh The Next Period of uh updates and checks that if they are the same and the light client does not hold any state so it doesn't have to do any state computations and it just whenever it needs uh asks the full Noe about some like queries the full Noe about some part of the state and using uh proofs it can because it has the block headers and it has the chain of the block headers it can uh very easily uh check if the state that the full nodes uh is returning is actually part of the chain or not yeah so that's basically uh what the light client is and what the network would look like and right now uh light client support is only uh implemented in L star and Nimbus and uh so we're working on uh adding that also to the prism client and the road map for doing this would is something like this uh we would have to we've done part of that but read and understand the light client specs and uh because there are there is uh an implementation a part part of the implementation already from a previous contributor uh we would have to read and evaluate uh the code and compare it to the uh light client specs and then update uh some of the implementation that's outdated and add and Implement what's left and then uh we would have to test it internally uh using unit tests and uh then we would have to test it against uh Nimbus and loar to see if everything works the same across all the uh clients and uh after all that uh we could uh implement the improvements that uh the mentor for this project uh Mr kopa uh suggested I cannot pronounce his first name and uh yeah so we two great guests here with us today uh par and Terren um yeah honored to have you here thank you so much for coming who um again the idea of the EPF day is also to meet the mentors also to meet the actual people working on the core of the ethereum on the client on the testing on all these all these important parts of it and um so one thing that I'm hoping to get you guys can get out of it is that to realize that these people are also human um like they might sound like these crazy Geniuses doing you know uh fixing the whole whole ethereum protocol and so on uh but they are they're really just cool people that you can hang out with that you can you can get to uh get to know them so that's what I was hoping to do in this panel just to get to know you a little and then we can maybe get to some technical topics if you have any questions uh I would say about any part of the protocol you guys guys know everything that's right uh but to be specific party um is from the dev P off team actually I believe you're head of the Panda Ops am I right he is like the the the humble head of the of the panda Ops Team so doing the uh the devop tooling the testing the uh helping with with making the test Nets run and and and uh doing the the leg work for all the client teams to to make sure that they they ship something and it can actually run somewhere ter is from the prism client uh you work on the epbs what do you work on I'm doing mostly epbs these days but I still work on prism clent I still code here and there but mostly on the EIP word okay so new eips go prism consensus layer so we have two experts here but I believe that if you ask about any part of the protocol they will have some good answer for you or point you to the right person so think about some questions but I have first few questions and just to start really slow just to get to know you how did you guys get into ethereum what brought you here how did you end up being here today actually your story is more interesting than M it's it's all right it's all right I can that's it's easy so uh I was first interested I think as a lot of people in the space are with Bitcoin um I heard about it when I was in high school and the interesting part for me was um so I I grew up in India and at the time India was still relatively disconnected from the Global Financial system um and I was under the age of 18 which means you can't really open a bank account or anything uh but I still found it cool to I don't know build a website and try and get paid for it or write some words on online and get paid for it threee AI generation days you would have an Indian dude like me write up your website article and then you I still remember I think it was 70 cents for 100 words or something which was great really good money as a high schooler um the problem was I had a PayPal account and at some point PayPal started doing verification and once they start doing verification under the age of 18 from a country that isn't PayPal verified you can forget about that account um I found Bitcoin interesting uh for pretty much the permission list reason um although it was kind of limited College started there wasn't that much more you could do with Bitcoin so I just did dig into it deeper uh until I finished my bachelors and a friend of mine introduced me to ethereum this was I think around the Dow um and I thought oh this is insanely cool you can actually program money you can build everything that you could imagine on top of it I should probably spend some time looking into it uh but I was doing an electrical engineering Masters at the time uh so I was more on the security how do you make sure that if I have a embedded system in a car that it doesn't just crash and then hit a wall right uh that that's the kind of training I I had uh the formal training um and that's also the nice thing about University in I had moved to Germany at the time and the nice thing about University in Germany is uh it's free so you can actually take up whatever course you want uh and you don't actually have to sign up for it you can just show up at a class and attend it um and that's actually where I met Gonzalo who's also sitting here he was doing mechanical engineering at the time um and we both thought blockchain was interesting and my univers our University offered a blockchain course except the first class was cancelled and since we both hadn't signed up for the class we both didn't know it was cancelled we just sat there um expecting something to happen and the class was like uh held at a facility that's about an hour away from the city so at some point it's like the Walk of Shame with someone you don't know and like okay how do I how do we get back to the city do we do something wrong I don't know um and then we got to talk again it was um it kind of started the journey into learning more about uh blockchains and ethereum and when it came to doing uh my M thesis I thought this is really cool let me try combining um uh what I know about embedded systems along with ethereum so I tried like a small project or thesis about it and that was that was my real introduction into the world wait what was the project how do you combine embedded systems it was It was kind of interesting so I was looking at uh ethereum as the way to do key exchange and then you can reduce the size of the keys you're doing and uh the size of the keys that you're using and if you're using smaller keys on really small embedded systems um every bite counts yeah so you can offer the same amount of security but use like a decentralized key exchange mechanism um it was it was really interesting to just think about it trying implementing it and the University was great to like support me and um like yeah why did you do that and that's I think analogous to what you guys have with the EPF today it didn't exist back then uh but thankfully I was in a situation where the University was supportive on the topic um and I think after a few months of looking into it um I would I wanted to look for a job also practical reasons needed money needed Visa all of those things um and I decided to apply at different companies working on different blockchain topics and one of them happened to be uh slockit so if you guys know about the Dow hack slock is the company that was um writing the Dow so the one that broke the down best reputation amazing right so at that time they pivoted so they were working on I mean the D they kind of had to Pivot so they were looking at embedd how to combine embedded systems and blockchain perfect for me right um and at the time they were building the smallest evm verifier that you can build uh it was 500 something kilobytes and it would fit in an embedded system and you can send it proofs and verify it uh it worked really really nicely um and it was a great place for me to for me to join I had the right skill sets for it uh the people there were amazing like Kristoff Yan was the head of slockit at the time and he was literally in the ethereum founding team so he would do these sessions once a month where he would just Deep dive into like how ethereum works and it was a very nice Vibe and it was a small city in Germany population 12,000 so there's not much to do besides meet with your co-workers um so it was a very very nice VI and I'm still very much in touch with them um and I happened to sit next to the guy who uh was the devops engineer at loet and we got along really really well so at some point I was like okay embedded systems are boring let me do devops and devops is not boring okay my U I think my whole life is just like serip just give yourself the chance and do something if you find something interesting just try it out um and I did about two years of that I learned everything I know about devops from him and um another point of and Deputy is Justin Drake from the eum foundation um tweeted about the fact that the EF was starting a security team and he just put up like an email address and like does anyone want to apply send your applications here uh I had a nice job I had people I really like working with like why not try this out uh so I just wrote up a bunch of ideas on what I thought they could improve bunch of things I could do and send it him I did not get the security job CU I had no training for security uh but he found the idea was interesting so he still had a call with me and they essentially just set up the devops job for me because I had a lot of ideas and um was enthusiastic about it and I was working with um medie from the lighthouse team at the time because medie was doing a lot of fuzzing and um it was interesting how he was doing the fuzzing they would manually run like 20 fuzzers and manually check that there were issues in these fuzzers I like this is probably a weekend job for me to automate and that was essentially what I did and uh this was still before I even got the job I had just done like the first interview and I was just like well there's an open source project no one has to give me permission to actually implement this uh so I just wrote a bunch of anable scripts and I spoke to Med and like hey I think I saved you like a few hours of a week and probably made your fing more efficient um and I think that's the first time I got really into the E2 side of things cuz I actually had to learn okay how is this stuff working what do you have to deploy how they connect and I think the lighthouse blog from 2019 November still has a mention of how I uh the automation had find a few bugs just before the we chain went live which was yeah it was super super interesting and very motivating um yeah and then since I got I got a job at the EF and since then I've been working on testing and security nice nice I think that's the long version of the yeah the journey yeah uh but thank you for sharing all that it's it's very cool I also relate to of it but I will maybe say it later teren so you want to share your sure yeah so my stories fre to elaborate more my stor is probably more relatable than most people here so uh end of 2017 I bought some e the price went up 20% and I was like oh this is awesome I'm gonna I'm G look more into it then um I subscribed to this Reddit ethereum um subreddit back then it was a lot more like um more like used in a way like people actually use it like I I gu the right way to promote technology so I saw Bal post about scalability on ethereum so he was looking back then he was working on this Ro map it's extion sharding so the chardine through small com track and he was looking for teams to work on that and I was like well this is really cool but I don't know where to start because I have zero knowledge of how it works in general and then um but then there are people on the same R comments with the same questions it's that how do we start how do I start so we created this like chat room basic basically and that was Rob and Preston which I started the journey with and then we didn't know what we were doing most of the time but then we know we wanted to work on ethereum and then we know we like it to work on gold land and that is the language we use for Chris so uh fast forward two months later we were just like basically making incremental progress but we're not sure like if what we're doing is right or wrong then um sh way invited us to this Workshop in Taiwan to talk about sharding so there we met like bunch of or original ethereum like visioners right like was there uh Gavin wood was there and a lot of people were there so yeah so that was kind of the eye that that was the eye opening moment for me to basically like continue working on it knowing this is interesting um and during those time like basically this this was a part-time job for me and most people just working onm just because like back then the infrastructure wasn't so good right to work onm you kind of have to um basically basally have a full-time job otherwise like there's no money to be made basically right and that's unfortunate but it is what it is so we're continue working on it for six month and then we're like well we're not making too much progress here right just this is only like two to two to three hours a day and then we still have a fulltime job and then I mean some of us are actually working on this doing fulltime job which we're not supposed to but then we're like okay what do we do so then I guess there was some complaints on Twitter not from me but people were like well if this is the vision we want to do can we fund this right like where's the money basically and then like so then there so that's that so that's basically the funding begin so then we got grants from ethereum and then another fun fact like people were complaining and because it yolo sent client him 1,000 e at that time but back then if was like $100 so it was like a $100,000 but then that was cool so we got enough money to do this full time basically so um let's see what year was that I guess so this was 2018 so end of 2018 we become fulltime basically on prism working on etherum and then there we're the first team I think there was no other team that's working on so we're on the first team we're working on this like Shing Ro map and the and then on the same parallel at the same parallel universe there was this like proofer State world map basically but it's also using the smart contract as well and that was what Danny EIP 1011 basically and then and then I guess like at some point during 2018 World I well this doesn't make sense actually sorry before that Justin Drake