-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Versioning in contracts #121
Comments
I think that simply versioning the "ethereum" import interface would make the best sense. 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. |
@axic we need another decisions call or something, otherwise these things will stay on the back burner forever. |
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? |
@lrettig good question. |
Like you said, we need another decision call to discuss this stuff :) |
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. |
@axic I think versioning in the namespace should be ok. |
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. |
Linking relevant threads here from the FEM forum: |
This is a different kind of versioning thread. The relevant one for that is ethereum/EIPs#154 |
This proposal could be extended to be a platform metadata section giving opportunity for storing more details. |
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:
ethereum@3
- the current revision), but disallow multiple versions.Option 2) means that the Sentinel contract would need to verify the contract based on the value in the custom section.
The text was updated successfully, but these errors were encountered: