All Core Devs - Consensus #12

Transcript

release in the generators repository. The test files will be generated and committed to the test repository which essentially means that if you just want to uh use the tests and run them, you can just clone the testing repository or use them as a whenever submodule or whatever you like and the test files only. If you want to write your own test generators and yeah make them a available to the other implementations as well, you um have to yeah open a pull request to the test generators um repository. If you write tests manually, you can also um still put them to the um ETH2.0 tests repository. So you don't have to go uh via the uh generators

repository if you don't need that. Um there's also a read me that describes the process but um yeah I think that's it and we've already started to migrate the existing um generators so the BLS and the um shuffling tests I think and also I added um simple SSD tests that you can try. Great. And the the shuffling tests are not reflecting the new shuffling.

Correct. There is um a PR from Paul uh from this morning. Oh great. Yeah, it was very easy to use. Sweet. And I had an issue that I posted a couple days ago about um I think the next next test that we'll add is these um fork choice tests. And it was a question regarding um whether we can specify these very abstractly um and I think very clearly uh by just specifying the block tree and kind of the the latest votes and specifying what the head should be. And the people that did take a look at it I think were generally positive about it rather than specifying

like the actual formal blocks and attestations and like getting more state specific. Um so if you haven't taken a look at that take a look at it. Uh we'll probably be rolling those out shortly. Um I think beyond that the next test would be the state tests. Um but we're still catching up to things in the in PIVM and then we'll do those tests. Okay. Any other questions, comments on testing before I move on? Great.

Okay, we have kind of a packed agenda, so we're going to run through client updates. Um, keep it relatively brief today. Just the high points. Okay. Uh, who wants to start? How about Lighthouse? Sure. Um, so we implemented Vitalics Optimize LMD ghost. Um, and Adrian did and he's starting to implement that proposed YAML test for fork choice testing to test it. Uh we got our BLS implementation to pass the test vectors.

We benched it. It's 5 milliseconds for BLS verification on an i7. Um created some test vectors. We're mostly up to date with the zero the version two spec. Um and we're going to make some more test vectors as we go. Um we're working with reviewers to get Rust gossip submerged where we experimented with alternate repo structures and decided that monor repo is the go for us. Uh and next steps are networking and syncing. Uh we're going to implement Prismatic's YAML chain test format and we're going to start working on C tree hashing from us.

Cool. How about Prismatic? Yeah, update from our side. Um so we were updating the core processing logic with the spec and we are fully aligned with the version 002. It's set for shuffling right now and most of the resource were spent with um validator runtime. So what we were able to accomplish is is an end toend workflow where we can deploy a deposit contract on gory test net and launch a beacon node to listen for deposit events and the and the and the transar event of that contract and then the beacon node

monitor till there's enough deposits on on the beacon node and then we can kick off on we can kick off the beacon chain. So we're aiming for eight validators, one shard, um a EPO length of eight and the target community size of one. So there's guarantee one validator per epoch and uh I just posted an issue to document the workflow. And then we're on top of that, we're also working on like a workflow UI for a demo purpose. Great. Thank you.

How about um Harmony? Uh working on the emulator. Uh we have a a main scenario now that uh works a bit uh it's a bit buggy. Main scenario I mean uh is uh it's it's include proposer um a tester if 1.0 no chain uh and state processing and block processing. So now working on doing some functional testing. Uh also need to add logs uh uh here and there and there in the components to see to get a feedback on

what is going on inside. And uh also need to to add config and command line interface. Uh so yeah don't want to make any prediction on on the time left to release but uh we put all our efforts to release it as as soon as possible. Hopefully next week maybe two weeks I don't know. So that's it. Great. Thank you very much. Um, how about chain safe?

Okay. Um, hopefully I don't sound like an idiot crazy this time. Uh, yeah, basically uh we've put a massive focus on like now that we're comfortable with the spec. So, we got testing our coverage is up pretty high on just like custom tests. I'm going to start looking at like integrating some of the other ones that people have been talking about. Um, and next week we should start actually wiring up everything. Um, and have sort of like some sort of like a like a mock simulation to a certain degree. Um, and then focusing on getting kind of the for contract stuff

going. Um, and we've been making some headway on the gossip side or uh on the lib P2P side. Uh Mike here has been doing a great job at uh getting the JavaScript implementation uh more up to spec. That's pretty much it from our end. Great. Thank you. How about um parody? Uh so so we are uh we are upgrading our our runtime uh into the current uh 0.2 version. Uh our last one was based on the the really old 2.1. So uh it's mostly a rewrite. Uh last time we did

this uh just by a one by one uh spec translation. But this time we decide not to do that. Uh instead we want to make things more modular and generic. So it's easier to test and also we can uh reuse the code in other situations. Uh so uh right now I finished the the most of the Casper FFG parts and most of the uh rewards and paneling parts and runoff uh and we are still working on uh the rest of the uh like upgrading the rest of the the spec. So uh that's for us. Great. Thank you for your um

comments and things you've been finding with respect to those uh the FFG and reward stuff. Um how about GU? We have GU today. Yeah please. So uh we had feedback and now you're muted. Okay. Uh yeah, because we're in the same room but multiple laptops. Anyh who, so uh from the guest team's perspective, not much. We kind of uh we had this marathon meeting sessions

a couple for the last three days. One of the focuses was mostly Ethereum 2.0 and how we're trying to approach the whole thing and maybe get a little bit up to speed. Um, technicality wise, I don't think we have anything meaningful to re to report. I think we mostly just want to create a a separate repo in which we can experiment with and maybe start hacking on something. So that's mostly it. uh some one thing that we can probably discuss a bit later is that uh at least my personal approach is that uh instead of just implementing the spec I'm also kind of trying to look at it in more critical way trying to break it or maybe challenge a few aspects and one of

them was the serialization format which I'm not fully aware I mean I'm not I don't have enough knowledge about it to understand what its exact design purpose is so I have a proposal that might be better might be worse But either way, I think um can probably discuss that a little bit later, but the reason I kind of brought it up is that I think if we we should either clarify the design document in the spec documentation exactly what were the design requirements and then maybe maybe we can change it or not. Anyway, so long story short, we're just starting to look into things and um let's see where it goes.

Great. We welcome breakage. Um, okay. How about and we we uh can talk about the serialization format later. I actually just noticed that I woke up and saw there was a bunch of dialogue around that. Um, okay, moving on. The how about Pegasus? Hi. Yeah. So, um we are in the middle of um updating to the version of the spec uh 0.1. So, we're pretty much done with state transition. Um we still have uh I don't know about 2/3 or half of block processing to do. Um we have a uh we completed this u I guess we're calling

it like a service adapter. basically allows us to um to deploy the beacon chain either either as like a monolithic executable or um broken into microservices. Basically, it just translates like um events from a event bus into gRPC calls um automatically. And we still have to integrate that though and and test it out. But that's sort of just like a fun side project for now. Um and um I believe what's next for us is um we have looming is is looking into the um oh the P2P implementation in Java um

that the web3j guys are working on and um starting to integrate that and also looking into integration tests and um kind of wiring those in. I think we've we've got SSC um tested and integrated into our library um so we can we can verify it and that's about it. Great. Thank you. Um we have a ton of teams still. Uh Nimbus, hi. So, uh we did a lot of work uh in the past two weeks. uh we meet and for

hacking in Braxel in Brussels uh from February 2 to February 8 and also presented um a talk at FOSDM on how to build a nefarium client and regarding the hacking we do with the wall team. Uh we fix we provided fixes to our simulation. So we have now a state and block processing with multiple validators just like in the fork choice. We identified the critical path to deliver a test net MVP in March. Uh I will put a link on what we have to do so that everyone can know uh what we are uh focusing on and uh like uh lighthouse we think that the monor repo is best uh so

