All Core Devs - Consensus #109

Transcript

foreign [Music] [Applause]

okay we should be live on YouTube let us know if you're there uh this is consensus layer call number 109. um this is issue 783 in the PM repo if you're following along great um I know that there was a main incident uh fortunately chain stayed alive and kept going and resolved itself I know there have been a couple of client releases and there is also a post-mortem out um by Prism is there anything that we

want to discuss about that today I know there's ongoing testing and Analysis okay uh if you're listening in check out prison's postmortem it's good um I think it will be continued work on this for a while thanks all right

Danny Ryan: moving on uh we're going to look at the neb we have a number of issues um I think a lot of these are updates and things that we're trying to make final decisions on um and we will begin to go through them so there's this openpr 3338 which is to

um make it so that the kcg commitments are The Blob commitments can be much larger than the actual gas limit it seems like the consensus now is to um have it at a pretty large number on the order of thousands but to keep there to be a restrictive constant that's in the realm of the gas limit such that this number the smaller number can be increased without changing the shape of the Merkel tree which is a property of SSD given the max list size um is there any update on this I it seems like we're on the order on the

verge of consensus and we just need to do a final cleanup and review okay is anybody against the two value strategy where we have a large value that helps us shape the Merkle Tree in a small value which is in the order of what we can actually handle okay uh I believe this PR was like gender is there anything that we need to do to get this cleaned up

um or are we in a good spot to just do a final review

emerge

Gajinder Singh: I think we we should be good for the final interview because there is one comment and regarding the site car validation so I can remove the extra validation command that I added while while editing the site car that it should be the index should be less than Max blobs per limit so since the subnets uh anyway are going to be open then Max blocks one limit so it's sort of a redundant validation that I added I can remove that

Danny Ryan: okay great other than that um we'll put some finalize on it and get this in uh

just for context you know this is probably one of about four things that we're trying to get finalized for a release for new testnets so this is on the list and we'll get that done

okay um the next is there are a couple of PR's um about this ongoing conversation I believe decision made to pass the version hashes into the engine API to do the validation against the transactions so that we don't have to do the transaction peaking on the consensus layer there's the engine API and there is the

consensus spec change Mikhail are there any comments here other than just needing to review and get these merged basically

Mikhail Kalinin: yeah I would just like to say that the pr is kind of created and the engine API and one another big question but just would like to attract my developers to these thing is that how to pass these old version flashes currently PR suggests do this by uh introducing a second parameters to new periodical uh which obviously breaks some extractions

that we had before only payroll but the other option would be to introduce an email to pass payload and block caches as one object but that's as well can break some abstractions so it's kind of like what's done currently is just you know to try to avoid uh if it's you can do some new um data structures to engine API but probably um it is easier for some clients to implement it as it was the last sign of an invalid so that's basically one of the things that

I'd like to to people to take a look at and yeah any if that's fine as is um then yeah we're ready to go over this PR oud um yeah to address and scars comments uh yeah so and yeah so that's basically this this this PR just what I've done is just the first this shot to El it does not you know change this uh trust assumption in any way

and that's another stuff that hashes then we need to decide which which but that's a biased that much

Danny Ryan: yeah I um I mean if the data transfer was a problem then we would consider that but by compressing it we just reduce the ability to communicate error messages and other things so I unless there's a strong reason I wouldn't do it

Mikhail Kalinin: right but uh yeah they fall off the chat

so yes it's not about the availability so but I'm sorry I really I I don't understand what uh what's broken by just different in this

chapter yeah

Danny Ryan: because the check only happens when you're synchronously communicating over the engine API so in the event that the execution layers sinking it doesn't actually ever it can't ever verify these numerical commitments um for the past components because uh it doesn't have them right and so it only happens when you're doing this synchronous check

there is a precedent for a value that's done in the synchronous track and that's the block hash which is also passed in from the there's a block hash embedded in the execution payload and the consensus layer and that's passed in and that's only checked uh you know the consistency between what's shown up in the execution there and the uh whether that hash is correct um and when you're synchronously communicating so anscar there is a precedent for this um and the assumption is that uh this type of synchronous check even though it's only happening when it's synchronous you can only really potentially fool

a uh syncing node and so yes that it exists it already exists with the block hash you can fool syncing nodes about this validation but it's very difficult to rule the network um does that make sense

