スマートコントラクトのアップグレーダビリティ

スマートコントラクトのアップグレーダビリティとは？

スマートコントラクトのアップグレーダビリティとは、デプロイ済みのスマートコントラクトシステムのロジックを、初回デプロイ後に変更、置換、拡張、またはリダイレクトする能力です。

暗号資産では、多くのスマートコントラクトが実際の資産を管理しており、チームはローンチ後にバグ修正、機能改善、統合の更新、セキュリティ問題への対応を行う必要があるため、アップグレーダビリティが利用されます。

スマートコントラクトのアップグレードに関する公式のEthereumドキュメントでは、スマートコントラクトは不変と扱われることが多い一方、将来の変更が必要な場合、開発者はアップグレードパターンを利用できると説明されています。

基本的なデプロイ済みスマートコントラクトは、アップグレード機構を備えて設計されていない限り、通常は同じコードを永続的に保持します。

アップグレード可能なスマートコントラクトシステムでは、ユーザー向けアドレス、保存された状態、ビジネスロジックを分離することで、ユーザーに手動移行を強いることなく新しいロジックを導入します。

最も一般的なアップグレーダビリティモデルでは、ユーザーが操作するプロキシコントラクトと、現在のロジックを含む実装コントラクトを使用します。

実装が変更されても、プロキシアドレスは同じまま、その背後のコードを変更できます。

残高、権限、統合が同じアドレスを参照し続けられるため、これはユーザーにとって有用です。

一方で、アップグレード権限を持つ人またはガバナンスシステムは、ユーザーが資金を預け入れた後にコントラクトの挙動を変更できる可能性があるため、リスクもあります。

簡単に言えば、スマートコントラクトのアップグレーダビリティとは、重要な状態、アドレスの継続性、ユーザーアクセスを維持しながら、後でロジックを更新できるようオンチェーンソフトウェアを設計することです。

スマートコントラクトのアップグレーダビリティが重要な理由

デプロイ済みブロックチェーンコードは、トークン、トレジャリー、融資市場、ステーキングシステム、ブリッジ、NFT、ガバナンス権を管理できるため、スマートコントラクトのアップグレーダビリティは重要です。

不変コードのバグは、資産のロック、ユーザー機能の停止、攻撃者への資金露出につながる可能性があります。

アップグレーダビリティは、開発者にデプロイ後の重大な問題の修正やプロトコル改善の手段を与えます。

OpenZeppelinのスマートコントラクトアップグレードガイドでは、アップグレード可能なデプロイメントにより、アドレス、状態、残高を維持しながらコントラクトコードを変更できると説明されています。

ユーザー、ウォレット、分析ツール、他のプロトコルがすでに元のコントラクトアドレスに依存している可能性があるため、この維持は重要です。

アップグレーダビリティがなければ、チームは新しいコントラクトをデプロイし、ユーザーに資金または承認を手動移行するよう求める必要がある場合があります。

移行は遅く、リスクがあり、コストが高く、混乱を招く可能性があります。

ただし、アップグレーダビリティはスマートコントラクトの信頼モデルも変えます。

アップグレード可能なコントラクトは、アップグレード機構を持たないコントラクトと同じ意味で完全に不変ではありません。

ユーザーは常に、誰がコントラクトをアップグレードできるか、アップグレードがどのように承認されるか、どれほど迅速に実行できるか、大きな変更が有効になる前に退出できるかを確認する必要があります。

スマートコントラクトのアップグレーダビリティの仕組み

スマートコントラクトのアップグレーダビリティは通常、ストレージをロジックから分離することで機能します。

プロキシコントラクトは、ユーザーが呼び出すアドレスを保持し、通常はシステムの主な状態を保存します。

実装コントラクトには、関数の動作を定義するロジックが含まれます。

ユーザーがプロキシを呼び出すと、プロキシは呼び出しを現在の実装コントラクトに転送します。

Ethereum形式のシステムでは、この転送にdelegatecallがよく使われます。これは、プロキシのストレージコンテキストで実装ロジックを実行します。

つまり、実装コードは、プロキシのストレージが実装自身のストレージであるかのように読み書きできます。

プロトコルがアップグレードされると、承認済みアカウントまたはガバナンスプロセスが、プロキシに保存されている実装アドレスを変更します。

変更後の呼び出しは、新しい実装ロジックに送られます。

ストレージレイアウトに互換性があれば、古いストレージはそのまま残り、ユーザー残高とプロトコル状態を維持できます。

この設計は強力ですが、ストレージレイアウト、初期化、認可、監査、アップグレードガバナンスに関する厳格なルールが必要です。

プロキシコントラクト

プロキシコントラクトは、多くのアップグレード可能なシステムでユーザーや他のコントラクトが操作する、安定したコントラクトアドレスです。

プロキシは通常、状態を保存し、関数呼び出しを実装コントラクトに転送します。

OpenZeppelinのプロキシアップグレードパターンドキュメントでは、非構造化ストレージプロキシパターンを、アップグレード可能なコントラクトの基本的な構成要素として説明しています。

プロキシは、ロジックがアップグレードされるたびにユーザーがコントラクトアドレスを変更する必要がないため有用です。

アプリケーション、ウォレット、ダッシュボード、DeFi統合は同じプロキシアドレスを使用し続けられます。

一方で、ユーザーには1つのコントラクトアドレスが見えても、実際のロジックは別のアドレスに存在する可能性があるため、プロキシパターンは複雑さも生みます。

ブロックチェーンエクスプローラーは、パターンを検出できる場合、プロキシ情報と実装アドレスを表示することがよくあります。

アップグレード可能なコントラクトを確認する際、ユーザーはプロキシと実装の両方を調査してください。

プロキシが自動的に安全になるわけではありません。安全性はアップグレード管理、ストレージ互換性、実装コードの品質に依存します。

プロキシは入口であり、実装はその入口の背後にあるロジックです。

