AllCoreDevs - Testing CL Breakout #101

everytime I relog I dox myself. Luca's PR LGTM

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Reacted to "everytime I relog I ..." with 😂

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Replying to "everytime I relog I ..." if someone wouldn’t recognize his name or voice it is potuz 😂

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Reacted to "if someone wouldn’t recognize his name or voice it is potuz 😂" with 👁️

Reacted to "everytime I relog I dox myself. Luca's PR LGTM" with 😂

Reacted to "Screenshot2026_10_19_165927.jpg" with 😄

Reacted to "Screenshot2026_10_19_165927.jpg" with 😄

Reacted to "Screenshot2026_10_19_165927.jpg" with 😂

Thanks!

@Nico Flaig I still don't understand, today a trusted builder can still give you a huge value and grieve other builders doesn't it?

can someone from lighthouse comment? seems like Mark was very strongly against this

Replying to "can someone from lighthouse comment? seems like Mark was very strongly against this" Will talk to him

Replying to "@Nico Flaig I still ..." no, we can check their balance on the beacon node and if they can't cover it, we reject it

Replying to "@Nico Flaig I still ..." but a trusted value

if we leave prs open till sfi, we gonna have a hard time targeting releases, whats the way forward?

oh well "there was some contentious discussion" sounds like a good reason

Replying to "@Nico Flaig I still ..." ah yeah but for trusted it, well trusted anyways

Replying to "@Nico Flaig I still ..." but the vero approach even let's trustless builder grief other builders

Replying to "@Nico Flaig I still ..." so then why not have the endpoint receive a list of bids

Replying to "@Nico Flaig I still ..." the beacon can pick the first one it thinks its valid

Replying to "@Nico Flaig I still ..." maybe that's a soluiton for it

Replying to "@Nico Flaig I still ..." at least it should cover your fear in allowing the VC contacting untrusted builders

Replying to "@Nico Flaig I still ..." cc @Luca | Vero has thought about that already probably

Replying to "@Nico Flaig I still ..." it’s a possibility I guess

Replying to "@Nico Flaig I still ..." I haven’t considered sending a list

what are reasons not to do it?

Replying to "@Nico Flaig I still ..." The VC could check builder balance + signature but since it doesn’t have access to the full at-proposal state it’s not going to be 100% correct

thanks!

Reacted to "Will talk to him" with 👍

but then shouldn’t all the other CFI-ed EIPs be on feature branches too?

with feature eip number triggers too

yeah and I think we can SFI immediately some of these

Yes agreed.

and this applies to the other two smaller EIPs too? 8365 and 8015?

no no no, the last part of Francesco is wrong

Could the endpoint receive a trusted and a trustless bid? The BN could pick the best between the two (including self-built) or flag out the trusted one if it thinks its not valid.

I am just saying, if you ask people in this call there are probably many different understandings of how it works now

Anyway, I don’t care about what the process is. I just care that it’s clear

Reacted to "Anyway, I don’t care about what the process is. I just care that it’s clear" with ➕

Reacted to "Anyway, I don’t care about what the process is. I just care that it’s clear" with ➕

Reacted to "Anyway, I don’t care..." with 👍

Reacted to "Anyway, I don’t care..." with ➕

nah please not we have it on our trunk

Reacted to "Anyway, I don’t care about what the process is. I just care that it’s clear" with 👍

Reacted to "Anyway, I don’t care..." with 👍

Yes. Lets just correct the process going forward and keep the devnet as is

feel like we are spending a lot of time on “the process” lol

Reacted to "feel like we are spending a lot of time on “the process” lol" with 👍

can we discuss some changes that I’d like to see to some eips?

Replying to "can we discuss some ..." what changes?

https://github.com/ethereum/consensus-specs/pull/5744

Replying to "can we discuss some ..." *process changes? 😆

Should we make ACDT 90 min going forward. It feels like the recent meetings have been very full

I thought Stokes asked everyone to take a look at this change and discuss in next acdc?

