EIP-2348: Validated EVM Contracts

Discussion topic for

A set of contract markers and validation rules relating to those markers is proposed. These
validation rules enable forwards compatible evolution of EVM contracts and provide some assurances
to Ethereum clients allowing them to disable some runtime verification steps by moving these
validations to the deployment phase.

What confuses me about this EIP is that you seem to suggest having the two versioning schemes, 1702 and 1707 used in tandem. Why are you doing this?
A simpler proposal would be to just say that this validation should apply to all accounts of (1702) version “1”, and not introduce any bytecode versioning header.

The reason is backwards compatibility. If we suddenly turn on 1702 and require all code to be validated suddenly contracts that could be submitted the block prior now fail to deploy. And such bad opcodes comes from widely used option in solidity (some of which may even be the default, I’d have to research that).

That’s bad UX, we need to provide some sort of a means for a contract deployer to “opt in,” and in time the tooling will default to opting in and provide options to opt out. We could just do the header (using 0xef as the version header) that required validation at deployment time. But the impression I got is that other core developers would want a flag to indicate that validation has been/could have been performed other than just the content of the contract.

So if we had to choose one it would be the 1707 variant. That preserves the ability of tooling to ease into the new requirements.

I see. Another alternative (which seems preferable to me) would be to rely upon https://specs.that.world/44-vertxn/ and use another field of the transaction data to specify that such contracts are to be created.

I don’t think that versioning information has a place in the bytecode. Some people use bytecode to store data, and could inadvertently deploy contracts which matches the versioning header. https://medium.com/coinmonks/on-efficient-ethereum-storage-c76869591add

Not that one necessarily want to support such crazy hacks, but it could indicate that putting the versioning header in the bytecode can have unintended consequences

Adding another data field in the transaction has a very high level of resistance to overcome, all of the client tooling would need to change to support it.

As for people using bytecode to store data, that is exactly the problem that this EIP is aiming to solve. Without clear deliniation about what is code and what is data we can’t make reasonable conclusions about the contract code. Just because some contracts started abusing the contract data should not preclude us from using the field as intended and to curb that abuse.

And I feel that the bytecode is a very good place for the versioning information. The JVM, CIL, WebAssembly, and LLVM bitcode all use items like magic numbers for headers, in stream metadata, and explicit versioning in their data files. This is in line with how modern VMs operate