All Core Devs - Consensus #90

Transcript

[Music] [Music] so [Music]

[Music] [Music] [Applause]

[Music] so

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

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

[Music]

Danny Ryan: stream is transferred if you can hear us in the chat on youtube let us know okay consistently our call number 90 issue 555 on the pm repo um looks like we will chat about anything merge related uh any sort of client updates other people want to share um mev discussion point uh a couple of discussion points from afri and then open discussion on the merge i don't have any particular action items

is there anything people want to go over today

Mikhail Kalinin: i have a couple of things related to the merge but not like directly something like big or that kind of thing uh so uh yeah this is yeah so we can just uh go ahead right now or

discussion go for it

Mikhail Kalinin: okay okay cool okay so first one is that uh was the um issue with the taco and aragon on the um uh shadow fork number seven

it was a kind of a deadlock where taku was sending portuguese updated to aragon and aragon didn't respond in time and then decode timed out this request and after that yeah taco just stopped sending anything to aragon and aragon was not responding because of it was like sinking and looking for a block um yeah that's kind of like a bug in aragon and a small issue in tekku the issue related to these timeouts and whether to send again the request or not to send

i think that yeah and that made me made a discussion with uh perry and uh i think we should add a kind of recommendation to this back now it says uh now the spec currently says that consensus a client may um retry the call if it was timed out but i think it should retry in some uh especially in some particular situation uh when for instance co client is syncing and it sends the for choice updated or new payload and the el went offline and for some reason didn't respond in time and this request turned out and cl should like retry this request once again because it is

processing a block and they want to get a response to proceed with the sync process otherwise the sim can just get stuck so i think that adding recommendation in this bag does make sense uh i i would also like to um yeah make a notice of this uh kind of thing to see our client developers so so they can think about it and take this into account uh of how the sync process on their site is code is designed and how does it work with respect to calls to execution layer so they won't be stuck in this kind of situation

we've

Danny Ryan: got it

can you open up a suggestion in the execution apis along with a detail of the scenario so that we can read a bit more on it

yeah

Mikhail Kalinin: sure i think i will just submit the pr it's like a tiny change and it will describe this particular situation

thanks any questions from mikael um chris

Terence Tsao: currently doesn't do this but it should not be very hard to add this so yeah

yes or

Enrico Del Fante: just an update form from tech of side so since this has been

seen in the tech very compare we already emerged a fix for for ensuring that we are going to resend for choice updated um no matter what so even if we got stuck somewhere with the same the same for just update data for whatever reason at some point after a while we we try to send it back to the execution layer even if it time it out or whatever response we had in the past we try to ensure that we continue sending something in any case yeah i think what's uh also important is

not only sending this but also uh if you see a process if the exclusion process depends on the response so that the response eventually should inform this the same process

so it's just kind of feedback so

Enrico Del Fante: so yeah definitely when when we when we receive a response we're feeding back uh the result to the in to the rest of the of the deco modules but um we still want to have a more clear situation what happened yesterday with regards of the of the sync process um i want to i probably tomorrow we will discuss it

with uh with dimitri as well and uh have more more more more more analysis on on where of the real root cause of the of the stock of the thinking process yesterday and uh we will connect to the pr i did it yeah today if if we need to do something to ensure that the the same process doesn't stack anymore thanks anything else on this one michael you had another one

yeah another thing is um we have been a bit analyzing and evaluating the latest valid hash thing and how and it's important uh for uh for the network and for your clients to implement it and uh one thing that i am wondering is uh it's not it's not like explicitly specified in the optimistic specification uh but i guess that clients uh like kind of agree on uh the exact behavior around uh um not validated blocks and what what happens um just a reminder not validated block according to the optimistic things pack is a blog that responded with the sinking or

accepted [Music] from from the outside and yeah what i'm wondering is the client's client's behavior cl clients behavior uh after restored will they replay these uh not validated blocks and will they try to resend the new payloads and the factories of data to ideal client for this particular blocks after the restart i was just making this question posting it in the chat and in the intro discord channel but just requesting some attention to it

i'm

Danny Ryan: not sure i would assume they

continued to insert blocks on the tip that they had not had inserting on the tip will either return accepted sinking or eventually valid or invalid rather than replaying whole stretches of uh uncertain blocks but i'm not sure how that's engineered exactly yeah i was like uh um thinking about two possible cases here one is not replaying them at all and the other one is to replay them starting from like the most recent justified checkpoint so um because justified we can assume that justify it if the if the block is just fired down the

radar has been validated by two thirds of networks so it's pretty safe to deem this payload is valid but what happens next is like yeah up to a client limitation definitely does it matter the distinction is there a case that you're concerned about

Mikhail Kalinin: um yeah the the case that i'm concerned about is that if it's not replayed we can like in a very um particular series in a very particular edge case it could result in like probably in data availability issues where el clients if they were a payload that is invalid

uh the el client can just drop it uh and uh yeah if cl is like strike tries to to sync with the um chain that contains an invalid payload and doesn't send this payload after restart then yell will never uh resolve from it from

this situation

Danny Ryan: assuming el can't find those invalid blocks on the network is that the assumption

Mikhail Kalinin: yes exactly exactly yes exactly and i think that this pretty um reasonable assumption because yeah um even if he always stores that box they will not expose uh to the rest of the network there's a reason

to ask

him yeah

Danny Ryan: right that's why it matters if this node that's in some sinking state is either going to think that that invalid chains the head for some reason or get pulled onto a valid chain and if they think that it's in the invalid chain is the head for some reason that means a lot of nodes a lot of validators do and so i think that it actually in that case you probably don't have the data availability problem but it would i guess depend on the particulars of why these invalid blocks exist to begin with i guess if your fork choice is anchoring

you on an invalid chain then there's a lot of nodes that are really happy about the invalid chain for some reason and likely serving it

Mikhail Kalinin: yeah exactly so that's a kind of like probably the situation that we don't that we shouldn't care about that much but anyway

Danny Ryan: does any engineer have some insight on what's actually happening here on node restarts while node is in optimistic for mode

Paul Hauner: lighthouse we won't try and

resend um those optimistic payloads or the not validated payloads um we might send an fcu a fork choice updated for it when we boot but we're not going to try and replay any not validated box when we first start up again we'll just kind of keep them and know them and we might send descendants for them if we see them by the peer-to-peer network or the api

right

Danny Ryan: i'm not certain this edge case would in most scenarios result in date availability problem but um if you want to think a bit more about it and write it down i'd love to take a look

okay

Danny Ryan: other merge related items perry we have a shadow fort coming up anything anyone needs to know or do on that

Parithosh Jayanthi: um currently the notes are just sinking um the beacon chain hasn't had genesis yet but we aim to hit ttd around tuesday

Danny Ryan: great and any update on sepolia

Parithosh Jayanthi: we have a ttd chosen there was some hashrate fluctuations yesterday but as far as i know they've stabilized

again and most of most if not all the validators have already updated so we should be prepared for a merge even if it happens earlier

great okay any other merge related discussions great glacier went fine by the way

Danny Ryan: yeah i saw one message in all core devs about it which was a signal that it went fine

Marius van der Wijden: one one block on the bad chain so less than 0.2 percent of hash rate

Danny Ryan: oh that's great and uh major infrastructure providers presumably refine our exchanges and infurias and wallets and things

Marius van der Wijden: i don't know

Danny Ryan: yeah we might have heard

it

Marius van der Wijden: i haven't seen anything yet

so

Danny Ryan: great okay anything else related to the merge

okay are there any other client updates people want to share okay great moving on to mev boost metachris can you give us the tl dr on the issue and what exactly you're requesting of this group

Chris Hager: sure hey everyone the tltr is regarding the builder specs

currently the get header request is not signed by the proposer which means that everybody can request the current headers from the relay

Danny Ryan: and getting a header that's a that's like a bid right

Chris Hager: a bit exactly assigned builder bit and uh having this open to everyone uh messes with the auction mechanics so now it's turning out to be an open auction on the relic which incentivizes builders to a bit low clear the relays and submit like incremental bids out beating each other by small amounts if we would change this to a silt bit option builders would be incentivized to

