AllCoreDevs - Execution #233

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.

The suspense on 8141 is killing me

gm

gm

Reacted to "The suspense on 81..." with 😂

Gm

gm!!

gm gm

gm

gm

gm

Replying to "The suspense on 8141..." and we haven’t even started

Reacted to "The suspense on 8141..." with 😂

Reacted to "The suspense on 8141..." with 😂

gm yes

Reacted to "and we haven’t even started" with 😂

Replying to "The suspense on 8141..." Technically we started 3 calls ago ;)

Reacted to "The suspense on 8141..." with 😂

Reacted to "Technically we start..." with ❤️

agenda: https://github.com/ethereum/pm/issues/1970

Did anyone check if we have an overflow bug at ACD #256?

barnabas: post one of those flaming gifs

Reacted to "barnabas: post one of those flaming gifs" with 😂

Reacted to "barnabas: post one..." with 😂

Reacted to "Did anyone check if ..." with 😂

Reacted to "Did anyone check if ..." with 😂

Reacted to "Did anyone check i..." with 😂

Reacted to "Did anyone check if ..." with 😂

B invited Fireflies.ai here to record & take notes. By continuing, you agree to https://fireflies.ai/privacy. Type: '/ff pause' - pause recording '/ff leave' - to stop recording View Realtime notes here: https://app.fireflies.ai/live/01KMJCZMBSR7PK4RH227RYAKHK?ref=live_chat

Replying to "B invited Fireflie..." you would not believe your eyes

Reacted to "Did anyone check if ..." with 😂

@Barnabas Nethermind ePBS devnet changes: https://github.com/NethermindEth/nethermind/compare/epbs-devnet-0

Reacted to "@Barnabas Nethermind..." with 💦

Replying to "@Barnabas Nethermind..." Thank you

Reacted to "barnabas: post one o..." with 😂

Reacted to "Did anyone check if ..." with 😂

shoutout to rafael for such a nice tool 🔥

Reacted to "shoutout to rafael for such a nice tool 🔥" with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael..." with ❤️

Its gated access since we only have a few runners, they all need to be a specific type of machine

Reacted to "shoutout to rafael f..." with ❤️

https://benchmarkoor.core.ethpandaops.io/ Most EL core devs should be able to login via github auth.

Reacted to "shoutout to rafael f..." with 🔥

Reacted to "https://benchmarkoor..." with ➕

Reacted to "shoutout to rafael..." with ❤️

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "https://benchmarkoor..." with ➕

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with 🔥

