All Core Devs - Consensus #33

Transcript

[Music] [Music]

so [Music] so

okay welcome everybody um the stream should be transferring over people of youtube let me know when you can hear me here's the agenda generally business as usual so we'll start with testing release updates ongoing audit from lease authority uh the i believe the intention is to release an initial report uh kind of for internal review it might be tomorrow it might be monday um from my understanding i haven't found anything crazy

uh but some recommendations on networking spec and some other little things um so we'll share that soon uh the intention from there is to [Music] discuss it figure out what needs to be changed with respect to the audit and get out of release as soon as possible this release will also include a number of uh minor things there's kind of some ongoing uh work on some of the subtleties in the networking spec there's a couple prs up right now under review so that stuff will go on as well the changes uh to the spec are kind of moving

outward which is good uh definitely much more to the networking spec than to the uh actual state transition function that is good um i am looking into the uh four choice tests likely what we're going to do is take some expand upon some initial work done by the harmony team and do integration tests i did want to ask y'all if there is value in doing kind of some some per function knit tests

i know that you're using much more sophisticated algorithms than the uh the spec provides now and i i wonder if there is any value to these unit tests and whether you have like kind of the interface to actually be able to test them so specifically like testing on attestation testing on block testing that kind of stuff and um kind of the internal results of that is there i think even if someone has a complex implementation like a proto array we always have the reference implementation to compare

the fancy one with a reference one so we can use uh you we can test at least the reference one against uh your test vectors is that true across the board um yeah so the proto-array the version of photo array doesn't um work for the present f2 as we have it was like for a previous previous version before all the bounce attack stuff um i'd be interested i would definitely be interested to test the stuff about um you know like should update genesis uh she should update the justified state i think that stuff is like sufficiently complex especially if you try to start to um

to optimize it to avoid reading states from the disk it'd be nice to test that right um but uh i think that we'll probably find that most clients don't actually do block processing inside their fork choice like it does in the spec um so i think like on one hand it'd be really nice to be able to test all that should should you know like should update the justified state but it may also be annoying if there's tests in there that are like oh here's an invalid block given to fork choice does it does it reject it or not because yeah we probably have to just skip all of those gotcha okay um good info

i will digest that thank you um any other comments on unit tests and that being feasible or worthwhile in the context of your client uh paul do you mind explaining like if you don't run if you don't like run like importing a block inside like the fork choice how do you like how do you implement like the fork choice um so we ours just works on the assumption that any block provided to our fork choice function has already run through per block processing and is valid oh thank you that makes sense yeah no worries maybe i had a few cents yeah please

yeah just to say that this integrational format of tests is useful for any kind of optimized or sophisticated implementation of the choice so it should work whatever you use uh as long as this implementation supports vultures interface uh which is like which is specified yeah yeah so i believe by default everyone should be able to handle integration tests um but the it's more weather because i can i can kind of very easily with a grain of salt uh turn the tests and the price back the unit tests

into unit tests for everyone else um but i just don't know i wanted to get a handle on whether that's valuable um okay so i'll i'm digging into that uh and i hope to provide you with something next week and a half um i guess i guess the tricky part sorry sorry i guess the tricky part would be to um like with with those tests that involve like actually having like a full chain of blocks with with all these attestations instead of like smaller unit tests just be i guess get tricky to actually come up with valid scenarios like you need to get most all the validators to you know um to test and and and swap things and

stuff like that yeah i guess that's that's the only problem with that one i mean the main problem with the integration tests why we've avoided them is they're very we've had trouble coming with a succinct way to write them um and so they end up being kind of like pretty ad hoc and verbose um so but you know if we can even get out small but uh representative scenarios and integration tests i think that would get us a long way oh yeah we're in a change we're at a space where an infinite improvement is possible so that's a good space to um paul also wrote pretty comprehensive um

end-to-end ish unfortunate test which um us prism has been um kind of leveraged the same style um i thought that was really useful i'm not sure if any other team has also looked into that yet paul what are the format of those yeah thank you sir i appreciate it um they uh so i've looked at my ones obviously and i've also looked at mikhail's ones um sorry if i didn't i'm just on the michael and other people involved um uh and the ones that i have are very much like they're very simple as in like here's a bunch of hashes here's some photos on the hashes and then now where is the head so they