we did some refactoring of uh all our libraries and otherwise we are also in sync with the latest spec we did some BLS uh uh speed improvement and uh regarding our or test net. Uh we choose uh to make some let's say sacrifices. Uh so first is uh Windows will be a secondary target uh while Linux and Mac will be a primary target uh because of issues with dependency management like Rox DB uh compiler uh issues like GCC clang uh that uh are uh a bit hard to

explain and automate if we want people to easily test uh our implementation and also uh still uh things in lip that are um missing on Windows. Uh the second sacrifice will be to freeze the specs uh that we are implementing to either 0.2 two or 0.3 so that we have uh the time to fix um our implementation with a stable spec because uh during our aathon in Brussels we had and we still have a lot of breakages when we were updating to 0.2. So uh a bit of overview of what we

are missing for test net. Um a state sync when a client is behind so that we can request uh missing either state or blocks uh to others. Uh a system for broadcasting at station and proposers. Uh we will be switching from RLP X uh which is a current um uh communication uh to lip P2P and implement uh uh well turn on fork choice and of course a lot of devops uh we will basically use uh AWS nodes to bootstrap uh everything.

Great. That sounds good. Um, and the intention on the releases is likely to do um continue to do a weekly release through February as we iron out some critical bugs um and to assess kind of at the end of February what we should maybe slowing that down so people can have more stable targets. Um okay, got a couple more. How about yeith? Yeah. So, um, we got BLS stuff working this week. There are still some minor issues which we're facing with like the Swift to C++ bridging head or C# bridging headers, but we're working on

that. Um, then the code has also been updated to the latest spec release. So we're on V2 and um next we're going to or yeah we're going to work on implementing more unit tests so we have most of the code covered and then make sure that we get a running simulator going. Cool. And hi EVM. Hello. Um hi. um we keep working on the syncing the current spec and also uh writing the local simulation without network layer. So it's a very simple um seration to uh simulate the a tester

what a tester would do and in the P2P side the Python demon li P2P binding module is ready uh by Kevin and we are integrating it with the trinity node and also researching uh uh keep keeping supporting the common modules uh like the deposit contract. So Nicholas, Denny and Nishant from Prismatic Labs, we have some updates on the validator regist um with the deposit contract current uh recently. You can check that on the

deposit contract repository now. And I don't believe the API changed, right? I think it was just some internal reworks. Yes. Yes. Just um optimization and uh for like to be more readable and thanks oh and thanks to VIP protein they support us very quickly. Yes. Yay. And I'd like to share a link here is the the checklist from the research team. So just what

uh our backlog in our mind. Yep. Uh share in the chat already. Thank you. Great. Thank you. Is that everyone? Um, deed, are you still working on a Dart client or have you been working mainly on kind of research and optimizations? Recently, I've stopped working on the Dart client mainly because just too inefficient uh language choice. I've continued to work on uh several other projects related to E2 all in Go.

uh like you probably know the LMD ghost simulation by now. I've written like five different ways of uh running LMD ghost uh with a little simulator to change parameters with latency and stuff like that. So it could help with like making your choice for your clients and how to implement your fork choice rule. And then I've started working just a few days ago on the shifting algorithm and uh found a little inconsistency between the set shifting and the uh individual index shifting but then documented it and this

something maybe that some clients may want to look at if they just copied original code and the issue. Um and then again, yeah, that's mostly it. And I'm considering uh contributing to the like the upcoming uh project from G. It's called Firefly now Peter. Uh yeah, but it's still like very early. Cool. Thank you. I appreciate the optimizations. And if you haven't if one of if you all haven't looked at them um they're definitely worthwhile taking a look at um for some inspiration on these algorithms. Um I guess a note on

algorithms in general uh I think this is noted maybe in the spec somewhere but these the all the these internal functions are for explaining the functionality not for dictating precisely how you must do things. we're not going to be running test vectors against, you know, get current epoch and things like that. Um, and so I know that at this point due to the spec changes, it was easier to follow things to the tea. Um, but as the spec is stabilizing more and more, um, please do break out of that like don't try like the it is not efficient path to follow everything uh written in the spec to the tea.

Um, okay. Uh, I believe that is all for the client updates. Thank you everyone. Um, I'm going to skip to number five, which is just a quick note on like clients. Uh, someone some team or two should probably uh drive the path forward on making a light client first. Um, specifically, I mean, for a number of reasons. light clients are very important to the healthy network. Uh but specifically the sooner that we get a viable light client to mainet um the sooner that we can um do some of the things that allow us to upgrade 10 uh specifically the

finality of the chain um on 10. Um and then beyond that maybe exposing a state route from 2 into 10 so that the data layer in phase one can be used um in can be pulled in uh via bringing witnesses um into one of contracts. So not something we need to discuss now, but if you are interested in uh paving that path forward on the light clients, um you can talk to me or people on the research team um on how we might do that.

Okay. Uh, Metallic you [Music] were document that I wrote a couple of months ago. Yeah, you were breaking up till just the end and I think you said you were going to link to the document that you wrote a wrote a couple months ago. No, I was I was wondering if I was wondering if you have the link otherwise I can look for it. Um, yeah, I'll drop it in the chat. um that you're talking about just the uh the issue in the spec repo, right? Right. Okay. Sharing that

now. Litecoin proposal. All right. Cool. Um, so again, if you're interested in driving that forward, uh, we're would definitely like to see one or two of the clients take it. Um, okay. Next up is Discovery V5 update and discussion. Uh, Felix, can you give us a rundown on what's going on in Discovery V5? Yeah, absolutely. Okay. So, it's been going um like not super much has happened, but we do actually have um so Frank has completed a a document that I think maybe many of you have already seen. Um is a Google document that is basically a preliminary specification

for the wire protocol for this. I started working on an implementation of it and um yeah here at the at the team meeting we've been discussing the way forward in general and how to yeah basically the the um yeah forgot what I wanted to say but basically um the our rough plan is to just basically make the priority to get it implemented at least in a at least in in a sort of prototype way and then also listen to all of your guys' feedback on the actual wire protocol.

What would you see are any major hurdles uh to moving this towards prototype and then into production? Um I'm not seeing any right now. Great. And is there any if um one or two of these teams wanted to get their hands dirty and maybe help out uh what would be the best way for them to do so? I mean so um one of the things you could definitely do is look into the ENR format. This is published on ethereum.org because it is kind of a core component. So it has a similar role to say SS for for the for the beaker chain in that it's a standalone format that you can implement and test

independently without having to talk to any other node or anything like that and you're definitely going to need it for so if anyone wants to implement that like I think they should just go ahead and do it I can link it in the chat. Yes please do. I think it's 778 right? Yeah something like that. So what would be the [Music] um yeah let me ask different way. So what is the um what's uh what's the current status so to say on the on on the research side of things I mean I know I haven't really participated in the in in the forums or anything so I don't really know what

kinds of ideas are floating around in terms of networking in general and everything. Is there anything major that has been discussed or anything um with respect to requirements or framework? The general path forward right now is to use the PTP. um yeah a subset of fltp and to integrate discovery v5 into it which Raul is here uh if we want to field any questions with how that might look. Um and then the the major requirements are that nodes can in a relatively short time uh

join a shard topic or subnet um and begin syncing. uh this is some you joining on the order of less than a minute and syncing uh some amount of the chain over the next five minutes or so and and you get an epic epoch look look ahead. Um beyond that at the beginning we expect to map multiple shards to one topic um to reduce the complexity um and to increase the stability of these topics and the amount of peers on each topic.

