AllCoreDevs - Consensus #179

gmgm

gm

gm gm

gm

Reacted to "gm" with ❤️

I can’t seem to hear anyone

Is it a me problem?

Its you

Reacted to "Is it a me problem?" with 👍

gm

Reacted to "Is it a me problem?" with 👍

Replying to "Is it a me problem?" You are a problem

gm

Reacted to "You are a problem" with 😱

Reacted to "Is it a me problem?" with 👍

lh has a bug that prevents restarting in certain circumstances, michael has a fix

Reacted to "lh has a bug that pr..." with 👍

Replying to "lh has a bug that pr..." When will this be in the devnet branch?

Replying to "lh has a bug that pr..." being reviewed tomorrow, I'd say mon/tues next week

what did I miss

Replying to "lh has a bug that pr..." Should we wait till then with the relaunch?

Replying to "lh has a bug that ..." IMO we can optismistically merge this into the devnet branch

I had little debug info

Replying to "lh has a bug that pr..." the bug shouldn't occur if we dont relaunch all at once

Reacted to "the bug shouldn't ..." with 👍

https://github.com/ethereum/beacon-APIs/pull/580

Replying to "" what do you guys want to merge?

Replying to "lh has a bug that pr..." just a weird fork choice bug, nothing major

but why can't you compare? I don't get that

Replying to "" I think Lodestar must have a fc bug given the issue they raised up

Reacted to "I think Lodestar mus..." with 👍

Replying to "lh has a bug that pr..." yep nico confirmed must have been just before you joined

Reacted to "yep nico confirmed m..." with 👍

I vote for keeping builder boost as we have pre-gloas

https://ethereum.github.io/beacon-APIs/#/Validator/produceBlockV3 for reference

So CLs can handle 8192 deposits but what about more? Can we bump the limit in hegota? Assuming a deposit costs 42k gas, we'd run into this problem at 350M gas limit.

Replying to "So CLs can handle 81..." The idea is to yeet the limit using stable containers

Replying to "So CLs can handle 81..." people don't like my way of thinking about this, but I think we should make it infinite and if someone uses this to attack the chain we fork and burn that eth

Replying to "So CLs can handle 81..." this is needed in hegota then. I wouldn't say stable containers is the simplest solution, e.g. could we just bump

Replying to "So CLs can handle 81..." is it worth the effort to bump the number?

https://github.com/shane-moore/beacon-APIs/pull/10 For adding blinded execution payload envelope in stateful block production path

I'm happy with that change. Just doing the most simple thing, bumping the number.

Replying to "I'm happy with that ..." why does it need to change at all? isn’t 8k enough?

proofs aginst the beacon roots may need to change

Replying to "I'm happy with that ..." it isn't if we raise the gas limit

I agree with Barnabas

if we do not ship stable containers we change it

Reacted to "if we do not ship st..." with 👍

Replying to "if we do not ship st..." Yes

Replying to "I'm happy with that ..." is the fear that someone will make 10k deposits in a single slot, and a chunk of them fail?

Replying to "I'm happy with that ..." It is much more than needed but we cannot limit in on the EL but need to account for worst-cases that go beyond 8192

Reacted to "I agree with Barnaba..." with 👍

Reacted to "if we do not ship st..." with 👍

https://github.com/ethereum/execution-apis/pull/764 https://github.com/ethereum/execution-apis/pull/793

Reacted to "if we do not ship st..." with 👍

"Rethinks everything" is a bit much, its not really different

It is not that hard to move to Marius PR

Reacted to It is not that hard ... with "👍"

Replying to "I'm happy with that ..." The fear is that someone will send a ton of deposits and DOS the chain cause the CL won't be able to process all the signatures in time. But whomever does this will risk constantly thousands of ETH that is locked for months and it's a trivial fork to burn it

Replying to "lh has a bug that pr..." @Potuz we missed `payload_data_is_available` in our `should_extend_payload`

Reacted to "It is not that hard ..." with 👍

The tradeoff for prysm is that we need to do more work implementing a client that uses vanilla http vs importing geth’s client, but we have an api client package that this should fit into well enough. I like the more aggressive option because we can deprecate json-rpc at hegota.