Reacted to "*process changes? 😆" with 😂

Replying to "@Nico Flaig I still ..." Well, the BN already can replace the VC-supplied bid, at will basically, the PR explicitly allows a lot of freedom on the BN side. And the VC would have no way to 100% know whether the trustless builder is able to cover the bid at the time of proposal either. So I don’t believe that solves it?

Haven’t read through it, but I also personally don’t like the burning etc stuff 🤷

I think it's fine too, but they'll have a full fork anyway to know that there shouldn't be 0x00 vals...

Maybe we could use next ACDC for this discussion

Replying to "@Nico Flaig I still ..." yeah but providing the list would at least allow the VC to contact untrusted builders

Replying to "@Nico Flaig I still ..." Which is Nico's problem

Reacted to "yeah but providing t..." with 👍

can we make this meeting 90' and stop it earlier when there's no issues?

Reacted to "yeah but providing t..." with 👍

I agree

sure

Im here for you Barnabas if you want to discuss

https://github.com/ethereum/EIPs/pull/12513

Replying to "@Nico Flaig I still ..." I’m just thinking this could get a bit impractical if the VC has 100 bids for its proposal slot for example, not sure this list really solves things

Reacted to "yeah but providing the list would at least allow the VC to contact untrusted builders" with 👍

I don’t think we should make a feature burn eth that was previously a valid operation ever.

sorting and sanity-validating 100 bids (to the first valid one) shouldn't be a problem for beacon node?

so fix launchpad, if one doesn't want that?

Replying to "@Nico Flaig I still ..." shouldn’t be a problem, no

Yeah I was misreading the call data for my recent top-up via launchpad 🤦

Reacted to "shouldn’t be a probl..." with 👍

Replying to "@Nico Flaig I still ..." no it shouldn't unless the operator is contacting directly builders that are all malicious. These are direct connection builders, they can be blacklisted immediately and never again be contacted

agree with Barnabas in principle, so if spec change is minimal seems good to do

Replying to "@Nico Flaig I still ..." on top of the blacklisting, I think this kind of griefing attack would be discovered extremely quickly and no one would connect to such a builder right?

so what does "deprecate" mean?

I propose we agree to SFI this on Thursday's call so that this PR can be open targetted to Heze, we then can argue on the spec repo which version to merge, but at least it's clear that one of the two options is targeting Heze.

isn't that the point of "hardforks"? that these things change?

Replying to "I propose we agree t..." 8365 is already merged into the spec?

Replying to "I propose we agree t..." yeah we can change it, but the point is that the EIP should be SFId

Replying to "I propose we agree t..." we usually sfi if the EIP is tested tho no?

Replying to "I propose we agree t..." we don’t have a devnet where its being tested

Replying to "I propose we agree t..." so why are we sfi it?

Replying to "@Nico Flaig I still ..." the problem is that in gloas you don't have to trust builders at all or detect anything, the protocol enforces everything, there is 0 trust assumptions and as a operator there is incentive to connect to as many builders as possible

https://github.com/ethereum/EIPs/pull/12533

Replying to "@Nico Flaig I still ..." I’ve updated the PR, added the Experimental tag

basically change the guard to process_deposit_request

Replying to "@Nico Flaig I still ..." I sympathize with your point and agree it would be great to incentivize validators to connect to as many direct builders as possible, trustlessly. I’ll try to think about this some more.

Replying to "@Nico Flaig I still ..." > no one would connect to such a builder right? That's what I meant about blacklisting

Yeah if people think it's important actually remove the 0x00 handling, it has to be ... removed. If not, whatever

Replying to "@Nico Flaig I still ..." Assuming the VC keeps track of builder balances, would this be solved? E.g. if fetches builder balances the slot before proposal or something like that, to reduce the possibility of this griefing attack. Probably can’t get the probability all the way down to 0 on the VC side.

Replying to "@Nico Flaig I still ..." (Could be a lot of data to fetch though, probably not ideal)