アップグレード可能なコントラクト

アップグレード可能なコントラクトとは？

アップグレード可能なコントラクトとは、ブロックチェーンアプリケーションが、ユーザー向けアドレス、保存済み状態、残高を維持したまま、デプロイ後にロジックを変更または拡張できるスマートコントラクト設計です。

暗号資産において、アップグレード可能なコントラクトは主に、DeFiプロトコル、トークンシステム、ステーキングコントラクト、ブリッジ、レンディング市場、スマートアカウント、ガバナンスシステム、その他、時間の経過とともに修正や新機能が必要となる可能性のあるオンチェーンアプリケーションに使用されます。

従来のスマートコントラクトは、オンチェーンにデプロイされたコードを直接編集できないため、通常は不変（immutable）と説明されます。

アップグレード可能なコントラクトは、コントラクトアドレスと保存データを、ユーザー操作を実行するビジネスロジックから分離することで、この制約を解決します。

アップグレード可能なコントラクトの最も一般的な構築方法はプロキシパターンです。この方式では、ユーザーはプロキシコントラクトとやり取りし、プロキシは呼び出しを別の実装コントラクトへ転送します。

プロキシは同じ公開アドレスを維持し、認可されたアップグレードが行われると実装コントラクトは新しいバージョンに置き換えられます。

つまり、プロトコルがバグを修正したり、機能を追加したり、内部ロジックを改善したりするたびに、ユーザーは新しいコントラクトアドレスへ移行する必要がありません。

暗号資産ユーザーにとっての主な利点は継続性です。トークン残高、ステーキング記録、投票力、プロトコル内のポジションを同じコントラクトストレージ内に維持できます。

開発者にとっての主な利点は柔軟性です。ユーザー資金やデータの完全な移行を強制せずにプロトコルを改善できます。

投資家とトレーダーにとっての主な懸念はガバナンスリスクです。ユーザーがすでに資産を預け入れた後でも、アップグレード権限によりプロトコルの挙動が変わる可能性があるためです。

アップグレード可能なコントラクトの仕組み

アップグレード可能なコントラクトは通常、少なくともプロキシコントラクトと実装コントラクトという2つの中核部分で構成されます。

プロキシコントラクトは、ユーザー、ウォレット、ブロックチェーンエクスプローラー、他のスマートコントラクトが通常やり取りするアドレスです。

実装コントラクトには、送金ルール、ステーキング計算、借入機能、報酬分配、アクセス制御チェックなど、実際のロジックが含まれます。

ユーザーがプロキシへトランザクションを送信すると、プロキシは

と呼ばれる低レベルの仕組みを使い、実装コントラクトのコードを実行します。

では、実装ロジックはプロキシの一部であるかのように実行されますが、ストレージ、アドレス、残高はプロキシに紐づいたままです。

そのため、プロキシはアップグレード中に実装アドレスを変更しつつ、ユーザーデータを保持できます。

アップグレード自体は通常、認可された管理者、マルチシグウォレット、ガバナンスコントラクト、またはタイムロックが、プロキシの実装先ポインターを新しい実装コントラクトへ変更することで行われます。

新しい実装は、プロキシの既存ストレージレイアウトと互換性を持つよう慎重に設計する必要があります。

ストレージレイアウトが破綻すると、アップグレード後のコントラクトは残高、所有権記録、権限、その他の重要データを誤って読み取る可能性があります。

これは、アップグレード可能なコントラクトが、単純なアップグレード不可能なコントラクトより厳格なエンジニアリング、テスト、監査を必要とする主な理由の一つです。

アップグレード可能なコントラクトが暗号資産で重要な理由

アップグレード可能なコントラクトが重要なのは、暗号資産アプリケーションが実際の資産を保護することが多く、従来のソフトウェア更新方法に依存できないためです。

通常のWebアプリケーションでは、開発者はユーザーに資産の移動を求めずに、バックエンドコードのパッチ適用、サービスの再デプロイ、データベースの変更を行えます。

