AllCoreDevs — Consensus #177

gm

gm

Reacted to "gm" with ❤️

@Justin Florentine (Besu) its a quiet morning?

GM

Reacted to "gm" with 🌞

Gm

gm

gm ☀️

gm

Gm, 1 more min

https://github.com/ethereum/pm/issues/1990

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

How much data duplication are we talking about per slot?

the max can be large

we can remove them from the envelope though but requires engine api changes

Replying to "How much data duplic..." Theoretically, ~1.5 MiB of requests. With today’s gas limit, ~500 KiB. That would require a 2500 batched deposits.

Replying to "How much data duplic..." But the average case is way, way smaller. IIRC.

I don’t think we can lower the deposit request limit, because deposits are not queued. Could be wrong though.

I think we can Justin

Reacted to "I think we can Justi..." with 👀

Replying to "I think we can Justi..." Oh okay! Nice.

Replying to "How much data duplic..." would it not be just for that one slot? How likely that we gonna get 2.5k deposits every slot?

Replying to "How much data duplic..." Yup, it’s not sustainable.

Replying to "How much data duplic..." whats the duplicated data on a slot where there are no deposits?

Sounds like regardless we need to make the limits consistent with each other

The hope is to continue increasing the gas limit over time

Blocks are also often built by builders and they may not respect this particular limit if the block with deposits is more profitable

Instead of putting an arbitrary limit on the EL side, we should just price it such that, with a given gas limit, it stays in a range the CL is fine with.

(They often don’t use vanilla clients to build blocks)

Reacted to "Instead of putting an arbitrary limit on the EL side, we should just price it such that, with a given gas limit, it stays in a range the CL is fine with." with 👍

Replying to "Blocks are also ofte..." I am really not sure how profitable execution requests are for builders.

Replying to "@Justin Florentine (..." it is. the vibes are off.

Reacted to "it is. the vibes are off." with ❤️

Replying to "Blocks are also ofte..." Whether they have incentives to pack the payload completely at the cost of slowing down their payload broadcast time

Reacted to "it is. the vibes are..." with ❤️

Reacted to it is. the vibes are... with "❤️"

Reacted to "it is. the vibes are..." with ❤️

Replying to "Blocks are also ofte..." why would it slow down broadcast time?

Replying to "Blocks are also ofte..." I mean if they pack all the execution requests, their payload size gets bigger which is not the best for broadcast

Replying to "Blocks are also ofte..." If they fill up the execution requests I mean*

Replying to "Blocks are also ofte..." I ll check rbuilder as to see how they pack their execution requests

gossip is never a problem, RPC is

I’m fine with that

5094 solves a beacon api issue basically

@Barnabas regaridng engin api changes, we need to do that for BALs anyways, so maybe can revisit that later?

edge cases always involve reorgs and proposing on top of a previous payload

Replying to "@Barnabas regaridng ..." how big of a change is it?

Reacted to "edge cases always in..." with 👍

Replying to "@Barnabas regaridng ..." thats actually true, kinda forgot about it

Replying to "@Barnabas regaridng ..." add a field to new_payload response

We should also discuss: https://github.com/ethereum/consensus-specs/pull/5067

If too hard: the plan B would be to lower the limits in the way Nico explained (might be worth doing regardless)

Reacted to "If too hard: the plan B would be to lower the limits in the way Nico explained (might be worth doing regardless)" with 👍

lowering the limits is not possible without involving extra checks on the EL

Yeah we intend to rebase & get this merged before the release is made. Unsure of its current status.

I think he is waiting for 5094 as it will introduce some merge conflicts.

I'm rebasing it atm

Yes

Reacted to "I'm rebasing it atm" with 👍

Replying to "If too hard: the pla..." also worth noting that the current limit breaks at 194M gas limit, and ELs could theoretically be stuck trying to build a payload that will never be accepted by CLs (kinda similar to the 10MB gossip limit situation)

It does change

is_parent_block_full goes away in 5094

Reacted to "is_parent_block_full goes away in 5094" with 👍

Replying to "edge cases always involve reorgs and proposing on top of a previous payload" This is the risk, but the problem is reduced to “the parent MUST be available”, so if clients are decently designed, there shouldn’t edge case handling in code

