AllCoreDevs — Consensus #176

Lol

gm!

gm

Andriian invited Fireflies.ai here to record & take notes. By continuing, you agree to https://fireflies.ai/privacy. Type: '/ff pause' - pause recording '/ff leave' - to stop recording View Realtime notes here: https://app.fireflies.ai/live/01KM0QR53Z1FQBRJZNKEFZDZ3E?ref=live_chat

good morning Ethereummm

GM

half of them are bots

I am a bot

Justin is def one of them :D

Reacted to "I am a bot" with 🤖

LIES

robocop

Reacted to "Justin is def one of..." with 👍

oh wait... right

The whole pandaops team

Reacted to "oh wait... right" with 😂

Reacted to "oh wait... right" with 😂

Replying to "The whole pandaops t..." They are machines

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

Reacted to "oh wait... right" with 😂

Reacted to "They are machines" with 😂

Reacted to "oh wait... right" with 😂

Reacted to "They are machines" with 😂

Reacted to "They are machines" with 😂

Reacted to "They are machines" with 😂

Alex, if there's time I'd like to go quickly over the open issues on ePBS so that it appears in the minutes and then call the right people to weigh in?

Replying to "The whole pandaops t..." Instructions unclear, running rm -rf /

Reacted to "oh wait... right" with 😂

Replying to "Alex, if there's tim..." Sure, do you want to go over Barnabas now?

Replying to "Alex, if there's tim..." I have a similar question

Replying to "Alex, if there's tim..." sure

Reacted to "oh wait... right" with 😂

Reacted to "They are machines" with 😂

Seems like this is the main PR: https://github.com/ethereum/consensus-specs/pull/4992

there is another alternative PR to fix it https://github.com/ethereum/consensus-specs/pull/5020

just opened that like an hour ago

Reacted to "just opened that lik..." with 👍

the issue potus is talking about: https://notes.ethereum.org/@pk910/4788-epbs

Not urgent but another issue. For proposer preferences we would like to replace eth/v1/validator/prepare_beacon_proposer and /eth/v1/validator/register_validator endpoints with it. But the protocol spec proposer preferences can only be sent out for the next epoch. This is an issue for a multitude of edge cases, Also originally called out by Nico, ideally it could be revisited. https://github.com/ethereum/consensus-specs/pull/4777#discussion_r2634788761

For Lido, restoring missing records is the best option. Otherwise, we will run into a few issues.

Patches just mentioned in discord that for RP the block root thing is a issue too: > rp uses state proof for validator withdrawal credentials, balances, and withdrawals, if i recall correctly

PR to support reorg head’s ancestor: https://github.com/ethereum/execution-apis/pull/770 Please review EL devs

Thanks Alex

To be fully honest, Lido will not fall apart if we have missing records. But we will have to spend A LOT of money and effort to adapt to it. Over the past 2 years, we have done our best to add permissionless proofs wherever possible to reduce the protocol’s reliance on Oracles. Hence, the exposure to changes in 4788 for Lido is significant at the moment

Let's have a more focused chat. I suspect the changes would be minimal if any just keeping things as they are now

Reacted to "To be fully honest..." with 👍

Reacted to "Let's have a more fo..." with 🫂

Replying to "To be fully honest, ..." Do you have a link to e.g. some solidity using 4788?

Replying to "To be fully honest, ..." Ideally we can find a way so its transparent under epbs

Replying to "To be fully honest, ..." An example would help

Hey, Tomás from ethrex exec client here. @Potuz what you mentioned is ELs needing to support executing blocks from a parent/ancestor or reorgs to exactly the parent block? That is, just marking head/head+some ancestors as non-canonical?

Its basically this PR: https://github.com/ethereum/execution-apis/pull/770

Replying to "Hey, Tomás from ethr..." yes, we may need to reorg to a previous block in the chain

Replying to "Hey, Tomás from ethr..." ok interesting, I think we already support this, but I’ll check if our test cases cover it correctly. Thanks for the link terence!

But then thats iffy ux, right? Getting the update 12 sec later

Replying to "But then thats iffy ..." Right.. that was my point. I don’t know how much this affect UX

Replying to "But then thats iffy ..." The cl knows that the head is bad, but keeps el in the dark until the next block

Replying to "But then thats iffy ..." Still wrapping my head around the issue but can the CL just update the EL as soon as it knows?

Which turns out to be a really good tests, we found so many bugs because of it

right

You won’t propose if you are optimistic anyway

But still the question is that for CLs that reorg to a back node, they will get SYNCING if they were *already* receiving SYNCING correct?

BTW, I am fairly certain that the proof becomes not larger than a couple of hashes

