プロキシ契約とは何ですか？

プロキシ契約の概念を理解する

プロキシ契約は、 Ethereumのようなブロックチェーンプラットフォームのスマートコントラクト開発で一般的に使用される設計パターンです。その主な目的は、契約の論理をストレージから分離することです。この分離により、開発者は契約アドレスを変更したり、プロキシ自体に保存されているデータを失ったりすることなく、契約のロジックをアップグレードまたは変更できます。

プロキシ契約は、多くの場合、実装契約と呼ばれる別の契約に電話を転送する仲介者として機能します。プロキシはすべての状態変数を保持しますが、実装契約には関数とビジネスロジックが含まれています。このアーキテクチャパターンは、分散型アプリケーション（DAPPS）に長期的な柔軟性を維持するために重要です。

プロキシ契約の仕組み

プロキシ契約のメカニズムは、EVM（Ethereum Virtual Machine）のDelegateCall機能に大きく依存しています。ユーザーがプロキシ契約と対話すると、プロキシはDelegateCallを使用して、実行を現在の実装契約に転送します。これにより、コードがプロキシのコンテキストで実行されることが保証されます。これは、ストレージ、アドレス、およびバランスがプロキシ契約に属することを意味します。

これがこれがどのように機能するかの内訳です：

• プロキシ契約には、現在の実装アドレスへの参照が含まれています。
• プロキシで関数が呼び出されると、 DeLegateCallを使用して、実装契約のコンテキストでその関数を実行します。
• 実行中に行われたすべての変更は、実装契約ではなく、プロキシの保存に影響します。

この方法により、契約システム全体を再配置せずにアップグレード可能性が可能になります。これは、ユーザーの信頼と契約の継続性を維持するために不可欠です。

さまざまな種類のプロキシ契約

プロキシ契約にはいくつかのタイプがあり、それぞれに特定のユースケースと実装の詳細があります。

• 透過的なプロキシ：このタイプは、管理者が管理者から来るか、通常のユーザーから来るかによって、呼び出しを異なってルーティングします。管理コールはプロキシ管理契約に転送され、通常のコールはロジック契約に移動します。
• uups（ユニバーサルアップグレード可能なプロキシ標準） ：このモデルでは、アップグレード機能がロジック契約自体に実装されています。これにより、同じ標準を使用してすべてのプロキシにわたって一貫したアップグレードメカニズムが実施されます。
• ビーコンプロキシ：実装アドレスを直接保存する代わりに、このプロキシは、現在の実装アドレスを動的に提供するビーコン契約を参照します。これにより、複数のプロキシを同時に大量にアップグレードできます。

各プロキシタイプには、セキュリティ、アップグレード可能性、複雑さの点で利点とトレードオフがあります。

プロキシ契約を展開する手順

プロキシ契約の展開には、いくつかのステップが含まれます。これが詳細なウォークスルーです：

• 実装契約の展開：これには、実際のビジネスロジックが含まれます。将来のアップグレードを妨げる可能性があるため、UUPSのような特定のプロキシタイプを使用する場合は、コンストラクターを持たないでください。
• プロキシ契約の展開：展開中に、実装契約のアドレスを指定します。一部のプロキシ契約では、管理者アドレスを設定する必要があります。
• プロキシとの対話：すべてのユーザーインタラクションはプロキシを通過する必要があります。トリュフ、ハードハット、リミックスなどのツールを使用して、プロキシと対話し、正しいABIが使用されるようにします。
• 実装のアップグレード（必要に応じて） ：ロジックの新しいバージョンの準備ができたら、新しい実装契約を展開し、プロキシの参照を更新します。このステップは、使用するプロキシタイプによって異なります。

これらの各手順は、資金の損失やセキュリティの脆弱性を避けるために慎重に実行する必要があります。

プロキシ契約のセキュリティ上の考慮事項

プロキシ契約は、開発者が対処しなければならない新しいセキュリティの課題を導入します。

• ストレージ衝突：実装契約とプロキシが慎重に設計されていない場合、ストレージ変数が重複する可能性があり、意図しないデータ腐敗につながります。
• 初期化の問題：実装契約のコンストラクターは、初期イザー関数に置き換えられないと問題を引き起こす可能性があります。これらの機能は、展開後の再目立化を防ぐために保護する必要があります。
• アクセス制御：契約をアップグレードする機能は、厳密に管理する必要があります。管理キーの不適切な管理は、悪意のあるアップグレードにつながる可能性があります。
• テストの複雑さ：プロキシ契約により、テストの複雑さが高まり、開発者はプロキシと実装契約の両方を徹底的にテストする必要があります。

Openzeppelinのようなフレームワークから監査されたプロキシパターンを使用すると、これらのリスクの多くを軽減できます。

プロキシ契約のユースケース

プロキシ契約は、長期的なメンテナンスが不可欠なさまざまな分散財務（DEFI）プロトコルとDAPPで広く使用されています。いくつかの注目すべきユースケースには次のものが含まれます。

• ガバナンス制御されたアップグレード： Aaveや複合化などのプロトコルは、プロキシ契約を使用して、ユーザーの相互作用を妨げることなくコミュニティ主導のアップグレードを可能にします。
• 再展開なしのバグ修正：展開された契約で重要なバグが発見された場合、開発者は新しい実装でロジックを修正し、ユーザーの残高や契約アドレスに影響を与えることなくプロキシをアップグレードできます。
• マルチ契約システム：複数の契約が連携するシステムでは、プロキシ契約により、すべてのコンポーネントを調整された方法でアップグレードできるようになります。

これらのユースケースは、実際のブロックチェーンアプリケーションでのプロキシ契約の実用的な価値を示しています。

よくある質問

Q：あらゆる種類のスマート契約にプロキシ契約を使用できますか？ A：プロキシ契約は広く適用可能ですが、アップグレード可能性が望まれない許可レスまたは不変の契約には適していない場合があります。たとえば、 ERC-20やERC-721などのトークン標準は、プロキシパターンの恩恵を受けることがよくありますが、一部のプロトコルは信頼の最小化の不変性を好みます。

Q：プロキシ契約を効果的にテストするにはどうすればよいですか？ A：プロキシ契約のテストには、プロキシと実装ロジックの両方を検証することが含まれます。 HardhatやFoundryなどのテストフレームワークを使用して、すべての相互作用がプロキシを通過することを確認します。プロキシ環境をock笑し、ストレージの整合性をチェックすることが重要です。

Q：プロキシ契約はすべてのEVM互換ブロックチェーンと互換性がありますか？ A：はい、プロキシ契約は、Binance Smart Chain 、 Polygon 、 Arbitrumなど、すべてのEVM互換チェーンで利用できるDelegateCallなどのEVM機能に依存しています。ただし、ツールまたは契約検証の違いは、展開ワークフローに影響する場合があります。

Q：プロキシ契約を使用することのガスへの影響は何ですか？ A：プロキシ契約は、追加のDelegateCallステップにより、少量のオーバーヘッドを追加します。ただし、このオーバーヘッドは通常最小限であり、ユーザーエクスペリエンスに大きな影響を与えません。プロキシ設計を最適化し、冗長な呼び出しを最小限に抑えることにより、ガスの節約を実現できます。