All Core Devs - Consensus #98

Transcript

foreign [Music] [Music] foreign [Music] [Applause]

[Music] foreign [Music]

Danny Ryan: okay we should be live

great sorry about the delay everyone I've had a little bit of audio issues but welcome to consensus layer call number 98. this is issue 660 on the ethereum slash PM repo I think the most oh I have I have to realize um so capile import for four are the things under construction uh primarily under con discussion today and um we have a few issues that will tackle metacris you wanted to give us an Mev boost update and also have to leave early so why don't we start there

Chris Hager: yeah sounds good I've tried to keep it short and only on

the most important updates that was the release of math boost 140 which has a bunch of minor improvements and the most notable feature is it allows setting a minimum beat value there is more details in the release notes Let Me paste the link to the updates in the chat here there's an upcoming post about implications and uh potential impact of setting various values otherwise there's a proposal and ongoing progress on replacing the types of nav boost with those from attestant also related to the upcoming changes for capella and EAP foreign which have a

bunch of payload changes and we need to plan these in and rather than duplicating the the work with types in multiple repositories it seems preferable to use their test and once foreign moving to the relay there was a vulnerability with incomplete block Builder submission validations that led to incorrect timestamps or pref rental values being delivered to CL clients the CI clients didn't like them and fell back to local block production I'm posting the full post modem here in the chat

so that's resolved it's anyone using math boost really use version 014 please it has all these Solutions yeah assignment here this uses the ticket rental Beacon API endpoint that is not yet in a text Beacon API documentation and not all bigger nodes have that implemented so my ask is consensus teams please implement this endpoint that would be usually helpful

[Music] um um one second

Alex Stokes: it's in the beginning apis yeah it's

just not uh like an official release yet

okay

Chris Hager: but here's the link it's only in the deaf deaf Beacon API and I think only Techo has this implemented yet and prism has the merge PR but it's not yet in a release I'm not sure about the other clients got it there is Big thanks to Justin traglia there is the relay it flies back since now in the same format as the other specs in the open API format inside Repository we see another relay really or dot WTF gaining a little bit of traction

and they slowly ramp up their deliver payloads about the Builder ecosystem there's a screenshots in the math boost status updates notes that I posted which shows that the leading Builder right now is Builder Ox 69 who delivers about 2 000 blocks in 24 hours followed by the flashbots builders with about 1 200 blocks for 24 hours followed by blocks route Weaver build and then a few others there is a website really scanned that just shows the the 24-hour statistics on an ongoing basis

and lastly there were a bunch of flashbots really updates and we also open sourced the priority load balancer that may be useful for anyone running the math boost really which allows distribution of the block validations across a number of validation nodes with a high and low priority queuing okay I think that's like a quick run through of the most notable updates and I would be happy to take any questions

Danny Ryan: nice thank you um I was just scanning to the execution api's degree in this list for anyone that's aware of it um are we doing the

the recipient diff is that in APR to be to come out maybe in the next upgrade of the execution apis

we have actually had a wrap consensus to not do the Deep but to it in another way just compute and just the sum of all transaction tips okay

Mikhail Kalinin: an extension to the engine API though right like we'll update the uh get

payload well I thought the El would calculate the like there's the question of like who will calculate this like if the El is going to calculate or like how sorry there's a question of like how you calculate the value of the block and then who calculates the value of the block and so if the El is doing it regardless of the way they do it we need to return it to the co but are you saying that the cl is going to calculate the sum

because I'll try to actually see how can calculate this um so it should I think

they can buy yeah I guess they don't have the gas used for every transaction but yeah it wouldn't be

Danny Ryan: it would still be a field it's just a matter of what that field the semantics is yeah yeah okay and there it was a PR issue for it

okay I'll take a look

Danny Ryan: any other questions for Chris okay thank you Chris um

really good info moving on so I have capella and then I actually have a 4844 issue near capella I'll make that but we'll start with capella Alex or anyone else can you give us the context on the founded withdrawals

Suite

Alex Stokes: yeah so we recently changed uh a little bit how we're doing withdrawals so there's no sort of formal cue in the states and instead rather than process things at Epoch boundaries you kind of do them every block and right now the version of the specs as you basically in the worst case sweep the entire value sets um so the you know obvious question then

