All Core Devs - Consensus #30

Transcript

[Music] [Music] okay stream is transitioning agenda is in the chat and let me pull up these

YouTube chat box talk to people let us know on YouTube on your stream page transitions all right cool so we're gonna go ahead and get started issue 1 1 2 our 30th call first thing testing and release updates we did release these are 9 3 which had some substantive changes to say transition

and networking nothing crazy check it out I have I forgot to get out something important in the networking in that PR namely adding a activation subnet bit filled to the DNR this ends up being backwards compatible with the previous method of guess in check and fully connecting the peers to see if they're on a subnet so I am going to release this probably today in a p09 for the BLS standards integration has gone through a couple of iterations there is a good PR or viewed it looks like that's going to be merged in very soon into

doubt at which point we will release that probably first week of this I'm not really waiting on anything but certainly by the first week of January we are undergoing pretty comprehensive auditor phase 0 with least authority I'll do an official announcement probably at some points a day and we're going to use that be 0 1 0 well be 0 10 as the target for that so that's what's coming up there the I have continued to fail to deliver for choice s I know there is some work so go on my harmony on that the guile or anyone from a harmony I want to give us

an update ok sure Alex just filed an issue in the it's back this repository let me just paste it here this is like issue with the format for and that we propose for a fourth choice tests and it also contains some already generated vectors we have finished like become dative accessory limitation that is very close to the spec and it handles things like delay data stations which were just queued and applied later on all this is to could be

useful for generating comprehensive scenarios for the fork choice and we think that integration test approach for the four choices very important thing because it could like find some issues with that with the integration of the four choice that are not covered by the spec and could lead to slight like I don't know a slightly different view of the chain on the chain in different client implementation so we will alexis working on the generator is so far and

when once we have this format approved we can just like generate more test vectors and probably integrate them with the ice pack later on so yeah the work is in progress and we have some some vector is already generated that's that's great yeah so that's awesome working on that thank you I will review that today and for a couple other people take a look at that grab their heads around the format yeah most interesting Parsons if this trade-off between very verbose and like almost hundred answer I

take the toasts to something that's very abstract very nice and then you'll have to build a lot of framework in here I'm interested in approach you're taking up the approach is like just to feed this will feed this become data processor with with some date data like attestation and blocks and and slot ticks and get the output that's it and yep can you link to the other is the the test issue yeah sure I guess there is no alex is working now on separate and

generators code from from like the processor code so yeah I wouldn't get in the issue it's like it's not yet ready gotcha thank you many I think you had an update for a straight absolutely hey everyone lots of cool progress the last few weeks on because so all our buzzers are now matching version 9.1 open spec will be upgrading to three or nine point four once at least three clients have implemented it I know we and by we I mean the lighthouse crew will be incrementally until to us or second week

with Jen I'm not sure about the other genes in other news we've integrated pipe and sub interpreters to allow us to have multiple pipe and interpreters per process so we're using them to basically keep the different pipe and implementations isolated with respect to their dependencies and global states and it allowed us to have trainings on be competitive in future to enable and disable high spec entry we've also integrated Nimbus to a bunch of different buzzers so a big thank you livin in this crew who exposed a nice ITC library for us to plug our test harness to so we've been helping out a few logging and error handling purposes but yeah happy to announce that Nimbus is on board now so you can check out the add Nimbus branch beacon files repo for

more details and we're currently fussing with inverse lighthouse in CR NT shuffling the block processing and the attestation process and in fact be confessor has potentially most likely identified its first crash in the cube should committee help a function yeah by the process attestation for the in target due to failed assertion so that's quite exciting we'll just raise this with the Nimbus team we provided traces but we should be able to provide a lot more relevant information mostly SSA blobs tomorrow we've also published a couple of fuzzers on posit which is a cloud-based fuzzing as a service platform so mostly doing this as a proof of concept to learn more about the

platform which looks quite promising the first couple of fuzzers are essentially free and then you have to pay a recurring fee we did have to adjust our build that was quite painful but we got there in the end and I get the long term plan is once the buzzers are stable we'll be submitting a request to Google course as opposed to basically use their infrastructure for continuous fuzzing so I expect this to happen around the end of January on a completely before front we've started looking at little box mutaters which is it's basically a library that allows your lending you type for the batteries so we can even use that in conjunction with guided buzzing engines

