Updating Move code

The Aptos network supports code updates, which means that already deployed Move code can be replaced with newer code. If a code update occurs, all users of the updated code will automatically receive the new code the next time their code is executed.

Code upgrades allow code owners to develop their contracts or frameworks under a stable, well-known account address that can be referenced by other applications inside or outside the network.

Code updates are based on an update policy that the package owner determines. The default policy is (backward) compatibility. This means that only updates are accepted which guarantee that none of the existing public APIs (including transactions and public functions) and/or the existing resource repository will be compromised by the update. This compatibility check is technically complete and possible due to the highly typed semantics of Move bytecode. However, even a compatible update can have dangerous consequences for applications, so the dependency of the updated code on the network must be carefully considered on a case-by-case basis (see also the discussion of security aspects below).

How it works

Code updates on the Aptos network occur at the Move package level. The package defines the update policy in the Move.toml manifest:

[package]
name = "MyApp"
version = "0.0.1"
upgrade_policy = "compatible"
...
Enter fullscreen mode Exit fullscreen mode

*CHECK FOR COMPATIBILITY
*> Aptos checks compatibility during publication of the Move package using a special Aptos framework transaction. This transaction aborts if compatibility is not met.

Upgrade Policy

Three different upgrade policies are currently supported:

  • compatible: updates must be backward compatible, in particular:

    • For a repository, all old struct declarations must be the same in the new code. This ensures that the existing state of the repository will be interpreted correctly by the new code. However, new structure definitions can be added.
    • For the API, all public functions must have the same signature as before. New functions can be added.
  • immutable: the code cannot be updated and is guaranteed to remain unchanged forever.

  • arbitrary: code can be arbitrarily updated without any compatibility checks.

These policies are ordered by strength as follows: arbitrary < compatible < immutable. A package’s network policy can only get stronger, not weaker. Furthermore, the policy of all dependencies of a package must be stronger or equal to the policy of a given package. For example, a immutable package cannot directly or indirectly reference a compatible package. This gives users a guarantee that no unexpected updates will happen under the hood. There is one exception to this rule: Framework packages installed at addresses 0x1 through 0xa are exempt from dependency checks. This is necessary so that a immutable package can be defined based on standard libraries that have a compatible policy.

In addition to the above rules, there is another rule for arbitrary packages: the dependency of a package with a arbitrary update policy must be within the same account (two packages must be located in the same address). This restriction is intended to protect users from abuse when sharing such packages. One account can work with arbitrary without restriction, but sharing such code is not allowed.

Security Considerations for Dependencies

As mentioned above, even compatible updates can lead to dangerous effects on contracts that depend on the updated code. These effects can arise simply from bugs, but can also be the result of malicious updates. For example, an updated dependency can suddenly cause all functions to crash, disrupting your contract, or suddenly require much more gas to run than before the update. Since you have no control over the update, dependencies on updated packages should be handled carefully.

  • The safest dependency is of course the immutable package. It is guaranteed never to change, including its transitive dependencies (per the Aptos framework module). In order to evolve a immutable package, its owner must submit a new major version, which is practically an independent new package. Currently, major versions must be expressed by naming (e.g. module feature_v1 and module feature_v2). However, not all package owners like to publish their code as immutable, because this deprives them of the ability to fix bugs and develop the code in place.
  • If you have a dependency on a compatible package, it is highly recommended that you know and understand the organization publishing the package. The highest level of assurance is that the package is managed by a DAO, where no user can initiate an update, but there must be a vote or something similar. This, for example, is the case with the Aptos framework.
  • Dependencies on arbitrary packages are technically only allowed in one account, so the decision to upgrade and the responsibility to ensure compatibility lies with the account owner.

Software upgrade

In general, Aptos offers, via the Move aptos_framework::code module, ways to publish code from anywhere in your smart contracts. Note, however, that code published in the current transaction cannot be executed until that transaction is complete.

The Aptos Framework itself, including all of the network administration logic, is an example for software updates. The framework is marked as compatible. Updating is done using special generated management scripts. For more information, see Aptos Management.

Оцените статью
devanswers.ru
Добавить комментарий