プロキシ パターンを使用してスマート コントラクトをアップグレードするにはどうすればよいですか?

Ethereum のプロキシ パターンを理解する

1. プロキシ パターンは、プロキシと実装という 2 つの別個のコントラクトを展開することによって、コントラクト ロジックをストレージから切り離します。

2. ユーザーはプロキシとのみ対話し、プロキシはすべての呼び出しを delegatecall を使用して現在の実装コントラクトに転送します。

3. データの破損や不整合を防ぐために、実装のアップグレード間でストレージ レイアウトの一貫性を保つ必要があります。

4. プロキシは実装アドレス用に 1 つのストレージ スロットを維持し、ユーザーの状態に影響を与えることなくアドレスを更新できるようにします。

5. このアーキテクチャにより、オンチェーンの残高、許容値、および過去の相互作用を維持しながら、下位互換性のある変更が可能になります。

透過的プロキシの主要コンポーネント

1. プロキシ コントラクトには、delegatecall 経由で外部呼び出しを指定された実装にルーティングするフォールバック関数が含まれています。

2. 管理者ロールはアップグレード権限を制限するために適用されます。承認されたアドレスのみが実装ポインタを変更できます。

3. 修飾子は、アップグレード ロジックを実行する前に呼び出し元が管理者であるかどうかをチェックし、不正な再構成を防ぎます。

4. 実装コントラクトは、ストレージ構造を定義する基本コントラクトを継承し、プロキシのレイアウトとの整合性を確保する必要があります。

5. 関数セレクターはバージョンを超えて保持されます。新しい関数は、意図的に動作をオーバーライドしない限り、既存の関数との衝突を避ける必要があります。

導入とアップグレードの手順

1. コア ビジネス ロジックと必要な状態変数を含む初期実装契約を展開します。

2. プロキシ コントラクトをデプロイし、最初の実装のアドレスでストレージを初期化し、管理アドレスを設定します。

3. テスト関数を呼び出し、戻り値が予想される出力と一致することを確認することで、プロキシが呼び出しを正しく委任していることを確認します。

4. アップグレードする場合は、ロジックは変更されているがストレージ レイアウトは同じである新しい実装コントラクトをコンパイルして展開します。

5. 新しい実装アドレスを使用してプロキシの upgradeTo 関数を呼び出し、管理者のみがこのトランザクションをトリガーするようにします。

セキュリティに関する考慮事項と落とし穴

1. 実装間のストレージ レイアウトの調整が欠落しているか不正確であると、サイレント データ破損が発生します。変数が間違ったスロットから読み取られる可能性があります。

2. 管理者の役割を保護しないと、システム全体が悪意のあるアップグレードにさらされることになります。マルチシグネチャウォレットまたはタイムロックを考慮する必要があります。

3. コンストラクターはデリゲートコール コンテキストで実行されないため、初期化関数はデプロイメント後に個別に呼び出す必要があります。

4. 実装コードに埋め込まれた外部ライブラリの依存関係も、そのバイトコードがロジック コントラクトの一部であるため、一貫してアップグレードする必要があります。

5. アップグレード ロジックが重要な移行中に再帰的なデリゲート呼び出しを適切に保護しない場合、再入リスクが増加します。

よくある質問

Q: 導入後に管理者アドレスを変更できますか?はい、ほとんどのプロキシ実装には、現在の管理者が呼び出しを開始した場合に管理者アドレスを更新できるchangeAdmin関数が含まれています。

Q: アップグレードされた実装を初期化するのを忘れた場合はどうなりますか?コントラクトの状態が初期化されないままになるため、重要な変数がゼロまたは空のアドレスなどのデフォルト値のままになり、予期しない動作が発生する可能性があります。

Q: 以前の実装バージョンにダウングレードすることは可能ですか?はい、以前の実装契約がオンチェーンに存在し、互換性のあるストレージ レイアウトが保持されている限り、ダウングレードは技術的にサポートされます。

Q: デリゲート呼び出し中に発行されたイベントは、プロキシのアドレスまたは実装のアドレスの下に表示されますか? EVM は、イベントを発行するときにターゲットと呼ばれるデリゲートではなく、呼び出しコンテキストをログに記録するため、イベントはプロキシのアドレスで発行されます。