AllCoreDevs - Testing #102

gm

Gm!

gm gm

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

gm

https://github.com/ethereum/pm/pull/2284

https://github.com/ethereum/pm/pull/2284" with 👍

https://github.com/ethereum/pm/pull/2284" with 👍

Worth repeating this: the vast vast majority of the findings are just about repricings (i.e. spec changes means not increasing gas costs)

I think most of the gasłeft increases problems can be fixed and it is the EIP I proposed. Some repricings can be mitigated, but this cannot be fixed fully.

Reacted to "Worth repeating th..." with 🙏

Sepolia is better to ditch in the case

Plus benchmarking

Reacted to "Sepolia is better to ditch in the case" with 👍

Reacted to "Plus benchmarking" with 🥲

I’m not super involved with 8037 stuff, but what would be the cost of pulling it from the fork, and shipping glammy without it?

Replying to "I’m not super involv..." Not raising the gas limit

Replying to "I’m not super inv..." Dont think we can! Also re testing everything

Right now it doesn't look like spec changes will needed, but better delay scheduling hoodi for now and give it (at least) two weeks.

Replying to "I’m not super involv..." That would be the biggest costs, IMO

Replying to "I’m not super involv..." yes, without raising the gas limit

I hope we can ship 8037

otherwise, as maria said, we can't raise the gaslimit safely, making the optimizations (such as BAL) meaningless

Reacted to "otherwise, as maria said, we can't raise the gaslimit safely, making the optimizations (such as BAL) meaningless" with ➕

Heeft gereageerd op "otherwise, as mari..." met ➕

Just for informational purpose, imo it’s very unlikely that we’ll want to do spec changes, we haven’t found anything meaningful in two days now, after finding basically all the known issues very quickly, and we have done quite a comprehensive analysis, involving at least one agent scan of every contract verified on Sourcify, and much more for high value contracts, plus a lot of other methods

I still dont think we should start with a spec change, that should be a last resort

I've been putting more than a month straight in all models in a math problem and they still produce only crap

Reacted to "Just for informational purpose, imo it’s very unlikely that we’ll want to do spec changes, we haven’t found anything meaningful in two days now, after finding basically all the known issues very quickly, and we have done quite a comprehensive analysis, involving at least one agent scan of every contract verified on Sourcify, and much more for high value contracts, plus a lot of other methods" with 👍

Reacted to "I still dont think we should start with a spec change, that should be a last resort" with 👍

Reacted to "I still dont think we should start with a spec change, that should be a last resort" with 👍

Reacted to "I still dont think..." with 👍

Reacted to "Worth repeating this: the vast vast majority of the findings are just about repricings (i.e. spec changes means not increasing gas costs)" with 🙏

Reacted to "Sepolia is better to ditch in the case" with 👍

Reacted to "Just for informati..." with 👍

Reacted to "I still dont think we should start with a spec change, that should be a last resort" with 👍

Replying to "I still dont think w..." Plan for the worst (spec change), hope for the best (no spec change)

Replying to "Right now it doesn't..." we seem to have pretty high confidence that nothing major is breaking for undue reasons, is two weeks absolutely necessary?

Reacted to "Plan for the worst..." with 👍

Reacted to "Just for informational purpose, imo it’s very unlikely that we’ll want to do spec changes, we haven’t found anything meaningful in two days now, after finding basically all the known issues very quickly, and we have done quite a comprehensive analysis, involving at least one agent scan of every contract verified on Sourcify, and much more for high value contracts, plus a lot of other methods" with 👍

Reacted to "I still dont think we should start with a spec change, that should be a last resort" with 👍

how probable is a new useful outcome from a nn that predicts most probable answer based on old knowledge? we still need brains to invent something new

Replying to "Right now it doesn't look like spec changes will needed, but better delay scheduling hoodi for now and give it (at least) two weeks." yeah agree, we should revisit it next week already

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

Replying to "Right now it doesn't look like spec changes will needed, but better delay scheduling hoodi for now and give it (at least) two weeks." fredrik mentioned that we could wait until the dealine of the audits being done, those will take 2 weeks

Reacted to "Plan for the worst (spec change), hope for the best (no spec change)" with 👍

Replying to "Right now it doesn't look like spec changes will needed, but better delay scheduling hoodi for now and give it (at least) two weeks." I think the main question to me is how long to we give people to migrate away from immutable contracts on mainnet, my feeling is that hoodi upgrade date won’t make a big difference there?