beat on the high side and no other builders would know about the builders about the pizza photo builders this there was a lot of discussion on this github issue that's linked i can link it here again and the conclusion basically is that the seal bit auction is strictly superior with the downside it needs an additional signature by the validator

Danny Ryan: and and the tr and trusting the relay that they would not hand these out because it's not encrypted or anything

Chris Hager: yes i mean this would just allow the relay to only serve the bit to the proposer

so it would uh i suppose that really would implement it we for sure would implement it it would be superior for yeah affordable network um yeah but there's no guarantees but otherwise the realest have no way of only providing the bid to the proposers theoretically you could still drive relays if they

right be misbehaving

Danny Ryan: another way would be if nodes were pre-registered as to what validators they have with the relay such that the relay would only give it to those pre-registered nodes

rather than a more dynamic request the signature only says who this thing is for and then i have to know who the the counterparty is correct

uh i mean

Chris Hager: yes currently in the builders text there is just no signature on this request so basically we need to implement it this way and this would not give the really the opportunity to figure out if the request was coming from a proposal or from anyone else right so even like a white list would not help in this case they really couldn't distinguish necessarily because the relay is open to any proposer there is no white listing on

the release for the proposers so it needs to provide the header to anyone who asks i see mikhail you have

a handwrist yeah

Mikhail Kalinin: just wondering what about the argument that the girl stabbed just posted the chat and that wasn't the um comment to the issue about like if if there will be like a kind of sealed auction uh there will be a way for waters and layers to be bribed to provide this information so what do you think about it and yeah it doesn't that doesn't make sense to um i don't know to not making it

sealed and with respect to this um kind of vector

maybe steph you have an answer yeah

Stephane Gosselin: so maybe i have a few thoughts to contribute here um i think one of them is we should consider like the design space that opens up if we have sort of an arbitrary message signing method on consensus clients i don't know if that's been like considered before but something like a prefixed message signing for just authentication or maybe like we can experiment with this um sort of separately i do think that for

this question of leaking bids it's tricky um two things that come to mind to mention is just the way that things work um today with miners so miners do have asymmetric information they see all of the payloads that they receive from the flashbot system and the bids um and they are trusted not to sort of use that um and if we sort of make the bids private and um in a boost environment we would be sort of replicating that right we'd be trusting the validators not to publish the bids for their independent slots maybe that's better um but you know perhaps not fully robust since it can

still be sort of bribed to um to be used or they can use it themselves so there's still some advantage to like a large validator pool who's able to see bids from many different entities and then perhaps is able to beat it themselves um the final point to consider is like how does this fit with like future pbs design does a future pbs design explicitly require bids to be public um and if so like maybe you know that's just the way that we should go um but i think that's still very much so an open research question tldr is there a way to like decouple making changes the consensus client by just having a generic signing method

that allows to build this without necessarily committing to open payments or close payments

Danny Ryan: on the large validator pool example they such a an entity who is potentially also searching and as a validator is can always beat the bids right like that's i mean sorry they they always have the opportunity to use their own block so i don't know does this change it

Stephane Gosselin: um does it change it no it doesn't change like the ability of a single individual validator from

like being to put whatever they want in their block

Paul Hauner: in terms of an arbitrary message signing scheme um i think the challenge here is not how do we sign the data it's more about how do we add that into the flow of producing a block so i'm not sure that having an arbitrary signing scheme would help because you'd you need to make sure that the the med boost can trigger the request to get it signed and all that kind of stuff and that's probably the tricky thing

um yeah

Mikhail Kalinin: my name thoughts was like uh there is like um

several uh fields in this request right uh if i'm recalling correctly parent hash slot and pop key uh the proposer is pop key so there could be a signature or a structure in these fields and there's this signature maybe uh like uh yeah this message and the signature may be submitted to math boost uh and then math boost may use this um kind of like uh signature and data signed data structure to pull data from uh relay so cl should just probably sign it once in the beginning of slot uh or sorry when it knows what the head is because

of the parent hash oh and yeah that could work this way not sure if it's complicated or not

Terence Tsao: i guess one minor concern is validated privacy right if you just have one relay and everybody out there responding to that relay so that really could remap all the all the slots with the ipa address

