AllCoreDevs - Execution #240

Red added read.ai meeting notes to the meeting. Read provides AI generated meeting summaries to make meetings more effective and efficient. View our Privacy Policy at https://www.read.ai/pp Type "read stop" to disable, or "opt out" to delete meeting data.

Gm

gm

GM!

not that I am speaking on behalf of Ethereum, that was a personal gm :-)

Reacted to "not that I am speaking on behalf of Ethereum, that was a personal gm :-)" with 👍

could we paste the prs that we are currently discussing pls

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

For us is ok too

Is this one?

Replying to "https://github.com/e..." I think this is for the second item

its 8038 not 8037

Reacted to "its 8038 not 8037" with 👍🏼

I would say on the BAL EIP

Replying to "https://github.com/e..." Yup not this one

Reacted to "For us is ok too" with 👍

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

Mario*

do we already have a PR for this, can we close 11778?

Here is PR about that https://github.com/ethereum/EIPs/pull/11844

Reacted to "Here is PR about tha..." with 👍

已使用👍回应"Here is PR about t..."

third item: https://github.com/ethereum/execution-specs/pull/3045

So we can close 11778 and 3045 both in favor of 11844?

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

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

Reacted to "So we can close 11778 and 3045 both in favor of 11844?" with 👍

Reacted to "https://github.com/e..." with 👍

I want everything merged by EOW

Reacted to "I want everything me..." with 🔥

and we should aim to launch devnet 7 next week

Reacted to "and we should aim to..." with 🚢

Reacted to "So we can close 11778 and 3045 both in favor of 11844?" with 👍

Reacted to "I want everything merged by EOW" with 🔥

Reacted to "and we should aim to launch devnet 7 next week" with 🚢

Se ha reaccionado a "I want everything ..." con 🔥

Se ha reaccionado a "and we should aim ..." con 🚢

https://github.com/ethereum/sys-asm/pull/50

Reacted to "and we should aim to launch devnet 7 next week" with 🚢

Reacted to "https://github.com/e..." with ✅

https://github.com/ethpandaops/ethereum-genesis-generator/commit/7cc307c718e04427c1bc75223518c31d05b23c75

I don't think the byte code is final

0x00006AE84ed173D4394de5E28F9ED56b28008282

Replying to "I don't think the by..." final enough for devnet 7?

Replying to "I don't think the by..." I let @Felix (Geth) decide that but I think we wanted final version for devnet 7 to start audits

https://github.com/ethereum/sys-asm/pull/49

Replying to "I don't think the by..." I do agree.

I'm in favor for the disableability, just in case of future updates. should we do the disable logic to the exit contract too? just in case

I can also add it in exit

why would we ever not wanna be able to exit?

why would we want to be able to pause it?

Replying to "I'm in favor for the..." It's not about disallowing exits. It's a way to disable the old contract if we move to a new contract in future

It should be decided here I guess?

Reacted to "It should be decided..." with 👍

Reacted to "It should be decided here I guess?" with 👍

Replying to "why would we want ..." like if there is a bug with ePBS

Replying to "why would we want ..." or for later upgrades

Replying to "why would we want ..." I can explain in more detail in Discord

Let's just ship the immutable simple contract, the parameters are fine and they will never change

how would we be able to handle fork transition ?

@Gary Rong (GETH) had the changes locally, created the PR: https://github.com/ethereum/EIPs/pull/11854

We're overengineering the thing that will be barely used by a few very professional players

this started from an attack that cannot happen and now moved into a nightmarish new contract without any reason

Reacted to "and we should aim to..." with 🚢

seems like a nice-to-have to me, if it’s easy to do, I’d lean towards doing it. but also should not block on it

Replying to "this started from an..." right but now that we already have a new contract, might as well put care into it, no?

Can we have 15 min later in the call for a short discussion about some 8037 behavior we found today?

Replying to "seems like a nice-to..." I agree. It sounds reasonable to me.

已使用👍回应"Can we have 15 min..."

Replying to "Can we have 15 min l..." would that possibly have devnet-7 implications?

we should ship it

Replying to "this started from an..." the most complicated the contract the more likely to have bugs, the longer to audit it, etc

Reacted to "we should ship it" with 👍

Reacted to "we should ship it" with 👍

I am fine with the change from Felix

no no default is ship

Replying to "Can we have 15 min l..." Ish

Replying to "Can we have 15 min l..." Could we do this in discord?

We still would have to test it though, I would not feel comfortable if we had no tests for this scenario

@matt is it easy and safe to add the assembly for this?

