Add support for the delayed upgrade

[karim-en]

Implement #20

Added apis:

- up_storage_prefix();
- up_get_delay_status(&self) -> UpgradableDurationStatus;
- up_init_staging_duration(staging_duration: near_sdk::Duration);
- up_stage_update_staging_duration(staging_duration: near_sdk::Duration);
- up_apply_update_staging_duration();

Added storage keys:

- "StagingDuration":  to save the delay duration of deploying staged code.
- "UpdateStagingDuration": to save the staged delay duration update.
- "StagingTimestamp": to save the allowed timestamp to apply the staged duration or code.

[mfornet]

Orthogonal to this PR. I wonder if we should avoid borsh here and use json, passing the code in base64. It will be more inefficient, but better for readability.

[karim-en]

@mfornet @sept-en
I've implemented it as base64 here 5c23697, but I worry that the gas limit could be reached faster by deploying a big contract.

The difference is 12TG for the example contract
https://explorer.testnet.near.org/transactions/HhRhMqRxLg2fSSEZ1ND3mBNL7m7wmw4oqqZmzVCPq6M4
https://explorer.testnet.near.org/transactions/7jn1RE5y9VwzvAQ1Q9Mpd5JqnB7KXZfou1NXKe6uWdRd

[birchmd]

LGTM

[mooori]

I think the README should be updated to explain how to use Upgradable with delay. If I’m not mistaken, it can not be used without delay anymore (up_deploy_code panics if there’s no staging timestamp).

[mooori]

How about introducing helper functions for storage writes too? It’s a nit, but I think it would improve readability.

#[inline]
fn up_set_duration(key: __UpgradableStorageKey, duration: &near_sdk::Duration) {
  near_sdk::env::storage_write(self.up_storage_key(key).as_ref(), duration.to_be_bytes());
}

// Same for `fn up_set_timestamp`.

These functions would be the counterparts of up_get_{duration, timestamp}.

---

Please remember to update the Upgradable section in the root README.

[karim-en]

How about introducing helper functions for storage writes too? It’s a nit, but I think it would improve readability.

#[inline]
fn up_set_duration(key: __UpgradableStorageKey, duration: &near_sdk::Duration) {
  near_sdk::env::storage_write(self.up_storage_key(key).as_ref(), duration.to_be_bytes());
}

// Same for `fn up_set_timestamp`.

These functions would be the counterparts of up_get_{duration, timestamp}.

Please remember to update the Upgradable section in the root README.

fixed in :
6489041
3a1f09a

[mooori]

How about using the term delay instead of staging duration in the code? I think that could make things clearer, for instance:

fn up_stage_new_delay(&self, delay: Option<near_sdk::Duration>);

// instead of

fn up_stage_update_staging_duration(&self, staging_duration: Option<near_sdk::Duration>);

---

There are events for StageCode and DeployCode.

https://github.com/aurora-is-near/near-plugins/blob/6489041834e6f7040f583b6795f15eebfc4cee30/near-plugins/src/upgradable.rs#L90-L95

https://github.com/aurora-is-near/near-plugins/blob/6489041834e6f7040f583b6795f15eebfc4cee30/near-plugins/src/upgradable.rs#L110-L115

I think it would make sense to also have events like StageDelay and SetDelay

[karim-en]

How about using the term delay instead of staging duration in the code? I think that could make things clearer, for instance:

fn up_stage_new_delay(&self, delay: Option<near_sdk::Duration>);

// instead of

fn up_stage_update_staging_duration(&self, staging_duration: Option<near_sdk::Duration>);

There are events for StageCode and DeployCode.

https://github.com/aurora-is-near/near-plugins/blob/6489041834e6f7040f583b6795f15eebfc4cee30/near-plugins/src/upgradable.rs#L90-L95

https://github.com/aurora-is-near/near-plugins/blob/6489041834e6f7040f583b6795f15eebfc4cee30/near-plugins/src/upgradable.rs#L110-L115

I think it would make sense to also have events like StageDelay and SetDelay

The term staging duration is already used in the NEP, NEP implementation, so I am skeptical about adding new terminology

Outdated

[birchmd]

I think we should get this merged. @mooori please take another look and let us know if you have any additional comments.

[mooori]

LGTM in general. Left some minor comments that I think should be addressed before merging.

[mooori]

@karim-en thanks!