AllCoreDevs — Execution #238

Gm

Gmgm

Gm

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

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

Due to the config drift, I’d prefer if we just had one track going forward

https://dora.glamsterdam-devnet-5.ethpandaops.io

Engine API change: https://github.com/ethereum/execution-apis/pull/796

also make sure you have https://github.com/ethereum/execution-apis/pull/786

+1 for merged devnets now 😄

Bal-devnet-7 is good for benchmarking

So we can keep it around for that

Reacted to "+1 for merged devnet..." with 👍

Will we have the deterministic deployer factory (Arachnid using Nick's method) on glam devnet 6? @pk910 I assume we won't have it in devnet 5?

IMO we should just bite the bullet now and move that over too. One branch everyone works on so we can focus on shipping glammy.

Yeah we haven’t added in devnet 5 as agreed on the acdt

Replying to "Will we have the det..." cool!

Reacted to "IMO we should just b..." with ➕

Reacted to "IMO we should just b..." with ➕

Replying to "Will we have the det..." Thanks

Replying to "IMO we should just b..." max pain, max gain

https://github.com/ethereum/execution-specs/issues/2915

I think no time yet

Everything :)

8246

if we are going to a single devnet, did we set a date for that?

Replying to "if we are going to a..." ±2w

https://github.com/misilva73/evm-gas-repricings/blob/main/reports/eip-8038/runtime_estimation/2026-05-01_2026-05-08_interop/new_gas_proposal.md Latest numbers from Maria for 8038 here. But we still need to re-take them with the latest optimizations. I’d not include in any glam devnet so far

glamsterdam eip list in case helpful: https://docs.google.com/spreadsheets/d/1ifXjsiFFzQW8s1gl4Gz3kVDKE2pvTMkPslHuE3U7Nqk/edit?usp=sharing

Sparse blob pool is optional afaik so we can mark it as is

how big is it on the EL?

Replying to "glamsterdam eip list..." + https://forkcast.org/upgrade/glamsterdam/devnet-inclusion

Also I want to add that we are very very far away from Blobs propagation being an issue

On mainnet

Reacted to "Also I want to add that we are very very far away from Blobs propagation being an issue" with 👍

I think epbs security >> blob optimizations right now

wait for numbers and then include them in the next devnet, likely 6, I'd say

Reacted to "I think epbs securit..." with 👍

Heeft gereageerd op "wait for numbers a..." met ➕

8058 you mean?

Reacted to "I think epbs security >> blob optimizations right now" with 👍

Would also be nice to see what tooling breaks

Reacted to "Would also be nice t..." with 👍

Reacted to "Would also be nice to see what tooling breaks" with 👍

Reacted to "I think epbs securit..." with 👍

I’m sure Maria and jochem can come up with non crazy wrong values

Antwoord verzenden naar "I’m sure Maria an..." tx gas to 1? :D

Replying to "https://github.com/m..." @Barnabas the latest values are here. And it’s a 15line change PR.

Reacted to "tx gas to 1? :D" with 👀

Antwoord verzenden naar "I’m sure Maria an..." RE: preliminary values and tooling breaking, if the numbers are not final we cannot conclude if tooling breaks or not

Reacted to "I think epbs securit..." with 👍

Ok so conclusion: glam-Devnet-6: 8038 + 2780 + 8246 + 7997 + 8070 (as optional tip) ~~7610~~

Replying to "Ok so conclusion: g..." What about on the CL side? Are we wanting to include 7688 (stable containers)?

Replying to "I’m sure Maria and j..." https://github.com/CarlBeek/reth/pull/10 Gathering the data atm

Replying to "Ok so conclusion: g..." I think that’s a call to be made acdt or acdc

Reacted to "tx gas to 1? :D" with 👀

Data repricing EIPs: https://nerolation.github.io/hegota-eip-presentations/eip-8131_eip-8279.html

small nit: magic should be 0xef02 or something like that because 7702 using 0xef01

Heeft gereageerd op "small nit: magic s..." met ➕

questions I see around using an onchain contract for validation are on access logic of that contract (BAL, pricing, warming, etc)

PREACH BROTHER

Reacted to "PREACH BROTHER" with 👍

Reacted to "PREACH BROTHER" with 😂

Reacted to "PREACH BROTHER" with 😂

We (PS) will be helping Greg schedule a call

For the bot, Greg referencing: https://eips.ethereum.org/EIPS/eip-7979 https://eips.ethereum.org/EIPS/eip-8173

Antwoord verzenden naar "small nit: magic s..." could you post this on ethmag?

