プロキシコントラクト

プロキシコントラクトとは？

プロキシコントラクトとは、利用者からの呼び出しを受け取り、実際のビジネスロジックを含む別のコントラクトに転送するスマートコントラクトです。

暗号資産分野では、同じ公開コントラクトアドレスと保存状態を維持しながらスマートコントラクトをアップグレードできるよう、主にプロキシコントラクトが使われます。

利用者が操作するコントラクトは、通常「プロキシ」と呼ばれます。

現在のロジックを含むコントラクトは、通常「実装コントラクト」「ロジックコントラクト」「マスターコピー」と呼ばれます。

OpenZeppelinのプロキシアップグレードパターンでは、プロキシによるアップグレードは、コントラクトのストレージとロジックを分離することで実現すると説明しています。

スマートコントラクトは、デプロイ後に変更することが困難、または不可能であるため、この分離は重要です。

通常のコントラクトをデプロイした後でバグが見つかると、チームは新しいアドレスに別のコントラクトをデプロイしなければならない場合があります。

プロキシコントラクトなら、同じプロキシアドレスを維持し、アップグレードが承認されたときに新しい実装コントラクトを参照させることができます。

利用者、ウォレット、アプリケーションは引き続きプロキシアドレスを操作し、そのアドレスの背後にあるロジックを変更できます。

プロキシコントラクトは、恒久的な正面玄関の背後に、交換可能なエンジンがあるものと考えると分かりやすいでしょう。

プロキシコントラクトが使われる理由

ブロックチェーンのイミュータビリティは安全性をもたらす一方、変更を難しくするため、プロキシコントラクトが使われます。

デプロイ済みコードを通常のウェブソフトウェアのように密かに編集できないため、イミュータビリティは利用者の信頼に役立ちます。

しかし、バグ修正、機能追加、セキュリティ問題への対応、性能改善、新しい規格への対応が必要な場合、変更しにくいことが問題になります。

プロキシがなければ、スマートコントラクトのアップグレードには、新しいコントラクトのデプロイと、利用者による資産や権限の移行が必要になることがよくあります。

こうした移行は、コストがかかり、分かりにくく、リスクや混乱を伴う可能性があります。

プロキシコントラクトを使うと、利用者向けのアドレスを維持できます。

これはDeFiプロトコル、NFTコレクション、DAO、トークンコントラクト、ブリッジ、ステーキングシステム、ゲーム内資産、アカウント抽象化ウォレットにとって重要です。

ロジックが変わるたびにコントラクトアドレスを変更する必要がないため、連携先への影響を抑えられます。

緊急の修正をより容易にデプロイできるため、セキュリティ向上にも役立つ場合があります。

ただし、実装を変更する権限を持つ者またはガバナンスプロセスが必要となり、アップグレード可能性に伴う信頼上の前提が生じます。

プロキシコントラクトの仕組み

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

利用者がプロキシを呼び出しても、通常、プロキシ自体が主要なアプリケーションロジックを実行するわけではありません。

代わりに、

などの低レベルなEVMの動作を使って、実装コントラクトに呼び出しを転送します。

実装コントラクトのコードが実行されますが、変更されるストレージはプロキシのものです。

これが、アップグレード可能なプロキシシステムを実現する重要な仕組みです。

残高、設定、所有者変数、トークン供給量、利用者のポジションなどの状態はプロキシに保持されます。

実装コントラクトは、その状態を読み取り、更新する方法を定めたコードを提供します。

システムをアップグレードする場合、新しいロジックを備えた実装コントラクトをデプロイします。

その後、プロキシの実装先ポインターを新しいコントラクトに更新します。

利用者向けのアドレスと保存データはプロキシに残り、以降の呼び出しでは新しいロジックが使われます。

プロキシコントラクトとDelegatecall

は、多くのプロキシコントラクトを機能させる低レベルの仕組みです。

通常の外部呼び出しでは、あるコントラクトが別のコントラクトを呼び出し、呼び出された側が自身のストレージを使います。

では、呼び出されたコントラクトのコードが、呼び出し元のコントラクトのストレージコンテキストで実行されます。