is if you want some bound on that sweep and so there's a PR let's see I'll go grab it but there's a PR that basically introduces the sweep and it's more just sort of like a rfqa this or RFC at this point um but yeah we should decide if we want this or not

Danny Ryan: thank you um any strong components want to make the case to get this in there I know potas and dab lion were on the epr but are not here

um my last comment was you know that this does add a little bit of complexity and I don't think there's currently a very strong case for the complexity or at least the value being selected um I'm that said I'm only kind of weakly against this point um if we don't have the proponents on here then I will take this up as a priority to get discussed over the next school days

dapplion: I'm here

Danny Ryan: oh cool how's it going

dapplion: yeah so quickly I agree I don't think it's Critical with we have not I mean we have not run this on a main Network so it's not clear that this

would be uh but the link it just it just felt nice from someone concerned with those issues to have that as a bound but I don't feel strongly for it

Danny Ryan: right so it's I wouldn't call it a classic dos because it's not somebody somebody can that's something somebody can induce on us it's just like the maximum work that certain edge cases will have but I I guess the logic right now for the value is we can we have a validator set today some fraction of it we can reasonably sweep thus bound it to that fraction that we know we can do I guess

dapplion: the reasoning for it is in

normal circumstance that value is completely relevant but God forbids we may end up seeing a network situation with whether that value matters and in a situation where that matters is probably where the nodes are already overloaded for adversary neutral conditions so having that gives some peace of mind so I wonder what are the drawbacks of having that in

Danny Ryan: um one of I guess one thing is uh additional code that's almost never run except in adversarial conditions so then the likelihood of the code atrophying is higher um that would be my main thing

got it

Alex Stokes: yeah so here's a question for cl devs like if the dollars that were double in size is this an issue you'd have to like scan the whole set like does that make you uncomfortable

yeah

Danny Ryan: I guess we we do that right we do that a lot on the epoch transition but also a lot of work's been put into optimizing the epoch Transitions and making sure we're doing it early and stuff and I guess if we end up in a 4X 10x valid or set size here are we are you going to have to put in a bunch of extra work to kind of do pre-computation on this

dapplion: so I think the issue is we risk having to do a full sweep per block not per

Epoch and

that's what model ring

Danny Ryan: yeah I understand that and I guess I will take the other side of the argument now the um if doing a full sweep would require which we almost would never have to do in this case would require additional like pre-computations than other special logic that would almost never get used then that all of a sudden becomes more complexity that is potentially never having to be used or is only is being added even though we almost never need to use it so maybe the argument is actually that the these minor code paths

prevent having to do all that additional complexity that we almost never need to use so yeah I'm

Ben Edgington: how much more complex is it is it not as simple as a bound on a for loop I mean is that the

complex

dapplion: it's not that bad it's just it's pretty simple in my opinion

Alex Stokes: so there's like a second dimension too so like the first thing is down in the sweep but then also there's a question of like do we want to try to make it like fair in some sense so you track where you go um and yeah I don't know it's like it's not major but I do feel like the full thing you know does at all its complexity and if it's just for this like tail case that we probably won't ever see

I think we have to ask if it's that important

Danny Ryan: yeah I mean so here's where I stand like I'd rather do nothing but if doing nothing actually means doing a bunch of like optimizations for this Tale in case then I'd rather do this um so if you think that if we don't add these code paths it actually means we have to like highly optimize this for a tail Edge case then let's add these co-pounds I've kind of changed my mind

very cool

Alex Stokes: um do we know though like do we know if clients will need to optimize like this anyone on a call want to chime in

dapplion: we haven't

Danny Ryan: but we won't even have to know if we just put this bound and in that case I might argue for a smaller bound

yeah probably answer

Alex Stokes: okay so yeah I think I was weekly four and I became weekly against but it sounds like we're going the other way so

Let's see we can make a smaller bound and then also does anyone care uh about this like this fairness thing because then it does become like just very very simple sorry

Sean Anderson: I was just gonna ask like what is the fairness component like more concretely

Alex Stokes: so like right now we're like gonna start somewhere in the dollar sets and go say like two to the 17 validators um the question is if there are no withdrawals do you just stay in the same spot every time or do you want to advance your pointer 2 to the 17 every time