Um and then topics are used to broadcast attestations which are then aggregated and passed to like a main topic which is the beacon node. uh which all peers would primarily really be joined against that one. Um any other specific questions beyond that? No, I mean this is yeah most of the stuff was I mean this is I know I think pretty much the general knowledge I was just yeah want because I sorry I usually I don't have to participate in research. Yeah. Um and since we do have Raul here, uh Raul, do you see any particular hurdles in integrating

um discovery v5 or any external discovery protocol? Hey guys, so it's uh I've been I've been going through the discovery version 5 protocol this morning uh and particularly the document that puts together uh a lot of concepts regarding V4 and V5 and how one compares to another. I found that super super useful and definitely definitely recommend everybody reading it. Um I did find a lot of similarities between uh discovery 5 particularly the pro the the topics functionality and the the sh sort of like the sharding aspect of it and so on. um and the advertisement placing with a subsystem that we particularly

have been specifying and we already have an initial implementation of which we call brandu on our side. So I think there's a lot of opportunity here for synergy because there's a number of very exciting ideas and particularly you know it's Felix has been thinking a lot about uh some of the adversarial environments and how to scale um you know advertisements appropriately as the network grows and shrinks and so on. So I would definitely like to create a forum between you know the people in the lip B2B team that have been working or conceptualizing rendevous and Felix and whoever wants to get involved to see how we can how we can move forward. And definitely um the one thing about

discovery version five is the the first thing that comes to mind is as long as you encode um addresses as multi adders then if you want to so once you discover peers in a particular topic right that map to a shard and then you want to establish a gossip sub overlay uh and you want to subscribe to that to that particular topic on on gossip sub given that you've already found peers of that topic and you want to bind to it then by using if you advertise those peers addresses as multi adders then you should be able you the libby stack should be able to take over that multi addader and establish the mesh right for for and establish the connection and the and the stream to to start talking on top of that yeah that is that is basically the plan right so

the plan is to like so the way I see it is that with this whole discovery version 5 effort is basically um one way to find peers there there are certainly other ways to find peers but this is the one that we that we know about that you know that is we feel is like best suited because it is like it's like it is basically the I feel the most sort of like yeah it's yes definitely definitely yeah and then so the what I mean you you can store any kind of address so if you want to store multi address is fine and it's going to make it possible to you know then connect to these and start talking gossip up so there's basically I don't think there's any problem with integrating these two systems yeah

neither neither Neither do I. As long as so this would essentially be a protocol that you develop and then when you instantiate the lip node in whatever client it is, whatever language, you just mount this protocol onto the node and and that's it. And um and then gossip sub would be listening to discovery events from this protocol and would be establishing the mesh. So yeah. Yeah. Right. Okay. [Music] Um, great. Thank you. Are there any other any questions about 75 or the PTP integration as we're uh here talking about it? Yeah. Can you can you just

give me a little bit more information about something that you mentioned? you you were talking about um about basically combining um kind of gossip sub channels um or pub sub rooms um oh I was shards into one basically to right so I have some notes floating around on this and I maybe get them into the validator doc I think um that will probably define some n that is less than shard count uh at least pieces especially at the beginning of test nets um where shard number mod in is actually the topic that you use rather than just shard. Okay, good. So

it's not something Okay, gotcha. So so you have essentially a formula that that everyone can follow to figure that out. Yeah. Yeah. Yeah. And the like you know if we have four gossip channels at the beginning we expect a low validator count. So um having some subset of gossip channels uh might reduce the complexity as we're ironing out all these things. Um and they're because these uh these shard sub networks are very small they greatly increase the chance of like eclipse attacks. Um and so I think this is another effort to mitigate that by having more people uh gossiping per okay so it's going to be also a fun so this is going to be a dynamic

function of the number of validators so it it could be um I it right now I think it's something that we might just coordinate over time um but we could definitely consider it being dynamic I dynamic in the sense that as the network matures I think we might double over time. Um, but something that we can also consider to have uh in the protocol, but that that then at least requires your uh gossip sub networking implementation to have be more aware of the protocol that it's that's running on top of it. Yeah. So, I'm not immediately wanting to push in that direction, but it's it's it's an option. Gota. Thank

you. Cool. Anything else um on discovery before we move on? Okay, thanks everyone. Um I realized we skipped research updates. Um let's not go too deep today, but do people want to give a quick research update? I can stop.

Yeah, someone said what was the question? A research update, right? Uh so on my side, I've been uh doing the uh leg work to get phase the the phase one spec uh phase up to a point where there's something theoretically viable for phase one by the end of the month. And so far there we've um already already merged into dev I think the structure of the shard blocks and what gets committed to in the shard block routes where the first thing is basically the exact same thing as what we've been doing for almost a year and uh the commitments are somewhat more

complicated but it's basically putting a bunch of shard blocks into a Merkel a Merkel tree. The thing that's still sitting in a PR is basically everything that has to do with proofs of custody, but not including the proof of custody interactive game. So that basically includes things like the mechanism for how sub keys work, penalties for revealing them early, the rules for when you have to reveal the uh reveal sub keys that you use. um also challenging for data um penalizing revealing sub keys early and a bunch of things like that. So that's um kind of sitting there in a PR ready for review.

And then the thing that I haven't started writing up, but it's honestly not that not that complicated. I mainly wanted to just wait until everything before it solidifies is the actual kind of interactive proof of custody game itself. So this would be what happens if uh you some uh validator committed to some custody bit then some other validator computed the custody bit themselves saw that it doesn't match and basically wanted to start the interactive kind of quote true game in order to figure out who who's actually at fault.

But like in general, I don't really ex expect any kind of serious difficulties in that. Um it's kind of largely a spec writing exercise. possibly with one kind of exception. And the one exception is basically that and like theoretically this is totally not mandatory but like if we want to have phase one be fully you cut out.

Can you hear us? So fully multi-arty computer friendly in the same way that phase zero is then instead of your or hey you just muted you were coming back via but we can hear you now I think. Yeah know sorry signal's not good here but basically if if we wants to make it um MP multi-party compute friendly that we needs to replace exor with something more complicated but that's a kind of very discreet and separate component in the same way the shuffling algorithm was right it's pretty much changing one

operation within this algorithm no matter how complex that blackbox is yeah so What I'll probably do is I'll just uh like when I get to writing up the proof of custody game, write it as just using um the hash of the data leaf and your subt and then like this in the same way we eventually swapped in a different a different shuffling algorithm. We'll just swap in a different hash function which could be one some fancy like thing that you can MPC in five rounds because it mixes mixes different binary fields in weird ways. It could be elliptic or multiplication. There's still

possibilities to go through, right? And just to be clear, uh the idea of keeping these things multi-party computation friendly is so that uh staking pools have options that can be more decentralized. Cool. Um any other research updates before we move on? Uh yes. Uh okay, go ahead, Justin. Okay, I'll go ahead. So, um I guess I'm still very much committed to phase zero.

I amum, you know, there's still work to be done in terms of finding bugs and design issues. One of the things I've been looking at is serialization and tree hashing. So, you know, expect some changes in 0.3 because a bunch of bugs and design issues were found. Um, I guess I'm very pleased that that Peter and G are trying to to break the spec. And I would encourage all implementers to try and keep an eye uh for trying to break things because I still think there's a bunch of things that that could be broken.

[Music] Um, one uh cool thing to expect soon is a um unified signature handling mechanism. So, uh that will be a nice simplification and clean up. Um I think I made for that a couple of hours ago. So, if you'll read a book and see if it's similar or different what you had in mind. Yeah. Amazing. Yes. Um and and yeah, this signature handling stuff would potentially be part of the SS spec. Um so it could be used outside as a kind of a standard. Um talking about standards,

