AllCoreDevs - Execution #242

hello

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

We are actively looking at those bids issues

also worth looking into second round of spamming report https://panda-uploads-production.devops-539.workers.dev/panda/uploads/c761e4/glamsterdam-devnet-7-self-built-blocks-round-2.html

All besu regressions are fixed on glam devnet 7

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

I need to double check but we should have all optimizations ported to glam-7 EDIT: We do 🙂

Benchmarkoor run: https://benchmarkoor.core.ethpandaops.io/suites/3f6a0898955dff4f

Yes, this is a problem for the tooling side, sorry about that for lagging so long behind the spec

The key thing to check is this one: https://misilva73.github.io/eip-2780-repricing/index.html

Reacted to "The key thing to c..." with 👍

已使用👍回应"The key thing to c..."

Reacted to "The key thing to check is this one: https://misilva73.github.io/eip-2780-repricing/index.html" with 👍

for the next named testnet we can start using trunk branches

Now that we migrating everything over from discv4 to 5, it would be great if admin_nodeInfo rpc endpoint would return enr fields instead of enode fields.

Reacted to "Now that we migrating everything over from discv4 to 5, it would be great if admin_nodeInfo rpc endpoint would return enr fields instead of enode fields." with 👍

Name hard to pronounce on purpose <3

Reacted to "Name hard to pronounce on purpose <3" with 💙

Reacted to "Name hard to pronounce on purpose <3" with 💙

Reacted to "Name hard to pronounce on purpose <3" with 💙

do we know how much community testing there was on devnet-7?

Replying to "do we know how much ..." Very little, the faucet was broken and no one raised a flag :/

do we keep another more internal devnet around that we try to break?

Reacted to "Very little, the faucet was broken and no one raised a flag :/" with 👍

Replying to "do we keep another m..." yes

Replying to "do we keep another m..." Yes we’ll have a NFT devnet

Replying to "do we keep another m..." nft devnets

Replying to "do we know how muc..." Heh, its a good test if someone public tests it :P

Replying to "do we know how much ..." okay, good - so not much expectation of keeping it running

Reacted to "Yes we’ll have a NFT..." with 👍

Replying to "do we know how much ..." Tbh we were going to wait for something that would be closer to mainnet spec (devnet-8 or a testnet)

Reacted to "Yes we’ll have a ..." with 👍

Reacted to "Name hard to prono..." with 💙

Reacted to "Tbh we were going to wait for something that would be closer to mainnet spec (devnet-8 or a testnet)" with 👍

Reacted to "Tbh we were going to wait for something that would be closer to mainnet spec (devnet-8 or a testnet)" with 👍

Can someone write down this testnet name here? For ref

plataberget

Reacted to " plataberget " with 👍

But devnet-8 will also work for the insiders 😛

plataberget is just a CNAME

Replying to "plataberget" ty, otherwise we get differently spelled testnet names and we dont want that

Reacted to " plataberget " with 🐻‍❄️

Reacted to "plataberget is just a CNAME" with 😂

Have mainnet mev relays been contacted for the testnet - it would be good to get actual relays running in there for integrated tests

Reacted to "plataberget is just a CNAME" with 😂

Reacted to "plataberget is jus..." with 😂

Reacted to "plataberget" with 👍

Hivechain PR is here: https://github.com/ethereum/hive/pull/1589 But it's blocked by this section: Known blocker: clients disagree on EIP-7928 BAL contents at block 57 I think its time to bring hivechain up to speed with glamsterdam

Replying to "Have mainnet mev rel..." right now 😄

Reacted to " plataberget " with 🐻‍❄️

Replying to "Have mainnet mev rel..." Will be more builders for gloas

Replying to "Have mainnet mev rel..." Would be good to get a mix of both builders and mev relays.

Reacted to "for devnet-8 rpc-c..." with 💯

Reacted to "for devnet-8 rpc-com..." with 💯

Reacted to "Would be good to get a mix of both builders and mev relays." with ➕