実装コントラクト

実装コントラクトは、プロキシが使用するビジネスロジックを含むコントラクトです。

送転送、入金、出金、融資、投票、ミント、バーン、一時停止、清算、その他のプロトコルアクションの関数を定義する場合があります。

プロキシベースのシステムでは、ユーザーは通常、実装アドレスを直接操作しません。

代わりにプロキシを操作し、プロキシが実装に実行を委譲します。

アップグレードとは通常、プロキシが新しい実装コントラクトを指すよう変更することです。

新しい実装は、古いストレージレイアウトとユーザーの期待に互換性を持つべきです。

危険な実装アップグレードは、悪意あるロジックの追加、会計処理の破綻、権限変更、出金停止を引き起こす可能性があります。

このため、アップグレード実行前に実装コードを検証、監査、テスト、レビューする必要があります。

プロキシアドレスが変わっていないからといって、プロトコルが永久に同じであると考えるべきではありません。

アップグレード可能なシステムでは、実装アドレスがセキュリティ上の重要な要素です。

Delegatecall

Delegatecallは、あるコントラクトが呼び出し元のストレージコンテキストを使いながら、別のコントラクトのコードを実行できる低レベルのEVM機構です。

プロキシのアップグレーダビリティでは、delegatecallにより、プロキシは状態をプロキシアドレスに保持したまま実装ロジックを使用できます。

このため、新しい実装では、プロキシからユーザー残高を移動せずに挙動を変更できます。

Delegatecallは、コードと状態を分離するため強力です。

実装は自身のストレージではなくプロキシストレージに書き込む前提で作らなければならないため、リスクもあります。

実装が想定と異なるストレージレイアウトを使用すると、変数が衝突したり状態が破損したりする可能性があります。

誤ったdelegatecall設計では、所有者変数、残高、マッピング、設定値が上書きされる可能性があります。

開発者は、ストレージとEVM実行を完全に理解していない限り、カスタムのプロキシdelegatecallロジックを作成すべきではありません。

ユーザーはすべてのオペコードを理解する必要はありませんが、アップグレード可能なプロキシが技術的な間接参照に依存することは知っておくべきです。

Delegatecallは、アップグレード可能なコントラクトに専門的な監査が必要な理由の一つです。

ストレージレイアウト

ストレージレイアウトとは、スマートコントラクトストレージにおける変数の順序と位置です。

公式のSolidityストレージレイアウトドキュメントでは、状態変数がストレージにどのように配置されるか、またレイアウトルールがコントラクトとライブラリにとって重要である理由が説明されています。

ストレージレイアウトは、アップグレーダビリティにおける最も重要なリスクの一つです。

新しい実装が既存変数の順序、型、構造を誤って変更した場合、プロキシは古いストレージデータを新しい誤った方法で解釈する可能性があります。

例えば、残高マッピングがずれたり、所有者アドレスが上書きされたり、設定変数が別の型として読み取られたりする場合があります。

これはストレージ衝突またはストレージ破損リスクと呼ばれます。

開発者は通常、既存変数の途中に変数を挿入するのではなく、既存変数の後に新しい変数を追加します。

また、慎重な移行計画なしに変数型や継承順序を変更することを避けます。

現代のアップグレードツールは、アップグレードを許可する前にストレージレイアウトを比較できます。

ユーザーは、ストレージレイアウトの安全性をアップグレード可能なコントラクトのセキュリティにおける中核として扱うべきです。

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

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

公式のERC-1967標準は、ツールとエクスプローラーがプロキシ設定をより信頼性高く識別できるよう、標準プロキシストレージスロットを定義しています。

これらの標準化スロットは、プロキシ管理変数がアプリケーションストレージ変数と衝突する可能性を低減します。

ERC-1967は、ブロックチェーンエクスプローラーがプロキシで現在使われている実装をユーザーに表示するのにも役立ちます。

多くの現代的なプロキシシステムは、ERC-1967互換スロットに依存しています。

この標準だけでアップグレードが安全になるわけではありません。

主に、プロキシメタデータを保存する予測可能な場所を提供するものです。

開発者には引き続き、正しい認可、ストレージレイアウト検証、実装レビュー、安全なアップグレード実行が必要です。

アップグレード可能なコントラクトを確認するユーザーは、未知のカスタムパターンではなく、プロキシが既知の標準に従うかを確認してください。

標準化されたプロキシストレージは透明性を向上させますが、スマートコントラクトのアップグレーダビリティにおける安全性の一部にすぎません。

Transparent Proxyパターン

Transparent Proxyパターンは、プロキシ関数と実装関数間の関数セレクターの混同を減らすため、管理者呼び出しとユーザー呼び出しを分離します。

OpenZeppelinのプロキシドキュメントでは、TransparentUpgradeableProxyには組み込みの管理者およびアップグレードインターフェースがあると説明されています。

このパターンでは、通常のユーザーはプロキシを通じて実装関数を操作します。

プロキシ管理者はアップグレードアクションを実行し、ユーザーと同じ方法で誤ってプロキシを通じた実装関数を呼び出すべきではありません。

この設計は、プロキシ関数と実装関数が同じセレクターを共有する衝突を避けるのに役立ちます。

Transparent Proxyは明確な管理者モデルを提供するため広く使用されています。

ただし、安全な管理者鍵の管理が依然として必要です。

プロキシ管理者が露出した単一鍵で管理されている場合、プロトコル全体がリスクにさらされる可能性があります。

Transparent Proxyは、マルチシグ制御、タイムロック、監査、明確なガバナンスと組み合わせることで安全に利用できる場合があります。

このパターンは1つの技術的リスクを低減しますが、ガバナンスリスクをなくすものではありません。

UUPS Proxyパターン

UUPSはUniversal Upgradeable Proxy Standardの略です。