such as elite rasa that's the classic engine we're using for BT post and you basically define our a probe description files with beacon state and instructive causal mutate the specific fields prior to any SSS realization or any hoc state transition so for those of you familiar of how solidity compilers being fussed it's extremely similar not very identical approach and it's a very much working work in progress so you can check out the LPN branch if you're interested but we're making good progress on that front as well happy to announce that personick also known as Krypton mental has joined the because team you'll be working with us primarily onboarding prism while having guarantee so if you guys recall last time I provided an update I shared

so the challenges we were facing with some namespace clashes for compiling down to pausing targets so fresh anak comes from the f1 fizzling team so he had to deal with a lot of similar issues so we're very much looking forward to his input he'll also be helping this with closing coverage and optimization they'll do these next row this after solving namespace questions they will have a blog post next week for everyone to consume that will detail all the technical challenges we face and the progress we've made on beacon first and I guess independently of beacon trials we've also implemented an RPC puzzle for lighthouse which has been running for about seven eight days now with no crashes so we can't integrate that to beacon files but I would definitely

encourage all clients to do something similar so feel free to hit me up if you want the fuzzing target so if you have any questions so we can just look at the RBC files branch on the lighthouse week that's it for me thank you awesome things funny and exciting that you found the first fuzzing issue proto should we use this muscala mister kala Scala Muskoka yes no yes and no so miss Coco's built I can like deploy as many different coins as

possible just running on a see if these stating boots get fat into the system where am i free client every consensus machine you get all the looks out goods registered so for this kind of processing it's another sense beats yes I met I met with the good gets writer go for it your clients with the failure glowing mark it's not with the failed SSD blobs can we log them in muscala Muskoka of course we'll get those tomorrow a shed in with you proto cool ok other testing updates great no nothing special so if you test very introduced if the version updates

the spec but if Africa is passing them and you should be fine yeah great client updates we will start with Trinity everyone yeah so again just working towards test nets specific features so we merged in this PR for our initial pass at attestation aggregation which is shall ways here she can speak more to but that was exciting a big one was merging and updates to Pius instead so essentially how we handle hash sure calculation and we did some small benchmarks at least I'll say micro

benchmarks and saw like crazy performance speed so that's really exciting a bunch of other laundry list of things so except for about our client we've been making progress on that sinking stability stability and pilot p2p and the client in general and then further work on our eighth one day to conclude it awesome thank you Artemus so we've been working to get minimum viable sync algorithm up and running I've been making good progress there we're hoping to be able to join a testament soon and as part of that we've also been doing some refactoring of our

storage layer to make that more reliable and to make sure that we can support the queries we need at the key layer and we've also been continuing to work on integrating harmonies discovery v5 implementation and cardless that's great thanks very next prismatic hey guys Terence from Kris Matic so love our biggest achievement last two weeks was able to run a magnetic config which was 16,000 validators our single beacon node in a local setup so a lot of optimization was involved such as we optimize our it one service depository

faster assignment from our PC and CoreLogic so now we're working towards a test net restart with the version 92 of his back after holiday break so this is a big one as we're redesigning a few of our core components such as attestation pool service a safe service because now we have this new aggregator role and from the networking side we're adding these reject old pops of validator to stop the automated publication of the publish on message and then the initial matrix looks good from that and other than that were just fishing parts from from from the test net as there as they are reported by the users and that's it

from me great thank you Nimbus yes so on the core part we started on the attestation aggregation and we have PR bursts we started working also on benchmarking tool in the same vein as this year I pass it SSE arbitrary SSE state and you can have a report on number of calls or the time it took so hopefully it will help finding potential slowness even at suspect level on the inside we are starting to get interested into how to manage a fleet of

Nimbus nodes and have like you switch reporting and such looking into having stack traces with less overhead because it's slowing down the processing by a lot on the limb p2p and networking front so we had le p2p this week we are still a leaning back and starting from next week we will have mixed liquid to be demon and Li p2p pure name test net we had some UPnP fixes and the only blocker right now to join / test net is disc v5 the goal is to try

like the lighthouse test net we are now on zero point nine point three mostly we are waiting for the CCI or I suspect energy states to make sure that we are in line on Phase two part we have track who was working on Viper in the past that is currently looking into Phase two for the e and maybe on the language art and generating was on and side note on f1 so currently we are trying to see if we can sync with gas parity the normal if one chain we have a

bottleneck in storage and sync at the moment but we are looking into it and we are started we started also looking to EVM C which is an abstract back-end proposed by the LF team and to see if we could add Nimbus as an alternative I came to EVM C for the holiday break we will have a couple of team members of congratulations on getting the and their lodestar hey y'all so we're still think some final touches are 0.9 point to branch they should have emerged the next

few days because with that one also have like a minimal at the station ideation we're working on SSD caching I think similarly to which Randy is doing and hoping that I think that's going to be really helpful for us knowing for our beacon chain but I think it's gonna help us start prototyping out like like client server my client proof servers a little bit better because our just our hash tree root has been really slow in the past so we're looking forward to that and we will be upgrading our lip p2p soon and refactoring based on this

newer version and that should help us with like validating incoming messages which we have not been doing up until now because they this new the PvP version gives you the like validators and callback it just like it took a pretty major refactor I think I mentioned it maybe a few meetings ago but they just kind of moved from like the old an older style of JavaScript to a newer style and a lot of the api's changed and it's just a little more a little more friendly to use and we're gonna be there's gonna be using it a little bit differently so cool

good to hear it's games and maintenance great White House hello so we started I guess last week a week before we started I made that 16k validated test that it ran for about a week it had four nodes on it it's quite small nodes on AWS each running 4k validators totem ended up in a loop with it it's a station publishing receiving over gossip sub loop this race exhausted the resources of two of them which took 50% evaluators out and then we stopped seeing finality so we managed to recover it after the first outage of 100 epochs without finality by just doubling the

disks and basically control-c and up enter again and even some nodes that had larger disk managers survived through the down time we come out the other side following the head which was pretty cool and so after that a couple of days later it got into the same thing and went down so we just kind of let it die because we figure we should probably fix the bugs as opposed to just this I've been around them so as a result we're now targeting of a zero point one point two release which has a fixed loops of course and it also has sparse state storage in the hot database we're doing in the cold database before but now in the hot 2 so that we can survive for longer without finality we also learn an interesting lesson which might be useful for other people that we were storing our state's

before our blocks which meant that if you kill - mind it when it was storing the state you would have this dangling pointer of the blocked State Route pointing to a state that's not stored so this made us realize that database wasn't consistent so we just swapped them around we've added a fix to our f1 cases because we previously relied upon an archive node so now we get all our deposit route deposit counts from the logs not from the contract calls because I think those will prune away old contract state we made some API upgrades that allowed the fo chain beacon ji n bit flight team I'm to launch a POC Explorer for lighthouse we've also added a bunch of stuff that you know the community suggested ages been busy in

the networking side he's updated rust gossip sub for content content addressed messages he's in the process of merging bosses up down into the main roster p2p library and he started implementing the naive attestation aggregation strategy so I think we're gonna launched a new test net tomorrow and make it public next week if all goes well this time we're gonna have more validator nose and dedicated boot nodes so that we can maybe a little bit more resilient and we're also hiring Ross developers so check out at Twitter if you want to link to that awesome on the attestation loops does this content addressing add two stations that fix it or do we know the

source is there any learnings to share here I'm not sure that age was able to fully identify what the the cause of the loop was we can add some more logging so hopefully then we'll know exactly what it was we basically put in a bunch of fixes to stop it from happening I think the content address matter just helps but yeah that's kind of ages domain I haven't been in there so I'd be speaking out of turn can you repeat this date storage real quick and then maybe write it up mommy that's interesting the difference of states origin block ordering oh yeah so it's if you store so a block points to a state but a state doesn't point to a block so if you store the state first

and then before you store the the block and you crash it means that you have some adjuncts eight in your database B but you don't know it's there whereas if you store your block first and then you stay if you crash before you store in your state you have the block there that points to a state that doesn't exist and in our code we return an error and kind of exit early if that happens cool Thank You Jasper yes oh uh so for also we are mostly still testing against a test net against first magic so trying to fix some syncing issues like is currently a

little bit slow so we try to make sure the connection doesn't drop that often so we can sink faster and trying to get into the discovery protocol with horse Matic using the cat cat Malia yeah so that's basically what we're doing and I think the go is to try to catch into as many ties net as possible so we can have some yeah so just for us cool thanks and never mind myself okay so we still hi was doing phase zero we have they don't know we're up to have the core beacon

chain full choice they said and BS stuff working on honest validator have basic what creation I'm about to do validation and then get our first look at X appearing there's still lots of parts so validator attestations rather than blocks all the storage staff it's one real integration we're still only on spec 0 9 1 and we'll catch up and what do you intend to use for your good p2p stack ah good question though so with with one option is some sort of interrupt with the lib p2p existing integration the

