AllCoreDevs - Testing #083

gm

gm

gmgm

gm

gm

Pandas rolling in [Full message cannot be displayed on this version]

Reacted to "Pandas rolling in" with 🥹

Reacted to "Pandas rolling in [F..." with 💌

ga! 🌊

Reacted to "Pandas rolling in" with 🥹

gm

Reacted to "Pandas rolling in" with ❤️

ACDT #83 https://github.com/ethereum/pm/issues/2116

🗳️ EIP-8282 builder deposits - go/no-go for Gloas (separate deposit path) https://github.com/ethereum/EIPs/pull/11760 https://github.com/ethereum/consensus-specs/pull/5359 https://github.com/ethereum/sys-asm/pull/43 https://github.com/ChainSafe/lodestar/pull/9507 https://eips.ethereum.org/EIPS/eip-8254 @jtraglia @wemeetagain @ensi321 @markolazic01 @potuz @nerolation

https://github.com/jtraglia/kurtosis-devnets/tree/master/gloas-deposits

Can client teams pls estimate implementation of this change of logic? I assume most of the heavy lifting will need to be done on the CL side. Also would like to hear how much extra work needs to be done on the EL side.

Was there a solution that didn't involve sys contracts and why is the latter preferred here?

How much delay (in weeks) will 8282 approx be?

Yeah, that relative point is key for me, regarding that this ... (hi Toni) delay narrative I don't buy because getting the caching right needs a lot of testing too

there's this implicit assumption that there's a base amount of time in the status quo, and it's that plus just extra effort for this EIP

Could “quite complicated” have a time factor attached to it?

I hope this is mostly testing overhead

Agree with dustin - we have to do one or the other solution anyway. I also agree this feels like the right solution to the deposit/scaling problem: * split validator and builder deposits * bump the SSZ limit for validators (not builders)

I also don”t think its super complex (Marius)

SSZ limit: EIP-7688

Reacted to "SSZ limit: EIP-7688" with 🔥

I still believe 7688 >> bumping ssz limit

what’s the timeline for this change?

typically we audit the system contracts

Which devnet are we targetting for this?

I’d propose glam-devnet-7

Reacted to "I’d propose glam-..." with 🔥

I think we will have to audit the contract (Marius)

Shouldn’t be a blocker for devnet testing ?

Reacted to "I think we will have to audit the contract (Marius)" with 👍

Reacted to "I think we will have..." with 👍

Reacted to "Shouldn’t be a block..." with 👍

Yeah, especially with invalid sigs, the fallbacks get tricky

Replying to "I think we will have to audit the contract (Marius)" no, just something we should expedite if ACD wants to do it

There are only heuristics

Replying to "I think we will have to audit the contract (Marius)" and accept it will add some time

and pathological cases thereof

Replying to "I think we will have..." According to Justin and Pari, it takes 1-2 months to get an audit

Yeah agreed. We need to have it audited before we ship it to first testnet

Replying to "Could “quite complic..." I mentioned it in the STEEL channel but I only reviewed the system contract part, so I cannot represent the team's full perspective. Also, I am not very familiar with the testing of past system contract, there may already be mature testing framework support that I'm not aware of.

To put numbers on what Terence’s saying: the attacks that are being mentioned cost the attacker the same that would cost him to buy ALL blocks in Ethereum for the next 19 years.

Reacted to "To put numbers on ..." with 💸

Reacted to "To put numbers on wh..." with 💸

Then it’ll be 38 years worth of blocks

we have to include CLs in the gas limit benchmarking if we don't go with 8282

Reacted to "To put numbers on wh..." with 👍

Replying to "To put numbers on ..." This only matters if it means the caching doesn't need to be tested and implemented

Replying to "we have to include C..." We already do, propagation timing is now part of the limit

Replying to "To put numbers on ..." Just ignore it is not a solution

Agreed, I’m just trying to sell the eip (convince you all why it’s necessary) — justin

I vote to do it right now

Reacted to "I vote to do it ri..." with 👍