Can we not just populate the 4788 contract with the missing roots

I'll post the full proof of this using the parent hash

Replying to "Can we not just popu..." What timestamp do they correspond to

Replying to "Can we not just popu..." Hmmm

Replying to "Can we not just popu..." yea, that's part of the problem. we can't insert multiple reoots with the same or multiple system calls. we need separate execution frames that mimic the block time of the empty missed payloads

@Dima Gusakov | Lido don't you have the option to choose that slot?

then you can just point to a full slot

WRT consolidations: those are processed on full slots so you can prove against the parent hash I think?

Replying to "WRT consolidations: ..." I need to look deeper here. The time for analysis was pretty small NGL

Reacted to "I need to look dee..." with 👍

I think it's 3 intermediate hashes to profe via the parent_root (header has 5 fields, so deph 3). so yea, basically +3 hashes per missed slot. but it makes proof path verification more complex

Replying to "WRT consolidations: ..." There's plenty of time for this I believe, and everyone is open to fix it the best way for everyone so I don't think this will be a problem at all

Replying to "I think it's 3 inter..." it's not linear in the missed blocks though, cause you will have the child block to the one you're interested always

Replying to "I think it's 3 inter..." so it's always just one jump that you need

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

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

For those interested in the different FC possibilities, created this to help me study it: https://nerolation.github.io/ePBS-ptc-fc-table/

That's not the simpler one though, that moves complexity to the cache

that's the one that has the least size impact on state though

The simple one is where we can just use the state for the cache

Similar to proposer look ahead

I have no strong preference

whatever clients decide is fine by me, just to be clear we're shipping this in devnet 1

Reacted to "For those interested..." with 🔥

Replying to "That's not the simpl..." 4992 still requires a separate ptc cache which is one of the main reasons I don't like it

Replying to "For those interested..." This is super cool!

What is the ensurance that on ACDT we can actually make a decision regarding this PTC stuff?

we have been dragging this on for a long time

Variable Payload Deadline Post: https://hackmd.io/@Nerolation/B1GKtAUcZg PR: https://github.com/ethereum/consensus-specs/pull/4843

Replying to "we have been draggin..." It needs a tad more analysis

Replying to "we have been draggin..." But I’ll track it so we can sort it out

Replying to "we have been draggin..." we can just decide 100%, we've called for clients for a long time, so we will make a decision with whomever is there on monday

Replying to "we have been draggin..." We can focus on devnet-0 issues before needing to make a decision here

Replying to "we have been draggin..." specially cause AFAICS there's no one with a strong feeling about any of these PRs

Replying to "we have been draggin..." Yeah, im also ok w/ just making a call monday

Replying to "we have been draggin..." In that case I will try to do a bit more thinking about the fork choice in the event we can make the protocol simpler

yeah not all snappy implementations are the same. it's a format, not an algorithm

Replying to "That's not the simpl..." yeah me too, my preferred one I believe is 2 epochs (or even 3) in state

Replying to "That's not the simpl..." but 4992 allows to at least always use head state to get the ptc, while the new version has branches depending on the slot number

5s execution deadline pls

Can we think this over a little longer?

Replying to "That's not the simpl..." 4992 is good with me, that I’m certain we won’t need another off chain cache and can use the state for it. (Except for beacon api use case)

Replying to "Can we think this ov..." I don’t think we need to make a decision on this today

Replying to "Can we think this ov..." But it will be time soon

We could just ship it in h*

Replying to "We could just ship i..." we can ship it any time, it's not a hard fork

Replying to "We could just ship i..." and its trivial to implement

Replying to "We could just ship i..." It needs to be coordinated though right?

Replying to "We could just ship i..." Essentially a soft fork

Replying to "We could just ship i..." What Toni's proposing is reasonable: wait until we have a reasonable solution, whatever we do is fine. @alex I don't think this really needs to be coordinated

Replying to "We could just ship i..." Deadline parameter only hard forks :p

Replying to "We could just ship i..." I suppose there are some interactions with pricing.. I.e., to accommodate a variable deadline being as useful as possible, if it is done

Replying to "We could just ship i..." PTC voting is kinda irrelevant in 99% of cases

Reacted to "Deadline parameter o..." with 🔥

Execution time turns into proving time; so 6-7 seconds would be great there

Reacted to "Deadline parameter o..." with 🔥

The only thing I disagree with Toni is that linear regression *is the only reasonable* thing to do, cause broadcast is linear in size

Replying to "That's not the simpl..." I am also fine with putting everything in the state so we can remove the off chain cache

Replying to "Execution time turns..." What if execution time also turns into gas limit increases :D