Danny Ryan: that's likely the case already right

Chris Hager: that's already the case because you'll need to get the payload and submit the assigned block so this is a call that is a already mapped to the validator

all

Danny Ryan: right

um micah

so i think i'm missing something here who is signing something so the a builder builds a block sends it over to the relay the who's signing that the builder's new site the builder's already signed it right

Danny Ryan: well they're signing a header the header which is a bid

Chris Hager: exactly and here in question it would be a signature by the validator to allow the relay to know that this request actually comes from the validator only and

Micah Zoltu: oh i see example so the only the validators again get the next

bid but only the next validator can't get the next bit if not anyone can ask for it right yes exactly yeah so to answer danny's question earlier the a large pool can put whatever they want in their own blocks this allows that same large pool um to potentially i guess not okay um so yeah so my general feelings are that i'm not a fan of obscuring the problem like the fundamental problem here is that there is some number of entities out there who know what the set of bids are and those people have an advantage because they can um you know they can take out bid

i don't like the idea of saying of saying that we solve the problem by just narrowing the set of entities who are allowed to have that information it just means that it's now an unfair game so you turn a fair game of a bidding war into an unfair game where the only person who can participate in the bidding war is the relay and that feels like not the right solution to the problem like i understand like we want to not have any war but like we're not actually solving that we're just making it so only certain people can play and if you have like 10 relays let's say those 10 relays get to play no one else gets to play and so now the game is become a relay so you can get the um the flow and once you have the flow now you can participate in the video with

everybody else and if you don't have a relay you can't participate and so you're playing underhanded and so i appreciate the problem and the need for a solute potential need for the solution i don't think that giving relays privileged information is the right one

yeah

Danny Ryan: and the some sort of reputation on relays

Dankrad Feist: what what privilege information you mean you mean like the the actual blocks

Danny Ryan: seeing the bids

they see the bids so if you're

Dankrad Feist: but that's literally why we'll have free

layers so that they that they do that

also

Micah Zoltu: if you're a builder and you want to you want to submit the smallest bid possible and win right that's that's your goal because you get to keep the difference and so the if you can't see the bids but someone else can see the bids that means they're going to win more than you because they will be able to submit bids that are lower and so they're going to make more money and so the relays if we say only the relays can see the bids no one else can see the bids then as a builder the optimal strategy is to go become a relay because the relays win like in the long game the relays are the only ones who win and so builders all have

Dankrad Feist: the relays have a trusted role in the setup right we know that i mean this

just because right now we don't have proper pbs

Danny Ryan: correct this disincentivizes people trusting new relays because all of a sudden being a relay gives you an advantage so uh it's less likely that you're more willing to work with new relays

right

Dankrad Feist: but that doesn't seem like a relay is a trusted

role right we know that

Danny Ryan: it's also a matter of

Dankrad Feist: basically the builders trust with their flow and the um the validators trust that the

relay is published there um publish the blocks and do not withhold them

do the release currently

Micah Zoltu: in the current plan do the relay see the whole block or only the

bids right now you

Danny Ryan: see the whole block once a block is selected

Dankrad Feist: they have to because they they guarantee that the block becomes available

like but they don't otherwise it will see until selection

Chris Hager: no because they really also guarantees that the right fee is paid to the validity that really needs to simulate the builder bit and give certain guarantees to the proposer else builders could just claim whatever they want

Micah Zoltu: so it's not until full pbs that we actually um turn relays into

untrusted

Danny Ryan: correct

we don't need a relation anymore for pbs that will just be builders

right relays

Danny Ryan: relays serve as like essentially what the protocol can give you

yeah

Dankrad Feist: the current trusted intermediary that solves the absence of pbs

Micah Zoltu: so if i understand your argument here dank red you're basically saying that relays are already trusted very significantly and this doesn't change that in a significant way

it doesn't

Dankrad Feist: i mean we know that we don't like i mean this is not news to me i mean this is clear that we we we built this trust that roll into them um and the idea is that you can have that hopefully like trustworthy individuals organizations take on that role so that people actually believe like if you know