プロキシの場合、実装コントラクトのコードがプロキシのストレージを変更できます。

これにより、プロキシは状態を維持したまま、使用する実装コードを変更できます。

一方、実装コードはプロキシのストレージレイアウトを考慮して作成する必要があり、リスクも伴います。

実装が誤ったストレージスロットに書き込むと、重要なデータを破損する可能性があります。

プロキシが悪意ある実装に委譲すると、そのロジックによって資産が引き出されたり、権限が変更されたりする場合があります。

SWC-112のdelegatecallに関する警告では、開発者に対し、

を慎重に使い、信頼できないコントラクトの呼び出しを避けるよう勧告しています。

プロキシシステムでは、

は単なる技術上の詳細ではなく、セキュリティモデルの中心です。

プロキシコントラクトと実装コントラクトの違い

プロキシコントラクトと実装コントラクトでは、役割が異なります。

プロキシコントラクトは、利用者が呼び出すアドレスを維持し、通常、システムの状態を保存します。

実装コントラクトは、状態の変更方法を決める関数やルールを含みます。

たとえば、トークンのプロキシがプロキシのストレージに残高を保持し、実装コントラクトが送金、承認、ミント、バーン、アクセス制御のロジックを定める場合があります。

新機能が必要になった場合、開発者は新しい実装コントラクトをデプロイします。

その後、プロキシをアップグレードし、新しい実装を参照させます。

プロキシアドレスは変わらないため、利用者や連携先が新しいアドレスに切り替える必要はありません。

この方式は便利ですが、誰がアップグレードを管理しているかを確認する必要があります。

単一の秘密鍵がプロキシ管理者を制御している場合、その鍵はコントラクトに対して大きな権限を持つ可能性があります。

タイムロックと投票を通じてガバナンスがアップグレードを管理すれば、変更の実施前に利用者が内容を確認する時間を確保できる場合があります。

プロキシコントラクトと通常のスマートコントラクトの違い

通常のスマートコントラクトでは、ストレージとロジックが同じコントラクトに含まれるのが一般的です。

デプロイ後、通常のコントラクトのコードは基本的に固定されます。

プロキシ方式では、ストレージとロジックを少なくとも2つのコントラクトに分けます。

プロキシは状態を保存して呼び出しを転送します。

実装コントラクトはロジックを保持し、アップグレードの仕組みが許可すれば置き換えられます。

このため、プロキシシステムは通常のコントラクトより柔軟です。

一方、セキュリティはプロキシ、実装、管理者の権限、初期化プロセス、ストレージレイアウト、アップグレード履歴に左右されるため、監査がより複雑になります。

通常のコントラクトでは、そのアドレスのコードが実行されるコードであるため、利用者にとって理解しやすい場合があります。

プロキシコントラクトでは、有効な実装を特定するため、プロキシの先を調べる必要があります。

ブロックチェーンエクスプローラーが検出できる場合、検証済みプロキシを表示し、現在の実装アドレスを示すことがあるのはこのためです。

プロキシコントラクトとアップグレード可能性

プロキシコントラクトを使う最も一般的な理由は、アップグレード可能にすることです。

アップグレード可能なコントラクトでは、プロキシアドレスを変更せずに、デプロイ後のロジックを変更できます。

バグ修正、機能追加、ガス代の改善、新しい連携、ガバナンス変更、プロトコルのアップグレードに役立つ場合があります。

ただし、アップグレード可能性によって信頼モデルは変わります。

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

利用者は、アップグレード権限のある者が悪意ある変更や不注意な変更をしないと信頼することになります。

アップグレード権限は、単一の所有者、マルチシグウォレット、DAO、タイムロック管理者、または別のガバナンスコントラクトが持つ場合があります。

より安全な設計では、アップグレード権限が透明で、悪用しにくくなっています。

たとえば、タイムロックによって重大なアップグレードの実行までに時間を設け、利用者が資金を引き出せる場合があります。

強固な管理策がなければ、プロキシコントラクトは利用者の資金に対する隠れたバックドアになり得ます。

ERC-1967プロキシ規格

ERC-1967は、プロキシ用のストレージスロットに関する広く使われている規格です。

