All Core Devs - Consensus #34

Transcript

[Music] so

[Music] [Music] okay the stream is switching over uh if you're on youtube hit me up in the chat box i know okay here's the agenda issue 129 same as usual um testing and release updates

Danny Ryan: i'm a little bit behind uh east denver and then the related east denver flu um has set me back a little bit so i

am behind on getting that release out um that has some stuff that came out of police authority audit which should be shared publicly very soon um as as well as a bunch of little things that we've been um catching especially on the network side the past few weeks that should be out in the next few days which should be that stable target um post art audit target we've been looking for um along with that i believe uh the alex from txrx has started or is starting on some poor choice tests uh migrating some of the four choice tests has been working on

uh from java into pi the pi spec let's hopefully get some of that out soon um in addition to that i did a huge uh pass on the testing to get basic testing in place for phase one um which also involved doing some fun stuff to get testing working across forks properly in many cases um that pr is up and should be in soon um that's primarily it

produces anything on your end uh hello so we have

uh during ethan for my continued work on the networking ripple with this thing

Protolambda: i hope to test clients networking functionalities so it has discovered v5 and rpc as well now working like this version uh this is the ken's lighthouse so i'm still working on testing if the compression of rpc works well it kind of relates to the open vr we have this change in how we do compression with snappy from just object to training and since the networking call moved to next week it

may be good to do like get after the call talk with like the network people and so this kind of feature makes it into the next release and that's about it

yeah

Danny Ryan: cool i i think generally people have not cared that much or have been positive in response to that so i do want to get that out into the next release but um if you do feel strongly about it now is the time or after the call in that pr if you want to speak up and we don't have medi right

yeah midi's not around but i can give an update on on the beacon

fizz yeah cool we're interested okay um yeah so

we recently published a blog post which kind of um gives a lot of the progress update um which is on a website and i can and i'll link here after i finish just giving an overview of it um but i guess the main points are that we we found an interesting bug which is a deposit with with an invalid merkle proofs in nimbus which they patch pretty quickly we've almost completed all the block processing state transition functions are covered in the beacon fuzzing i think the only things that are remaining are process random process s1 data but they should they should be done pretty quickly uh definitely by

the next update uh we've successfully integrated prism we have to use kind of a fork of go go fuzz build which allows us to use like shared library compilation and symbolic linking uh but that has some issues because nimbus also uses go um in the go wrap around library so we expect to have prism supported in the fuzzer in master hopefully by next week uh we've also improved some of the tooling so that we can programmatically generate corpus for the from the test repo provided we give it a specific spec version which helps us kind of build these things faster we've got a better build process so

we've updated the make file um and the ongoing steps and current next steps is to start including the epoch state transitions java integration and update to the f2 spec version 10.1

sweet

Danny Ryan: thank you very much

Jacek Sieka: uh i just mentioned that i'm a little bit surprised that you're running to go uh on the

present side yeah is it because you know are you no longer wrapping lippy t2p using native native nim well we are

Jacek Sieka: wrapping that but it's it's lippy to be part of the fuzzing

it

shouldn't be right oh yeah

yeah the issue is using multiple go different uh libraries

um so there are there yeah it's just that we don't we shouldn't have go as a part of the normal build we just have a demon running which is um which is running as a standalone processor like the nim code shouldn't be tainted by goal so i'm just a little bit surprised but we can take it offline yeah fair point yeah there may be some some other issues yeah i'll talk to you after cool any other testing updates

Danny Ryan: okay um client updates i'd like to hear the details of what's been going on but also um with an eye for multi-client test nets in the coming month um i'd like to hear kind of the biggest bottleneck what y'all are currently doing to address it and also if um we should be probably seeing some similar issues across clients so um if there are things to share feedback to give each other please chime in and we can start with uh teku

yup

um i can speak for techo um so

we're making progress on sync um we're connecting to and downloading blocks from prism sapphire testnet um we haven't yet caught up to chain head we're working through performance and reliability issues that are slowing us down so there's more work to do but exciting that we are downloading blocks from the live test net we've also been doing some work related to deposit processing we should now be correctly processing pre and post genesis deposits we've done some work on the discovery v5 implementation from harmony to make integration with tecu easier and we've confirmed it works well enough to discover nodes from lighthouse um we've also been making progress on