I may run out of batteries, just want to express my support for this given the fork delay

Reacted to "I may run out of batteries, just want to express my support for this given the fork delay" with 👍

Replying to "Right now it doesn't..." i feel like we’ve already pumped the brakes and engage some auditors. we might as well let the audits run

I agree we should wait. It would be worst if in 2 weeks, audits come with new findings and we need to change dates again

Reacted to "i feel like we’ve already pumped the brakes and engage some auditors. we might as well let the audits run" with 👍

Reacted to "I agree we should wait. It would be worst if in 2 weeks, Audis come with new findings and we need to change dates again" with 👍

Replying to "Right now it doesn't..." it’s not ideal, but it is what it is

Replying to "Right now it doesn't..." Also, agree that the most likely delay will be from the contracts that need to upgrade and deploy before mainnet

Reacted to "Also, agree that the most likely delay will be from the contracts that need to upgrade and deploy before mainnet" with 👍

Reacted to "I may run out of batteries, just want to express my support for this given the fork delay" with 👍

Support it from lighthouse side

Reacted to "Support it from lighthouse side" with ❤️

did support it last time and still do

Reacted to "I may run out of batteries, just want to express my support for this given the fork delay" with ❤️

in favor

Reacted to "did support it last time and still do" with ❤️

ok if and only if it doesn't create "sepolia gloas" and "post-sepolia" gloas which need supporting/testing

Reacted to "in favor" with ❤️

we can do devnet 13 or whatever number we are on

where we can test this

Reacted to "where we can test this" with ❤️

sepolia should be fine. we had no onboardings there, so the transition doesn't change even if we change the onboarding

Reacted to "Also, agree that t..." with 👍

Reacted to "where we can test this" with ❤️

Replying to "ok if and only if it..." no impact on sepolia

Reacted to "where we can test ..." with ❤️

Reacted to "no impact on sepolia" with 👍

Reacted to "sepolia should be fine. we had no onboardings there, so the transition doesn't change even if we change the onboarding" with ❤️

Reacted to "sepolia should be fine. we had no onboardings there, so the transition doesn't change even if we change the onboarding" with 👍

Reacted to "no impact on sepolia" with 👍

Sepolia is irrelevant for this Dustin

Reacted to "sepolia should be fine. we had no onboardings there, so the transition doesn't change even if we change the onboarding" with 👍

you will still be able to do it yes as there was no such deposits

Thanks all. Have to drop

https://github.com/ethereum/execution-apis/pull/958

sorry for merging before we could discuss, it was insta merged by Mikhail lol

Reacted to "sorry for merging before we could discuss, it was insta merged by Mikhail lol" with 🚢

Reacted to "sorry for merging before we could discuss, it was insta merged by Mikhail lol" with 🚢

Reacted to "sorry for merging before we could discuss, it was insta merged by Mikhail lol" with 😂

Heeft gereageerd op "sorry for merging ..." met 🚢

Heeft gereageerd op "sorry for merging ..." met 😂

General note, on devnets, kept running into getPayload timing on Reth, e.g., https://discord.com/channels/595666850260713488/892088344438255616/1554105035212718181

Yeah this I think will break FCU timings on Prysm

so they might also have been trying this strategy

Replying to "General note, on dev..." pretty sure thats what we are discussing now 😄

I wish focil and specially shorter slots are thought better with regards to this interaction

Replying to "General note, on d..." yes that's why I mention it

Replying to "General note, on d..." it's not a random tangent

Replying to "General note, on d..." i.e. it's not only from Besu

besu/reth/ethrex all had these issues

anyone with an modification in mind pls open a pr

does payload execution now have a deadline?

lodestar calls at t=0 at least, if EL responds instantly we could call getPayload 500ms later if we anyway wait for builder response

Replying to "lodestar calls at ..." Yeah in some pathological scenarios where Nimbus doesn't fcu ahead of time it does this 500ms wait/delay

Replying to "lodestar calls at t=..." just need to clarify the expectation whether EL should wait with response to produce a better payload or whether it should respond instantly

fix 8037

In geth, we always return the payload when the getPayload is requested, fallback to empty if the full one is not yet built

you got an hour

lol

Heeft gereageerd op "you got an hour" met 😂

Heeft gereageerd op "you got an hour" met 🚢