if @lightclient and @Felix (Geth) think it's simple just put it in

@Felix (Geth) what about https://github.com/ethereum/sys-asm/pull/48 ?

Replying to "@Felix (Geth) what a..." I guess this should be closed

About #48, we decided against it ACDT

Replying to "@Felix (Geth) what a..." this is out with 49 then.

Reacted to "About #48, we decided against it ACDT" with 👍

Replying to "Can we have 15 min l..." Nvm its basically what you and @Luis Pinto | Besu also found out

Reacted to "About #48, we decide..." with 👍

Reacted to "About #48, we decided against it ACDT" with 👍

Replying to "@Felix (Geth) what a..." right exactly, so would expect to see it closed

Reacted to "Nvm its basically what you and @Luis Pinto | Besu also found out" with 👍

Replying to "About #48, we decide..." Could we close it to avoid confusion pls

Replying to "Can we have 15 min l..." so @Marius Van Der Wijden (M) does it need attention on the call?

Reacted to "Nvm its basically wh..." with 👍

Reacted to "Nvm its basically what you and @Luis Pinto | Besu also found out" with 👍

Replying to "Can we have 15 min l..." No

Reacted to "No" with 👍

Replying to "Can we have 15 min l..." Sorry about that!

Replying to "About #48, we deci..." I closed

Reacted to "I closed" with 🙏🏼

Replying to "Can we have 15 min l..." no worries, that’s what we hired Dragan as ACDE bouncer for!

Replying to "Can we have 15 min l..." Take a look at proposal in discord, it still has some discussion points open

Replying to "Can we have 15 min l..." ⁠2780-intrin-tx-gas⁠ chat

Replying to "Can we have 15 min l..." @Dragan Rakita and do we need to bring anything from that chat up now? or is it tracking towards final decisions by tomorrow?

Reacted to "no worries, that’s what we hired Dragan as ACDE bouncer for!" with 😂

Replying to "Can we have 15 min l..." I think it is already mentioned, but Guru gave good summary here of alternative here: https://discord.com/channels/595666850260713488/1504670887851327648/1522247438969081876

Replying to "Can we have 15 min l..." Mostly for client to take a look and give opinion on it

Reacted to "I closed" with 🙏🏼

@Maria Silva will you need new snapshots for running these new benches? Just asking so we can start generating them in advance

Reacted to "no worries, that’s what we hired Dragan as ACDE bouncer for!" with 😂

https://ethresear.ch/t/is-the-slot-0-reorg-cost-fixable-epbs-attestation-deadline-study/25338 Justification and research on att. deadline reasoning

Proposed: attestation at 2 payload deadline 6 ptc at 9

Replying to "@Maria Silva will yo..." Yes, we will generate new snapshots. But we will be using State Actor to generated the snapshots directly on bencharmakoor

Replying to "@Maria Silva will yo..." I think we will try to use state-actor to generate the state.

Replying to "Proposed: attestation at 2 ptc at 6" if 2s are too aggressive, we could start with 3s, observe the network after glamsterdam, and then see if we can go to 2s.

Replying to "Proposed: attestation at 2 ptc at 6" ptc at 9 but payload deadline at 6

devnet 6 is pretty stable

Replying to "@Maria Silva will yo..." Ah ok, then we should be ok then since we are integrated, right?

Reacted to "devnet 6 is pretty stable" with 🎩

Replying to "devnet 6 is pretty s..." we've had invalid blocks, clients stuck, etc.

Also doing devnet 7 gives us branches to work with

3, 6, 9

Replying to "@Maria Silva will yo..." Yes, I will let you know if anything could be done in advance, thank you

Reacted to "Yes, I will let you ..." with 🙏

Replying to "https://ethresear.ch..." @Barnabas

Reacted to "devnet 6 is pretty s..." with 🎩

Reacted to "https://ethresear.ch/t/is-the-slot-0-reorg-cost-fixable-epbs-attestation-deadline-study/25338 Justification and research on att. deadline reasoning" with 👍

To be precise 3 also helps local builders to build a decebt payload

already on it

Reacted to "already on it" with 👍

Reacted to "already on it" with 👍

Se ha reaccionado a "devnet 6 is pretty..." con 🎩

Paste a link plz

https://discord.com/channels/595666850260713488/1504670887851327648/1522247438969081876

Reacted to "https://discord.com/channels/595666850260713488/1504670887851327648/1522247438969081876" with 👍

I think ACDT deadline is more sane

Reacted to "I think ACDT deadlin..." with 👍