Oscar

Ansgar Dietrichs: right I mean I'm not super familiar with the with the block cache situation I would then consider this an issue as well but uh I don't think it's a good idea to once we recognize there's an issue to business say well you know this property is gone forever now so now we might as well just stop caring about it my question then would be if we stop care about this why do we even still

have why do we even still store the El header other than of course the the values that we want to make accessible via the the broadcasters from inside the EDM I mean that's that's the reason but for integrity checks then we might as well just completely never store anything and just treat everything ephemeral information

you know

Danny Ryan: like I don't follow that nor do I necessarily agree but the block hash or Marius or somebody familiar with the engine API even if your syncing is block hash checked

Marius van der Wijden: the you mean the execution layer block

age

Danny Ryan: no the

the block hash so there's a block hash that's explicitly in the um okay block hash is always checked by the engine API so these could also always be checked by the engine API about ad overhead during sync

you mean during the consensus layers not the execution layers you're doing the execution layer I think we always check the block every because we have to sort of change oh sorry we're talking about two different things

Danny Ryan: the because during the engine API has an additional field where the consensus layer says block hash

yes we check that on everything

yeah

Danny Ryan: even when you're in like a sync status and doing other stuff if somebody gives you a new payload you check that yes yes okay so to not change the Assumption the sync assumption here this feel this list of case review commitments would also have to be checked at the same time um like like block hash is checked no matter what even if execution layer is sinking is that something that we're willing to do otherwise

we do change the assumption States so it would be similar to no cash check

Danny Ryan: okay so then as long as clients can and are willing to do that this does not change the security assumption at all

Mikhail Kalinin: yeah I saw that by default it is possible as we have discussed it yeah so if it's not please arise you're concerns in the pr

Danny Ryan: so OnStar just to be explicit in the execution payload which is a consensus layer data structure there's a a couple there's an X thing called extra there's just an extra field called The Block hash which is the execution layer block hash of the rest of the payload contents this is passed into the engine API and before the

before the Executioner does anything it checks to make sure this uh that that hash is consistent with the rest of the payload fields and so it it does this kind of like synchronous check and it does that independent of syncing and so these kvg commitments being uh correct against the transactions would also be done kind of in that pre-processing before returning anything related to syncing or otherwise and so they're the president for doing this

how costly is system check because check is very cheap for us

Danny Ryan: this is um you have to look into so you have to deserialize transactions and pull out a

field and check the field against it Buffy today that's fine we already have to deserialize them and remarkalize them right so this is cheap I'm scared we can talk about I can explain it again or we can talk about it outside but it's it's exactly the same thing it's not these blocks the black ashes are not guaranteed to be self-consistent here because this is an extra field in the consensus layer it's kind of like how the kcb commitments are an extra field and in the consensus layer and we have to ask

the execution layer now to make sure that they're their equivalent to what's in the transaction similarly the extra field of block hash in the consensus layer that we asked to make sure is consistent with the rest of the fields and the execution layer um but yeah I'm confident that this is very very similar and we can talk about it outside the call when UCL start sending new payloads while the El is thinking the CL does

yes is this is it from the like week subjectivity checkpoint it's from wherever you're thinking from and that's the point that you're seeing

it from is the week subject to the checkpoint that you've chosen

Danny Ryan: it certainly could be it also could be sent a day ago when you turn your note off it also could be that you use the weak subativity hash and eugenesis sync and and check that those hashes are correct when you get to the head so it just depends on your model okay so there's a few things here one I'm pretty confident this is the same type of thing as block hash and if we're doing the validity check up front independent of syncing then we're in an okay validity check mode that

looks exactly like we've done something in the past um we do need to validate that this is not put induced uh unprecedented load uh in the pre-processing check um which we're pretty confident is the case because you have to do the deserialization to do the vertical position anyway um and so we should Sandy check both of those things and if anybody has issue with the way this is done they should jump into the engine API uh ER very soon like this is something that we've pretty much decided and we need to make sure and you check that this is

correct and okay um because we're looking to do a release this coming week to get this onto chestnuts and onskar you and I can sync on um the validity of this and convince each other that this is either okay or not um anything else on this one

Terence Tsao: yeah so um one thing to note is I don't have a good answer to this but I want like whoever is working on the Builder they're really excited to be aware of