Replying to "That's not the simpl..." I think it's the best of all, since it also affects hashing in the best way

Target mid April tbh

Reacted to "What if execution ti..." with 😃

Otherwise we risk overlapping with interop

Replying to "That's not the simpl..." perhaps we can put 3 epochs and be done with duties as well

Sounds good to me

We should make a decision about PTC then today

Reacted to "What if execution ti..." with 😃

Replying to "The only thing I dis..." I can see that argument but we should then not interpolate as of 3.6 but pick a later point in time

Replying to "The only thing I dis..." yeah the constant term should be benched correctly

Replying to "The only thing I dis..." Also, broadcast in linear, but we would anchor on uncompressed sizes, which changes the situation

Are we talking CL side or EL side?

lol

Ah, right, I think it should be an acde decision

epbs-devnet-2 doesn't exist right? :D

Can we make sfi decisions on ACDT?

we usually have around 50ppl

ACDT had very low volume when I go there

Replying to "Can we make sfi deci…" Maybe we should first discuss on acde? Going forward that might be fine

Reacted to "Maybe we should firs..." with 👍🏽

Reacted to "Maybe we should firs..." with 👍🏽

Reacted to "Maybe we should fi..." with 👍🏽

Reacted to "Maybe we should fi..." with 👍🏽

I am not strongly opinionated though, fine to be overruled

Acdt could at minimum have a recommendation maybe

Replying to "I am not strongly op..." I'm strongly opinionated to not overrule ansgar

Reacted to "Maybe we should firs..." with 👍🏽

ppl usually don’t speak up anyways lol.

Replying to "Acdt could at minimu…" Will discuss with Barnabas

Reacted to "ppl usually don’t sp..." with 😢

Reacted to "I'm strongly opinion…" with ❤️

Reacted to "I'm strongly opini..." with 💯

yes, let's SFI that right now

:)

Is SSZ ok in the EL now?

Reacted to "I'm strongly opinion..." with 💯

yo

Someone summoned me

does it need to be synced with a fork? can be built opt-in

Replying to "Someone summoned me" We are talking about ssz engine api

Replying to "The only thing I dis..." we need to find a way of using compressed sizes here

SSZ yees

not bound by a fork

Is via discovery

+1 to Marius point, but that kind of thinking delays shipping though, until we get the "perfect API", we're bottlenecked by JSON

SSZ can be used right now

Joking aside, proving can start earlier anyway. This is the latest time when the payload must arrive the attesters. Builders will have to make sure their block is proven and might have time for the prove until the ptc deadline, independent from the payload deadline

What exactly would you change?

we would need to have rest support anyway

there we can mess around with the versioning a little bit

Replying to "The only thing I dis..." agree yeah, that would be the cleanest solution. Worth discussing async or at some point in the future what the blockers are there

Meta versioning 😅

Reacted to "Meta versioning 😅" with 😂

yes

Engine API version versioning system

I would like to see a more fluid interface so EL and CL can coordinate tightly

Reacted to "Engine API version v..." with 😭

all api versioning is dumb

CL has a bit different approach of types maintanance per fork

Replying to "all api versioning i..." Gotta compliment guilio and jacek for their restraint in not jumping on this and saying we should get rid of EL/CL split altogether

Replying to "all api versioning i..." single binary?

Can't speak for Marius,, but some of the things I've had in mind are: fcU bundles too many things, for example, e.g., setting head vs triggering sync or checking head validity vs setting new head validity being conflated. Inability to ask in any deterministic way whether a block is valid in a way which doesn't trigger a bunch of interference with other operations

There are a bunch of semantic points

the best solution to api versioning is "dont", the second best is mime types

basically right now engine API supports optimistic and and only optimistic sync, and that's always been the case

but that's decreasingly useful

Replying to "all api versioning i..." besu/teku has considerd this for years, we're still kinda "meh" on the value add

I think I’d suggest “engine api next gen” for interop, and think about more iterative change before that

Reacted to "besu/teku has consid..." with 🥦

also, the basic notion of exchangecapabilities is one big TOCTOU

might as well just try to use $FOO, not ask to use $FOO

Reacted to "besu/teku has consid..." with 🥦

Replying to "all api versioning i..." I agree 😄

Reacted to "Gotta compliment gui..." with 🤣

Replying to "CL has a bit diffe..." Yeah, what the CL and EL consider a "mess" might vary

Replying to "all api versioning i..." problem is Vouch and company, we will never get rid of the damned API

we have Eth-consensus-version header for this on beacon-api so we don't need to bump the api version just because the type changes

Reacted to "Gotta compliment gui..." with 🤣