https://docs.google.com/presentation/d/1RwAwNkC21oGBYy_VHFahiHT4kvjxx67uOL2arWTwuiY/edit?usp=sharing

https://ethereum-magicians.org/t/eip-8222-lean-staking/28196

Isn’t this an ACDC topic instead of EL?

Why do we do this at the beacon contract level instead of just do it an any application level, make you money private to a new account and then deposit from that account

Why do we need to change the beacon deposit flow?

Reacted to "Why do we do this at..." with ➕

Reacted to "Why do we do this at the beacon contract level instead of just do it an any application level, make you money private to a new account and then deposit from that account" with ➕

I like the push for privacy, but this feels like an unecessary step towards full privacy on L1. Why would a validator not just use a privacy protocol (railway, tc, privacy pools etc) afterwards instead of the protcol doing the mixing? Also, it still feels early to enshrine zk proofs minting eth.

Replying to "Why do we do this at..." I guess the staking pool is so big now but reducing it might reduce power of privacy

Heeft gereageerd op "I like the push fo..." met ➕

Reacted to "I like the push for privacy, but this feels like an unecessary step towards full privacy on L1. Why would a validator not just use a privacy protocol (railway, tc, privacy pools etc) afterwards instead of the protcol doing the mixing? Also, it still feels early to enshrine zk proofs minting eth." with 💯

Heeft gereageerd op "Why do we do this ..." met ➕

Reacted to "I like the push for ..." with ➕

Replying to "Why do we do this at..." But any privacy pool solves this issue on the app layer

Replying to "Why do we do this at..." Don’t see the point of this EIP

Replying to "Why do we do this at..." I must be missing something

Replying to "Why do we do this at..." Yeah staking pool is built for staking not privacy

Replying to "Why do we do this at..." Can’t you use privacy pools to make deposits into staking pools?

Reacted to "I like the push fo..." with ➕

This eip makes zero sense to me

Reacted to "Isn’t this an ACDC t..." with 👍

Yeah I don’t get it at all

Reacted to "This eip makes zero ..." with ➕

Reacted to "This eip makes zero sense to me" with ➕

Process Q: are you PFI’ing 8222 in hegota or only seeking feedback at this phase?

Reacted to "Process Q: are you PFI’ing 8222 in hegota or only seeking feedback at this phase?" with ➕

Replying to "Process Q: are you..." seeking feedback I guess

I don’t understand the plausible deniability part, an authority will ask me to give proof what I have used the pool for. Are you saying that it would not be possible to provide this proof?

Reacted to This eip makes zero ... with "➕"

You can deposit just 1 ETH

exactly

Reacted to "You can deposit just..." with 👍

I think this is just trying to enshrine a privacy pool

If we were to enshrine a privacy pool, we should enshrine one that doesn’t require you to stake as part of it

Replying to "I think this is just..." But one that has “legitimate, non-mixing-goal” traffic

Replying to "I don’t understand t..." Pretty much yes, you can plausibly say that you are using it for staking

Replying to "I think this is just..." That is in my view the key part. You can’t just ban/mark address of this pool as you can with TC

Replying to "I don’t understand t..." But can I prove it? Because if I can then there is no plausible deniability

Replying to "If we were to enshri..." I read the proposal in a different way and it starts making some sense: 1) we enshrine 1 privacy pool that can be used for anything. 2) if you want to stake you MUST send to that privacy pool.

Reacted to "That is in my view t..." with 👍

Replying to "If we were to enshri..." This way your enshrined privacy pool is guaranteed to have a lot of liquidity

Replying to "If we were to enshri..." Mixing staking with the fund transfer/mixing is the sauce of this no?

Replying to "I don’t understand t..." Since an authority will treat no proof as me lying

Replying to "If we were to enshri..." At least it would make sense to me this way, but still is kinda crazy to push this to L1 right now

Replying to "I don’t understand t..." Tornado cash has no plausible deniability afaik

Reacted to "Tornado cash has no ..." with 👍

Replying to "I don’t understand t..." You can prove that you sent your TC money to a particular account, and that account deposited to the beacon contract

Replying to "I don’t understand t..." Yes, this is mixing funds seeking TC functionality with those seeking staking functionality

Replying to "If we were to enshri..." Is the timing the issue? Or is it the privacy pool enshrining?

Reacted to "Yes, this is mixing ..." with 👍

Thanks for clarifying, @mo (@mmjahanara) . So churn might be fine, I was wrong. I still think it's fine to just use privacy protocols and we focus on making it more simple/cheap/secure/trustless to use those, instead of making so big changes for a very small set of "users", which are validators.

Replying to "If we were to enshri..." I am fine with enshrining a privacy pool on L1 early, I think forcing validators to use it is crazy