Barnabas AI prefers mine :P

We have benchmarks for Barnabas’s implementation

We’re about to add them in the PR description implementing it https://github.com/lambdaclass/ethrex/pull/6710

Replying to "" hmmm but without this why did you get true as result? was the PTC voting yes for timely and no for available?

I don’t expect a huge diff in perf between the two

Tbh I don't care too much either, it should just go in

Replying to "I'm happy with that ..." so so many 1 eth deposits that the OOM CLs that can’t process them in time because they can only do 8k? Seems low probability enough that i’d take the dos risk and not mess with the constant at all to me… (but probably low information/weakly held view)

Loool I got Pari in my club!

Replying to "I'm happy with that ..." oh no! the constant is a different thing

Potuz just wants to take the bikes out of the shed and ride!

Just closed 764 in favor of 793

Replying to "I don’t expect a hug..." We’d need some CLs to implement Marius’s to have some real numbers for it

Replying to "I'm happy with that ..." the constant always needs to be larger than the maximum legal EL block

Replying to "I'm happy with that ..." otherwise there's a deadlock in the chain

🚲🛖

Replying to "Just closed 764 in f..." Please everyone implement 793

Reacted to "🚲🛖" with 🚲

Reacted to "otherwise there's a ..." with 🫡

Reacted to "the constant always ..." with 👍🏽

we'll let you know when we've got one potuz

Replying to "lh has a bug that pr..." yes, that's what I think happened but not 100% confirmed, but it seems like the ptc voted against data being available but payload timely

Replying to "" if that's happened I really want to know it may be a general bug in clients. I'll ask now in the meeting

Reacted to "Please everyone impl..." with 👍

how deep can we reorg?

As deep as we want 😄

Its a config variable

Assertor has a notion of time and slots, so it can keep track

https://discord.com/channels/595666850260713488/892088344438255616/1506975822513442896

Replying to "Its a config variabl..." Can we test this: https://eips.ethereum.org/EIPS/eip-8252

We set them on the deadline and if blobs have arrived by then, we set the flag

Replying to "Its a config variabl..." or test, many days being reorged, e.g.?

interesting, Lodestar for sure sends the attestations early

cause I get them sometimes even before the beacon block!

Replying to "Its a config variabl..." Yeah no reason we can’t 😄 can we also modify the values to make the test faster to avoid super long networks?

https://forky.glamsterdam-devnet-4.ethpandaops.io/

Is there any CL client that already implements 793?

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

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

Replying to "lh has a bug that pr..." @Potuz lodestar should vote correctly here, we also have `PAYLOAD_DUE_BPS` implemented for separate deadlines (configurable via config)

Replying to "" ah nice! now I need just one more

Replying to "" ok so it may be Prysm that is voting incorrectly, will check that endpoint, it'd be nice to confirm your parent block had this situation

Replying to "https://eips.ethereum.org/EIPS/eip-8148" https://github.com/ethereum/consensus-specs/pull/4901

Is there an argument against just using 0x02 with todays ceiling and executing withdrawals manually? That’s sort of hacking in custom ceiling

I’d merge this idea with removing maxEB upper bound.

If we do a custom ceiling, there is no real reason to limit it with 2048 ETH imo

Reacted to "If we do a custom ce..." with 👍🏽

they can't on pools

they don't own the withdrawal address

Reacted to "If we do a custom ce..." with 👍🏽

The protocol shouldn’t be concerned of your cashflow.

Can we bundle this with halving issuance?

Reacted to "Can we bundle this with halving issuance? " with 😂

Reacted to "Can we bundle this w..." with 👍

Reacted to "Can we bundle this w..." with 😂

Reacted to "Can we bundle this w..." with 😂

Reacted to "Can we bundle this with halving issuance? " with 😂

stupid question, but why write the threshold into EL storage vs CL?

Reacted to "Can we bundle this w..." with 😂

Reacted to "Can we bundle this w..." with 🔥

Reacted to "Can we bundle this w..." with 😂

Reacted to "Can we bundle this w..." with 😂