パブリックブロックチェーンでは、デプロイ済みコントラクトコードは通常恒久的であるため、コントラクトがアップグレード可能でなければ、重大なバグへの対応には困難な移行が必要になる場合があります。

アップグレード可能な設計は、プロトコルロジックの制御された更新を可能にすることで、この問題を軽減できます。

これは、脆弱性の修正、新しいトークン標準のサポート、リスク管理機能の追加、ガス効率の改善、ブロックチェーンエコシステムの変化への対応が必要なプロジェクトで有用です。

ただし、アップグレード可能性は暗号資産アプリケーションの信頼モデルも変えます。

1つのアドレスがコントラクトを即座にアップグレードできる場合、ユーザーはそのアドレスが悪意ある、または不注意なロジックを導入しないことを信頼しなければなりません。

アップグレードが分散型ガバナンスにより管理される場合、ユーザーはガバナンスプロセス、投票ルール、タイムロック、投票参加を信頼する必要があります。

適切に設計されたアップグレード可能なコントラクトでは、柔軟性と、誰がアップグレードできるか、いつ実行できるか、ユーザーが変更をどのように監視できるかに関する強力な制限のバランスを取るべきです。

プロキシパターン

プロキシパターンは、アップグレード可能なコントラクトで最も広く使用されるアーキテクチャです。

このパターンでは、プロキシコントラクトが状態を保存し、関数呼び出しを実装コントラクトへ転送します。

実装コントラクトにはビジネスロジックが含まれますが、通常のユーザーが直接利用するべきではありません。

プロトコルをアップグレードすると、新しい実装コントラクトがデプロイされ、プロキシはその新しい実装を指すよう更新されます。

ユーザー向けアドレスは同じままであるため、ウォレット、統合サービス、他のコントラクトは引き続きプロキシアドレスを呼び出せます。

この設計は、Ethereumのスマートコントラクトアップグレードに関するドキュメントで詳しく説明されています。

プロキシパターンは、コストが高く、リスクがあり、ユーザーにとって分かりにくい手動の状態移行を回避できるため強力です。

一方で、開発者がプロキシストレージ、関数セレクター、initializer関数、管理者権限の仕組みを理解していなければ危険です。

プロキシは、アップグレード可能であるというだけで自動的に安全になるわけではありません。

設計の安全性は、実装品質、アップグレード権限、テスト、ガバナンス、監視に左右されます。

実装コントラクト

実装コントラクトは、アプリケーションの動作を定義するコードを含むため、ロジックコントラクトと呼ばれることもあります。

例えば、トークンコントラクトでは、実装が送金ルール、承認、ミント上限、バーンロジック、ロールベースの権限を定義する場合があります。

ステーキングコントラクトでは、実装が入金ルール、出金ルール、報酬計算式、ペナルティロジック、緊急制御を定義する場合があります。

レンディングコントラクトでは、実装が担保ルール、利息計算、強制決済ロジック、リスクパラメーターを定義する場合があります。

プロキシが実装へ呼び出しを委譲するとき、実装コードはプロキシのストレージを使用します。

つまり、実装は変数がプロキシコントラクト内に保存されるものとして記述する必要があります。

開発者は通常、ユーザーが実装コントラクトを直接初期化したり、不正に利用したりできないようにするべきです。

また、新しい実装が前バージョンのストレージレイアウトと互換性を持つことも確認する必要があります。

ストレージを誤って変更する新しい実装は、オンチェーンデータに恒久的な損害を与える可能性があります。

ストレージレイアウト

ストレージレイアウトは、アップグレード可能なコントラクトのセキュリティにおける最も重要な概念の一つです。

Solidityでは、状態変数は変数の順序や継承順序などの特定ルールに従ってストレージスロットに配置されます。

コントラクトをアップグレードする際、新しい実装はプロキシの既存ストレージを旧実装と同じ方法で解釈しなければなりません。