averages are I don't know which parts are being used but there's a library appear talk which is another like library of different p2p algorithms same sort of Heritage's as Lib PDP and the guy I can add here so I was I was analyzing different approaches I think the main thing will be a possibility to look at the mmm and the existing IPF fast are they p2p implementation in doctor but it's more like 4050 percent done and it was developed probably like

actively one or two years ago so this is something to explore for us I think we'll be just implementing c-sharp implementation and we can start with with connecting to one of the existing like go demon the ones in the past I'm not sure if this is viable option at all but we'll be exploring it as the next step yeah it works on the go demon we are using it in Nimbus it works the main issue is that you don't control the logging parts and so some things stay hidden when you work on the frame - you really like to know how many peers you are connected to on stuff oh that's great news so I think we can track the message messages roll maybe unless they encrypted probably encrypted but then it

will be this thing that we'll start with for sure so the first first stages phase zero will be on this go demon and in the meantime we'll be implementing quickly to pay for Delta but it all depends on like whether we were if the resources or the Gogi moon will be enough thanks thanks for these news well and then there's potentially the option of using rests or NIM right to create targets yeah you know it's actually very easy to bind from C sharp turn to rust or success class libraries though if those libraries will be sufficient then we should have a very good quality bindings with good performance so it won't be over investing in terribly p2p stack for

Delta not sure if it'll be worth it good thank you I'll probably reach out to people as we get into that on whatever communication to see for people have any tips or suggestions yeah cool there's that networking channel and the discord which is good and get out of issues and things test networks up and running real harmony yeah we are currently working on these for choice staff also anton made a

couple more of simulations and yeah you can find his write-up in the notes to networking call to the yesterday's call also mitri is working on basically five simulation he tried to evaluate it dentistry simulator and it's like it's been announced in the documentation of NS three that it supports python but it it doesn't support it doesn't have a good support for fight and for example you can just create your own application like I know disco fire stack and

evaluate it within industry and probably you will fall back to Anton's too similar as a dental health as grafted and also why else i've been accidentally reviewing navy corrugation attestation found a couple of issues filed them so that's that's it so far thank you ok let's move on to research updates to start Joseph DeLong do you want to discuss the new group that yaller for me

yeah sure so we did some people from Artemis and the harmony team are emerging and focusing on phase two phase one research now we're starting January 6 will be all together but we're kind of starting now a little bit I think and Anton is working on disc v5 simulation no real updates yet and I think the real premise of what we're doing is trying to increase the amount of people who were working on the research after that great and it was named pxrx cool great thank

setting and I suppose you know you can give updates certain research or whatever makes sense in the future thanks Joseph ok on to other research updates Vitalik getting the dress today it feels in the main kind of to research areas right now it seemed to be a new one is just figuring out the right short-term data availability scheme I think the main update from the kind of chats we've had with starter and other people recently is that the idea of starting a merkel root it does seem like the best a long-term approach but it depends on having us dark friendly a

hash function that we can fully rely on and that's not going to come for some amount of time so before then there's different options like there's just using the two-dimensional scheme that we've had for over a couple of years that may even had a PR for back in the day there is using Frye as a kind of the main ingredient behind Starks as a fraud proof mechanism there's some some other ideas so that's why one that's one thing that a big risk of trying to kind of think through another thing is figuring out how each transfers will kind of what

will work in phase two and I know I've been talking separately so we'll and and also an OMB another in the other research call about this but I mean maybe I'll just kind of repeat the problem set up for everyone the problem set up is basically that the with the kind of minimalistic structure for how the east to begin chain will work the like cross shard messages are under purely a higher level concept right like the base protocol doesn't know about them it's just a bunch of moral proofs and code verifying other merkel proofs and if the base protocol doesn't really even know that any of this stuff is happening it's just entirely this higher-level thing but the

problem is that keep like ether the currency can't be an entirely higher level because people need to be able to use ether the currency to pay transaction fees and transaction fees have to be legible by block producers and people want the ability to be able to and have transfer use from one shard to another chart and this these transfers need to be ideally and have complete about within once a lot because that's what we wants to be want to be able to achieve anyway and the challenge so the challenge basically is that we need some means of transferring if it's meeting