公式のEIP-1822標準では、アップグレードロジックが実装設計に紐づくユニバーサルなアップグレード可能プロキシパターンが説明されています。

OpenZeppelinドキュメントでは、UUPSUpgradeableはTransparent Proxyと同じ組み込みプロキシ管理者構造を用いるのではなく、実装コントラクトにアップグレード機構を含めると説明されています。

プロキシ自体をより単純にできるため、UUPSプロキシはTransparent Proxyより軽量になる場合があります。

ただし、実装にはアップグレード関数を正しく含め、保護する必要があります。

不適切なUUPS実装では、アップグレード機能を誤って削除したり、アップグレード権限を露出したり、無許可のアップグレードを許したりする可能性があります。

開発者は、アップグレード経路を壊す実装へのアップグレードも防止する必要があります。

UUPSは、成熟したライブラリと検証ツールとともに使用する場合、効率的かつ柔軟になり得ます。

認可とアップグレードの安全確認を理解せずに、盲目的にコピーすべきではありません。

ユーザーは、誰がUUPSアップグレードを管理しているか、過去のアップグレードが透明で監査済みだったかを確認してください。

Beacon Proxyパターン

Beacon Proxyパターンでは、複数のプロキシの実装アドレスを保存するビーコンコントラクトを使用します。

各プロキシが独自の実装アドレスを保存する代わりに、各プロキシはビーコンから実装を読み取ります。

これにより、1つのビーコンを更新して多数のプロキシインスタンスをまとめてアップグレードできます。

Beacon Proxyは、ボールト、プール、アカウント、ユーザー固有のコントラクトインスタンスなど、多数の類似コントラクトをデプロイするシステムに有用です。

多くのインスタンスに同じアップグレードが必要な場合、運用上の複雑さを減らせます。

一方で、不適切なビーコンアップグレードが同時に多くのプロキシへ影響するため、影響範囲を広げる可能性があります。

OpenZeppelinのプロキシドキュメントには、プロキシ関連コンポーネントとしてBeaconProxyとUpgradeableBeaconが含まれます。

ビーコン権限は多くのコントラクトのロジックを管理できる可能性があるため、慎重に保護する必要があります。

ユーザーは、利用するコントラクトがビーコンに依存するか、そのビーコンを誰が更新できるかを確認してください。

ビーコンは開発者にとって便利ですが、共有された管理点にアップグレード権限を集中させます。

Diamond Proxyパターン

Diamond Proxyパターンでは、1つのプロキシに似たコントラクトが、ファセットと呼ばれる複数の実装コントラクトに関数呼び出しをルーティングできます。

公式のEIP-2535 Diamond Standardでは、ファセットを通じて関数を追加、置換、削除できるモジュール型スマートコントラクトシステムが定義されています。

Diamondは、コントラクトサイズ制限を超える大規模システムや、モジュール型アップグレードが必要なシステムに有用です。

Diamondは、多数の個別ファセットに複雑なロジックを整理しながら、1つのメインアドレスを維持できます。

この柔軟性は、大規模DeFiシステム、ゲーム、アカウントシステム、プロトコルフレームワークで強力になり得ます。

一方で、ユーザーと監査人はファセットルーティング、セレクターテーブル、ストレージパターン、アップグレード権限を理解する必要があるため、複雑さが増します。

Diamondのアップグレードではシステムの一部だけを置き換えられるため、変更追跡が重要です。

複数のファセットが同じストレージを共有する可能性があるため、ストレージ設計は特に重要です。

開発者は、適切な場合、明確なDiamond Storageまたは名前空間ストレージパターンを使用してください。

ユーザーは、Diamondコントラクトを慎重なレビューが必要な高度なアップグレード可能システムとして扱うべきです。

名前空間ストレージ

名前空間ストレージは、異なるモジュールが定義されたストレージ位置を使用し、衝突リスクを低減するようコントラクトストレージを整理する手法です。

公式のERC-7201 Namespaced Storage Layout標準では、Solidityソースコードで名前空間ストレージのストレージ位置を文書化するための規約が定義されています。

名前空間ストレージは、長い継承チェーンを通じた単純な変数順序への依存を減らすため、アップグレード可能およびモジュール型コントラクトで有用です。

複数のモジュールからコントラクトを構築する場合、アップグレードをより安全にできる可能性があります。

コンパイラーとフレームワークの対応がある場合、ツールがストレージ変更をより明確に検証するのにも役立ちます。

アップグレード可能なコントラクトの記述に関するOpenZeppelinガイダンスでは、必要なコンパイラー情報を用いてアップグレードプラグインが名前空間ストレージレイアウトを検証するには、Solidity 0.8.20以降が必要であると記載されています。

名前空間ストレージによって監査が不要になるわけではありません。

将来の変更を管理しやすくするために状態を構造化する手段です。

このアーキテクチャを選ぶ場合、開発者は名前空間ストレージを一貫して使用すべきです。

より安全なストレージ設計により、アップグレード関連の状態破損の可能性が下がるため、ユーザーは間接的に利益を得ます。

イニシャライザー

イニシャライザーは、アップグレード可能なコントラクトでコンストラクターの代わりに使用される特別なセットアップ関数です。

通常のコントラクトでは、コンストラクターはコントラクトのデプロイ時に実行されます。

プロキシシステムでは、ユーザーはプロキシを操作し、実装のコンストラクターは通常の方法でプロキシストレージを初期化しません。

このため、アップグレード可能な実装では通常、イニシャライザー関数を使用して、所有者、トークン名、権限、設定値、その他の初期状態を設定します。

後のアップグレードに慎重に設計されたreinitializerを使用する場合を除き、イニシャライザーは一度だけ実行されるべきです。

イニシャライザーが保護されていない場合、攻撃者がコントラクトを初期化し、重要なロールを取得する可能性があります。

新しい実装で新たな状態変数が必要な場合、それらを安全に設定するためreinitializerが必要になる場合があります。

開発者はイニシャライザーを保護し、適切な場合には単独の実装コントラクトで初期化を無効化する必要があります。

ユーザーは、アップグレード可能なコントラクトの初期化履歴が不明確な場合に注意してください。

初期化のミスは、アップグレード可能なコントラクトの脆弱性における主要な原因です。

アップグレード権限

アップグレード権限とは、アップグレードを承認できるアカウント、コントラクト、マルチシグウォレット、タイムロック、DAO、またはガバナンスシステムです。

アップグレード権限は、アップグレード可能なコントラクトにおける最も重要な信頼上の前提の一つです。

1つの秘密鍵がアップグレードを管理している場合、その鍵はプロトコルロジックを置き換えられる可能性があります。

マルチシグウォレットがアップグレードを管理している場合、ユーザーは署名者グループとその運用セキュリティを信頼する必要があります。

DAOがアップグレードを管理している場合、ユーザーは投票力、定足数、提案遅延、実行遅延、ガバナンス攻撃リスクを理解する必要があります。

タイムロックがアップグレードを管理している場合、ユーザーは変更が有効になる前に確認し、退出する時間を持てる場合があります。

安全なアップグレードプロセスでは、マルチシグ実行、タイムロック遅延、公開提案の開示、監査レビュー、モニタリングを組み合わせることがよくあります。

アップグレード権限は可視化され、文書化されるべきです。

小規模なグループが即座にロジックを変更できる場合、ユーザーはアップグレード可能なコントラクトをトラストレスとして扱うべきではありません。

アップグレード可能なシステムでは、ガバナンス設計はセキュリティ設計です。

タイムロック

タイムロックは、アップグレードの提案または承認後、実行を遅延させます。

この遅延により、ユーザー、監査人、研究者、モニタリングシステムは予定されている変更を確認する時間を得られます。

タイムロックは、コントラクトの挙動を即座に変更する不意のアップグレードのリスクを低減できます。

ユーザーがアップグレードに同意しない場合、資金を引き出す時間も提供できます。

ただし、アクティブな攻撃中には緊急修正に迅速性が必要な場合があるため、タイムロックは完璧ではありません。

一部のシステムは、短い緊急経路と長い通常のガバナンス経路を使用します。

緊急経路はエクスプロイトからユーザーを保護できますが、中央集権化リスクも生む可能性があります。

優れたプロトコルは、タイムロックルールを明確に説明します。

ユーザーは、アップグレードが遅延されるか、即時か、緊急権限により管理されるかを確認してください。

タイムロックは、アップグレード権限を即時の権限から可視で遅延した権限に変えるため価値があります。

ガバナンス管理のアップグレード

ガバナンス管理のアップグレードでは、トークン投票、委任投票、評議会承認、DAO提案、または類似のシステムを用いて実装変更を承認します。

これにより、単一の管理者鍵よりアップグレードを分散化できる可能性があります。

一方で、アップグレードが遅く、より複雑になる可能性もあります。

ガバナンスの安全性は、投票者の分布、定足数ルール、提案しきい値、投票遅延、実行遅延、委任、票の買収またはフラッシュローンによるガバナンス攻撃への耐性に依存します。

ガバナンス投票が、変更の技術的安全性を自動的に意味するわけではありません。

投票者は、完全に理解していないコードを承認する可能性があります。

悪意ある提案は、大規模なアップグレードパッケージ内に危険なロジックを隠す可能性があります。

プロトコルは投票前に、明確なアップグレード差分、監査、シミュレーション結果、平易な説明を公開すべきです。

ユーザーは、プロトコルに資産を預け入れる前にガバナンスのアップグレードプロセスを確認してください。

ガバナンスは権限を分散できますが、技術的なセキュリティレビューの必要性をなくすものではありません。

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

不変スマートコントラクトは、外部管理または移行経路を備えて設計されていない限り、デプロイ後に変更できません。

アップグレード可能なスマートコントラクトは、定義されたアップグレード機構を通じてロジックを変更できます。

不変コントラクトは、デプロイ済みコードが固定されたままであるため、理解しやすい場合があります。

重大なバグが発見され、安全な修正方法がない場合には危険となる可能性もあります。

アップグレード可能なコントラクトでは、バグを修正し機能を追加できます。

一方で、将来のロジックがユーザーが最初に確認したコードと異なる可能性があるため、信頼リスクも生じます。

どちらのモデルが常に優れているわけではありません。

ルールを決して変更すべきでない単純なトークンコントラクトでは、不変性が選ばれる場合があります。

複雑なDeFiプロトコルでは、セキュリティパッチや変化する市場状況のためにアップグレーダビリティが必要な場合があります。

適切な設計は、リスク、複雑性、ガバナンスの成熟度、ユーザーの期待に依存します。

移行とアップグレーダビリティの違い

移行とは、新しいコントラクトをデプロイし、ユーザー、資産、統合を古いコントラクトから新しいコントラクトへ移すことです。

アップグレーダビリティとは、状態またはユーザー向けの継続性を維持しながら、既存アドレスまたはシステムの背後にあるロジックを変更することです。

移行は、古いコントラクトが変更されず、新しいコントラクトが分離されるため、理解しやすい場合があります。

ユーザーが送転送を承認し、ポジションを移動し、新しいトークンを請求し、統合を更新する必要がある可能性があるため、移行は負担になる場合があります。

同じアドレスをアクティブなまま維持できるため、アップグレーダビリティはより円滑なユーザー体験を生む場合があります。

一方で、アップグレーダビリティは同じアドレスの背後に大きな変更を隠す可能性もあります。

一部のプロトコルは、変更の重大性に応じて両方の手法を使用します。

小さなバグ修正にはアップグレードを使用し、大規模な再設計には移行を使用する場合があります。

ユーザーは、プロトコルがその場で変更できるのか、手動移行が必要なのかを理解してください。