ERC-1967規格は、実装アドレス、管理者アドレス、ビーコンアドレスなどのプロキシ情報に使う特定のストレージスロットを定めています。

目的は、プロキシと実装コントラクトの間でストレージが衝突するのを防ぐことです。

ストレージ衝突とは、意図せず2つの変数が同じストレージスロットを使うことです。

プロキシシステムでは、

を介してプロキシのストレージと実装ロジックが相互作用するため、特に危険です。

ERC-1967は、ブロックチェーンエクスプローラーや開発ツールが、プロキシの背後にある有効な実装を特定するのにも役立ちます。

これにより、プロキシシステムを調査し、監査しやすくなります。

一般的なアップグレード可能プロキシパターンの多くがERC-1967のスロットを利用します。

既知の規格を使っても、プロキシの安全性が自動的に保証されるわけではありません。

ただし、不要な混乱を減らし、重要なプロキシデータの保存先をツールが把握しやすくなります。

Transparent Proxy

Transparent Proxyは、管理者による呼び出しと利用者による呼び出しを分離するプロキシパターンです。

このパターンでは、通常の利用者はプロキシを呼び出し、その呼び出しは実装コントラクトに転送されます。

管理者はアップグレード関連の操作を実行できますが、通常、誤ってプロキシ経由で実装関数を呼び出すことはできません。

この設計は、プロキシ管理者の関数と実装関数の関数セレクターが衝突するのを防ぐのに役立ちます。

OpenZeppelinのプロキシのドキュメントでは、

を、組み込みの管理者とアップグレード用インターフェースを備えたプロキシとして紹介しています。

アップグレードロジックがシステムのプロキシ側に明確に配置されているため、Transparent Proxyは広く使われています。

ただし、より簡素なプロキシ方式と比べて、わずかにオーバーヘッドが大きい場合があります。

プロキシ管理者を慎重に管理する必要もあります。

プロキシ管理者が侵害されると、攻撃者がコントラクトを悪意あるロジックにアップグレードできる可能性があります。

Transparent Proxyの安全性は、実装コードと管理者のセキュリティに左右されます。

UUPS Proxy

UUPSはUniversal Upgradeable Proxy Standardの略です。

ERC-1822 UUPS規格では、アップグレード互換性を実装ロジックで管理するプロキシ設計を説明しています。

UUPS方式では、アップグレード関数が重いプロキシ管理者インターフェースではなく実装コントラクトにあるため、プロキシをより簡素にできます。

これにより、デプロイコストやプロキシの複雑さを抑えられる場合があります。

ただし、実装コントラクト内のアップグレード関数を適切に保護する必要があります。

アクセス制御に問題があれば、攻撃者がシステムをアップグレードできる場合があります。

新しい実装でアップグレード関数を削除または破損すると、再度アップグレードすることが困難、または不可能になる場合があります。

OpenZeppelinのUUPSツールには、アップグレード可能性を誤って失うリスクを減らす仕組みがありますが、開発者による慎重な確認は欠かせません。

UUPS Proxyは柔軟で効率的なため強力です。

アップグレード権限がどこにあるかをチームが十分理解していなければ、リスクが高まります。

Beacon Proxy

Beacon Proxyは、別のビーコンコントラクトから実装アドレスを取得するプロキシです。

各プロキシがそれぞれ実装アドレスを保存する代わりに、複数のプロキシが1つのビーコンを参照できます。

ビーコンをアップグレードすると、それを使うすべてのプロキシが新しい実装を利用し始める場合があります。

同じロジックを共有する多数の類似コントラクトをまとめてアップグレードしたいプロジェクトに適しています。

たとえば、ファクトリーが共通ロジックを使う多数のユーザーボールト、プール、アカウント、NFT関連コントラクトを作成する場合があります。

Beacon Proxyは、一括アップグレードを簡素化できます。

一方、ビーコンのアップグレード1回で多数のプロキシに影響が及ぶため、リスクが高まる場合があります。

ビーコン管理者は慎重に保護する必要があります。