execution environments and I have between one shard and another shard such that this mechanism is also understandable by block producers so it's kind of at least semi enshrined in some sense and there's two major categories of solution to this so one of them is to just kind of go all the way and create a ultimately limited appetite for at this point does that impression feel correct to people by the way so by guaranteed cross shard messaging I basically mean like in shard a you can you send a and of crush our message to shard via and then the protocol itself kind of guarantee is in some way that

the that cross shard message gets received by shard B and then gets X and then gets executed by ship but by shard B and there's kind of key and gas mechanics figure it out to to make sure that this kind of thing doesn't kind of add protocol level to make sure that this doesn't lead to like DOS or attack vectors anything like that there's no appetite it's just that the it just feels like very much tightly coupling in a way that is brittle and so I would need to be demonstrated that it's not follow that path yeah I would second what Danny just said um it just feels tightly coupled and then brings issues as far as the transaction

but like what's in that transaction on the second chart as well to me that sounds like a nerd speak for a limited appetite so if we don't do the guaranteed cross shard messaging thing which like in and it does seem like a like a reasonable path to go like it basically makes aetherium what I know or eats you a step closer to being this kind of pure data availability layer like not quite because we also provide almost almost pure computation but definitely you're kind of more likely or 1.5 complex complex city than we are one

complexity so if we go that route then basically and though there needs to be so let's say I have a transaction in some other X in some random execution environments and I have some each from that execution environment which basically meet so and we'll just call these execution environments with name starting with E I don't know I'd say I have some ethnic in execution environment Eddie and I once to send it to my account inside of Eddie on shard B then I send a cross card receipt and this is a concept that and if Eddie understands and I said this risky gets included in a block on short a then it

gets included in a block on shard on shard B and then it gets verified and it gets updated but then uncharred iya I want to have the ability to then kind of immediately use that if in order to basically pay for gas and send transactions and the problem is that like first of all block producers should not be expected to understand the execution environment because there's just lots of them or potentially lots of them and so and potentially it gets hard to verify how many of these execution vibrates we trustworthy whether or not their ethos kind of backed by actual years so the challenge would be so the way to do

it would be that that each kind of actually gets held in some under lot some special execution environments that block through we'll call it the the ether environment that block producers are required to understand and then it feels like the simplest approach would be to say that the only things that can hold accounts in the ether execution environments are other execution environments I mean and our block and and our block proposers and and if we do that then basically what would happen is that you would send it so uninsured a we would send this proceed and then uncharred bia that receipt were getting

well you know at the same time there would be kind of one other receipt that includes in all of these different eath transfers and that other receipt would be that other receipt would kind of go over a shard B and that receipt would prove that the actual underlying ether got moved from Sharon a to shard B and then that and then on shard B when you have a transaction get executed then that eath would actually need to get mu transferred to the Block proposer as part of the execution so like if we do this right then the eath execution environment would be the only one that bought producers would actually be

required to understand and it's basically taking the functionality that would otherwise have to be enshrined at protocol layer and you kind of putting it into an execution environment and [Music] that like it seems like it works in and there is convoy there is some level of complexity but that's essentially a complexity that would have to be there anyway the thing lots to figure out is basically that there's like special function functionality that might have to be included to make that make this sort of thing work so still more thinking on this yeah there's a lot of little intricacies there yeah depending on the design of the system

and the things for example you know that seems like it depends upon being able to specify transactions happening in maybe a series of these per shard blocks so that you can maybe do all your ease transfers first and then do execution on other ease things like that ok any questions for italic on that I'm sure we will discuss that maybe more on the face you call in January and always kind of on each research to stuff so check it out other research updates excuse moving yeah ok cool so these two call coming mid-january

we'll give a date here and bet that one will most likely focus on discussions around crush our transactions some of the things that our Luck's been talking about and likely the fee market I think are probably the the two hot topics so the goal during that call is to really hyper focus and use it as the brainstorming productive session some stuff that quill has been up to we are continued doing continue to work on tooling for the contract EE to run so we can have that running and and and we can play with that across shards so we're trying to set up a kind of a clan to make the tooling to build these E's

more kind of truffle like so it's a lot easier for other people to dive in so that's some things that we've been doing and then we also need to make it quicker because there are a lot of right now things that are slow to even you know run this contract ee so we're kind of bottlenecked by our tooling right now so we're working on that we are releasing a first chapter this e to resource or book so super excited about this the draft is done we have an outline the first chapter I think is really really good actually and so the whole point of this I think actually maybe just wait will likely release it next week or maybe the week after since that's holidays and I think people are gonna be really excited about