I think we need to decide first if we want to enshrine a privacy pool in protocol or not. Once the answer is yes, we can then discuss the different mechanisms.

Thanks everyone for the comments/discussion

Reacted to "I think we need to decide first if we want to enshrine a privacy pool in protocol or not. Once the answer is yes, we can then discuss the different mechanisms. " with 👍

Reacted to "I think we need to decide first if we want to enshrine a privacy pool in protocol or not. Once the answer is yes, we can then discuss the different mechanisms. " with 👍

Reacted to "I think we need to d..." with 👍

Reacted to "I think we need to decide first if we want to enshrine a privacy pool in protocol or not. Once the answer is yes, we can then discuss the different mechanisms. " with 👍

yes, and the actual question is when. hegota feels early.

Replying to "I think we need to d..." I agree.

Reacted to "yes, and the actual ..." with 👍

Reacted to yes, and the actual ... with "🔥"

Reacted to "That is in my view t..." with 👍

Reacted to "But one that has “le..." with 👍

I do not want to move away from my EOA, I trust my key management more than contracts 🙂

Reacted to "Thanks everyone for ..." with 💙

Replying to "I do not want to m..." Then you are free to stay with the EOA !

Reacted to "Yes, this is mixing ..." with 👍

Reacted to Then you are free to... with "💯"

Reacted to "Then you are free to stay with the EOA !" with 💯

Reacted to "I do not want to mov..." with 😂

Reacted to "I read the proposal ..." with 👍

Reacted to "This way your enshri..." with 👍

Reacted to "Thanks everyone for ..." with 💙

Reacted to "I do not want to move away from my EOA, I trust my key management more than contracts 🙂" with 😂

Reacted to "I do not want to mov..." with 😂

Reacted to "I read the proposal ..." with 👍

Reacted to "Thanks everyone for ..." with 💙

Replying to "I do not want to m..." It's an opt-in flag. If you believe that it's fine with ECDSA you can sit on your EOA forever

Reacted to "Then you are free to..." with 💯

Replying to "I do not want to mov..." How, if you disable the legacy contract?

Lightclient referencing: https://eips.ethereum.org/EIPS/eip-7851 https://eips.ethereum.org/EIPS/eip-8151

Reacted to "Lightclient referenc..." with 🙏

Reacted to "Lightclient referenc..." with 🙏

SETCODEFROM would also allow for extremely-cheap deployments for duplicated code that already exists on chain

it feels like the permanent delegations will be abused to permanently take over wallets in phishing / blind signing attacks?

Reacted to "SETCODEFROM would also allow for extremely-cheap deployments for duplicated code that already exists on chain" with ❤️

Reacted to "SETCODEFROM would al..." with 👍

SETCODEFROM FTW!

Replying to "it feels like the ..." At this point the attacker is signing a crated transaction with your keys he swippes your account. On an EOA this means you are done for anyway

Replying to "it feels like the ..." Same attack surface as a 7702 delegation basically

Replying to "it feels like the pe..." Yea, if you loose your key you're lost anyway. But right now there are already phishing attempts on 7702 delegations. having a way to make those permanent afterwards increases the problem?

Reacted to "At this point the at..." with 👍

Replying to "it feels like the pe..." I recommend not losing your key

Reacted to "I recommend not lo..." with 👍

Reacted to "I recommend not losi..." with 👍

Heeft gereageerd op "SETCODEFROM FTW!" met 😍

Antwoord verzenden naar "SETCODEFROM FTW!" this would also make the deployment cheaper as code exists on chain (must require selfdestruct disable though). is there an EIP on this one?

Reacted to "I recommend not losing your key" with 👍

Reacted to "I recommend not lo..." with 👍

Replying to "it feels like the pe..." I'm thinking about users that blidly sign a untrusted delegation. That's not revertable anymore with the permanent delegation, so the phished wallet is permanently lost - even without loosing the key

Antwoord verzenden naar "SETCODEFROM FTW!" or do you mean the SETSELFDELEGATE_OPCODE

Replying to "it feels like the pe..." I also recommend not signing transactions blind

Reacted to I also recommend not... with "❤️"

Reacted to "I also recommend not..." with ❤️

Replying to "SETCODEFROM FTW!" I had 8058. But it was using ALs.

Replying to "it feels like the pe..." Yea, would recommend that too :D But that's what is unfortunately happening a lot :D

Replying to "SETCODEFROM FTW!" We can either refactor that one which targeted deployments only. Or just create a new one

Reacted to "I also recommend not signing transactions blind" with ❤️