Reacted to "I think ACDT deadline is more sane" with 👍

Reacted to "I think ACDT deadline is more sane" with ➕

Reacted to "To be precise 3 also..." with 👍

Reacted to "To be precise 3 also..." with 💯

https://github.com/ethereum/pm/issues/2140#issuecomment-4805184883

CRITICAL DECISION FOLKS

Ice ice baby

Replying to "To be precise 3 also..." Can’t we improve building decently-enough with some engineering such that we don’t need to loose this 1 extra second? I agree that we can’t forget about local builders and in fact, we should probably build for them so that they have less reasons to go to MEVboost

August 6 deadline Hegota

Reacted to "August 6 deadline Hegota" with 🔥

A réagi à "August 6 deadline ..." avec 🔥

Reacted to "August 6 deadline He..." with 🔥

Reacted to "CRITICAL DECISION FOLKS" with 🦩

Reacted to "CRITICAL DECISION FOLKS" with 🐻‍❄️

Reacted to "August 6 deadline Hegota" with 🔥

Reacted to "August 6 deadline Hegota" with 🔥

Reacted to "CRITICAL DECISION FOLKS" with 🐻‍❄️

Reacted to "CRITICAL DECISION FOLKS" with 🐻‍❄️

Reacted to "CRITICAL DECISION FO..." with 🐻‍❄️

Reacted to "August 6 deadline ..." with 🔥

Reacted to "CRITICAL DECISION ..." with 🐻❄️

Reacted to "CRITICAL DECISION FO..." with 🐻‍❄️

@Justin Traglia it seems to me that this is all that's needed right? https://github.com/ethereum/consensus-specs/pull/5414

Reacted to "CRITICAL DECISION FOLKS" with 🐻‍❄️

Se ha reaccionado a "CRITICAL DECISION ..." con 🐻❄️

it would be very nice to bench less than 3 seconds into the slot for attestations, I'd love if we could go to at least 2500ms and then reduce the deadline for Bid calling from 1 second to 300ms or similar

Reacted to "it would be very nic..." with 👍

Replying to "@Justin Traglia it s..." Yes, Attestation deadline = 3 seconds Payload deadline = 6 seconds PTC attestation = 9 seconds

Replying to "it would be very nic..." would expect that we would need to have mainnet with epbs enabled before we could evaluate this. I’d propose such changes for hegota.

Replying to "it would be very nic..." we do not need a hard fork for this

Replying to "To be precise 3 also..." If that would be easy, we would've done it already, the problem is that you can't parallelize building and now with bals it becomes even harder

Replying to "it would be very nic..." if clients ship with lowering the default deadlinde for bid selection and after a release we release with the 2500ms attestation, there shouldn't be splits

Replying to "it would be very n..." has this been measured with some trickier regions of the world?

Replying to "To be precise 3 also..." @Marius Van Der Wijden (M) the 3 seconds is irrelevant for local builders to build a decent payload

Replying to "To be precise 3 also..." the payload is built way in advance

Replying to "To be precise 3 also..." in fact the lower the deadline is better for local builders

now is it a privacy dapp sender, or a privacyd app sender

Replying to "it would be very n..." devnets don't count, they're all datacenter nodes

Replying to "To be precise 3 also..." Carlos' point on slot 0 for local builders I believe is gone with ePBS that local builders don't need to broadcast blobs in 2 seconds

Replying to "To be precise 3 also..." and just for clarity: the payload is built before the slot even starts

Replying to "it would be very nic..." I do think this should be changed only at a hard fork, users are slow to upgrade outside of it

Replying to "it would be very nic..." yes, we've had previously tested geographically separated nodes with very large blocks, and ePBS will have very small blocks

Replying to "it would be very nic..." @Nico Flaig users delaying the upgrade also does not lead to split views