移行リスクとアップグレードリスクは異なりますが、どちらも慎重なコミュニケーションが必要です。

ソースコード検証

ソースコード検証は、ユーザーが公開されたソースコードとデプロイ済みバイトコードを比較するのに役立ちます。

公式のEthereumスマートコントラクト検証ドキュメントでは、検証はスマートコントラクトのソースコードとコンパイル済みバイトコードを比較すると説明されています。

アップグレード可能なコントラクトでは、可能な場合、プロキシと現在の実装の両方を検証してください。

検証済みプロキシだけでは、ビジネスロジック全体を示さない場合があります。

検証済み実装は現在のロジックを読むのに役立ちますが、アップグレード権限も確認する必要があります。

プロトコルがアップグレードする際は、新しい実装も検証すべきです。

以前の実装が監査済みだったからといって、コントラクトが安全なままであると考えるべきではありません。

アップグレードでは、新機能の追加、権限変更、会計処理の変更、新たなバグの導入が行われる可能性があります。

検証は透明性を高める手順であり、完全なセキュリティ保証ではありません。

アップグレード可能なシステムでは、アップグレードごとに継続的な検証が必要です。

ストレージギャップ

ストレージギャップとは、将来のバージョンが子コントラクトのストレージを予期せずずらさずに変数を追加できるよう、アップグレード可能なコントラクトに追加される予約済みの未使用ストレージスロットです。

このパターンは、継承を多用するアップグレード可能なコントラクトで一般的です。

ストレージギャップは、将来の変数のために予約された固定サイズの未使用配列として表示される場合があります。

将来のアップグレードで状態変数を追加する際、開発者はそれに応じてギャップサイズを削減できます。

ストレージギャップは有用ですが、規律が必要です。

ギャップを誤って使うと、ストレージレイアウトの問題が依然として起こる可能性があります。

名前空間ストレージは、一部のアーキテクチャにおいて大きなストレージギャップへの依存を減らせる新しい手法です。

開発者は、使用するアップグレードフレームワークとコンパイラーツールのガイダンスに従ってください。

監査人は、すべてのアップグレードでストレージギャップとレイアウト変更を確認すべきです。

ユーザーがストレージギャップを管理する必要はありませんが、開発者が正しく使用することで利益を得ます。

アップグレードテスト

アップグレードテストでは、新しい実装が既存のプロキシ状態で正しく機能するかを確認します。

通常のユニットテストだけでは、クリーンなストレージを持つ新規コントラクトをデプロイする可能性があるため不十分です。

アップグレードテストでは、旧バージョンをシミュレーションし、現実的な状態を入力し、アップグレードを実行した後、既存状態に対して新バージョンをテストする必要があります。

テストでは、残高、権限、会計、トークン承認、ロール割り当て、オラクル設定、一時停止ロジック、ユーザーポジションを確認すべきです。

無許可ユーザーがコントラクトをアップグレードできないことも確認すべきです。

適切な場合、フォークテストは実際のチェーン状態に対するアップグレードをシミュレーションするのに役立ちます。

ストレージレイアウト検証ツールは、デプロイ前に多くの危険な変更を検出できます。

テストカバレッジには、正常系と失敗系の両方を含めるべきです。

すべてのアップグレードは、追加の移行リスクを持つ新しいデプロイメントとして扱うべきです。

真剣なテストなしにアップグレードするプロトコルは、ユーザーを回避可能な危険にさらしています。

アップグレード監査

アップグレード監査では、新しい実装、ストレージ変更、イニシャライザーまたはreinitializerロジック、アクセス制御、ガバナンス実行経路を確認します。

アップグレード監査では、旧バージョンと新バージョンを比較すべきです。

目的は新しいコードを調査するだけでなく、新しいコードが既存状態とユーザーにどう影響するかを理解することです。

監査人は、ストレージレイアウト、外部呼び出し、権限、アップグレード認可、緊急制御、イベント、統合との互換性を確認すべきです。

アプリケーションがコントラクトを呼び出す際に、アップグレードがABI破壊的変更を生むかも確認すべきです。

監査は安全性を保証しませんが、リスクを低減します。

大規模プロトコルは、アップグレードがユーザー資金に影響する場合、監査報告書または概要を公開すべきです。

小さなアップグレードでも、会計、権限、出金、オラクルロジックに関わる場合は危険になり得ます。

ユーザーは、主要な実装アップグレードが監査済みか確認してから信頼してください。

アップグレード監査は、隠れたリグレッションに対する中核的な防御です。

ABI互換性

ABI互換性とは、アップグレード後も外部アプリケーションが想定どおりコントラクトを呼び出し続けられることを意味します。

ABIは、ウォレットとアプリケーションが使用する関数名、入力、出力、イベント、エラーを定義します。

アップグレードで関数を削除したり、戻り値の型を変更したり、イベントの挙動を変更したり、統合側が依存する前提を変更したりすると、互換性が破損する可能性があります。

ABI破壊的変更により、フロントエンドアプリ、ボット、会計システム、DeFi統合が失敗する可能性があります。

ストレージが安全であっても、連携なしにインターフェースが変更されればユーザー体験は破綻する可能性があります。

開発者は、アップグレード前にABI変更を明確に文書化すべきです。

統合側は、依存するプロトコルの実装アップグレードを監視すべきです。

アプリケーションが新しい実装に更新されていない場合、ユーザーには失敗したトランザクションが表示される可能性があります。

スマートコントラクトはより広いエコシステム内に存在するため、ABI互換性はアップグレードの安全性の一部です。

技術的に有効なアップグレードでも、インターフェースを不用意に変更すれば実際のユーザーに影響する可能性があります。

管理者鍵リスク

管理者鍵リスクとは、アップグレードを管理する鍵またはアカウントが盗難、誤用、紛失、または信頼できない当事者に管理されるリスクです。

