スマートコントラクトをアップグレードする方法は？

スマートコントラクトのアップグレード可能性を理解する

スマートコントラクトは設計により不変です。つまり、ブロックチェーンに展開されると、コードを変更できません。ただし、スマートコントラクトをアップグレードすることは、バグを修正し、機能を改善する、または変化する条件に適応する必要がある開発者にとって重要な要件です。スマート契約のアップグレード可能性は、既存の契約の直接的な変更ではありませんが、契約の状態と住所を維持しながらロジックの変更を可能にする設計パターンが含まれます。

これを達成するには、プロキシ契約、非構造化されたストレージプロキシ、永遠のストレージパターンなど、いくつかの方法があります。各方法には長所と短所があります。開発者は、スマートコントラクトにアップグレード可能性を実装する前に、どのアプローチがユースケースに最も適しているかを慎重に評価する必要があります。

アップグレード可能性のためにプロキシ契約を使用します

スマート契約をアップグレードする最も一般的で安全な方法の1つは、プロキシ契約を使用することです。これには、2つの契約を展開することが含まれます。州と転送の呼び出しを保持するプロキシ契約と、実際のロジックを含む実装契約です。

• 実装契約を指すDelegateCall関数を使用してプロキシ契約を展開します。
• スマート契約のロジックを含む初期実装契約を展開します。
• プロキシ契約の実装アドレスを設定して、実装契約のアドレスを指すようにします。
• アップグレードが必要な場合は、更新されたロジックを使用して新しい実装契約を展開します。
• プロキシのアドレスや状態を変更せずに、プロキシ契約の実装ポインターを新しい実装契約アドレスに更新します。

この方法により、ユーザーは同じ契約アドレスと対話することが保証されますが、基礎となるロジックはシームレスにアップグレードできます。

非構造化ストレージプロキシパターン

非構造化されたストレージプロキシパターンは、プロキシ契約法の高度なバージョンです。ストレージスロットを使用して実装アドレスを保存し、偶発的な上書きに対してより安全にします。

• プロキシ契約の特定のストレージスロットを定義して、実装アドレスを保存します。
• DeLegateCallを使用してすべての関数呼び出しを実装契約に転送するプロキシ契約にフォールバック関数を書きます。
• プロキシ契約と初期実装契約を展開します。
• インラインアセンブリまたは事前定義された関数を使用して、指定されたストレージスロットに実装アドレスを設定します。
• アップグレードするには、実装契約の新しいバージョンを展開し、ストレージスロットのプロキシの実装アドレスを更新します。

この方法は、プロキシのストレージを実装から分離し、ストレージの衝突のリスクを減らし、より安全なアップグレードを確保します。

永遠のストレージパターンの実装

永遠のストレージパターンは、データストレージをロジックから分離し、開発者がデータに影響を与えることなくロジックをアップグレードできるようにします。これは、データの持続性が重要な長期契約に特に役立ちます。

• すべてのデータ変数を保持するストレージ契約を作成します。
• 関数呼び出しを介してストレージ契約と対話するロジック契約を作成します。
• 展開中またはレジストリ契約を介して、ロジック契約をストレージ契約にリンクします。
• アップグレードが必要な場合は、新しいロジック契約を展開し、レジストリまたはストレージ契約で参照を更新します。
• 互換性を維持するために、新しいロジック契約が以前のバージョンと同じインターフェイスとデータ構造に従っていることを確認してください。

このパターンは、データを無傷に保ちながらロジックをアップグレードする柔軟性を提供し、複雑な分散型アプリケーションに最適です。

スマートコントラクトをアップグレードするための考慮事項

スマートコントラクトのアップグレードにはリスクがないわけではありません。開発者は、アップグレード可能性を実装する前に、いくつかの重要な要因を考慮する必要があります。

• セキュリティの意味：アップグレードメカニズムは、潜在的な攻撃ベクトルを導入します。プロキシ契約と実装契約の両方を徹底的に監査することが不可欠です。
• アクセス制御：アップグレードする機能は、信頼できるエンティティに制限する必要があります。マルチ署名ガバナンスまたはタイムロックを実装すると、セキュリティが強化されます。
• 互換性：新しい実装は、契約の破損を避けるために、既存のデータ構造と機能の署名と互換性がなければなりません。
• テスト：アップグレードが意図したとおりに機能し、新しいバグや脆弱性を導入しないことを確認するには、厳密なテストが必要です。
• ドキュメント：アップグレードプロセスとメカニズムの明確なドキュメントは、将来のメンテナンスと透明性に不可欠です。

これらの考慮事項は、アップグレードメカニズムが堅牢で安全で、保守可能であることを保証するのに役立ちます。

よくある質問

誰かがスマートコントラクトをアップグレードできますか？いいえ、スマート契約をアップグレードする機能は、通常、契約で定義されている特定のアドレスまたは役割に制限されています。これらの役割には、所有者の住所、ガバナンス契約、またはマルチシグウォレットが含まれる場合があります。

プロキシ契約を使用せずにアップグレード可能性は可能ですか？はい、プロキシ契約は最も一般的な方法ですが、永遠のストレージパターンやモジュラー契約設計などの他のアプローチは、アーキテクチャに応じてアップグレード性を可能にすることもできます。

契約のアップグレード中にユーザーファンドはどうなりますか？プロキシ契約は同じ住所と状態を維持しているため、ユーザーファンドはアップグレード中は引き続き安全です。基礎となるロジックは更新されますが、ストレージとバランスは影響を受けません。

展開前にスマートコントラクトのアップグレードをテストするにはどうすればよいですか？アップグレードプロセスをシミュレートすることにより、ローカルブロックチェーンまたはテストネットのアップグレードをテストできます。 HardhatやTruffleなどのツールを使用して、制御された環境でプロキシおよび実装契約を展開およびテストします。