最小限のプロキシ契約（EIP-1167）とは何ですか？

最小限のプロキシ契約により、DeLegateCallを使用してコールを実装契約に効率的に転送し、複数のインスタンスで費用対効果の高い展開と共有ロジックを可能にします。

2025/07/15 05:00

最小のプロキシ契約を理解する

最小限のプロキシ契約は、最小限のオーバーヘッドを維持しながら、すべてのコールを別の契約に転送するように設計された軽量のスマート契約です。特に共有ロジックとの契約の複数のインスタンスを展開する場合、イーサリアムベースのシステムで重要な役割を果たします。この概念は、最小限のバイトコードを使用して既存の契約のクローンを作成するための標準の概要を説明するEIP-1167を通じて形式化されました。

このメカニズムの背後にある核となるアイデアは、コードの再利用です。毎回同一のロジックで新しい契約を展開する代わりに、開発者はすべての機能呼び出しを既存の実装契約に委任するプロキシを展開できます。これにより、展開コストが大幅に削減され、アップグレードが簡素化されます。

重要な概念：最小限のプロキシ契約には、実行をターゲット契約にリダイレクトするために必要なコードのみが含まれます。

EIP-1167はどのように機能しますか？

EIP-1167は、その機能を実現するために、 DelegateCall OpCodeを堅牢性で活用します。 DeLegateCallでは、1つの契約が別の契約からコードを実行することができます。最小限のプロキシの場合、これはプロキシが発信者のコンテキストを変更することなく、すべての着信コールを実装契約に転送することを意味します。

これがどのように機能しますか：

• プロキシ契約には、実装契約のアドレスを保持する単一のストレージスロットが含まれています。
• ユーザーがプロキシと対話すると、フォールバック関数がトリガーされます。
• このフォールバック関数は、DeLegateCallを使用して、コールを保存された実装アドレスに転送します。

その単純さのため、プロキシ契約では展開にはほとんどガスが必要です。多くの場合、50,000ガス未満のガスです。この効率により、多くの同様の契約を迅速かつ安価に展開する必要があるシナリオに最適です。

最小のプロキシ契約の構造

通常、最小限のプロキシ契約は、EIP-1167で定義された厳密な構造に従います。これに含まれるものは次のとおりです。

• 実装契約を指す一定のアドレス変数。
• その実装アドレスに対してDeLegateCallを実行するフォールバック関数。
• 実装アドレスを超えたコンストラクターまたは状態変数はありません。

この設計により、プロキシはロジック自体を保存せず、単に実装契約の導管として機能することが保証されます。以下は、Solidityで書かれたこのような契約の単純化されたバージョンです。

 pragma solidity ^0.8.0;契約minimalproxy {





address private immutable implementation; constructor(address _implementation) { implementation = _implementation; } fallback() external payable { address impl = implementation; assembly { let ptr := mload(0x40) calldatacopy(ptr, 0, calldatasize()) let result := delegatecall(gas(), impl, ptr, calldatasize(), 0, 0) let size := returndatasize() returndatacopy(ptr, 0, size) switch result case 0 { revert(ptr, size) } default { return(ptr, size) } } }
 }

重要な注意：フォールバック関数でのインラインアセンブリの使用は、プロキシを最小限で効率的に保つために不可欠です。

最小限のプロキシ契約のユースケース

最小限のプロキシ契約は、効率と柔軟性のために、さまざまな分散型アプリケーションとプロトコルで広く使用されています。最も一般的なユースケースには次のものがあります。

• トークン工場：単一の実装契約から複数のERC-20またはERC-721トークンの作成。
• アップグレード可能な契約：透明なプロキシやUUPSなどのアップグレード可能性パターンの基本層として機能します。
• ガス効率の良い展開：数百または数千の契約を即位させるときの展開コストを削減します。
• 契約テンプレート：複数の展開にわたって予測可能な動作のための標準化されたテンプレートを提供します。

これらのユースケースのそれぞれは、展開フットプリントの削減と、複数のプロキシ全体で一貫したロジックを維持する能力の恩恵を受けます。

最小プロキシと他のプロキシパターンの違い

透明なプロキシ、UUP（ユニバーサルアップグレード可能なプロキシ標準）、ビーコンプロキシなど、イーサリアムにはいくつかのプロキシパターンがあります。それぞれには、複雑さ、アップグレード可能性、ガスコストの観点から独自のトレードオフがあります。

最小限のプロキシと他のプロキシタイプの重要な違いは、機能と拡張性にあります。

• 最小限のプロキシは、追加のインフラストラクチャとペアリングされない限り、アップグレードをサポートしません。
• 透明なプロキシには、管理ロジックとプロキシレジストリ、ガスの使用量の増加、複雑さが含まれます。
• UUPSプロキシは、実装契約を介して自己完結型のアップグレードを可能にします。

最小限のプロキシは、展開後、またはアップグレードが外部で処理される場合、実装が静的なままになるシナリオに最適です。

セキュリティ上の考慮事項とベストプラクティス

最小限のプロキシ契約は簡単ですが、リスクがないわけではありません。開発者は、安全な使用法を確保するためにベストプラクティスに従う必要があります。

• 実装の不変性を確保する：展開したら、明示的に意図して保護されていない限り、実装アドレスは変更されないはずです。
• ストレージの競合を避けてください：プロキシと実装はストレージのコンテキストを共有するため、後でプロキシを拡張する場合は慎重な計画が必要です。
• Bytecodeの検証：悪意のある変更を防ぐために、プロキシ契約と実装契約の両方のバイトコードを常に確認してください。
• 徹底的にテスト： HardhatやFoundryなどのツールを使用して、メインネットの展開前にインタラクションとテストエッジケースをシミュレートします。

重要なヒント：プロキシ契約が実装からセキュリティを継承していると仮定しないでください。それは別々に監査する必要があります。

よくある質問

Q：最小限のプロキシ契約をアップグレードできますか？

最小限のプロキシ自体にはアップグレードロジックは含まれていませんが、UUPSなどの他の標準と組み合わせるか、外部コントローラーを使用して実装アドレスを管理することにより、アップグレード可能なシステムを作成できます。

Q：完全な契約と比較して、最小限のプロキシを展開するのはどれくらい安いですか？

最小限のプロキシを展開すると、通常は約20,000〜50,000ガスのコストがかかりますが、完全な契約を展開すると、複雑さに応じて200万ガスを超える場合があります。

Q：展開されたプロキシから実装アドレスを取得する方法はありますか？

はい、実装アドレスは通常、特定のストレージスロットに保存されます（多くの場合、スロット0）。 eth_getStorageAtなどのツールを使用して、または契約作成コードを検査することで読み取ることができます。

Q：最小限のプロキシは、すべての堅牢性バージョンと互換性がありますか？

彼らは、0.5.0以上の堅牢性でうまく機能します。ただし、最適な互換性とガスの節約には、堅牢性0.8.x以降を使用することをお勧めします。