開発者は通常、変数を削除したり、並べ替えたり、型を変更したりせず、既存の変数の後にのみ新しい変数を追加します。

コントラクトが元々あるスロットにユーザー残高を保存していた場合、新バージョンはその同じスロットを管理者アドレスや報酬変数として誤って扱ってはなりません。

ストレージ衝突は、残高の破損、権限の喪失、不正確な会計処理、悪用可能なコントラクト動作につながる可能性があります。

Solidityのストレージレイアウトに関するドキュメントでは、Solidityが永続ストレージ内で状態変数をどのように編成するかを説明しています。

最新のアップグレード可能なコントラクトライブラリには、デプロイ前に安全でないストレージ変更を検出する助けとなるツールやチェックも含まれています。

ツールを使用していても、ストレージレイアウトはすべてのアップグレード時に慎重にレビューする必要があります。

ERC-1967プロキシストレージスロット

ERC-1967は、実装アドレス、管理者アドレス、Beaconアドレスなど、プロキシ情報用の特定ストレージスロットを定義する一般的なEthereum標準です。

ERC-1967の目的は、プロキシと実装コントラクト間のストレージ衝突を減らすことです。

また、ブロックチェーンエクスプローラーと開発ツールが、プロキシの背後にある実装を識別する助けにもなります。

標準的なストレージスロットがなければ、ウォレット、エクスプローラー、監査者、監視ツールが、プロキシがどのロジックコントラクトを使用しているかを理解するのはより困難になります。

ERC-1967が特に重要なのは、プロキシ自体がアップグレード関連データを保存する必要がある一方で、実装もプロキシのストレージを使用することを想定しているためです。

公式のERC-1967仕様は、これらのプロキシストレージスロットの慣例を定義しています。

暗号資産ユーザーにとってERC-1967は、多くのツールが現在の実装アドレスを表示できるため、アップグレード可能なコントラクトを調査しやすくします。

開発者にとってERC-1967は、プロキシメタデータをより安全かつ標準的に保存する方法を提供します。

ERC-7201名前空間ストレージ

ERC-7201は、スマートコントラクトにおける名前空間ストレージレイアウトのための新しい標準です。

名前空間ストレージは、関連する状態変数を特定の名前空間の下にグループ化し、特に複雑なアップグレード可能システムでストレージレイアウトの競合を減らします。

これは、コントラクトが継承、モジュール、プラグイン、または複数のアップグレード可能コンポーネントを使用する場合に有用です。

OpenZeppelin Contracts 5.xは、アップグレード可能なバリアントにERC-7201形式のストレージ名前空間を含むアップグレード可能コントラクトパターンを使用しています。

公式のERC-7201仕様は、Solidityソースコード内で名前空間ストレージの場所を文書化するための慣例を説明しています。

開発者にとって名前空間ストレージは、各コントラクトコンポーネントが独自のストレージ領域を維持できるため、アップグレードの検討を容易にします。

ユーザーにとって名前空間ストレージはほとんど見えませんが、正しく実装されれば安全性を向上させる可能性があります。

ただし、監査、テスト、慎重なアップグレードレビューの必要性をなくすものではありません。

コンストラクターの代わりにinitializerを使用する理由

アップグレード可能なコントラクトでは通常、コンストラクターの代わりにinitializer関数を使用します。

通常のコンストラクターはコントラクトのデプロイ時に一度だけ実行されますが、プロキシ設計では、プロキシは実装のコードを使う一方、プロキシの状態に対して実装のコンストラクターは実行されません。

このため、アップグレード可能なコントラクトでは、セットアップロジックを

などの関数へ移すのが一般的です。

initializerは、トークン名、トークンシンボル、所有者アドレス、管理者ロール、手数料パラメーター、初期設定などを設定します。

initializerは、各プロキシについて一度しか実行できないよう保護しなければなりません。