Danny Ryan: an argument that this is not actually a fairness criteria this is a mechanism criteria because you could have a range whatever that bound is where everyone's already withdrawn and you can't withdraw them anymore and it would actually get stuck so this is in an edge case and unstuckness or criteria to say yes it does help with fairness in the normal case but there's an edge case that it's requisite so I think it I don't think it's to be debated I think it has to go in if we if we do this bound does that make sense

Alex Stokes: yeah it does to me um

okay so I will keep polishing this PR and I guess yeah we can just build more consensus asynchronously

Danny Ryan: sounds good um and because I think this code path will maybe never fingers crossed be hit on mainnet um we need to make sure we have a lot of good test for it so that in the event that it is it's not attribute okay um are there any outstanding capella issues other than uh this bound of a draw sweep okay great let's move on to 4844

um this Blood blibes blob side car uh is currently mutable in Gossip there'll be two ways to fix it only to do the actual kdg verifications um at each top the other would be to reintroduce that sidecar signature it seems like due to complexity especially Rippling into um validator signatures and stuff that that is the former is the preferable path here so we do have some benchmarks um that Sean and Kev have done on various operations in the issue and I believe there might even be a PR that I

haven't looked at yet it's 3108 uh that Sean put up there is there any outstanding discussion points that have not been made on this issue that people want to bring up or are there any questions for additional context if you're not caught up on this okay so it does seem both of these operations signature verification and um the full aggregate verify both scale with the size of the number of blobs here both on the order of four

blobs per block look like a pretty um reasonable amount of verification time with respect to what we're already doing at each hop but both especially on signature signature verification if you're doing the full root calculation and in the um blob verification scale to something like slightly more than what our verification time is per hop there is one hack that's at least worth mentioning the flat hash so instead of doing the SSD hashtri root of the blobs or the signature you could do a flat hash which greatly reduces the time um but it looks like

from this discussion in these benchmarks we should probably move forward with just doing full blood verification at each hop and if that becomes untenable actually maybe discussed doing this flat hash each

hop

Dankrad Feist: so um in terms of scaling right the um uh so the the blood verification already does a flat hash um so and I think the rest of the computation like the so you don't have to do any uh kcg stuff per blob or any like group operations blah blah or maybe a minimal one like maybe one group multiplication which is like a really small operation

um so so maybe like I mean at least if we're comparing it to uh to a full signature without flat hash this might already be more efficient than verifying a signature at least asymptotically

Danny Ryan: yeah we're I guess I yeah I don't know exactly where it scales to but if you're looking at these benchmarks which we've done on different machines um you know we're we're 16 blobs per block for the signature verification with the root you know we're at something like 11 milliseconds um oh no

why does

Dankrad Feist: the marginal cost what's the marginal cost per block because I think my estimate is for uh for full verification it's just it's

about half a millisecond

problem marginal

Danny Ryan: um yeah on the signature verification we're at three milliseconds six milliseconds and then 11 or 12 milliseconds for four eight and sixteen okay

Dankrad Feist: so fairly similar numbers

then yeah yeah

Danny Ryan: um and then on the full blob verification I think we're at four milliseconds eight milliseconds and 14 milliseconds for the same set of numbers so it actually is pretty pretty similar and that's that's what the signature

verification with the full root calculation uh so with the flat hash we're at 1.7 2.1 2.8 which makes sense that it's scaling a significant subset of those nonetheless I believe the general consensus is to move forward with full blob verification um as it does not really add any additional complexity it also doesn't do um it pretty much adds no additional complexity it's likely a tenable number at the lower end of the blobs per block um and we can get more data as we move into test Nets is that the general

consensus here

Dankrad Feist: sorry did we have any do we have any number what it costs for 16 blocks or eight drops versus four on full verification

Danny Ryan: yes um and what what verification is for for 4 8 and 16. it is four eight and fourteen although he mentions that this is

feel strong

Dankrad Feist: somehow I would expect that there would be a

higher marginal cost for the first blob because you have to do pairings so like the first Blood probably should take like something like three milliseconds and then additional blobs should be like half a millisecond so that's what I would expect okay so that's why that's why I'm surprised there's a key to hear that oh somehow it's more of a like my expectation would be that um it should actually become less of a problem as the blobs uh become larger because like it's a very yeah compared to

door and

Danny Ryan: if you look at if you look at some of these numbers between 11 and 16 it ends up like it goes 10 14 13 13 15 14. so you know this I think maybe some error here and

