AllCoreDevs - Consensus #183

gm

gmgm

gm

gm

gm gm

We found some beacon api performance issues which are nice

Have we checked bid spamming? Eg sending 1000+ bids, each 1 gwei greater in value?

Replying to "Have we checked bid ..." Not yet afaik

we have 500k exited validators

Replying to "Have we checked bid ..." It's not easy because each builder can only bid once per slot. So we have to deposit a few thousand builders to stress test it

Replying to "Have we checked bid ..." Ah yeah that’s true.

https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8 is not yet public, probably, intentionaly

Replying to "https://notes.ethere..." ah this is a bug when using the api

Replying to "https://notes.ethere..." will fix

Discussion is in the epbs channel, please chime in

Can we set a soft deadline?

Reacted to "Discussion is in the..." with 👍

I have been OOO past week, but will get up to speed today and tomorrow.

Reacted to "Discussion is in the..." with 👍

https://github.com/ethereum/beacon-APIs/pull/630 for more eyes

Replying to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8 is not yet public, probably, intentionaly" ty! i see it

do clients have circuit breaker implementations? that seems higher prio than out of protocol stuff

Replying to "https://notes.ethere..." It should be public now

The invalid payloads should be fixed. Do you still see invalid payloads?

https://discord.com/channels/595666850260713488/1364000387195076608/1527979143881429153

sorry, mic acted up. For LH, i dont think we ahve something wrt circuit breaker yet

🚢 🐻‍❄️ 🛳️

https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8

Reacted to "https://notes.ethe..." with 🔥

Reacted to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" with 🔥

Reacted to "https://notes.ethere..." with 🔥

Reacted to "https://notes.ethere..." with 🚢

Reacted to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" with 🚢

Request to add approval to move Glamsterdam EIP to Review

Reacted to "https://notes.ethere..." with 🔥

Reacted to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" with 🔥

Reacted to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" with 🚢

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

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

Replying to "https://notes.ethere..." So just nw changes on el?

Replying to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" there should be the 7997 "change" (depending on the client)

Replying to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" we wanted to discuss this on acdt on monday

Replying to "https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-8" https://discord.com/channels/595666850260713488/688075293562503241/1529721797434671114

think it would be good to couple it with the fork anyway

Reacted to "think it would be good to couple it with the fork anyway" with 👍

at least make it required for heze

Reacted to "think it would be good to couple it with the fork anyway" with 👍

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

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

New delayed state root alternative: https://github.com/ethereum/EIPs/pull/11936/changes

@Stefan Starflinger you’re here: are we withholding blobs? Slot 64824 Prysm was hung because we never got the columns

Reacted to "think it would be good to couple it with the fork anyway" with 👍

It’s not clear it’s our fault or clients that aren’t replying to our requests

Reacted to "New delayed state root alternative: https://github.com/ethereum/EIPs/pull/11936/changes" with 😃

Replying to "@Stefan Starflinger ..." No we are not actively witholding blobs

oopsie

gm

gm lol

LOL

Someone didn't like Toni's proposal?

https://github.com/ethereum/EIPs/pull/11936/changes

Thanks for making asset processing a pain in the backside later 😛

we're just stress testing forkcast

Reacted to "we're just stress te..." with 😄

Reacted to "we're just stress te..." with 😄

Reacted to "we're just stress testing forkcast" with 😄

Reacted to "Thanks for making as..." with 😅

Reacted to "we're just stress testing forkcast" with 😄

Replying to "we're just stress te..." lol bad time for stress testing forkcast XD

Tx root is the ssd root?

what about block hash?

Ssz root?

Reacted to "Ssz root?" with ❤️

forkcast also has bad habit of outsourcing all its stress to me

Replying to "Ssz root?" that's 7807 (PFI next week as non-headliner)

Reacted to "Ssz root?" with ❤️

is that a non-headliner or headliner scope?

Could you share the link of the eip ?

would you need to compute the state root before revealing the BAL?

Quantitatively, how much of an optimization is this?

@pari if we have 5 min at the end, I would love to talk a bit about the rest-ssz spec

