プロキシ契約とは何ですか？また、アップグレード性をどのように可能にしますか？

スマート契約開発におけるプロキシ契約の理解

ブロックチェーンとスマートコントラクトの開発の世界では、プロキシ契約が重要な設計パターンとして浮上しています。展開が一度不可能な従来のスマート契約とは異なり、プロキシ契約は、契約全体を再展開することなく変更とアップグレードを実装するための構造化されたメカニズムを提供します。この柔軟性は、展開されたコードを直接変更できないイーサリアムのような環境で特に重要です。プロキシ契約は、ユーザーとアプリケーションの実際のロジックの間の仲介者として機能し、開発者が時間の経過とともに機能を更新できるようにします。

プロキシ契約の仕組み：技術的な概要

その中核では、プロキシ契約は、実装契約と呼ばれる別の契約を中心にファサードまたはラッパーとして機能します。ユーザーがプロキシと対話すると、 delegatecall opcodeを使用して機能コールを実装契約に転送します。このオペコードは、ロジックが他の場所に存在していても、実行のコンテキスト（ストレージや送信者アドレスなど）がプロキシの状態と一致し続けることを保証します。

• プロキシは契約の状態を維持します。
• 実装契約には、ビジネスロジックが含まれています。
• ユーザーからの関数呼び出しは、プロキシを介して現在の実装にルーティングされます。

この分離により、プロキシアドレスに結び付けられたすべての既存のデータとインタラクションを保存しながら、実装の更新が可能になります。

アップグレード可能性を有効にする上でのDelegateCallの役割

プロキシ契約のアップグレード可能性を可能にする主要な技術的機能は、 delegatecallメカニズムです。 Solidityでは、 delegatecallでは、1つの契約が別の契約からコードを実行しながら、発信者のストレージ、価値、およびコンテキストを維持できます。これは、プロキシ契約がdelegatecallを使用して実装契約で機能を呼び出す場合、実行中に行われた変更は実装ではなくプロキシのストレージに影響することを意味します。

この動作は、次のために不可欠です。

• アップグレード後もデータが持続することを保証します。
• これは、将来の変更に必要なストレージからロジックを切り離します。

delegatecallがなければ、アップグレードでは契約とその関連データの両方を再配置する必要があり、潜在的な矛盾と情報の損失につながります。

実際に使用されるプロキシパターンの種類

いくつかのプロキシパターンがイーサリアムエコシステム内に存在し、それぞれがさまざまな複雑さと制御の程度を提供します。

• 透明なプロキシパターン：このアプローチは、すべての外部呼び出しを実装契約にルーティングします。発信者が管理者であり、プロキシで管理機能に直接アクセスできます。これにより、ガバナンス操作が定期的なユーザーインタラクションを妨げないようにします。

• UUPS（ユニバーサルアップグレード可能なプロキシ標準） ：このモデルでは、アップグレードロジックは実装契約自体の一部です。これにより、実装レベルでアップグレードを制御できるようにすることにより、集中リスクが低下します。

• ビーコンプロキシパターン：実装アドレスをハードコードする代わりに、ビーコンプロキシは、個別のビーコン契約から最新の実装アドレスを取得します。これにより、複数のプロキシを同時に大量にアップグレードできます。

これらの各モデルには、セキュリティ、分散化、メンテナンスの容易さの点でトレードオフがあり、プロジェクトの要件に応じて異なるユースケースに適しています。

基本的なプロキシ契約の実装：ステップバイステップガイド

基本的なプロキシ契約を作成するには、いくつかの正確な手順が含まれます。堅牢性を使用して手動で行う方法は次のとおりです。

• 実装契約の書き込み：標準的な堅牢性契約でアプリケーションのコアロジックを定義します。たとえば、バランス追跡および転送機能を備えた単純なトークン契約を作成します。

• 実装契約の展開：HardhatやTruffleなどの展開スクリプトまたはツールを使用して、実装契約を目的のネットワークに展開します。契約アドレスに注意してください。

• プロキシ契約の作成：実装アドレスを保存し、 delegatecallを使用して着信トランザクションを転送するプロキシ契約を作成します。フォールバックが不明な関数呼び出しを適切に処理することを確認してください。

 pragma solidity ^0.8.0;契約プロキシ{




address public 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) } } }
 }

• プロキシ契約の展開：プロキシを展開し、実装アドレスをコンストラクターに渡します。

• プロキシと対話する：すべてのユーザーインタラクションはプロキシ契約を通過し、永続的な状態を維持しながら正しいロジックが実行されるようにする必要があります。

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

アップグレード性は、新しい攻撃ベクトルを導入し、慎重な取り扱いが必要です。ここにいくつかの重要な考慮事項があります：

• 管理者アクセス制御：信頼できるエンティティのみがアップグレードを開始できるはずです。不正な変更を防ぐために、マルチシグネチャウォレットまたはタイムロックを実装します。

• ストレージ衝突：プロキシおよび実装契約にストレージ変数が重複している場合、データの破損が発生する可能性があります。競合を避けるために、OpenzeppelinのInitializableなライブラリを使用します。

• テストと監査：ステージング環境でプロキシベースのシステムを徹底的にテストします。搾取可能な脆弱性がないことを確認するために、メインネットに展開する前に正式な監査を実施します。

• ドキュメントと透明性：アップグレード手順を明確に文書化し、潜在的な変化についてユーザーと透明性を維持します。

ベストプラクティスを順守することにより、開発者はアップグレード可能なスマートコントラクトの利点を活用しながら、リスクを軽減できます。

よくある質問

Q1：プロキシ契約をアップグレードできますか？いいえ、通常、アクセス制御メカニズムによって管理される管理特権を持つアドレスのみがアップグレードを実行できます。不正アクセスを防ぐには、適切な役割管理が不可欠です。

Q2：実装契約の過去のバージョンを追跡することは可能ですか？はい、履歴実装アドレスをオンチェーンまたはオフチェーンで保存することにより、開発者は特定の期間に使用された以前のバージョンを監査および検証できます。

Q3：コール中に実装契約が元に戻すとどうなりますか？実装契約が戻ると、トランザクションが失敗し、通話中に行われた状態の変更が展開されます。プロキシ契約は、失敗したロジックの変更を保持しません。

Q4：すべてのEthereum Virtual Machine（EVM）互換ブロックチェーンと互換性がありますか？はい、 delegatecallなどの基本的なEVM機能に依存しているため、Binance Smart Chain、Polygon、AvalancheなどのすべてのEVM互換ネットワークでプロキシ契約が機能します。