AllCoreDevs - Execution #230

gm

gm

Leeeeeeeeroooooooooy

Reacted to "Leeeeeeeeroooooooooy" with 😂

if we keep putting memeable forknames, yes

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

https://dora.bal-devnet-2.ethpandaops.io/

Reacted to "Leeeeeeeeroooooooo..." with 😂

https://github.com/ethpandaops/bal-devnets/pull/29 examples for the flags besu and geth have

the two EIP-8024 changes discussed: https://github.com/ethereum/EIPs/pull/11094#issuecomment-3769076517 https://github.com/ethereum/EIPs/pull/11306

https://hive.ethpandaops.io/#/group/generic?suites=rpc-compat e.g eth_simulateV1 fail example: https://hive.ethpandaops.io/#/test/generic/1768973576-78237392b0c263f38d2ab3465fd9ac5c?testnumber=133

——— devnet-3 BAL OPTIMIZATIONS (parallel exec, parallel state loading, parallel state root calc) 8037 State Creation Gas Cost Increase 7954 Increase Maximum Contract Size

Replying to "——— devnet-3 BAL OP..." What about eth/70? We wanted to increase the higher gas limit and without the data repricing we may run into limits.

Reacted to "What about eth/70? W..." with 👍

- non EIP priorities - BAL optimizations - parallel execution - parallel state root calculation - batched state reads - `eth_simulateV1` RPC support - EIP priorities - devnet-3 - EIP-8037: State Creation Gas Cost Increase - EIP-7954: Increase Maximum Contract Size - devnet-4+ - data repricings - EIP-7976: Increase Calldata Floor Cost - EIP-7981: Increase Access List Cost - other repricings - EIP-2780: Reduce intrinsic transaction gas - EIP-7904: General Repricing - EIP-8038: State-access gas cost increase - EIP-7975: eth/70 - partial block receipt lists - EIP-8070: Sparse Blobpool - EIP-7997: Deterministic Factory Predeploy

Replying to "——— devnet-3 BAL OP..." Thats on a separate devnet, right?

Replying to "——— devnet-3 BAL OP..." So eth/70, 7976 and 7981

Eth/71 for devnet 3 ? https://github.com/ethereum/EIPs/pull/11307

Replying to "- non EIP priorities..." non EIP priorities: BAL optimizations - parallel exec - parallel state root calculation - batched state reads EIP priorities devnet-3 - 8037 State Creation Gas Cost Increase - 7954 Increase Maximum Contract Size ——— devnet-4 & beyond data repricings - 7976 Increase Calldata Floor Cost - 7981 Increase Access List Cost - 2780 Reduce intrinsic transaction gas - 7904 General Repricing - 8038 State-access gas cost increase - 7975: eth/70 - partial block receipt lists - 8070 Sparse Blobpool - 7997 Deterministic Factory Predeploy

Replying to "Eth/71 for devnet 3 ..." Thats a good point, I think it would be great if we can include this

Replying to "- non EIP priorities..." 7778 missing

Reacted to "Eth/71 for devnet 3 ..." with 👍

Reacted to "Eth/71 for devnet 3 ..." with 👍

Average receipts rlp is like 200KB on mainnet

Replying to "Average receipts rlp..." do you have examples of worst cases or 95/99 percentiles?

Replying to "Eth/71 for devnet 3 ..." BAL item cap https://github.com/ethereum/EIPs/pull/11234 not sure when we want to have it as it will depend if we want to add read into BAL @Toni Wahrstätter

Replying to "Eth/71 for devnet 3 ..." Are clients expected to store the access list to serve it? Unless you're an archive node, you will not be able to serve this for historical blocks

agree with @Felix (Geth)

let me collect, will post later in el networking

Reacted to "let me collect" with 🙏

Reacted to Eth/71 for devnet 3 ... with "👍"

Replying to "Eth/71 for devnet 3 ..." I wouldnt include BAL in p2p tbh. By default clients will not be able to serve it

Reacted to "let me collect, will..." with 🙏

Replying to "Eth/71 for devnet 3 ..." We should keep them during a Weak Subjectivity Period

And after we can prune them, so clients will be able to serve recent BALs