攻撃者がアップグレード権限を取得すると、資金を流出させたり残高を変更したりする悪意あるロジックをデプロイする可能性があります。

管理者鍵を失うと、チームは将来のバグを修正できなくなる可能性があります。

1人が管理者鍵を管理している場合、ユーザーはその人物が悪意または過失により行動しないことを信頼する必要があります。

マルチシグウォレットは複数の承認を必要とすることで、単一鍵リスクを低減できます。

タイムロックは遅延を加えることで、不意のアップグレードリスクを低減できます。

DAOガバナンスはアップグレード権限を分散できますが、ガバナンス攻撃リスクを生みます。

プロトコルは、誰がアップグレードを管理するか、鍵がどのように保護されているかを開示すべきです。

ユーザーは、隠された、または不明確な管理者権限を重大な警告サインとして扱うべきです。

アップグレード可能なコントラクトでは、管理者のセキュリティはコードのセキュリティと同じくらい重要な場合があります。

緊急アップグレード

緊急アップグレードは、重大な脆弱性の修正または進行中の攻撃の停止に使用される迅速なアップグレードです。

完全なガバナンスサイクルを待つには遅すぎる場合、ユーザー資金を保護できる可能性があります。

緊急アップグレードは、通常のレビュー、投票、タイムロック遅延を回避する場合があるため、中央集権化リスクも生みます。

プロトコルは、緊急事態が起きる前に緊急権限を定義すべきです。

緊急制御は限定的で、文書化・監視され、信頼できるプロセスによって管理されるべきです。

緊急アップグレード後、チームは何がなぜ変更されたかについて明確な情報を公開すべきです。

ユーザーは、プロトコルが緊急アップグレード権限を持つか理解してください。

緊急経路がないプロトコルは、エクスプロイトへの対応が遅くなる可能性があります。

無制限の緊急権限を持つプロトコルは、過度の信頼を必要とする可能性があります。

最適な設計は、迅速な保護と透明性・説明責任のバランスを取ります。

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

アップグレード可能なトークンは、デプロイ後にロジックを変更できるトークンコントラクトです。

これにより、バグ修正、コンプライアンス変更、新たな手数料モデル、ブリッジ変更、機能更新が可能になる場合があります。

また、新たなミント権限、送転送制限、ブラックリスト、予期しない手数料などの危険な変更も可能になる場合があります。

トークンのルールが固定されていると考える前に、ユーザーはトークンコントラクトがアップグレード可能か確認してください。

名前、シンボル、アドレスが同じでも、アップグレード権限を持つトークンは挙動を変更する可能性があります。

トークン保有者は、管理者ロール、ミント権限、一時停止制御、ブラックリスト機能、アップグレードガバナンスを確認すべきです。

主要なアップグレード後には、検証済みソースコードを確認すべきです。

流動性プロバイダーは、トークンルールの変更が取引プールに影響する可能性があるため、特に注意してください。

アップグレード可能なトークンは正当な場合もありますが、不変トークンとは異なる信頼モデルを持ちます。

トークンのアップグレーダビリティは、ユーザーに明確に開示されるべきです。

アップグレード可能なDeFiプロトコル

アップグレード可能なDeFiプロトコルは、融資、スワップ、ステーキング、清算、ボールト戦略、金利、担保ルールのロジックを変更できます。

DeFi市場は急速に変化し、バグが重大になり得るため、この柔軟性は有用です。

一方で、ユーザーが資金を預け入れた後にプロトコルルールが変更される可能性があるため、リスクも生じます。

アップグレードにより、出金ロジック、手数料計算、リスクパラメーター、オラクルソース、清算挙動が変わる可能性があります。

ユーザーは、DeFiプロトコルのアップグレードがチーム、マルチシグウォレット、タイムロック、ガバナンスプロセスのどれに管理されているか確認してください。

重要なコントラクトが不変かアップグレード可能かも確認してください。

プロトコルには、不変コントラクトとアップグレード可能なコントラクトの両方が含まれる場合があります。

コントラクトがプールされた流動性を保有することが多いため、DeFiのアップグレードリスクは特に重要です。

1つの不適切なアップグレードが同時に多くのユーザーへ影響する可能性があります。

アップグレード可能なDeFiには、一度限りの信頼ではなく継続的な監視が必要です。

アップグレーダビリティとオラクル

オラクルは、資産価格などの外部データをスマートコントラクトに提供します。

アップグレード可能なプロトコルでは、オラクルロジックまたはオラクルアドレスを変更できる場合があります。

公式のEthereumオラクルドキュメントでは、スマートコントラクトはオフチェーンデータに直接アクセスできないため、オラクルが必要だと説明されています。

古いフィードの信頼性が低下したり、より良い情報源が利用可能になったりした場合、オラクルのアップグレーダビリティは有用です。

管理者が操作された、または悪意あるオラクルへ切り替えられる場合、危険になる可能性があります。

融資およびデリバティブシステムでは、不適切なオラクルアップグレードが不公正な清算や誤った決済を引き起こす可能性があります。

ユーザーは、誰がオラクルソースを変更できるか、その変更がタイムロックされているかを確認してください。

開発者は、堅牢なオラクルガバナンスとモニタリングを使用すべきです。

オラクル変更は高リスクのアップグレードとして扱うべきです。

データソースは、主要コントラクトコードの外部に存在していても、スマートコントラクトロジックの一部です。

アップグレーダビリティとブリッジ

ブリッジロジックは新しいチェーン、メッセージ形式、バリデーターセット、リスク管理、セキュリティパッチに対応する必要があるため、ブリッジではアップグレード可能なコントラクトがよく使用されます。

ブリッジのアップグレーダビリティは適応性を向上できます。

一方で、ブリッジは多額のロック済みまたはミント済み資産を管理する可能性があるため、重大な信頼リスクも生みます。