利用中のコントラクトがビーコンに依存しているか確認してください。ビーコンの変更によって、多数のコントラクトの動作が変わる可能性があります。

Beacon Proxyは多数のコントラクトを効率的に扱えますが、アップグレード権限がビーコンに集中します。

Minimal ProxyとERC-1167

Minimal Proxyは、別の実装コントラクトの動作を低コストで複製するために設計された、小規模なプロキシコントラクトです。

ERC-1167 Minimal Proxy規格は、固定された実装に呼び出しを委譲する、安価なコントラクトクローン向けの最小限のバイトコードパターンを定めています。

Minimal Proxyは「クローン」と呼ばれることもあります。

ウォレット、ボールト、プール、アカウント、マーケットプレイスのインスタンスなど、同じロジックのコントラクトを多数デプロイする必要がある場合に便利です。

各クローンは独自のアドレスと状態を持ちますが、実装ロジックを再利用します。

実装コード全体を毎回デプロイする必要がないため、ガス代を節約できます。

すべてのMinimal Proxyがアップグレード可能なわけではありません。

多くのERC-1167クローンは固定の実装を参照し、別の場所に追加のアップグレードロジックがなければ参照先を変更できません。

安価な複製を目的とするMinimal Proxyと、置き換え可能なロジックを目的とするアップグレード可能プロキシは別のものです。

両方の考え方を組み合わせるシステムもありますが、混同しないようにしてください。

プロキシコントラクトのストレージレイアウト

ストレージレイアウトは、プロキシコントラクトの設計で特に重要な項目です。

プロキシが状態を保存し、実装がロジックを提供するため、実装は正しい順序でストレージを読み書きしなければなりません。

新しい実装で変数の順序を誤って変更すると、以前のストレージが別の型のデータとして解釈される可能性があります。

たとえば、残高のマッピングが所有者変数に置き換わったり、設定値が新しい変数で上書きされたりする場合があります。

その結果、コントラクトの故障やセキュリティ上の脆弱性につながる可能性があります。

アップグレード可能コントラクトのフレームワークでは通常、既存の変数を並べ替えたり削除したりせず、新しい変数を末尾に追加するよう開発者に求めます。

将来の変数に備えて、ストレージギャップを確保する場合もあります。

ストレージレイアウトのチェックにより、デプロイ前に多くのアップグレードミスを検出できます。

開発者は、ストレージレイアウトをコントラクトの公開された安全性モデルの一部として扱う必要があります。

アップグレード時のストレージレイアウトの確認方法を説明していないアップグレード可能プロジェクトには注意してください。

プロキシコントラクトの初期化

アップグレード可能なプロキシコントラクトでは、コンストラクターの代わりに初期化関数を使うことがよくあります。

コンストラクターが実行されるのは実装コントラクトのデプロイ時だけです。

しかし、プロキシシステムでは利用者がプロキシを操作するため、プロキシのストレージを初期化する必要があります。

そのため、通常、プロキシ経由で呼び出す初期化関数を通じてセットアップを行います。

初期化では、所有者、トークン名、トレジャリーアドレス、管理者権限、供給量、手数料設定、ガバナンスパラメーターなどを設定する場合があります。

初期化を忘れると、プロキシが保護されないままになる可能性があります。

攻撃者が先に初期化関数を呼び出すと、所有者や管理者になる場合があります。

初期化関数を複数回呼び出せる場合、重要な設定が上書きされる可能性があります。

このため、アップグレード可能コントラクトでは、初期化の繰り返しを防ぐガードが必要です。

初期化のバグは、アップグレード可能コントラクトでよくある特に危険なミスの1つです。

プロキシ管理者とアップグレード権限

プロキシ管理者とは、プロキシの実装をアップグレードできるアカウントまたはコントラクトです。

単一のウォレット、マルチシグウォレット、DAOの投票、タイムロック、ガバナンスコントラクトが管理する場合があります。

利用者の資産を制御するコードを変更できるため、管理者の役割は非常に重要です。

管理者が悪意あるロジックにアップグレードすると、それ以前の実装が安全でも、利用者が資金を失う可能性があります。

管理者鍵が盗まれた場合、攻撃者が実装を置き換えられることがあります。

