AllCoreDevs — Execution #237

gm

gm

gm

g(lasterda)m

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

sound check?

gm

gm

Replying to "sound check?" Passed, thanks!

Replying to "sound check?" 👍

gm

Reacted to 👍 with "🙏"

hi all.

Hello!

ACDT has more turnout!

Reacted to "ACDT has more turnou..." with 😂

Reacted to "ACDT has more turn..." with 😂

Reacted to "ACDT has more turnou..." with 😂

is anyone speaking?

Reacted to "ACDT has more turnou..." with 😂

Reacted to "ACDT has more turnout!" with 😂

Reacted to "ACDT has more turn..." with 😂

Reacted to "ACDT has more turnou..." with 😂

Can't talk without the AI listening :O

Reacted to "Can't talk without the AI listening :O" with 🤖

Reacted to "Can't talk without t..." with 🤖

Reacted to "ACDT has more turnout!" with 😂

Reacted to "Can't talk without t..." with 🤖

Reacted to "Can't talk without t..." with 🤖

Is the call being recorded?

Replying to "ACDT has more turnou..." Closer to fork.

yes

Replying to "Is the call being re..." yep

Reacted to "yep" with 🙏

Reacted to "yes" with 🙏

The el spec is devnet 3 right?

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

Replying to "The el spec is devne..." for what

Replying to "The el spec is devne..." no, its bal-devnet-7 + https://github.com/ethereum/execution-apis/pull/796

Replying to "The el spec is dev..." for glamsterdam-devnet-4

Replying to "The el spec is devne..." https://notes.ethereum.org/@ethpandaops/glamsterdam-devnet-4

Replying to "The el spec is devne..." pls check spec sheet if uncertain

Replying to "The el spec is dev..." Wait but then you have geth as well, no

Is it already in a test ?

Replying to "The el spec is devne..." you added 796 in glamsterdam-devnet-4 branch?

Reacted to "ACDT has more turnou..." with 😂