our rest apis uh focusing on apis required by block explorers and lastly we've started working on an encrypted key store for local key management and also a standalone signing service for management of keys externally

um as far as bottlenecks

um one issue that we definitely need to address is storage so we're kind of using an absurd amount of disk space right now uh we haven't really started looking at optimizing this at all so if people have ideas that would be interesting um we floated some ideas around about maybe using um a tri-backed state storage so that we're sort of only

storing diffs between states or maybe like a state snapshot state snapshot strategy where um we only store like a few states and basically rebuild them as needed if people have ideas about general storage schemas we'd be interested um and jim if you're online i think you had some some issues related to each one data management i don't know if you want to speak to that

Cem Ozer: yeah i'm online uh one thing that like we've been having like problems that like uh we were like trying to like uh process deposits efficiently um so like for that like we wanna just like use event logs instead of like

just asking blocks and then getting deposits in them uh when like starting up like tekku however when we do that uh like there's an issue of like being able to like miss a genesis block which might have like no deposits but an eth1 timestamp so that's kind of like an age case that we've been working on for like the past week but like i'm curious if any other clients have like thought about that scenario or like like already fixed that and if they if anybody has fixed it i'd really appreciate it like knowing how they did it so basically the issue is uh like just like getting deposit events and using deposit events because

otherwise like it's just like really efficiently you're hitting like the east one node for each block uh after your like contract deployment plug contract deployment block basically and uh being able to like start like like trigger genesis uh on a block that doesn't have any deposit events due to its time was that clear

yeah yeah so the is it that the only blocks you're aware of are those with uh deposit events so that the e1

Danny Ryan: api is not available to

give you just the existence of a block

it is like the existence of a block you

Cem Ozer: mean just like one block

Danny Ryan: right

Cem Ozer: yeah it is definitely able to do that but like uh in that scenario like uh like we would be asking for like basically each block after like the uh like e2 deposit contract deployment block and that's a very bad like way of like getting like like all like deposit events so like there must be a better way to do it

i feel like

Danny Ryan: i would definitely uh reach out to paul after call

i think he's he's been deepest in this

Cem Ozer: good idea thank you um any ideas for meredith on reducing uh state size

and disc just uh bangkok just after we have been looking into slant storage and how to reduce the start size for lighthouse and we figured out what the the registry is the biggest and you can take some hybrid departure so you can so you don't do the field tree

storage because it's much too detailed you don't want to store binary now it's on this old time what you can do is store the finalized state in a flat manner and whenever you load it into the state converted to three and then just for the whole part of the state you maintain these deaths of like tree and store them as gifts instead we can take that after the call with michael and me

cool yeah i think that makes sense

Danny Ryan: cool thank you um how about trinity

one sec

Carl Beekhuizen: before we move on um meredith

you mentioned you're implementing a separate signing interface um can you speak to exactly what you're implementing there or can you share a link to what that is

yeah

someone actually dropped me a link to an eep let me see if i can find the actual specification

Carl Beekhuizen: awesome thank you

um i'll i'll

i'll find it and i'll drop it in chat

yeah so

Ben Edgington: internally we're calling it eth2signer as a standalone signing as a service um there is uh if you look at the pegasus eng github there is uh e2 signer repo but it's just started just now we haven't made a huge amount of progress just yet

but uh it would be good to get some common interfaces uh on this stuff if anyone else is interested

Carl Beekhuizen: yeah i agree this it would be really cool to have a common interface particularly if you want to support hsms for signing further down the line

yeah um backhand and front-end interfaces for sure yep cool okay

Alex Stokes: back to trinity yeah hey everyone um yeah things have been a little slow uh mainly just working on spec updates

we have some work on stability of our pilot p2p library uh updates to fork choice and some integration with milagro and i really can't speak to bottlenecks like we've been discussing at the moment but i imagine we'll have all the same issues