Replying to "stupid question, but..." Could live in CL.

Replying to "stupid question, but why write the threshold into EL storage vs CL?" i mean the sweep is on the CL so feels like it should be there

Replying to "stupid question, but..." I suspect it makes it easier for pools to track this

Replying to "stupid question, but..." ask this please

Replying to "stupid question, but..." I assume it's about the contract handling this

Replying to "stupid question, but..." yeah each validator has a new value

Replying to "stupid question, but..." I guess it goes in the beaconstate?

Replying to "stupid question, but..." yeah there's a new slice (or you can modify the validator slice) both of them were speced out

Replying to "stupid question, but..." Can we do this as an optional field?

Replying to "stupid question, but..." Yeah, it's 8 bytes of beaconstate per validator (~8MB today)

Replying to "stupid question, but..." I thought Matt was asking why not send the message in the CL instead the EL

would be nice to simplify it

like, no EL requests, no txs, write directly to the CL state

Makes sense yeah. Thanks

I know it’s a bit out of order, but could we decide the fate of the remaining glammy CL EIPs? Suggested decisions could be: 8080 - CFI -> DFI 8061 - CFI -> SFI 8045 -> CFI -> DFI (possibly move to hegota CFI list?) 7688 - CFI -> SFI or CFI -> DFI

Dima told me 75% have less than 32ETH

but that includes surely the limit of 12 keys set originally

so I'd expect a lot of them to have 12 keyus

To me this still feels too much complexity for too little number of users.

Reacted to "To me this still fee..." with 👍

Reacted to "To me this still feels too much complexity for too little number of users." with 👍

On the other hand I did look in early drafts of this EIP and it does seem very simple to implement

Reacted to "On the other hand ..." with 👍

Reacted to "On the other hand I did look in early drafts of this EIP and it does seem very simple to implement" with 👍

I'm just skeptical on the usage and whether this can be handled out of the protocol

I get it now, this is mirroring 7002. Feel like a lot of touched surface (EL, CL, Requests). Would be great to have a % how much of the stake would adopt this.

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

We kind of ‘pre-dfi-ed’ this in Svalbard.

no auto CFIs

those are two things. You can propose it for hegota

needs to be reproposed for Hegota

This is why it would be important to make a call on DFI these now

Replying to "We kind of ‘pre-dfi-..." blog post made it sound pretty final

which one?

Replying to "which one?" 8061

ahh we've already implemented and tested all of this

taking it out is a mess

Reacted to "ahh we've already implemented and tested all of this" with 👍

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

Replying to "https://eips.ethereu..."

“EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window only”

Can any other CL also pls take a look?

Replying to "https://eips.ethereu..." We have worked on it in Teku and we have a stale implementation

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

Reacted to "https://eips.ethereu..." with 👍

I think we should keep it in Gloas!

Reacted to "I think we should ..." with 👍

Reacted to "I think we should ke..." with 👍

Reacted to "I think we should ke..." with 👍

7688 is also related to max deposits and raising gas limit

Replying to "https://eips.ethereu..." Soldogn blog: “EIP-7688 (SSZ stable containers) remains in Glamsterdam scope but is held out of glamsterdam-devnet-1 while the team works through bounded gossip-message size for attestations under progressive lists.”

Well there’s the alternate option of just bumping limits

we haven't rebased 7688 - if we set a devnet date we can do it

true but this could be solved in simpler ways by just bumping the limit

What was the argument for this EIP? Mainly to have stable proofs against the beacon root?

Replying to "Well there’s the alternate option of just bumping limits" Up to which limit?

i think just keeping the CFI / SFI / DFI lists up to date do the work of signaling to devs which are still in contention

Reacted to "i think just keepi..." with 👍

Stable devnets before stable containers

Reacted to "Stable devnets befor..." with 👍

Reacted to "Stable devnets befor..." with 👍

Reacted to "Stable devnets befor..." with 👍

Reacted to "Stable devnets before stable containers" with 👍

Does anyone have an intuition how long it takes to implement?

Reacted to "Stable devnets before stable containers" with 👍