Replying to "The el spec is dev..." Nope it was reorged out again :(

test_bal_call_revert_insufficient_funds

Reacted to "test_bal_call_revert..." with 👍

Reacted to "Nope it was reorged out again :(" with 🥲

@Toni Wahrstätter, yep, this was found by a zkevm execution witness test being run in Nimbus catching this BAL situation.

Reacted to @Toni Wahrstätter, y... with "👍"

Reacted to "@Toni Wahrstätter, y..." with 👍

Reacted to "@Toni Wahrstätter, y..." with 😎

Reacted to @Toni Wahrstätter, y... with "👍"

Reacted to "@Toni Wahrstätter..." with 👍

Replying to "@Toni Wahrstätter, y..." Ah great, yeah I vaguely remembered you caught something there but wasn't sure it was this one! Thanks a lot for the heads up!

Reacted to "@Toni Wahrstätter, y..." with 😮

Reacted to "@Toni Wahrstätter, y..." with 👍

I think it is better yes

Reacted to "Ah great, yeah I vag..." with 🫡

Do you have a writeup of it?

Reacted to "@Toni Wahrstätter, yep, this was found by a zkevm execution witness test being run in Nimbus catching this BAL situation." with 😎

Reacted to "@Toni Wahrstätter, yep, this was found by a zkevm execution witness test being run in Nimbus catching this BAL situation." with 👍

Replying to "Do you have a writeu..." https://github.com/ethereum/EIPs/pull/11699

Reacted to "Can't talk without t..." with 🤖

Replying to "Do you have a writeu..." That's all we have on this for now

Replying to "Do you have a writeu..." With specs + tests attached

I would like for other clients to take a look how it is implemented for them and give their opinion after that

Reacted to "I would like for o..." with ➕

Heeft gereageerd op "I would like for o..." met ➕

Lol I just implemented that

Replying to "Do you have a writeu..." Background: https://discord.com/channels/595666850260713488/1364000387195076608/1506952443681050715

Replying to "The el spec is devne..." let me know when you pass all tests and i'll deposit for geth in devnet-7 :)

We will take a look (besu)

We load the code before the value transfer now

Reacted to "We will take a loo..." with 👍

Replying to "Do you have a writeu..." Nimbus wanted to go this way as well I think https://github.com/ethereum/execution-specs/pull/2473#issuecomment-4484429185

Replying to "We load the code b..." which puts the account in the BAL

Removal of EIP because its not needed as the all the ELs are too fast 🙂

Reacted to "Removal of EIP becau..." with 🔥

Reacted to "Removal of EIP becau..." with 🔥

Reacted to "Removal of EIP becau..." with 🔥

Replying to "Removal of EIP becau..." Let’s go!

Reacted to "Removal of EIP becau..." with 🔥

Replying to "Removal of EIP becau..." All green on Benchmarkoor

Reacted to "Removal of EIP bec..." with 🔥

Reacted to "Removal of EIP becau..." with 🔥

Reacted to "Removal of EIP becau..." with 🔥

Reacted to "Removal of EIP because the all the ELs are too fast 🙂" with 🔥

I opened the thread re the 7702 delegation + BAL in the discord. Please, EL clients, chime in!

Reacted to Removal of EIP becau... with "🔥"

Reacted to "Removal of EIP becau..." with 🔥

qq, now that we have slotNum accessible from the EL, why not use that instead of EL block? EL block could have a variable period length.

Reacted to "qq, now that we have..." with 🔥

Reacted to "qq, now that we have..." with 😅

Replying to "qq, now that we have..." because block numbers are continuous, whereas slot numbers are not, so it is an imperfect "clock"

Replying to "qq, now that we have..." blockNum are sequential data changes, slotNums can have gaps where no data changes?

We already have this, blocks/tx/receipts are in flat files, while state that need random access/writes are in mdbx

Replying to "qq, now that we have..." each slot has deterministic time tho.

Replying to "qq, now that we have..." so is the block number as far as we are concerned

Replying to "qq, now that we have..." time isn't important 🙂 blockTime >= slotTime gap in blocks from slots missed would suggest the data was inactive when was just no blocks

With tis one we will not have the last recent read. So we will add only the recent write in mdbx with this EIP for example

Replying to "qq, now that we have..." i.e. consensus issue shouldn't cause the data to seem more idle

The difference in pricing is more a "recency discount", and we could just set that discount to 0 for now. And then once we have benchmarks on client optimizations we can have pricing diverge.

Would reading price change?

Maybe price change but don’t update metadata?

Could you share slides afterwards

Replying to "Maybe price change b..." that's the other way around: we want to inform clients that some data is cold and can be removed from the db

Reacted to "Could you share slid..." with 👍

Replying to "Maybe price change b..." Yes, I don’t see how we could price without the metadata

Replying to "Maybe price change b..." I mean for read, old one cost more but we don’t update the metadata.

Replying to "Could you share slid..." Interested in the slides as well.

yeah but turning each read into a write might backfire

+1 to Peter’s comment, should not underestimate the severity of a tree change, but maybe this would be an opportunity to get comfortable with it

State tiering makes sense to me, but I find leaving reads out of this tiering mechanism a bit of a weird asymmetry.

Reacted to "+1 to Peter’s commen..." with ➕

Replying to "yeah but turning eac..." it's only on the first touch of an epoch

Tree change is very heavy. I think Han have a graph somewhere that show there are around 30% read that has no write.

Replying to "Could you share slid..." i'll be sure to add them to the github issue agenda once we have the link

Reacted to "i'll be sure to add ..." with 🙏

maybe if we make it every X epochs then might make sense?

Reacted to "i'll be sure to add ..." with 🙏

Replying to "yeah but turning eac..." where X is 100, 1000, 10k?

Reacted to "State tiering makes ..." with ➕

Replying to "yeah but turning eac..." so epoch % X

Replying to "+1 to Peter’s commen..." this is not a tree change, just adding a field

Replying to "The el spec is dev..." I pass all tests...

Replying to "The el spec is dev..." I already passed them yesterday

Replying to "yeah but turning eac..." probably better go with power of 2 though

Replying to "+1 to Peter’s com..." It's probably fine, I just wanted to flag it as a potential pain point

Replying to "Tree change is very ..." not changing the tree though

Reacted to "Screenshot2026_05_21_163508.jpg" with 😅

Replying to "Tree change is very ..." functionally, there is no tree change: just an extra field in the rlp which is optional - so it's the exact same interface and it's backwards-compatible

Replying to "Screenshot2026_05_21_163508.jpg" Shrae 😄

Reacted to "It's probably fine, ..." with 👍

Reacted to "Screenshot2026_05_21_163508.jpg" with 😅

Replying to "yeah but turning eac..." that would make write amplification minimal?

Reacted to "Shrae 😄" with ➕

Reacted to "Screenshot2026_05_21_163508.jpg" with 😅

Replying to "The el spec is devne..." whats wrong here then? https://hive.ethpandaops.io/#/group/bal-quick

Reacted to "Screenshot2026_05_21_163508.jpg" with 😅

It's happened with railgun

Replying to "+1 to Peter’s comment, should not underestimate the severity of a tree change, but maybe this would be an opportunity to get comfortable with it" It’s not a transition, but it does change the tree structure, no? But yes important clarification, no transition necessary

Reacted to "Screenshot2026_05_..." with 😅

Replying to "The el spec is devne..." how can I fix it

Reacted to "We already have this..." with 👍

Replying to "+1 to Peter’s commen..." it adds an extra field in the hashing, but for accocunts it's the same interface - you just add an optional field to the account object. For the slots, it's a two field change to the interface, but come on, it's just about writing an rlp payload in the tree, we have been doing this for over 10 years it's safe

Replying to "Tree change is very ..." I mean write to update metadata will cause patricia tree rebuild/update, hence change the tree. Read does not change the tree.

Replying to "yeah but turning eac..." @Guillaume WDYT?

Replying to "yeah but turning e..." We should investigate the "track most recent read" approach before doing EIP-8188

Let's ship this, we can even use a special-type state for this

Saying competition is bad and monopoly should be imposed it's a very.... Overly creative? contra-economic and anti-darwinian argument

Replying to "yeah but turning eac..." WDYM track most recent read approach?

Reacted to "ACDT has more turn..." with 🧪

really like the intent of this EIP, but imo it enshrines too much too soon I’d rather get there with minimal EIPs on top of 8141 (e.g., keyed nonces, will present it soon) first to unlock native/trustless private txns without having to enshrine a single pool now with opinionated cryptography, etc… and then have to upgrade it via ACD governance

Replying to "The el spec is dev..." The format from eels doesn't work with geth yet. The tests pass in a different format

Replying to "+1 to Peter’s comment, should not underestimate the severity of a tree change, but maybe this would be an opportunity to get comfortable with it" Yes I am definitely not opposed, as I was saying, we should start getting more comfortable with state changes anyway, and this is a nice candidate to "ease" into it

Replying to "really like the inte..." we can just enshrine the nullifiers can't we?

Replying to "Let's ship this, we ..." This looks like headliner type of EIP. New state type for utxo is interesting to drive gas price down.

Replying to "really like the inte..." I guess 2D nonces and Frame txs do this already

Replying to "really like the inte..." yes that’s basically what keyed nonces is doing

Replying to "yeah but turning eac..." @Łukasz Rozmej I meant it's only done once per epoch. We want to make epochs ~ 1M blocks so doing it the first time an epoch is accessed makes sense - it just sucks to be the first person to read a location.

Replying to "really like the inte..." yeah that's good enough

Replying to "really like the inte..." https://eips.ethereum.org/EIPS/eip-8250

just putting this here for the AI summary to cheat off of. the 3 EIPs being proposed for Hegota today: EIP-8188: State Tiering by Write Age EIP-8182: Private ETH and ERC-20 Transfers EIP-4758: Deactivate SELFDESTRUCT

Reacted to "yeah that's good eno..." with 👍

Replying to "+1 to Peter’s commen..." I couldn't agree more

Replying to "+1 to Peter’s commen..." It is necessary imo, probably every clients will have its own gotchas 😄

Replying to "The el spec is dev..." I just rebased it so it might work now

We had similar barrier with gas changing.

claude -p "what is the likelihood that private txns will lead to crackdown on eth and eventual price crash"

Replying to "Let's ship this, we ..." I think some of Vitalik's alternative state sections are nobrainers to be added, UTXO is one of them, vector commitments/ring buffers is another. Some of these should be implemented as PoC in some clients, although it seems like a lot of work perhaps

Reacted to This looks like head... with "👍"

Replying to "really like the inte..." I agree. There are unknown unknowns. Feels like there are many moving parts that could evolve over the next few months

Reacted to "really like the intent of this EIP, but imo it enshrines too much too soon I’d rather get there with minimal EIPs on top of 8141 (e.g., keyed nonces, will present it soon) first to unlock native/trustless private txns without having to enshrine a single pool now with opinionated cryptography, etc… and then have to upgrade it via ACD governance basically I think the direction is good but the EIP is doing too much too soon" with ➕

We can already use railgun and it works great

Good proposal if rg didn't exist

Replying to "claude -p "what is t..." A crackdown sounds bullish to me

So basically the proposal aims to increase anonimity set by splitting it with a railgun euivalent. (insert meme with unifying standards here); Main problem to solve for adoption is regulation and compliance.

This is a poor frame

Reacted to "So basically the p..." with 👍

Reacted to I guess 2D nonces an... with "👍"

Replying to "Good proposal if rg ..." Railgun is upgradable

Replying to "So basically the p..." 927

I agree that it would only make sense if we added a builtin "nullifier" storage segment

Reacted to "+1 to Peter’s comment, should not underestimate the severity of a tree change, but maybe this would be an opportunity to get comfortable with it" with ➕

Reacted to "just putting this he..." with ❤️

Upgrade to a PQ contract later would be an issue for regular deployed? Would need a governacne over pool and it to be a proxy

Ethereum is upgradeable, it's the reason we are here:-) money is a social construct and as the world and users needs change, adaptation is important, so far every though Tornado is much bigger... Today people still don't use Tornado as much as railgun. The difference is the private proofs of innocence system which is basically only useful if updated live 24/7

Reacted to "Ethereum is upgradeable, it's the reason we are here:-) money is a social construct and as the world and users needs change, adaptation is important, so far every though Tornado is much bigger... Today people still don't use Tornado as much as railgun. The difference is the private proofs of innocence system which is basically only useful if updated live 24/7" with 🔥

Reacted to "This is a poor fra..." with 👍

Replying to "Ethereum is upgradea..." Tornado has more than double the volume of railgun

real reason people don’t use tornado is because they could get on the ofac list if they did. Would probably happen to all those that interact wtih this address too tbh.

I remember we had some ideas regarding crypto to add "basic opcodes" to EVM which would be building blocks to port an existing crypto algo to EVM, instead of enshrining a specific cryptography method. Not sure how feasible this is because this assumes most/all crypto uses a small set of basic building blocks to function. But nevertheless something to re-explore, such that anyone can create a library contract implementing a specific cryptography method, instead of protocol deploying it as precompile

"credible neutrality"

Replying to "Ethereum is upgrad..." (usage by frequency of use and number of unique addresses, not ETH number)

(In terms of such warnings)

Replying to "I remember we had so..." This would help 🙂 https://ethresear.ch/t/native-proof-verification/24798

Replying to "I remember we had so..." You get automatic post-quantum-like upgrades of the verification stack for all applications without enshrining any application

Antwoord verzenden naar "I remember we had ..." Great, thanks for the ref!! 😁👍

Reacted to "Great, thanks for th..." with ❤️

kinda funny that the only way to build unstoppable apps on Ethereum is through enshrining your app into the protocol

so it has to go through eth governance if you wanted to upgrade your contract

https://eips.ethereum.org/EIPS/eip-6049 Deprecate SELFDESTRUCT EIP 😁

Tornado cash has more than 5x the number of deposits of railgun

Replying to "so it has to go thro..." Stamp of approval has its weight

Replying to "really like the inte..." 8182 solves the “what is the canonical anonymity set and how is it governed” question which 2D nonces / frame txs doesn’t address (though they are also good!)

Ship it! CFI for Hegota please 😬

Reacted to "Ship it! CFI for Heg..." with ➕

Reacted to "Ship it! CFI for H..." with ➕

Replying to "So basically the pro..." Its goal is to create a single canonical anonymity set, which is the optimal outcome.

Builders/searchers used it for "metamorphic contracts" in the past. Not sure this is still a thing.

I remember the project right now has low TVL, not sure if they are still in operation

Replying to "Builders/searchers u..." I think few ppl use metamorphic contract now 🤔 But I need to check some analysis and data

Replying to "kinda funny that the..." If you need the app to evolve over time and don’t want additional trust assumptions (tokens, multisigs) then you need enshrinement! Doesn’t mean every app that fits that profile should be enshrined, but private transfers are, IMO, a foundational requirement.

ideally none :D

people are still using it because contracts are immutable ...

Turn selfdestruct off, see what happens (wait 2 years), see if selfdestruct needs to be reenabled 😄

Replying to "I remember the proje..." cc @spencre

Reacted to "Turn selfdestruct of..." with 😂

create a new contract without selfdestruct?

Reacted to "Turn selfdestruct ..." with 😅

does removing current SD enables anything?

Reacted to "does removing curr..." with 👍

Reacted to "people are still usi..." with 😆

Reacted to "does removing current SD enables anything?" with ➕

Replying to "does removing curr..." Much less edge cases in the evm

Reacted to "Much less edge cases..." with ☝️

Reacted to "Much less edge cases..." with 👍

Replying to "create a new contrac..." they can't upgrade their contract

Replying to "does removing curr..." optimizes for development time :)