it's that now before even that the cl can verify SSC block transaction you can actually verify that before but now that CL can no longer verify that we have to rely the El to verify that so I'm not quite sure how the real layer will be able to verify that and it's kind of like an open question so I encourage people to think about that I I don't have a good solution to this but yeah

Danny Ryan: I don't know if I follow because the relayer can also ask their execution AP uh client correct

Terence Tsao: yeah basically layer needs to code a new payload right but me

might not want to do that because it's slow right it's basically they want to reduce latency but they just want to verify the alignment between the blob transaction version of the cases income they lent but but then instead of verifying the whole thing they just want to verify that but but then you cannot do that anymore

Danny Ryan: yeah I suppose if a relay is being lazy or quote optimistic and they're not running all the transactions then they're already taking an assumption that their Builder is giving them correct values so I don't know if not doing this consistency check is really changing their model too much

yeah

Terence Tsao: yeah Fair that's that's a fair

point

Danny Ryan: but I mean I agreed something to think about um if that's how you realize constructed okay great um this is on the list of things that's going into release early this week for next test Nets please take a look at this if you have um concern or if you have uh if you want to kind of weigh in on on this strategy

I believe we have a relatively non-contentious PR that is adding a variable to kind of make the number of blob side car subnets um look and how those are specified look like how attestation subnets are specified which is with its own variable so that it can be tuned up and down independent of the actual number of Globs um pop do you want to give us a quick on this one uh yes uh uh clearly in the in in the current spec uh the the number of psychi because it's a public is equal to Max Bob block uh

but but it's not good because uh because if you want to if you want to change the the constant Matchbox uh the number of something is changed there will be some subnet that that uh that will be used for toolbox so it's like if he in this PR we we can change the Maxwell block like it didn't

independently right without changing the the number of subnets right and this is the this is parallels how application subnets are done independent to Max committees um I do think it it's a no-brainer to have these as two configurable values rather than just one I think we were we had some build issues due to some CI cache problems but this is likely to emerge later today unless anybody has uh an issue

I

Gajinder Singh: I have a confusion over this in the sense that in the first PR that we discussed we introduced a variable Max

commitments per block which was set to be 4096 now we have Max blobs per block which is currently set to four and then we have another for subnet so I think the the new variable for subnet and Max blocks per block they are doing the same thing as of now because we rejected Max blocks per block to be independent from what CL can handle in the subnet

Danny Ryan: so right so they're not doing the same exact thing um so if you had Max blobs for Block S4 and you change the sub or to eight and you change the subnet count to you have the subnet count at four you would then

have two blobs being distributed per subnet and this is kind of a this allows you to tune the essentially the gas limit independent to how it's delivered on the P2P mesh it essentially allows yeah allows for reuse of uh subnets for additional blobs instead of always making these evidence all right cool

um next up three three five four this is

update the indianness of polynomial commitments

Danny Ryan: this has been an ongoing discussion um I believe that there's General agreement to swap over to Big Indian um I in discussions it was maybe unclear if that's to do for everything or rather just one interface um can anybody give an update on where this stands in relation to what's going to happen in the libraries and and everything and if this is ready to go in

Gajinder Singh: so I maybe can say something on this

that for the on this El side now that we have rlp transactions uh basically it will anyway all the data will anyway be encoded in big Indian and so and if the pre compiles are also began and so that basically solves a problem of el uh but that means that Library will have to take inputs also in the big Indian form so either the library fully shifts to Big Indian or a particular pre-compile verification function which verifies blob version hashes uh sorry which verifies commitment version has

seasonal proofs basically it can just take big engine as input and Library can do whatever it wants to do in inside

Marius van der Wijden: yeah so it's really not an issue for us we can uh we can before we call the library we can just run from the inputs around so like the library like the library should do what they want and the prequel like as long as like there's a shame anyway between the pre-compile and the library so we can turn turn the buds around

Zucker

Danny Ryan: I believe there was a desire to change the limited interfaces yeah library right

Marius van der Wijden: yeah yeah we definitely want to change

the libraries because it doesn't make any sense for them to be the land you know like the only reason was because we expected the consumers to be a little Indian but now it seems all the consumers will be big Indian so there's no point in keeping the library little Indian because all the back-end PLS libraries will also be

taken yeah

