
代理コントラクトという言葉を聞いたことがあるかもしれません。
そして、「危険だ」とか「信用できない」と言う人がいたかもしれません。
- 「誰が」「なぜ」プロキシ契約を使うのか?
- Web3の精神に反するのか?
- 本当に危険なのか?
この記事では、これらの質問に答え、プロキシ契約に関するその他の重要な情報を共有し、通常のweb3ユーザーとして、代理コントラクトについてどのように考え、扱うべきかを説明します。さあ、始めましょう!
そもそも、代理コントラクトとは何か?
通常、イーサリアム上のコントラクトは不変であり、一度デプロイされるとアップグレードできません。
結局のところ、ブロックチェーンは一般的に「不変の公開台帳」として定義されていますが、開発者は代理コントラクトモデルを使用することで、この制限を回避することができます。
代理コントラクトは、すべての機能を実装コントラクトと呼ばれる別のスマート・コントラクトに送信(または委譲)します。
実装コントラクト自体(「実行する」あらゆるのコードを含むコントラクト)は、必要に応じて後で変更したり「アップグレード」したりすることができます。
開発者は実装コントラクトの別バージョンをブロックチェーンにデプロイし、受け取ったリクエストをすべて2番目の実装コントラクトに送るように代理コントラクトを更新するだけです(下図)。このようなリクエストの一例として、トークンやNFTのような資産の移転が考えられます。
代理コントラクトの例えとして、土地を買うことが挙げられます。
土地は代理コントラクトとして機能し、有用な機能はすべて家そのものに委譲され、所有者は屋根の葺き替えやキッチンとしてのリフォームなどを自由に行うことができます。
しかし、いくらリフォームしても、あるいはその土地にまったく新しい家を建てても、住所は変わりません!

代理コントラクトを活用しているプロジェクト
代理コントラクトは危険なのでしょうか?
代理コントラクトを使用するNFTプロジェクトに参加すべきでしょうか?
マーケットプレイスやトークン、あるいはDeFiプロトコルについてはどうでしょうか。
こうした疑問に答える前に、実際に存在するプロキシ契約の例をいくつか見てみましょう:
10KTF - このスマートコントラクトは、おそらく最も注目すべきNFTスマートコントラクトの1つで、アップグレード可能なプロキシコントラクトモデルを利用しています。契約をアップグレードすることで、ウォレットの委任、ロイヤリティの強制、新しいプリミティブ/標準の適用などの機能を統合することができます。
USDC - 最大のステーブルコインの1つであるUSDCも代理契約モデルを採用しました。実際、彼らは「Upgrading a multi-billion dollar ERC-20 token(数十億ドル規模のERC-20トークンのアップグレード)」と題した2020年のブログ記事で、その理由と実装について詳しく述べています。彼らは、以下の一文で、彼らの懸念を痛烈に表現しています:「USDCの時価総額はアップグレード時に14億ドルにまで成長しており、私たちのキャリアは危機に瀕していました。」
Blur - BlurはNFTマーケットプレイスであり、$BLURトークンコントラクトを除くほぼすべてのスマートコントラクトで代理コントラクトを利用しています。なぜなら、ユーザーはすでにプロキシアドレスにアセットを承認しており、新たな実装コントラクトはユーザーウォレットからそれらのアセットを引き出す能力を持つからです。新しいBlur実装コントラクトにバグがある場合、Blur代理コントラクトに承認された何十万ものNFTが危険にさらされることになります。詐欺師がウォレットからNFTを抜き取る可能性があり、NFT市場のゲームオーバーが予想されます。サーキットブレーカー機能、コントラクト監査、ホワイトハットハッカーなどの安全策があれば、攻撃を未然に防ぐことができるでしょう。
Compound Finance - Blurと10KTFのアップグレードにまつわるガバナンスがどうなっているかは不明ですが、これらは非公開企業であるため、おそらくより成熟したDAOに見られるような厳格さはない(もちろん透明性も!)と言ってよいでしょう。注目すべき例としては、TVLで10億ドル以上のDeFi融資プラットフォームであるCompound Financeがあります。そのガバナンス・プロセスは、例えば、最低1週間のリードタイムがない限りプロトコルのアップデートを許さず、これはコードによって強制されています。
プロジェクトはなぜ代理コントラクトを活用しているのか?
代理人契約を使用するニュアンスの理由はたくさんありますが、主な理由は以下の通りです:
- **アップグレード性:**これが第一の理由です。代理コントラクトやユーザーに影響を与えることなく、実装コントラクトをアップグレードすることができます。プロジェクトは、すでにある資産の再承認や資金の移行などを要求することで、ユーザーを失いたくありません。代理コントラクトは実装コントラクトのアドレスのみを保存し、そのコードは保存しないため、実装コントラクトのアップグレードによってユーザーが影響を受けることはありません。そのため、実装コントラクトがアップグレードされても、ユーザーは通常通り代理コントラクトとやり取りを続けることができます。
- **将来実装する機能を隠す:**もしかしたら、チームは時間をかけてコントラクトに機能を追加する予定かもしれません。他のコントラクトを仮置きするプレースホルダー方式を構築する必要がなく、時間をかけて機能を追加していくことができます。代理コントラクトは、ブロックチェーン・プロジェクトの新機能を突然リリースする簡単な方法です。
- 将来に備える: 暗号が将来どうなるかは誰にもわかりません。もしかしたら、注目の新しい資産タイプやNFTがBlurで特別な方法で扱われる必要があるかもしれません。新しい機能やプリミティブが開発されるかもしれません。例えば、CryptoPunks(クリプトパンクス)はOpenseaのようなNFTマーケットプレイスで取引するためにはサードパーティの「ラップコントラクト」に依存しています。これは、CryptoPunksがリリースされた当時、ERC-721規格がなかったためです。クリプトのプロジェクトは、複数のコントラクトバージョンを持つことを避けたいと考えています。これは、DeFiの流動性を破壊し、NFTの出所を複雑にするためです。代理コントラクトを使用していれば、CryptoPunksはこの変更を考慮してアップグレードできたはずです(理論上)!