Replying to "To be precise 3 also helps local builders to build a decebt payload " agree with potuz but would say that we should not assume that the payload is built before the slot starts. With epbs, having the full slot for execution, we scale such that weak nodes finish execution just before the next slot (which is the earliest they can start building if they don't build optimistically using/trusting the BAL)

Replying to "To be precise 3 also helps local builders to build a decebt payload " the slowest (executing) nodes shouldn't build locally if they want to build decent blocks

Replying to "To be precise 3 also..." that is really the total edge case of a local builder that won't take a bid and that is weak enough that just finished executing at second 0

Replying to "To be precise 3 also..." giving out a full second of timing games for every single block just for this case seems crazy.

Replying to "To be precise 3 also helps local builders to build a decebt payload " agree but the delta between slowest and fastest nodes will always end up allowing timing games

Replying to "To be precise 3 also..." yeah that one I give to you.

Also, shipping those two EIPs together (on top of frame) is nice for dapps as they won't need to redesign they contract another time but only once.

Reacted to "Also, shipping those..." with 🔥

Replying to "To be precise 3 also..." @Marius Van Der Wijden (M) Geth improved drastically when with Bloatnet we realized block production performance was terrible. So not really sure I agree with your premise

A réagi à "Also, shipping tho..." avec 🔥

Replying to "it would be very nic..." but a node that didn't update votes differently, so you lose the head vote reward, the bid deadline is not relevant if operators run modified clients to play timing games

Replying to "To be precise 3 also..." Though true the more work we put on the prover, the harder it is.. that is undeniable

link to today's presentation: https://docs.google.com/presentation/d/12HAIc8F0u5Rt3XGG9l_C-JK8h_BuSoERvOLXIGPLu9c/edit?usp=sharing link to 8250: https://eips.ethereum.org/EIPS/eip-8250 link to 8272: https://eips.ethereum.org/EIPS/eip-8272

it’s not for the block root

it's for the privacy protocol merkle root

Unless there is a standard about that merkle root being in a particular storage slot in these kind of contracts, I think you can't link them in an MPT yea

there is a roots system contract

is it not about VOPS?

I think what Guillaume is asking is, why can't we prove against a block root

Why not just have an MMR over block roots

Replying to "Unless there is a st..." Maybe not a standard but clearly defined per contract

Reacted to "Why not just have an..." with 👀

https://nerolation.github.io/hegota-eip-presentations/hegota-pfi-proposal.html#1

why is this something to cater to? zk yes, sure, but specifically try building 10k or whatever blocks

Replying to "why is this somethin..." it's a ton less hashing

the usecase as pitched is, make MEV builders' jobs easier

I mean.

Replying to "the usecase as pitch..." What is bottlenecks on reducing block times from 12s to something like 6s or 3s?

Just a nit, it will be newPayloadV6

if these sidecars are large, might make sense to consider EC broadcast instead of gossipsub (assuming EC broadcast also lands on Hegota)

Replying to "if these sidecars ar..." 1MB is really large message for gossipsub

Provers can separate the provingo of post-state root of previous block, from subsequent block execution. Still unsure what this means reg potentially having to aggregate the proof. But worth creating some doc were we can explore this in more detail and we can share tradeoffs.

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

If we calculate the state root of the previous block, we can start without waiting the BAL of the new block it seems @Toni Wahrstätter , so do that between two blocks

Replying to "the usecase as pitched is, make MEV builders' jobs easier" builders are also part of the ecosystem and simplifying things for them also reduces entry barriers for new builders

Replying to "the usecase as pitched is, make MEV builders' jobs easier" The big builders care less about delaying the state root bc they invested a lot of time and resources in optimizing that. New builders struggle catching up.

Propagation? We can div by 2 the gas limit and the block time. And do it as much as we want. What we don’t get a linear reduction on might be on bandwidth capacity and propagation speed. @Dragan Rakita

Replying to "If we calculate the state root of the previous block, we can start without waiting the BAL of the new block it seems @Toni Wahrstätter , so do that between two blocks" right yeah, you could use the BAL of the prev slot. This means, also block builders can now profit from it

Replying to "the usecase as pitch..." the thing with optimizing for building is the value yielded only ever accrues back to the builder

Seems interesting at a glance

Replying to "the usecase as pitched is, make MEV builders' jobs easier" Are you sure? One could also argue that making building simpler, creating a more leveled playingfield, allows for more smaller builders that are less sophisticated to enter, thus making things more competetitve and being beneficial for proposers

Reacted to "right yeah, you coul..." with 👍

which one?

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

Will add it on our list

Replying to "the usecase as pitch..." i'm mostly sure, but just mostly. in order for that value to manifest as a more diverse market of buidlers, it would have to help smaller builders more than established builders, otherwise its a wash. seems like consolidation is only affected evenly here.

We do have it in the execution-specs list: https://github.com/ethereum/execution-specs/issues/2915

it shoudl be sfi it its been included for a while?

i can take care of that (the meta)

Reacted to "it shoudl be sfi it its been included for a while?" with 👍

will let Cayman know to fix eip 8282

Reacted to "will let Cayman know..." with 🙏

Replying to "i can take care of t..." Here is the PR https://github.com/ethereum/EIPs/pull/11853

which was teh EIP we DFI-ed?

repricing one