skip a lot of that like they don't actually have like full blocks and they don't go through all of this sort of stuff um so they're they're like on that side where they're not um they don't they wouldn't work at all with the current like spec implementation but they are actually really easy to just generate like pathological scenarios where things are weird yeah did you have another question in there i think i got distracted uh i just was wondering what they what what they look like um i'll take a look at those two thanks and uh one more thing to add is that our uh original intention was like i used uh integration tests for

common scenarios and for some um kind of complex scenarios but if if there is something some checks that are really difficult to implement in integration tests then fall back to unit tests for example a good example of unit testing is like updating of justified best justified box checkpoints that's great thanks um proto might join us at the end of this call i think he's traveling right now but he had a couple of notes he's working on a testing tool

called eth2 lurk sampling rpc and package network components for use uh looking to wrap it into a ripple for people to interact and test clients he's also working on the package spec pr which is going to allow for people to easily run like pip install pi spec which would be useful to you know people looking to experiment and run stuff against the high spec um protocols you can talk a little bit more about his e3 tool but you can check out progress in the repo i just shared other

testing release updates great client updates let's start with artemis uh i gotta remind danny that it's actually teco uh thank you sorry taku taku i got it this is jem uh from techo producer named artemis so uh currently melvis is continuing work on getting sync up and running we started testing against prism sapphire tesla and we're working through incomparabilities and other issues as they come up

anton is working on our version of protos backing binary miracle tree to improve our hashing performance uh thanks to ben our 10.1 bls implementation is ready to go adrian is working on general stability and stability of the code base and having furniture and work on following each one chain three deposits at a distance behind so that's where we're at cool um any what's what was the first issue you ran into trying to connect to the prism test set uh i think the first issue although like if the metadata is online she'll probably be better at answering it i think the first issue was that like we had a different understanding of the

beacon blocks by range request uh with prism but i think we already like adapted to what they have like uh like what their unders what their understanding was and i think that was just like getting blocks up to like uh getting blocks up to like the specified slot versus like uh the counting skip slots or not was like issue prism was counting them and like we were not counting them and so now we also count them cool great glad to hear you're all working on that thank you jim uh a little while we agree block which turned out to be our fault

but uh um it was uh took a while to debug but we got there yeah debugging when your hashes adrian when you're counting yeah when you're counting the skip slots what do you mean by that so uh yeah by that i mean like let's say like we started block one and we want like a count of like five blocks and um and like for example like for the fourth block is not there uh instead of like finishing at six we is like uh again like finish finish at like five we like uh we think of like this like skip slot four as like

um a block like we would have returned the block if that was that if it was there but no if it was not there like we don't care we don't go up until six we again like finish up five right so it's add a start slot give me all the blocks from start slot to count slot or start slot plus count rather than give me this many count number of bucks yeah well good thank you adrian like i'm curious about your understanding as well is that like lighthouse implementation as well just curious yeah that's what we do as well perfect okay i'm curious so if i understand it right

the effect that you were seeing was basically that you were getting more blocks than you asked for right you you yeah fewer blocks yeah so for example the prism network doesn't have any blocks until 200 slot 217. so if we ask for 100 blocks starting from genesis we were getting nothing and we'd expected 100 so yeah working that through yeah that's a that's a fun edge case to start the network with uh well because i think the spec actually says that let's say there are no blocks in the

range 0 to 100 and you ask for 0 to 100 you should get zero blocks yeah there's an exact there's an example in this bank that points that out right yeah yeah i think within it okay cool and then what do you do when the other guy doesn't send you the blocks you expected like do you how do you handle that i i think that's a question for meredith i don't think she's uh he's here so uh i'll be fair if that's okay yeah yep okay cool because we've had some uh uncertainties around that how that should be handled safely as well so i'm just curious to hear how you deal with

it like somebody sends you you know if you were more boxed than you asked for yeah let's uh catch up offline yeah okay how about nimbus hi so as we said last time the world team is in brussels the first thing we did got impressive reception by the community we were running nimbus on our own phones as the testnet that we have so at least the truth that beacon chain works on on mobile and not just raspberry pi otherwise since we're

all there we decided on a new way to communicate all milestones and how we work on the numbers so now we have public milestones with a various project that are dispatched into to everyone on the core nimby concha inside we updated our ssd parser to better handle the malformatted ssc and we started about a month ago a sink refactoring and it's uh currently 90 done on the testing side um we are running out uh

