Ethereum Core Devs Meeting 136 Agenda

[timbeiko]

Meeting Info

• April 15, 2022, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/JXbOeiPN_uE
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

• Merge Updates
  • Shadow Fork Updates
  • lastestValidHash support
  • Testnet Plans
• Shanghai Planning #450
  • SELFDESTRUCT & EOF
  • Verkle Tries Code Chunking & EOF
  • Pause for new CFI EIPs
  • EIP-4396

[yperbasis]

On Shanghai planning. If we're not ready to commit to EIP-4758: Deactivate SELFDESTRUCT in Shanghai, should we at least prohibit SELFDESTRUCT in EOF code as part of EIP-3540 or EIP-3670? I think @axic suggested that some time ago.

[chfast]

On Shanghai planning. If we're not ready to commit to EIP-4758: Deactivate SELFDESTRUCT in Shanghai, should we at least prohibit SELFDESTRUCT in EOF code as part of EIP-3540 or EIP-3670? I think @axic suggested that some time ago.

This is in EIP-3670's Rationale section and it also includes CALLCODE instruction. https://eips.ethereum.org/EIPS/eip-3670#possibility-for-deprecation

[timbeiko]

Added to the agenda, @yperbasis @chfast

[yperbasis]

Also, time permitting, I'd like to discuss compatibility between EOF and code chunking for Verkle Trees.

[mkalinin]

I have updated latestValidHash analysis with my recent thoughts on a couple of attack vectors on nodes that doesn't support latestValidHash, https://hackmd.io/GDc0maGsQeKfP8o2C7L52w?view#Do-not-support-during-SYNCING

Based on the analysis, I think it's important to have this supported by all EL clients as it is currently stated in the spec.

[MarekM25]

In testnet plans we could discuss how we can mitigate a few risks. Of course, the main risk is bugs, and I believe that the sooner we start forking public testnets longer the time we should observe it. Two additional points:

1. All our devnets/shadowforks are controlled by one man-our wizard - @parithosh. Is it worth starting devnet with something closer to public tesnet in terms of validators control? Or should we try it on a real testnet like Sepolia?
2. Misconfiguration. In every hardfork, we've observed some amounts of nodes that were forgotten to upgrade (let's say X). All previous hardforks were significantly less demanding for node operators. Now node operator needs to do a few things:
   a) Upgrade EL
   b) Upgrade CL
   c) Configure JWT Secret between clients
   d) Make sure that there is a connection between clients.
   In theory, people can train it on Kiln, and we can mitigate it with correct announcements and documentation. However, in practice, I believe that longer public testnets will reduce the number X for the next testnet and later for the mainnet. People need to get used to running Ethereum nodes with two apps. From my observation, the configuration was a bit confusing even for devs and technical people (especially JWT/ports in the beginning).

[axic]

Also, time permitting, I'd like to discuss compatibility between EOF and code chunking for Verkle Trees.

@yperbasis the ideal solution would be to have two "account types", for legacy accounts the code chunking needs to work as described, and for the "EOF accounts" it wouldn't need to have the FIO field, saving 1 byte per chunk.

This could be easily accomplished by having two different values in the VERSION_LEAF_KEY.

That being said, the current verkle chunking spec is compatible with EOF, just not as optimal as it could be.

[axic]

On Shanghai planning. If we're not ready to commit to EIP-4758: Deactivate SELFDESTRUCT in Shanghai, should we at least prohibit SELFDESTRUCT in EOF code as part of EIP-3540 or EIP-3670? I think @axic suggested that some time ago.

This is in EIP-3670's Rationale section and it also includes CALLCODE instruction. https://eips.ethereum.org/EIPS/eip-3670#possibility-for-deprecation

It would be nice to disable "undesirable* opcodes, however it will not solve the question of those existing in legacy code. If SELFDESTRUCT is transformed into a different useful feature, then disabling it also makes no sense.

[adietrichs]

If there is time today, I would like to briefly get some feedback on how important a security fix people think EIP-4396 would be. Being mindful of the desire to pause CFIs for Shanghai, and given that the EIP still requires significant work in comparing its different variants & picking the optimal one, it would be helpful to get a feeling for whether this should realistically target Shanghai.

[timbeiko]

Closed in favor of #514