uh I don't know exactly how it would scale if we ran a bunch of these

uh thank God

Kev Wedderburn: what did you say you was expecting

Dankrad Feist: I'm expecting something like uh three milliseconds plus 0.5 times number of blocks times number of blobs

extra point five milliseconds

Dankrad Feist: I don't know like Danny's numbers just sounded very linear that surprised me

or their Cavs numbers all right sorry

okay uh Kev

Dankrad Feist: let's let's discuss those benchmarks that would be great um let's

see

Danny Ryan: how much and help me understand how much parallelization um is being utilized in this and would I see similar numbers on single core

go on sorry yeah

Kev Wedderburn: I haven't actually checked uh but yeah I do have 16 cores

so it's right about Don credit is that calculation utilizing parallelization

Dankrad Feist: I don't know you can definitely paralyze it but I mean the numbers don't sound like it's paralyzed because otherwise we'd expect

it to uh yeah to increase a lot more with more blobs

yeah yeah

Danny Ryan: I guess but to that and the parallelization number would be good but I'd like to know what this looks like not throwing on 16 cores which if that's that's so rad that's good okay well let's um Circle back and just sanity check some of these numbers uh as for the gossip validation we can toss it in there I don't think this is going to greatly affect our smaller test Nets but we might revisit it if

um if we hit a wall with some of these numbers but I does that seem a reasonable path forward I guess the only thing that we expect to come out of revisiting the the numbers is actually a lower verification cost concrete which would be another check mark for going in this direction so um I'm going to review Sean's PR thank you Sean and um we'll try to get this out soon this isn't a Blocker on testnets this somebody could add an additional load on the test net by allowing bad data to be gossiped but I don't think that's what we're going to

run into for the next month so cool anything else on this one okay I know we have the 4844 call the weekly call earlier this week are there any other discussion items that we need to bring up today on 4844 okay great Mikhail Miguel has an engine API spec Improvement proposal Miguel can you give us

the details on that

yeah thanks Daniel okay so can we go over here um there is the issues here

Mikhail Kalinin: yeah the proposal basically contains to the two main parts in it in itself so the first part is the um proposed change to the engine API itself um and it's uh just introducing the cat Caps or get capabilities method um which we have which we came up to um the um workshop and for Defcon and this method allows us uh it basically Returns the list of

um currently supported engine API methods supported by the um El client and still client just request this list and understand what's going on what's the El version it is talking to and what to do next um so basically this list allows us to introduce new methods introduce them outside of like hard Works without any coordination efforts for upgrades of the client software also it allows to deprecate methods so yeah that's basically about this engine API change um itself and the other part of this

proposal is establishing some kind of process of how can we how do we want to or how can we work on the engineer aspects to make it a bit more structure structurable and reduce the degree of mass anticipate in the upcoming hard works and all this kind of stuff uh quickly about this um this part uh so what purpose is like basically we'll have a reference table of all methods that is uh that were historically proposed and were historically included in the engine API aspects um this table will contain the um actually the status of method like is it

like a final or it's deprecated uh final means it's stable and should be implemented by every El client or there could be experimental status which is helpful for doing prototypes and all this kind of stuff [Music] um I also uh the other part of it is um like how the spec files actually gonna be should be structure it and what's what's proposed in this uh what suggested in this proposal is that we will have like kind of files uh with uh different uh methods required for this or that the ID like eip4844 like withdrawals and alongside the work

is going around these features these new features and we are close and um as long as we're getting closer to um to the new Hearts work we create a new hardcore documents we put everything uh that we decided uh to be in the scope of this hard work in this document then we do some rounds of iteration on it on this spec document then we finalize it after uh we decided that okay there is a species we finalize this file and we basically never change this file the purpose of this is to have like a structured set of changes that we did to the engine API and uh to allow for

cross-references between the files so uh like for example Shanghai may I refer to Paris and say that okay so this new payload method is basically the same but we're changing these uh these three things are just list them so it's a kind of differential stack um description so it should be useful and yep and yeah that's basically it um um basically a live quiet has a different opinion on how should we structure those files and probably you can share it as well yeah my comment was just around the like

overloading of the use of the hard Forks as the organization mechanism for you know all the different rpcs I think that this makes sense for people who are going in and just implementing these so like client developers and stuff because you know we've already sort of implemented all the past forks and so we're in the new fork and it kind of makes sense that this is like the minimal set of changes that need to be done to get to the latest but I think it is not a great way of viewing the engine API and spec if you are not like very deep in like implementing these things and I think this is like a similar problem that this DL specs have where if