10.1 spec bugs we also fixed the fuzzing bag that was highlighted by the become first team and we are also re-enabling tests that we disabled during the 10-point 10.x transitions and that we forgot to re-enable and otherwise we are currently hiring so we hired a new nimbus dev we are still looking for junior developers and the tech writer and that's all great thank you trinity and the the

the phone demo was very cool very exciting uh trinity everyone uh generally just working towards version 10 1 of the spec we merged in the work to pull out our client as a separate binary uh some more work on the beacon node developer client apis progress on disk b5 more progress on our ethernet integration a big one is we finally merged our port of pilot b2p to trio which again is working towards concurrency stability uh which is kind of a python detail and yeah just general spec updates to version 10 1 and that's pretty much it

great thank you let's start hey uh so we are still uh integrating our new ssc implementation into loadstar turns out we don't have all of the apis that we that we need to fully integrate it we need to be able to generate some proofs if we want to use it for our deposit data um we've all found some like strange we found some loose ends in the typescript types i guess we're using some apis that not many people use so we're getting some pushing some of that

upstream we started passing the 0.9.4 spec tests but we still have some work to do to update our fork choice uh but there's no test for that so um not not yet i guess um we've done some research into updating our bls implementation i guess so we're using harumi's library i think he just put out a release that maybe brings him in line with the new spec so we can take a look at that in the next few days and we've been upgrading our lip gtp implementation

to this new async version and we're taking the time to like go through and add all the typescript typings that aren't there because it's written in javascript and we're hoping to push a lot of that upstream as well cool so you all found you said you found bugs in typescript uh just i guess loose types um things aren't actually typed or like things in the node api that aren't there things in the javascript standard that aren't actually typed out cool thank you yeah um i've been following uh the progress on harumi it seems like

he's i guess if he made a release maybe he's there but i know he's at least getting very close and kind of passing tests and things so uh it's exciting i know a number of teams are waiting on that one uh he published on twitter that it's ready great fantastic thanks thanks kevin um let's do prism oh hey guys terence here um just a few test net related updates so we performed the first volunteer exit for the test net the actual object was successfully going through the innovation block so that's

pretty cool to see and um we do have validators slashing protection it's not running with a validator it's just a db so we're working towards including validator slashing object in the block as well and then a bunch of few are micro optimizations so we're using a new uh costume state structure so since golen doesn't have immutability over a fully copy of the object so for state copies we share references with the parent object instead of copy or read so that's a lot um less easy on the memory side of things and then a little bit just more um testing on the array for choice um it's working really

great so thanks to proto and paul on that we're getting that to be more stable on the run time observing blocks and then uh mostly just um just mostly just decreasing the ram and cpu usage and then i'm working on increasing listing times that's it thanks thanks terence um lighthouse yup thanks terence um the so our rfp submission deadline to the ui has passed uh and we're selecting a winning candidate this week we had several applicants and we of course appreciate their efforts in applying uh

we are in the final stages of hiring some additional developers thanks to everyone that applied for that we had more than 20 applicants which was great to see lots of interest um we re-architected some of our concurrency logs to get some better stability and to be a little bit less invasive or heavy-handed we did some more work on the network upgrade adrian did so by the next call we expect to have upgrade our network stack to include noise snappy compression and the native attestation medication strategy um we're passing the version 10.1 tests i'm hoping to merge into master this week just dealing with some kind of wider code based things um we're in the

process of starting 100k validated test net um when we're optimizing that to make sure it can comfortably run on lower spec devices like kind of cheaper aws machines um we're running large we found that running large valid accounts has been really good for uncovering efficiencies that are hidden when we're using smaller states as such we're in the process of rewriting our attestation processing and looking to get orders of magnitude improvement on that and we had a pretty fun troubleshooting session trying to deal with some higher ram usage on large valued accounts and we found that we were experiencing memory fragmentation because our tree hash cache was made up of lots of little small heap allocations um so they were kind of

when you had multiple of them they're kind of interleaving across memory pages and resolving and not getting freed that's because rust doesn't have a compacting garbage collector um so we built uh an abstraction to allow storing these multiple smaller lists in just one big allocation this this worked well uh reduced our memory usage by more than half didn't really affect performance but then we managed to move some allocations from the heap onto the stack and managed to shave 70 off our um 100k state um hashing times which is really good that's it from us cool thanks

um is there anyone from nether mind here okay i don't think so um and i believe that is everyone correct great um research updates start with italic um research updates uh from myself uh so i've been kind of going and going off into accord into a corner and thinking about like kind of