everyone else has happened cool thanks uh numbers yes uh so we have a

Mamy Ratsimbazafy: lot of updates for the past three weeks on the core specs side so we are targeting uh 10.2

uh we created an auto detection on a report on skip test because we realized that when refactoring the repo sometimes we forgot to re-enable tests and sometimes they show up on phasing so that's that that should be catched up much earlier we have a bls signatures implementation ready uh so far we have been waiting for the new vector uh test vector fixes but um uh we'll go ahead next week because this is a blocking or implementation of the honest

validator spec which is implemented just except everything that touches bls signatures we are working progress on attestation aggregation and folk choice and also we so in the past more than a year ago we had the bounty program and that was how we maintained the if one at first and we restarted this bounty program and the first two bounties would be on improving test runners so that can be used with nimbus and on an https server so that it can be used

for uh collecting metrics and for uh eth2 api

now on the networking side uh we have a

new code to manage uh peer lifetime so pretty disconnected predict reply we have uh we had a significant focus on discovery in the past uh three weeks we have some issues on windows maybe on not traversal and all of those issues manifest as finalization issues

on the lipitoup front we have

excellent progress on noise and we are now looking for interrupt testing candidates

with our own natively p2p backend

on the speed size side

we have implemented a lightweight stack traces and this improves uh both compilation and runtime of or nimbus by twice because [Music] we enable stack traces and they take a significant toll on the binaries because they prevent lots of compiler optimization so this is a very welcome improvement

on the devops side we had

we

fixed our test net deployment because we sometimes had nodes that were not reset every week and that caused issue and also we have created a specialized infrastructure to test finalization issues because i talked about uh discovery that manifest as feminization issues but also when we have speed issues like we have too many nodes on the same machine uh the way we detect that is by finalization and we want to know if the finalization issues come from spec

from speeds or from networking on if1 we are pleased to say that we pass all the transaction tests uh from f1 so the same one as deaf and parity and uh we are other evmc implementation done and that would allow sorry not yes host implementation done and the next step is to allow fuzzing or own evm implementation with the same tools as evm1 in terms of bottleneck

uh one of the major bottleneck that we had

is a discovery to be able to connect with other test nets without having to use some bootstrap nodes and the other it's a bottleneck more for testing and debugging is a log volume right now we create about 80 megabytes per hour of compressed logs because we need some verbosity to debug assuming we grow to thousands or tens of thousands of nodes it will be impossible to manage by hand to to debug so we will need some kind of parser to

deal with all of those and for the volume uh we just rotate the logs every four hours to keep

it manageable and not flus or adws instances with logs interesting thanks on the fourth choice that y'all are working on are you all working on a pro proto array or what are y'all doing there so for choice uh both [Music] one straight from the copy past it

from the spec and one implementation from proto array and the idea is to make it almost

an independent module so that it's easier to fizz and in terms of testing we use the same approach as lighthouse which is to create some kind of interpreter uh that says uh okay push a block at that slot push another block at that slope not now run uh process slots and then now run the fork

got choice um anybody

Danny Ryan: else running into issues with massive amounts of vlogs and writing a custom parser and have any advice there our thoughts

we kind of dump ours all into aws and

have aws kind of consume them so there's no fancy um anything to kind of help there but you did mention natural vessel i just wanted to ask what kind of nat traversal techniques you're using

uh it's a mini upnp okay cool thanks uh mommy

Ben Edgington: could i ask a couple of quick questions uh you mentioned spec v10 0.10.2 this is not an official release right what do you mean by this

um sorry so it's 0.8.1 i was sure it was updated

but maybe i was thinking of the spec that danny was supposed to release yeah yeah

Danny Ryan: fair enough

Ben Edgington: um on the bls as well again you said you are waiting for test vectors and so on is this the current state of the bls standard because we know it's going to change a little bit more or did you implement the newer stuff as well

Mamy Ratsimbazafy: no it says draft five so the one that is current and the vectors i'm waiting for it's a fast aggregate verify because uh some of the test vectors are expecting uh wrong signatures are actually correct it's the same

