パッケージのアップグレード
Aptosブロックチェーン上のMoveコード(例: Moveモジュール)はアップグレード出来ます。コード所有者とモジュール開発者は、変更されない単一の安定した既知のアカウントアドレス下でコントラクトを更新及び進化させる事が出来ます。モジュールのアップグレードが発生すると、そのモジュールの全ての消費者は、コード(例: 次回それで対話する)の最新バージョンを自動的に受け取ります。
Aptosブロックチェーンは異なる アップグレードポリシー を元々サポートしており、Move開発者はMoveコードのアップグレード方法関連の制約を明示的に定義出来ます。デフォルトのポリシーは 下位互換性 が有ります。つまり、コードのアップグレードは、アップグレードによって壊れたリソースストレージまたはパブリックAPI(パブリック関数を含む)が無い事が保証される場合のみ受け入れられます。この互換性チェックが可能なのは、Moveの厳密に型指定されたバイトコードセマンティクスゆえです。
注意: 互換性のあるアップグレードであっても、アプリケーションや依存するMoveコードに危険な影響を与える可能性が有ります(例えば、基礎となるモジュールのセマンティクスが変更された時)。
結果として、開発者は、オンチェーンでアップグレード出来る第三者のMoveコードに依存する場合は注意が必要です。詳細は 依存関係のセキュリティ考慮事項を御覧下さい。
使い方
Aptosブロックチェーン上のMoveコードのアップグレードはMoveパッケージの粒度で行われます。パッケージはMove.tomlマニフェスト内でアップグレードポリシーを指定します。
[package]
name = "MyApp"
version = "0.0.1"
upgrade_policy = "compatible"
...
AptosはMoveパッケージがAptosトランザクションを介して公開される時、互換性をチェックします。互換性がないと判断された場合、このトランザクションは中止されます。
アップグレード方法
既に公開したMoveコードをアップグレードするには、以前に公開したのと同じアドレスでコードを再公開するだけです。これはAptos CLIを使用してコードのコンパイルと公開の手順に従って実行出来ます。 例えば初めてのMoveモジュールチュートリアルを御覧下さい。
アップグレードポリシー
現在Aptosでは2つの異なるアップグレードポリシーをサポートしています。
compatible: これらのアップグレードは下位互換性がなければなりません。具体的には、- ストレージの場合、全ての古い構造体宣言は新しいコード内で同じである必要があります。これにより、ストレージの既存の状態が新しいコードによって正しく解釈されます。ただし、新しい構造体宣言を追加する事は出来ます。
- APIの場合、既存の全てのパブリック関数は以前と同じ署名を持つ必要があります。パブリック関数やエントリ関数を含む新しい関数を追加出来ます。
immutable: コードはアップグレード出来ず、永久に同じである事が保証されます。
これらのポリシーはcompatible < immutable即ち互換性が不変よりも弱い、の様な強度の順序で並べられています。オンチェーンのパッケージのポリシーは、弱くなる事はなく強くなる以外有りません。更にパッケージの全ての依存関係のポリシーは、指定されたパッケージのポリシーよりも強力であるか、同等である必要があります。例えば、immutableパッケージは直接的または間接的にcompatibleパッケージを参照する事が出来ません。これにより、ユーザーは内部で予期しない更新が発生しない事が保証されます。
注意: 上記のルールには例外がひとつ有ります。0x1から0xaのアドレスへインストールされたフレームワークパッケージは、依存関係チェックの対象外です。
これは、標準ライブラリに基づいてimmutableパッケージを定義出来るようにするため必要で、ライブラリはcompatibleポリシーを持ち、重要なアップグレードと修正を許可します。
互換性ルール
compatibleアップグレードポリシーを使用すると、モジュール パッケージをアップグレード出来ます。ただし、以前に公開された既存のモジュールの更新は、互換性があり以下のルールへ従う必要があります。
- 全ての既存の構造体のフィールドは更新出来ません。つまり、新しいフィールドの追加や、既存のフィールドの変更は出来ません。構造体の機能も変更出来ません(新しい機能の追加や既存機能の削除は出来ません)。
- 全てのパブリック関数とエントリ関数は、署名(引数の型、型引数、戻り値の型)を変更出来ません。ただし、引数名は変更出来ます。
public(friend)関数はプライベートとして扱われるため、シグネチャは任意で変更する事が出来ます。いずれにしても、同じパッケージ内のモジュールだけがフレンド関数を呼び出す事が出来、署名が変更された場合は更新する必要が有るためこれは安全です。
モジュールを更新する時、互換性の無いエラーが表示される場合は上記のルールを確認し、違反を修正して下さい。
依存関係のセキュリティ考慮事項
上記の様に、互換性のあるアップグレードであっても、アップ グレードされたコードに依存するアプリケーションに壊滅的な影響を与える可能性があります。これらの影響はバグから発生する場合もありますが、悪意のあるアップグレードの結果である場合もあります。例えば、アップグレードされた依存関係によって突然全ての関数が終了し、Moveコードの動作が中断される可能性が有ります。あるいは、アップグレードされた依存関係によって、全ての関数の実行にかかるガスコストがアップグレード前よりも大幅に増加する可能性もあります。そのため、アップグレード可能なパッケージへの依存関係は慎重に扱う必要があります。
- 最も安全な依存関係は、もちろん
immutableパッケージです。これにより、依存関係はその推移的な依存関係も含め変更されない事が保証されます。不変のパッケージを更新するには、所有者は新しいメジャー バージョンを導入する必要がありますが、これは実質的には新しい個別の独立したパッケージをデプロイするのと同じです。メジャーバージョン管理は名前(例:module feature_v1とmodule feature_v2)でのみ表現で出来るためです。全てのパッケージ所有者がimmutableとしてコードを公開する事を好むわけではありません。これは、バグを修正してその場でコードを更新する機能が失われるためです。 compatibleパッケージの依存関係を所持している場合は、パッケージを公開している実体を知って理解しておく事を強くお勧めします。最も高いレベルの保証は、パッケージが分散型自律組織(DAO)によって管理され、単一のユーザーがアップグレードを開始できないようにし、投票などを行 う必要がある場合です。これはAptosフレームワークの場合です。
プログラムによるアップグレード
一般的に、AptosはMoveモジュールaptos_framework::codeを介して、スマート コントラクトのどこからでもコードを公開する方法を提供します。ただし、現在のトランザクションで公開されたコードは、そのトランザクションが終了した後でのみ実行出来る事に注意して下さい。
Aptosフレームワーク自体は、全てのオンチェーン管理ロジックを含め、プログラムによるアップグレードの例です。フレームワークは compatibleとしてマークされています。
アップグレードは、特定の生成されたガバナンススクリプトを介して行われます。詳細はAptosガバナンスを御覧下さい。