longer term problems around like 51 attack detection and 51 attack recovery um and i think there were a couple of kind of insights that we had um that we had in terms of kind of how to move the protocol into in a direction more more favorable to these kinds of things um and the the first kind of big suggestion that i had was basically to come up with a way to be able to include beacon uh beacon chain uncle blocks and so far kind of no for no further con concrete suggest um suggestions from

that i mean except just that that that this is something that and if if we won't like if we want to do it it's worth trying to start i'm starting to think about earlier um and the specific way in which we would handle those things also depends a lot on kind of some like specific choices in terms of how we end up doing things like things like execute execution environments and data inclusion for example um the next thing i'm trying to think through was basically if there's backwards uh compatible ways to introduce ways to kind of detect edge

cases so basically where an attacker tries to sensor blocks for just long enough that they get the network thinks they're the that they're censoring and the other part of the uh of the network doesn't take because they're censoring and there's some uh some progress on that on that front um i guess um one kind of decision points that i can realizing that we'll have at some point is basically figuring out exactly how we would end up uh treat uh treating successful 51 attacks so this would basically be

cases where some fraudulent block with bad ex with bad execution or where potentially bad data gets and uh gets included and then like would the inside would the chain have to be reverted or with the support treated in some other way um basically but that's still kind of a long a longer term concern at this point um yeah so short term amount of planning to probably do when you do any research at some point post at some point of uh just kind of the basic the basic techniques for uh

basically another another round of 51 attack deduction and prevention that's a bit more kind of abstraction longer term cool thank you um other research updates yeah i can do uh quote great so yeah yeah so we have actually a lot a few things um so we are five so we've been working on an eth2 general book um that makes a lot of the topics accessible and works as an on-ramp into

phase one and phase two discussions uh we've been working on that with kelvin uh kellen victor and we are five chapters into that book right now um so there's there's an introduction an eth one overview covers pow evm scaling blockchain basics we have an e2 overview which goes into pos speak and change shards ees the rollout phases then we have a proof of state chapter uh it goes into core concepts basic operations for choice long-range attacks cast breath of g week subjectivity then we have the building blocks which is bls randolph sse committee's deposit contract shuffling and then uh beacon chain

chapter which starts going into validator lifecycle duties structure all of that and so um this has been uh quilt has been giving feedback and kelvin's been iterating pretty quickly ben edgington has also been involved so ben's i know separately been doing a work on annotating the spec um and he's also helping edit um edit some of this and review it as well and given a lot of good feedback and so uh this is exciting and from from like my perspective this is in general just a part of a master plan and to transition people into etooling and contract tooling once we're ready um and a lot of this book should guide the narrative and make a lot of eth2 more accessible and it's pretty

comprehensive and so pretty excited i think we're generally shooting for the initial release um around two to three months from now and uh and then it would be uh actively iterated on to where we will you know go ahead and then add phase one into book phase two um and then further pieces so um as this becomes more complete we'll start getting feedback from um from more people and uh making this more wide open um so just fyi that's that's been in that's been in the works um one thing that's been interesting to us is so we've realized that there are some i guess higher level questions in phase two

that we generally need to situate um so you've been brainstorming uh with e-wasm uh it's in the e32 research team on some of these questions um and so over the last week we've mainly been working on mario's writing things up showing how everything end-to-end state providers to state access ee communication uh e upgrade great ability everything how they kind of overlap to try and uh produce you know general plan a and plan b um and so we can all kind of make a decision on final scope and direction um so that's that's been a pretty big effort um one thing this this is super interesting so um the original so the state provider post that and scar and sam

did originally went deep on this discussion around dynamic state access versus static state access and one of the things that you know so dynamic state access is very much a used pattern in eth1 and so one of the things in that post is it kind of took a maybe a skeptical view on using uh on switching over to static state access and eth2 um but we're actually realizing that maybe maybe we took too skeptical of a view on that and so we're diving into an exploration here and in fact have realized how moving towards a static state access

model can bring a lot of benefits so one is we could get synchronous communication with between ees it simplifies the state provider network drastically and a lot of things that are interesting like it actually works more it seems to work more towards the kind of ownership borrowing model um from uh that that you would like kind of see in something like uh patterns of rust as an example and so diving into this analysis um the first thing we've done is sam wilson has extended the solidity compiler into yule um so we've added taint analysis so we're actually able to run uh taint analysis on current contracts in ease one and we're able to see um which contracts are using dynamic state access

