Smart contract upgradeability

[hugopeixoto]

I have applied for a w3f grant (w3f/Grants-Program#238) with a proposal for designing, demonstrating and documenting smart contract upgradability.

@mmagician suggested that we ask here whether anyone is working on it already. I searched #ink:matrix.parity.io and there are some folks asking about this, and some interesting points being discussed, but it doesn't seem like it's being worked on at the moment.

There are still some open questions on how to approach this, and part of the work will be to explore them, but any feedback on our proposed approach or on the problem in general would be appreciated.

[Robbepop]

I have read the proposal at w3f/Grants-Program#238.

Generally I like the experiments with smart contract upgradeability as long as it is opt-in and we can still have non-upgradeability (immutability) as a feature in smart contracts.

One point that disturbs me right now is:

For milestone 2, we will extract this pattern into an ink directive which will
automatically generate the proxied methods. This brings us ergonomy of use,
making upgradeability easy to opt in to.

It reads as if it is a declared goal of making a specialized ink! directive at any cost. However, there might be a good chance that the research finds out this won't be needed or a more general ink! directive that also helps with upgradeability will actually be a much better fit than a specialized feature.
So I'd like to restate that this second milestone heavily depends on the outcome of the first milestone and requires lots of design considerations before a specialized implementation of new directives in ink! are agreed upon.

[mmagician]

@Robbepop Thanks for the input - I would propose we reduce the scope of the grant to the first milestone (for now) & once it's ready, we see how to proceed.

[hugopeixoto]

Thanks for the review. I think this makes sense, M2 was more of a "let's figure out the mechanism and extract the ink directives that need to be in place for this to be ergonomic" and less of a "we're totally going to extract this particular mechanism". I'll update the proposal.

[HCastano]

Closing this in favour of #698 which is more general and actionable.