管理者の対応が遅すぎたり、分散化されすぎたりすると、緊急の修正が難しくなる場合があります。

優れたプロキシガバナンスには、安全性、迅速な対応、透明性、利用者の退出権のバランスが必要です。

タイムロックは、アップグレードの公表後に実行を遅らせることで信頼性の向上に役立ちます。

マルチシグでは複数の署名者を必要とするため、単一鍵への依存を減らせます。

アップグレード提案や監査結果を公開すると、利用者が変更内容を把握しやすくなります。

プロキシコントラクトとブロックチェーンエクスプローラー

ブロックチェーンエクスプローラーは、プロキシコントラクトの調査に役立つ場合があります。

優れたエクスプローラーでは、あるアドレスがプロキシであることや、現在の実装アドレスを確認できる場合があります。

ERC-1967などの既知の規格に従うプロキシなら、管理者情報も表示されることがあります。

これにより、利用者や監査担当者は実際に実行されるコードを確認できます。

プロキシが検出されないと、利用者はプロキシのバイトコードだけを確認し、実装ロジックを見落とす可能性があります。

プロキシには目に見えるアプリケーションコードがほとんどない場合があるため、誤った安心感につながりかねません。

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

実装がこれまでに変更されたかも確認しましょう。

プロキシが新しいロジックにアップグレード済みであれば、以前の監査が適用されない場合があります。

高額な操作を行う場合は、表示されたアドレスだけでなく、プロキシ、実装、管理者、アップグレード履歴も確認する方が安全です。

プロキシコントラクトとトークンコントラクト

将来のアップグレードに対応するため、プロキシを使うトークンコントラクトは多数あります。

アップグレード可能なトークンは、同じトークンアドレスを保ちながら、送金ルール、手数料、ミント、バーン、ブリッジ、コンプライアンス、ガバナンスの機能を変更できる場合があります。

トークンを時間とともに適応させる必要がある場合には便利です。

一方、購入または受け取り後に、利用者が前提としていたルールが変わる可能性があるため、リスクも伴います。

たとえば、アップグレードによって送金制限の追加、手数料動作の変更、停止権限の追加、アクセス制御の変更が行われる場合があります。

トークンのルールが恒久的だと考える前に、トークンコントラクトがアップグレード可能か確認してください。

アップグレードを誰が管理し、変更がガバナンスによって遅延されるかも確認しましょう。

プロキシを使うトークンが自動的に危険というわけではありません。

完全に不変なトークンコントラクトとは異なる信頼モデルを持つということです。

重要なのは、アップグレード権限が透明で、適切に保護されているかどうかです。

プロキシコントラクトとDeFiプロトコル

金融アプリケーションには保守が必要となるため、DeFiプロトコルではプロキシコントラクトがよく使われます。

融資プロトコル、自動マーケットメイカー、デリバティブシステム、ステーキングボールト、イールド戦略は、監査、市場の変化、オラクルの改善、バグ発見を受けてアップグレードが必要になる場合があります。

プロキシコントラクトにより、すべての利用者にポジション移行を求めずに、こうしたシステムを改善できます。

DeFiのポジションは複雑で、複数のプロトコルにまたがって連携することもあるため、これは便利です。

ただし、アップグレード可能性はシステム全体に影響するリスクも生みます。

広く使われているDeFiコントラクトで不適切なアップグレードが行われると、多数の利用者や連携先に一度に影響する可能性があります。

アップグレード可能なDeFiプロトコルには、強固なテスト、監査、監視、ガバナンス管理、緊急時の手順が必要です。

プロトコルが監査済みかどうかだけでなく、現在の実装が監査済みか、今後のアップグレードに公開レビューが必要かも確認してください。

DeFiでは、プロキシコントラクトが保守性を高める一方、ガバナンスの重要性も高めます。

プロキシコントラクトとNFT

NFTプロジェクトでは、メタデータ、ミント、マーケットプレイス連携、ロイヤリティ、ステーキング、ゲームの仕組みをアップグレードするため、プロキシコントラクトを使う場合があります。

NFTのプロキシにより、ローンチ後にプロジェクトが機能を追加できる場合があります。

実装がトークンURIのロジックを制御していれば、メタデータの動作を変更できる可能性もあります。

シンプルなコレクティブルからゲーム、会員権、デジタルアイデンティティへとプロジェクトが発展する場合には役立ちます。

コレクターが固定ルールや恒久的なメタデータを期待していると、議論になる可能性があります。

NFTを購入する前に、コントラクトがアップグレード可能か、メタデータが変更可能か確認してください。

アップグレード管理者が誰かも確認しましょう。

完全に不変なNFTとアップグレード可能なNFTは、どちらも正当なものになり得ますが、提供する保証は異なります。

固定されたオンチェーンルールを購入するのか、変化し得るプロジェクトに参加するのかを理解してください。

プロキシコントラクトはNFT開発の柔軟性を高めますが、アップグレードプロセスに対する信頼も必要です。

プロキシコントラクトとDAO

DAOでは、ガバナンスモジュール、トレジャリーツール、投票システム、ステーキングコントラクト、プロトコルのパラメーターをアップグレードするため、プロキシコントラクトを使う場合があります。

DAOが管理するプロキシでは、提案や投票が必要になるため、単一管理者のプロキシより透明性が高まる場合があります。

ただし、DAOガバナンスによってアップグレードの安全性が自動的に保証されるわけではありません。

投票率の低さ、票の買収、ガバナンス攻撃、拙速な提案、分かりにくいコード変更は、依然としてリスクになります。

適切なDAOアップグレードプロセスには、分かりやすい概要、技術的な差分、監査へのリンク、リスク分析、投票期間、タイムロックによる遅延が必要です。

DAOのメンバーは、どのコントラクトがアップグレード可能で、ガバナンスにどのような権限があるかを理解する必要があります。

ガバナンスがトレジャリー、トークン、コアプロトコルのロジックをアップグレードできる場合、投票者には重大なセキュリティ上の責任があります。

プロキシコントラクトはDAOが時間とともに適応するのに役立ちます。

一方で、利用者が安定していると考えていたルールをガバナンスが変更できるようにもなります。

DAOのアップグレード可能性は、可視化、文書化、慎重な管理が必要です。

プロキシコントラクトのメリット

第一のメリットは、アップグレード可能性です。

メインのコントラクトアドレスを変更せずに、バグ修正、機能追加、ロジック改善を行えます。

第二のメリットは、状態の継続性です。

実装ロジックが変わっても、利用者の残高、ポジション、権限、設定をプロキシに保持できます。

第三のメリットは、連携の安定性です。

ウォレット、dApp、インデクサー、ほかのコントラクトが同じアドレスを引き続き利用できます。

第四のメリットは、移行時の負担軽減です。

アップグレードのたびに、利用者が手動で資産を新しいコントラクトに移す必要がなくなる場合があります。

第五のメリットは、クローンパターンにおけるガス効率です。

Minimal Proxyを使うと、毎回コード全体をデプロイするより低コストで、類似コントラクトを多数展開できます。

第六のメリットは、モジュール型のアーキテクチャです。

チームはストレージ、ロジック、アップグレード管理、デプロイ方法をより明確に分けられます。

これらのメリットを得るには、プロキシコントラクトの慎重な設計、監査、ガバナンス、監視が必要です。

プロキシコントラクトのリスク

第一のリスクは、悪意あるアップグレードです。

アップグレード権限が侵害されたり、権限の保有者が不誠実だったりすると、安全なロジックを悪意あるものに置き換える可能性があります。

第二のリスクは、ストレージ衝突です。

ストレージレイアウトが誤っていると、アップグレードによって重要なコントラクトの状態が破損する場合があります。

第三のリスクは、初期化の失敗です。

未初期化のプロキシや実装によって、攻撃者が制御権を得る可能性があります。

第四のリスクは、関数セレクターの衝突です。

設計が不適切だと、プロキシ管理者の関数と実装関数が競合する場合があります。

第五のリスクは、監査対象との不一致です。

以前に監査を受けたコントラクトでも、現在の実装は異なる可能性があります。