like flashbots does this or ether scan provides this or someone then they will actually like uh be trustworthy enough and if they aren't then like if someone can raise the suspicion that they

are

Danny Ryan: i guess the the question here for me is does the discussion of open verse close bids change drastically change the trust assumption that we're willing to put on the relay you know if if not then you know i think you it it does buy you something if it does then it doesn't

like i mean like honestly the just like if problem don't trust them to

do that they can just take uh even all the all the maybe that you extracted in your blog as a builder reassemble it and make it their own

Danny Ryan: right and thus the trust assumption here isn't changed

Micah Zoltu: i think we need to finish this conversation quickly because dank red is going to be too far away to hear slowly disappear just falling away into the distance

i wait oh wait am i is my microphone set up correctly maybe yeah you thought you're

Danny Ryan: using your headphones but you're really walking away from your computer

mike

Dankrad Feist: yes it seems so

Danny Ryan: um we can still hear you though barely um

i do want to point out in terms of i just want to point out potential design here and and how to get the signature i don't think it's necessarily a good idea but it is a design that we have not discussed before essentially when the there's a register kind of validator message which registers i think the fee recipient but other things can be put in there so you could actually register another key that's your kind of like mev boost application key and that key could sign non-consensus messages uh for authentication purposes um rather than having to go into the

validator client and go into you know a much more kind of privileged signing space on that validator key just tossing it out there

yeah

Chris Hager: that's actually a possible approach that could be reduced for other purposes and remove additional signing so i think i just want to point out one thing regarding the trust assumption so really it just changes the power or anti-transparency a little bit so if it's a sealed bit auction it gives the really and the validator additional especially misbehaving ones additional negotiating power because they can

then ask for bribes to reveal the current beats to close parties and on the other side it's probably leading to lower beats by the builders so the valley vehicles would conceivably receive less rewards less mb rewards

is

Micah Zoltu: so the offensive side correctly the concern with the escalating bids is just it's spammy right like if you have a thousand builders all building or even two and they're racing each other um can we address that similarly to how we

address um block gas escalation gas price escalation where like the replaced by fee where you the next bid needs to be substantially higher than the previous one by a percentage and so it hits exponential pretty quick and you basically have a finite number of bids that can actually show up for any given block and that would also encourage people to get in first because if the next bid has to beat yours by let's say 10 then you're no longer incentivized to be as strongly to be last right you want to be the first guy that bids you know nine percent less than what anyone else can afford

to pay

Chris Hager: yes that's also an option for

well-behaving release to implement of course there is nothing that can force this behavior on misbehaving release another thought

Danny Ryan: right so a misbehaving relay could offer more

Micah Zoltu: i think can uh it's more noticeable so like if you submit a bid that you know should have beaten the previous bid and it never shows up and this happens a couple times you notice it whereas if someone is if if a relay is stealing bid flow and they're you know outbidding people by just like a tiny

little bit that's easier to mask like the relay can just you know vary how much they outbid by and they all they win coincidentally you know 70 of the time um and so i feel like being more noticeable is valuable because proposals will stop giving to that relay if they detect it whereas we can't detect it and you don't know that you need to stop giving to the relay you're just like i'm losing a lot i don't know why

Dankrad Feist: but i mean as a validator i uh what's um what's the downside of like i mean basically i determine what i accept from the relay i could say oh i'm fine with ten percent increase i could say i wanted more granular one percent because then i get better bids right because

otherwise you might be leaving nine percent on the table so like doesn't this create just a race to the bottom where validators will just decrease that constant

um i think creature

Micah Zoltu: race to the bottom but in a way that is acceptable to all the parties involved including the spam so basically relays will you know allow the race down to the point where the spam is too much for them to handle then they'll just say hey we're not going to relay

right anything

Dankrad Feist: i guess the concern is that um like if you have a bigger pipe then you can handle more bits so like that so that's a downside for at home

validators that they say like [Music] they can't uh handle 0.1 increases whereas like um yeah professional operators can easily handle that and they don't care

Micah Zoltu: yeah that's that's fair i guess um the relay isn't doing any sort of filtering before like a a relay that is helpful to validators could do some of that

i mean three