Reacted to "you got an hour" with 😂

Reacted to "you got an hour" with 😂

Reacted to "In geth, we always return the payload when the getPayload is requested, fallback to empty if the full one is not yet built" with 👍

its perfect as it is :)

The hash is enough

We just recalculate the block root

sry :(

Reacted to "its perfect as it is :)" with 😅

Reacted to "its perfect as it is :)" with 😅

Replying to "sry :(" no jokes are allowed

block root != sig though?

Don't know how to UN mute

Reacted to "no jokes are allow..." with 🥲

Reacted to "no jokes are allowed" with 🥲

And once more the solution to this would be to not serve these payloads

I thought we were moving to the breakout...

This is the breakout

Replying to "I thought we were mo..." I’m sorry, we decided to stay in this call since the EL doesn’t have anything to discuss.

Replying to "I thought we were mo..." now they are forced to listen to dustin and potuz fight

Reacted to "now they are forced to listen to dustin and potuz fight" with 😂

Reacted to "now they are force..." with 😂

Reacted to "now they are forced to listen to dustin and potuz fight" with 😂

Reacted to "now they are forced ..." with 😂

Yeah agree we should specify

Please no

`len(payload.transactions) <= bid.gas_limit // MIN_TRANSACTION_GAS`

Why would you need that?

Reacted to "now they are forced to listen to dustin and potuz fight" with 😂

For us it's still a problem cause it's hard to verify these during serialization

Replying to "For us it's still a ..." Still worthwhile to have, since it would save the EL from validating it

I’m in favor

can we discuss what the final form of the consensus spec’s gonna be? Can we expect shorter slots to be merged in this week ?

Seems a bit ... architectural-boundary-crossing?

Not really against it but

Replying to "Seems a bit ... arch..." we do have eip 1559 transition rule on cl side too

Replying to "Seems a bit ... ar..." Yeah true

min gas limit: its 21k before glamsterdam and 12k with glamsterdam due to https://eips.ethereum.org/EIPS/eip-2780 but open to change in the future of course

Reacted to "min gas limit: its 21k before glamsterdam and 12k with glamsterdam due to https://eips.ethereum.org/EIPS/eip-2780 but open to change in the future of course" with 👍

已使用👍回应"min gas limit: its..."

Learned to raise a hand also :)

Heeft gereageerd op "Learned to raise a..." met 🙏

4 clients have already impl with the heze spec

Fine by me if it's SFId in ACD this week

if that gives a rough consensus

Didn’t we agree not to do quick slot in next devnet? If so don’t merge

Replying to "Didn’t we agree not ..." heze-devnet-2 is arleady up for a week

Replying to "Didn’t we agree not ..." heze-devnet-3 has quick slots

Replying to "Didn’t we agree not ..." so not sure what we are waiting for

Reacted to "Fine by me if it's SFId in ACD this week" with 👍

can we merge into the feature then? outside of the main heze repo right?

we have 4 implementations, isn’t that majority?

Replying to "can we merge into th..." pls don’t

Replying to "can we merge into th..." Yeah we can. Keep tests/changes in the feature.

Replying to "can we merge into th..." to be clear i’m agnostic on the right solution, just seems like it’s in limbo right now, with open PRs, but obv happy with anything that works for the devs

but we have it on our trunk and it's untested due to spec not being merged

I would like to have some way to have several EIPs all stacked on one consensus specs branch, eg all of the EIPs for a devnet, don't care if its the main branch or some other branch..

Sorry @Potuz I agree with you. No changing times

Replying to "we have 4 implementa..." This is tricky because anyone can implement, but agreement from the team is different IMO

Merging means everything coming after would need to build on top. This cements a proposal in while it's not SFI'd yet and is frontrunning a SFI decision.

Replying to "I would like to have..." yea like a devnet or interop branch or something

Replying to "Merging means everyt..." no

Replying to "Merging means everyt..." CL spec always did CFI -> spec release -> SFI

Replying to "I would like to have..." well my preference is just one main branch

We did the same with FOCIL, it was tested but didn’t get merged until SFI’d. IMO we should do the same

Replying to "I would like to have..." and revert EIPs that don't end up getting SFId :shrug:

It does. Afterwards the decision is, "should we do the proposal or change all other features that were forced to build on top"

Replying to "We did the same with..." agreed

can we merge to main in CL with it being isolated from the main spec?