you're just trying to go in and if you what something does right now it's hard because you have to like kind of start the latest fork and look and see uh if the thing you're looking for is enough work and then go back one fork and look and see if it's not fork and I'm afraid to like recreate that with the engine API or if I want to see like what does git payload V3 do I started support I don't see it there I go back another forward I don't see it there you know and so it like goes for forward in that way so I think that if we do a logical separation of the different methods so we might have a method that's like or a file it's like blobs.nd and that would just have like all the things related to blobs which is right now mostly just

4.44 and then maybe like payload.md it has like all the like new payload get payload types of stuff that I think is not much worse for client developers because we can still say within the method like hey this is Shanghai or we can say in like the overview of methods like these are the methods that we're doing for Shanghai but to most people who just want to view and see what the engine API is doing I think that's a better way of interacting with it yeah yeah well I certainly see some really practical outcomes of this approach so we all just basically have if we are talking about new payloads we will have all the change so this method in one file and you can drag them back um and yeah implement it easily you will

just have it on one screen uh instead of like jumping from one hard Fork to another figuring out what was introduced uh same in in Paris and Shanghai what's needed to be implemented in Cancun if someone is implementing and cool from scratch I don't know but yeah what I like about this um hard work MD files is that you can just you know uh have it specked out and then finalize and then you just never touch this file and never change anything and that's unless there is like some bug that we want to fix um yeah also uh it more aligns with like this feature approach so if you have

like um eap4844 feature in a separate file so you can just then um yeah it's and it introduces changes to different parts of engine API it will contain them all in one file and we want to keep those changes separately from the mains back until some point in time when we decide to put to include this feature into hard work and then yeah so definitely functional approach also functional rights approach for this empty files makes makes sense to me so there is a kind of

trade-off

Danny Ryan: I don't feel very strongly here but I do

question who is the engine API spec for and it I would say almost entirely is for client developers because it's not a user facing API you know so as opposed to the API where we want it to be organized such that it's highly functional for users to jump in this is like so I think should be optimized for client developers because it's not something that other people would be using um that said I think both are relatively both paths are relatively functional for client Developers yeah I feel like if we have a list of

these are the things that were added or changed for each fork and then we the file level organize it logically I think that's the best of both worlds or you know vice versa like have a list of like this is The Logical things within related to payloads and the files this works I think just going with one of those approaches where you have both give us gives us the best of both worlds are we so when we're originally writing this we kind of planned on moving it to a more uh functional description like the apis and like the um Beacon apis are that can be better rendered and stuff uh instead it looks like we're at least currently doubling down on markdown

um I'm not markdown works for me I don't really mind but I do wonder if it's worth revisiting if markdown's serving us as we wanted to well the proposal does have a like folder section for the openrpc definition okay so we would do both um yeah I think so do we have this sentence for Paris or not

Mikhail Kalinin: oh we'll have to introduce them okay and we will start a time this proposal if we agree on it and yeah from my a short experience on like trying to put

some specification or finalized to save um and yeah block tags into an open Arabic subscription it's really hard to expect anything in in this form so I think markdown works better at least better than all of an RPC specification and it's not specification

schema

Jacek Sieka: I had a question you mentioned a request for a list of methods that the client supports or in the execution client supports

um not so much a question but a comment uh that that that's often not terribly useful because what users do often is that they upgrade their execution layer separately after um consensus layered land so one thing that that I think is useful is that we also kind of think a little about how to standardize error codes for something that's been deprecated and removed and then how we reason about methods that don't exist yet because typically what we'll do is consensus clients is that if there exists a newer version of a method we'll try the newer version first and if

that doesn't work it will try the older one or maybe the other way around like it depends on where where in the deployment phase we are right so um calling a function that lists all the functions available is kind of useless if we can just try and try each one separately and see if it works and then get like reasonable errors too to pick one

Mikhail Kalinin: I think that Jason RBC also already has this kind of error so if you call an app that I don't know what these are specifically is but yeah this this may also uh I don't know work but it's just

you know it just looks ugly from my perspective to be honest

and yeah and it's reality right because you don't like and it's reality uh sorry