Replying to "SETCODEFROM FTW!" I meant the new opcode mentioned by Ben basically

Antwoord verzenden naar "SETCODEFROM FTW!" new one seems the right way tbh, so we preserve the access list idea

Reacted to "new one seems the ri..." with 👍

Replying to "it feels like the ..." It's really the same attack model as we had before. Even before 7702 guys

Reacted to "It's really the same..." with 💯

Replying to "it feels like the pe..." Is it happening a lot?

8058

Replying to "it feels like the ..." Nope 7702 is not enabling much sweeping. Dead accounts are delegated to sweepers but no sweep is actually happening ...

Reacted to "Thanks for clarifyin..." with 👀

Replying to "8058" 8058 would be superseded by Ben’s proposal

I would introduce new EIP for this idea

Reacted to "I would introduce ne..." with 👍

Reacted to "I would introduce ne..." with 👍

It’s specially interesting because deployments will become super expensive. Yet clients do no extra work nor increase DB size for already existing code.

So would be nice UX

Antwoord verzenden naar "It’s specially in..." yes plus 8037

Heeft gereageerd op "So would be nice UX" met 👍

Love both EIPs :D

Start planning I star?

These two eips feel like the natural follow up in hegota for account abstraction.

Reacted to "Start planning I sta..." with 😅

Heeft gereageerd op "Start planning I s..." met 😍

Reacted to "Start planning I sta..." with 😅

Reacted to "Start planning I star?" with 😅

Reacted to "Love both EIPs :D" with ❤️

could you link the proposal?

Replying to "Start planning I sta..." quick schedule more features before the market tanks further i need job security

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

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

Reacted to quick schedule more ... with "😂"

I thought for a sec Barnabas was trying to use the opportunity to have Marius not on the call today to reverse the deicision :-)

Reacted to "I thought for a sec Barnabas was trying to use the opportunity to have Marius not on the call today to reverse the deicision :-)" with 😂

Heeft gereageerd op "I thought for a se..." met 😂

Or we set the deposit field to like uint max

Or whatever high number

Reacted to "I thought for a se..." with 😂

Reacted to "I thought for a sec ..." with 😂

Marius’s pr: https://github.com/ethereum/execution-apis/pull/793

Heeft gereageerd op "Marius’s pr: http..." met 👍

A few clients have demonstrated that they can handle lots of deposits (at least 8k per slot).

Reacted to "A few clients have d..." with 👀

not sure Cayman is here, but yes, that would be an alternative

see https://github.com/ethereum/EIPs/pull/11760 would be good if EL devs can take a look

You are assuming that eth doesn’t drop to $8, where the cost of attack is significantly less 🥦

Reacted to "A few clients have demonstrated that they can handle lots of deposits (at least 8k per slot)." with ❤️

loool

Reacted to "Start planning I sta..." with 😅

Reacted to "You are assuming tha..." with 😅

Reacted to "You are assuming that eth doesn’t drop to $8, where the cost of attack is significantly less 🥦" with 😂

Heeft gereageerd op "You are assuming t..." met 😆

Reacted to "You are assuming that eth doesn’t drop to $8, where the cost of attack is significantly less 🥦" with 😅

To get the sense of how many new validator deposits can be included in a single transaction, block and IL: https://hackmd.io/@jihoonsong/SJWAnFakMg

Reacted to "You are assuming t..." with 😅

Reacted to "You are assuming tha..." with 😭

Reacted to "You are assuming t..." with 😭

Reacted to "To get the sense of ..." with 🙏

Reacted to "You are assuming tha..." with 😅

Reacted to "You are assuming tha..." with 😂

Reacted to "You are assuming tha..." with 😆

Reacted to "You are assuming tha..." with 😭

Heeft gereageerd op "To get the sense o..." met 🙏

Heeft gereageerd op "To get the sense o..." met 😍

11:00 UTC

Reacted to "Screenshot2026_06_04_092747.jpg" with ❤️

Reacted to "You are assuming tha..." with 😅

Reacted to "Screenshot2026_06_04_092747.jpg" with 😄

Reacted to "Screenshot2026_06_04_092747.jpg" with 😄

Reacted to "Screenshot2026_06_04_092747.jpg" with 😄

North Americans computing the UTC to USA time

Reacted to Screenshot2026_06_04_092747.jpg with "😂"

Heeft gereageerd op "Screenshot2026_06_..." met ❤️

Reacted to "North Americans comp..." with 😅

nightmare for California

Reacted to "North Americans comp..." with 😂

Reacted to "nightmare for Califo..." with 👍

Reacted to "North Americans computing the UTC to USA time" with 😅