this so let's all say for now we have stepped up involvement on some of the state provider relayer questions so one of the things that I've been talking about one of the big differences in the two is that block producers don't have the state where is the eath one X group is doing research around the premise that block producers are minors and youth one have states that's a huge difference between some of the challenges that we have and so when we look at the fee market everything unto end that actually has a significant impact on everything so Sam and on Skaar are putting up a write up soon of different directions that we think that this can go in we're hoping that people you know Danny guitar like other people will kind of help but help make a

decision on direction so there's kind of different routes that we're thinking there so stay tuned there should be right up underneath research there soon let's see cross our transaction so I've started going in on this I'm specifically starting off by looking at eath one data right now trying to bloat that evaluate that kind of hyper focus on four of the main contracts and one of the goals is to look at what can be parallelized right now you know what practices for writing contracts needs one how though that wouldn't necessarily work in the eath 2 world and then see how how would we write those differently how would we make that work how can we reduce pressure overhead etc etc so I'm

hoping to me this is kind of a three-month style project that should result in a really really good write-up on so that's that's been started let's see also figured out collaboration with tx/rx so super excited that you know these guys are joining it on research efforts oh yeah and pretty excited to club with these with this group as well so I think this will move things quicker and I think overall this is just really good for youth to that's all from quote thank you other research updates just one quick question is there like any kind of working group or even

people like anyone who is kind of moving forward on figuring out details of the eath 1/2 ECU bridge um I don't think there's a working group yet but we do have somebody Mick il is kind of a sign to that effort and it's working on it okay I think one person is fine for now but it's just give like our resources are kind of highly parallelizable and feels like it makes sense to and not waste be proactive and started thinking and but I'm thinking about this and moving toward a kind of full spec for that component even now yeah um this is quick update for pxrx all say we're we're starting to kind of like narrow or

research topics that happens to be one of them and we're gonna do a workshop outside Stanford blockchain conference if people are around for that just like we did last year this time in particular focusing on phase two other research updates just a quick not from my site we are organizing an event next year in May is ETH Barcelona is a short event the first time organized this one so it's short event is a one-day event and we hope to have it

would be good to have some of the teams working on eight-point 2.0 may be presenting some of their updates at this audit event so are we having the link the current website there is not much information yet Twista date and but we would be adding more information on the coming months and what is the day that's May 15 of the top of 2020 great thank you it's exciting thank Justin I think I saw you have mute I'm Bruce and I guess you know last time I mentioned there was this this is this you know breakthrough but it turned out that there was a silly

mistake that I made that was noticed by dampen a so you know basically the problem that I'm trying to solve is to build an optimal snark which has basically an optimal prover and verify and what we have right now is smart with optimal verifiers but not optimal prove it and the way that stocks are built is that you have this pony on polynomial commitment and then the ioki and like like the few of the ideas like that we had a couple weeks ago still stand on the on the perennial commitment so you can you can do polynomial commitments without any FFTs and this is what makes the this Knox suboptimal for the approver but then you still have you still to come up

with a new way to design and IOP without the 50s and I think that I have an IEP now that has an optimal prover but the trade-off is that the verifier is no longer optimal so basically we flipped the optimality on the program verifier health suboptimal fire it's a logarithmic number of not exponentiation so actually it's pretty good but yeah I started to run through all the numbers and the proof is like logarithmic number of g1 elements so kind of about the size of a bullet proof like 2 kilobytes that kind of ballpark so yeah so basically it's like yeah I just wanted to kind of

throw in there is this kind of general question I keep having on general is your knowledge groups which is that I just keep failing to get a good answer for why like any sub linear scheme cants just become a become a constant verifier ski invited by just like we're basically rehearsing it over itself and like I people tell me things about kind of soundness breaking because of this like intuitively that doesn't make sense to me right because a proof that says either statement X is true or these assumptions are broken is the same thing as a proof that says either either a proof of access true or these assumptions of bookid where these assumptions are broken like from a

first-order or even a logic point of view they just collapse into the same thing so you know so I'm gonna bury and he said there's two types of two types of photographers with respect to this there's the ones that are like oh yeah that should just work and those are those that are just that it just feels wrong hmm so I don't I haven't seen like something very distinct as to why it's wrong other than it feels wrong right I mean might be one of those like theory versus practice things right where like more than more theoretical of cryptographers they don't like the Oracle like model of hash functions at all for example you know so I just wonder if it's something it's something