Jacek Sieka: I think the core issue is here that we don't know when the when the execution client is restarted and upgraded as consumers that might happen anytime I think there is no agree signal

Mikhail Kalinin: but it depends on the dialogue that you use if you use websockets so you you can you may know because the session had got expired right and you had you had a new session established that can query

um every time the session is just as you started you can query this list of methods for HTTP yes it is more complicated and basically yeah and probably it is like Fallen back to error and calling a list of methods if you see that the method is unavailable or yet unavailable oh yeah yeah but but it will not work if some method is still available but uh El has been upgraded and has new capabilities that it can suggest that can um um that can handle so CL will have the query

so errors will not work in this case

Andrew Ashikhmin: uh so sorry uh guys uh clarification uh my understanding is that uh the the switch to the new to V2 methods is quite dramatic it's it's not a transitional period so for all pre-shan high blocks uh we should use V1 methods and for starting with the Shanghai for all Shanghai logs we should use B2 methods because uh the the head hash will be different depending on whether there is uh there are like even if it's uh uh there are no withdrawals the the hash of uh of an empty list should be present so

it's not like a gradual switch to to a new set of methods

Mikhail Kalinin: yeah I I can understand this point pretty well because I was trying to make these points uh as well and yeah yeah I I think it's another thing to debate whether we want we too to be backwards compatible to be one or not um and uh I suppose that CL uh clients they will be just cool which is easier for sale client developers to implement something like okay with CV2 method and we use it for every um on go uh for every interaction after we request it and got this method is

supported by you all instead of like we should called for trigger whether this block is is after the fork or before the fork to decide on which Mallet we use so as you like reducing complexity by having with two backwards compatible to be one but if this is not the case that we would like to solve I would argue that we should yeah be clear on which methods is called before and after artwork so to stop making it backwards compatible

I mean

Jacek Sieka: backwards compatible is nice because then

like again we can just try the new method if it works we get we get you know either the new data or the old data regardless of if the fork has happened or not in general of course that's not possible but that's what we've done in consensus like the beacon API a couple of times where we upgrade you know between block V1 and V2 you could first query only face zero blocks and then you could query any Fork blocks including phase zero and that was very nice because then you just try it with the new one and if it worked it worked if it didn't then you tried the old one and that's it it's you don't make lists or anything you

just give it a shot

Mikhail Kalinin: yeah yeah yeah that's that's supposed to maybe this is just you know can work out what we have currently I'm not sure uh yeah I've said that it's just seems awkward to me it looks ugly um yeah it it definitely reduces this bad complexity I don't know about engineering complexity and the mass and the code that um dislike callback uh would introduce about backwards compatibility um I have a pretty strong opinion that we should not support more uh than like two forks uh

uh in one methods version because like if we will support all perks and like we we tend methods will you know contain all the logic that is needed for everyone with two and so forth that that is going to be a huge mess but backwards compatibility for like one work is probably again if it's reduces engineering complexity so we need probably client developer inputs on the get capabilities methods versus uh trying and fall back okay

if there is an error and the other one is like the um yeah the other two things are backwards compatibility and the structural this back basically hard Sports versus functional um grouping does anybody want to chime in

Danny Ryan: okay based on this conversation in the

right discussion in three two one Mikhail are there any immediate changes you're going to make or is it still in a good shape for other people to read in China at this point

Mikhail Kalinin: I think yeah it's still good to read probably until next week

Danny Ryan: okay and then how much is this is this a a critical blocker as we're moving towards um Shanghai or is this something that won't block our development efforts you know what's our timing criticality

here yeah

Mikhail Kalinin: that's a good question I don't think it's blocking really anything right now but yeah we we just need to

start like if we were if we're going to have some process and yeah the earlier we do but the better for us let's clean ups we will have to do in the future

Danny Ryan: okay um so please take a look this week if you want to chime in on this process we might have a feeling we might not be able to get to it all cordoves next week but maybe we'll throw it on the agenda and if we don't then in two weeks time we'll revisit this conversation sound good any final closing comments here

foreign

Danny Ryan: now for uh General open discussion anything anybody wants to bring up today anything at all okay great thank you everyone uh talk to you very soon take care

thanks everyone thank you thank you bye bye thanks bye thank you [Music]

foreign [Music] [Music] foreign [Music] [Music] [Music]

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