Replying to "Eth/71 for devnet 3 ..." But thats a short time, syncing clients will not really need them to catch up to the tip

Make sense to add eth/70 to Glamsterdam

Reacted to "Make sense to add ..." with 👍

Reacted to "Make sense to add et..." with 👍

Replying to "Eth/71 for devnet 3 ..." 113056 it is enough for healing optimization during snap sync, or enabled // during backward sync if you node turned off during some days

What’s the eth/71 EIP?

we are overloading the term “protocol” here :-)

Replying to "What’s the eth/71 EI..." https://github.com/ethereum/EIPs/pull/11307

Reacted to "https://github.com/e..." with 👍

perfect

every blockchain needs a deadline guy

Barnabus "deadline" Busa

Reacted to "every blockchain n..." with 😂

Reacted to "every blockchain nee..." with 😂

Reacted to "Barnabus "deadline..." with 😂

We have an eth/70 devnet: https://dora.nft-devnet-10.ethpandaops.io/ which can be used for testing

Reacted to "Barnabus "deadline" ..." with 😂

Reacted to "Barnabus "deadline..." with 😂

Reacted to "every blockchain n..." with 💯

Replying to "We have an eth/70 ..." Geth and Nethermind are working

Replying to "We have an eth/70 de..." Works in nethermind, we are adding more tests and constraints

what about besu? eth/70

Replying to "what about besu? eth..." implemented, and testing right now

makes sense

Reacted to "implemented, and tes..." with 👍

Replying to "We have an eth/70 de..." Reth branch matt/make-eth70-default and image should be at ghcr.io/paradigmxyz/reth:8399bafdbe36d9660a1752800534cf8a7cb4e6c6

I was curious whether Justin would remain video on during Anders’ presentation :-)

is there anything to prevent key providers withholding keys?

much like FOCIL

Replying to "much like FOCIL" FOCIL is a lot more on CL (but yes also cross layer)

Reacted to "FOCIL is a lot more ..." with ➕

yes, if you withold your key you still pay full gas, and your transaction is skipped

https://ethresear.ch/t/lucid-encrypted-mempool-with-distributed-payload-propagation/24042

what encryption scheme?

Who are the decrypters? What are their incentives? Is there any in-protocol mechanism to prevent them from decrypting the transactions earlier for the builders?

Reacted to "Who are the decrypte..." with ➕

we don’t have any efficient PQ encryption schemes in the protocol though

Replying to "we don’t have any ef..." Note that the in-protocol part here is just using the released decryption key, which is a symmetric key, so PQ is not a big issue here.

Replying to "we don’t have any ef..." AES? That’s quantum-safe

Reacted to "AES? That’s quantum-..." with 💯

so we’d need AES precompile essentially?

Isn’t the decryption offchain?

but the code to decrypt is on chain?

Replying to "Isn’t the decryption..." This uses a KEM - DEM framework, so the envelope includes an (pk encrypted) symmetric key. The decryption of that is off-chain. Using the then-revealed symmetric key is onchain, IIUC.

have encrypted mempools like this been deployed successfully out of protocol?

Replying to "but the code to decr..." No, decryption is Offchain, you need to just check that the commitment from the open plaintext agrees to with the committed ticket.

Replying to "have encrypted mempo..." does Shutter network count?

Replying to "Isn’t the decryption..." Keep Kems offchain, they generally are as impacted as assymetric algos (EC, RSA) and have the same key size / sig size issues when going to PQ for KEM. so off-chain KEM is best.

Replying to "have encrypted mempo..." otherwise, "like this" i would say is no, because lucid depends on focil/ePBS

Replying to "Isn’t the decryption..." Benedikt Wagner has outlined one specification for this off-chain part included in Appendix C: https://ethresear.ch/t/lucid-encrypted-mempool-with-distributed-payload-propagation/24042#p-58297-appendix-c-kemdem-hybrid-encryption-51

https://github.com/lightclient/execution-specs/pull/1

Reacted to "https://github.com/l..." with 🔥

would you use immediates for TXPARAM or is stack ok?

Reacted to "https://github.com/l..." with 🔥

feedback for whoever is coordinating the YouTube stream for the call, the steam makes it only look like there’s 9 people on the call , not sure what changed but it’s like a zoomed in view.