Hivechain PR is here: https://github.com/ethereum/hive/pull/1589 But it's blocked by this section: Known blocker: clients disagree on EIP-7928 BAL contents at block 57 I think its time to bring hivechain up to speed with glamsterdam" with 💯

Reacted to "Would be good to get a mix of both builders and mev relays." with ➕

Replying to "for devnet-8 rpc-com..." This disagreement looks concerning

Replying to "Have mainnet mev rel..." yup we are intending to make a blog post with this announcement

Reacted to "yup we are intending to make a blog post with this announcement" with 🙏

Reacted to "yup we are intending..." with 🙏

Etan first EIP: https://eips.ethereum.org/EIPS/eip-8115

Etan second EIP: https://eips.ethereum.org/EIPS/eip-8116

Hivechain PR is here: https://github.com/ethereum/hive/pull/1589 But it's blocked by this section: Known blocker: clients disagree on EIP-7928 BAL contents at block 57 I think its time to bring hivechain up to speed with glamsterdam" with 💯

Etan third EIP: https://eips.ethereum.org/EIPS/eip-7807

Replying to "Etan first EIP: http..." There is some similar EIP, problem is if you want to use priority fee to send it somewhere else. Alternative is to set priority fee before last tx, so last tx can send it somewhere else.

This should take into account we now have state gas and execution gas (EIP-8037) re: changing cumulative gas in EIP-8116

Replying to "This should take i..." (in receipts)

Individual tx gasUsed already in the api spec so this is already handled by the ethereum clients? It is in besu at least https://github.com/ethereum/execution-apis/blob/e5d1bb60e6c064e4b15080da07b4370d0baadf92/src/schemas/receipt.yaml#L86-L89

Reacted to "Etan third EIP: https://eips.ethereum.org/EIPS/eip-7807" with 🔥

Would you also put other fields like the state gas refund in the receipt?

it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 😂

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with ⛱️

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 😂

Reacted to "it’s great, Etan is ..." with ⛱️

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 😂

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with ⛱️

Reacted to "it’s great, Etan ..." with 💙

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 🍿

Replying to "it’s great, Etan is ..." haha

Reacted to "it’s great, Etan is ..." with 🍿

Se ha reaccionado a "it’s great, Etan ..." con ⛱️

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 🍿

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 😂

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 🍿

Derek / Hadrien EIP: https://eips.ethereum.org/EIPS/eip-7819

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 😂

Reacted to "it’s great, Etan is reading out the question and answering them - I can just sit back and enjoy :-)" with 🍿

Replying to "Etan first EIP: http..." not sure if it's necessary. with ePBS the builder already has to have enough balance in advance on the beacon chain to pay the proposer

Reacted to "Tbh we were going to wait for something that would be closer to mainnet spec (devnet-8 or a testnet)" with 👍

Replying to "Etan first EIP: http..." The thing is builder <> proposer may still prefer trusted bid. That’s still supported in epbs. I’m not sure if this is a blocker though

What’s the difference between this and DELEGATECALL?

Reacted to "Would you also put..." with 👍

love this EIP

Replying to "Derek / Hadrien EIP:..." does 7819 makes sense if we do frames?

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

Replying to "love this EIP" (EIP-7819)

Reacted to "https://eips.ether..." with 💙

Replying to "Derek / Hadrien EIP:..." For sure, frames don’t say anything about how the account implements the proxy logic. 7819 just makes it really cheap for accounts to proxy

Reacted to "does 7819 makes sense if we do frames?" with ➕

Replying to "Etan third EIP: https://eips.ethereum.org/EIPS/eip-7807" @Etan (Nimbus) is it preferred to have it along with ssz txs/receipts?

Replying to "Derek / Hadrien EIP:..." So it’s purely orthogonal to frames

Replying to "Etan third EIP: http..." back when it was proposed to do txs/receipt in the same it was deemed as too big (headliner scope), so now we just do the block hash first, and then can do tx/receipt a fork later

Alex’ EIP: https://eips.ethereum.org/EIPS/eip-7906