Reacted to "I vote to do it righ..." with 👍

Correctness pls

Reacted to "I vote to do it righ..." with 👍

This will likely push the fork to dec this year btw

Reacted to "I vote to do it righ..." with 👍

always correctness

Correctness

I think it’ll mostly go to 2027

correctness

🫩

Replying to "This will likely pus..." I don’t think so… (m)

And I’m happy to hear people prefer to do the right thing instead of the fast one

Can we ship EL before this?

Reacted to "I vote to do it right now" with 👍

Replying to "This will likely pus..." I think so (pari)

Reacted to "Can we ship EL before this?" with 👀

Reacted to "Can we ship EL befor..." with 👀

Replying to "Can we ship EL befor..." No, pricing depends on the scaling

Replying to "Can we ship EL befor..." That you get from ePBS

Replying to "This will likely pus..." The verification can be done in parallel to the other testing that we need to do (M)

Replying to "Can we ship EL befor..." Not really

2 forks per year 🧐

Replying to "Can we ship EL befor..." We could ship the EIP changes assuming 3s execution

Replying to "2 forks per year 🧐" 0 == 2

Replying to "Can we ship EL befor..." You’re already increasing the block size by 50–100%

Replying to "I think it’ll mostly..." What’s the most delay coming from from your perspective?

Reacted to "0 == 2" with 😆

已使用😆回应"0 == 2"

if it works like the withdrawals+consolidations, they will stay queued until the fork right>

Replying to "Can we ship EL befor..." It’s not only execution, the bottleneck is broadcast

Replying to "Can we ship EL befor..." And you now have 2 seconds not 3

Replying to "I think it’ll mostly..." history

We can tweak data if needed for smaller block but lets not wait for ePBS

Replying to "if it works like the..." ?

Replying to "if it works like the..." yes

Replying to "if it works like the..." should work exactly the same

Replying to "I think it’ll mostly..." Fulu first testnet was launched in September

maybe we could avoid deploying in advance and instead do it with the fork?

you're not getting queued deposits before the fork. they're unqueued by the system call from the fork onwards

earlier deposits would be queued on the EL side. CL has no access

Does this really delay epbs by 3 months?

Erigon appears to be creating invalid BALs blocks. today.

(re "finishing line")

are we really starving for more gas today/this year?

Replying to "Can we ship EL befor..." 150M should be feasible without CL changes

Reacted to "150M should be feasi..." with 🛳️

yea, with the gas adjustments I got to 216M gas for 8192 deposits

Replying to "Can we ship EL befor..." I thought 200m is feasible without CL changes (m) 100mgas per 2s ish

I agree with potuz

I think we need better understanding of timing game elastic demand

I completely agree with this

Just not the gas limit increase

is zk proving that time-critical to ship asap?

(i.e. in X months)

There’s also invalid blocks

Reacted to "There’s also inva..." with 👍

I don’t think 8282 is going to add 3 months to glamsterdam btw, maybe 3-4 weeks. — justin

Does anyone have a good estimate for the timeline impact of EIP-8282 from the EL perspective? From the CL side, I don’t think this is too bad, but I understand EL may be different

Replying to "Does anyone have a g..." ELs are saying they are ready almost

Reacted to "I don’t think 8282 i..." with 👍

Replying to "Does anyone have a g..." so shouldn’t matter?

I don’t think the CL side is easy, last time we changed and rushed to merge these changes in the CL-spec repo a ton of bugs were introduced in the spec

Replying to "Does anyone have a g..." Almost none the only impact would be because of the security review

Is auditing a big part of the whole thing?

This needs o be reviewed and Justin’s branch has thousands of lines of changes

This will delay the fork in a non-trivial way

Replying to "Does anyone have a g..." 1-2 mo

Replying to "This needs o be revi..." Thousands of lines??

Blocks would on avg be bigger. Worst-case blocks would also be bigger and an increasing gas limit would contribute to that. Note, that the data repricing would improve the situation again because data will be 60% more expensive too. I think we can do 200-300M blocks with today's attestation deadline.