initializerを複数回呼び出せる場合、攻撃者が所有権をリセットし、権限を変更し、コントラクトの支配権を取得する可能性があります。

OpenZeppelinのアップグレード可能なコントラクト作成ガイドでは、プロキシベースのアップグレード可能コントラクトでコンストラクターがinitializer関数に置き換えられる理由を説明しています。

適切なアップグレード可能コントラクトでは、新バージョンが追加のセットアップを必要とする場合、reinitializer関数も慎重に使用します。

すべてのinitializerとreinitializerは、アップグレードプロセスの一部としてレビューする必要があります。

Transparent Proxy

Transparent Proxyは、管理者の呼び出しとユーザーの呼び出しを分離するプロキシ設計です。

このモデルでは、管理者はアップグレード関連の操作を実行でき、通常のユーザーの呼び出しは実装コントラクトへ転送されます。

Transparent Proxyパターンは、管理者がプロキシを介して実装関数を誤って呼び出す問題を回避する助けとなります。

また、プロキシ管理者関数と実装関数間の関数セレクター競合のリスクも抑えます。

このパターンは、アップグレードに明確な管理構造を提供するため、本番システムで一般的です。

トレードオフとして、プロキシ管理者コントラクトなど、追加のデプロイおよび管理コンポーネントが必要になる場合があります。

ユーザーにとって重要なのは、誰がプロキシ管理者を管理しているか、アップグレードに遅延があるか、ガバナンスにより管理されているか、外部監視されているかを確認することです。

UUPS Proxy

UUPSはUniversal Upgradeable Proxy Standardの略です。

UUPS設計では、アップグレードロジックは通常、プロキシ自体が完全に管理するのではなく、実装コントラクトに配置されます。

これによりプロキシは小さくなりデプロイコストも低くなる可能性がありますが、実装側がアップグレード関数を正しく含め、保護する必要があります。

アップグレードの認可ロジックが誤っている場合、コントラクトは不正なアップグレードに対して脆弱になる可能性があります。

将来の実装でアップグレード関数が削除または破損した場合、プロキシは再度のアップグレードが困難または不可能になる可能性があります。

UUPSプロキシは人気がありますが、慎重なアクセス制御とテストが必要です。

ユーザーは、UUPSコントラクトに明確なアップグレード権限、タイムロック、公開されたアップグレード履歴があるかを確認するべきです。

Beacon Proxy

Beacon Proxyは、複数のプロキシコントラクトが共有Beaconコントラクトから実装アドレスを読み取る設計です。

これにより、Beaconに保存されている実装アドレスを変更することで、多数のプロキシインスタンスを一度にアップグレードできます。

Beacon Proxyは、プロトコルがボールト、プール、アカウント、トークン化ポジションなど、多数の類似コントラクトをデプロイする場合に有用です。

主な利点は運用効率です。1回のBeaconアップグレードで多数のプロキシを更新できます。

主なリスクは集中です。不適切なBeaconアップグレードが、多数のコントラクトに同時に影響する可能性があります。

Beaconの所有権とアップグレード権限は、強力なガバナンスと監視で保護する必要があります。

Diamond Pattern

Diamond Patternは、1つのプロキシが異なる関数呼び出しを、しばしばfacetと呼ばれる異なる実装コントラクトへルーティングできるアップグレードアーキテクチャです。

これにより、大規模なスマートコントラクトシステムをより小さなモジュールに分割できます。

Diamond設計では、すべての関数を一度に置き換えることなく、システムの一部をアップグレードできます。

これは、多数の機能を1つのアドレスで提供する必要がある複雑な暗号資産プロトコルで有用な場合があります。

トレードオフは複雑性です。開発者は関数セレクター、facetストレージ、アクセス制御、アップグレードルールを非常に慎重に管理する必要があります。

Diamond形式のシステムは強力になり得ますが、より単純なプロキシ構造よりも一般ユーザーが調査しにくい場合があります。

アップグレード可能なコントラクトの利点

アップグレード可能なコントラクトの1つ目の利点は、バグ修正です。

重大な問題が発見された場合、開発者はユーザーに手動で資金を移行させることなく、ロジックにパッチを適用できる可能性があります。

2つ目の利点は、機能拡張です。

プロトコルは、同じコントラクトアドレスを維持しながら、新しい担保タイプ、報酬ルール、モジュール、セキュリティ制御を追加する場合があります。

3つ目の利点は、統合の安定性です。

ウォレット、分析プラットフォーム、アグリゲーター、他のスマートコントラクトは、アップグレード後も同じプロキシアドレスを参照し続けられます。

4つ目の利点は、ユーザー体験です。

ユーザーはプロトコル更新のたびに、承認、出金、再入金、ポジションの手動移動を行う必要がない場合があります。

5つ目の利点は、緊急対応です。

適切にガバナンスされたアップグレードプロセスは、完全な移行プロセスより迅速に、プロトコルが進行中のリスクへ対応する助けとなる可能性があります。

アップグレード可能なコントラクトのリスク

アップグレード可能なコントラクトの最大のリスクは、管理者権限の悪用です。

アップグレード権限が脆弱な秘密鍵、不注意なチーム、侵害されたガバナンスプロセスによって管理されている場合、コントラクトは有害な形で変更される可能性があります。

悪意あるアップグレードは、資金の流出、出金の停止、手数料の変更、残高の改変、ユーザー保護の削除を引き起こす可能性があります。

もう一つの主要リスクは、ストレージの破損です。

不適切に設計された実装アップグレードは、古いデータと新しいロジックの関係を破壊する可能性があります。

3つ目のリスクは、隠れた複雑性です。

ユーザーは1つのコントラクトとやり取りしていると考えるかもしれませんが、実際の挙動は現在の実装アドレスとアップグレード権限に依存します。

4つ目のリスクは、監視不足です。

ユーザーや統合サービスがアップグレードを追跡しなければ、プロトコルの挙動における重要な変更を見逃す可能性があります。

5つ目のリスクは、ガバナンスの乗っ取りです。

投票力が集中している場合、少数のグループが他のユーザーを犠牲にして自らに有利なアップグレードを承認する可能性があります。

ユーザーがアップグレード可能なコントラクトを評価する方法

ユーザーはまず、そのコントラクトがプロキシかどうか、および現在どの実装を使用しているかを確認するべきです。

多くのブロックチェーンエクスプローラーは、コントラクトがERC-1967などの一般的なプロキシ標準に従う場合、プロキシ情報を表示します。

ユーザーは、誰がコントラクトをアップグレードする権限を持つかも確認するべきです。

単一の外部所有アカウントにより管理されるアップグレードは、通常、マルチシグ、タイムロック、透明性のあるガバナンスプロセスにより管理されるアップグレードよりリスクが高いです。

ユーザーは、プロジェクトがアップグレード前に告知するかどうかを確認するべきです。

また、コントラクトが監査を受けているか、監査レポートがアップグレードロジックを対象としているか、過去のアップグレードが安全に実行されたかも確認するべきです。

大きな金額を預け入れる場合、ユーザーはタイムロック期間、緊急停止権限、管理者ロールの変更、アップグレードイベント履歴に注意を払うべきです。

技術的によく書かれたコントラクトでも、アップグレード権限が過度に中央集権化されている、または監視が不十分であれば、リスクを伴う可能性があります。

開発者向けベストプラクティス

開発者は、強いセキュリティ経験がない限り、プロキシロジックを一から書くのではなく、十分にレビューされたアップグレードフレームワークを使用するべきです。

マルチシグ所有権、ロールベースの権限、タイムロック、オンチェーンガバナンスなどの強力なアクセス制御で、アップグレード関数を保護するべきです。

初回デプロイとすべてのアップグレード経路の両方について、自動テストを記述するべきです。