“{"error":"user \"Giulio2002\" is not authorized: no matching role mapping found”}” :(

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with 🐐

Replying to "“{"error":"user \"Gi..." same

Reacted to "“{"error":"user \"Gi..." with 😔

Reacted to "“{"error":"user \"Giulio2002\" is not authorized: no matching role mapping found”}” :(" with 😔

Reacted to "“{"error":"user \..." with 😔

Reacted to "shoutout to rafael f..." with ❤️

Reacted to "shoutout to rafael f..." with 🔥

Replying to "“{"error":"user \..." please retry. Added you and marek

Reacted to "please retry. Added ..." with ❤️

Reacted to "please retry. Added ..." with ❤️

Reacted to "shoutout to rafael f..." with 🐐

Replying to "“{"error":"user \"Gi..." works, thank you!

Replying to "“{"error":"user \"Gi..." {"error":"user \"benaadams\" is not authorized: no matching role mapping found"}

Reacted to "works, thank you!" with ❤️

Replying to "“{"error":"user \"Gi..." Add “mpaulucci” too plz

Results for Besu look outdated for main given our recent runs on MOD related ones

Reacted to "shoutout to rafael..." with ❤️

Reacted to "shoutout to rafael..." with 🐐

Reacted to "shoutout to rafael..." with 🔥

Reacted to "shoutout to rafael..." with 💯

Replying to "“{"error":"user \..." added you both too 👍

https://x.com/EFprotocol/status/2031056150427242892?s=20 https://gasrepricing.com/

add ❤️

Reacted to "https://x.com/EFprot..." with 🔥

Reacted to "https://x.com/EFprot…" with 🔥

Reacted to "https://x.com/EFprot..." with 🔥

Reacted to "https://x.com/EFprotocol/status/2031056150427242892?s=20 https://gasrepricing.com/" with 🔥

Reacted to "https://x.com/EFprot..." with 🔥

Reacted to "https://x.com/EFpr..." with 🔥

Reacted to "https://x.com/EFprot..." with 🔥

Reacted to "added you both too �..." with ❤️

Reacted to "https://x.com/EFpr..." with 🔥

Reacted to "https://x.com/EFprot..." with 🔥

Reacted to https://x.com/EFprot... with "🔥"

Reacted to “{"error":"user \"Gi... with "😔"

Reacted to “{"error":"user \"Gi... with "😔"

Reacted to "https://x.com/EFprot..." with 🔥

I haven't tested this much in light mode btw :D I prefer dark mode xD

Reacted to "I haven't tested thi..." with 🔥

Reacted to "I haven't tested thi..." with 🔥

Reacted to "I haven't tested t..." with 🌚

This is amazing!

Reacted to "I haven't tested thi..." with 🌚

Reacted to "I haven't tested t..." with 🌚

Reacted to "I haven't tested thi..." with 🔥

Reacted to "This is amazing!" with 🎉

Reacted to "I haven't tested this much in light mode btw :D I prefer dark mode xD" with 🔥

Reacted to "This is amazing!" with 🎉

Reacted to "This is amazing!" with ❤️

Reacted to "This is amazing!" with 🎉

Reacted to "This is amazing!" with 💯

Very cool

Reacted to "This is amazing!" with 🎉

Reacted to "I haven't tested this much in light mode btw :D I prefer dark mode xD" with 🌚

Reacted to "This is amazing!" with 🎉

Reacted to "I haven't tested thi..." with 🌚

Reacted to "I haven't tested thi..." with 🌚

Replying to "Results for Besu l..." Yep sorry they might be old numbers

This one’s got Rafael’s handiwork all over 😄 I think rest of us just reviewed if anything <3

Reacted to "I haven't tested thi..." with 🌚

Reacted to "This one’s got Rafae..." with 🔥

Reacted to "I haven't tested t..." with 🌚

Reacted to "I haven't tested t..." with 🔥

amazing eips if you ask me 🤓

Reacted to "This one’s got Ra..." with 🔥

Reacted to "Yep sorry they might..." with 👍

Am I misunderstanding, but is the new per storage slot access cost of more than the cold access read cost itself? So using access lists is defacto dead.

Reacted to "This one’s got Rafae..." with 🔥

Reacted to "This is amazing!" with 💯

Reacted to "This one’s got Ra..." with 🔥

Reacted to "I haven't tested t..." with 🌚

Reacted to "This one’s got Rafae..." with 🔥

https://hackmd.io/@bosulmun/HyifHDRcZl

Reacted to "I haven't tested t..." with 🔥

Reacted to "I haven't tested t..." with ➕

Replying to "This one’s got Ra..." It got a lot of help from Nethermind too that pionereed the benchmarking efforts with their gas-benchmarks repo. Also shoutout to them. Specially Kamil, which whom I spent a lot of chats with to get benchmarkoor to this point 🙏

Reacted to "It got a lot of help from Nethermind too that pionereed the benchmarking efforts with their gas-benchmarks repo. Also shoutout to them. Specially Kamil, which whom I spent a lot of chats with to get benchmarkoor to this point 🙏" with ❤️

Replying to "This one’s got Rafae..." 100%, standing on the shoulder of giants 🙂

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

Reacted to "Did anyone check if ..." with 😂

Reacted to "The suspense on 8141..." with 😂

Reacted to "https://hackmd.io/@b..." with 👍

Reacted to "https://hackmd.io/@b..." with 👍

Reacted to "https://hackmd.io/@b..." with 👍

Reacted to "https://docs.google.com/presentation/d/1ui9lPlbyxVnA36vB0EGk577XZhTRgriMDeWO0DfiTdg/edit?usp=sharing" with 🙏

not from Besu

Reacted to "https://hackmd.io/@b..." with 👍

we will look at it

Reacted to "we will look at it" with ❤️

Nethermind will look into it also

Reacted to "Nethermind will look..." with 👍🏻

Reacted to "Nethermind will look..." with 👍🏻

https://hackmd.io/@matt/frame-mempool

ICYMI

Replying to "https://hackmd.io/@m..." Strategy 3 can leverage ePBS builders as paymasters.

Dont we have lodestars before schemed tx intro?

Sorry etherm-js

I can go first no issue, just out of order in the agenda

possibly sry didnt check order on agenda

Replying to "Dont we have lodesta..." yes, I’ll briefly ask for an ethereumjs update before handing to you if that’s okay

Replying to "Dont we have lodesta..." Ofc

Reacted to "Ofc" with 👍

Lfg @Derek Chiang

Reacted to "Lfg @Derek Chiang" with 🔥

Reacted to "Lfg @Derek Chiang" with 🔥

Reacted to "Lfg @Derek Chiang" with 🔥

Replying to "https://hackmd.io/@m..." Naive question, How is reputation managed for ePBS builders?

Reacted to "Lfg @Derek Chiang" with 🔥

Replying to "https://hackmd.io/@m..." Paymasters will require stake/reputation management to avoid them DOSing the mempool.

Replying to "https://hackmd.io/@m..." nothing specified yet

Reacted to "Lfg @Derek Chiang" with 🔥

Reacted to "nothing specified ye..." with 👍

@Chris - Base what alternative you plan on shipping?

Reacted to "@Chris - Base what a..." with ➕

Replying to "@Chris - Base what a..." https://eips.ethereum.org/EIPS/eip-8130

EthereumJS: https://github.com/ethereum/pm/issues/1970#issuecomment-4116337595

Reacted to "Lfg @Derek Chiang" with ❤️

Wasn’t post-quantum the reason we are even discussing frames? It’s the first line in the motivation section. We’ve discussed basically everything but post-quantum cryptography in the pros and cons.

I don’t really think you build VERIFY frames on top of schemed txs. VERIFY is the core of frame tx

Replying to "Wasn’t post-quant..." There is also native AA

Replying to "Wasn’t post-quantum ..." Native AA is needed irrespective of what PQ signature scheme is chosen for Ethereum EL clients.

Reacted to "Native AA is neede..." with 👍

Reacted to "Native AA is needed ..." with 👍

I think PQ support is the easiest part of a frame. Frames are essentially orthagonal to PQ.

Reacted to "Native AA is neede..." with 👍

Reacted to "I think PQ support..." with 👍

Replying to "Wasn’t post-quantum ..." Right, my argment being we should update the motivation and be hones about why we are doing it.

Reacted to "Native AA is needed ..." with 👍

Replying to "I don’t really think..." You can

Replying to "I don’t really think..." Just add a new scheme_type and add a verify extension

Replying to "I don’t really think..." but how do you have multiple verify frames for sender and payer?

Replying to "I don’t really think..." there are so many different ways to handle this that schemed tx is too rigid

Replying to "I don’t really think..." You still can

Reacted to "Native AA is needed ..." with 👍

Is every scheme implemented as a new precompile? That is almost the same complexity as a new transaction type, no?

Replying to "I don’t really think..." What can verify frames do that an extension cannot do

Replying to "Is every scheme impl..." You already do that in frames

Replying to "Is every scheme impl..." Like - this is not getting solved in frames either

Replying to "Is every scheme impl..." Not until you add support for PQ.

Replying to "Is every scheme impl..." Its the same

Replying to "Is every scheme impl..." Precompiles for PQ is needed regardless of the decision on Frames

Replying to "Is every scheme impl..." Yeah exactly, it is the same

Is the testing team fine with complications between FrameTransactions and Focil while delivering them in the same fork? Normally we avoided this kind of complexity creap in same fork.

Is any pq signature prod ready?

Reacted to "Yeah exactly, it is ..." with 🤔

Replying to "Is any pq signature ..." Dilithium or what I added into the EIP

Replying to "Is the testing team ..." @Mario Vega?

the sponsor address is currently written into the frame

All of these work in 8130 as well which is why we are pursuing it

Given the state of 8141 + our timelines

Replying to "I don’t really think..." looking at it again, i guess you can do verify frames as an extension

Replying to "Is any pq signature ..." Sphinx Dillithium and Falcon are all NIST approved and there’s a solidity coded by ZKNox. Antonio Sanso worked on it

Replying to "I don’t really think..." Yeah, just more targetted

Replying to "I don’t really think..." You don’t need to shove everything into a single proposal

Replying to "the sponsor address ..." To preserve privacy by removing the frame target we would need to do some signature changes to prevent signature substitution attacks. Dragan’s Composable Transaction (EIP-8175) has a very nice solution to this

Replying to "I don’t really think..." VERIFY is what we are aiming to deliver though. schemed tx doesnt provide anything over what we can do today

Replying to "the sponsor address ..." we have been discussing this a lot more and i think we are beginning to be open to moving signatures up to the root of the tx

Replying to "the sponsor address ..." we want aggregation to work both on protocol level signatures and in signatures used during evm execution

any contract that's managing funds / value can become a "paymaster" say you start with usdc and want to swap via uniswap, pool contract could become a paymaster where output amount can be used to cover for gas as well. Privacy pools is a cool use case, but in general any protocol could offer a gasless experience via verify/frame

Reacted to "any contract that's ..." with 👍

Reacted to "any contract that's ..." with 🔥

If each signature was given a unique hash (function of prior sigs or position for example) signautre substitution attacks are nerfed.

Reacted to "any contract that's ..." with 🔥

Reacted to "any contract that's ..." with 👍

What about transaction assertions? It’s an important security feature for many users and it seems to be possible to do this quite elegantly in Frame Transactions. Can SchemedTransactions do this without adding more complexity to the protocol?

Reacted to "What about transacti..." with 👍

Replying to "What about transacti..." i assume it can it needs yet another exetension

Reacted to "i assume it can it n..." with 🤔

Reacted to "Is the testing tea..." with 👍

https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8

Vitalik’s AA writeup: https://docs.fileverse.io/0xd961b83d3421bddec9d8966efabf13800617cfea/10#key=Z-XeQk6mE7uZX9Q2ZbqWkiniYi9IZ1oSbd_2vPFyt26S7Kf8gO_UHpLJ936--lp8

Reacted to "Vitalik’s AA writ..." with 👍

Reacted to "Vitalik’s AA writeup..." with 👍🏻

Replying to "Is the testing tea..." frame tx will be a lot of work for us (but doable), and focil is not that difficult IMO

Reacted to "frame tx will be a l…" with 👍

Replying to "Is the testing team ..." yeah but have you looked into their interaction?

Replying to "Is the testing team ..." https://ethereum-magicians.org/t/focil-native-account-abstraction/27999

Reacted to "https://ethereum-mag..." with 👍

Replying to "Is the testing team …" I am more than happy to help regarding the interaction. Please feel free to reach out, if needed!

Replying to "Is the testing team ..." I will bring it up at our meeting later today for discussion so that we can look over the particulars

Reacted to "I am more than happy..." with 🩵

Replying to "Is the testing team ..." The worst part of Frame vs. Schemed is mempool validation and statelessness interaction. ZKEVM stateless nodes will not be able to neither manage mempool nor help as includers in FOCIL.

Reacted to "I am more than hap..." with 💙

Replying to "Is the testing team ..." Arbitrary state validity rules are a mess for stateless clients. With 300GB state is fine. With 4TB we’ll see how many people holds state when they can not.

yes the point of the mempool strategy doc is to convey that the public mempool can be quite restrictive in the beginning if this is the sticking point for accepting

As someone who has worked on native AA all the way back in 2020: I think it’s obvious we need to do (something like) frame txs eventually. maybe it’s not urgent enough for H*, but it is the right principled approach

Reacted to "I am more than happy..." with ❤️

Reacted to "As someone who has worked on native AA all the way back in 2020: I think it’s obvious we need to do (something like) frame txs eventually. maybe it’s not urgent enough for H*, but it is the right principled approach" with 👍

can someone clarify the "native batching" point for erc20 approvals and frames, mentioned earlier?

Reacted to "As someone who has worked on native AA all the way back in 2020: I think it’s obvious we need to do (something like) frame txs eventually. maybe it’s not urgent enough for H*, but it is the right principled approach" with 👍

Replying to "As someone who has..." If Frame solves AA fully and finally and the opportunity window is there, why wouldn't we go forward with it now? What's to be gained by waiting?

Replying to "Is the testing team ..." There has been a number of "partial statelessness" proposals that seemed to mitigate the "4TB" issue, I believe.

Reacted to "As someone who has w..." with 👍

Replying to "As someone who has w..." imo there is no reason to wait and have no headliner.

Replying to "Is the testing team …" That's why FOCIL imposes further restrictions on Frame transactions to be included in ILs.

Reacted to "imo there is no reas..." with 👍

Replying to "Is the testing team ..." We’ll look at the interactions, we don’t have an answer at the moment, thanks for bringing this up

Reacted to "imo there is no re..." with 👍

Reacted to "We’ll look at the in…" with 👍

Reacted to "imo there is no reas..." with 👍

Reacted to "We’ll look at the in..." with 👍

Reacted to "imo there is no re..." with 👍

Reacted to "imo there is no reas..." with 👍

Replying to "As someone who has w..." I do think it's quite urgent to be able to audit verifiers and have execution governance DeFi DAOs able to move their contracts to PQ. They are the main target that you would attack. So Frame has many many reasons to get in. And one somewhat time constrained reason to get in now

Reacted to imo there is no reas... with "👍"

Reacted to "imo there is no reas..." with 👍

Reacted to "imo there is no reas..." with 👍

Reacted to "imo there is no re..." with 👍

Reacted to "imo there is no reason to wait and have no headliner." with 👍

Reacted to "We’ll look at the..." with 👍

Replying to "Is the testing team …" Frame transactions in ILs don't do arbitrary state validation; it will be a bit more restricted than the mempool rules for them.

Reacted to "imo there is no reas..." with 👍

Replying to "Is the testing team ..." The problem is that if you have arbitrary state dependent validity conditions for txs. Then is impossible to not need the full state in order to validate txs and therefore maintain mempool or be an includer

Reacted to "imo there is no reas..." with 👍

Reacted to "The problem is that ..." with 👍

Replying to "can someone clarif..." Since a frame transaction can include multiple actions / contract calls, you can have two calls inside one transaction: DIA, approve() to defi protocol defi protocol deposit()

Transaciton composability as seen in schemed transaction first appeard in Composable Transactions, EIP-8175

Replying to "Is the testing team ..." So FrameTransactions are not friendly to lightclients? You either have state or not able to verify transactions?

Replying to "Transaciton compos..." schmidhubered

Replying to "Is the testing team ..." Lightclients, stateless clients (ZKEVM), partial stateful clients, VOPS.. Anything that doesn’t have full state has severe issues.

Replying to "can someone clarif..." yeah but why do we even call that out? isnt that the default property of frame txs in general? I thought that's some special case / work done on erc20 approvals more tightly coupled with frame txs on a low level

Hard disagree here. Why isn’t it necessary now? Why frames is the best we have, why not ship it as a headliner.?

Replying to "Is the testing team …" It's not arbitrary state dependent validity conditions. See the runtime check in the article above.

i know there is time pressure to choose headliner, but we do have >12 months before hegota to get this finished

So no headliner just potentially delays it (but could still be included in h*) correct?

Reacted to "i know there is time..." with 👍

Replying to "Is the testing team ..." I don’t think we need to allow arbitrary combinations. It’s perfectly fine to say that if you want the IL mechanism to protect your transaction then you have to stay within limits on the verification.

Reacted to "i know there is time..." with 👍

Reacted to "i know there is time..." with 👆

Reacted to i know there is time... with "👍"

Reacted to "imo there is no reas..." with 👍

Hat auf "i know there is time..." mit 👍 reagiert

Reacted to "i know there is ti..." with 👍

Replying to "Is the testing team …" (FYI, I'm talking about those in ILs strictly.)

Reacted to "i know there is time..." with 👍

Replying to "Is the testing team ..." That applies only to the txs you shove into ILs right? Not to overall validity conditions. These are imposed by frame txs EIP. Not by focil

Reacted to "(FYI, I'm talking ab..." with 👍

Reacted to "That applies only to…" with 👍

Reacted to "i know there is time..." with 👆

if verification remains enshrined, we will never be able to natively support privacy pools

Reacted to "i know there is ti..." with 👍