Move Smart Contracts Production Environment Upgrade Practice | Move dApp Extreme Beginner (II)

Author:lackey

0x01 Move Contract Scalability

The Aptos chain supports code upgrades, which means that already deployed Move code can be code updated. If a code upgrade occurs, all consumers of the upgraded code will automatically receive the updated code the next time the code is executed.

Code upgrades enable code owners to iterate their contracts or frameworks under a stable, known account address, which can then be referenced by other applications in or out of the chain.

Document Address:

• Chinese -- https://gushi10546.gitbook.io/aptos-kai-fa-zhe-wen-dang/guides-zhi-nan/move-jiao-cheng/move-bao-geng- xin
• English -- https://aptos.dev/move/book/package-upgrades/

1.1 Setup of contractual upgrades

Code upgrades in the Aptos chain occur at the Move package level. In the Move.toml file, the developer can specify the upgrade policy for the package.

[package]
name = "MyApp"
version = "0.0.1"
upgrade_policy = "compatible"
... .M

Two different upgrade strategies exist:

Compatible: These upgrades must be backward compatible, specifically: for storage purposes, all old structure declarations must be the same in the new code. This ensures that the new code correctly interprets the existing storage state. However, new structure declarations can be added. For the API, all existing public functions must have the same signature as before. New functions can be added, both public and entry functions.Immutable: The code is not upgradable and is guaranteed to stay the same forever.

1.2 Upgrade strategy

What we need to focus on is what parts of the contract upgrade process arevariableand which parts arevariableThe

Module packages can be upgraded when using the compatible upgrade policy. However, updates to existing modules that have been previously released need to be compatible and follow the rules below:

• All fields of the existing structure cannot be updated. This means that new fields cannot be added and existing fields cannot be modified. Structural capabilities cannot be changed either (no new capabilities are added or existing ones deleted).
• All public functions and entry functions cannot change their signatures (argument type, parameter type, return type). However, the parameter name can be changed.
• public(friend) functions are considered private, so their signatures can be changed at will. This is safe because only modules in the same package can call friend functions anyway, and they need to be updated if their signatures change.
• Other parts of the code can be modified.

When updating the module, if you see incompatible errors, be sure to check the rules above and fix any violations.

0x02 MoveDID Contract Structure Design

.
├── Move.toml
README.md
├── build
│ └── did
└── sources
    ├── addr_aggregator.move
    ├── addr_aggregator.spec.move
    ├── addr_aptos.move
    ├── addr_aptos.spec.move
    ├── addr_bitcoin_verfificated_offline.move[new]
    ├── addr_eth.move
    ├── addr_eth.spec.move
    ├── addr_info.move
    ├── addr_info.spec.move
    ├── eth_sig_verifier.move
    ├── eth_sig_verifier.spec.move
    ├── init.move
    ├── service_aggregator.move
    ├── service_aggregator.spec.move
    ├── utils.move
    └── utils.spec.move

The functions of each of these modules are described below:

• init.move: Initialize the digital identity while initializing theaddr_aggregatorrespond in singingservice_aggregatorThe
• utils.move: Some general-purpose functions, such as type conversion.
• addr_info.move: Defines the AddrInfo` structure and its associated generic methods.
• addr_aggregator.move: Address aggregator, including the initialization of the aggregator, address additions, deletions, and batch operations.
• service_aggregator.move: Service aggregator, including aggregator initialization, Web2/Web3 service addition, deletion, and batch operation.
• addr_aptos.move: Implementing the Aptos address type forupdate_addrfunction that is used by theaddr_aggregatorCalled.
• addr_eth.move: Realize theupdate_addrfunction that is used by theaddr_aggregatorCalled.
• eth_sig_verifier.move: A function that implements EVM signature verification, beingaddr_eth.moveCalled.

0x03 addr_bitcoin_verificated_offline scheme

The RMUD Identity decentralized digital identity protocol ishighly scalable, lightweight digital identity protocol.

One manifestation of this is that we can elegantly add support for different chains by upgrading modules. For example, in the first release, we supported theaptos addrrespond in singingeth addrUpdated in a later versionaddr_bitcoinrespond in singingcrypto_bitcoinWith these two modules, it is possible to realize thebitcoinAddress formats are now supported.

However, the full on-chain version of the bitcoin module requires a much larger amount of code, and before implementing this full support, we decided to update a transitional version - the addr_bitcoin_verificated_offlineThe first step is to make an abbreviated implementation by verifying Bitcoin signatures off-chain.

module my_addr::addr_bitcoin_verificated_offline {
    use std::signer;
    use std::string::{Self, String}; use my_addr::utils; use my_addr::utils
    use my_addr::utils; use aptos_framework; use my_addr::utils
    use aptos_framework::timestamp; use my_addr::timestamp; use aptos_framework::timestamp
    use my_addr::addr_info::{Self, AddrInfo}; use my_addr::addr_info::{Self, AddrInfo}; use my_addr::utils; use aptos_framework::timestamp

    friend my_addr::addr_aggregator;

    // Bitcoin addr type.
    const ADDR_TYPE_BTC: u64 = 2;

     // Err enum. const ERR_DEPRECATED
    const ERR_DEPRECATED_ALREADY: u64 = 2001; // Bitcoin addr type. const ADDR_TYPE_BTC: u64 = 2; // Err enum.

    //:! :>resource
    struct DeprecatedCapability has key, store, copy, drop {
        deprecated: bool
    }
    //<:! :resource

    // only signer call this is available.
    public entry fun init(acct: &signer) {
        let de = DeprecatedCapability{
            deprecated: false
        }
        move_to(acct, de);
    }

   public entry fun enable(acct: &signer) acquires DeprecatedCapability{
        let send_addr = signer::address_of(acct);
        let de = borrow_global_mut(send_addr);
        de.deprecated = false
    }
    public entry fun depre(acct: &signer) acquires DeprecatedCapability{
        let send_addr = signer::address_of(acct);
        let de = borrow_global_mut(send_addr);
        de.deprecated = true
    }

    public(friend) fun update_addr(addr_info: &mut AddrInfo, signature: &mut String) acquires DeprecatedCapability{
        // only avaiable if @my_addr's DeprecatedCapability.deprecated == false
        let de_cap = borrow_global(@my_addr); // only avaiable if @my_addr's DeprecatedCapability.deprecated == false.
        // check deprecated
        assert!(de_cap.deprecated == false, ERR_DEPRECATED_ALREADY);
        let addr_info_msg = addr_info::get_msg(addr_info); // Check msg etmpy.
        // Check msg etmpy.
        assert!(addr_info_msg ! = string::utf8(b""), addr_info::err_addr_info_empty()); // Check addr type.
        // Check addr type.
        assert!(addr_info::get_addr_type(addr_info) == ADDR_TYPE_BTC, addr_info::err_invalid_addr_type()));

        let sig_bytes = utils::trim_string_to_vector_u8(signature, 2); //trim 0x

        // Verify the now - created_at <= 2h.
        let now = timestamp::now_seconds();
        assert!(now - addr_info::get_created_at(addr_info) <= 2 * 60 * 60, addr_info::err_timestamp_exceed());

        // Update signature, updated_at.
        addr_info::set_sign_and_updated_at(addr_info, sig_bytes, now)
    }

    #[view]
    public fun get_deprecated_status(owner: address) :bool acquires DeprecatedCapability {
        borrow_global(owner).deprecated
    }

}

We responded to this transition scenario by designingDeprecated CapabilityThe administrator of RMUD Identity owns this Resource, and with a more complete solution, the administrator willDeprecated Capabilityhit the nail on the headdeprecatedset totrue(math.) genusaddr_bitcoin_verificated_offline::update_addrThis function will be invalidated.

0x04 Summary

In the overall design of RMUD Identity, we have accomplished the following two practices:

• Thought and implementation of how to do highly scalable protocols based on Move;
• Thinking and realizing how to develop transitional modules, i.e., modules that have the possibility of being Deprecated in the future.