um I've been trying to standardize or find strategies to to to work with standardized um cryptographic primitives. So specifically BLS 12 381 um I uh contacted a bunch of blockchains and asked them what their plans were and the great majority of next generation blockchains are looking to use BLS aggregation in some way or another and the very good news is that um there seems to be consensus that BF BLS 12321 is the way forward and there's also appetite to standardize on on every single fine detail or at least as much

as possible um to make everyone's lives easier and to have more interoperability. The the the other cryptographic hash um primitive is is uh the hash function. So I guess the good news is that SHA 256 is an option on the table because we have an existing pre-ompile in in E1 and it looks like again the great majority of blockchains both the next generation ones but also the the current ones use SH 256. Um, so it's uh is at least to me is looking like a like a very good option to to replace Kak 56 K6 with SH

56. Uh one thing that we added uh recently is uh transfers um so that you can send BEF uh within the within the the beacon chain and I guess that was uh prompted by the the AMA where people had lots of questions around around that and another question I guess people had is around the fungibility of of BF and F and I guess we we've been thinking about that more seriously and and seeing what our options are there. Um, and I guess, uh, earlier this month we had VDF day, so I won't give the details because I'll probably write a post, but

we've basically made lots of progress. We have lots of new ideas and one of the good news is that the the RSA MPC um that is suggested by the Lihero team um does look viable and it's been reviewed by uh several MPC experts that were that were there and and they seem to agree that it is the idea makes sense and it can plausibly scale to lots of consequence. And I guess the good news here is that uh anyone who's using RSA accumulators uh will be able to benefit from that hopefully uh this year. And that's it for me.

Great. Thank you, Leo. Uh we're going to keep it brief today. We have still have a bunch on the agenda, but want to give an update. Yes. Um very quickly just uh an update from my side is that I uh integrated uh part of the Bitcoin chain on the simulator. Uh I did a couple of runs uh in order to uh thousands of nodes simulated and when I did did those simulations I started running some problems. uh at some point the communication uh you know the number of messages in the network just kind of exploded and analyzed a little bit and and I realized that it happened when uh when there are um ankle blocks on the beacon chain and I think this is because me um perhaps naively I I assume that

there could not be ankle blocks in the beacon chain as from the moment that every validator is assigned at a particular slot then I thought there is no chance to have become blocks but at Yeah, I realize that when there is some important latency issues between different nodes, it's actually possible that this could happen. And so, yeah, I'm working on that and I'm looking at the specs to see how this is actually solved in the spec. I I perhaps need more time to deep. Great. Thanks. Glad to hear the beacon chain stuff is getting integrated into the simulations. Um yes in times of latency there certainly can be um uncle blocks or orphaned uh blocks due to the

fork choice becoming destabilized. Um so that's definitely an expectation in certain environments although the attestation based fork choice should allow it to be rel relatively stable. Um okay great uh I can give a brief update on my side. Excellent. So handle uh got some slides so I can share that on the chat immediately and we need to continue the discussions on that. Uh we've been working as well more on the 1.x stuff on the P2P discovery. So I prefer it matches between uh the 2.0 and the 1.x

but we're implementing the simulator discovery as and is edged by the 1.x guys. So I'm going to put the link there as well if you have comments. Thanks be interesting in the future. And that's it for me. It was brief. Great. Thank you. And uh an update on that is this is the the slides are um handle their efficient aggregation network aggregation proposal um and research that's very interesting I and my personal on it is that we should get things get these nodes on a network and tests um but this is a interesting

viable path forward as we need to optimize um okay Great. Let's see. Next thing on the agenda, um I posted a minimal kind of phase zero wire API uh before we translate that into an actual wire protocol spec. Um some of the components are heavily drawn from the uh 1.0 wire protocol. Um mainly this is specifying uh the minimal messages uh blocks attestations exits uh that are passed around and the expected uh topics to be

passed around. Um, one of the more interesting things to discuss is the um, sync API or the sync protocol and how that's a little bit different in the context of uh, a proof ofstake network with a weak subjectivity. A weak subjectivity being the length of time from when you last synced that you can uh remain synced or the when you bring something to the protocol like a a recent finalized uh block how old that can be to safely sync. Um and so this complicates things in a certain sense that it requires um a slightly changed user experience

and that I have to have this extra protocol piece of information about a recent piece of information about the network but actually simplifies things another way. The weak subjectivity period um you know the expectation to serve um that's kind of like this natural cut off or that time sum multiple is a natural cutoff. uh for how long a node is really expected to serve past blocks. Um and so there's a really the the two if you don't have uh if you're syncing uh either the expectation is that you have the state associated with the uh weak subjectivity uh hash that you're bringing that you maybe got from a

snapshot or some previous sync and you've been offline or the expectation is I show up with this latest finalized uh epoch checkpoint um and it is within the week subjectivity safe safe weak subjectivity period and I uh from that point would perform something similar to a fast sync of the state um relative to 10. Um if you haven't taken a look at this document and you are uh know a lot about syncing 10, please do. Um I'd like obviously can field some comments now or take some comments on there. Uh once we kind of get a general thumbs up, we're going to

turn this into a more formal spec specifying the the bytes and actual messages and what they look like so that we can move forward with networking. Uh this is this and unified test vectors are really some of the the biggest blockers on kind of interoperability other than just ironing up spec. Um are there any comments on this currently? Okay, take a look at it please offline.

Um, another interesting thing that comes out of this conversation is the user experience around weak sub subjectivity. Um, and there's a lot of there's a lot of options there, but essentially if I I'll share blink. Sorry, Greg. There's the link. Um, so essentially we have to begin to think about what the viable user what what's the user experience around a user who has not synced or is reyncing after being offline for a long time around getting this piece of information uh from the network a recent finalized checkpoint.

Um, you know, there's many options. Uh, it's like get two of three from your favorite three block explorers. uh have an option where it's shipped it's baked into clients when they ship uh weekly. Um there's but anyway it's something that we should begin to discuss and maybe actually survey and discuss with uh real users of the network. Um because it's it's a slightly modified user experience in a proof ofstake network. It would be interesting if you know if there was you know there was no other option if if the client didn't have an automatic checkpoint or if the user didn't have a checkpoint to provide.

It'd be, you know, interesting if the client um, you know, could default um, you know, to looking up some kind of a um, I don't know, like a, you know, an IPFS um multi address, you know, that's been voted on like a known good checkpoint. Yeah, I I agree. There's a lot of interesting viable paths here and I wouldn't even say that every client has to do it the same way.

Um, but there's a kind of large design space there. You know, I might just I might just tweet it or put it on my key like sign it sign it with my keybase. Um, just to have a piece of data out there that people can use. Um, but again, that's not like the most sane or you shouldn't necessarily just trust me, but the Okay, so you're not going to require it to be um for So, basically, it's it's going to be up to each individual client um to provide a a sane user experience for um yeah, and we can come around some standards. Uh but this is not this is part of the protocol is I need to show up with some recent piece of information being some uh recent finalized checkpoint uh to sync the network. if I haven't synced the network

before. Um, and that really is not really like an integral like protocol definition of what how that should be. So I guess I think the user experience might be slightly varied or standardized depending on what we come up with. Uh, Zahiri you raised your hand. uh what we have recommended in the past is that the client ship with a set of known public keys uh hold by reputable parties such the ethereum foundation uh bunch of other client vendors institutions like blockchain x force and so on. So the clients just know these public keys and they obtain a snapshot from some known location could be IPFS