Danny Ryan: got it um with respect to the pr that's in the consensus layer is this ready to go for final review or is there are there additional changes that need to be made does anybody know

the tests are fixed so to me it's ready

Danny Ryan: okay so this is on the list of the handful of things that are going into the next release and this is likely to be merged in the next few days um if you have any additional desired review or comment please do so immediately Alex I believe you wanted to give us

some 4788 updates

Alex Stokes: yeah I can do that um let's see so 4788 is Eid key to send over let's say the beacon block route uh to the El so it can be exposed in the evm in a trust minimized fashion it says lots of great applications for staking pools uh restaking Mev stuff all sorts of things so uh this might be at this point more of a execution layer conversation to have I think it's pretty minimal on the CL so uh there might not be too much to discuss here but that being said um on the last acde we decided

so the way it was written before was that the L would use timestamps to figure out which slots correspond to which block groups so essentially the block road be sent over and the question now is which slots does it pertain to and if we send over some well if the El just has some uh slot data like for example knowing like how to map time stamps in the slots then it can just do the computation itself we decided to not sort of violate the abstraction barrier between the two layers and then send over the slots along with the root and so that's what the latest changes um I think there might have been even some pushback though about this approach so I don't know if anyone's had a chance to look and if they have any thoughts or

feelings about the direction this is going

Danny Ryan: yeah I was the one that put the comment I didn't realize that that was the outcome of the last ACB um it I understand the abstraction layer it does them excessive to use you know the and the execution payload header as a messaging bus for the slot but at the end of the day um I don't have a very strong opinion here yeah I mean I kind of agree or go ahead

Marius

Marius van der Wijden: yeah I don't I also don't like the putting the slot in the header um I don't I don't fully get why we need

to or like store it by slot and not store it by uh by timestamp and let the let the smart contract figure out the spot or the other way around store the beacon like right now we're storing a mapping of lots of Beacon route if we would turn it around and store a mapping our speaking route to timestamp um the the contract would need to provide a big route that's kind of fun I'd say and um and then get the timestamp for it because again I don't know if I'm wrong but like the only really use case I would Envision is um a slot trying to verify that a certain big route was

um what was uh was there at some point

Danny Ryan: and I think yeah I mean it's generally to make proofs against right

yeah

Marius van der Wijden: yeah but like you can like if you provide all the data yourself you can also make proof against it but you need to make sure that this was this was actually at one point in the chain right and so if that's the only thing we need this for then why do we need to return the why do we need to return the the beacon route if we can just like provide the beacon route and say okay this was at one point or at this slot this was

sure

um I

Danny Ryan: I see how the lookup can work either way um it does complicate the data structure in using a mapping which would probably be more of unbounded in growth rather than um a ring buffer or uh which could be more simply bounded in growth um I think the the ux of the mapping in that direction makes intuitively more sense to me but I I agree that given the use case both would work

Marius van der Wijden: yeah so uh anyway I implemented the current spec without the slot with only the timestamp and um ads it's kind of not not hard to

do it works what I would have right now what I don't like is that it's uh it's an OP code that reads A Certain address and a certain um and a certain storage slot um I would rather make it a a pre-compile stateful stateful pre-compiled yeah it's kind of a New Concept but um any way we implemented it's going to be a New Concept if we if we implement it as as something that is not in the state it would be like a New Concept because we we cannot look it up like we look up

the block hashes um so we would have to have like another next part of the storage and um also I think Alex doesn't want this because it would mean that the state transition function is even less pure than it already is and um so I think yeah the the putting it in the state makes more sense to me and then if we put it in the state at a specific address then it kind of makes sense to make this a pre-compile because then we we kind of know what what happens and we like if we if we have

this op code that reads it like we have to think about all of these edge cases that we don't have if we know it's a pre-compressor for example like what if someone calls this uh calls this address that where the where like the storage lips or what if someone self-destructs to it or like there's a bunch of Education that are figured out with free compiles that we don't have with this yet

Danny Ryan: yeah I personally think a staple stable Creek miles are actually very useful especially in stateless where you're trying to not have as many kind of like assumed hidden inputs um to various things I I think that it's a design pattern worth

you know making a thing even though it's not a thing yet

Marius van der Wijden: that's kind of that's the end of my only problem with it it's it's not yet a thing and in order to make it I think we think we kind of have to like think about it so like yeah