moved in that direction like maybe you can't prove stuff as easily about them yeah my impression is that it's not the soundness that is the issue it's the knowledge soundness so the extract ability of the of the witnesses and apparently I think it's like the argument is basically that the extract ability kind of the difficulty to extract kind of grows exponentially with every layer of recursion and so you need to be very careful in the safety proofs that's my understanding but there's another problem with this recursion is that it but you need to really happy handed machinery like

cycles of elliptic curves and right it's like a constant factor mmm I mean that's purely a practical problem right I mean theoretically you could definitely do it because it's Universal computation but like one more practical example of this as like correct me if I'm wrong but there is a version of something board looks like that has square root verification time right yes Terrance yeah and so you could just stack that on top of itself and get a bulletproof what's caused the verification done but the constant would be huge all right right huge constants okay thank you other research updates for the body great I have an item here highlights from the

client survey I haven't had a chance to go through these thank you all for submitting them one of the things that I did see in a very cursory look is that we still need to get noise of TPP and plantations going I think some of this is due to some uncertainty and it's just probably prioritizing so what other than that I really myself proto and he smothers we got to dig out and see see what's there it's just for mating a planning this is for aiding and like figuring out where maybe we can help or others from helping resources if there's some clear bottlenecks and things like that I really appreciate it the initial look it's a lot of bloody good time for their

other thoughts on this things that came up that we're concerning about it thinks that I miss things that we miss okay networking the bulk of this conversation has moved to a networking call which we've done to this month they've been very productive we'll probably do one in the second week of January dens notes are posted in the agenda the other questions thoughts updates on networking that weren't necessarily covered in that call or we were into this okay spec discussion Paul has a proposal issued 1537 in the specs Rico that

pretty much says instead of using block depth from the head or block depth using a using time stamps to reduce the overhead of caching and the essential issues of handling reorg locally when trying to figure out the said local version of the chain in view I my initial Lucas and I up all the others is that if its overall a simplification on the client side that in terms of like security and things that were looking to get out of this mechanism it seems so we fine even and I don't want us all to end up on different

versions of this but I think if client a and client B of the different versions of it like me would still and almost all scenarios come to the same conclusion about some data at least over time to do the voting mechanism Paul do you have some items some things you want to discuss here I think mainly we're kind of looking for some buy-in maybe some acknowledgement of the pain points from other clients and whether this would be something that seems oh yeah so basically the current mechanism doesn't cache so well you have to cash all the way up to the head the head of the s-1 chain then you have to catch all of the

way back to the previous f1 block so that means that the size of the case grows linearly with the time since you've got last night you may make it successful that's one vote and then if you want to protect yourself from reorg on the f2 chain you also have to cash all the way back to the previous the f1 at the previous finalized block so it becomes very difficult to catch the mate and the most annoying one it's basically you have to catch up to the f1 head which means you have to deal with reals so this is the proposal I've made means you you follow you can follow at 128 blocks I'm with the current one even if you if you like that there are points like at the start of the voting period where if you don't have an immediate connection to the f1 chain

your ability to vote is impaired not massively but somewhat but with the thing that I proposed you can basically not talk to an f1 node for less than the follow distance and you'll be fine I think clients will find this is much much easier to implement so have a look and yes see if it's easier for you if it works it also gets rid of the beacon state read when you're the occasional one you need to do when you're voting so I think that would make Preston happy and if you are not maintaining a cache which maybe you should this would end up being a very similar mechanism correctable in terms of making dynamic

RPC calls yeah so the problem that we has is the weird thing about the current voting thing is you need to you need to find a block by time stamp and the f1 RPC doesn't support that that's one of the reasons you need to case yeah it'll be yeah I think it's kind of different but if you're gonna call from an RPC or if you're gonna read from your cache but I think I'd be very surprised if anyone ends up actually reading from the RPC so every time they produce a block who's you go to read like more than a thousand blocks and yeah it's just it's just messy does anyone want to say anything about that I have something else related that's what I want to bring up yeah quickly I mean please take the

conversation of the issue but are there any visceral reactions on this being bad and really messing up your workflow okay issue 1537 tried to get some eyes on that the next like day if possible Paul next issue yeah so the next thing I wanted to talk about was how we have to wait for Genesis so when your the deposit contracts launch we have this period where we're waiting for either me in Genesis time or the right number of validators to start so this is critical we've implemented it but it's kind of it's annoying a few aspects one is that it adds a whole new application states