Dankrad Feist: yeah it's true i mean why does the relay even need to send several bits that's a good question right why can't the relay simply

send one bit exactly at the cutoff point and say here this is it and just do all the

first

Micah Zoltu: you know one bit every second maybe

Dankrad Feist: i mean why does it need it why do you need another

bit like this but

Micah Zoltu: assume there's value in getting one early just so you have a block prepared and you're ready right okay last absolute second

Dankrad Feist: sure but like there's no i i see little value in a continuous you could say you can configure two time points with your relay you say like right i want one two seconds before and 100 milliseconds before but there doesn't seem to be much value

in a continuous flow

Danny Ryan: is that how it's designed a continuous flow and then mev boost filters rather than the relay

pre-filter oh it's that it's relay filtering a continuous flow of incoming blocks i think

Danny Ryan: and then only giving the highest bid to mev

boost yes at the point when it asks yeah

Danny Ryan: yeah okay so that's this isn't an issue the continuous stream bombarding a hobbyist validator is not an issue

Micah Zoltu: it doesn't mean you can't have a hobby obviously relay

Chris Hager: absolutely i mean you also need to simulate the debates and like that's a lot of infrastructure to run and have the data availability else it gets published and punished so running really really hard

Micah Zoltu: yeah and i think that having the design in in place to allow relays to compete on that um like how much um they're allowed the bid increment i think is good because it encourages relays to be beefier and stronger and better and faster etc because it allows them to reduce that a bit increment which gets more validators presumably listening to them right

Chris Hager: yes

Micah Zoltu: um but put in place the infrastructure to allow competition on that front

Chris Hager: i mean i think that the really utilization and performance is not the main point necessarily it's more like the auction structure and how and the value of the bits because we expect to just have enough caching on the real list to be able to handle bombardment by entities asking for bits i wonder if it's a consideration to be closely aligned with future pbs designs where beats would necessarily be somewhat public

Micah Zoltu: yeah i definitely would rather would rather not um you know do a certain auction now and then change that once we have pbs if we don't have to like in terms of design

Danny Ryan: bypasses and get make privileged connections with large validators to send them directly

correct yeah say that you don't think you're dead

Danny Ryan: they essentially act as a relay to privileged parties

Stephane Gosselin: yeah i think it's somewhat inevitable

that even if we have um like some public relays that there will be private connections directly to large validators and the question is should this be the norm or the exception

Danny Ryan: so it does look like there's a lively discussion going on in this issue um and i think there's now a number of people that are more informed and we've kind of explored the design a bit more can we take this to the issue i don't think we're necessarily going to come to a conclusion on this call

i

Chris Hager: personally am happy with the outcome it was a really interesting discussion and it's good to have uh everyone thinking a little bit about the implications and i think it's all right to continue the conversation on the other channels now

Micah Zoltu: discord room where this discussion is happening

Chris Hager: i think the most closely would be on the eve rnd the block construction channel okay and the the issue is this one here which already has a bunch of comments

Danny Ryan: cool thank you

Chris Hager: thanks everyone

yeah i

Danny Ryan: appreciate that um

[Music] since we're on the topic is there any any other mev boost updates or discussion points for this group

just let me add a pleased test on sepolia our bill and relay is available okay yeah

Enrico Del Fante: i have a question around this uh because uh is the um activation topic so when when we should start working i should start requesting the the builder so there is this discussion around waiting 10

10 or 16 epochs after the first execution finalization and show what we should do and with this regard and for sepolia so i'm thinking that on the cl side we should just relay on the 204 response the the relayer will give us if we are asking before this delay and actually do nothing what what do you think

i think we can configure our reliance polio to not produce blocks for 16 ethers

that should be fine and we will return 205.

Enrico Del Fante: yeah perfect

Danny Ryan: okay uh other mev boosts discussion points great um after he left a comment i do not believe afri is here but i'll quickly go through it a couple of conveniences as aphro said

that we should be reviewing as we move towards the merge pulling chain configurations from github uh the repositories were planned to serve as a reference um and there's you know security implications of pulling specs from third-party services which are hard to gauge in fact we had kind of a weird github issue on a repository name change that did lead to some potential issues that were not exploited and are now patched but uh so that is a recommendation from afri we can discuss that recommendation if anybody feels otherwise