or something. Uh and the snapshot is signed with a bunch of these keys and that's how the client um trust the whole community basically not a particular vendor. Yeah. And that's a viable path, but we should also probably expose to the user some them being able to override that and provide their own piece of data. But requiring it to have like a fail safe is is probably in everyone's advantage, right? Just to um you know, if it if the checkpoint if it's a known good checkpoint, it's within the weak subjectivity period. Um, you know, that's essentially, you know, those

those validators can or sorry, the beacon chain can sync on that known, you know, on that known good checkpoint, then it essentially makes them a better validator sooner. Right. Right. And this isn't just validators. This is also or sorry, beacon chains. Yeah. Just users, nodes in general. Um, and yeah, the but the a known the implication of a known good checkpoint, it's like who who knows it, who said it. Um there's there's kind of the subjective uh trust issue there regardless of how you slice it. Um okay, cool. Let's move on. Just to add a tiny nitpick. Yes. Uh

yes, there is a certain trust issue with checkpoints, but essentially you're already trusting your client. So if you're trusting the developers of your client not to add anything malicious, then you might as well trust the check point hash or whatever that they provide. Yeah. And I think I generally agree with that shipping shipping in the client and maybe that being the default and allowing me to override via some. I think that's a probably pretty sane user experience, especially if there's a diversity of clients um in case someone starts shipping some weird stuff.

Um, okay. I lost my agenda. Okay, cool. Um, paths to test nets. Uh, Mara brought that up. Um, I've been kind of saying few things throughout this. uh being the path is there's maybe a three-fold path. One is uh continuing to iron out bugs and solidifying the phase zero spec uh which we have been doing and as Justin said, please read the spec with active eyes. Uh there are bugs still in there.

um uh Yasuk found or the Nimbus team found a off by one bug uh during certain attestation inclusions at at epoch boundaries that we need to put a fix in for but I imagine there's uh things in there. So that's uh that's one thing. Another thing is getting these um crossclient test vectors together. uh it does not make any sense for people to have interop like uh crossclient test nets or crossclient testing uh on the network level without these test vectors in place. Um and then the third thing really I think is the the networking specification stuff um being the uh this wire protocol and

discovery um on small test nets and small uh network tests um discovery maybe we don't need topic discovery and everything can operate on one channel that's definitely a viable option especially on low low number of validators um but still this wire protocol is a blocker so those are those are the three things that need to happen um and continue to happen uh so that's I've been focusing a lot on testing and focusing a lot on these uh on this wire protocol. And so if you don't have someone on your team taking a look at uh the networking stuff or the testing, you probably should. Um but ma, did you have

any other questions or comments on this? And I I noted Lighthouse uh wrote a really good article the other day uh setting expectations for what test nets are and the different kinds of test nets. Um so anyone wants to comment? Um do we have a particular deadline like a date set in mind? other than just like March. Um March in what sense? I I again like if we don't have uh if we don't have state tests I think that people any sort of test nets should probably not be crossclient. Um and so I the expectation I think is to see

people experimenting with single client test nets, shortlived single client test nets, maybe longer lived single client test nets and as these other pieces come together um experimenting with um you know one or two clients uh doing some isolated experiments with each other. Um, in terms of some sort of like sanctioned larger scale long live test net, um, I'm not putting a date on that because we don't have the places the pieces in place to do that. Um, and would be a, uh, a distraction uh, in my opinion rather than uh, something that would help us out.

So, I mean, those those are kind of the thoughts. Again, I'm not I'm not putting any sort of deadline on when we reach those milestones, but we're getting to the point over this month where people are going to be experimenting more with single client test nets. And as we get this the testing in place, people should experiment, you know, go to a client you're friendly with. Uh maybe you're targeting the same uh spec release and try to experiment with some interop stuff. So, so maybe it'd be fair to say that if in March if you manage to get a single client test net running then you are

kind of meeting expectations. Do you think that's fair? Yeah. Um and cool. Yeah. I I've said it once, I'll say it twice. If we do not have state tests targeting a particular release, you should not waste your time trying to have interop because if we're not all passing the same tests, you're going to be trying to you're going to be working through all those bugs that are certainly going to arise on a on a network test, which we don't want to do.

That'll be a lot of fingerpointing. Um I um I wanted to ask uh kind of related about who is going to be going um who who's targeting let me start again. I'm wondering for the for the March who's going to be on who's going to who's sorry let me start again in March who isn't going to be using the go Damon or go code for lib P2P I know um JavaScript at Lotusar are looking at um they're going to run their own. We're going to run our own hopefully. Just wondering who else is.

Uh I think for for us we will also not using the gold diamond because we have the the rest version of live P2P. So we probably will use that. We will use demon on the side. Yeah, likely on the PVM side the demon for now. Adrian's been the one who's been implementing it in Rust. Um, but it's my understanding that we can probably expect some um, compatibility issues between the two, like some kind of teething problems. Um, so I mean that's going to be something to consider. Uh, but I think getting through that is going to be good because we also don't

want to have the whole network, you know, relying on this one implementation of LI P2P. So it would be necessary pain, I think. Yeah. And if we can maybe have the we have those experiments before we're even testing the particulars of the protocol. It might be worthwhile um having one or two of these uh the P2Ps tested against each other. Yes, I would like to note that sorry, you go. Oh, I was going to note that um the lip team has started a um interoperability test repository. Um they'll be adding things for pub sub in there soon. I think there's a PR waiting.

Yeah. So I wanted to say on the one hand we do have interperability tests for IPFS itself and we are getting better at largecale interperability tests for libby. Um I am happy to support you in setting up some smoke tests for the protocols that you want to use um within within. So, so a smoke test basically in my head is getting together the minimal um a minimal chat application so to speak uh across a number of implementations that are already using gossip hub and uh the protocols that and the connected and the and the transports that you intend to use and so on. On the

other hand, I do want to point I I did want to ask Phoenix the implementation of discovery version five. I assume this is happening in Go, right? Yeah. So the in so the the implementation I'm working on is uh likely is going to be in Go. Um we have some of the um we have some implementations of some of the components in Python, but these are more used to generate test vectors and things like that. So these are the ones that I use to also verify the go code sometimes. So specifically we have a Python implementation of the of the ENR format and and things like that. And I'm looking to also uh create at least a

Python implementation of the of the wire protocol formats just so that there to see that there are no encoding issues and things like that. But I don't have an active interest in making a production ready Python implementation. Okay. Um there is um the general plan that I also outlined out outlined at Devcon is uh to provide a web assembly module for uh discovery version five. So this would be something that is likely going to happen more toward the end of this year where um and the goal of for this component would be that if you don't have much of an interest to

implement this stuff or you well you know it can it's it can be quite a lot of work to get this right and um and you know stay up to date when it comes to you know attacks being discovered and things like that. Um it might actually be really helpful if you can just sort of run uh this particular discovery in a sort of sandbox and not really care much about the details. So my plan for this, my rough plan for this is that this web assembly module would basically expect you to provide uh very basic functions like you know basically it would be up to you to open the UDP socket and provide a function for reading and and

and writing to it as a web assembly uh linkable module and then well it would take care of of everything else and it would likely call some call back as soon as a node is sound or something like that. Yeah. So the reason why I was asking uh was because I'm I'm assuming that the people who are running on native lily P2P implementations so Rust and Go and uh JS would probably invest in implementing uh discovery version 5 once Felix is you know mostly done with his sort of like reference implementation and go. Um and for the

rest if that reference implementation is built in go you can and I can help you with this. We can fork the demon repository and add support uh such that we introduce a number of control messages in the demon that are directly exposing discovery version 5. So that would be sort of like an interim solution so that everybody else that's not on uh these large implementations of lip still gets access to discovery version five without having to invest a lot. Yeah, I feel like the demon is another option. Although I still kind of like my general opinion is still that the demon is a sort of unnecessary complication that is more like a temporary fix until everyone gets their stuff together and you know is able to