your beacon to your beacon node so you have to have this period where you don't know what Genesis is you don't you can't have a beacon chain so for us it means that you know our RPC API expects to there to be a beacon change so we can't start our API and it's just like kind of all this weird usability stuff about like running a node before it even knows what the blockchain is so it's kind of frustrating from that perspective and it's also another like for all of the clients they're gonna have to implement this like listening to the f1 chain then producing the Genesis state they're all gonna have to make sure they get it right and we're all gonna have to like you know pay someone to ordered it and it seems to me like from like a pure engineering perspective and there might

be like some I don't know like some political like a social aspect to this that I'm not saying but it seems to me that it would you get us that quicker if we just said that on like the EF produces or someone produces a script that can listen to the s-1 chain and then produce the Genesis clock and this is like kind of like a widely like easy to read like ordered once script and then once it produces the Genesis state then we just like drop that into our clients and and then push it out there and there's like a couple of things you can do too like if there's a couple of edge cases there where like if you want to like if there's like two days between when Genesis happens on the s-1 training

when it happens on the f2 chain and like you would have to be at your computer to load the tool download the new release but there's some things we can do with script there so but I just kind of wanted to table the idea of getting moving this waiting for Genesis thing outside of the beacon modes and making it this separate thing so it's kind of this like community like outside of the protocol agreement on what Genesis is gonna be and then we load it into the clients so specifically this one is not this is not spec chain and to you say and then we load it into the clients but that can easily be like a bash script coupled with this good yeah yeah that's right I was looking is awry from him about this and he was saying that it basically ends

up being an instance of starting the beacon change from no entrusted state and which is something we have to implement anyway and something I didn't mention before is obviously that all of this code that we write the listings again and the system and then launches it basically gets thrown out after that and I assume that anybody that wants to run like private test nets and stuff isn't going to bother with the ceremony they'll just produce a Genesis date and roll from it so yeah so I guess specifically what's the action item well I guess the action item would be that I get that so the clients would perhaps

think about this and then all agree that you know we don't we don't want to implement this it's waiting for Genesis thing and then we would perhaps agree that I like the if you're in foundation is going to do it or maybe like one or two clients are going to do it yeah I'm not sure it's it's like it's not imperative but it's one less thing that we have to do before we launch the beacon chain I'm not sure if there's like an immediate action for it but at least if we can just kind of think about it and maybe if someone thinks it's a terrible idea they can put the hand up I can I can make any make sure that the thing is if somebody does if some people think it's a good idea it can be done and if someone thinks it about it's a bad idea

they can still use their current flow yeah yeah making shine yeah so you want to start the chain from basically a plastid state with it yeah that's right but that trusted state so he wants to use the capability of starting from a trusted state to piggyback off of a separate script that would find that state from Jenna from reading Genesis from one but it wouldn't just be the same as what we're doing right now basically it's just so you subtracting that body wind doors have been scripted

yeah that's right like it's it's mainly like a kind of an agreement that it's not expected of the earth to clients to have to implement this thing that there is going to be like it I think ultimately like if all the clients won't agree that they're going to do it it it probably has to be someone like the etherion foundation that produces the script that produces the genesis state otherwise it together it we like if only one client you know writes this script and we're kind of just trusting one client with it I'm not sure okay maybe but like like doing the ceremony it kind of like brings a bridge you know like you actually like properly bridge it want to meet just like if you have this

trusted state you're kind of like big city no offer you can also modify the script you can do whatever I make the issue I guess the action item is does somebody want to write this script specifically does the we can chat about it there all right Tom's been thanks Paul great I just looked at is valid Genesis state to make sure that it doesn't trigger earlier than Genesis time it's good okay other spec items it's that discussion there's the you know phase 1 PR obviously that needs

love and has not gotten it but I don't know if there's much discussed there okay okay final item open discussion closing remarks anything great happy holidays everyone talk to y'all soon we'll plan on doing this probably I don't know I I need to leave my calendar but probably not the day after New

Year's and maybe do we get for that thank you everyone keep up the good work talk to y'all Simon soon thank you thanks everyone [Music] [Music]

[Music] [Music]

[Music] [Music] you

you [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music] you

you [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music]

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

[Music] you [Music]

[Music] [Music] [Music]

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

[Music] you [Music]

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

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

[Music] you [Music]

[Music] [Music] [Music]

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

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

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] you

[Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] you

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music] you

[Music] [Music] [Music]

[Music] [Music]

[Music] [Music]

[Music] [Music]

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

[Music] [Music]

[Music]