Daily Recap, Layer 1 R&D - Day 2

[Music] okay we're gonna do a similar thing as yesterday we're gonna run through the sessions somebody from the session will come up say maybe a little bit about what happened if we solved any of those fundamental problems and maybe next steps or where to collaborate moving forward like yesterday if you think you're the person who's supposed to do that you are so just come up um let us go with i'm going to start from the right on my schedule and start with portal so we got portal portal network primer and execution client q a told some people about how it's all put together talked a little bit about the talks with some of the execution teams on sort of like the idea between whether or not their users are the network or users and there's sort of a bit of a spread um i don't know how much else there is to say there we just like went into relatively some breadth and depth of how it all gets put together uh yep uh we talked to them a little i should just do all right we talked a little bit later about client diversity i made a suggestion that like if we actually care about client diversity then then we may need to do some like actual changes to how clients are being built or changes at the networking level things like that again some like fun little conversations with all the different client teams on kind of how right what are you building your client for what's the road map who are your users is it network is it users what's the plan uh did a deep and then did a deep dive at the end of the day on specifically house how the portal network handles state which is like the most complicated thing that we had to do and it's complicated oh and and geth promised that they're going to solve all of our problems for us thank you um in that same room we had a bunch of four four four four four stuff going on um i think i mispronounced that uh the so we had the eip44s prototype does anybody want to go over how that session went uh right so the first one was a prototype of stuff where's henry is he in here hello henry anyway uh henry dieff i mentioned him earlier he's here somewhere he was working on a prototype of some of the data formatting and import and export from geth so he gave that demo i was super cool and then like a recurring theme through this like we had different people come to each session and it was just kind of like answering a bunch of just like general questions about like how the whole thing would work that was like a recurring theme to the day of just like what are kind of the basics of like how's this history structured and who holds it um but either way so we had some of that uh ah yes i should mention this so yasik was there he also looks somewhere i swear there's people oh he's over there so he's been working on this idea of era files as a consistent layer and basically is one of these structures so that's that's kind of what we segued into after the demo was like how would you actually structure these things uh the history and uh if you want to hear more and talk to them about that but basically there's a nice way to uh you know write the data down and there's like a proof scheme built in with a z and all sorts of fun stuff so that was the first session next session uh was a little more general because it was more again this like probably thorniest question of like how's the history actually you know provisioned how is it made available and uh there aren't any great answers we are hopeful the poll network could be helpful here um and yeah uh i gave like a sampling of possible answers this morning i don't know if we made any you know great progress on that front in terms of like new information but you know we will keep working on it and then we had the pearl network session and i think the takeaway from that was essentially that the network isn't really designed uh to serve this like archival use case but it could be great for like sort of point queries right if you need like the 10 millionth block portal could do that um yeah and then we just had like a recap session at the end of like a rollout plan basically we're going to reach out to various institutions um and actually build on more of the infrastructure and i think if uh yeah essentially want to prove out this thing working uh and then from there go to client teams and be like hey this is time we're ready to go and make it happen that was that cool and then over here we spent the day working on some uh consensus stuff does anybody want to give us a recap barnaby do you want to talk about the pbs session um i'd only do pbs i think but that was a very nice session we started discussing kind of the design space of the mechanism so as i explained this morning there's a lot of moving parts you have the proposals you have the builders you have your testers you need to find the best way to kind of coordinate everyone around the around this market one of the main constraints that we discuss is this idea of time buying that people usually have an incentive to do things late rather than soon because then they can accumulate more mev or more transactions in their block then we discuss the four choice to make pbs work we need a way to keep people accountable so for instance if they don't do their job we need a way to say i haven't seen their block on time and for the fork choice that works for this is called block slot but it does introduce latency constraints that could be solved with this backup scheme we also discussed how this meshes with current for choice constraints such as proposer boost then we discuss cr list which is a way to avoid censorship when you have a single builder on the on the market and later vitalik also commented that you don't have to commit to a hash of the execution block you could commit to just a bid amount and the index of the builder and that might give you a more flexible construction that's it for pbs next do we spend some time on the single slot finality requirements is does anybody want to get a recap on that i was there um we drove a vitalik as we had a discussion around the requirements not quite that uh did we went over and discussed it's not there don't look over there um discuss kind of the requirements that we want to see from uh any sort of like single slot finality or you know it's really any sort of um accountable safety accumulation on a per slot level um how the protocol might evolve into there what things that we from the current protocol that we really want to make sure we preserve and new things that we want to get there we ended up kind of like throwing out all the all the fun stuff like you know make it zk friendly whatever that means in that context um and i think we're like a bit more on the same page i think that uh one problem we've had in just working on proof of stake consensus and ethereum in general is like we have all these kind of like abstract nice things to have um that are all in our heads but actually getting them down in kind of a systematic way on paper is hard so that was good and then that transitioned into the stanford group who joined us here and has been doing a lot of work on ethereum proof of stake consensus and things showed us a model that they've been working on which might give some of the properties that we're looking for here which you know uses some sort of black box bft consensus and then some sort of uh oracle about how many people are online i'm sorry i'm gonna butcher this uh to to dynamically adjust uh the finality threshold uh knowing that there are trade-offs when you do so um very interesting stuff uh we're excited to continue to collaborate on that i then was not in the next session uh if anybody wants to talk about uh fork choice stuff i text you from the other room though it's all solved it's no problem i had a bit of uh the unfortunate job to basically tell about the latest fork choice related issues that we've we've uh come across and also talk about some of the mitigations um so basically yeah there's this thing called ex-anteriorx where yeah you release rather than doing a reorg where you see a block and you reorg it out the idea is basically you by like strategically timing your messages you get to re-org out future blogs and the way we're mitigating it is basically giving the proposal some boost um that basically allows um yeah i mean i don't want to go into the specifics of of the attack now but basically talked about a bunch of problems ex-anterior balancing basically this idea of splitting committees into different views and this proposal boost which is uh implemented and live on on some of the clients already is basically um giving the proposer some power to kind of sway um like make everyone converge on on one chain um and then we yeah we kind of concluded that we need to tune this boost parameter because there are there are some kind of side effects to this boosting because the boost can also be abused by an adversary and then we talked about some kind of like more forward-looking um fork choice changes which we refer to as view proposal view merge it's this idea of rather than giving the proposal actual fork choice weight and like kind of philosophically kind of defeating the purpose of the democratizing um the power to a committee of thousands of validators we only give the proposal kind of a way of adding information and by adding this information kind of syncing everyone up specifics doesn't don't make sense to to recap here but yeah basically a bunch of problems and hopefully a bunch of solutions right so peter killed stateless that's it no so we started with some explanation with uh about vocal trees how stuff works uh we had a couple of discussions how to interact with stateless clients uh jolt was like we had a conversation with joel about uh including the proof in the transaction we decided against that so um yeah anything else from that uh yeah we asghar was also questioning some aspects we like the complexities we decided uh yeah yeah we were looking for why we were doing something basically and it's basically a performance issue and then there was andrew are you here because there was the the stateless database sorry vertical database okay so um andrew was explaining how aragon do their database scheme and how it would evolve so we we discussed how we could implement things and there's a couple questions to to be answered some follow-ups and then there was the [Music] what we did we did that was not the sink yes there was the sink so the question uh yeah can we do a vertical uh stateless sync i think it's clear we nee we don't we we can do the snapsync i mean we use the snapsynth that was the decision and then there's the transition that was the biggest discussion um so we identified some some issues uh overlay tree definitely doesn't work and we identified a new a new solution that we need to look into so basically with uh someone does the conversion or multiple people like we we stop the state like we freeze the state at some point uh and we log every difference uh between that state and the current state and uh people will voluntarily convert um this to to a vertical tree and then that that vertical tree gets a sync and then all the logs all the differences get applied until you you reach a vertical tree uh this is the current model we want to work on and uh there's some investigations to be done um do you guys want to add something people we're in uh in the session no you should see the faces i'm getting yeah so i think that was it thanks cool there was some people working on testing and shadow forking any any takeaways from there yeah so uh we did the shadow this morning girly shadow fork number four it went great uh there were some issues uh with the notes running out of uh running out of memory uh some visual notes also left the network after the transition and yeah but it looked pretty good then we did a session on merge testing tools where we discussed all the tools that the execution layer has all the tools that the consensus layer clients have to to to do like investigation of issues on on the respective chains chains and we discussed uh some of the tools that we would like to have that we want to want to build some of the documentation that we want to write for the uh for the other clients on or the other teams to to be able to debug issues and also to write down um things that other people could help us with so if if we if for example guest finds a bug or stumbles upon something with a with a client combination what data do we do we have to uh like collect for nimbus or lighthouse to to investigate this these issues um so that session was pretty productive and then we did a session on merge testing where we discussed some of the strategies that we currently use uh fuzzing these these shadow forks [Music] static test cases and stuff like this um and also the things that we that we want to use want to use want to do and yeah and then we had i hope there's no no cameras running we had a session on uh win merge and uh damn yeah so uh yeah we we we we had a we had a session on on when merge and and timelines [Music] [Laughter] the the merge is coming and we'll keep talking about it a bunch this week um cool yeah cool uh great thank you i had a lot of fun the past couple days uh i really appreciate it i texted if you're in that telegram group we do have some like hack space available throughout the week for this group to continue to collaborate to work on testing the merge or really kind of just have a space you can go and be in i think there'll be generally coffee and snacks available it's it's a few different locations depending on the day so just look at that text that's in there um we are having a party at six in one hour in this building right here named the atom building a apostrophe d a m uh in the loft space it's upstairs um should be there's lots of food lots of beverage uh so i don't think you need to grab dinner before um and that's all i have tim okay thank you this is awesome really really appreciate it [Applause] oh and huge huge shout out to the volunteers huge shout out to a lot of digital company huge shout out to the people working making sure we had food and everything it was this was awesome it was awesome we've been in some like janky situations before and this was not one of them round of applause for danny and tim for making this happen [Applause] [Music]