link it directly into their sort of application. And I I feel like with with uh this kind of thing like you know providing a web assembly module you'll actually be able to sort of like link it without without like you know running into the cross language barrier so much. I mean the other thing we can do is we can also provide a sort of C library artifact if anyone's interested in that. So we can just we we can just create a yeah dynamically loadable C library or even a statically linkable C library that that implements this stuff is really up to up to what people want. So I just always felt that basically web assembly would be the best option because it's it gets this sort of

baseline security in that everything runs inside of a sandbox and any Yeah. Uh regarding uh the Nimbus team uh we would like uh either a C library or um I know that Rust can expose a C interface. So maybe if you can just put some extern uh C uh in the Rust library and expose um components, we will be able to use it. Yeah. So all of these things are all of these things are possible. So it the the the the artifact that we can provide on the software side is a C library static or dynamic or yeah like I said web assembly module or maybe like the demon but I I

feel like the demon is going to create a lot of complications down the line because you're going to have to ship the demon with your application and has to be running and everything like that. So it's kind of a Yeah, I mean it's nice for experimentation but if you want to ship an application then having to ship a demon is a bit yeah so let's uh let's talk about this in in detail uh offline Felix because I I I agree and we have discussed as well about web assembly forms of uh the B2B going forward. Uh and I think this this would be a good you know thing to explore together.

Um the thing about just making one single piece of the system web assembly is that I worry about interoperability because the P2P like at the end of the day you will want to connect with you know with the peers that you've discovered via version five you will want to connect to them via gossip sub and establish an overlay and you know maybe kick off other protocols and so on. So that's that's the thing that I'm not 100% sure how that integration could happen if only one element is isn't sort of like compiled down and served as web assembly. But yeah, let's let's take that offline and well I mean I can just quickly add to that. So for me it's like the whole like this like note discovery stuff is like in I mean in any sensible implementation what you would kind of do

is you would treat it as a blackbox anyway and just basically make it so that you can switch out discovery mechanisms if you wanted to. And I see this whole discovery version five effort as being like one possible way to do no discovery with certain properties. And uh it's really like a very very standalone type of thing where basically as long as you're able to give it a a socket to run on you can just well you can run it or not but if you're running it it will put out suggestions for nodes to connect to. But if you're using some other mechanism that's totally fine as well. You don't actually have to use this stuff. So that's that's that's basically how how I see it. It might not even be a good fit. Say I don't know

like on mobile phones where you know connecting mobile phones to a DHT has always been a bit of a problem. So yeah, definitely. So so yeah, solution. Yeah, I'm definitely interested in taking you up on the on the web assembly experiment. So yeah, let's let's continue talking about that the rest. Yeah, it it seems like just two things to say. one, it seems like with the um you know with the demon implementation, why couldn't it just be a flag, you know, to switch to Felix's, you know, V5 implementation? And then and then two, Felix also made the point about um you know, deploying the the lib P2P demon um is a little bit difficult, but you know, we have a you know, there is a branch of the lib P2P demon that deploys it as a

shared object. So that's actually not a problem. Just needs to be integrated into the master branch. Um, Ry, do you know the status on that? Yeah, I wanted to say that the demon, like Felix says, is not not a long-term solution for us. And what we're looking to when trying to implement on our own, a problem we're seeing is interoperability between the existing implementations where there is no real spec. So I believe that if anything would be useful at least for from from our point of view where where we want to create another implementation would be really a canonical uh source of truth to go back to to

validate what is what is the correct implementation of certain protocols. Yeah. So all native implementations could potentially have that problem. Right Jason? Yes. Right. And and and that brings us back to the wish list of a of a sort of a spec first approach where where the protocol is just a instead of referring to you know the goal implementation. Yeah, totally. And I I agree with that. We've been trying to make sort of like the shift towards a spec approach. Um as you know lib was actually factor out from from IPFS and so on. So it wasn't initially a spec to begin with. It was

actually an implementation and it grew out of that. Uh we are for the new modules that we're implementing. So you'll see this for example in brand. You'll see this in gossip hub and so on. We normally taking the practice of creating a spec along with a reference implementation. We're also going to be structuring and those go in either the spec goes in first like like it happened with Barndeoo and then the reference implementation is merged after the spec but never the other way around or they both go in together right so we are like there is a before and an after and now we are embarked on the effort of like re retroactively creating specs for all the stuff that hasn't been explicitly speced out or where the spec has fallen out of sync with reality uh and everybody is like once again I want to welcome

everybody to contribute and I spoke to Danny as well about this uh like this is really a joint effort u and I want like ideally the community you are part of the community as well you are the living community as well so we should like I know that from our side we want to steer this and we really in this but it's like difficult with day-to-day to actually find the right priorities and the right time uh so we would definitely appreciate your help here so when you detect stuff that needs to be specked out there are number in lib2p specs slashsp specs there are a number of pull requests that have been open for a while that uh we try to like one session we hammered out a number of specs together

but they're still there in the queue waiting to be reviewed if you want to you know have a say in those uh feel free please feel free to to join the conversation as well right so we are so to sum it up we are working on better specs but um like feel free to to join this effort and contrib contribute as well whenever you find something that's not well speced out or something that can be improved or something that is simply not speced out. Yeah, I want to second that. Um, be be actively engaged with the lip P2P stuff as much as you can and and get back to it. Um, my expectation is that the standardization on LIP P2P will pay dividends over time, but that there might be a little bit of extra leg work right now. Um but as you have time uh do

put in the leg work. Um okay. Anything else related to test nets networking interoperability all that fun stuff? Um just the the the point about the canonical implementation um can you know can you know if the the PI EVM team is kind of leading the charge and they're using the lib P2P demon um so can we expect to sort of look to that implementation to being the canonical

implementation well the underneath lib underneath the demon is go. Correct. Yeah. So, yes, Go, the Go implementation currently is the canonical implementation certainly. Okay. So, it seems like it'd be important to um kind of come to terms with the V5 stuff that Felix is working on in the how that fits in with the LIB P2P demon, right? Um yes, and I maybe a little bit discussed offline. I think that uh if it is not that much trouble doing some sort of integration there uh might be useful in the short term maybe not in the long term. Um but the

discovery v5 stuff really the where it sits in relation to the the lip implementation is not super relevant to the lip spec itself. as long as um the messages about discovered peers are being passed. Yeah. Okay. Yeah. It's a it's basically these these things are really not not not so related. So it's basically the the lip pcs are one thing and then you know this particular discovery mechanism is a different thing with its own spec and its own sort of it's it's bit of an external project. You can integrate it with the P2P if you want to. You can put

an interface on top in the software if you want to, but like realistically we're just going to yeah like we have this like spec first approach and we're definitely going to look towards finishing the spec very very soon like as soon as we can or I don't want to put a like date on it but it's definitely going to like we're we're really really working on the spec at the moment and um and then well how exactly the integration will work on the software side I think we can figure that out. Yeah. So Danny is there a way that we can create kind of like a smaller team of people who are interested or maybe representatives from each team that somewhat are you know the peer-to-peer people in in those team to actually

discuss you know how we going to move forward with this because like some some kind of fluid forum right like not a GitHub issue not a GitHub but something that's a bit more fluid because like we're not going to flesh it out in this particular call and I think it's better to um yeah let's start with maybe a um a chat on I hate Telegram, but we use it for everything. Uh let's get maybe somebody from every team in a Telegram. Um if that's reasonable. Felix, you unmuted. Sorry, I don't have Telegram. Uh could we use something public? Yeah.