Danny Ryan: yeah I mean and that that's one of the things is uh you know Engineers seeing if staple big files break some deep assumptions and and the software because it's from a theoretical standpoint they seem fine and clean I think from a engineering standpoint it's unclear until you all say so yeah

Marius van der Wijden: so in general I think this this uh

this Eep is not really yet ready yet and we shouldn't push too hard on it um before these things are so that's that's kind of my take like it's a good it's a good Eep and and we can we can definitely do it but like pushing it into

what's the next one Cancun would be kind of hot in my opinion

Danny Ryan: hard because you want it because you think it should be a stapleberry compile but there's going to be a lot of uncertainty when we go down that path

Marius van der Wijden: yeah but we should make sure we have

this concept of a state pre-compiled down um if we make this change

Danny Ryan: okay I think it probably makes sense to do a draft PR of a stateful pre-compiled version and to talk about this on the Executioner call in one week

Alex Stokes: yeah I agree uh Marius do you feel really strongly about somehow also trying to look at storing things by timestamp rather than slots and just ignore the slot at the El

Marius van der Wijden: yes yes I feel very strongly about not having the slot in the header

Danny Ryan: I feel strongly about that yeah I'm sure

but like we get instead just have the El compute this some other way like the eel just needs a few constants to be able to do the time same to slot conversion

Marius van der Wijden: so yeah much of an ass that is kind of that is kind of licking the abstraction

and what's also the point of the CIP

Marius van der Wijden: yeah but it means that like for every test net for every Network that we set up we have to kind of to do this whole dance of creating something that works on both sides

Danny Ryan: um okay I'm gonna think about uh timestamps and see if we can make that

look nice and yeah I can make this look like a staple pre-compile definitely in the next couple days and then we can discuss next week

Marius van der Wijden: perfect

Danny Ryan: um the last thing is for dancoon is 3360 which is a um we agreed on a previous call that this is something that we want to see in dencoon this is the expanding the application slot range from instead of slots for

Epoch to be uh either from Epoch n it can be included either in Epoch n or n plus one where n is the epoch of the app station was created in um this is to improve or to allow our security proofs to work properly for OMD ghost as well as opening up um the usage of a confirmation rule which is in progress in which the two we'll talk about soon um this is two lines of change in the state transition spec as well as the modification of PVP gossip conditions I guess the final to do is to get some review here and I'll probably open up an

EIP in relation to it to give it kind of a number to track it but I would like folks that from various teams if I'm up thumbs up it so we can keep it moving because it's important for security it's generally been agreed on um are there any questions on this PR 3360 okay we're gonna keep that moving um I'm not certain I don't think it's going to make it into the release like Tuesday but it would be in a subsequent

release okay great anything else on Jeanette thank you you're up next removing merge conditionals since capella

yes so uh in the there are trips we introduced some defense texts to detect if the merge uh has been triggered or not and I think

this tests are so this is these conditions are still in the capella and then aspects but I think we have again very few benefits to give them in the spec a status quo things they are just meaningless for the magnet and both the future updates so I wonder if we can just remove it from capella so it will be a causes of change but it should be

compatible with magnet you have any comments

Danny Ryan: yeah I think I'm in the only one to speak out slightly against it in that it's nice in theory to be able to perform merges on other test Nets at arbitrary Forks post capella um I think the actual use of that is probably minimal to zero um and there's been General agreement from client teams that keeping that complexity Fork to Fork um and managing that especially in pads

that we're really not testing much at all anymore is yeah it means it's it's much preferable to just remove from the spec which would then remove it from various tests so yeah I'm I think I was the only one that was slightly against and um no one else agrees so we'll move this forward unless others have one enchantment is Mario on the call Mario Vega um do you know if we're doing Hive tests on capella and after on merge

transition conditions

Mario Vega: yeah I don't see how this could break and you're desperate really need to double check yeah I'm not sure um but we also want to remove the premiere tests anyway so um yeah

Danny Ryan: um so this is in two PR's three two three two and three three five zero if you want to chime in before this moves forward do so very soon great uh Aditya you're up next with the

confirmation rule PR

