AllCoreDevs - Testing #091

gm gm!!

Gm!

gm

gm gn

Agenda: https://github.com/ethereum/pm/issues/2181

Reacted to "Agenda: https://github.com/ethereum/pm/issues/2181" with ❤️

Reacted to "Agenda: https://github.com/ethereum/pm/issues/2181" with ❤️

Reacted to "Agenda: https://github.com/ethereum/pm/issues/2181" with ❤️

fixed

Should be fixed

Reacted to "fixed" with 🚀

Reacted to "fixed" with 🚀

(Tested fix on like 4 nodes today when swapping back from tysm)

lighthouse-nimbusel seems to have struggled from toni’s attack

Reacted to "fixed" with 🚀

What’s Toni’s attacK

Reacted to "fixed" with 🚀

Reacted to "What’s Toni’s attacK" with 🥷

Reacted to "What’s Toni’s at..." with 🥷

Reacted to "What’s Toni’s attacK" with 🥷

Reacted to "What’s Toni’s attacK" with 🥷

Great attack Toni 😃👍

Heeft gereageerd op "What’s Toni’s at..." met 🥷

Reacted to "What’s Toni’s at..." with 🥷

Se ha reaccionado a "What’s Toni’s at..." con 🥷

Reacted to "What’s Toni’s attacK" with 🥷

Reacted to "What’s Toni’s attacK" with 🥷

Is there a way how we can add this to benchmarks? I think I understand that this is a CL+EL benchmark, so not a pure EL one (cannot add this to execution-specs benchmarks / benchmarkoor)?

CLs don't know this really

how does the block hash stay the same when the payload changes?

Reacted to "What’s Toni’s attacK" with 🥷

Is there a writeup of this issue?

Replying to "Is there a writeup o..." Was having audio issues, so didn’t hear it entirely

Reacted to "Is there a writeup of this issue?" with ➕

Reacted to "Is there a writeup of this issue?" with ➕

We should add this to some kind of CL benchmark infrastructure / test infrastructure if possible

why doesn't `[IGNORE] The node has not seen another valid `SignedExecutionPayloadEnvelope` for this block root from this builder` cover the re-propagation?

Reacted to "why doesn't `[IGNORE] The node has not seen another valid `SignedExecutionPayloadEnvelope` for this block root from this builder` cover the re-propagation?" with ➕

Antwoord verzenden naar "We should add this..." I think we can add this to a hive test?

Replying to "why doesn't `[IGNORE..." Is there a bug with re propagation here?

Replying to "why doesn't `[IGNORE..." lodestar only propagates the first signed envelope from a builder for block root

How does a large payload affect BLS?

Replying to "why doesn't `[IGNORE..." Teku does the same

Replying to "why doesn't `[IGNORE] The node has not seen another valid `SignedExecutionPayloadEnvelope` for this block root from this builder` cover the re-propagation?" We are repropogating envelopes we’ve already seen. We are fixing this in the coming days it will be ready for devnet 8

yeah not having the IGNORE might be the bug here

Reacted to "yeah not having the IGNORE might be the bug here" with 👍

Reacted to "yeah not having the IGNORE might be the bug here" with 👍

Reacted to "yeah not having the IGNORE might be the bug here" with 👍

Replying to "yeah not having the ..." To be clear, it is in the spec.

Reacted to "To be clear, it is i..." with 👍

Reacted to "To be clear, it is in the spec." with 👍

Reacted to "To be clear, it is i..." with 👍

Hive test?

Replying to "yeah not having the ..." And in the next release, there will be reference tests for Gloas gossip validation functions. Here is the test for that check.

geth reth still failing 50ish tests

others failing under 10

Reacted to "yeah not having the IGNORE might be the bug here" with 👍

public devnet or public testnet?

devnet-8 is currently planned to be public

i.e. is there going to be a "devnet 9" of any form at all

public testnet

Replying to "public devnet or pub..." public devnet, before public testnets iiuc

Replying to "devnet-8 is currentl..." Aren’t they all technically public 😅

devnet 8 == public testnet

Replying to "devnet-8 is currentl..." yes

Reacted to "yes" with 😄

devnet 8 timeline is whenever you guys are done

might be cool to have a copy paste to share on twitter about the most affected parties, who use this or that

Reacted to "yeah not having the ..." with 👍

Is Platåberget just another name for devnet 8?

Reacted to "Is Platåberget just another name for devnet 8?" with 👍

Replying to "Is Platåberget just ..." yes

Reacted to "Is Platåberget just another name for devnet 8?" with 👍