Yeah. Yeah, that's much better. It can be G. Yeah, yeah, we can use Gar. We have a a Discord channel too for Go Ethereum that's fully public. we can create a channel there too. So I think both works just let's make something public and accessible for everyone. Cool. Um I I'm going to air on the side of getter even though the interface is terrible because everyone here uses it already. U one opposition though would be I mean G and I mean chat based systems are kind of nice for instant collaboration but if you want actually long-term collaboration from multiple people might not be the most perfect one. So for

example E research may be a bit better but yeah whatever. So whatever suits you just my two cents. Okay I'll think about it. I have some I have another offer. So, we do have a mailing list uh that only I am on. It's it's p2p ethereum.org. So, if anyone's in the mailing list, we could just take it there. Yeah. How do you get on that mailing list? Uh I can send you the sign up. Send me the Yeah, I'll uh I'll pick one place.

Maybe we can maybe do a waiting list or something because it's really more of a long-term kind of thing. So we we set that up a long time ago but never really used it. So it's like it's a Google group basically and you can use it through the web interface if you want. We can also make a forum about it. I don't really know like whoever is maybe forum would be I don't know you can think about this. Yeah, I'll think about it. I'll we will have some place to to meet very soon. All right. Great. Thank you. Um there's a lot of things to discuss there. Appreciate you helping on the call today.

Um okay, next up is something that has been very contentious in the uh getter chat recently. Genesis slot number and signed versus unsigned ends. Uh quick update, quick briefing on that is that there are some due to some subtractions very early in the spec uh in early epochs. If we start at slot zero, um then you get some negative numbers that pop up and you have to write in some conditional logic just for the first few epochs into the spec. Um, one, as some people might call it, hacky way to fix this is just to not start at

zero and to start it to the 19 or something slot or 2 to the 63, which was proposed, I think it's currently in the spec. Um, this brought up some issues. one, it's not necessarily elegant, and two, this 2 to the 63 thing actually uh has some like issues with overlapping with signed integers in certain uh languages and just kind of confusing everything there. Um some people are pushed back and say let's just have signed integers. Uh some people say we should have unsigned integers because these values should be ne negative. We should just specify the ranges that are expected and uh still start at zero and have some additional logic in there. Um I do want to point out that

[Music] uh just because we are exposing via these serialization formats um unsigned integers um the actual like what you're doing underneath the hood uh with respect to your integers. The spec doesn't really care. the protocol doesn't really care as long as you're coming up with the same state transitions and the same formats uh and the same serialized and uh hash formats. So, but that said, if we do start at zero, there is some stuff to work through there. Um I personally don't think allowing the negative numbers and just going to below zero is the elegant way to do it. Uh maybe it is, I don't know.

Anyway, it's kind of my opinion, my perspective, at least the background on this issue. Um, does anybody want to chime in? Um I think regardless of what we end up choosing uh what could really help a lot and uh give back um let's say power to implementers are um ranges like uh if we assume that it's alive for 200 years.

what are the ranges that we could expect from the numbers and then everyone is free to implement how it wants and from um uh if I had to uh vote for something I'm more for signed integers because um it avoids dealing with lots of nasty underflows uh stuff and uh yeah that's its So u a few days ago we already had this discussion in the gter and like the main thing we have to think about is that there's three classes of integers you're dealing with dealing with slot numbers you're dealing with validator indices

and we are dealing with balances and they may require different solutions. So I outlined like a list of like seven items or something like that with the different options could take genesis slot and integer size and sign inside. I think we should move it to an issue uh continue there. Yeah, if you want to open up an issue with the um the notes that you wrote, happy to take it there. Um Oh, Yasik said the

issues were recently closed. Um there's been a number of issues around underflow overflow things. Um there were two I think you guessed it that were closed recently. Um I think primarily because they've been dealt with with respect to just starting at slot 2 to 63. Um but there's definitely some push back on the implementation teams. I think it seems that the 2 to 63 is probably not the best path forward even if we're going to start not at the slot zero because of the um intersection with these signed integers and that just kind

of causing issues depending on language. Um, all right. I think we're not going to decide this today. Uh, but I'm happy to hear more input before we close it. I I would be interested, Danny, to know if there were anybody who were really set against um moving to uh signed integers um or if it's just because there's, you know, a lot of work to do on the spec to make it happen. Um the idea I moving to signed integers especially with respect to balances seems very wrong to me. Um like I said there's different classes with different

solutions. You should split it up. Um, even for balances, I mean, it's easier to catch with an asset if the balance goes uh negative than uh if you do um a minus and then it roll overs to uh billions of billions of ETH uh because you forgot to to check um uh that you don't have an an underflow, right? But when this you have to check either way and if your value ends up uh having a one in the in the most significant bit and you're transferring that out of what is

a signed environment in the beacon chain and into what it would be an unsigned environment in the uh the VM, you still have you essentially still have the overflow or the underflow. Uh yes. So like the sync syncing the VM with the beacon chain is also a consideration. Uh I think it restrict like the issues to um interfaces between VM and serialization which is easier to uh not forget about like I know that when I'm out of this domain I need to check what I'm putting uh in the container let's say. Yik says implementations can deal

with this as long as spec is unambiguous and explicit. Um I on that side I on the side of keeping the what is serialized unsigned and to make the spec hardened up a little bit so that people can do whatever they want under the hood. Um that said I don't know that's still that still leaves the question about the starting slot number and you know this thing is screaming at you that that um signed integers are the right uh the right way to go. Yeah I mean effectively you're just reimplementing signed integers by starting the slot number at a large positive number. So, um, yeah.

Yeah. I mean, what Okay, so there's a few things where we have a if we start at slot zero, then we have like a the negative epoch or negative um um I hear you. I hear you. Get at least consensus on how to proceed. Stay aware of consensus. They create an issue with the problem classes and the options known so far. And can we

continue the discussion there? Yes. And it seems like the general consensus on starting at some arbitrary slot in the future is not what people want to do doing. Is that correct? Is that incorrect? I agree. But I can't say uh so for others. Yeah, we can discuss it later in the issue. Okay. Um great. Deer, can you uh open that issue, please?

Yes, there's a self-interested comment. It' be good to get this resolved fairly swiftly uh in that you know I mean for many languages it doesn't make a big difference but for us uh poor penitated Java programmers this this is a huge uh difference to the way we implement stuff right and for the way that seems that the general consensus is to not start at some arbitrary slot in the future um for what you're doing underneath the hood right now uh you can say start at slot eight or not eight uh I don't know two two to the two to the fourth uh two to the 10th I don't know um to just get around that issue and use your signed

integers um in the spec and in your implementation and then resolve from there I think regardless that we're going to want to serialize to unsigned integers at least for these um balance values. It's my gut. Um but again, yeah, the temp fix is to not start at 2 to 63 and to start at the 10th. Um and to let's move quickly and maybe resolve this in by Thursday of next week. So that'll be by the release next Friday.

Great. Okay. Uh we're at an hour and a half. Um I'm going to say uh okay there's people there's a number of people that are at ETCC in Paris in early March. I will not be there. Um but I think any time to get people in the same room how even if it's informal um with respect to agenda there's probably a lot to chat about and lots to work through. Um, and maybe some interesting, you know, testing to be done.

Um, so if anybody wants to take the lead on getting people in the same room, by all means. Um, and then in April, it looks like there's a critical mass of people from different teams that are going to be in Sydney. Uh, and so I will be organizing something either right before or right after after Edcon. Um, I that's a while from now, so I don't know what the agenda is, but I'm sure there'll be plenty to do. We can organize something in Paris on Friday uh if there is enough people interested. Uh, so I don't know to get