Replying to "edge cases always in..." well, designing decently a client to deal with late reorgs is not trivial at all

@Potuz currently, the plan is make an alpha.5 release without BAL and follow up this time next week with alpha.6 with BAL.

Replying to "edge cases always in..." and this will add complexity

why do the intermediate release of epbs-devnet-2?

https://github.com/ethereum/pm/issues/1990#issuecomment-4260587912

Replying to "If too hard: the plan B would be to lower the limits in the way Nico explained (might be worth doing regardless)" Ideally we audit all these interdependent limit layers and turn them into functions instead of hardcoded values that (a) don’t align, and (b) drift over time

Reacted to "Ideally we audit all..." with 👍

Reacted to "Ideally we audit all..." with 👍

Replying to "why do the intermedi..." Just to keep things compartmentalized. Open to putting everything into a single release. Whatever clients want.

I also think it's easier to do BAL

with ePBS on our side

would rather encounter go into interop knowing these potential issues are happening before interop

yes

exactly

Stokes saying the words “The Merge” brings up memories from 6y ago 😅

Reacted to "Stokes saying the wo..." with 😄

Reacted to "Stokes saying the words “The Merge” brings up memories from 6y ago 😅" with ❤️

Replying to "Stokes saying the wo..." I had the same thought lol

What do other clients think? Do we prefer a single release?

bal devnets have other cl changes too like slotnum

Reacted to "I had the same thought lol" with ❤️

Reacted to "Stokes saying the wo..." with ❤️

Replying to "bal devnets have o..." this is the problem, ultimately, this is why to move to merged asap

Replying to "What do other client..." nimbus + prysm obviously want to skip epbs devnet 2

We also have to consider the testing velocity that is impacted after the merge for each stream

Replying to "What do other client..." it's my preference, but it doesn't matter much

Replying to "What do other client..." Their concerns are valid.

no strong preference at lighthouse one devnet makes sense

I would rather go to interop with kurtosis ready and confidence in the code and then on Monday, we can spin up devnet together with debugging and sorting out issues easily since everyone is there

yeah my preference is not strong either, just think we're wasting time not merging the trivial changes from BAL

Reacted to "yeah my preference i..." with 👍

Reacted to "yeah my preference..." with 👍

Reacted to "I would rather go ..." with 👍

Reacted to "I would rather go to..." with 👍

Replying to "yeah my preference i..." it's a good point, I'm trying to think of a reason not to do it 🤔

Sounds good to me.

are we good with this @terence ?

Replying to "are we good with thi..." yes

Reacted to "yes" with 👍

https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip7928

I think it’s this, right?

https://notes.ethereum.org/@ethpandaops/bal-devnet-3#Test-Releases

also here

https://github.com/ethereum/consensus-specs/releases/tag/v1.6.1

oh this changes the payloadtype right :(

Ya but Im looking for a PR against gloas.. not an existing features spec : )

Reacted to "Ya but Im looking fo..." with 👍

Reacted to "Ya but Im looking fo..." with 👍

Reacted to "Ya but Im looking fo..." with 👍

Replying to "Ya but Im looking fo..." Ah, yeah no PR yet. But the PR would just merge this into Gloas.

Which is the bal xyz link?

Replying to "Ya but Im looking fo..." I will work on this today. Should be simple.

https://blockaccesslist.xyz/

ATM for interop id like us to just focus on a stable Glamsterdam devnet + breaking it rather than adding more features

the header is gone in Gloas

We haven’t broken things at all yet

Reacted to "https://blockaccessl..." with 🙏

the root would need to be removed right?

Replying to "Ya but Im looking fo..." Thanks! I think you might want to merge 5094 first otherwise there will be conflicts.. up to you!

Replying to "Ya but Im looking fo..." 100% 🙂

Replying to "Which is the bal xyz..." Blockaccesslist.xyz

It'd be better to have the actual PR @Toni Wahrstätter, there are nonsense objects there like the execution header. Do you want the root in the bid or not?

I assume not

Replying to "It'd be better to ha..." Let me check