Rlp on cl

Reacted to "Rlp on cl" with 😂

Replying to "Rlp on cl" Really tempted to abuse mod rights on this one

Reacted to "Really tempted to ab..." with 😂

Replying to "Rlp on cl" Marius, you may be excused to leave this call right now

Reacted to "Really tempted to ..." with 😂

Replying to "Rlp on cl" lol

Reacted to "Rlp on cl" with 😂

Reacted to "Marius, you may be e..." with 😂

Reacted to "Rlp on cl" with 😂

Replying to "Rlp on cl" mods crush their skulls

Reacted to "Really tempted to ab..." with 😂

Reacted to "besu/teku has consid..." with 🥦

Reacted to "Really tempted to ..." with 😂

flatbuffers+ssz :D

I don’t care SSZ vs RLP, i just want binary and zero copy

Replying to "Rlp on cl" good luck here forkcast summary job

Reacted to "good luck here forkc..." with 😰

Replying to "I don’t care SSZ vs ..." not a fan of deserializing?

SSZ is not simple, it needs safety checks and parallelisation. Need not MVP level

Barnabas’ PR: https://github.com/ethereum/execution-apis/pull/764

Replying to "I don’t care SSZ vs ..." If this sentence makes it so that we go with RLP, you'll be in charge of implementing it in Prysm @Raúl Kripalani

fine

Reacted to "good luck here forkc..." with 😰

I think we can rediscuss in ACDE£?

Reacted to "If this sentence mak…" with 😂

Reacted to "If this sentence mak..." with 😂

Reacted to "If this sentence mak..." with 😂

Reacted to "If this sentence m..." with 😂

Reacted to "I think we can redis..." with 💷

This is the PR https://github.com/ethereum/execution-apis/pull/297 I was hoping to get input from client devs on. So far, the feedback I got from Nimbus was they prefer a #302-like approach which is the (fixed secret for localhost) over #297's OS-specific paths due to some complexity concerns. While from Lodestar is open to implementing default behavior but there was questions on overall impact since tooling already handles this and CL/EL often don't share filesystems. Waiting for more input from other client teams before deciding on the best agreed upon approach on this, thank you.

I know might be a stupid question, but any CL’s opposed to this? 764

Replying to "I don’t care SSZ vs …" Deep inside i knew i was making a mistake putting those two words together in a sentence

@FLCL I would be happy to do it in Nethermind theb

To prove you wrong 🙂

Reacted to "Deep inside i knew i..." with 😂

Replying to "The only thing I d..." well different snappy implementations exist

Reacted to "Deep inside i knew i..." with 😂

Reacted to "Deep inside i knew i..." with 😂

Replying to "The only thing I d..." Nimbus uses its own for example, but the general point is that it's a format, not one compression/encoding specification

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

I think changing defaults so late is a no go

Replying to "Rlp on cl" Btw can we get a ranked list of talking time? Who are the biggest yappers on acd

Replying to "Rlp on cl" Probably stokes 😂

Replying to "Rlp on cl" Ranked list for chat would also be cool

Replying to "Rlp on cl" oh crap

Replying to "I don’t care SSZ vs …" @Stefan Starflinger we don’t get rid of deserialization (unless we send blobs binaries without any framing), but with SSZ we can use the data from the network buffer without making another alloc

Reacted to "Gotta compliment gui..." with 🤣

Replying to "I don’t care SSZ vs …" Which we can’t do in JSON because of the base64 decoding penalty

Replying to "Rlp on cl" Yeah the interesting point would be position 2+

Replying to "The only thing I dis..." I have strong opinions on this, this is not going to cause a split view: PTC is irrelevant unless the next proposer is going to reorg the payload, which it shouldn't. I think it's fine to use different algo's as long as their outputs are not TOOO different

Replying to "Rlp on cl" Ansgar will likely take the top spot

Replying to "all api versioning i..." Nah, I am realistic in my expectations 🙂

Replying to "all api versioning i..." I hope this is enough work from for now 🙂

Replying to "Rlp on cl" Congrats you found the only feature that jitsi has and zoom does not

Reacted to "Congrats you found t..." with 😂

Replying to "Rlp on cl" > Btw can we get a ranked list of talking time? Who are the biggest yappers on acd Can we not do this on this call?

Reacted to "Rlp on cl" with 😂

Reacted to "> Btw can we get a r..." with 😂

Reacted to "Probably stokes 😂" with 🚀

Reacted to "Btw can we get a ran..." with 😂

Reacted to "> Btw can we get a r..." with 😂

Replying to "The only thing I d..." so it works until it doesn't?