安全でない変更を検出するため、アップグレード前後のストレージレイアウトを比較するべきです。

initializer保護を使用し、保護されていないセットアップ関数を避けるべきです。

必要かつ完全にレビューされている場合を除き、危険な低レベルパターンを避けるべきです。

実装のソースコードを公開し、プロキシ関係を容易に調査できるようにするべきです。

アップグレード時に明確なイベントを発行し、監視システムが変更を検出できるようにするべきです。

何を変更したか、なぜ変更したか、どのリスクを考慮したかを文書化するべきです。

単一の主体に無制限の権限を与えずに、緊急対応を計画するべきです。

アップグレード可能なコントラクトと不変コントラクトの比較

不変コントラクトは、デプロイ後にデプロイ済みコードを変更できません。

これにより、コントラクトに設定可能なパラメーターがすでに含まれていない限り、ルールが固定されるため、ユーザーは高い予測可能性を得られます。

アップグレード可能なコントラクトは、定義されたアップグレードメカニズムを通じてロジックを変更できます。

これは開発者に柔軟性を与える一方、ユーザーはアップグレードプロセスを信頼する必要があります。

不変コントラクトは、単純な資産、最小限のプロトコル、将来の柔軟性より固定ルールが重要なシステムで好まれることがよくあります。

アップグレード可能なコントラクトは、パッチ、リスク制御、統合、長期メンテナンスが必要になる可能性のある複雑なプロトコルで好まれることがよくあります。

どちらの設計も常に優れているわけではありません。

適切な選択は、保護する価値、アプリケーションの複雑性、予想されるアップグレードの必要性、ガバナンスの強さに依存します。

アップグレード可能性がトークンとプロトコルのリスクに与える影響

アップグレード可能なコントラクトは、コントラクトロジックがミント、バーン、送金制限、手数料、ガバナンス権を定義する場合があるため、トークン保有者に直接影響する可能性があります。

アップグレードでトークンルールが変われば、市場の信頼とトークンのユーティリティに影響する可能性があります。

アップグレード可能なステーキングコントラクトは、報酬率、ロック期間、ペナルティ、出金時の挙動に影響する可能性があります。

アップグレード可能なレンディングコントラクトは、担保比率、強制決済しきい値、金利、市場リスク制御に影響する可能性があります。

アップグレード可能なブリッジは、資産カストディ、メッセージ検証、出金ロジックに影響する可能性があります。

このため、トレーダーと長期投資家は、アップグレード権限をプロトコルのファンダメンタル分析の一部として扱うべきです。

トークンは市場レベルでは分散化されているように見えても、少数のグループがアップグレードできるコントラクトに依存している場合があります。

アップグレード可能性を理解することは、プロトコルのルールが真に固定されているのか、依然として変更され得るのかを判断する助けとなります。

よくある誤解

よくある誤解の一つは、アップグレード可能なコントラクトでは元のコントラクトコード自体がオンチェーンで編集されるというものです。

大半のプロキシ設計では、元のプロキシコードは編集されず、プロキシが異なる実装コントラクトを指すようになります。

もう一つの誤解は、アップグレード可能性は常に悪いというものです。

アップグレード可能性は、透明性があり、制限され、監査され、責任を持ってガバナンスされる場合に有用となり得ます。

3つ目の誤解は、監査がアップグレードリスクをなくすというものです。

監査は現在のコードとアップグレードプロセスをレビューできますが、将来の実装が新たなリスクを導入する可能性はあります。

4つ目の誤解は、ユーザーはトークンコントラクトアドレスだけを確認すればよいというものです。

アップグレード可能なシステムでは、ユーザーは実装コントラクト、管理者ロール、アップグレードイベントも確認するべきです。

5つ目の誤解は、分散化により不適切なアップグレードが自動的に防止されるというものです。

投票力が集中している、参加率が低い、提案のレビューが困難である場合、ガバナンスはなお失敗する可能性があります。