problem that you raised

Ben Edgington: yeah uh if you re-download the test repo they're correct in the latest taji zed i mean that confused me ours was cached and danny didn't update we didn't change the version number on the test repo so uh if you've cached it previously they're wrong but the latest version is correct

already because okay i'll check it out they're

Danny Ryan: i believe they're incorrect actually in the repo in the code in the repo and the files but they're correct in the tar gz right associated with it um which was maybe a confusing decision to make armed it was certainly a confusing decision

making my apologies

okay speaking further

Carl Beekhuizen: speaking further on the um vls front um as was mentioned there's that uh there's a new pr on the hashtag repo um so uh although we were supposed to have finalized uh vls there have been some complaints as to the efficiency of this particular low power devices amongst a few other things um so there's a new pr i can link to it quickly um open it only affects the hash to base which is now called hash to fields

which is the first part of the um the hashing into the curve it should be a relatively minor change and the people seem very certain that this is the very final version um i think it's worthwhile making the change to try avoid a uh ketchup v2 so uh i i think provided until we launch mainnet i think it's advisable to try make changes to to follow the bls back um i do really think that this is the final one uh i think having spoken to the the authors

of of these specs

but uh and yeah

Danny Ryan: the next step in the process is there there's another kind of quarterly meeting

Carl Beekhuizen: um yes i would i would guess uh uh the yeah so nothing came up at the last quarter meeting there were no perceived issues but this was uh something else realized internally um the the quarterly meetings aren't enough when it's officially standardized it's more just to bring bring it out to the public as a point to get get feedback on all these these kinds of changes

so i guess maybe this is the results of the last meeting in some weird roundabout way but certainly was not the intention

yeah thanks um so

Mamy Ratsimbazafy: you were talking about the hash to curve being finalized but regarding the bls signature itself which depends on how to curve and is a separate spec how stable is it

Carl Beekhuizen: um to the extent that i know it is 100 stable so there is one minor caveat to that uh well two caveats i guess one is that there are still no test vectors so uh i do expect it to change to add test vectors uh i've as a part of some of the

bls pre-compile work i've been doing lately we've generated some some test vectors there so maybe we can we can leverage those the other thing which may change is if officially the spec or the draft expired or bls uh because there hasn't been there haven't been any changes to it for over a year now um so there would have to be i think a version bump i'm not exactly familiar with with the intricacies of versioning under um under these standards but there will be a version vlog but i don't expect any changes on that front

at least and then that one i can work from whatever then i'm on the horizon thank you

okay moving on uh prism oh hey guys so um yeah we have a bunch of updates so um we are working on this um slashes servers which is to slash double votes double test and surround and surrounding a test so the latest progress on that is that a vision node was able to detect uh was able to detect a several vote and then were able to include the slashing object in abroad so the next thing to verify is that the slashing actually happened and then the validator gets ejected so we're working on that i'm also working on a various day management service so where that we

store hot state aka post finalized state on a per epo boundary interval and then we basically do playback on that and then a code state which is before the finalized sharepoint state on on a per user define interval and the um such design was highly multivated by the uh by the uh lighthouse design so um so props to them for being the pioneer on that and um the and then the implementation is mostly done i'm just working on micro optimizations uh here's a few other text tests we're working on so we're working on dynamic

attestation subnet um subscription we're also working on better on contrarian blood fashion for sinking and then we also like thinking in the back of our head how to use less memory during um initial sinking and then we also updated the test away time from one third to basically right away when he sees the vlog and um in terms of bottleneck i would say our biggest bottleneck today is um basically we subscribe to all the subnet for the for the for the committee id so we have a tons of uh undergraduates on aggregated signature to verify um i just took a profile before this

code and then looks like 30 of our runtime which is verifying on aggregated signature so like danny said that's not sustainable so we're working um towards solving that yeah and that's my update thanks terence um and maybe age can speak to that a little bit i think he's looking he's also trying to tackle that hurdle right now okay um any comments for prism another just if yeah

if you're

subscribed to all the all the subnets um what what checks do you have for checking the attestations before re-propagating them across gossip sub