悪意あるブリッジアップグレードは、出金ルールの変更、ラップド資産の不適切なミント、資金のリダイレクトを行う可能性があります。

ユーザーは、ブリッジのアップグレード権限、バリデーターガバナンス、タイムロック、監査、緊急制御を確認してください。

ブリッジは、複数ネットワークと検証上の前提に依存するため、すでに複雑です。

アップグレーダビリティはさらにリスクの層を追加します。

強固なアップグレードガバナンスを備えたブリッジコントラクトは、単一鍵に管理されるものより安全な場合があります。

ただし、いかなるアップグレードプロセスもすべてのブリッジリスクをなくすことはできません。

ブリッジユーザーは、資産を移動する前に技術的前提とガバナンス上の前提の両方を理解してください。

アップグレーダビリティとユーザーの信頼

アップグレーダビリティには信頼上のトレードオフがあります。

ユーザーはバグ修正と機能改善のメリットを得ます。

同時に、将来のロジックが好ましくない方法で変更されるリスクを受け入れます。

透明なアップグレードプロセスは、変更前に何が変わるかを示すことで信頼を向上できます。

隠された、または即時のアップグレードプロセスは、ユーザーが変更を適時に評価できないため信頼を低下させる可能性があります。

プロトコルはアップグレード権限を平易な言葉で説明すべきです。

実装アドレス、管理者アドレス、タイムロック詳細、監査報告書、ガバナンス提案を公開すべきです。

ユーザーは、コントラクトが監査済みかだけを尋ねるべきではありません。

監査済みのコードが明日置き換えられる可能性があるかも確認すべきです。

アップグレード可能なスマートコントラクトでは、信頼は現在のコードと将来の変更管理の両方に依存します。

コントラクトがアップグレード可能か確認する方法

まず、ブロックチェーンエクスプローラーでコントラクトページを確認し、プロキシとしてラベル付けされているかを確認してください。

エクスプローラーに実装アドレスが表示される場合、次にそのアドレスを確認してください。

プロキシがERC-1967、Transparent Proxy、UUPS、Beacon Proxy、Diamondなどの既知のパターンに従うか確認してください。

実装のソースコードが検証済みか確認してください。

管理者アドレス、所有者ロール、マルチシグウォレット、タイムロック、ガバナンスコントラクトを通じて、誰がアップグレードを管理するか確認してください。

実装変更またはアップグレードトランザクションに関する最近のイベントを確認してください。

プロトコルのアップグレードポリシーを理解するため、ドキュメントを読んでください。

アップグレーダビリティがスコープに含まれたかを確認するため、監査報告書を確認してください。

プロトコルがDAO管理のアップグレードを利用している場合、ガバナンス提案を監視してください。

アップグレード可能なシステムでは、プロキシ、実装、権限構造をあわせて確認する必要があるため、コントラクトアドレスだけでは不十分です。

スマートコントラクトのアップグレーダビリティでよくある間違い

よくある間違いの一つは、アップグレード中にストレージ変数の順序を変更することです。

もう一つは、イニシャライザー関数の保護を忘れることです。

3つ目は、1つの秘密鍵を唯一のアップグレード管理者として使用することです。

4つ目は、タイムロックや公開告知なしにアップグレードすることです。

5つ目は、ソースコードを検証せずに新しい実装をデプロイすることです。

6つ目は、古い監査が新しい実装も引き続き対象にしていると考えることです。

7つ目は、統合を壊す形でABIを変更することです。

8つ目は、既存の本番環境に近い状態に対してアップグレードをテストしないことです。

9つ目は、深いレビューなしにカスタムプロキシロジックを使用することです。

10個目は、小規模な管理者グループが即座にロジックを置き換えられるにもかかわらず、システムが分散化されているとユーザーに伝えることです。

スマートコントラクトのアップグレーダビリティのメリット

1つ目のメリットは、デプロイ後にバグを修正できることです。

2つ目は、ユーザーに手動移行を強いることなく機能を追加できることです。

3つ目は、ユーザー、ウォレット、統合におけるアドレスの継続性です。

4つ目は、緊急時の対応能力を高められることです。

5つ目は、複雑なプロトコルの長期的な保守性を向上できることです。

6つ目は、変化の速い暗号資産市場における製品改善をより円滑に行えることです。

7つ目は、オラクル統合、リスクパラメーター、外部依存関係を更新できることです。

8つ目は、プロトコル設計の進化に伴う移行の負担を減らせることです。

これらのメリットは、多くの高度な暗号資産アプリケーションがアップグレード可能なアーキテクチャを選ぶ理由を説明しています。

メリットは、アップグレード権限が透明で、安全に保護され、遅延され、監査され、責任を持ってガバナンスされる場合に最も大きくなります。

スマートコントラクトのアップグレーダビリティのリスクと限界

1つ目のリスクは、悪意ある、または侵害されたアップグレード権限です。

2つ目のリスクは、安全でない実装変更中のストレージ破損です。

3つ目のリスクは、イニシャライザーまたはreinitializerの誤用です。

4つ目のリスクは、管理者鍵を通じた隠れた中央集権化です。

5つ目のリスクは、ABIまたは挙動変更による統合の破綻です。

6つ目のリスクは、見えるアドレスが同じでもロジックが変わるため、ユーザーが混乱することです。

7つ目のリスクは、緊急アップグレードの悪用です。

8つ目のリスクは、古い実装だけを対象とした監査による誤った安心感です。

9つ目のリスクは、ガバナンスの乗っ取りまたは急ぎすぎた投票です。

10個目のリスクは、システムが複雑になり、ユーザーと監査人にとって理解が難しくなることです。

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

可能な場合、カスタムプロキシコードではなく、成熟し十分にレビューされたアップグレードライブラリを使用してください。

Transparent Proxy、UUPS、Beacon Proxy、Diamondなどの明確なアップグレードパターンを、それぞれのトレードオフを理解した後にのみ選択してください。