+1 for staking EIPs as stretch goal

the block changes are weird

does the header need to be cached in the beacon state or not?

so do I assume that there are zero changes on payload processing?

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

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

This was the PR but would have to check if somwthing changed since then

it's fine

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

Can I take care of opening the CL spec PR @Toni Wahrstätter

?

this one seems wrong to me

are we allowed to ship partials ahead of glamsterdam?

This one seemed wrong? https://github.com/ethereum/consensus-specs/pull/4526

Replying to "are we allowed to sh..." this was mostly a joke

Reacted to "this was mostly a jo..." with 😄

Reacted to "this was mostly a joke" with 😄

Replying to "this one seems wrong..." To put it differently, it's outdated. Gloas spec has changed since then.

Reacted to "this was mostly a jo..." with 😄

Reacted to "this was mostly a ..." with 😄

Replying to "this one seems wrong..." not that, the changes on the feature are wrong

Replying to "https://blockaccessl..." Bal CL changes are just a new field (block_access_list) in the payload (with all the consequences with data structures and engine API)?

Replying to "are we allowed to ship partials ahead of glamsterdam?" Partial messages? Yes that’s the idea :-)

Replying to "this one seems wrong..." Such as?

Reacted to "Partial messages? Ye..." with 👍

Replying to "https://blockaccessl..." it's just the payload change, nothing else changes, no state and no processing changes

Replying to "this one seems wrong..." there should not be any state and processing changes

Reacted to "it's just the payloa..." with 👍

Ah here’s the SLOTNUM consensus-specs PR: https://github.com/ethereum/consensus-specs/pull/4840

Nice one to have

Replying to "this one seems wrong..." Feel free to go for it @Potuz , if you want, I can also do it but if you take the shot

not to include 8045 or not to include 11443

Replying to "this one seems wrong..." Are you referring to ExecutionPayloadHeader-related changes? If so, I think that's what I meant by outdated.

Replying to "this one seems wrong..." https://github.com/sigp/lighthouse/commit/a17c447680d655d70f4230f2603f6ad7182f943a https://github.com/sigp/lighthouse/commit/47094d592c252363911e82ec3c68ac8f4ab05a9d https://github.com/sigp/lighthouse/commit/658163cfdeeca00a4cd3ff2c36c2c11ef8b12d61 these are the main changes LH made to support BAL

Replying to "not to include 8045 ..." 11443 if I’m following you correctly

Replying to "not to include 8045 ..." Exactly when we include 8045 is another question

Yeah it's because that PR was made before we had Gloas in master. It's just outdated artifact.

I think we should do that to be consistent

Replying to "not to include 8045 ..." I was just saying we can touch on 11443 at interop

Replying to "@Barnabas regaridng ..." @Potuz this

Replying to "@Barnabas regaridng ..." yes, the API changes, that's not my concern :)

This makes sense to me, but can we aim this as a post-interop optimization?

🚢

Reacted to "🚢" with 🚢

lets aim to 5094 now and optimize later

@Nico Flaig if you do that please do it independent of 5094

One more small thing. Are we okay with this change by Etan? https://github.com/ethereum/consensus-specs/pull/5113

so that we can merge 5094 independent of that

Reacted to "One more small thing..." with 👍

Replying to "One more small thing..." Good with us. It’s easy

Reacted to "One more small thi..." with 👍

Replying to "One more small thing..." trivial for us

Replying to "@Nico Flaig if you d..." yes, definitely should be separate

Replying to "One more small thing..." We can yes

Reacted to "yes, definitely shou..." with 👍

Reacted to "lets aim to 5094 now..." with 👍

Replying to "One more small thing..." ppl use the approve button on github 😂

Reacted to "ppl use the approve ..." with 🔥

Reacted to "ppl use the approv..." with 😄

Reacted to "ppl use the approve ..." with 🧠

Reacted to "ppl use the approve ..." with 😄

Reacted to "ppl use the approve ..." with 😄

Reacted to "ppl use the approv..." with 🧠

Reacted to "lets aim to 5094 now..." with 👍

Reacted to "ppl use the approve ..." with 😄