Terence Tsao: uh we basically implement what's in the spread today which i believe it does check this signature basically checking the signature is the it's it's the heaviest part so the debate is whether you should check the signature uh whether that you should check the signature before you republicate and i think we do check the signature today

which block do you use or which state should you use to check this

Terence Tsao: we use the target state i believe

sorry which one we use the target state which is the ipad boundary state

all right

Mamy Ratsimbazafy: for verifying signatures are you already using a rumi's implementation

Terence Tsao: um we're not using the latest one we're using the previous implementation i think he has updated to uh version 10 which were not incorporated

okay um never mind

Jacek Sieka: uh one more question sorry um out of curiosity do you cash i'm sorry i couldn't really hear you

[Music] i was curious whether your cache the target epoch states or any epoch states or do you always load them from db before doing the checking

Terence Tsao: um so we have a fru cache on top of the db for the state so um those cash gets hit pretty often ish given this is a target state and we use a lot so yes

so so so so so yeah we it is cash

Danny Ryan: anything else

okay

another moment uh g'day guys uh from sunny or not so sunny brisbane north of the night uh so we have um our uh uh basically a lib pdp from mothra a wrapper for that working.net uh integrated into our nether mind s2 beacon node and so we can actually gossip blocks um between a couple of local nodes so um we've got a thread of that working we still only have blocks no no attestations or anything yet and still on version like nine one of the spec or something uh but we but it's good to have um uh

uh to be able to use that mothra library and not have to as far as a quick uh leg up to get that started so um yep next up i think we're gonna i'm gonna try and uh update the version uh to 10.1 because i the change in things like getting rid of um uh signing route i think will make it easier to to finish off the the rest of the uh stuff like uh attestations cool any particular bottlenecks worth discussing uh we're probably here we're probably behind other people so i mean like

although i did look i'm not sure what like spec level other people are up to like i think the prism tested i was looking at still said it's 9.3 on the website but i don't know if that's correct so um yeah i took him from we're

Terence Tsao: still 9.3 on the test net but then like our our client actually runs 10.1 we just haven't updated

the number yet okay that's cool so yeah i'm going to probably try and go for 10.1 because it seems have some improvements over for the rest of the development but we've got um yeah it'll be good uh to try and

once i've got that in there trying to get it working with uh interrupt with one of the other clients i know there's some guys from tekku locally in brisbane so that's probably going to be my my target but i'm happy to talk to some other people and try and get some interrupt working cool thank you um lighthouse hey everyone um so i'll try and

make it relatively quick uh i guess first and foremost we've added uh two new developers for lighthouse so welcome to diva and adam i'm sure you guys will be hearing from them um very shortly in the near future

uh so the things we've done over the past two weeks we raised we raised a 4k kind of test net um validated test net for f denver um which turned out to be quite useful some developers and researchers to prototype with it's been running for about 93 000 slots and we kind of haven't touched it's just running smoothly we kind of just had it just as a as a kind of a test for the denver hackathon um so while steadf denver michael from our team uh met up with proto and implemented the merkle tree based storage system for validated field in the beacon state um it's shown some pretty significant reductions in tree hashing time but an increased um increase during rewards and penalties so we're still deciding whether to

adopt the approach or not um throughout the throughout the client uh we did a we did a project wide sweep of temporary heap allocations because we were getting um we're finding a whole heap of uh using a ridiculous amount of memory more than what we needed um so we've actually reduced our memory footprint by about half again so since the since the start of the month we're down to about quarter then what of what we were originally using um we're still using a two to four gigabyte uh gigabytes of ram for a beacon node on a 100k validator test net um but we still think we can probably get a little bit better than that um the ram the ram usage depends on how many validators are

using um the node's local api uh the reduction of heap allocations and memory usages also gave us a 30 uh improvement in block processing in time uh which is pretty good so that'll also help our syncing speeds um and we're in the process of refactoring our bls library so that at compile time you can choose to weather use either the milagro or the harumi implementations um we'll still kind of go through those to find out which is to actually benchmark which is which is faster