this is pretty cool this is working uh we have a branch in progress it needs to be expanded there's some cases that it's not catching um and so the the point of this is twofold one so we can kind of see the different patterns that are existing each one and evaluate those the other is if we do push towards a static state axis model then ultimately we need to provide tooling for developers if they're writing a contract and solidity for example or viper that warns them if they're using dynamic state patterns um and so this is in in order to like do this realistically uh this taint analysis we we would actually need to add to the tooling and so this is pretty cool so we're showing a lot of promise here

uh onscar has been analyzing contracts by hand so he started with uniswap and so um he's uh kind of put the scenario of what would uniswap look like if we move that to a static state access model um and it seems like we're able to accomplish that with my inner some minor changes um so that's this is just the beginning um we're also looking at a on-chain cue based deck some of the patterns around that and then we'll also want to start looking at other patterns that um of other major contracts in each one right now um so that's this is in progress and i think this will be really interesting we're excited to kind of share um results around that um on the other side of things

um so we've been talking in these calls about suite of tools around e development simulating shards um so this continues to move forward um greg has been working on the simulator and he's been updating internals to match the phase one spec that has been in progress um and so now he's building an sdk around the actual simulation server that's the next step and so when we say simulation this is kind of like the ganache of eth2 is what we think of this as um and then uh there's work around a repo called ease uh which we would consider kind of like the truffle um and so again if you look at our quilt repos you can see these things in progress um right now um we've started uh gotten it to where um there's

a library to create common e project template so this includes like the e-source the wrapper stubs and test stubs and so the goal is that this is like a unified workflow for developing and then deploying it to the simulator and then running the tests on it um so part of this suite is plugging in different modules and libraries these are different like uh libraries that that would pre-exist in ee you might want to use you know particular tri very proof back end um or for um or different memory back ends so matt continues to work on that he's uh and creating generic interfaces to create these multiple proofs on the fly so that's been moving forward quite well um yeah so these are all the updates

from quilt we've been staying uh productive and trying to stay heads down uh if you haven't heard as much from us sweet that's a lot going on appreciate all the updates um any comment or question on that and there's a lot there cool really really excited about the book planned here there's progress remake thank you will um other other updates other research updates um i'll do one for txrx okay so um uh

we're working on a construction for a clock sync protocol that is kind of compatible with some of the beacon chain requirements and um we're looking at two approaches uh hardening the protocol and that's kind of like an investigation for a robust clock calibration and um the second one is a kind of a relaxed adversarial model and so we're still kind of like um uh working on some requirements and documenting those um uh we're helping quilt with some ee tooling uh and so we kind of put some

resources towards working on ease with them uh and we're working on paper for a one-way bridge and our finger cuffs two-way bridge and that's going to be probably out in a week pending review and cross-shard transaction simulation in python is still ongoing um and that covers it for us cool and a reminder that uh 222 is happening on what day february 22nd 222. uh but yeah so that that's that's happening

um can i can i just say as an aside there's a slot for eth2 that's opened up at consensus 2020 puja has gotten that for us um and so if there are people interesting in participating like consensus not with the y with the you the conference that they have in new york in may and so they want to kind of like get more technical um anyway so i put some stuff in the uh uh sharding getter if you're interested thanks joseph um other research updates we'll move on just a quick note so

proto started this kind of write-up about client implementation that i'm trying to help him with this so i have been trying to fill up some of the more general content on different topics this week i was working on the bootstrapping for networking and leave perfect here so yeah we expect to have our first complete draft by the time of its barcelona which is in the middle of may and so yeah i tried to provide them because it's easier to uh continue to help contributing uh when there is already some kind of uh

initial test and starting from scratch so uh yeah i just want to invite all the clients developers to uh to contribute to the write-up you can find the link in the education channel in the discord and i will probably read also thank you yeah thanks lou um awesome effort and yeah so the the education channel is new um seems like people are discussing this kind of client education doc but in general um if people want to chat about any of the other um general education efforts it's a good place to chat great

shall we move on um moving on network stuff we did have a network call um about a week ago there are some limited notes up from that uh there were a couple of pr's that have come derivative of that and in general in the networking um there's kind of continued refinement of network spec some added conditions to validation conditions to gossip subchannels