Reacted to "ppl use the approve button on github 😂" with 😄

we had a draft PR a while ago I think

@Oisin Kyne can you share the link of your slides?

Replying to "@Oisin Kyne can you ..." https://docs.google.com/presentation/d/1hbkdjHsP_2rTc0zTgXLBf3thYv9FHEcNurWiZKnR6c8/edit?slide=id.p34#slide=id.p34

Reacted to "Stokes saying the ..." with ❤️

https://eips.ethereum.org/EIPS/eip-8205

Reacted to "https://docs.google.com/presentation/d/1hbkdjHsP_2rTc0zTgXLBf3thYv9FHEcNurWiZKnR6c8/edit?slide=id.p34#slide=id.p34" with 👍

@Oisin Kyne we had this PR for EIP-7716 https://github.com/ChainSafe/lodestar/pull/6851

@Toni Wahrstätter I think this is all that's needed https://github.com/ethereum/consensus-specs/pull/5117

I'll fix Heze/etc. if that's fine, I don't think you want BALs ont he Bid

Reacted to "I'll fix Heze/etc. i..." with 👍

8205: IMO Overcomplicating the protocol for little benefit.

https://eips.ethereum.org/EIPS/eip-8205

Replying to "8205: IMO Overcompli..." I think this is a problem staking pools face, FWIW

Replying to "8205: IMO Overcompli..." It feels like it could be solved on the app side tho?

Replying to "8205: IMO Overcompli..." Yeah I have the same question

Replying to "@Oisin Kyne we had t..." 233 line diff, super encouraging! 😄

Replying to "8205: IMO Overcompli..." Is the idea to go from having to do 2tx to doing 1tx?

most of it is fork boilerplate code, the real diff is ~100 lines

Replying to "8205: IMO Overcompli..." you would still need to do 2 txs, one with pre-registration, followed by the actual sum of eth

Replying to "8205: IMO Overcompli..." like how is it different than just doing 1eth deposit followed by your actual deposit?

Reacted to "like how is it different than just doing 1eth deposit followed by your actual deposit?" with 👀

Reacted to "most of it is fork b..." with 🥳

Spec changes so far: https://github.com/ethereum/execution-specs/pull/2697 Keri & I are working on getting the tests done currently!

Reacted to "Spec changes so fa..." with 🔥

Reacted to "Spec changes so far:..." with 🔥

Reacted to "Spec changes so fa..." with 🔥

Unrelated heads up: native AA breakout occurring next Wednesday, 15:00 UTC. Agenda WIP: https://github.com/ethereum/pm/issues/2018

Reacted to Spec changes so far:... with "🔥"

Opus 4.7 is out, so we can ship Glamsterdam to mainnet during Svalbard

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

Reacted to "Opus 4.7 is out, s..." with 🔥

Reacted to "Opus 4.7 is out, so ..." with 🔥

Reacted to "Opus 4.7 is out, so we can ship Glamsterdam to mainnet during Svalbard" with 🔥

we still have 13 mins so lets do a live review?

Reacted to "Opus 4.7 is out, so ..." with 🔥

Reacted to Opus 4.7 is out, so ... with "🚀"

Reacted to "Opus 4.7 is out, so ..." with 🔥

Reacted to "we still have 13 min..." with 😄

Replying to "Opus 4.7 is out, s..." We got 4.6 back!! Woo

Reacted to "Opus 4.7 is out, so ..." with 🔥

Reacted to "Opus 4.7 is out, so ..." with 🚀

Reacted to "Opus 4.7 is out, so we can ship Glamsterdam to mainnet during Svalbard" with 🔥

Reacted to "Opus 4.7 is out, s..." with 🔥

Reacted to "Opus 4.7 is out, s..." with 🚀

Reacted to "We got 4.6 back!! ..." with 😂

Reacted to "Opus 4.7 is out, so ..." with 🔥

Replying to "Opus 4.7 is out, so we can ship Glamsterdam to mainnet during Svalbard" Opus models like macOS. Always be one version behind

Reacted to "Opus 4.7 is out, so ..." with 🔥

Reacted to "we still have 13 m..." with 😄