this list of people. I don't know if prismatic for example will be in Paris. Uh so uh tell me maybe by commenting on the agenda if you if you're interested or not and if we have enough teams and enough people we can organize it uh in consensus offices in Paris. It's your call guys. Okay. Thank you. I appreciate you stepping up. So we can just uh thumbs up on your comment on the ETH call agenda.

Yes. Okay. And we are going to meet at Edcon. Is that is that true? I will be organizing an event um for the people at Edcon either right before right after. you you said it would be a little bit it's two months out so it' be a little bit before you have the agenda. Um but if we could if we could decide a little you know sooner if it's going to be before or after that' be helpful obviously. Yes. I'll try to um talk with people and figure out that very soon. I think that we have a uh we can use the Edcon venue I believe the day before. So I'm kind of airing on that. Uh but I

need to kind of see everyone's uh schedules before I do that. Um, okay. We have not talked about SOS verse SS. Um, I have something I have to do six minutes ago, but maybe let's just do a a quick a quick brief on that and then we'll take it offline. Yeah. So, I think this is getting way too long, so I don't want to hold up anybody. Uh if you guys can just send me a link the discussion forum where we can actually continue discussing then I have it I'm happy to take it offline just uh just as a really quick DLDDR thing. Um yesterday we were reading through the

the SSZ um specification and although it's I agree that it's really nice and simple one thing that kind of occurred to me is that uh for example if I want to access the nth item of a list or of a dynamic type then that one actually does require linear iteration over the data and this one is if we ever want for example to process these SSC packages uh via the EVM then this actually might be a a problem because it might become expensive prohibitively expensive and uh basically my solution I just try to figure out an alternative solution which uh which doesn't which basically changes

the encoding a tiny bit it uses offsets instead of lengths and this way it actually permits uh you to directly access any data in a dynamic list without having to iterate over the previous ones That said, uh so I think my uh my serialization format is kind of simpler a bit and um size-wise it's exactly the same size, but um I think one thing that I'm really really missing about the SSD spec is that uh it it doesn't really state what the design goals were. So I do have this alternative proposal but I have no idea whether it actually satisfies the the design decisions or requirements that

SSD set outs to to do. So maybe maybe as a starting point one really good solution but I would be happy for comments on the spec of course on my proposal but I think one of the most important things would be to actually have a small list of this of things that the the serialization format needs to support and what are the basic invariance that it needs to satisfy and uh well if we have that we should definitely add it to the SSD spec and then based on that we can either try to challenge it and make something better or we can acknowledge that it is the best that we can come up with. But either way, it would really help to know what the limitations of the of the design are, right? And I just shared um

in this rationale doc there are some uh design goals at the bottom and I I just shared that in the chat. Uh but we can why don't we put all of this in an issue and discuss offline because we're at an hour 40. Um thank you for digging in. Um, and we'll talk about it soon. Great. Cool. Thanks. Cool. Okay. Thank you everyone. I gotta run. Um, solid progress. Uh, stay in touch on getter the issues. I'm going to be cutting a release of the spec tomorrow.

Um, I need to get this critical bug that Nimbus found into it. Um, but great. Okay, cool. Talk soon. Thanks everyone. Thank you. Bye everyone. Bye-bye all. Have a nice day. Bye. Bye. Thank you. [Music] What's up?

[Music] [Music] Jesus. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] [Music]

[Music] [Music]

[Music] [Music] [Music] Heat. Heat.

[Music] What's up?

[Music] usual. Heat. Heat. [Music] Heat.

Heat. [Music] Heat. [Music] Heat. [Music] Heat. Heat. Heat.

[Music] [Music] [Music]

[Music] [Music] Heat. Heat.

[Music] [Music] What's up?

[Music] Please heat. [Music] Heat.

Heat. Heat. [Music] Heat. [Music] Heat.

[Music] Heat. Heat. Heat. [Music] [Music]

[Music] Heat. Heat. [Music] [Music]

[Music] [Music] [Music] What's up?

[Music] Heat.

Heat. [Music] Heat. [Music] Heat. [Music] Heat.

[Music] Heat. Heat. Heat. [Music] [Music]

[Music] [Music]

[Music] [Music] What's

[Music] up? Heat. Heat. [Music] Heat.

[Music] Heat. [Music] Heat. Heat. [Music] clearance.

[Music] [Music] [Music] [Music]

Heat. Heat. [Music] [Music] Heat. Heat.

[Music] [Music] [Music] Super key.

[Music] Heat. Heat. Heat. [Music] Heat.

[Music] Heat. [Music] Heat. Heat. Heat. [Music] [Music]

[Music] [Music]

[Music] [Music] [Music] What's

[Music] up? Jesus. [Music] Heat.

Heat. [Music] Heat. Heat. [Music] Everything.

[Music] [Music] Heat. Heat.

[Music] [Music] [Music]

[Music] [Music] What's

up? [Music] Jesus. Heat. Heat. [Music] Heat.

[Music] Heat. Heat. [Music] Heat. Heat. Heat.

[Music] [Music] [Music]

[Music] [Music] [Music] [Music]

[Music] What's up?

[Music] [Music] Jesus. [Music] Heat.

[Music] Heat. Heat. Heat. [Music] Heat.

[Music] Heat. Heat. Heat. [Music] [Music]

This [Music] is a Heat. Heat. [Music]

[Music] [Music] [Music]

[Music] See what

[Music] [Music] happens. Heat. [Music] Heat. Heat. Heat.

[Music] Heat. Heat.

[Music] [Music]

[Music] [Music]

[Music] Heat. [Music] Heat. Heat. Heat. [Music] What's up?

[Music] Jesus. [Music] Heat.

[Music] Heat. [Music] Heat. [Music] Heat.

[Music] Heat. Heat. [Music] [Music]

[Music] [Music] [Music]

[Music] What's up?

[Music] [Music] Okay. Heat. [Music] Heat. Heat.

[Music] Heat.

[Music] Heat. Heat. [Music] Heat. Slow down. [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] Heat. Heat.

[Music] Heat.

[Music] Heat. Heat. Heat. [Music] [Music]

[Music] [Music]

[Music] [Music] Jesus.

[Music] [Music] [Music] Thank [Music] you. Heat.

[Music] Heat. Heat. [Music] Heat.

[Music] Heat. Heat. [Music] Heat. Heat.

[Music] [Music] [Music] [Music]

Heat. Heat. [Music] [Music] [Music]

[Music] Jesus. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] [Music]

[Music] Heat. Heat. [Music] [Music]

[Music] [Music] [Music] Heat. Heat.

[Music] What's up?

[Music] [Music] Thank you. [Music] Heat. Heat.

[Music] Heat. Heat. [Music] Heat. Heat.

[Music] [Music]

[Music] [Music] Heat. Heat. [Music] [Music] What's up?

[Music] [Music] Heat. Heat.

[Music] Heat. Heat.

[Music] [Music]

[Music] [Music]

[Music] Heat. Heat. [Music] [Music] What's up?

[Music] [Music] Thank [Music] you. Heat. [Music] Heat.

[Music] Heat. [Music] Heat. [Music] Heat. Heat.

[Music] [Music]

[Music] [Music]

[Music] Heat. [Music] Heat. Heat. Heat.

[Music] What's up?

[Music] [Music] Please. [Music] Heat.

[Music] Heat. Heat. [Music] Heat. [Music] Heat. Heat.

[Music] Heat. Heat. [Music]

[Music] [Music]

[Music] Heat. Heat. [Music] [Music] What's up?

[Music] [Music] Jesus. [Music] Heat.

[Music] Heat. [Music] Heat. Heat. Heat. Heat.

[Music] [Music] [Music]

[Music] [Music] [Music]