第六のリスクは、隠れた複雑さです。

通常の不変コントラクトではなく、プロキシとやり取りしていることに利用者が気付かない場合があります。

第七のリスクは、ガバナンスの掌握です。

攻撃者が投票権、管理者アクセス、ソーシャルエンジニアリングを通じてアップグレードプロセスに影響を与える場合があります。

第八のリスクは、ツール側の誤認です。

カスタムまたは標準規格に準拠しないプロキシでは、ブロックチェーンエクスプローラー、ウォレット、インデクサーが詳細を正しく表示できない場合があります。

操作前にプロキシコントラクトを確認する方法

まず、ブロックチェーンエクスプローラーで、コントラクトアドレスがプロキシとして表示されているか確認してください。

現在の実装アドレスを確認しましょう。

実装コントラクトのソースコードが公開され、検証済みか確認してください。

実装が最近変更されたかを確認しましょう。

プロキシ管理者またはアップグレード権限を持つ者を調べてください。

アップグレードがマルチシグ、DAO、タイムロック、単一の秘密鍵のどれを通じて行われるか確認しましょう。

監査日と実装のデプロイ日を比較してください。

コントラクトが意図的にアップグレード可能かを、公式ドキュメントで確認しましょう。

プロキシアドレスが変わっていないからといって、コントラクトが不変だと考えないでください。

多額の資金を預け入れる場合、プロキシの確認を通常のデューデリジェンスに含めてください。

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

専門家のレビューなしに独自のプロキシロジックを作成せず、十分にレビューされたプロキシフレームワークを使ってください。

ツールでプロキシの状態を確認できるよう、適切な場合はERC-1967などの規格に従ってください。

強固なアクセス制御でアップグレード関数を保護してください。

高額なアップグレード権限には、マルチシグウォレット、タイムロック、ガバナンスコントラクトを使ってください。

初期化関数を慎重に作成し、初期化の繰り返しを防いでください。

アップグレードの前に、ストレージレイアウトをテストしてください。

影響を理解しないまま既存のストレージ変数を並べ替えたり、削除したり、変更したりしないでください。

実装コントラクトをブロックチェーンエクスプローラーで検証してください。

重大な変更の前に、アップグレードの告知、監査、技術的な説明を公開してください。

アップグレードのイベントを監視し、失敗時に迅速に対応できるようにしてください。

利用者向けのベストプラクティス

アップグレード可能なプロキシは、完全に不変なスマートコントラクトとは異なることを理解してください。

多額の資金を預け入れる前に、プロキシをアップグレードできる者を確認してください。

タイムロックによってアップグレードが遅延されるか確認しましょう。

最新の実装が検証済みで、監査を受けているか確認してください。

プロキシ管理者が不明な単一ウォレットによって管理されている場合は注意してください。

大きなポジションを保有するプロトコルについて、アップグレードイベントを監視してください。

リスクを理解しないまま、アップグレード可能なコントラクトに無制限のトークン使用許可を与えないでください。

プロトコルの利用後、不要な承認を取り消してください。

過去の動作が安全に見えても、アップグレードによって今後の動作が変わる可能性があります。

プロキシコントラクトは、継続的な信頼性評価が必要な柔軟なシステムとして扱ってください。

プロキシコントラクトに関するよくある誤解

よくある誤解の1つは、プロキシコントラクトは自動的に危険だというものです。

実績のあるパターン、適切なアクセス制御、強固なガバナンス、監査、透明なアップグレードがあれば、安全に利用できる場合があります。

一方、人気のあるフレームワークを使っているため自動的に安全という誤解もあります。

標準的なプロキシであっても、実装が悪意あるものだったり、管理者が侵害されていたりすれば危険です。

プロキシアドレスだけを確認すれば、必要なロジックをすべて確認できるという誤解もあります。

実際のアプリケーションロジックは、多くの場合、実装コントラクトにあります。

監査を受けていれば現在のコードも対象になっているという誤解もあります。

プロキシがアップグレード済みなら、以前の監査は新しい実装を対象としていない可能性があります。

Minimal Proxyはすべてアップグレード可能という誤解もあります。