to reduce some of the dos vectors and i do expect a few things to come out the next few days from the lease authority audit given when that lease authority audit will be released i think we'll do a call not next week but the following to dig deeper into um any pending um issues anything else that we want to kind of knock out before some final release before the next release from uh audits and ongoing things um are there so we will have a lot of time talk during that call as usual there's a lot of pr's

to also discuss some some ongoing things but since we're all here are there any um networking related items that people want to discuss today um this can also be uh general questions i know some people are working through sync and other items the first time like we discussed blocked by range request any uh any questions people have about the spec any um anything like that because they're all kind of in a different range

on where they are tackling that so there's some good knowledge to share there's currently uh protos made at pr for snappy compression which might be worth having a discussion about i have not reviewed that yet but it has to do with um essentially which length we are prefect prefixing uh which kind of dictates how we might stream either the compressed or stream kind of uncompressing the decompress is that what's going on in each yeah that's pretty much it um so if people have

the compression kind of already set up it's it'll be interesting to have a look at the vr and put your two cents in but yeah fundamentally it's it's pretty much deciding which kind of uh snappy um whether we're using the frame or just block compression and if we're using the frame compression we might have to do a modification in there like the rpc header which is pretty much what the er is about um but yeah i guess just have a look at it if you haven't seen this before thanks dude and then any compression ratio statistics uh there's no statistics i don't actually have any districts at the

moment but i think uh prisms are using it uh if i'm not mistaken um i also don't have an assist statistic on hand so maybe i can go back and take a look and then i'll share it with you guys jose are you asking if there's a a better compression given what we do blocks or frames or is that just you're just curious about snappy compression in general i'm curious how well our data compresses with that uh sniping given that it's a lot of hashes and stuff like whether like if it if it's if it's two percent or five percent one kid must

yeah there's also a lot of zeros there's a lot of viewing 64's that are um we're definitely not using all those ranges uh on the um especially the validator extreme okay um network questions comments thoughts before we move on uh yeah okay one more thing is that uh limp p to p have specified the noise protocol um so if anyone started looking into noise uh pretty much the the the one dependent handshake that we need is the xx

handshake um yeah just as an fyi for people looking into implementing noise right and you've added a pr to make that explicit um right pretty much it's just a link to the bit of specs and just explicitly what we have to implement if you haven't already implemented it great okay um we will dig deeper into networking in about two weeks time on that call i'll post that soon thank you uh general spec discussion actually uh tomas joined tomas you want to give us an update on another month i have really bad connection here we'll

see if you can hear um i'm reviewing the document that you just updated with the list so um we didn't move that much forward but we we have many of the things that you are discussing from other work we've done so we you have all the snappy compression this is that we started networking uh we have vls but uh haven't updated yet for the latest uh spec of dls uh we started some initial work on discovery five but i think only uh next week or next two weeks we'll start to look uh further at updating the spec to the zero 10 um and then i hope will be i mean the plan for now is probably end of february or maybe march to have s-net and then start to think about

connecting to the multi-client test nets yeah that's from me glad to hear the progress thanks um okay there's a the next section is flag for just general spec discussion um this can also extend into general test discussion just things that have come up that you want to discuss um it i know prism's seen this a bunch on their test net and it came up in the ama yesterday it's kind of a not great uh features

if you miss your first uh attestation your pre-first epoch you um your hysteresis drops you down your effective balance down uh substantially so you're kind of like spend a lot of time working your way back up um there's an issue open for discussion there very likely will make a modification so that it's um not quite so punishing if you mess up the beginning um so that's that's coming um other things i want to talk about today cool i know

everyone's free heads down it's a lot of work to do um okay open discussion closing remarks um a lot of us are gonna be in colorado next week uh for east denver oh shall we hang out uh and then following that a lot of stanford blockchain conference stuff it's a lot of good stuff going on in spring um comments thoughts anything else is there like a group related to the uh denver there is a chat in uh we have a conferences chat section with a few conferences in the discord now uh there's ethember svc and hcc

um so we can use that for just general discussion um we should certainly hang out grab a bite um i'll try to i know i got a tally there's like a handful of people who's showing up but i'll pop in there and um see if we can order something cool thank you anything else okay nothing else for me keep up the good work see a lot of y'all

in person soon and uh talk to you later take care everyone thank you [Music] [Music]

[Music] [Music]

so [Music] so [Music] [Music]

you