Versioning in contracts

[axic]

As we are making changes to the API it would make sense thinking about how to version imports in contracts.

Immediately an option comes to mind where either the namespace or the function name is version, for example following GCC's <symbol>@<version> scheme.

If we version functions does it mean that multiple versions of the functions are accepted in a contract? I would say that is a bad idea.

If we version the namespace does it mean that multiple versions of the namespaces are accepted in a contract? Again, I think we shouldn't do that.

I would propose one of the following two options:

1. Version the namespace (as ethereum@3 - the current revision), but disallow multiple versions.
2. Have a custom section with the version in it.

Option 2) means that the Sentinel contract would need to verify the contract based on the value in the custom section.

[jakelang]

I think that simply versioning the "ethereum" import interface would make the best sense.
Furthermore, a contract should only be able to use one version of the interface.

If we have a custom section indicating the version, then Sentinel must still validate that the imports are correct (as has been mentioned already). A contract can specify an erroneous version number in the custom section and import from a different version. If Sentinel correctly catches this, it should either reject contract deployment or amend the version number (assuming all the imports are from one version). However, this is unnecessarily complicated.

It would make much more sense for Sentinel to just verify that all contract imports are from one version, implicitly assigning a contract its version number by that of the interface it imports.
In Hera, we can then simply support multiple versions of the interface by using multiple namespaces (naming scheme TBD), and throw an exception if a certain version is unsupported.
We can also choose to either rely on Sentinel catching multi-version imports at deployment time, or additionally detect this and throw an exception at runtime.

[jakelang]

@axic we need another decisions call or something, otherwise these things will stay on the back burner forever.

[lrettig]

What happens if a contract that implements e.g. v4 calls into one implementing e.g. v3? This should be fine, right? I do think there's a more interesting question here for package managers--what happens if you try to import a contract that implements an earlier version?

[jakelang]

@lrettig good question.
I think it would make sense to just prohibit this altogether (checked at runtime) because allowing cross-revision calls means that the VM has to implement each revision of the EEI, and also opens up crazy vulnerability surface if we eventually have contracts that can access deprecated or unsafe host functions by calling a contract on an older revision.
We could also go more draconian and just automatically fail all calls to contracts with an older revision tag than the latest, making them effectively "dead" contracts.
Note that this solution is messy as hell and only belongs on the testnet.

[lrettig]

Like you said, we need another decision call to discuss this stuff :)

[axic]

I think for now we should just go for: have a version number in the namespace. A contract can import a single version of the namespace, i.e. all imports must share the same version number.

Reasoning: a custom section would make this unnecessarily complicated and we're trying to use custom sections for other purposes already.

This probably will get very complicated with linking. Lets discuss it when we get there.

[jakelang]

@axic I think versioning in the namespace should be ok.
This does really complicate linking semantics, however. A custom section can have multiple subsections, though, which allows us to separate the deployer data and the EEI namespace. And it is simpler, IMO, for a VM to just use the correct version of the EEI upon reading the custom section.

[axic]

My other uses for custom sections are not that much ewasm specific and would feel weird to have one very complicated ewasm-specific custom section with all these different features smacked into it.

[lrettig]

Linking relevant threads here from the FEM forum:

• https://ethereum-magicians.org/t/remediations-for-eip-1283-reentrancy-bug/2434/57
• https://ethereum-magicians.org/t/immutables-invariants-and-upgradability/2440

[axic]

This is a different kind of versioning thread. The relevant one for that is ethereum/EIPs#154

[lrettig]

Also #17 and #153. Thanks.