Reacted to "Much less edge cas..." with ☝️

Reacted to "Much less edge cas..." with ☝️

Reacted to "optimizes for deve..." with ☝️

Replying to "does removing curren..." it will delay verkle :D

Reacted to "optimizes for develo..." with ☝️

Reacted to "Much less edge cases..." with ☝️

Reacted to "Much less edge cases..." with ☝️

Reacted to "it will delay verk..." with 😆

Heeft gereageerd op "Much less edge cas..." met ☝️

Reacted to "it will delay verkle..." with 😆

Reacted to "it will delay verk..." with 😆

Se ha reaccionado a "Much less edge cas..." con ☝️

Replying to "does removing curren..." disables bugs in other eip specs :P

Reacted to "disables bugs in o..." with ☝️

Replying to "create a new contrac..." make a new one from scratch, recrete all the nft stuff on that, and burn the old contract

Se ha reaccionado a "disables bugs in o..." con ☝️

Reacted to "Much less edge cases..." with ☝️

Reacted to "optimizes for develo..." with ☝️

Replying to "does removing curren..." BTW it’s a part of the EOF proposal. Not sure if it doesn’t mean that it has to be rejected.

Se ha reaccionado a "it will delay verk..." con 😆

PFI it, I think the reason you mentioned (complain) is exactly the reason why we would want to PFI those early. Also signals we are serious about destroying (lol) SD

this discussions reminds me of the lost coins debate on btc

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

Reacted to "PFI it, I think the ..." with 👍🏼

Reacted to "PFI it, I think th..." with 👍🏼

https://hackmd.io/@bomanaps/rJXLPhYRWl

Reacted to "it will delay verkle..." with 😆

Replying to "PFI it, I think the ..." CFI it even: stronger signal, stronger complains, but we’ll get the voices we want so we can discuss properly

Reacted to "CFI it even: stronge..." with 🔥

Reacted to "CFI it even: stron..." with ➕

Reacted to "CFI it even: stron..." with 🔥

Reacted to "CFI it even: stron..." with ➕

Reacted to "PFI it, I think the ..." with 👍🏼

Reacted to "BTW it’s a part of the EOF proposal. Not sure if it doesn’t mean that it has to be rejected." with 🤣

Reacted to "CFI it even: stronge..." with 🔥

Reacted to "CFI it even: stron..." with 🔥

ACDT keep 👍 cancel 👎

Se ha reaccionado a "CFI it even: stron..." con 🔥