Replying to "Does anyone have a g..." Sure but if it’s a few weeks then id say just wait. Hard fork itself has a coordination cost as well

Replying to "This needs o be revi..." Your PR was +1K when you opened it

Replying to "This needs o be revi..." testing

📦 SSZ-ify the Engine API (EL) - status + unblock Marius's PR, get client teams implementing https://github.com/ethereum/execution-apis/pull/793 @barnabasbusa @MariusVanDerWijden

Replying to "This needs o be revi..." the cl spec side is simple/minimal

Replying to "This needs o be revi..." Needs to be reviewed, whatever it is

prysm: ethpandaops/prysm-beacon-chain:syjn99-prototype-ssz-over-http

Replying to "This needs o be revi..." Ya but that’s weeks not months right

Replying to "Can we ship EL befor..." Another important point to this decision is that we want to give the community enough time to adapt repricings. So, even though the client dev work may be done, we should give for the ecosystem to work through the impact

Replying to "This needs o be revi..." Yeah I don’t think this will delay months the fork

Replying to "This needs o be revi..." But it’s a non-trivial amount and yeah I also think it’s of the order of weeks

Reacted to "prysm: ethpandaops/prysm-beacon-chain:syjn99-prototype-ssz-over-http" with 👍

Replying to "This needs o be revi..." If it’s “weeks” then EL should just wait. Forking itself has a coordination and testing cost. They will spend more on that rather ship together (I think)

https://github.com/ethereum/execution-apis/pull/793#issuecomment-4706520975

Why fork names should be mentioned there

Reacted to "Why fork names shoul..." with 👍🏼

🔧 glamsterdam-devnet-5 - salvaged; bugs fixed, net recovered https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-5 @barnabasbusa

I kept trying to understand why Justin signs his messages given that his picture is there and only now read the name Berlin People.

Replying to "Can we ship EL befor..." Ecosystem mostly learn about features when it hit the testiest, when EIP is under development they don’t know if EIP is going to be removed or not.

Reacted to "I kept trying to und..." with 😄

Replying to "Why fork names shoul..." I don’t like this either but not I hill I would die on

Reacted to "I kept trying to understand why Justin signs his messages given that his picture is there and only now read the name Berlin People." with 😄

wasn’t it for a payload that was missing?

Are we getting the data columns before the block and pending queue is not working as expected?

Reacted to "If it’s “weeks” then..." with 👍

Reacted to "If it’s “weeks” then..." with 👍

Replying to "wasn’t it for a payl..." Over gossip we get the payload and then we fail to get the columns

Replying to "wasn’t it for a payl..." That drops us from syncing cause the chain advances over that payload

do we want ssz engine changes for all forks or only for amsterdam forward?

we should aim for next monday

imo

unify the devnets

there are no EL devnets

EL tracker for glamsterdam-devnet-76 https://github.com/ethereum/execution-specs/issues/2915

Replying to "EL tracker for gla..." 6*

Replying to "do we want ssz engin..." I think it’d be great to support from fusaka, just because we have stable codebase running on rn and it seems like orthogonal with forks.

can we make the call for 8282?

Let’s put it in

Replying to "EL tracker for glams..." lulz

Reacted to "can we make the call..." with 🛳️

Reacted to "can we make the call..." with 🛳️

Replying to "can we make the call..." Don’t wanna wait till thursday for this

We can start working on it even if there’s no call on it

Sure lets add it! haha

Replying to "can we make the call..." are we clear on how much of a threat the dos is?

It’s just replacing the current one

Replying to "can we make the call..." yeah pretty clear at this point I’d say

Replying to "can we make the call..." There’s no threat justin

Replying to "can we make the call..." The attack does not really exist

Replying to "can we make the call..." But it’s a good EIP nonetheless

Replying to "can we make the call..." lol

Reacted to "I don’t like this ei..." with 🤷

Is there a breakout on the CL side?

Can u throw me in cl breakout pls