Replying to "https://eips.ether..." Great EIP, these current way of deploying delegate proxies will be more expensive (in terms of gas units) in Glamsterdam and this solves this problem elegantly, thanks a lot!

Replying to "Etan third EIP: http..." so yes, would be preferred, but it's okay to do block hash first 🙂

Reacted to "so yes, would be preferred, but it's okay to do block hash first 🙂" with 👍

正在回复 "https://eips.ether..." My main concern is how to validate the pending txs in the mempool. With 7702, we have an explicit list of auths and we can make apply some restrictions in the mempool so that one tx will not invalidate all the pending txs of certain account

正在回复 "https://eips.ether..." With contract-style auth, it's harder to figure out the auths and easier to mess up the mempool

hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum

Replying to "What’s the differenc..." Ok argument that it’s cheaper may be valid, but can’t understand that you don’t have to create the code with SETDELEGATE. I guess the code needs to exist on chain first (deployed somehow) before you can do SETDELEGATE.

Reacted to "hard to underscore h..." with ❤️

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with 👍

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with ❤️

Se ha reaccionado a "hard to underscore..." con ❤️

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with ❤️

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with 👍

Reacted to "hard to underscore..." with 👍

Reacted to "hard to underscore..." with ❤️

Se ha reaccionado a "hard to underscore..." con 👍

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with ❤️

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with ❤️

Replying to "What’s the difference between this and DELEGATECALL?" The implementation code has to exist. That is the code that proxy delegate call to, or that 7702 accounts point to. No difference.

Replying to "https://eips.ether..." This is a good point, but the EIP-7702 note that clients should only allow one EIP-7702 tx in mempool wouldnt this directly mitigate this problem? As EIP-7702 can mass-invalidate txs in mempool

Replying to "What’s the difference between this and DELEGATECALL?" The difference is that currently the delegate call is done by a clone / proxy. That is a piece of code that represent the instance (it holds the storage). It usually a few hundreds of bytes long.

Reacted to "hard to underscore h..." with 👍

I don't like 7906, I prefer the idea of exposing access to the journal

正在回复 "https://eips.ether..." It's exactly my point. With opcode, it's easier to set auths with a small contract and how can you know if it's an authorization tx without executing it?

Replying to "What’s the difference between this and DELEGATECALL?" (And that is the piece of code that, if you want proxy upgradeability, needs to do an SLOAD)

Reacted to "hard to underscore how valuable 7906 assertions are for the community. we have talked to tons of users since earlier last year from small users to large enterprise and being able to assert what is happening in the tx at end was overwelming answer when asked what would make them feel safer transacting on ethereum" with ❤️

Reacted to hard to underscore h... with "❤️"

Replying to "https://eips.ether..." Yes good point, I should first read this EIP more carefully before engaging here 😄👍

Replying to "What’s the difference between this and DELEGATECALL?" This is the piece of code we don’t want to deploy anymore. We want to have a factory use SETDELEGATE to create « eip-7702-like » delegations (instead of using create or create2)

Replying to "I don't like 7906,..." Is there a (draft) EIP somewhere regarding direct journal access?

Replying to "https://eips.ethereu..." i think the designator should be changed slightly so that you can differentiate 7702 accounts vs contracts?

Reacted to "Is there a (draft) EIP somewhere regarding direct journal access?" with 👀

Replying to "What’s the difference between this and DELEGATECALL?" Basically: setdelegate sets a 23 bytes code instead of using create(2) to deploy significantly larger code. And you get upgradeability for free (if the factory decides to support it) without having to pay an sload every time

Replying to "I don't like 7906, I..." There was a draft iirc. Tyler from the security team wrote it up

Replying to "I don't like 7906,..." If we dont have it we should draft it and "propose it for PFI" (lol) before next week ACDC

Replying to "I don't like 7906, I..." how would that be different from 7906?

Replying to "I don't like 7906,..." Idk, Marius says he does not like EIP-7906, which seems to imply EIP-7906 does not have the journal access

Replying to "I don't like 7906, I..." Not a frame and different api

Replying to "Etan third EIP: https://eips.ethereum.org/EIPS/eip-7807" if block is handleable, at least receipts seem to be too