FAQ

暗号資産におけるアップグレード可能なコントラクトとは何ですか？

アップグレード可能なコントラクトとは、同じアドレスと保存データを維持したまま、プロトコルがデプロイ後にロジックを変更できるスマートコントラクト設計です。

暗号資産プロジェクトはなぜアップグレード可能なコントラクトを使用するのですか？

暗号資産プロジェクトは、バグ修正、機能追加、セキュリティ制御の改善、移行コストの削減、時間の経過に伴う統合の維持のためにアップグレード可能なコントラクトを使用します。

アップグレード可能なコントラクトは安全ですか？

アップグレード可能なコントラクトは、強力なアクセス制御、慎重なストレージ管理、監査、監視、透明性のあるガバナンスを使用する場合、安全となり得ます。

アップグレード可能なコントラクトの主なリスクは何ですか？

主なリスクは、認可されたアップグレーダーが、プロトコルの挙動を変えたりユーザー資金を危険にさらしたりする有害または欠陥のあるロジックを導入する可能性があることです。

プロキシコントラクトとは何ですか？

プロキシコントラクトは、データを保存し、現在のロジックを含む実装コントラクトへ呼び出しを転送するユーザー向けコントラクトです。

実装コントラクトとは何ですか？

実装コントラクトは、プロキシが呼び出しを委譲したときに関数がどのように動作するかを定義するロジックコントラクトです。

アップグレード可能なコントラクトはなぜinitializerを使用するのですか？

アップグレード可能なコントラクトがinitializerを使うのは、コンストラクターロジックでは通常のコントラクトデプロイと同じようにプロキシのストレージを初期化できないためです。

ストレージ衝突とは何ですか？

ストレージ衝突とは、新しいコントラクトロジックが、古いレイアウトと競合する方法でストレージスロットを読み書きする場合に発生します。

ERC-1967とは何ですか？

ERC-1967は、実装アドレス、管理者アドレス、Beaconアドレスなどのプロキシ情報用ストレージスロットを定義する標準です。

ERC-7201とは何ですか？

ERC-7201は名前空間ストレージレイアウトの標準で、複雑なアップグレード可能コントラクトにおける状態変数の整理とストレージ競合の低減に役立ちます。

アップグレード可能なコントラクトは後から不変にできますか？

はい。一部のプロジェクトはアップグレード権限を放棄または無効化できますが、ユーザーは発表だけに依存せず、オンチェーンで確認するべきです。

コントラクトがアップグレード可能かどうかを確認するにはどうすればよいですか？

ユーザーはブロックチェーンエクスプローラーでコントラクトを調査し、プロキシ情報を探し、実装アドレスを確認し、管理者またはガバナンス権限を確認できます。

結論

アップグレード可能なコントラクトは、アドレス、状態、残高を維持しながら、暗号資産プロトコルがロジックを改善できる強力なスマートコントラクト設計です。

最も一般的な設計では、データを保存するプロキシコントラクトが、置き換え可能な実装コントラクトへ実行を委譲します。

このモデルにより、バグ修正、機能アップグレード、長期的なプロトコル保守を容易にできます。

一方、アップグレード権限が中央集権化されている、ストレージレイアウトが不適切に扱われる、ガバナンスが脆弱である場合、重大なリスクも生じ得ます。

ERC-1967プロキシストレージスロット、ERC-7201名前空間ストレージ、initializer関数、監査、タイムロック、透明性のある管理者制御などの重要な標準と実務は、これらのリスクを軽減できます。

暗号資産ユーザーにとって、アップグレード可能性は、プロトコルのルールが固定されているか、依然として変更可能かを決めるため、常にリスク分析の一部とすべきです。

開発者にとって、アップグレード可能なコントラクトは、初回デプロイ時から慎重な設計、テスト、監視、ガバナンスを必要とする、セキュリティ上重要なインフラとして扱うべきです。