hi everyone uh this beard introduces a fast confirmation rule in the spec um I'm pretty excited for this one because I think it's a milestone Edition for ux so at least from our current analysis it looks like we should be able to confirm blocks within three to four slots so under a minute on mainnet the way this rule works is you input some safety thresholds so um your assumptions about how many validators are Byzantine how many of them are willing to get slashed stuff like that and this rule outputs whether a certain block is confirmed or not um and I guess this is two main places we would use this in Spec one of them is

the full Choice update to the execution layer um specifically the safe block hash earlier we used just the Justified block route but we can do much better now it's going to be much closer to the head of the chain and the second place is the beacon API this is stuff we haven't specified yet still thinking about the best way to expose this uh to CL users so we can have a discussion about this now but also we can wait um until people have read this and continue the discussion next time

Danny Ryan: do we have like when you on on get Block apis on uh the beacon apis do we have some special keywords like head

and finalist and Justified

yep that's one place we could we could insert confirmed um you also probably need to um set up your security parameters for it um so I I think another place uh we could do this in the beacon API is the Fortress debug endpoint so it should output the confirmation score for all the unfinylized blocks so that way if you're running some kind of visualizer you have the data readily available

Danny Ryan: and what's the um synchrony assumption here in addition to your the safety threshold values

right the synchrony assumption is that um attestations are delivered in the

same slot which means everything that happened in a particular slot gets delivered to all the honest people by the end of it

Danny Ryan: great and before I take a deep look at this what's your kind of estimation of complexity is this primarily just a lot of math simple math compute on values or is there additional things that need to be stored and that beyond what we already have

I think it might take some effort to do this efficiently for the most part it's using all the food Choice Machinery so get weight is being used uh mostly

I can't see what a blocker for this would be but it's mostly effort in performance engineering

Danny Ryan: okay yeah thanks Aditya and others that have been working on this this is really exciting uh any questions for the chat okay great and um lion we have one more issue 3288 or PR I haven't opened up yet um can you give us a quick on this

this is a very simple change which we do for the Netflix compatible it will allow participants to submit a valid or exit which is valid indefinitely on the Chain currently if you submit an exit what if you could use an exit before of time that exit is only valid for to Forks and that's pretty bad ux for certain use cases where you where you may want to present exits so what this would do is it will lock the epoch that you use for verifying the signature to Capella allowing exits to be valid indefinitely it's a very

again it's a very simple change that has pretty nice ux benefits so I think this this should be able to be included for the

nap

Danny Ryan: does anyone else want to weigh in here I think it's very close to the POS too the POS address change operation so it makes sense to exit as well

so

Danny Ryan: the BLS change operation should be

changed as well I mean I mean should be because the POS address operation uh the domain was also fixed I see so I think these two are I mean the exist is also a one-time operation so it's fine to just uh I mean I support spis change is the primary counter argument that this was put in place to ensure that if there was some sort of sustained forking you your messages across Forks would not be replayable but

this is kind of a one-time operation and doesn't really affect your security too much it's just an exit but it doesn't really matter if there's replay um if you ask me I don't I don't know I don't have that history buttons here if I had to wait I would say it was just overlooked

Mikhail Kalinin: so even if such exit happens you can deposit again on that

Danny Ryan: yeah I don't I don't know if it was

overlooked but I don't think the ux was considered too much about offline signing and having to bring additional information into offline signing okay uh there's no tests on the CPR but it was someone was going to say something sorry I just want to trimming that uh we do have um open PR on the deposit COI that we were discussing if uh we can add the voluntary exit operation feature but right now it's sort of uh stuck at

the domain the signing domain like and to support uh for offline signing but also in the future upgrades we have to upgrade the current version sorry the current folk version in every protocol upgrades so it does wasn't the ux for random maintenance for the deposit tool I mean the signing tool to me and for the test I can fix it after the call maybe tomorrow okay let's get tests in there and um

evolving processes this should also have an accompanying VIP so we can track changes um so if we're going to do this we should open up an EIP with quick motivation justification that links to this um and get tests done and get some thumbs UPS from various teams after we do that Tim you want to write the EIP that's the blocker I will uh you can Circle back with uh lion I'm sure assistance would help keep this moving anything else on the neb on spec on

Research anything else at all today okay uh we have a lot of little things to do on all these PR's uh that are going to be merged very soon if you have any final comments or review on them please please do so now um we're aiming to have a release early mid this coming week um so that we can keep the 10 cents thank you everyone talk to y'all soon thank you thank you

goodbye

guys

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