すべてのアップグレード前にストレージレイアウトを検証してください。

イニシャライザーとreinitializerを慎重に保護してください。

重要なアップグレード権限には、マルチシグ制御、タイムロック、ガバナンスプロセスを使用してください。

実装アドレス、アップグレードトランザクション、平易な言葉でのアップグレード説明を公開してください。

新しい実装ごとにソースコードを検証してください。

適切な場合、本番環境に近い状態およびフォーク環境に対してアップグレードテストを実行してください。

実行前に主要なアップグレードを監査してください。

アップグレードイベントを監視し、アーキテクチャが許す場合はロールバックまたはインシデント対応計画を準備してください。

ユーザー向けベストプラクティス

資金を預け入れる前に、コントラクトがアップグレード可能か確認してください。

誰がアップグレード権限を管理しているかを確認してください。

アップグレードにタイムロック、マルチシグ制御、監査、公開ガバナンスを利用するプロトコルを優先してください。

現在の実装ソースコードが検証済みか確認してください。

古い監査が新しい実装も対象にしていると考えないでください。

プロトコルを頻繁に利用する場合は、主要なプロトコルアップグレードの告知を監視してください。

緊急アップグレードが通常の遅延を回避できるか理解してください。

管理者ロール、一時停止制御、オラクル制御、トークンMint権限を確認してください。

可能な場合、議論のある、または不明確なアップグレードの前に資金を引き出すことを検討してください。

アップグレーダビリティを小さな技術的詳細ではなく、信頼上の前提として扱ってください。

FAQ

スマートコントラクトのアップグレーダビリティとは何ですか？

スマートコントラクトのアップグレーダビリティとは、デプロイ済みスマートコントラクトシステムが、設計されたアップグレード機構を通じてデプロイ後にロジックを変更できることを意味します。

スマートコントラクトはなぜアップグレードされるのですか？

スマートコントラクトは、バグ修正、機能追加、セキュリティ向上、統合更新、リスク管理の調整、変化するプロトコルニーズへの対応のためにアップグレードされます。

アップグレード可能なスマートコントラクトは安全性が低いですか？

アップグレード可能なスマートコントラクトが自動的に安全性が低いわけではありませんが、管理者制御、ストレージレイアウト、ガバナンス、将来の実装変更に関連するリスクが追加されます。

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

プロキシコントラクトとは、通常はシステム状態を維持しながら、呼び出しを実装コントラクトへ転送する安定したアドレスです。

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

実装コントラクトには、プロキシが委譲を通じて実行するロジックが含まれます。

スマートコントラクトのアップグレードにおける最大のリスクは何ですか？

最大のリスクは、承認済みまたは侵害されたアップグレード権限が、安全なロジックを壊れた、または悪意あるロジックに置き換えられることです。

ストレージレイアウトリスクとは何ですか？

ストレージレイアウトリスクとは、新しい実装が既存のプロキシストレージを誤って読み書きし、重要な状態を破損する可能性です。

アップグレーダビリティにおけるタイムロックとは何ですか？

タイムロックはアップグレードの実行を遅らせ、提案された変更が有効になる前にユーザーとレビュアーが確認する時間を与えます。

ソースコードが検証済みであれば、アップグレード可能なコントラクトは安全ですか？

いいえ。検証済みソースコードは透明性を向上させますが、ユーザーはアップグレード権限、監査、ストレージの安全性、ガバナンス、将来の変更リスクも確認する必要があります。

コントラクトがアップグレード可能かはどう確認できますか？

ブロックチェーンエクスプローラーのプロキシラベル、実装アドレス、ERC-1967スロット、アップグレードイベント、管理者ロール、ガバナンスドキュメント、監査報告書を確認できます。

まとめ

スマートコントラクトのアップグレーダビリティは、重要なアドレスと状態を維持しながら、ブロックチェーンアプリケーションがデプロイ後にコントラクトロジックを変更できるようにする設計アプローチです。

暗号資産アプリケーションはローンチ後にバグ修正、機能改善、セキュリティパッチ、統合更新を必要とすることが多いため、広く使用されています。

最も一般的なアップグレーダビリティ設計では、プロキシ、実装コントラクト、delegatecall、標準化ストレージスロット、管理されたアップグレード権限を使用します。

アップグレーダビリティはプロトコルの保守性と回復力を高められますが、将来のコードがユーザーが最初に確認したコードと異なる可能性があるため、信頼モデルも変えます。

アップグレード可能なシステムの安全性は、ストレージレイアウトの規律、イニシャライザー保護、ソースコード検証、テスト、監査、管理者鍵のセキュリティ、タイムロック、透明なガバナンスに依存します。

アップグレード権限が削除されている、または設計上不可能になっていない限り、ユーザーはアップグレード可能なコントラクトを完全に不変として扱ってはいけません。

開発者も、パターンには重大なエンジニアリングおよびガバナンス上の責任が加わるため、アップグレーダビリティを単純な近道として扱ってはいけません。

初心者にとって、スマートコントラクトのアップグレーダビリティは、デプロイ後にブロックチェーンソフトウェアを更新する方法と理解するのが最適です。

上級ユーザーにとっては、プロキシアーキテクチャ、ストレージ互換性、アクセス制御、ガバナンス実行、モニタリング、ユーザーの退出権を含む完全なセキュリティモデルです。

暗号資産用語集の文脈では、Smart Contract Upgradeabilityとは、重要なオンチェーン状態とユーザー向けアドレスを維持しながら、管理された機構を通じてデプロイ済みスマートコントラクトシステムのロジックを変更する能力を意味します。

重要なポイントは、スマートコントラクトのアップグレーダビリティは恒久的なバグからユーザーを保護し、プロトコルの進化を支援できる一方、アップグレード権限が重大なリスク源にもなり得るため、透明性、強固な管理、慎重なテスト、明確な開示を伴って扱う必要があることです。