Smart Contract Upgradability

[ilblackdragon]

Smart contract upgradability

In NEAR smart contracts are upgradable in-place by default.
This means that given a specific account-id - the contract code may change depending on various rules.

Non-upgradable

There are many contracts that should not be upgradable.

There are two ways that contract code can be upgraded in-place: using an access key and contract re-deploying it's own code.

To determine if contract is not upgradable, need to check that contract doesn't have any full access keys and that contract's code doesn't contain any DeployContract calls to itself.

Additionally, contract code can contain ability to add FullAccessKeys to itself, and in this way return back control to the facilitator (for example multisig and lockup contracts have this ability under certain circumstances).

Accessible contract

Accessible contracts are contracts that have access keys with ability to re-deploy new code on them.

Usually this will be used for development or in some highly permissioned settings.

For example, contracts like multisig is really owned by the person or people who control it and hence they can re-deploy the code on it to upgrade or remove multisig.

Owner-pattern

Owner pattern means that contract's upgradability is owned by a different account.

This allows to introduce a more sophisticated management, anything from multisig to DAO. This also allows to easily evolve the management over time. For example, starting from simple account, one can change owner later to multisig and later upgrade to a DAO.

Owner upgradable pattern introduces next set of methods on a contract that follows this standard:

    /// Returns current owner account.
    get_owner() -> AccountId

    /// Sets new owner. If owner is set to `system` this contract is considered to be non-upgradable without hard forks.
    /// Can only be called by owner.
    set_owner(owner: AccountId)

    /// Returns how long between staging code and deploy can be called in nanoseconds.
    /// Usually staging duration is set at deploy. Good defaults are 1 and 7 days.
    get_staging_duration() -> WrappedDuration

    /// Stages new contract on the given account. 
    /// Can only be called by owner.
    /// This means that contract code is ready to be activated after specific staging time passes.
    /// Caller is responsible for attaching extra balance to cover storage.
    stage_code(code: bytes)

    /// Deploys staged code. 
    /// Can only be called by owner.
    /// If there is no staged code, will fail.
    deploy_code()

TBD: do we want to have a way to change staging duration?

State migrations

This section is TBD on state migration patters

[render]

Your Render PR Server URL is https://nomicon-pr-123.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-bu073aipp1jok35mbkog.

[ilblackdragon]

Referencing a overview for upgradability in Ethereum - https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/

[bowenwang1996]

TBD: do we want to have a way to change staging duration?

Should we also allow activation upon some absolute time?

[ilblackdragon]

@bowenwang1996

Should we also allow activation upon some absolute time?

Interesting, we can make stage_code to take timestamp. And just check that timestamp is further than staging duration to satisfy the requirement. This would make timing more predictable so people who deploy don't need to stage it perfectly to have a round deployment time.

Also interesting consideration if deploy_code should be available for anyone to call - then there can be a "cron" service that just calls it when it's time. The problem is that there should be a way to "unstage" then.

I also think it's important to match this with an advance tool I was describing: neard --launch-from-mainnet --fast-time. This would start from a current snapshot of mainnet but with given node as a validator and also run with faster time. This way you can fork from snapshot, stage, then test as if it was deployed in mainnet as a final check with all the other contracts and real user state.

[bowenwang1996]

I also think it's important to match this with an advance tool I was describing: neard --launch-from-mainnet --fast-time. This would start from a current snapshot of mainnet but with given node as a validator and also run with faster time. This way you can fork from snapshot, stage, then test as if it was deployed in mainnet as a final check with all the other contracts and real user state.

Sounds nice, but I don't think it is trivial to build :(

[Kouprin]

How does voting for upgrade look like? For non-trustless case I see no concerns.

[ilblackdragon]

How does voting for upgrade look like? For non-trustless case I see no concerns.

This standard doesn't define how exactly owner decides to upgrade or not. It can be anything from multisig to DAO to a single person deciding, to using Oracle if price is above :)

[alexauroradev]

What about pausablity of a contract or escape hatches or commit-reveal scheme? Should we allow for this because of security upgrades?

[alexauroradev]

I also think it's important to match this with an advance tool I was describing: neard --launch-from-mainnet --fast-time. This would start from a current snapshot of mainnet but with given node as a validator and also run with faster time. This way you can fork from snapshot, stage, then test as if it was deployed in mainnet as a final check with all the other contracts and real user state.

How does this differ from using different staging time?

[ilblackdragon]

How does this differ from using different staging time?

This would be a tool for testing locally contracts while developing. Not related to staging itself.

[mfornet]

This section is TBD on state migration patters

Is there any discussion somewhere about state migration patterns?

[ilblackdragon]

https://github.com/near/near-sdk-rs/blob/31cba6213919ec4866bc0fab7f6963de241cc43a/HELP.md#upgrading-a-contract

[ori-near]

Hi @ilblackdragon (or anyone who is interested in championing this NEP forward) – We are cleaning the NEP backlog and noticed that this PR still has some remaining "TBD" sections noted. Therefore, we are labeling this PR as "Needs author revision."

Please ping the @near/nep-moderators once you are ready for us to review it. We will review it again in February, unless we hear from you sooner. We typically close NEPs that are inactive for more than two months, so please let us know if you need more time.

[ilblackdragon]

I do think it's an important to standardize as we currently have a zoo of upgradability patterns. But I will not be one to do this. I'm going to close until an author who can put in time can be found.