[Music] in terms of interoperability so

this is interoperability is very uh is is kind of one of our main focuses in the in the very near future

the bottlenecks of getting there is that we're uh pretty much in the process of upgrading lighthouse to what we're calling kind of version 0.2.0 um and this is going to have pretty much be feature complete for for mainnet launch so that means it'll include the attestation aggregation strategy noise and um and snappy compression so we pretty much have most of that implemented there's still a bit of code to go but we probably need to go into uh a fair amount of testing before we merge that to master but once we have that merged into master we will be ready to do interrupt with everybody we assume so um as soon as we get that merged down we're going to be

we'll have this we're going to start up like an interrupt test net which will be a long lasting test net that we hope other clients can join but we'll also try and join other clients test nets so the first thing is just kind of finishing off the testing of that um and i guess the last thing is that we've kicked off uh a process to build a kind of like a ui front end for our validator client and that's currently in like the research phase so uh we'll probably be updating everyone as that

kind of develops cheers cool major bottlenecks yeah so i guess yeah uh i mean we have actual performance bottlenecks so

this is the ram that

we've kind of been targeting um we i think we fixed and tracked down most of all of our deadlocks um in terms of actually just getting to an interrupt interrupt um test net and testing with other clients it's it's just a matter of finishing off the last bit of code and then thoroughly testing it internally before kind of releasing and testing because we don't really want to have a test and then realize oh we need to change something then restart the

test net so um pretty much that right and

Danny Ryan: you said that memory is scaling with the number of validators using the local api is that correct

uh yeah

Danny Ryan: so the number of like local validators that are signing

entities

attached to a beacon node yeah yeah so yeah i think we're

still tracking down why why that's the case while i'm still getting memory fragration across there okay that seems to be the case

okay and you but you also have nodes that have thousands or tens of thousands of validators or such to it uh yeah yeah i mean in in reality that's probably not gonna happen but we still wanna we have that problem yeah and

Danny Ryan: can you give us any uh details on your strategy to find validators of particular attestation subnets given

the e r

uh yeah so

as i was saying on that thread the original plan was just to um so what pretty much we when a validator kind of subscribes we know in advance when it needs to subscribe to a to a subnet um so we we we've given ourselves kind of like an epoch leeway so we know an epoch in advance when which subnet we kind of need to subscribe to so the initial plan is to um use this v5 and just kind of search for random peers and just try and and when we'll only connect to ones that have um the subnet in the in our field but failing that if that's too slow or if that doesn't give us results it'll be

dependent on the number of nodes on the network that are validators versus the number of nodes just sitting there that aren't subscribed to any of the any of the subnets um so the other solution which is what alex suggested is to just crawl the dhd which isn't too difficult but it'll be a different kind of search where we kind of just ask all the all the peers um all the other peers that they know about that have uh this particular field in an enr and if you specify return me at least three of them then the query hopefully shouldn't take too long definitely not at least an epoch i imagine so that that's the second strategy if we need it

right

Jacek Sieka: have you thought about the reorg happening right then

kind of like uh yeah so

if ryog's happen uh the validated client will detect it because it kind of polls all the time for its duties and so it will resend a subscription um so we have like a a service that's looking after all these subscriptions on the beacon node so it will update and realize that it it'll change which which subnets it needs to connect to um so if a re-log happens it'll kind of readjust itself we may have less time than an epoch uh in some circumstances like if a validator just connects and needs to you know uh perform an attestation on the next slot well in those circumstances obviously not gonna have enough time to track down peers but in a long running scenario we we in principle should

Danny Ryan: something also to consider is that the agitation subnet subscriptions in enrs are relatively stable on the order of the day um and so there's also the chance to kind of like pre-walk the dhc and have uh information that you think is correct and is very likely correct locked and loaded

uh so when you say their order of a day um that's that's the the random subscriptions you're talking about right

correct and

Danny Ryan: those are the only ones that actually go into the enr okay yeah sure i believe what is specified doesn't say if you're just joining for that epoch worth of

duties that you i don't think you put it

into vnr um i believe