Dustin Brody: well so

what i would be is the proposal to remove them simply from github or is the proposal to not

i mean

Danny Ryan: he's suggesting not dynamically pull them in builds and instead they're used as a reference they're used as something you can integrate into your client but not to every time you build your client have to have that dependency i think is the suggestion

Dustin Brody: so this is my working assumption as one of the people who's been has updated these from time to time um is that nobody just blindly pulls it that they have some kind of check on whether it's sort of

pinning um some commit whether it's you know with get some modules with some other method um nobody's at least should be blindly trusting people to begin with so i'm not sure i understand the concern

Danny Ryan: then i'm not sure i understand how you're using the dynamic pull

Dustin Brody: well when you say dynamic because what i've seen offers github issues i don't know if there's npr's on this yet um they are they are not limited in scope to simply dynamic pulls as i understand that phrase um they they are they affect the repo in any use of the

repo so when you say dynamic pull this is not necessarily run curl or wget at build time per se and just accept whatever random garbage github responds with

Danny Ryan: okay

this is there there's a specific commit in in say the merged test nets or some equipment that you would point to right

Dustin Brody: yes and to me that is and it's certainly possible to pin that down further the usual methods shaw patches whatever but the the point is i don't see how and and there's certainly a risk of centralization um generically that github presents with any

development approach

um but that's yeah

Danny Ryan: i suppose if github's honoring a hash of a commit then there's not much an attacker can do

Dustin Brody: right well what i would suggest is an open new attack surface um if there are other reasons to do this and i know some of his um issues i have mentioned or alluded to this for example like just organizational issues so maybe you know sepolia or prodder while there's there's there are there's a sorry there's a proposal to say well maybe rather than have these sort of

el side on one repo and the cl config on the other non on another repo um to put them in the same repo i mean that kind of thing is a little different to me but in terms of just pulling them from github altogether or discouraging even this kind of pinned um pull as part of a build i don't see the value in that

Danny Ryan: yeah i mean i i understand the argument i something that we did see was a rename of a repo and then someone and and github honors redirects to the previous name or sorry organization the previous organization

uh unless somebody registers the new organization which is you know clearly seems like a major issue with github but i think his abstract security implications of pulling specs from third-party services are hard to gauge probably you know when you start thinking about some of these weirder edge cases and the dependency on github that's probably the concern i'm not making a claim one way or the other on uh the suggestions of avery but i just wanted to highlight them because he did put them into the issue

Dustin Brody: sure and and i would acknowledge that that this is sort of an odd behavior perhaps on the part of github um exploitable for for sure

Danny Ryan: um yeah especially if you're pointing to

master right rather than maybe

append

Dustin Brody: yes well but that's the other that's the other part is that if you're not if you're pointing to a some specific commit then it seems a little irrelevant because it's the worst case is maybe they can move it but then the bill should fail that there's no yeah either either the committee exists or doesn't i mean more broadly i think there is an issue here but it's so it's kind of a weirdly specific um fallout manifestation of what would be potentially borderline catastrophic i i mean if to pin this on the it's just simply network

configs i mean there's so much else that people depend on github for in terms of code and

Danny Ryan: the dependencies

Dustin Brody: it seems like an odd target to me

but that's

Danny Ryan: okay i would say when doing so being careful is important um just given some of the weirdness that we've seen also but i i yeah i yeah i'm not laying down the hammer on this one

yeah

Micah Zoltu: i think they could be there primary takeaway is don't use master use a specific hash i think as long as it breaks doing that we're mostly

protected

Danny Ryan: right barring some

deeper github bug or github takeover problem

Micah Zoltu: even that so if you're using git it will evaluate the hashes for you so you can't actually be screwed github unless you're using just like uh like raw dot github user content whatever so i guess two things don't use master and use git don't use curl

Danny Ryan: okay um and the other thing was checkpoint sync from infira uh he suggests that we should be moving towards p2p state sync instead of checkpoint sync and providing alternatives or you know coming up with a feasible