Reacted to "Stable devnets befor..." with 👍

Replying to "Does anyone have an ..." It should be done in most clients, just probably stale implementations

Reacted to "Stable devnets befor..." with 👍

Reacted to "Stable devnets befor..." with 👍

https://github.com/eth-protocol-fellows/cohort-seven/blob/main/projects/project-ideas.md

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

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

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

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

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

Replying to "stupid question, but why write the threshold into EL storage vs CL?" i think i misunderstood it

I feel like we tried this before and no one came

Works for europe

How many people PST?

having ACDs at different times is gonna confuse people lol

Replying to "I feel like we tried..." It will be different, according to some Aussie/nz folks

Reacted to "having ACDs at different times is gonna confuse people lol" with 👍

not opposed just pointing out

Reacted to "having ACDs at diffe..." with 👍

We’ve tried this in the past as well

Reacted to "having ACDs at different times is gonna confuse people lol" with 👍

Not easy to solve

Reacted to "Not easy to solve" with 👍

and did more people show up?

Reacted to "Not easy to solve" with 👍

Is 1100 UTC the latest possible time for people in AEST?

Terence will be gone

is it a permanent move?

people in the west US

Replying to "is it a permanent mo..." ye permanent

and Lighthouse crowd and some Teku people will come

Is terence here now?

i like that idea

Terence is on vacations for the first time in 10 years

Reacted to "Terence is on vacations for the first time in 10 years" with ❤️

Not a CL dev but I won’t be able to make it

Reacted to "Terence is on vacati..." with ❤️

Reacted to "Terence is on vacations for the first time in 10 years" with ❤️

Reacted to "Terence is on vacati..." with ❤️

Reacted to "Terence is on vacations for the first time in 10 years" with ❤️

Reacted to "Terence is on vacati..." with ❤️

Reacted to "Terence is on vacations for the first time in 10 years" with ❤️

Reacted to "Terence is on vacati..." with ❤️

Replying to "Terence is on vacati..." Since when is that an excuse 😂

Reacted to "Terence is on vacati..." with ❤️

Reacted to "Terence is on vacati..." with ❤️

nooo

Reacted to "Since when is that a..." with 😁

Reacted to "Terence is on vacati..." with ❤️

Reacted to "Terence is on vaca..." with ❤️

Can you repeat the new timing please?

11 UTC

FWIW that timing is perfect for me :)

Reacted to "FWIW that timing is perfect for me :)" with 🎉

How many trials are we gonna have?

Reacted to "How many trials are we gonna have?" with 😆

australia people, get your people to show up

low stakes to try out a new time, why not?

55 people here today

next call we ship like crazy

Reacted to "next call we ship like crazy" with 😆

Reacted to "next call we ship li..." with 😆

Reacted to "next call we ship li..." with 😆

Reacted to "Terence is on vacati..." with ❤️

Reacted to "next call we ship like crazy" with 😆

what if we move australia closer to europe?

Replying to "55 people here today" I don’t think the raw number of ppl should be the deciding factor

Reacted to "what if we move aust..." with ☝️

Reacted to "what if we move aust..." with 🧠

Reacted to "what if we move australia closer to europe?" with ☝️

Reacted to "what if we move australia closer to europe?" with 🧠

Reacted to "what if we move aust..." with 🧠

Reacted to "what if we move australia closer to europe?" with 🧠

Reacted to "what if we move aust..." with ☝️

Reacted to "what if we move australia closer to europe?" with 🧠

Reacted to "what if we move aust..." with ☝️

Reacted to "what if we move aust..." with 🧠

Se ha reaccionado a "what if we move au..." con 🧠

Se ha reaccionado a "what if we move au..." con ☝️

Reacted to "next call we ship li..." with 😆

Reacted to "what if we move au..." with 🧠

Reacted to "what if we move australia closer to europe?" with ☝️

gg

Reacted to "what if we move aust..." with 🧠

Reacted to "what if we move aust..." with 🧠

why is it all the way down there

Reacted to "what if we move aust..." with 🧠

Reacted to "what if we move aust..." with ☝️

Reacted to "what if we move aust..." with 🧠