yeah it will be shortly subscribed yes that makes sense so the idea is that as long as the the you know whatever the the constant is the number of random subnets he's supposed to connect to should cover all the subnets

Danny Ryan: should cover all the subnets what do you mean

yeah i mean it'll be statistical based on the number of peers like if you have as long as as long as there's at least a thousand validators then it shouldn't be too difficult to find those thousand value days across any subnet that you need but i guess we'll find that in practice

correct okay um any jim did you have a question

or thought for my house i saw you i made earlier and do you mean about like finding like the genesis block efficiency uh no i just i saw you on mute towards the end of when age was speaking it's wonderful i was curious like which like uh spec version you guys are like gonna go for for your like that's not uh i think we'll

Adrian Manning: be going for 10.1 cool thank you another another quick thing is that we've we've implemented noise and we're testing that so um if nimbus nimbus said they needed a testing partner to check out their noise then we were happy to that'd be interesting to

interrupt with great okay uh lodestar

hello uh so

Cayman Nava: past few weeks let's see um so we've upgraded our bls implementation to ten point x release 10.1 i guess um and we've cut a new release of that so based on harumi's implementation compiled to wasm everything else in our repo is still on a 0.9 level we we have some fork choice things that we're still upgrading and our network i'd say is probably our bottleneck at this point so we're uh adding so we have a noise implementation that we're

interopping with go at the moment i don't know exactly what the status is so i don't want to offer us up as a testing partner but that's in progress and we have a pr open for snappy compression and we're going to begin working again on disk v5 we're about halfway through and we had stopped work for a while and now we're gonna get back to that um some other things we merged in uh this new ssc implementation that we had been working on for a while and just merging it in no changes kind of sped up our state transition by

roughly 10 to 100 x and then just lightly memoizing a few uh functions spread it up another 10 to 100. and we'll probably stop there for now because i don't we don't have like the best uh data to benchmark against um but i think once we start really syncing a bunch of blocks we'll we'll have something we can test against and take it a little further um we're also going to be working on fixing up our state management similarly to how described a few people earlier we're going to store

we're going to kind of checkpoint historical states and then have a more rich history of the recent states but just kept in memory and share it sharing a lot of data between them

oh yeah

Danno Ferrin: cool any particular bottleneck you want to discuss

Cayman Nava: um maybe disk v5 but [Music] started some conversations and a few other channels and i think i think we'll get that sorted

Danno Ferrin: great congrats on the sse and state transition

boosts oh

Cayman Nava: thanks

Danno Ferrin: okay um other client updates or items

great research updates txrx want to go

Joseph Delong: sure okay so yeah uh we were at east denver um and we

worked with ethicia we made a um an ee it's called simply kind of um and uh that was just kind of like a rudimentary execution environment to see kind of like what some of the components are um and we're using that to kind of like inform some research um uh some our team also is helping quilt with uh ease and we made some updates to that just last week

um and ease

if you're unfamiliar is um a truffle like um interface to help you build ees it's still very in them it's still in a pretty rudimentary place

but it's gonna be a fantastic tool going forward um we have two pending write-ups right now um one from mikhail uh around a safety uh of um and east one e2 bridge each one is two um finality gadget um and that should be out if it's not out today if it's not already out it should be out today um and another write-up on uh disk v5 from alex um is imminent yeah we're just kind of making research progress right now

oh we did e222 yeah that was great

that's it for me

Danny Ryan: thank you um proto has put together a draft phase 2 spec if you want to take a look at that inspects your post pr open um other research items you want to go over

Ansgar Dietrichs: uh i can give a summary for the football team sure uh so we'll will is currently on

the plane um as the sun's gone um yeah we basically spent last week at uh sbc um and had um many productive discussions there and synced up with the other research teams uh we uh struggled before but before sbc we published the eath research post on on our vision for phase two um if you guys want to have a look on that that's basically all of our thoughts around phase two um in our opinion there are no real like blockers uh left for phase two it's still a huge design space but uh the approach that we plan on on taking is to just like basically um uh take like the minimal implementation minimal uh phase two spec implementation

that we see and uh that's basically also what proto uh has been started um writing the specs uh on they came from the same discussions around that there and we want to shift our focus uh for now on like implementing that and then with a target of having like a minimal like mvp version of a phase two implementation um done so that we can then uh iterate on that and compare it with like other more involved research that's still to be done there but but yeah our next few months will be like mostly focused on getting this minimal face to implement it

and then a few other small updates um sam and i have been looking into this whole question around dynamics that access aesthetic state access some of you might have heard of that that's this dsasa topic account internal preference is the to likely go with ssa for phase two um we have been looking a little bit into feasibility there um i've i've been specifically looking at uh existing uh popular et1 projects to see like how easily uh those like similar use cases could be um implemented in a like ssa um phase two world uh that's looking great so far um and sam has been working on for the last few

weeks uh last two weeks specifically like on a a so-called like taint analysis tool for for um solidity integration so so the idea here is to to have have a tool that it's basically doing like an optimization pass over yule and it's checking um contracts for dsa so if we were to go with with like purely ssa then we had we would have need like um developer tooling around right um detecting dsa and basically so that would just like as any syntax check it would just like highlight code parts of your code that would that use dsa patterns so you can correct that or overwrite the this check if you if you really know what you're doing um that's really looking great so far as well here's a write-up on each research

on that and that's basically done as a mvp for now um and and i i think we'll have like a more comprehensive write-up on the whole ssa dsa topic as soon as we have a quick clear picture on all of the remaining questions there and then as a last update from our sides um i mean as just already said matt and johnny had like a new release of the east tool so that's the idea there is like that it's like core libraries for ee development and we hope that that will be really helpful for prototyping going forward so we don't really have to like implement all those things state account structure every single time we want to prototype a new ee

um if you want to see like a summary there you can johnny post one on twitter there and i

believe that's all from our side for now awesome great work so having

Carl Beekhuizen: having had some uh well quite a few discussions about the whole ssd say spc um it it's a very interesting change and i think it it's definitely the right move um and simplifies a lot of the the harder problems um or at least there's it's easier to come up with a solution uh but it does mean changing the standard pattern um and this comes up with the uh uh the the tainting and whatever oscar was

talking to but uh i'd just like to encourage people to to stay up to date with us because i think it's important that we get as many items as possible on whether this is a feasible direction to go on uh to go towards uh for for how we do state in the future um from what we discussed we couldn't see any major design patterns that are that we prevent by switching over to ssa um and certainly it's worth it for the because the simplifications that can be made um but yeah i just would like to advise people to just to follow up to follow what's happening here because i think it's an interesting design space and it's important to fully understand the decisions we're making

thanks girl other research updates

Danny Ryan: okay um we will have a networking call on wednesday the week from yesterday i pushed that sorry about that um but are there any pressing networking guidance we can bring up today

i can just briefly mention uh the pr

pushed for segregating uh it was aggregating at the station topics not really all broadcast topics by work version it's a tiny little patch that allows running um multiple networks on so have a look at that thank you okay spec discussion thoughts comments

concerns issues great closing comments anything who's gonna

Joseph Delong: be in paris are we gonna are we gonna have a get-together for

e2 hello uh shower is here

um i'm thinking about if well we can have something on the march march 6 and there's a potential uh port on the [Music] is to discord china the general channel which i'm um trying to check uh the people's opinion of having zanzi on the sixth and if you are interested in and please dm dme or just uh can put if some signal on the is to discord and

i know that uh the golly testnating they might want to have uh organizing some events so the discussion is also on discord yeah and there's the ecc channel in the discord if you want to coordinate me okay anything else if london so the rest is hackathon in london uh this weekend

and i invite everyone who is around the co-work or just talk about you can do i'll see you there dude okay anything else great keep up the good work uh we'll do this call in two weeks we do the

networking call next week um and i got a lot of spec work to do so i'm gonna get to it talk to y'all soon thanks everyone thanks guys thanks [Music] so

[Music] [Music] so [Music] you

[Music] so

so [Music] [Music] so [Music]

[Music] [Music]

[Music] you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.