Actually there is the legacy interpreter and the normal interpreter which support @version field.
We should ensure all new smart contract are created with the normal interpreter and are versionned as the legacy interpreter may not be maintained.
Describe the solution you'd like
In the pending validation we already parse the contract to ensure the code is valid.
We could have another control before parsing, that verify if the last transaction has code or not.
If the last transaction does not have code, the current transaction should use versionned interpreter with @version.
If the previous transaction has code, then if the code is legacy, we allow legacy code, if the code is not legacy, the new transaction must also be on versionned interpreter
Describe the problem you discovered
Actually there is the legacy interpreter and the normal interpreter which support
@version
field. We should ensure all new smart contract are created with the normal interpreter and are versionned as the legacy interpreter may not be maintained.Describe the solution you'd like
In the pending validation we already parse the contract to ensure the code is valid. We could have another control before parsing, that verify if the last transaction has code or not. If the last transaction does not have code, the current transaction should use versionned interpreter with @version. If the previous transaction has code, then if the code is legacy, we allow legacy code, if the code is not legacy, the new transaction must also be on versionned interpreter