Eth2.0 Implementers Call #20 [2019/6/27]
Devcon·Wed, Oct 9, 2019, 12:00 AM
The original livestream failed due to technical difficulties. This was recorded locally and uploaded later. Apologies for the local recording software not displaying the names and highlighting the speaker. Should be back to normal next week. Agenda: https://github.com/ethereum/eth2.0-pm/issues/51
Transcript
what's that okay sorry we are recording locally sorry to the Internet you will see this later if anybody watch these things who welcome I am pulling up the agenda you the agenda is in the chat so this is the last call before the fades zero spec freeze we are working hard on the last few PRS honking them stuff that we want to get them in general the intention here is to be feature complete to not be just meddling with things to make them cleaner we're trying to clean up everything before and to really get it in a stable place for implementers auditors from verification people buzzing etc to to dig in obviously three out of the four of those people the intention is to find issues so if we have issues if they're relatively minor bugs we're going to be releasing the minor releases we're also going to continue our testing efforts so we're going to be releasing you know B 0 8 0 T 1 T 2 if we're incrementing just on testing and not substantive things so that would just be increasing the test vectors feel if the increasing and test vectors found some minor bug we will fix the minor bug and release as a minor version 4 on the on the audit and form verification stuff there might be some structural things that come up there might be some deeper change where maybe some sort of additional abstraction it was warranted for X Y or Z we will deal with those on a case-by-case basis as they come up potentially releasing as any major versions if it's small isolated and worthwhile getting out or potentially piling on a few of these and maybe after a long run of feedback maybe on the more of the three four month time horizon we would do a semi major version bump but again I don't know what those are we because we haven't found them yet so we will address them as they come cool Secretary's happening thank you everyone I think the amount of people contributed to this is pretty awesome and unbelievable do you find issues keep contributing in 6 min upstream ok on to the first item of the agenda testing is davidic here you want to give it an update just a short 2/3 so there's this B are open but basically aims to completes the spectres coverage there's these two open issues remaining Munford how we formalized the finalization and how we deal lift missiles there's really just days of representing data and I hope to complete this release to edge cases are soon and all the other tests are complete so do we get much higher coverage of that suspect okay Thanks so there'll be a much more test vector coverage with the coming release I believe that there is fuzzing of the PI spec and the go spec still ongoing it's real ongoing we've been trying to improve how we move on from our initial set of states to like it more the first set of states the difficult thing is it's not like a virtual machine where there's many many difference in boot stance the input states are red like relatively sparse because there's all these invariants that have to be met by the state so what they do is we maybe creates input sets then first block changes and then when there's a felon posters we continue from there so we expand and expand the output States miss it the difficult thing here is to live in it in an intelligent way it not overflowed this pre state collection you want meaningful states are the first set of states not like small changes if you're interested in forcing please do join the like the tarragon chats or gator channel and we can talk more about the efforts okay thanks any other updates on Ted yep can you give a link to the today Ron chat maybe in the agenda you yeah we'll pop it in this chat you cool okay any other testing update no don't you great let's move on to client updates we will start with Trinity today hello so yes we just joined the yes hi some things are spectra Merce retreat and had a great week in popular to discuss and play around the new Python libraries we plan to migrate found I think I owe to trio which is another Python synchronised library and the reason most important progress is that Alex has a huge PR folder version zero point seven point one and also since the specs which is coming so we plan to a bump to version 0.8 or together yep I think that's all unless an Alex do you have anything to comment that's it thank cool thank you how about harmony we have updated our client to the latest spec zero point seven point one inclusion as a union we are placing all tests from github and our benchmarks showed no significant performance changes since zero six version of spec also we have read it really data RPC server part we will add client part Sunday in a fusion and we are working only P to be a minimal implementation we are fortunate to Java and we have finished second part and moving forward and next we are going to add persistence to our client and and that's all I think here thanks about lodestar yeah we've been building a few last kind of stubbed pieces of the client things like getting a valid each data eath one data for creating a new block getting our deposit processing actually working with the real Merkle tree and syncing getting a real sync between a network and a chain going and we're still in the process of moving to zero point seven point one the spec and we're also working on getting a benchmarking chassis setup yeah cool cool is there I think last time y'all were discussing experiment with some some typescript conversions is that on the horizon yeah so uh assembly spent yeah so worse so we have kind of a rough implementation of an LMP ghost its we haven't integrated it into the into the code yet it still as a PR and we are also thinking about doing SSD or rewriting SSD with assembly script I think the kind of the blocker there is a sha-2 implementation and so those are still works of progress I think I think they're gonna take a little bit of time but we're we're we're we're still working right that's still I guess a priority cool thank you how about a prismatic you guys yeah we're passing all the video points have to inspect tests except for one final one that we finished there go as a Z it's passing as well all sped tests and the next thing up is we're gonna be fixing up every part of a runtime so that it matches all the core changes and it sure that we cannot my benchmarking improve the clay ID itself we importantly spend a bunch of time working on transforming the yeah molds because they use hex trims to represent binary data instead of base64 so just a lot of hiccups basically on for based on based on that but things are good now aside from that we put together a central repo for etherium 2.0 API schemas we'll be sharing with that I'm gonna chat about this on this call so we don't want to take time away but out areas are recent they're really over the chat yeah maybe Preston can give a little bit of like a really brief explanation of this repo for everyone yeah so the goal here is we just want to give feedback and sort of collect together these API schemas so that people wanting to build on at the EM 2.0 have one place to go to this could be going into upstream and into the spec repo or live here we don't really have a preference now but we wanted to start getting feedback on this idea so like Errol said don't take too much tannins call goes down the agenda but let us know afterwards thanks cool thank you about Artemis um pass I'm just kidding um okay so on 5/8 quarter now due to my teammates beating me in the bed and upgrading from V 5.1 to b7 one of the spec so um I think that's 95 Dave yeah I think that's the first time we've actually been like up-to-date this back so you know interpret that how you will um but but they really did a good job so that was awesome we are also working on some stuff with deposits tweaking that whole process incorporating some feedback received from The Hobbit spec there's some good comments about you know like some cases it was there was it needed to be a little bit simpler like it for its purpose and um some more mods to match like other implementations so that it's less work to use it and then also matching you know the the actual real by our protocol and really a lot of credit goes to Dean and Rene actually for volunteering their time to like rewrite this back and it was it was a little bit spread out over some documents and and they they both kind of took all of the information incorporated it made it do much better version of it so that was so cool and I think that's pretty much it cool Congrats on taking giant ease how about parody so so last week we also updated to seven one test which we are really happy to see all the the backs of fakes and we are able to remove our work accounts so that's really great and for this week we are we did some fix for our Ivers in rocks TV so it's more stable now and we did a major overhaul for our panel remark Oh library which still hasn't been terminated but we had a library and the the Suffolk Networks stat is doing the works so that's for us oh yeah thanks for finding some of those book um lighthouse hi everyone West at the moment passing all the zero point six point three tests and we've decided not to keep up to date with the zero point seven point one and we're going to wait straight for the spec freeze and then jump straight to that one and since the spec freeze is happening we've also decided to start doing releases and so we're targeting a version zero point zero point one release of lighthouse next month which will of course still be just for developers and researchers so instead of doing although the spec updates 0.
7 we've been working on things like the reduced tree fork choice that was discussed I see three and we're seeing already some good speed improvements with that around you know sort of five times faster than our previous implementation without any significant overheads which is great but we haven't got any direct benchmarking to sort of show that yet but we should expect that expect that soon on the networking front we've been making some great progress with our leading implementation and especially disk discovery version five we're proud to say we have discovery version five running in lighthouse at the moment doing discovery although it's we'll just an initial implementation for our purposes it's not the full spec yet and also we've been having a chat to the Apache Milagro maintainer and we're gonna start be pushing pushing some fixes and some stuff up to them as well because that's our our core BLS library yeah and that's lay us great on the discovery v5 are you doing any of the advertisement and kind of topic discovery yet or just the base underneath that I'll let Adrian it's that one oh yeah just based ascott at the moment I haven't done the advertising stuff yet cool cool thanks how about Nimbus hi so regarding specs we have most of zero point seven point one implemented and we also updated or test shoot with the official test vectors for pls shuffling I wasn't the intent integer part of SSE regarding specs focus for the upcoming weeks will be on performance implementing SOS tile SSC to enable the rest of your official tests and we are currently we will start refactoring the state transition because with 0.7 now we have names for all the state transition function like process slot process blocks and things like this and with that we will also refactor the mocking part of the test suit like merging blocks on state now beyond Kos pecs we continue working on a stink library because we we fought NIM I think library and we add more and more function to support a peer-to-peer networking we also launched a lipid to pee demon based test net last week so now we have test net 0 based on our px and test net 1 based on the p2p we will do a blog posts probably not this week but a little maybe tweets from now to explain how to install everything we still are all running out some details we have a frame 1 deposit contract watch already we did encounter some issues with log filtering and some RPC methods that are not intuitive on a frame 1 and also over team at status now have a lot of interest on if I am to know that it's being stabilized and Jacques Wagner the main dev of Viper started to use name as it wasn't contracts generator so I'm posting them so Fred in in the chat so NIM might become like sure it wasn't we're official facilities and also we are starting to talk with embark team at status so that each team knows what are the challenges of developing dubs and of FIM to for the embark team and that's it for us okay thanks and last but not least ye you know so no real updates from us we kind of stopped working on it while the spec was still rolling I think we did some refactoring stuff since the last time I was here and then once this spec is frozen I'm gonna try catch to seven point whatever faster than Artemis did just to like get some clout there but yeah that's pretty much it challenge accepted y'all wanna make it Dean I'm a one-man show and I'm gonna beat you dude it's not hard to beat our team man stop bragging okay okay thank you welcome back cool did I miss anybody perfect well actually they June Park is here he is not working on a client but he has begun a formal verification effort in for analyzing the beacon chain and K soon do you want to give us just a little update on that um hi everyone I'm diggin yeah so we started this formal modeling of this : resist state function and a month ago and yeah so far we trying to understand the details and rationale underlying into the hood and then you know you are starting to actually modeling in keh keh framework and yeah that's what I have right now cool thank glad to have you I would love to have like maybe in a month or two 10 or 20 minute session about how easy did you find the Ephrem to spec and compared to maybe a frame 1 you yeah oh yeah I talking to me yeah yeah oh yeah sure sure of course because most of us have been working on that for a year now and it was hard at first I guess and now we are kind of insensitive to this is okay but I made a de jure and did you end up using that accompanying document I sent you was that help yeah yeah yeah yes I made an accompanying document explaining a lot of things and I'm want to refine it and figure out a good place for it to live because without it it's definitely confusing okay let's move on yeah sure so yeah so yeah you do that once you're at the point cuckoo great so let's move on we have I think a number of thousand people it's if research team research updates want to start so let's see on the phase one side I wrote up a small definitely incomplete checklist of things that we might want to consider changing or at least we'll have to decide what we'll have to decide on for phase one I think it's the most recent issue in the issues list at the moment so the big one the big ones there that I can think of so one of them is just a short blog time so is it going to be what the same as the beacon box I'm half a beacon what quarter of a beacon board something else the second is just size of a beacon vlog the third is exactly how the crosslink are data or you know one is how cross link data works I also wants to I consider removing the attestation list and basically only having one at the station object or at least pushing the data from the one at the station object top into the header and the reasoning basically being that I not really convinced that there's a particular need to in to have space for more than one attestation because the the the set of things that we're using these a char data stations for is much less than and the equivalent set for amecameca stations and there's a couple of other smaller ones so I guess if anyone wants to I take a look at that list then and none of its origins but once the 0 is frozen they do expect that we were that we'd wants there and have moved full steam ahead on getting the theist once back finalized so it's definitely good to start looking at so that's phase one on the fees to side the main thing is I've been talking to the Phase two research people people on an offense trying to figure out they basically helped me markets would work and some of the issues around batching transactions and this is more on three more in III search batching transactions how to make sure this scheme is censorship resistance and how to make sure we actually get the efficiency gains from batching and so forth the so I think what we're the kind of concrete possible changes to the basic execution environments or sorry the basic they face two specs that seem likely one of them is changing it so that you can have multiple beacon chain or multiple top-level transactions in one shared block one of them is allowing larger short execution environment states so instead of 32 bytes and you could still have 32 bytes but you could pay more and potentially go all the way up to something like 32 kilobytes so basically the upper limit being is it's something that still needs to be small enough to fit into a beacon block for a front for a fraud proof but otherwise it can be larger and it being larger has a lot of really nice benefits so like you can have some some level of proof matching happen between blocks you can have some level of batching happen even if there's or you can have multiple transactions I get what portal Bruce get created independently both getting I get included without either either of them breaking as well as some other things so that's nice by the way Karl or you won't be a forestry on the call well if not then Karl has been doing some wonderful thinking around teaching plasma like I and applying them to a nice - context or data just gets published on chain and it turns out that you can do that to do some really nice things like potentially do cross your transactions much more easily improve efficiency a lot theoretically you might you were in the normal case you might not even need to publish Marco proofs into the into the chain one of the really nice ones was that if you stick bigger sharp shard block times and add a protocol where validator is like pre declare when when they're going to make a shard block very soon then you can achieve and have extremely fast de-facto confirmation times for any application even if the shard in the individual shard block times are still longer like four seconds or or even eight or whenever so i'm that's and that's one III search that's something i'm also potentially really excited about because it lets us how create basically user experience equivalence to all these more centralized platforms without us actually being more centralized so yeah [Music] cool thank you italic Justin yeah so I only have just one one update basically I was at Deakin and avataric was at Deakin and there was this excitement for a new curve which was introduced with Zach C called the BLS 12 377 so it's kind of similar to BLS 12 381 it has the same embedding degree of 12 but it is slightly different bit size of 377 and the reason why this excitement is because you can do efficient it's not proofs about snarks so you have this this one level of recursion is not like a infinite recursion like at least one level and you can also do if fish and snot proofs about signatures so one of the things we were considering is whether or not we should move to this new curve which has this this interesting property I guess the the bad news is that BLS 12 377 is is a bit more than just changing parameters and and and constants so there is a little bit of work to to take the existing implementations and put them over the other downside is that there's a it has a cost in terms of hash to g2 so that becomes a bit more expensive so I think at this point in time pragmatically speaking we were looking to to stick with TLS 1281 you know which has more maturity more infrastructure more testing and by sticking with be as 1231 we also you know can can meet the DEF CON suggestion of launching the the deposit contract during a public ceremony so I guess it will be interesting to see how this how this space kind of evolves in the future I mean it's it's mind-boggling how much improvement we're seeing over time and I wouldn't be surprised if there's new suggestions that that come up you know this year and next year so maybe you know during phase one or phase two we could potentially evaluates a change to to a new curve but I'd say in the short term stick would be less 1281 so does that mean that because very strongly BLS standardization default but it means that the community might be fragmented between physician on the 381 and 377 right yeah so one of the you know the the things that needs to be done is kind of make sure understand a simulation effort that everyone is on the same page it seems that word of you know of the other blocking projects looking to launch with such a curve where the first one we want to deploy so there's about 10 maybe 10 different option projects and we're the first one he would deploy the deposit contract you know if it does have a little bit of weight in the space and momentum so it's possible you know that the mayor fact that we do go ahead would be a lesser austerity one might be enough of an incentive for others to come in one thing that was you know voice during the the standardization meetings is that other people also want you know no fragmentation and cohesiveness so we'll see what the next meeting come up comes comes up with which is a bit less than two weeks um but yeah for sure we don't want fragmentation although what that does sounds like is that there will be some level of fragmentation especially going off further into the future whether anyone wants it or not basically and because if he expects to keep on finding better and better curves that have more and more capabilities and so and you start with one that has one level of full recursion with pairings and you might find one that has two levels of recursion eventually someone might might find a cycle then someone might find a more efficient curve with a cycle so that's I guess a there's there's definitely a high probability that we should be preparing for an elliptic curve world that continues being a messy one for the next decade or pretty much all the way up until quantum computers nuke the whole space so one of the things we're trying to do with the standardization effort is to have the notion of a cipher suite so a little bit of metadata which specifies you know which curve you're using average hash function and so I guess this is maybe a good test of the robustness of the cipher suite you know can how well does it work with the existing curves that we know of the IETF Aston is a standardization effort is not just for the blockchain project so they will be interested in standardizing all the various meaningful options so I guess that's good news for us because it it means that we have some level of preparedness in this possible messy world of lots of different curves yep cool Thank You Justin Leo raises him audibly oh yes just a very quick notes so from beers from Barcelona I have been contact from the Stark we're a team and they showed some interest on working with with a simulator and the idea would be to study how various network parameters are affected by block size yeah this is in the context of the TDM improvement proposal 2028 so that I just wanted to share that thanks oh thank you let's do a us an update and then get a different quote Hey the the last month has been really busy probably many of you have seen that we released a tool called Scout which is a black box prototyping environment for for phase 2 execution it uses wasn't internally it was based on metallics phase 2 proposal - there is a research post explaining while introducing scape and giving some background just look for worst guy out on each research and the code itself can be found on he was less scared and notice black boxes most of the phase 0 and phase 1 stuff except what is required and basically it is a tool which operates on a yellow test file and it can execute execution environments using that mo test file and the chart blocks can be defined as well as there wasn't code for execution environment and the main goal with with this design is to be able to quickly prototype different features in execution environments and be able to benchmark those features now initially we have implemented a couple of different execution moments with different basic functionality so we do have a snipes verification which is integrated with chakra days we do have pls signature verification and some code for a token contracts and examples and all of these are really nice to prove that all these features can be implemented at compile it wasn't but actually right now we are focusing on the more important questions and there are basically two important questions is the speed of all this was encoded in the true put of what the exit environments have to do and basically the the key part execution amendments have to work on is they have to get a witness for a state and they have to verify that witness and then they need to apply the changes on it so our first goal right now is to prototype this witness verification so one one way to do that is using sse partials we haven't have that implemented yet but that is one of the next steps and the main outcome we hope to get out of this witness benchmarking is to prove that a stateless model is the right direction and then is the first thing we have to prove now since as I mentioned this black boxes pretty much everything from Phase II and Phase one because we don't need it for benchmarking but we do need to to have that at some way supported two to have a proper infrastructure to test execution environments so the the other goal outside of the the benchmarking we're doing is it would be nice to get this functionality implemented in a properly to client and and such a client would also need to implement a lot of the phase one spec as well as whatever is needed based on this phase two proposal the e boson team is working together with with the quilt team so I think we're gonna talk a bit more about this part but it would be nice to have a execution only test net at some point to be able to to have proper hands on experience with execution environments and that is that is my update hanguk someone from the quilt team yeah I'll go ahead cool cool so I guess number one I worked on a wiki this past week and so I'm actually posting it here in the chat so this covers a lot of the glossary terms a lot of the material a lot of the current conversations and basically consolidates all the info on so far on Phase two in one spot and so I'd like to get this on the etherium github wiki but I'm not sure the best place to put it up so maybe Danny if you have a suggestion there look at it we can throw it into either the new east wiki or on to it might get more eyes on it if we put it in the SEC repo but what's a big asterisk this is just like for research and implementation but I'll take a look at it and make it we can make a call after okay awesome yeah that works other things on our front a you know we've been collaborating with the awasum team on various things so one thing that we've been doing is trying to support scout and so we've we've been working on implementing assistive partials in rest and helping with that effort also we continue to dive into kind of the theory and some of the ideas behind the the relay market I think you know batalik talked about that and that's there's a discussion there are only three search so we're kind of thinking about that a little bit deeper and there's there's been good conversation there another another thing is what Alex just mentioned we are looking to help basically get a phase phase one a test net up that can support a certain number of shards that we can integrate Scout into and the basic execution the basic execution engine from that so we can start having playgrounds with execution environments that that can be a number of assumptions can be tested and benchmarked and explored also from our front we're in a kind of a transitionary phase so we will have more of an official road map here soon so i think i'm on the next call there will be some other things that we're looking at expanding on and diving into and contributing on so that's that's everything from close before great thank you super excited to see pretty much all three phases moving in parallel display cool cool let's see maybe the Pegasus research team then you have to be real oh yes so we had submitted the undulant paper to use linux and we got accepted to face to with some commands to take into a code so there will be a new version of the paper in produced without any change the as well result just something easier to wait I will Stan so that's paperwork and something that we're working on right now we're looking at how to use whole apps for interim to as a way to execute reductions on any shot from in developed so it's the beginning for us we're going to look at the simple case first which is transfer between Holland and we have one proposal yd and we're going to discuss that with Mary right at next week and to see how we can mount very faults and that's it great thank you guys any other research updates before we move on cool networking with a couple guys from protocol labs here today any updates from your end yeah hi it's pardon me if there's noise in the background I'm at a conference but yeah roll and I are here we so here's our update we basically we don't have any update on grants yet we're very close to making a couple grants some in conjunction with other funding sources some on our own so we'll probably have an announcement about that next week but all of them are aimed at building Lippe to be implementations in the languages that all of the client folks on this call need so they should be this should be encouraging announcements and I think though they'll bear fruit by September when we need them the second thing and then we can people can ask questions or whatever the word they want to go last time there was a question about TLS and I did I think I didn't answer the question well because I didn't fully understand it but I believe the question was sort of along the lines of what security is being provided by TLS and versus what does the application layer need to provide and so assuming that's a correct understanding of the question we talked about a little and I'm gonna let Raul answer it but we have an answer for that and if that's not the if that wasn't the question you were trying to ask then after this just just fire away with whatever whatever the real question was bro yeah well it's a concern was that was that a question like we want to differentiate we want to differentiate what why transport level encryption and authentication and security in general is necessary versus application level aquata I think there may be were some misunderstanding on the call but I I think everyone could would love just a quick on on that of course so transport level security is necessary to be able to first of all not be subjected to man in the middle attacks that could be a note that's being transmitted to be able to authenticate the pier that you that you that you are interfacing with if you for example have a key a public you for that pier then by authenticating them one initiate in the connection or handshaking your you're able to certify that you're really speaking to them of course for you know and all kinds of reasons to avoid observability and censorship and so on encourages necessary as well and the transport layer and of course is if the application itself needs to use for two primitives to for example sign specific pieces of data as my specific roles or nodes in the network validators and so on then you could imagine very easily imagine a message paste where you have a piece of data transaction instead of dog or a condition or whatever that is signed by validator and that message has gossip through the no way so as is being gossiped through the network Transport Security would be making message the actual transmission of that message secure between peers but those beers would need to verify that the origin of that initial message is actually the validator that they expect you to do to be so that would be an application of a signature for its own I mean these are there are both the one doesn't exclude the necessity of the other and the reason why we are there are two reasons why we want to adopt Els 1.3 or one of them is that is that it's a prerequisite for take that is super important or the other hand TLS adopting sianis 1.3 would help a lot as well it's censorship persistence if we you can very easily imagine a transport that is when HTTP 1.3 is our HTTP 3 is deployed in real life you could easily imagine transport that mimics HTTP 3 about using quake with TLS 1.
3 over port 443 for example so therefore you know would be very difficult for forest sensors to actually traffic unless you know at least to conduct any any kind of deep packet inspection of course they can always provide the adjustments so that's another reason why we want to agitate as 1.3 the Lippi to be stack is designed for bug ability had a security level at the secure channel level which means that another algorithm another another approach another secure channel that we looking into very serious ease is nice we have some experiments in this department there are teams that were actually probably going to be funding a team as well to implement some primitives that are lacking in a JavaScript environment to be able to conduct joist in a very in not use around essentially so that would be and like if you want me I can I can go down into like why we're interested in a noise and handshakes but basically we're probably looking at a system where we can conduct the i-x or the ID handshake a strong what is the noise provide some clear benefits over that guy oh yeah yeah it does so one of the tier benefits that I personally I'm very excited about is that it allows us to send push data on the first message as the handshake is being completed or it's going through the different steps it any push data or any accessory data that is conveyed in any of those hundred messages messages acquires different levels of security based on the state of that handshake so you can imagine on an IX hundred for example the first initiate a message to the pier yeah that accessory data would be or that push data would be plain text but then if the other pier wants to push back so if the respondent wants to like any data then on that second on the response because as already cryptic enough cryptographic material to secure that push data it would be it would be invited so it makes for a very elegant I like this TLS one country also provides this disability but for example and go it's not I I don't think a goal SDK is capable of sending zero round-trip data yet it should be on the roadmap but noise does already so and there is a variant of quick as well that you just noise for its handshakes is called again quick so I mean I do see some very interesting developments there and major adoption by projects that definitely have you know important vegetation so I'm pretty confident with us okay it's a relatively mature probably a little would you say it's more mature than a psycho and more widely enough yeah I would I would say psych Iowa so sorry in the early days of maybe two people we definitely want to move away from psych I owe that is just say cetera is pretty trivial to implement and for a best baseline interoperability across the b2b implementations you want to implement Sicario because this is what led to the implementation support and for example for the JDL implementations is exactly what we're doing not all programming languages support TLS 1.2 get so that is something against the state of TLS 1.3 at this point but that's practically a noise library for every language out there so it would it would make for a very good you know second baseline encryption mechanism I would just add one more thing Sekai Oh as of right now it has not enough been security audited that'll actually probably change by the end of a year but these other protocols like noise I believe has undergone it's like a formal verification and TLS 1.2 obviously it's an IETF standard so you know there is that to consider as well got it thanks people users will be able to choose which implementation they'd like great yeah correct so in parallel with all of this there is an ongoing the architecture of multi-screen - right now the selection of the encryption channel is being conducted in plain text which is not great but it does allow for that applicability so peers negotiate on what's on what secure channel they want to they want to adopt for that connection this will probably move to the multi adder as a component of the multi adder so you can imagine a multi adder like IP I before the the IP address / TCP / the port number / cycle or noise I cane or TLS 1.
3 so that would allow peers to directly initiate a secure channel without having to conduct any plaintext negotiation out of the open which makes the system prone to deep packet inspection and censorship by cos 1.3 is also vulnerable wonderful - like side channel leaks break the RSA exchange from the point of view of the p2p we would be basically implementing and adopting probably a stick a library in each language you probably want to do that like you want to adopt an SDK if you want to make sure that the language has a supports in such a point fourth 41.3 so yeah we are likely to be as a user of TLS one country is you know vulnerable to anything giannis wonderful itself is okay let's keep moving oh it's just any other questions for Braille or mic oh yeah have a quick question um so you I think Mike mentioned in the beginning that Yeller Yeller [Music] y'all are providing a lot of funding and support for new implementations which is badass because that obviously helps several of the teams I was curious about um about like testing what's the what's the status on on that what we need to do in order to ensure that um then you know lid p2p and the gossip protocol or production-ready I know like um y'all main like our time line for youth to might be slightly different than a lid p2p and so I'm curious what your thoughts are on that if they're just gonna be a grant or not yeah so we think of the testing and two different there's two aspects of it one is the interoperability testing between the different languages and that's an area where we are very interested in making a grant we we have a rudimentary system called IPTV which you think at Orchestra interoperability test but we need we would need some help I mean some somebody with some time to actually turn it into a proper Interop test suite which could also be used to validate that particularly looking at the implementation needs minimum minimum requirements necessarily called the fee fee whatever that means exactly um the the other side of testing is what I think you're getting at Johnnie like sort of production readiness testing basically integrate integration tests of the whole system to get data on performance and you know longevity tests leader running see if it falls over or not and for that we've built a system that we call test lab you can look at it it's a github / Lapita b-side test lab lav and basically what it is is it's a an Orchestrator built on top of nomad for those of you who are interested in container orchestrators and what it does is spin up large numbers of nodes so like a thousand nodes probably give it in the far where it could probably go beyond that and that that's our plan for testing you know real world like productions areas yeah we we would be open to a grant if someone wants to build out that test suite we do have an engineer that are allowed to work on that so there's a couple options there but we haven't made any decision yet [Music] okay so it sounds like you have this some so like a test suite to verify like interoperability between implementations like maybe that needs some some work on it but that's badass that'll be super helpful as far as like the performance testing so you all build something on top of Nomad so that you can let spin up a bunch of nodes in containers and then and then do some performance testing because we I think it'd be wise if we could you know what's performant for us may or may not be what's performant for y'all maybe y'all have higher requirements than we do but it would be it would be nice to be able to do you know to sweep some on things like you know message grates packet size and with limitations like how fast we need you know like actual gossip messages to propagate through the network just so that we're you know we're aware of where things break down because there's always there's always you know options you know if something needs to be tweaked you can fix it so I feel strongly at that like for eath to like we really really really should focus on that so is that something that y'all would have funds to to work on as well yeah I think we're open to funding something in that area I guess we've started out with sort of the idea that we need to support language implementers first and so for people fixing deficiencies in the existing languages so that's kind of why we're we what yeah I don't want you to see on the back burner but it was not the first LF also is interested in funding such work let and there's a couple of proposals under evaluation and trying to figure out the best way to move forward but let's maybe taking this offline I very much agree Johnny that we should be doing this as well okay dude I just wanted to say one just one last thing real quick like a phone makes sense that they want to do the interoperability kind of stuff first um but but we have this deadline of you know like of January 3rd you know maybe we could all find talk about um how everyone feels like like realistically like can we play out some different scenarios and see like with these tests with a long-running test that like how realistic is it really is January 3rd really good a very 3rd with a suggestion okay that obviously it's a nice target but it's not that's not a deadline and I want to tell the reporters that are listening to this that is not a deadline and that is something that is more in the hands of employers than it is even in the hands of the researchers so you know that that was purely a suggestion and something that is maybe feasible but not that there's a lot you know I expected the last miles to be long there's a lot of things a lot a little thing so I don't want to harp in on that January third date as a deadline that exists because there's a lot of things we're juggling right now and a lot of unknowns though it's just a I'm not one of those groups but like um you know obviously I'm a model of sensitivity here but like I would imagine that groups that get you know their funding from the EF they hear January 3rd and they're like okay we have to do everything possible you know not to do that and it's just you know I think that the focus should you know but he obviously had like a good push date but like no one should be like you should logically think about like what's realistic so that we can test everything and you know and do it quickly but maybe you're already thinking that I'm just saying it out loud so just definitely yeah we'd like to do it quickly but more importantly we'd like to do it right I mean the general Feraud suggestion was very tentative and I think it was mostly to try and avoid the December holiday so basically it would be we wouldn't launch before Dan referred John referred all the words could make sense what I have done is a survey some of the implementers to ask them if they think they will be production ready in 2019 for launch on January for it and two of the teams have responded positively with optimism that it is possible so at the end of the day we only need you know we need a minimum of two clients to be ready in there and we'll see how how the landscape evolves kind of organically but for sure I'm not expecting the majority of the clients to necessarily be ready on on in 2019 okay I would I don't I don't believe you reached out to us and I'm curious what the exactly what the what we're defining ready as like are we saying that there's going to be a three month long multi-client test net starting in September you know so that we can you know that we can kind of sort out any bugs that are found and if so like that means that that multi-client test net is gonna run flawlessly for three months and then we immediately get a lot of and I just seen it seems improbable so like um [Music] that's just my thinking I think all of us could push really hard and make January third but it's just it's dangerous in my opinion can i guy say something yep okay cool so we've been working with prism and a few different other teams Renee's been working on implementing hobbits we're planning on doing your kind of like an impromptu meeting in Toronto next week for anybody that's around I think it's gonna be Preston and Renee Dean Greg change safe guys I think Anton might be joining us so if anybody else is interested we're going to kind of start ironing out some of the networking stuff and trying to come up with somewhat of a loose specification for what that stack is gonna look like and next we're gonna try to move on to do some research in terms of like data sync like peer discovery etcetera so anyone wants to join us please please do it we'll be in Toronto next week well so we have a few like Johnny mentioned we have a few updates to the Hobbit spec that largely came out of the conversation with prismatic so I'm gonna post a link right now and any feedback is welcome you okay there's a couple of things on the agenda I want to get to before we get to the hour and a half mark and then we can come back to open discussion Greg from chain safe suggested that we have Brussels move to make communications to discord primarily we communicate in one get er there's a couple you know maybe two or three getters that we communicate in and then there's like tons of fragmented telegram communications and emails and things like that the proposal is to have a more unified place to talk one of the main downside that I've seen it just is a little bit more overhead to come in eavesdrop participate because you do have to create a username and login so it kind of I think the minimum hire for me is to bridge the current sharding getter to like the general room on this discord put otherwise it seems like people are generally very positive about this because anyone not I would like to speak up yeah I like bridges too I mean at a bridge to a telegram as well cool you have with a bridge it's a telegram people a sect does that does that exist bridging yeah and that would imply that a lot of us probably you don't have to download yet another messaging app just make a new messaging app the default bridges them all it's called much fix I'm jerking I don't have right I don't intend it download it I'm kind of I'm at the match anyway um I let's do it I think this is good I think it makes them I know proto that he would help us do that so uh protocol Jeff this calm cool and then proto has a proposal for standardizing I think rafidhi escapes and testing bro do you want to give it quick on that sure so the idea here is that you can use this one field that can contain any data in the clock body to use it for debugging during testing so you can put like this little meta information in it about who is like what kind of client is running or producing the block where's the client locate that's for how long is it running on these kinds of meta information metadata and then be able to easily debug like large amounts of blocks you and sounds great but we essentially need from others is to agree in the same format hello yeah okay so don't try to achieve is like collect suggestions from all the other clients on what data they can provide it will be what would be useful for interrupting and then standardize it are like so much standardize it it doesn't persist after the test nuts just for testing and maybe we should open an issue on the spec test repo and we can everyone can add the ideas because 32 bytes is it's large and small at the same time for example IP addresses you need 4 bytes at minimum and well we can run out easily yes let's say like client vendor a time stamp or maybe two types of time stamps some statistics and an IP address it would be like just a set of four bytes each it's all fit in 32 bytes generally I'd say that the client version is more important also the client thing else so maybe like you know the first four correct I just attached [Music] cool okay let's take this to issue yet so maybe like they lost a few you cut out a little bit last few bytes what so my internet is unstable can y'all hear me yes okay cool okay let's just take this to an issue thank you Berto okay before we have just open discussion just where did there any pressing questions about the specification things that have come up many issues you've run into okay great and now open special closing remark clearly there is a desire to [Music] figure out the minimum requirements to be production-ready some of this is a little fuzzy because there's a lot of unknown unknowns that we're going to run into in the next four five months but it's probably worth at least beginning to enumerate the the knowns there so why don't we take that to an issue in e to PM Rico and we'll just start the list and then we can from there engage in the conversation does that seem reasonable a list of unknown unknowns no like yeah yeah but like how long do we need a test net before we feel comfortable do we need to do some incentivize test nets before we're ready what sort of performance metrics and stress testing doing it's beyond the network layer things like that there are a bunch of things that maybe we can't quite a numerate day because we haven't hit them but we there are some things that we should we should get out and start just kind of so that as we move into this Interop networking phase we're not blend in Thank You Johnny for you know beginning that conversation yeah I'm not as mean as I said on my promise that's okay okay it's Joseph here DeLong is there any update on something that's supposed to be happening in the second week of September we interrupt them I see him typing until him again okay well it's the child this is the six through the 13th okay so I will have him I don't know message 18 different channels yeah I know there's somewhat of a cap at some point I don't know four it's going to hit it but I think for planning purposes we can start figuring out an RSVP sometime the next couple weeks could be useful just so people can get the firmware on their calendars okay yeah I think he's present ation I'm sorry he'll have them reply yeah thank you he tells me that he will go out dates for like the in throw up on like the next next like call so let her all the details by then didn't we hey thank you that's that's not right I'm sorry he's no he's doing a presentation like that's what he's prepping for so invites are going out today three to four per team that september 6 through 13th so thank you Johnny yeah Thank You Joseph okay is there anything else a few more minutes before we close you okay I got some PRS to do work on in this last little sprint before Sunday great thank you everyone I will be sending that release out on Sunday appreciate it talk to y'all soon and I'll get there recording up I'm in pretty terrible in there right now but I've recorded locally I will get it up as soon as possible Thanks everyone thanks bye thank you bye appears
Automatic transcript — names and jargon may be misspelled.