p2p protocol uh and ensuring that users can provide their own checkpoints um i definitely i respond to this you know it is requisite i think we all know to get out of band information to perform sync um are there a checkpoint route or full checkpoint state um but if you've already had to find the route from somewhere you trust maybe you might as well get the state and not add the pdp complexity i think that's what we're kind of all operating on but we are also probably relying pretty heavily on infuria as a single source of information rather than some sort of multi-party multi-authority source of information and i think we can and probably should do better but i also believe that this group is

still moderately biased towards not adding state retrieval inside of the p2p i guess that's more response to avery than to y'all but uh any questions or any discussion points on this

Jacek Sieka: uh i just wanted to briefly go back to the previous one uh about github one thing that we haven't specified is the format of those repositories really we haven't documented what should be in there we have a couple of things in there we have like a genesis state the boot nodes um we have a deposit contract miracle tree hash thing

that helps avoid some deposit downloads like there's a bunch of stuff and now we're adding s like s1 to the mix as well and i think there are incompatibilities between clients there as well or at least there used to be so maybe it's worth an effort to actually document what's in that repo and then and sort of even more decreases um the risk of having it in any one particular location because at least we're like agreed on what should be in there and then that also helps people launch their own tests and stuff um

with all clients supporting the same thing

Danny Ryan: yeah i don't disagree um is there confusion or disparity in how we specify the information here or is it just not is we usually do it in the same way but it's just not a standard

i think

Jacek Sieka: there's two formats for boot nodes and two formats for eth1 genesis if i remember it right like vaguely from in drop events

i think there's even more it's on

genesis format okay there you go i mean these so the big ones are be so uh i never met in geth but bisou is also a bit different than guest

Jacek Sieka: yeah so like if we move this into one repo that's uh it's like an obvious good thing to do in the same

goal

Marius van der Wijden: the problem is that we have like the different clients have different use cases and different things so for for gas it's like we only need to support the hard forks basically in our in our genesis because we're only following uh

main chain may not but for other clients they want to have a more granular approach to the to the genesis block basically they want to enable or disable eaps one by one and that's why they have a different genesis format and and they need it for their use cases that they have next to

with your minute

Danny Ryan: i would presume the

more configurable format is convert is has all the information to be converted into the guth format just for my understanding

Marius van der Wijden: kind of probably but we don't have this eip2 right to hard fork mapping anywhere in the code

okay

Danny Ryan: so there are potentially some issues in trying to unify

nonetheless if somebody wants to take the charge by all means

Jacek Sieka: um cool to the point about states um i think there's two things to point out like checkpoint sync in itself isn't inherently more or less secure than thinking from genesis right um unless you trust your source um but i think in general we're moving towards this world where you need to have one point of reference like you know tofu in ssh and then where we get states from is a bit of an open

problem what's nice about this particular problem is that once you have a hash it's very easy to verify the data you're getting um and i mean uh it's just dumb data at that point so i think one reason why we haven't really worked very hard to solve this is because we envision a fairly easy solution once like should this ever become a real problem

Danny Ryan: yeah i agree nonetheless if we don't create some sort of standard encourage encourage a bit more adoption we will continue to rely

on a single provider which you know you could definitely argue the damage that such a provider can do is actually very limited but still there's damage that can't be done

oh

Jacek Sieka: i could use my usual airfile plug here

Danny Ryan: what is the state of the air file

Jacek Sieka: um we actually have community members running servers that provide error files

um we can also use them in nimbus instead of um database so the way that we're using them right now is that when we have multiple uh what's called multiple beacon nodes they can share you know the block storage for providing blocks via b2b using error files so we have something like i think 12 beaker nodes running on a server and it uses a space of one so i would say the format is fairly good fairly stable i'd encourage others to take a look at it instead it's

possible to use um i'm i'm like always like one week away from riding in the eip actually and then something else pops up

all right

Danny Ryan: anything else on afri's checkpoint sync comments and if he joins us in a call or two we can discuss more with him okay

next item on the agenda open discussion spec research anything else okay thank you uh happy sepolia happy shadow fork happy great glacier talk to you soon

good night paul thanks jerome [Music]

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

you

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