Comments (5)
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.
Related Issues (20)
- The function `set_contract_storage` in integration test it's missing a size check.
- Linter: Unprotected `terminate_contract`
- Linter: Unprotected `DelegateCall` call
- Immutable contracts allowed to change state via `env` HOT 4
- Add a lint for missing `no_main`
- Different gas value for `weight_to_fee()` in ink! integration and e2e tests HOT 6
- Split up `ink_linting` into two `dylint` libraries HOT 1
- Use standard Github's machines for test jobs
- Linter: Warn about using non-fallible APIs for `Lazy` and `Mapping` HOT 1
- Support expressions for `extension` and `function` during chain extension definition
- Event defintions with generics
- Deprecation of "legacy" inline events HOT 1
- Unify `call-runtime` and `e2e-call-runtime` examples
- Linter: Dangereous `self.env().transferred_value()` pattern
- Linter: Divide before multiply
- Add support and integration test for `caller_is_root`
- Migrate ink! CI from organization runners to standard GitHub runners
- Add links to linter warning details on use.ink
- Cross contract calling produces unsupported code HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ink.