Reacted to "@pari if we have 5 min at the end, I would love to talk a bit about the rest-ssz spec" with ❤️

Reacted to "@pari if we have 5 min at the end, I would love to talk a bit about the rest-ssz spec" with ❤️

Reacted to "@pari if we have 5..." with ❤️

Reacted to "@pari if we have 5 min at the end, I would love to talk a bit about the rest-ssz spec" with ❤️

Reacted to "@pari if we have 5 m..." with ❤️

Replying to "Ssz root?" with SSZ block header we don't need the engine API to obtain it

newPayload already does this, though

Répondre à "would you need to ..." if we assume we might want to separate the BAL and the payload

like, it has INVALID_BLOCK_HASH if it's wrong

Not for the hash it checks the consistency though

Could you share the link ?

https://github.com/ethereum/EIPs/pull/11936/changes

But yeah, we can just check consistency on the receival of the envelope and that’s it…

There's a sort of debugging/tooling aspect here of, CLs being able to log blockhash to identify unambiguously which block it's sending to newPayload etc

I will leave editorial review on these EIPs asap

Problem is for blocks that arrive and the node doesn’t have the parent envelope yet

Reacted to "I will leave editorial review on these EIPs asap" with ❤️

Reacted to "I will leave editorial review on these EIPs asap" with ❤️

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

Lol its succession today

Replying to "https://github.com/e..." I think this would be nice & simple start to PQ-ifying the protocol.

Reacted to "Lol its succession today" with 😂

Reacted to "Lol its succession t..." with 😂

Reacted to "I think this would be nice & simple start to PQ-ifying the protocol." with 👍

The original hash onion: https://eth2book.info/capella/part2/building_blocks/randomness/#the-old-hash-onions

Reacted to "The original hash onion: https://eth2book.info/capella/part2/building_blocks/randomness/#the-old-hash-onions" with 👀

Reacted to "The original hash ..." with 👀

Few questions: Why do this now, when everything else is still quantum vulnerable? Are we even sure that we’ll be using RANDAO in 3-4 years? Even if so, why don’t we wait until the validator set is much smaller?

The stored state changes with each usage, so this does not lend itself to reuse easily.

Reacted to "The original hash on..." with 👀

Reacted to "Few questions: Why do this now, when everything else is still quantum vulnerable? Are we even sure that we’ll be using RANDAO in 3-4 years? Even if so, why don’t we wait until the validator set is much smaller?" with 👍

Another point is we might not even use committees in the future (though a shuffle could still be useful for the proposer selection)

Potuz: rotating BLS keys with very small lifetime don't quite work for the RANDAO usage.

historically, iterative worked better

Replying to "Potuz: rotating BLS keys with very small lifetime don't quite work for the RANDAO usage." why is that?

Iterative feels much better

I disagree with Kev on that statement, but @Gottfried Herold rotating per finalized epoch does

Reacted to "historically, iterat..." with 👍

Reacted to "Iterative feels much..." with 👍

Reacted to "historically, iterative worked better" with 👍

(because the users can choose the pubkey; you would need to have users choose pubkey with a delay, which is not good for the PQ use case)

Reacted to "Iterative feels mu..." with 👍

Reacted to "historically, iter..." with 👍

Reacted to "Iterative feels much..." with 👍

Reacted to "historically, iterat..." with 👍

@Gottfried Herold the point is that rotating is deterministic, the users cannot choose the key

If deterministic, then it would work, yes.

That’s my proposal, the deterministic derivation depends on a committed PQ safe key

Ah, OK.

Yes, this approach is my favorite,

That’s why I believe all this is premature

Generally agree with the iterative approach, but I agree it feels premature

Iterative makes sense once the final approach is established

Reacted to "Iterative makes sens..." with 👍

It doesn’t make sense to put us on a path enshrining the first iteration when the final approach is not decided

Reacted to "Iterative makes sens..." with 👍

Reacted to "It doesn’t make sense to put us on a path enshrining the first iteration when the final approach is not decided" with 👍

Reacted to "It doesn’t make s..." with 👍

Reacted to "Iterative makes se..." with 👍

