IIP-3: Allow messages without `&self` receiver; opt out of automatic storage loading about ink HOT 5 OPEN

My personal take. I think this would be a useful feature to have. I personally do not see any security implications with this feature other than a potential user error, but this can be fixed with extensive documentation.

On the other, hand, introducing this feature will highlight the issue addressed in #1969 (i.e. ink! does not provide immutability in messages intrinsically). Since it would be absolutely valid to have this:

#[ink(message)]
fn update_cell(value: u8) {
  Lazy::<u8, ManualKey<127>>::new().set(&value);
}

Therefore, as part of this PR, I believe we should then remove mutability field from the metadata and advertise ink! code as mutable. Even though this is beyond the scope of this issue, it is affected as well.

My sentiment has always been removing direct storage and code manipulation and provide an encapsulating interface that would handle storage access and code upgrades while inferring the mutability from the message it is called. But again, beyond the scope of this issue.

I think this feature would actually pave the way for the upgradeability interface which I will outline later this week.

On the final note, I think ink::env::set_code_hash::<<Self as ink::env::ContractEnv>::Env>(&code_hash).unwrap() can be turned into a proc macro set_code_hash!(&code_hash).unwrap() for shortness.

from ink.

Therefore, as part of this PR, I believe we should then remove mutability field from the metadata and advertise ink! code as mutable. Even though this is beyond the scope of this issue, it is affected as well.

There still exists the distinction that mutable messages will automatically persist the top level storage struct upon successful execution. It is a limitation that the mutability does not provide us with any guarantees, if a user chooses to use the underlying APIs, as @xermicus says #1969 (comment).

My sentiment has always been removing direct storage and code manipulation and provide an encapsulating interface that would handle storage access and code upgrades while inferring the mutability from the message it is called. But again, beyond the scope of this issue.

At the moment the ink codegen requires the public API for reading/writing from storage. Maybe there is a technique we can use to hide that API from being used directly by the contract author, but I can't think off the top of my head a way to prevent calling the under the covers methods entirely, if they are to be exposed to the codegen.

from ink.

It is a limitation that the mutability does not provide us with any guarantees, if a user chooses to use the underlying APIs

Indeed, that's why we should discourage the use of the interface in favour of higher-level APIs that should come in future.

At the moment the ink codegen requires the public API for reading/writing from storage. Maybe there is a technique we can use to hide that API from being used directly by the contract author, but I can't think off the top of my head a way to prevent calling the under the covers methods entirely, if they are to be exposed to the codegen.

This is obviously a massive refactoring of the ink_env crate which is not the main priority atm. Therefore, as mentioned earlier, we should simply provide a better interface that would be favourable to use instead of direct storage operations for upgradeability. I see the design described in this issue as a step forward to it, but only if it will not be used by the developer directly and will be encapsulated as part of some migration function in future.

It's okay to use it now, since it allows devs to "unscrew" the migration as I mentioned in #1909 (comment)

from ink.

I've just successfully tested an approach to upgrade contracts with breaking storage changes and it might be used to fix broken contracts using the proposal:

Intermediate contract version preparation

• Move the new (breaking contract) field into a struct
• Add the previous working version of the field into the struct
• Implement parity_scale_codec::Decode manually for the struct to decode only the working field
• Transform the working field value into the new field value in the upgrading code function (the function should be mutable)
• Implement parity_scale_codec::Encode manually for the struct to encode only the new field

Final contract version preparation

• Turn the struct into the new field back
• Remove transforming value code from the upgrading function

Contract upgrade itself

• Upgrade contracts to intermediate and then to final contract version in one transaction

from ink.

Thankyou @ShadoySV that is a nice idea for a workaround!

from ink.