Reacted to "Is Platåberget just ..." with 👍

Replying to "Is Platåberget just ..." devnet 8 is just easier to spell lol

Reacted to "might be cool to hav..." with 👍

Replying to "Is Platåberget just ..." I’ve been referring to it as PB as it’s unpronounceable

Reacted to "I’ve been referring to it as PB as it’s unpronounceable" with 😂

Reacted to "devnet 8 is just easier to spell lol" with 😄

The numbers haven't changed drastically between 7 and 8 though

Replying to "Is Platåberget just ..." the peanut butter devnet

Replying to "Is Platåberget just ..." I support this name change

Reacted to "the peanut butter devnet" with 😂

Replying to "Is Platåberget just ..." Will supply jelly.

Reacted to "I support this name change" with ➕

Reacted to "the peanut butter devnet" with 😂

So I wouldn't expect large changes going forward

Reacted to "Will supply jelly." with 🪼

Reacted to "I’ve been referring to it as PB as it’s unpronounceable" with 😂

Reacted to "the peanut butter devnet" with 😂

Reacted to "Will supply jelly." with 🪼

Reacted to "the peanut butter devnet" with 😂

what's the scope of remaining changes in terms of, is there convergence to prices and it's figuring out +/- the last few %?

Reacted to "the peanut butter de..." with 😂

Replying to "Is Platåberget just ..." Someone redo this song with “peanut butter devnet time” pls https://www.youtube.com/watch?v=eRBOgtp0Hac

or is it possible some are still 50% off

Reacted to "the peanut butter de..." with 😂

Reacted to "the peanut butter ..." with 😂

does security team would have an update on the audit progress of the builder system contracts?

Heeft gereageerd op "does security team..." met ➕

Delaying 8, yes

Reacted to "does security team would have an update on the audit progress of the builder system contracts?" with ➕

Replying to "does security team w..." I believe Felix is the one handling this. Not the security team.

Replying to "does security team w..." Like the one coordinating with the auditors.

Heeft gereageerd op "Delaying 8, yes" met ❤️

Reacted to "Delaying 8, yes" with ❤️

Reacted to "Delaying 8, yes" with ❤️

For prysm, I don’t think we put genesis state in binary

https://github.com/ethereum/pm/issues/2181#issuecomment-5241502214

17MB is fine, we don't put any state in the binary

70mb

yeah same with us

Fetch it from GitHub previous, we just provide a example cmd

for the devnets yeah we use the ethclients repo version of these. we do by default include it in the binaries, would have to see what makes the most sense here

70MB would be large for that

Is this via git Lfs? (Ill have to make sure our billing limits are appropriate if so)

S3 = cheap, git ifs == cheap-ish

For EIP editors in the call, please approve https://github.com/ethereum/ERCs/pull/1917 and https://github.com/ethereum/EIPs/pull/12021 due to approval of https://github.com/ethcatherders/EIPIP/issues/411 It blocks moving an EIP to Review for Glamsterdam, thanks 😃

Reacted to "the peanut butter de..." with 😂

hoodi genesis.ssz is 145MB

Sounds to me generally it should be fine and I would prefer not to forgo this test vector

Can CL’s “schedule” a default gas target value? I wouldn’t want 200m enabled whenever glamsterdam releases are made.

we can just do another release and bump the default incrementally

Reacted to "we can just do another release and bump the default incrementally" with 👍

Couldn’t you set it in the EL ?

CLs do drive it via builder API

just let the gas limit naturally ramp up

Dragan’s suggestion is my preference. I would prefer to bump the gas target in CL clients in the release after the upgrade.

for a few blocks, a few transactions that are heavy on state creation might fail and work again a bit later

Reacted to "Dragan’s suggestion ..." with 👍

Reacted to "we can just do another release and bump the default incrementally" with 👍

Why doing it in a separate release though?

This wastes having more granular controll over it at the hardfork. It makes things messier, requiring coordination, pushing validators to upgrade

Only downside is that blocks would gradually increase over time, and would hit 200M only after few months when all validators update to newest client version.

Why can’t client set it with 2 gas limits. One pre gloss and one post gloas

What percentage of the network needs to bump their gas targets in order for the network to reach 200m? 51%?

you can't do that Toni

would need to be epoch/slot aware

can’t we have a gas_limit -> fulu_gas_limit, and a new flag like gloas_gas_limit, that will be the new gas_limit post gloas ?

Replying to "What percentage of t..." With 51% it would levitate over ~130M, half would decrease it and other half would increase it by 12%

Reacted to "With 51% it would levitate over ~130M, half would decrease it and other half would increase it by 12%" with 🙏

Call it “next fork” then it doesn’t have to disappear

Reacted to "Call it “next fork..." with 👍

Reacted to "Call it “next fork” then it doesn’t have to disappear" with 👍

Replying to "Call it “next fork” ..." or that

gloas calls a different engine api that has the gaslimit; can't use same switch?

the gas limit it supposed to be controlled by operators, not client devs, so this feature goes into the other direction

Can someone EIP this idea?

Replying to "gloas calls a differ..." cl teams could introduce a new flag for this.

Reacted to "Can someone EIP this idea?" with 👍🏼

Replying to "gloas calls a differ..." but they wanted to override the existing flag

"deprecated" flags in production never really disappear

Antwoord verzenden naar "Can someone EIP th..." This is non-Core as it should not require (?) any protocol changes. So we can "just" add this to Hegota for instance

it's quite bad

why do we need 200M at the fork boundary?

One flag for pre gloss becomes no op after gloas One flag for post gloss

Replying to "why do we need 200M ..." we don’t, but we need to start signaling towards 200M

Does it have to be a flag? Is there any other way to bake a default for a specific fork?

Replying to "why do we need 200M ..." We don’t need it

Replying to ""deprecated" flags i..." Can’t the existing override flag just override both defaults?

Replying to "why do we need 200M ..." I don't think we should have 200M at the fork, seems risky

does it take a while to get to 200M? ahh its more a people wont update it either

To Barnabas point we can always pressure the professional node operator set

Reacted to "To Barnabas point ..." with 🙏

Replying to "To Barnabas point we..." We just need a few of them, but it will be slow

Replying to "To Barnabas point we..." Because of the ramp up

Replying to "To Barnabas point ..." "we promise no issuance changes in the future"

Reacted to ""we promise no issuance changes in the future"" with 😂

Reacted to ""we promise no issua..." with 😂

Issue is state gas is getting much higher so needs higher gaslimit; or txs pre fork will fail post fork

Se ha reaccionado a ""we promise no iss..." con 😂

Reacted to "Issue is state gas is getting much higher so needs higher gaslimit" with 💯

yes mandatory, we delaying the launch anyway, so get to it

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

btw does it make sense to have both sparse + non sparse nodes?

Reacted to "Issue is state gas is getting much higher so needs higher gaslimit" with 💯

Reacted to "Issue is state gas..." with 💯

Reacted to "yes mandatory, we ..." with ❤️

i mean do you guys want a flag?

Replying to "btw does it make sen..." if its mandatory, then it should all be sparse

Replying to "btw does it make sense to have both sparse + non sparse nodes?" some time network will contain both

Replying to "btw does it make sense to have both sparse + non sparse nodes?" i mean mainnet and so on

Reacted to "Someone redo this so..." with 😂

https://eips.ethereum.org/EIPS/eip-8136 https://eips.ethereum.org/EIPS/eip-8189

Heeft gereageerd op "https://eips.ether..." met 🚀

Reacted to "https://eips.ethereum.org/EIPS/eip-8136 https://eips.ethereum.org/EIPS/eip-8189" with 🚀

Reacted to "https://eips.ethereum.org/EIPS/eip-8136 https://eips.ethereum.org/EIPS/eip-8189" with 🚀

potuz’s post: https://www.potuz.net/posts/gloas-circuit-breaker/

Our first part (just to deal with builder) has been approved, we haven’t merged it. We can cherry pick it to devnet7 if you guys want to test

Unrelated psa: will be scheduling a bi-weekly frame tx breakout call, lead by lightclient, starting tuesday 18th @ 2pm utc (right after FOCIL breakout). Will also announce on discord.

could we trigger it ?

Heeft gereageerd op "Unrelated psa: wil..." met ❤️

Reacted to "Unrelated psa: will be scheduling a bi-weekly frame tx breakout call, lead by lightclient, starting tuesday 18th @ 2pm utc (right after FOCIL breakout). Will also announce on discord." with ❤️

Replying to "Our first part (just..." if its gnna be in devnet 8 branch then its fine?

@lightclient could you approve https://github.com/ethereum/EIPs/pull/12021 as EIP editor? This unblocks updates to EIP-8282 (https://github.com/ethereum/EIPs/pull/11869 ), thanks 😃

Replying to "could we trigger it ..." Teku CB uses the same existing (blocks) circuit breaker options (the default values are too permissive for Gloas) so we should reduce them to trigger it. I’ll share stricter values to configure

Reacted to "@lightclient could y..." with 😍

Reacted to "@lightclient could y..." with 😍