Reacted to "hard to underscore h..." with ❤️

Replying to "I don't like 7906, I..." you want the frame, or similar controlled env, so that people don’t raw dog get internal state of contracts instead of using public abi

Replying to "Etan third EIP: http..." receipts are kinda tied to transactions, both follow this "typed envelope" format

Replying to "I don't like 7906, I..." Also 7906 seems to have changed quite significantly from when we last discussed it in BA

Replying to "I don't like 7906, I..." Its just very convoluted and creates a headache for benchmarking imo

Replying to "I don't like 7906, I..." Its very much against the idea of making the evm simple and easy to reason about

Replying to "I don't like 7906, I..." we’re pretty far past that 😅

已使用👍回应"Its very much agai..."

Replying to "I don't like 7906, I..." i’m not sure what other info you would want from something like this though? TXDIFF is basically the journal right?

Replying to "I don't like 7906, I..." What was idea to expose journals? Sounds invasive

Replying to "Etan third EIP: https://eips.ethereum.org/EIPS/eip-7807" but they are still simpler as we don't need to sign it and manage in tx pool. Not like I'm pushing a lot for that but might be cool to do. Receipts will require ssz-way hashing support on EL side as an additional difficulty

Replying to "I don't like 7906, I..." Isn't 7906 exactly exposing the journal via solidity/evm api?

Replying to "I don't like 7906, I..." Yes, txdiff is basically what I proposed in BA

Replying to "I don't like 7906, I..." It just does much more than that

Replying to "I don't like 7906, I..." yeah i’m not sure we need the TXTRACE suite

Implemented in Ethrex today: https://github.com/lambdaclass/ethrex/pull/6891 Public devnet info: https://github.com/lambdaclass/ethrex/blob/hegota-devnet/scripts/hegota-devnet/USER-GUIDE.md Playground demo (WIP): https://eip7906.forshtat.com/ Architecture overview: https://x.com/forshtat/status/2082434836589948942 https://forshtat.com/posts/trustless-clear-signing-architecture/ (mirror)

Reacted to yeah i’m not sure we... with "👍"

Reacted to "Implemented in Ethre..." with 🔥

Reacted to "Implemented in Ethrex today: https://github.com/lambdaclass/ethrex/pull/6891 Public devnet info: https://github.com/lambdaclass/ethrex/blob/hegota-devnet/scripts/hegota-devnet/USER-GUIDE.md Playground demo (WIP): https://eip7906.forshtat.com/ Architecture overview: https://x.com/forshtat/status/2082434836589948942 https://forshtat.com/posts/trustless-clear-signing-architecture/ (mirror)" with 🔥

Thanks for the presentation, actually quite nice!

Replying to "I don't like 7906, I..." IMO just TXDIFF is fairly straight forward

Reacted to "Thanks for the prese..." with ☝️

Reacted to Implemented in Ethre... with "🔥"

Replying to "I don't like 7906, I..." I think we can do txdiff with a better interface (that was my proposal back then)

Looking forward to declarative requirements so users can express their wishes in a declarative, simple way :)

Replying to "I don't like 7906, I..." +1 on TXDIFF, handling atomic what’s atomic

Replying to "What’s the difference between this and DELEGATECALL?" A thing to understand is that SETDELEGATE is a « factory opcode » (like create and create2)

https://eips.ethereum.org/EIPS/eip-7668 (remove bloom filters)

Replying to "https://eips.ethereu..." had it typed out already, 1s frontrun

Would this eip be consumed by etan's header change?

Se ha reaccionado a "Implemented in Eth..." con 🔥

Replying to "Would this eip be co..." not 100%, there's another bloom filter in the receipt

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

Replying to "Would this eip be co..." mine only removes the one from the block header (and replaces JSON-RPC with 1111111..1)

Reacted to Implemented in Ethre... with "🔥"

Replying to "Would this eip be co..." I see! Makes sense

Thanks

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

Reacted to "https://eips.ethereu..." with 🔥

Reacted to "had it typed out a..." with 💙