Replying to "It doesn’t make sens..." still, having the EIP as a documentation of the current research makes sense, even if it doesn't go beyond H* PFI initially

Reacted to "still, having the EIP as a documentation of the current research makes sense, even if it doesn't go beyond H* PFI initially" with 👍

Reacted to "Iterative makes sens..." with 👍

I mean, an alternative (just for RANDAO) would be signing the epoch number (like we do today) with a (static) pubkey of a determinstic signature scheme and authenticate the static pubkey with a fixed slote of the PQ signature scheme. The latter is a one-time scheme, but that is fine because you always authenticate the same static pubkey. This avoids adding data to state...

Replying to "There's a sort of de..." I believe the execution payload already contains the block hash and the engine api validates it. I suppose the main change here is that in the time between the bid and the payload reveal the state root and block hash are unknown - instead there will be some other partial commitment digest that could be used.

exactly

Reacted to "still, having the EI..." with 👍

Replying to "I mean, an alternati..." Yes this is precisely what I want to do but even for attestations so that we keep attestations being aggregatable by everyone

Reacted to "I believe the execution payload already contains the block hash and the engine api validates it. I suppose the main change here is that in the time between the bid and the payload reveal the state root and block hash are unknown - instead there will be some other partial commitment digest that could be used." with 👍

xmss is stateful, signing requires writing to flash, no?

IMO It would be better to have all the PQ schemes finalised (including particular hash function etc) before including anything to the protocol.

Replying to "There's a sort of de..." Yes, I think this is the cleanest that we validate it on new payload, but the problem is that implementations do use the has committed and not necessarily revealed

Reacted to "IMO It would be better to have all the PQ schemes finalised (including particular hash function etc) before including anything to the protocol." with 👍

Replying to "I mean, an alternati..." I mean, for the RANDAO usecase, we don't even have aggregatibility or efficiency as really critical requirements.

Reacted to "It doesn’t make sense to put us on a path enshrining the first iteration when the final approach is not decided" with 👍

Reacted to "still, having the EIP as a documentation of the current research makes sense, even if it doesn't go beyond H* PFI initially" with 👍

Replying to "I mean, an alternati..." Sure, but the same system described above: deterministically generating a BLS pair for example, would work for both

Replying to "I mean, an alternati..." I agree. *If* we go for the BLS route, this seems the right thing. But the approach works with a non-BLS scheme even if we don't.

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

I see yes, in practice I guess this sort of introduces two “primary keys” / identifiers for a single payload which does add some complexity. My main motivation behind suggesting this change is that I think the 7862 delayed state root proposal is quite invasive and impacts state proof latency which could have practical implications for cross chain messages and light clients. I think the net complexity of this solution is lower. In regards to the prover stack the post state root contributes approximately ~10% of the proving workload - I don’t think the 7862 complexity justifies a 10% proving hot path reduction imo.

Technically, would this reduce state growth? 😄

Replying to "Technically, would t..." it reduces state size, it doesn't slow down future growth

Replying to "Technically, would t..." So yes, technically lol

https://github.com/ethereum/pm/issues/2157#issuecomment-4981597977

Reacted to "Yes, I think this is the cleanest that we validate it on new payload, but the problem is that implementations do use the has committed and not necessarily revealed" with 👍

Reacted to "https://github.com/ethereum/pm/issues/2157#issuecomment-4981597977" with 👍

# Still used (according to LH) - eth_syncing - eth_getBlockByNumber - eth_getBlockByHash - eth_chainId # used in eth1 deposit path - eth_blockNumber - eth_call - eth_getLogs # unused - eth_getCode - eth_sendRawTransaction

[Prysm] # Still used eth_getBlockByNumber eth_getBlockByHash eth_chainId # used in eth1 deposit path eth_call eth_getLogs # unused eth_blockNumber - using eth_getBlockByNumber instead eth_syncing eth_getCode eth_sendRawTransaction

Replying to "# Still used (acco..." note that all listed under "used in eth1 deposit path" are already dead code for LH

Replying to "# Still used (accord..." ^ same for Prysm

https://github.com/ethereum/pm/issues/2158#issuecomment-5059393845