Daily Recap, Layer 1 R&D - Day 1

[Music] all right so talking to the microphone so if i come here so thank god it's just that this great explanation of the theoretical part about tank sharding then comes the more like implementation focused parts where all these samples do require lots and lots of network communication and so our goal here is to try around two problems we have what do we want to optimize for bandwidth actually think of another one bandwidth we have latency and we have altruism this is a problem widespread in the network layer where lots of things in network layer are not really attributable on chain we do want people to serve and participate as a honest actor so the way we currently approach this is with peer scoring and peer scoring only really works with like frequent communication and smaller meshes whereas sampling is this thing that distributes randomly across the whole network so it's difficult to put a score on a pair that you don't talk to up with afterwards and so there are two design directions so far where we could either try and implement this sampling thing on top of le p2p which is a tcp based solution so we have persistent connections like a set amount of pairs or we have disk v5 which is our current discovery protocol which is built on top of udp which is communicating infrequently with many more pairs so in this way it's more similar to sampling at the same time it's a dht it's very different than gossip sub and so it may have latency problems and then when we think of an attackability right so in peer-to-peer networking in general you can try and fake an identity or try and like have multiple identities as a single pair sybil attacks so we want to try and avoid this from harming the distribution of samples we don't want anyone to spam the network with simple identities to then basically have a they want say about what's being served what's not being served and worse to deterministically selectively hand out samples to those that request it because that might prevent people from sampling correctly so one attribute here where sampling is supposed to be random it's supposed to be something that the pair that is trying to verify for themselves if this sufficient amount of data is available they pick the samples themselves it's not selected by the protocol if it is globally selected we don't have it's not sufficient to replicate it end times so everyone will be just doing the same thing it will be very predictable for an attacker to try and influence so they also kind of want to preserve is this ability of nodes on the network to decide for themselves which samples to request and as you may have guessed this is a huge like problem in networking because it means that you have to traverse the network find parents that are able to serve you those random samples if you think about the p2p design with tcp connections then we have more persistent connections more persistent pairs so we either like drop more responsibility responsibility on those pairs to sort a few more of the samples or we have to think about rotation about taking a peer connection for maintaining it for a while but then shifting to other parents to be able to get fresh data different random data to do something correctly so the first gossip sub based design gossip sub is the protocol that pushes messages truly p2p it was like that where to try and rotate through subscriptions between many different pairs obviously this has limitations um because rotation rotating subscriptions is still slow still requires you to create new connections to find pairs and so instead i'm i think i've favor less persistent connections there are arguments on both sides here on the on the gossip sub the how many how many points do we have that we like per block in this construction doncard how many samples per block which is 250 yeah so okay one more point if you try and push this sample model into topics then you get lots and lots of different topics if you want to properly request or distribute data um right so we got many tiny hard to find subnets and so even though we use a like a solution that's maybe more stable in other situations it might not be as stable for this problem um then we have the alternative that we are looking into right now where say you do something on a udp-based network and say you try and combine it with the discovery protocol to find parents quickly within certain regions then you do have this ability to find samples and not have this bottleneck with connections or with many different topics and you with udp you don't have to need to have this persistent connection it if you overlay it on disk v5 at some point you essentially need to have one handshake to understand each other but then after that once you know the pair you can use that session to send one request message get one request response message back and that's of the communication um however as we said this q5 has its own problems it's more vulnerable to sybil attacks and we kind of want to avoid sampling from getting simple attacks and yes and another thing somewhere that i think there's probably like very much of a hybrid that we're going to be exploring but in terms of sending out full rows and columns uh such that validators and others that want large amounts of the data are listening that's actually a much more obvious thing to be sending uh probably in in gossip but again probably some sort of spectrum design right so you could think of rows and columns similar to shards of nuts in the previous designs where you take batches of these samples or like basically what would be a shard block but now in this more global version of data sharding you can take a column or you can take a row and you could assign it to a topic and there wouldn't be like this crazy amount of topics necessary but instead you only divide it by as many rows or as many columns you have um and the messages will be larger here simple is very very small it could fit in a single network package easily it's like on the order of 500 bytes whereas like this fill column or fill row is more comparable to a full shard blob okay and then we need to talk about altruism so just like serving blobs or serving beacon blocks samples are also this type of message that peers need to serve on the network for others to be able to verify the the validity of the chain and what i'm saying here with validity it means that peers need to verify data is available right somebody needs to serve this data the nice thing about the builder proposal separation is that we're separating the entity that is creating the data from the entity that's collecting the fee that is mining the data and so we could put the responsibility for availability with the builder the fee can be paid in advance it can be paid in like unconditionally as long as the transaction is mined for the transaction block the fee is paid availability depends on the builder putting in the effort to publish the data and so if everyone acts honestly is running the sampling attesting and adjusting fork choice based on sampling we can make sure that we force the builder to see the network and to publish the data or otherwise they wouldn't be paying a fee right they they they will be losing money here with the like sync cost essentially of well paying for the data transaction but not getting the data confirmed so it's a highly incentivized action because of the way the fee market the fee model works is that ultimately you know the the risk and the cost to disseminate that data ultimately can be priced in the in the free market exactly so we have good incentives for the data to be seated to be published but we don't have yet is that after publishing it to the network to retain it and to serve these many this like this larger amount of sample recast we don't like to direct all the simple requests to this one builder endpoint but rather like distribute the work and then once you're distributing you hit altruism problems so think about sampling we have like 75 samples to request per node basic math says that it also means that you'd have 75 samples to serve as a node if every everything is distributed equally but to distribute everything you'll need to distribute that initial published data from the builder to off the network and builder is not going to connect and reach out to every single node so you need some altruism here although maybe not crazy altruism to take the data from the initial publishing two words of the network and then serve it to those that are also sampling the worry here is that if federators are lazy and not participating in this sampling network but as a server that it will be very difficult to request these samples in the first place because not everybody can contact or should contact the one builder that has the incentive to publish in general to do so right so maybe one more thing to highlight of tank sharding and that availability sampling is not just a task of a validator to do something every node on the network can run the same network activity can do the same requests and so you don't have to take 32if to verify that your that the data is available somewhere on the network you can recast the mixture as a node without being stacked and this definitely creates asymmetry yes yes all right so we need more altruism on the serving side to serve those nodes that are requesting and not be and that are not stacked so deadline sir so i guess this is the problem with the networking but how do you know who has the data like is this something like ipfs or swarm that we have to build eventually so i don't want to be too opinionated during this talk i do like i do like one design more than the other so one solution is to try and overlay this type of sampling method on top of some type of dht something that's more structured to locate these samples you can traverse the dht by basically doing this logarithmic search to find nodes closer and closer to a certain identity and so you could if you are able to distribute samples towards a network that is free of symbols that doesn't have these fake identities then you can put them in a spot where they can easily easily be found the the definition of like honesty and with respect to the altruism can be the data that you have and are expected to serve is going to be related to your public identity such that i can make whether it's the dht or asking my local peers or any other sort of method it's like i can pre-operate know you're supposed to have this and then if you don't then i can consider you i can downscore you or consider you dishonest and maybe not go to you in the future alright i mean how can you i mean maybe the guy didn't get it for the first place from the proposal right the data that he's supposed to deliver to another um here right so it's very difficult to attribute a file to a node it's not serving a sample even if their identity is close to this identity of the sample you the node might not have found the sample uh or might not have gotten it from the builder in the first place i can still use it to like understand my peers and to prioritize or de-prioritize peers over time i think it's a bad thing to make a decision on a one-off uh but making decisions over time i think is probably reasonable right so as with a lot of this spare scoring over time it shoot efforts out if a player is consistently not serving your recasts then they are probably just lazy and you shouldn't be asking them for the consistently sample getting it from the proposal that's probably on them anyway right and i mean if they are not getting the sample from the proposer or from the builder here then it's also really just on the builder and then it's the correct behavior to say the data is not being available even if the builder is messing with a particular node like you probably still don't want to ask him because the builder's messing with them they're not useful to you they're malicious it's just they're not useful to you so stop asking so the consequence of data not being available is that some actor can confirm some weird commitments that maybe means other different data is available and nobody can reconstruct the layer 2 state because we don't have access to the data anymore but they can now claim whatever type of transition they might have wanted to introduce to the actor that doesn't produce the data not like the network consequence how do we enforce this so you mean the economic consequence to the builder here um like like in the case like the data's not available and i've asked a few like how do we like root right so short term it's relatively easy you say if you can't find the data if it's not available you fork away you say i will follow this other chain that does have all data available long term and data starts to disappear once being pruned by nodes then you start having a problem because you cannot divert anymore especially if you finalize you have a problem with data availability and i mean this is kind of an open problem at the same time you could try and force notes to like at least ensure data is being published that you at least follow a chain that at the time of publishing we are sure that honest nodes are able to get the data and if you have that type of guarantee then you can at least trust that there's some honest minority that will have the data and that should be able to recover the situation it all depends on the parameters and how how much time do you give honest nodes to retrieve this how many do you really need to to get all this data in the first place especially if you increase the data yeah if we in the current system if we somehow we're going to miss a beacon block if that would disappear i believe something like this happened to eos at one point then if one block of the chain disappears you'll not you're not able to re run the transition and so new players will have trouble onboarding on the network this is kind of you know you can also change the bounds of what the pdp is expected to serve and change the bounds of what is how people are expected to join the network and that's a conversation for tomorrow eip4444 it's pronounced erp for force it's written in the erp [Laughter] joking um all right so that's networking in a summary um i think we'll have like another like later session this week about discovery v5 this is the dht so if you're already motivated to work on dhts or in something here maybe join that section session reach out and i think we'll close it here [Applause] okay so the goal here is to go through the sessions whoever was the lead or ended up doing a lot of talking during that session is going to come up and they're going to say kind of what happened uh briefly really you know if there was progress made or particularly interesting next steps or maybe uh noting where further collaboration on this would happen uh that'd be really useful for the people that were not in the session to kind of get us all back on the same page um tim is here tim does that sound like a reasonable plan okay cool so we're gonna start with the uh the other the other room is iso and just kind of run through them so um does mario or kelvin want to tell us quick recap on the l2 evm usage session are either of you still here great hey there's my phone uh let's see uh kelvin says don't change the evm when you make an l2 because it causes problems uh there's a lot of talk about like um you know things that they want to do i mean this is often this was mostly in the optimism context but like we talked about wanting to reserve a section of opcodes for for non-use so that l2s can use them for things without fear of future edition of opcodes then suddenly making those mean something different in the evm um but but it all is is quite convoluted because then if say they use that reserved section to implement something that would we then do implement later then do they have two sections of opcodes that mean it a lot of it came down to in building l2s keeping things as close to how they work in l1 as possible saves a lot of headache and then we talked about a lot of things that were not to the evm in l2s thank you we're going to stay on the l2 track and then we'll jump into evm and then we'll go back and then we'll go into sharding so resource pricing storage execution l2 l1 anybody want to give us a recap on that great there's no solution okay tldr spoiler alert yeah no full solution yet but so basically um yeah recess pricing so i think the idea is that um with this 484 the eip we basically for the first time we have a new type of resource we want to price that is very meaningfully different from from from the other ones so basically just using the existing one-dimensional gas model really has quite severe door breaks so if you just i don't know give it a fix hundred thousand gas per block price or something so really want to move to like a multi-dimensional pricing model and um we look both at like just the specific context of the eip so just like a two-dimensional model but then also with the context of trying to to make it forward compatible with like a full multi-dimensional model and i think maybe just to tell the hours just that um they are i think fundamentally like this there's a simple simple solution that basically works for the two-dimensional case where basically you just have like a floating you basically you have to just choose whether you want to have like a floating gas consumption per blob or whether you just press it in etherically and have that floating so invo in both situations you basically just price it separately and um just try and make it as full competitor as possible sorry this probably wasn't all that helpful but actually what then and later on today uh it turned out we when we were talking with like some of the layer 2 teams it actually happens that the kind of layer 2 price um i don't want to kind of preemptively talk about this but but like basically that there's a lot of parallels between that problem and the uh layer two pricing problems and so that whatever the solution we end up uh choosing for the for the layer one for eight for four solution can probably just be more or less copy pasted to layer twos so there's a lot of synergy there so i don't know yeah sorry that was my best do you have anything to add cool killed two birds with stone stone there we talked about chard data and l2 pricing today um and how to upstream l2 evm contribution back into l1 who was on that session and wants to talk about it yeah if you think that it might be you it's you okay so we talked about a bunch of things in this session one of the sets of ideas was around how l2s could be a vehicle either for experimentation or with with l1 features that are under serious consideration or whether l2s could adopt new features earlier than l1 because l2s might be more agile there were a bunch of i think it was generally agreed that it was a good thing to have more coordination and consensus built around which were the features for which this could be done and to make sure that different l2s don't gratuitously do the same feature in different ways try to get that kind of coordination but we also talked about what are some of the limitations on the ability of l2s to early adopt or do experimental adoption of things and many of those had to do with essentially the risk that an l2 gets too far out in front either that tries something where there hasn't been enough security due diligence and something horrible goes wrong or else that l2s adopt something out in front of ethereum and then ethereum veers in the other direction and the l2 is left either maintaining something that is no longer supported that is never going to be adopted by ethereum or worse yet when ethereum does something that is actively inconsistent with the l2 so we talked about ways of coordinating one of the ideas that came out was the idea of having a sort of advanced experimental version of geth or something like that so that there was a set of experimental features which were coherently developed and that were designed for those who wanted to be early adopters say an l2 to be able to adopt things in ways that that were well supported and not gratuitously conflicting does anybody else who was there want to add okay great thank you okay let's do some of the uh evm stuff we have self-destruct removal and intro to eof um any recaps from today sorry okay so there were actually two sessions about uh eof so one was supposed to be about basics and was supposed to touch the self distract and second was about the new features that are coming later uh but they kind of merge into single one um it span one uh two hours of that [Music] so we started with some basics like how uf containers works and i try to collect information if there's something suspicious that can be spot uh in the audience um there's a recurring question if like how rigid it's supposed to be uh we put like quite a lot of constraints in the spec which some of them at least might seems confusing in the first so you can take a look there and see if you have comments about that then we move to explaining what kind of forward compatibility eof provides and how we can use that and there are two immediate actions we can take with that first of all we can uh we can deprecate existing instructions safely at the time we deploy the eof that comes to should we remove self-destruct entirely uh should we remove other instructions instructions like call code maybe gas instruction maybe pc instruction and we have some arguments uh depending on the instruction if that's a good idea or like maybe it's not so maybe there's some risk related to that and finally we we discussed uh how the jumps will evolve along with the eof so we plan to introduce static jumps and and later also functions and function calls that reside in the single eof container and that would be allowed to remove dynamic jumps so there's also like quite a lot of discussion about the details about this one and like how exactly to do that and can we move with all the features at once or like we should deploy in parts um i don't know i think all i remember if any other voices about that oh yeah yeah i wanted to say that okay and one more topic that was kind of interesting is like we didn't have fully specified that yet but that's that's something we really want to collect feedback about is um the the legacy code with exist with eof at least for longer time and if you can deploy the eof from legacy code using the create and also if you can deploy a legacy code from eof contracts currently that's possible but we found some compelling arguments that deploying like legacy code from uf is not a good idea and we try to include that in the spec okay thanks thank you great and ethereum accounts can the theorem count czar come up so the first thing that we talked about was should we just implement these account changes on l2 and it seems like this is something that all the sessions touched on one way or another it seems like the l2 session seemed to say l1 should implement things and the l1 stations say l2 should implement things it's a game of chicken and the rough take from like core devs in the room felt like there was very rough consensus that they would like to see some of these implementations on some sort of side chain or l2 network first that will give them a lot more confidence as it you know progresses as a standard rather than implementing something on mainnet that people don't want as much and so that was the takeaway from that we also asked why aren't smart contracts popular today and we came up with a list of some things and i'll just read that really quickly so security it adds new threat model to your account over just having an eoa it's expensive to deploy and there's overhead for interacting with it versus just using an eoa there's limited features in the existing smart contract wallet and there's poor standardization around smart smart contract wallace in general and we talked about maybe some solutions for the deployment issue it might be beneficial to have some opcode that says set the code hash of an account and that code hash could point to an already deployed contract reducing the cost of actually deploying new code um and then last we came up with some features for accounts for smart contract walls that we think are useful and some exist today and some don't exist as much and i'll read those really quickly so obviously recovery and transaction batching are really important and then counter factual deployment being able to say i want to deploy a contract on many different networks with the same address and set up some default configuration for that account without having to actually set it up on every network having modularity being able to like use new functionality for wallets without having to like manually upgrade your wallet spending limits transaction sponsoring alternative validity conditions not being sucked into only using these ecdsa signatures it would be good to have the ability to use quantum resistant cryptography at some point in the future and custom nonces and then we talked a little bit about um eoa migration as well and it didn't feel like there was strong feelings like either way so that's something that we'll still continue discussing and try to decide is something like eoa migration a useful thing to do in l1 or something that we should just let let it be how it is did anybody else from the session want to say something uh um i think you sort of said this but we talked about eoa format 1 letting us drop the gas opcode which drops the ability to do meta transactions which like strongly influences focusing on account abstraction which gives us [Music] you need the gasop code to do metering inside of the evm and so if we drop the gasop code it sort of gives us this strong incentive to like focus on account abstraction anyways it like gives us this little on-ramp towards like now we don't have this feature anymore you can only do it in legacy we should build it in eoa but anyways thank you that was not a part of that room sounds fun um great we're going to move on to all the stuff that happened in here uh let's get started with the 4844 open problems is anybody willing to do a recap on that i can probably do that um let's see so a lot of the problems that we focused on were around some of the potential attack vectors dos vectors which focus either on the bim pool which there are things to work through and think through there or just block larger block dissemination in general these are in the form of either computational resource attacks when you're sending transactions that aren't necessarily pre-validated because you have to verify some of these commitments and also bandwidth you're sending around much larger things than you are today so how can i abuse that uh there are obviously places to abuse um there's also don great what was the commit what was the the hint that you can [Music] uh it's add hard to verify a memphis transaction that costs like four to fifteen milliseconds uh yeah so the cost there is primarily just complexity and that being an additional thing that needs to be computed and carried around but um greatly changes the the computational attack ends up being much smaller than the the bandwidth so it kind of bounds the problem to dealing with uh some of the bandwidth problems there we also talked about generally just block dissemination as well and then resource pricing was the other half of that conversation which onscar did catch us up on were there other things that we talked about in the open problems we spent a lot of time talking about those attacks was there was anything else in that list at the beginning okay cool uh life cycle of a blob transaction i was not part of that session who wants to give us a recap of what happened over here great so with the layer two teams and layer on tops we went through the different ways a layer two could adopt blob transactions to build build the dr2 chain to basically go from initial layer to transaction to the output of the sequencer to a blob transaction to the memory pool and so forth through the whole system so it was really like a good way to start the day with as an introduction to the erp and i hope that from here like layer one devs better understand the data requirements for layer two and layer two devs better understand the complexities with later on and therefore there are more sessions about the erp so there was some overlap i hope the diagrams and the conversation was useful for sure so there are two more sessions focused on eip foreign first one session about the implementation the implementation really touched upon the data availability requirements the security and the propagation of this blob on our technical level throughout this whole system as well as the format of the data transaction and again because there are some different groups between the different sessions we did touch on the optimization and then later on in the next session about benchmarking and optimization we again covered that where we do want to add that extra data as duncan mentioned and i'm not sure if easier but more inputs from the secret roll-up teams how to optimize the blob verification which was great and then aside from the cryptographic optimizations we also need to make changes to the transaction pool to better attribute bad transactions to parents that serve them or really that announce the transactions regardless where you request the transaction from if you announce it in the first place it should not it should not be a bad transaction and so with this more like attributable transactions a better verification of transactions we and also we discussed some improvements in how to sync and disable these blobs then we all kind of like get closer to where we want to be with the erp to not be as afraid about the computational costs at the same time the bandwidth problems are still a little bit of an open problem and we're working on that thank you um kcg ceremony [Music] so yeah uh we talked over here about the kcg ceremony and if you don't know what that is um if you're familiar with zcash maybe you've heard of a trusted setup it's a similar idea it's actually the exact same thing but uh much much larger so one of the things that eip 4844 uh requires is a kcg commitment to be baked into ethereum the protocol and what we need to do in advance of that is a trusted setup where we have a ton of people uh generate some randomness it all gets bundled together and then we can use the output from that ceremony to um uh it lets these blob transactions actually come to life so we talked about what that would actually look like how it would be different from other trusted setups other ceremonies how we can improve on it and especially how given this is you know it's a uh it's a new thing that we're adding to the protocol how do we really build trust with the broader community uh so people in ethereum people who don't care about ethereum this should be really uh something that has a legitimacy so we want to make it a really large ceremony we talked about some methods to do that using po-ops different ways to represent their participation how we can transfer who's running the sequencer the coordinating server between different groups in the community a bunch of different ways i think those are those are the large large topics that we covered um ideally we'll have this in sometime this year but as always you know timelines are iffy in ethereum so you know hopefully this year uh definitely before shanghai if if that's when we're trying to get um eip 4844 in and um yeah so with next steps we will be uh we already have some benchmarks that have been taken place um we'll be designing the ui getting an audit of the work that's already been done uh starting to spin up multiple implementations so that people can contribute on their own in different ways as well as starting to design what the story is what the narrative is again trying to build the public the community trust in understanding and having this mutual understanding that the ceremony itself is legitimate you can trust the output or rather that you don't have to trust it at all because of the way it's been constructed and you can verify the transcript so um i think that summarizes everything uh yeah and we'll be moving forward over the next month getting audits on these different components and starting to build awareness about uh getting different pockets of the community involved in the actually running the sequencer as a possibility thank you uh the state of the crypto libraries with respect to bls and kzg what's the state oh i got i got a competition um yes we looked with two time horizons we've got uh four eight four four coming uh and then beyond that the kind of full bank sharding there are different requirements so 4844 um doesn't require much lift from where we are on the consensus side we have this bls 12381 library we're all using the blast library um it appears to be fit for purpose and so on so our recommendation would be that um somebody fund uh supranational who create the library to add the very small shims we need to expose the functionality to create kcg commitments and to verify openings um uh on that and then that's usable by the execution layer clients and also the consensus uh clients so that that's that was the easy bit uh there's a much bigger lift to doing full tank sharding so we've got things like kcg multi-proofs uh we've got polynomial all sorts of polynomial multiplication and uh um reed solomon encoding and all that kind of stuff so the question was where's where does the responsibility lie for building these components um i think our our one main conclusion is that it's not reasonable to expect every client implementation team to have applied cryptography expertise and so we need to find a way to somehow outsource this or provide the right help to client teams in order to be able to implement this stuff safely we didn't um come to any great conclusions on this but there's some good ideas floating around that's all i got mammy did you want to add george all right [Music]