https://eth-act.github.io/evmification-data/index.html

Reacted to "https://eips.ethereum.org/EIPS/eip-8200" with 🔥

Replying to "Would this eip be co..." One thing to clarify is the 7778 interaction with the gas_used in receipt. Should be fine but should clarify that the gas used is the user-facing one, after refunds. @Etan (Nimbus)

Replying to "https://eips.ether..." it would be funny me claiming the frontrun, and you being first, then you frontran the frontrun 😍

Reacted to "https://eips.ether..." with 🔥

What is the difference to just repricing the precompilies when we roll out zkevms?

Se ha reaccionado a "https://eips.ether..." con 🔥

Based on evm code

We should also PFI https://eips.ethereum.org/EIPS/eip-7666 (EVMIfy IDENTITY precompile) for Hegota, which is not PFId

Replying to "We should also PFI..." (together with EIP-8200)

正在回复 "https://eips.ether..." What I meant is: for 7702, it's very easy to detect the authorizations and then do some validations in the mempool; with this EIP, all the contracts can do the auths with the opcode, it's very hard to detect these operations without the execution, making the mempool validation even harder

Reacted to "We should also PFI h..." with ➕

Replying to "I don't like 7906, I..." In defense of the TXTRACE, despite its obvious issues, it is what allows the open-ended "negative constraint" (`nothing except A, B, and C changed in this transaction`). WIth TXDIFF the wallet needs to know where to look one way or another. I've heard some positive feedback about being able to express "negative constraints" when talking about EIP-7906 in the past.

Replying to "I don't like 7906, I..." You can do that with txdiff? E.g. there should not be any touched storage slots besides the ones we want touched and they should have the following values/live in the following ranges

Lol who would've thought that the 19 bls precompiles aren't really used 😂

Reacted to "Lol who would've t..." with 😅

Reacted to "Lol who would've thought that the 19 bls precompiles aren't really used 😂 " with 😅

If we intent to remove BLS precompiles then should we make them more expensive in Hegota? Or explicitly signal we deprecate them?

Replying to "If we intent to remo..." why can’t we just remove them?

Reacted to "Lol who would've thought that the 19 bls precompiles aren't really used 😂 " with 😅

Reacted to "We should also PFI..." with ➕

Its a bit like being able to remove dedicated libraries for precompiles

lol, there were some scary bugs too for bls

Yup, its a new EIP, we can discuss it regarding that EIP and PFI it now and DFI it later

Replying to "Yup, its a new EIP..." (this proposed BLS reprice)

Replying to "Yup, its a new EIP..." And yes I also know this is contentious as we just added BLS

Replying to "Yup, its a new EIP..." So such EIP being "frowned upon" would be an understatement 😂

Reacted to "Lol who would've tho..." with 😅

Reacted to "So such EIP being "frowned upon" would be an understatement 😂" with 😁

also go and vote 🐻‍❄️ https://ethereum-magicians.org/t/mascot-needed-for-glamsterdam-upgrade/26008

only 1 more day left from the end of the poll

Reacted to "also go and vote 🐻‍..." with 🐻‍❄️

Reacted to "also go and vote 🐻‍..." with 🐻‍❄️

Check out Pooja's comment on ACD so we can move these EIPs forward: https://github.com/ethereum/pm/issues/2166#issuecomment-5108689733

Replying to "also go and vote �..." a polar bear is an artic panda right?

Reacted to "Check out Pooja's ..." with 🔥

Repricings eips were updated here: https://github.com/ethereum/EIPs/pull/12038 The individual PRs had issues that I fixed here

Replying to "I don't like 7906, I..." Basically yes, it will need to adopt some fields from TXTRACE but it is possible to have a single opcode to return a list of "touched storage slots" and the changes.

Inspiring call

Reacted to "Inspiring call" with ❤️

Reacted to "Inspiring call" with ❤️

Ansgar sing please

Reacted to "Inspiring call" with ❤️

happy birthday song?

Reacted to "happy birthday song?" with ❤️

Reacted to "happy birthday song?" with 😂