EVM version is in the scope of metadata and so can be defined by a different standard.
If EVM versions were numbered or well-defined, perhaps they could be signaled via the salt. But I don’t think they are that important. It would make code harder to find and result in unnecessary duplication.
B) or to be ensured within the published Metadata file linked from CBOR.
Option (B) is likely preferred by explorers, given that Blockscout already reads the EVM version from compiler settings in the verified metadata.
In that case the part of the ERC part about metadata would be irrelevant as CALMs would have to have CBOR attached.
I am fine with that since I assume CALM optimisations will prefer to optimise for run time gas costs (while the deployment / replicate costs can be slightly higher due to CBOR attached).
Does anyone has an opposite view on this assumption? (in the case of replicable CALMs among chains)
Signaling / declaring the EVM compatibility version is key for multichain replications.
Imagine someone blindly replicates CALM contract with CLZ opcodes onto chains that do not have that assuming it will work there in the same way.
Wrt to signal via salt - interesting - there are not that many evm versions (assuming not to be thousands in the future either). Impact on the tooling would be to iterate over set of evm version constants in order to find the exact address, where CALM is deployed.
@vbaranov would that work for explorers? (note, CBOR metadata can still be there, the salt approach is to derive the EVM version directly from the chain runtime)
The negative impact is on the validity tooling like isCarved() check hashcarve/src/HashCarve.sol at 4fd5fe3e83d6f838775e40bb60c1c035f83848fe · radeksvarz/hashcarve · GitHub
Can you pls elaborate on 2) required tooling?
ad3) capability based declarations - I like it in general, however I am not sure it can be practically achieved - declaring PUSH0 requirement is easy, once we get into larger set of opcodes (like e.g. EOF related) - how could that be declared? I think we would end up with some sort of capability release naming anyway.
Just to give the idea about some supporting tooling - this is the replication CLI tool (WIP).
For the EVM version / capabilities - the tool can check the compatibility of the target version with declared ones before the replication occurs.
Another aspect to be considered into the standard besides EVM version:
Calls / Delegate Calls
Should the ERC limit CALMs not allowing to call another contracts?
Again for the sake of the EVM capabilities - let’s assume 1 CALM is compiled with paris target, but it calls another CALM that is of the very recent version having CLZ opcode. After the replication to the “paris capable” chain - some behaviour of CALM 1 with calls will be broken there.
I mean state in the EIP that tooling must independently verify opcode compatibility.
No; just warn about it in Security Considerations.
Strongly agree.
They could just as easily make this mistake with CBOR. The tooling has to be version-aware either way. There would be fewer problems if the tooling determined the EVM version itself rather than depending on signal.
There may be some limitations to compatibility detection. For example, if two different L2’s had utilized the same precompile address for different purposes, it might be hard to detect which one was intended. More generally, it won’t be possible for tooling to resolve every conceivable deviation. Nevertheless, I think it would be worse if tooling relied on self-identification and such self-identification was wrong.
I don’t think it is important for this ERC to solve evm versioning because the issue is broader than this standard. I recommend we just mention it in Security Considerations.
I strongly agree, and understand the principle, the question is - what is the suggested library for opcode compatibility checks? (if any)
I don’t think the EIP must specify this.
I am preparing related CALM toolings. We are aligning with Nick wrt diamonds tooling. So I would like to know about such a library.
