Execution Layer Meeting 167

[timbeiko]

Meeting Info

• August 3rd, 2023, 14:00-15:30 UTC
• Youtube Stream: https://youtube.com/live/X46mbG8N5XM
• Zoom: shared on #allcoredevs Discord channel shortly before the call
• Ethereum Protocol Calls Calendar subscription

Agenda

• Dencun Updates
  • Update EIP-4788: set nonce of beacon root history address to nonzero EIPs#7431
  • @holiman EthMag 4788 comment
  • Update EIP-4788: Mention genesis block with no existing beacon block root case EIPs#7445
  • Update EIP-6780: Add clarifications to EIP-6780 EIPs#7308
• Devnet 8 spec
  • Un-merged Engine API PRs:
    • Add EIP-4844 transaction and receipt execution-apis#398
    • Clarify Cancun payloads handling by earlier APIs; reorder checks execution-apis#426
    • Rename "data gas" to "blob gas" execution-apis#451
• Large Validator Testnet Results
• EIP Discussion
  • EIP-5806
  • EIP-7377
• Verkle Trie update

[Amxx]

Would it be possible to present / discuss EIP-5806 ?

[lightclient]

I would like to discuss EIP-7377.

[yperbasis]

Let's clarify whether the EIP-4788 storage should be deleted or not at the end of the block in case the balance of address 0xb is 0. There was a discussion on Discord about it. Currently the EIP-161 empty rule (Eq 14 in the Yellow Paper) doesn't require the storage to be empty, implying that deleting the precompile storage is correct, but to my mind that's contrary to the intent of EIP-4788.

[holiman]

implying that deleting the precompile storage is correct, but to my mind that's contrary to the intent of EIP-4788.

Yes, wiping the storage at the end of each block is contrary to the intent :)

I concur that it needs to be fixed. My suggestion is to set the nonce to 1, if it is zero every time we do the other 4788-related state modifications.

And with more words: ethereum/EIPs#7431

[timbeiko]

Added it all, @Amxx @lightclient @yperbasis @holiman 👍

[yperbasis]

I suggest to omit EIP-6780 from devnet 8. There're a few reasons:

1. devnet 8 introduces quite a few changes already on top of devnet 7 (EIP-1153, 4788, 5656);
2. We (erigon) and perhaps geth haven't implemented it yet; and
3. There're no ethereum/tests for it yet.

[holiman]

Geth merged support for 6780 two weeks ago: ethereum/go-ethereum#27189

[yperbasis]

Geth merged support for 6780 two weeks ago: ethereum/go-ethereum#27189

OK, maybe we (erigon) can piggyback on that :)

[shemnon]

Execution-spec-tests has tests for EIP-5656 and EIP-6780 - https://github.com/ethereum/execution-spec-tests/tree/main/tests/cancun

[holiman]

@shemnon are those available in statetest-format anywhere? Or not until next release?

[ralexstokes]

we should call this out along w/ the other 4788 updates

ethereum/EIPs#7445

[jrudolf]

@gballet and myself would like to present/discuss Verkle (EIP-6800)
See also https://verkle.info

[shemnon]

@holiman I'm not sure what the execution spec tests team is planning. Here's the output from a current snapshot - https://gist.github.com/shemnon/83773562a7e728d07bbacf04e3c54682

I checked the master branch of geth along with Besu at one point with their filler and it passed all the tests. I think nothing has changed in the interim.

[yperbasis]

There are some Engine API PRs that are targeted for devnet-8 but not merged yet: ethereum/execution-apis#398, ethereum/execution-apis#426, ethereum/execution-apis#451. Let's either merge them or exclude from devnet-8.

[timbeiko]

Added @yperbasis 👍

[shemnon]

Do we need a final call for EIP-6780 clarifications?

• OP stack depends on the burn feature
• Arbitrum doesn't depend on the burn
• zksync doesnt' support selfdestruct (they link at the solidity level)
• starkware reverts on selfdestruct
• Polygon zkEVM already went to SENDALL and don't burn.
• zkScroll has it marked as "INVALID" at the moment and expressly said they will follow mainnet's lead
• Linea - question in process but as the arithmetize Besu's trie logs I don't anticipate problems

For maximum compatibility it looks like the clarification as written is the way to go. Polygon's zkSync will be an outlier but it appears they do not depend on that for correct functioning, which OP stack does depend on the self-burn.

[timbeiko]

@shemnon yes, we can cover it.

Also, re: "OP stack depends on the burn feature", they are fine with 6780 as-is given their use case creates + SELFDESTRUCTS a contract in the same transaction.

[parithosh]

We'd like to bring up the >2M validator state test results that we performed over the week

[timbeiko]

Added @parithosh !

[jrudolf]

Slides for the Verkle presentation

[smartprogrammer93]

@jrudolf slides added here:
https://github.com/tvanepps/EthereumDiscordGuidebook

[timbeiko]

Closed in favor of #845