これらの理由のほとんどは、同じことを異なる方法で言っているように見えますが、ニュアンスの違いです。
プロジェクトによっては、ユーティリティやプロジェクトにまったく同じコントラクトアドレスを持つ必要はありません。ユーザーは、特定のUIやウェブサイトを通じてのみ契約とやり取りする場合もあるからです。
ユーザーがスマートコントラクトのブックマーク(NFTのセキュリティ101クラスで学ぶセキュリティ戦略)を採用しない限り、ユーザーは知る由もありません。
しかし、別のプロジェクトでは、トークンコレクションの証明やトークンの統一性が必要になるかもしれません!
代理コントラクトかどうかの見分け方
代理コントラクトかどうかを見分けるには、主に2つの方法があります。
もちろん、あらゆるブロックチェーン分析ツールがありますが、私たちはほとんどの人にEtherscanをお勧めします。
方法 1: まず、Etherscan でContractに移動します。
例では、NFT Security 102 クラスの例でよく参照する代理コントラクト、Helix を使用します。
Contractタブに移動します。ほとんどのコントラクトにはない2つのボタン、「Write as Proxy」と「Read as Proxy」が表示されます。

Etherscanチームが検証済みプロキシとして確認したコントラクトのスクリーンショット。
代理コントラクトと対話する必要がある場合は "Write as Proxy" ボタンを使用してください。
方法 2: プロキシを認識するもう一つの方法は、Etherscan がプロキシであると言っているにも関わらず、開発者が Etherscan で前述のボタンを明示的に利用できるようにしていない場合です。
その代わり、Contract ページにこのような小さなバナーが表示され、代理コントラクトである "かもしれない" と表示されます:

Etherscan がプロキシであると信じている契約ですが、開発者はそれを確認したり Etherscan に提出したりしていません。
代理コントラクトを使うリスク
では、代理コントラクトであることがわかったところで、ユーザーにはどのようなリスクがあるのでしょうか?
代理コントラクトを使用するプロジェクトのセクションでいくつか触れましたが、以下にその概要を説明します。
- 開発者のデプロイ/管理用ウォレットが侵害され、悪意のあるアップデートがデプロイされる可能性がある: ビットコインプロトコルのコア開発者の一人である LukeDashJr を含む、最も有能な開発者のウォレットが侵害された悪名高い事例は数え切れません。悪質な行為者は、代理コントラクトのデプロイアドレスを使用して、コレクション全体を効果的に破壊することができます。
- 開発者が悪意あるアップデートを展開する可能性がある: ほとんどの悪意ある開発者は、単に財宝を盗んで逃げる傾向がありますが(クリプトではラグプルと呼びます)、悪意を持ってプロキシコントラクトをアップグレードすることで、さらに大きな損害を与える可能性があります。ドレイン実装コントラクトを使用して承認されたすべての資産を盗んだり、管理者バーン機能のような機能を追加して、ユーザーのウォレットにすでに「送信」されたトークンを盗むこともできます!
- 開発者がコントラクトを更新し、バグを入れる可能性がある: つい最近、Sushiswapはコントラクトのバグ有りバージョンを展開しました。攻撃者はこのバグを利用し、当時プラットフォームを利用していた著名なクリプト関係者やSushiswapの一般ユーザーのウォレットから330万ドルを流出させました。Sushiswapは代理コントラクトを使用していませんでしたが、もし代理コントラクトを使用していたら、もっとひどいことになっていたでしょう。コントラクトのアップグレードにバグがあった場合、Sushiswapで承認したことのあるすべての人が、この同じバグに脆弱であることを意味します!ハッカーは、Sushiswapでトークン承認を行ったすべての人から資金を盗むことができたでしょう。これが事実であれば、2023年最大のDeFiエクスプロイトになっていた可能性があります!

取引所にとって、代理コントラクトモデルを使用しないことは理にかなっています。少し慎重なユーザーや組織は、アップデート後に新しいユーザーが直面するかもしれない潜在的な問題を待つことができます。代理コントラクトを使用して実装コントラクトをアップグレードすると、すべてのユーザーがその承認取り消し(リボーク)をしない限り、以前に承認したすべてのトークンに新たなリスクが生じることを意味します。
おすすめの対策
代理コントラクトの使用に関連するリスクを理解することはさておき、野良の代理コントラクトに遭遇した場合に従うべき一般的な経験則がいくつかあります:
- エコシステム外の資産に対する承認を求めるNFTコントラクトには特に注意が必要。(エコシステム内の場合はあまり神経質になる必要はない)
例えば、あなたがNFTプロジェクトの一員で、そのコレクションに代理コントラクトを導入しているとします。同じコレクションがあなたのApeCoinやWrapped Ethereumの承認を求めた場合、それはより高いリスクとして扱われるべきです。先に述べたように、Blurは代理コントラクトしか使用していないため、この「避けられない」例としてよくBlurが挙げられます。
- NFTやERC-20トークンを承認する場合、特にマーケットプレイスや取引所では、事前に代理コントラクトかどうかを確認する。
新しいマーケットプレイスやDEXを使うときはいつもこれを確認し、代理コントラクトを使う理由や、新しい実装コントラクトを更新する前に新しいデプロイメントをどのように保護し、監査するのかについて彼らが話しているかどうかを把握に勤めます。
- Revoke.cashまたはApprovals.xyzのようなサービスを使用して、未使用または非アクティブなプロキシ(またはすべてのコントラクト)の承認を取り消す。
非活動的なプロジェクト、特に匿名の創設者を持つプロジェクトは、承認されたトークンを管理するためのコードを新しい実装コントラクトにデプロイすることで、あなたの承認を利用しようとするかもしれません。このような可能性を避けるために、承認は常にクリーンな状態に保ち、承認には支出上限を設定し、不要な承認をウォレットから排除するために定期的な監査を行うことを忘れないでください!
結論
代理コントラクトは悪いことばかりではありません。正直なところ、ほとんどのプロジェクト、特に独自のエコシステムやトークンの中で独自の目的のために代理コントラクトを使用しているプロジェクトでは、プロジェクトの長期的な存続性を確保するための完全に賢明な方法です!
新しいERC規格やトレンドに対応し、Wallet Delegationのような新しいプリミティブをシームレスに統合するのに役立ちます。しかし、それらを使用することは、ブロックチェーンユーザーが長年慣れ親しんできた予測、そして何より重要でミーム的な不変性を低下させます。
結局のところ、代理コントラクトを使うかどうかの決定は、ユーザー次第であり、彼らが何に納得するか次第です。ほとんどの場合、代理コントラクトは、プロジェクトの長期的な実行可能性を保証するための完全に賢明な方法です。しかし、取引所やマーケットプレイス(Blur、Openseaなど)を含むケースでは更新が頻繁にあるべきではないため、代理コントラクトの使用は適切ではないかもしれません。
Web3の最新のセキュリティ情報・詐欺手口についてもっと知りたい、もしくは質問がある方は、私たちのディスコード https://discord.gg/boringsecurity に参加してください。

