Repository navigation
Ethereum Core Devs Meeting 136 Agenda #508
Description
Activity
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
CALLCODEinstruction. https://eips.ethereum.org/EIPS/eip-3670#possibility-for-deprecationAdded to the agenda, @yperbasis @chfast
Also, time permitting, I'd like to discuss compatibility between EOF and code chunking for Verkle Trees.
Reacted by Tim BeikoI have updated
latestValidHashanalysis with my recent thoughts on a couple of attack vectors on nodes that doesn't supportlatestValidHash, https://hackmd.io/GDc0maGsQeKfP8o2C7L52w?view#Do-not-support-during-SYNCINGBased on the analysis, I think it's important to have this supported by all EL clients as it is currently stated in the spec.
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:
- 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?
- 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).
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
FIOfield, 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.
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
CALLCODEinstruction. https://eips.ethereum.org/EIPS/eip-3670#possibility-for-deprecationIt would be nice to disable "undesirable* opcodes, however it will not solve the question of those existing in legacy code. If
SELFDESTRUCTis transformed into a different useful feature, then disabling it also makes no sense.Reacted by Jamie Lokier and Andrew AshikhminIf 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.
Meeting Info
Agenda
lastestValidHashsupport