多くのMinimal Proxyは、固定ロジックに呼び出しを転送する低コストのクローンにすぎません。

よくある質問

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

プロキシコントラクトとは、別のコントラクトに呼び出しを転送するスマートコントラクトです。通常、ロジックを変更しながら同じアドレスとストレージを維持するために使われます。

暗号資産プロジェクトがプロキシコントラクトを使うのはなぜですか？

アップグレード、バグ修正、機能追加、移行負担の軽減、アドレスの維持、類似コントラクトの効率的なデプロイを目的に利用します。

プロキシコントラクトはアップグレード可能ですか？

多くのプロキシはアップグレード可能ですが、固定ロジックを参照するMinimal Proxyなど、すべてがアップグレード可能なわけではありません。

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

実装コントラクトとは、転送または

を通じてプロキシが実行するロジックを含むコントラクトです。

プロキシコントラクトにおけるdelegatecallとは何ですか？

は、プロキシ自身のストレージコンテキストを使いながら実装コードを実行できるEVMの操作です。

ERC-1967とは何ですか？

ERC-1967は、実装、管理者、ビーコンのアドレスなど、プロキシデータ用の特定のストレージスロットを定める規格です。

Transparent Proxyとは何ですか？

Transparent Proxyは、関数の衝突リスクを抑えるため、管理者のアップグレード呼び出しと通常の利用者の呼び出しを分ける、アップグレード可能なプロキシパターンです。

UUPS Proxyとは何ですか？

UUPS Proxyは、主にプロキシ側ではなく実装コントラクト側でアップグレードロジックを処理する、アップグレード可能なプロキシパターンです。

Beacon Proxyとは何ですか？

Beacon Proxyは、ビーコンコントラクトから実装アドレスを取得します。ビーコンを変更することで、複数のプロキシをまとめてアップグレードできます。

Minimal Proxyとは何ですか？

Minimal Proxyは、ERC-1167に基づくことが多い小規模なクローンコントラクトです。共有実装ロジックに呼び出しを転送し、デプロイコストを抑えます。

プロキシコントラクトにはリスクがありますか？

はい。アップグレード権限が弱い、ストレージレイアウトが誤っている、初期化が安全でない、ロジックが変更可能だと利用者が理解していない場合、リスクがあります。

コントラクトがプロキシかどうかを確認する方法は？

ブロックチェーンエクスプローラーで、プロキシの表示、実装アドレス、ERC-1967のストレージスロット、検証済みソースコード、アップグレードイベントを確認できます。

まとめ

プロキシコントラクトは、利用者向けのアドレスと保存状態を、コントラクトの動作を実行するロジックから分離するスマートコントラクトの設計パターンです。

利用者や連携先が新しいアドレスに移行せずにスマートコントラクトをアップグレードできるため、暗号資産分野で広く使われています。

プロキシは呼び出しを受け取り、ストレージを保持し、多くの場合

を通じて実装コントラクトに処理を転送します。

ERC-1967、ERC-1822、ERC-1167などの規格は、Transparent Proxy、UUPS Proxy、Beacon Proxy、Minimal Proxyを含む一般的な設計の整理に役立ちます。

プロキシコントラクトは、アップグレード可能性、状態の継続性、連携の安定性、低コストなクローンのデプロイなどのメリットをもたらします。

同時に、悪意あるアップグレード、ストレージ衝突、未初期化コントラクト、管理者鍵の侵害、不明確なガバナンス、古い監査といった重大なリスクも生じます。

開発者は、プロキシコントラクトを慎重な設計、テスト、アクセス制御、公開ドキュメントが必要な、リスクの高いアーキテクチャ要素として扱うべきです。

利用者は、プロキシの背後にあるロジックが時間とともに変わる可能性があるため、通常の不変コントラクトとは異なる観点で確認してください。

プロキシコントラクトは、管理された条件のもとで背後のコードを置き換えながら、同じオンチェーンアドレスを維持する仕組みと考えると分かりやすいでしょう。

この柔軟性は、アップグレード権限が透明で、制限され、慎重に管理される場合に限り、暗号資産システムの安全性と保守性の向上に役立ちます。