ERC-4626――DeFiトークン化ベーシュの新標準
TechFlow厳選深潮セレクト
ERC-4626――DeFiトークン化ベーシュの新標準
ERC-4626は、収益性の金庫（バンク）における技術的仕様を改善する標準であり、個別の基盤となるERC-20トークンの株式を代表する収益金庫に標準APIを提供する。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Sina Pilehchiha
翻訳：TechFlow
TLDR：ERC-4626は、トークン化された保険庫（Vault）のための標準規格です。
ERC-4626が登場する前は、各保険庫がそれぞれ独自の仕様と実装を持っており、統合が困難でエラーが発生しやすく、リソースの無駄となっていました。
ERC-4626は、ERC-20のように標準化された仕様により、統合の手間を軽減し、一貫性があり堅牢な実装パターンを構築しようとするものです。
ERC-4626とは何か？
ERC-4626は、収益型保険庫の技術的仕様を改善するための標準であり、単一の基盤ERC-20トークンに対する収益保険庫に標準APIを提供します。
トークン化された保険庫は、DeFiにおいて非常に一般的なパターンとなっています。収益アグリゲーターや貸借市場、ステーキング派生商品など、多くのdAppがトークン化保険庫を利用・依存しています。具体的な例としてはYearnやBalancerがあります。Yearnは収益アグリゲーターとして、ユーザーがデジタル資産を預け入れて利回りを得られるようにする保険庫を提供しています。Balancerは自動化されたポートフォリオ管理および流動性提供プラットフォームであり、そのコアビジネスロジックは保険庫に依存しています。これらの保険庫はさまざまなプール内のトークンを管理しつつ、トークン管理とプール自体のロジックを分離しています。
プロトコルは保険庫のトークン化によって流動性と柔軟性を高めます。トークン化された保険庫は容易に取引でき、DeFiプラットフォーム上で資産として利用可能です。さらに、多様で相互接続された金融商品の創出も可能になります。このパラダイムは業界で「マネーレゴ」として広く推奨されています。
しかし、適切な適合性や標準化がない場合、組み合わせ可能性（コンポーザビリティ）には課題が伴います。これは開発者がERC-20などの業界標準に従うことを難しくするだけでなく、新規開発者にとって混乱のもとにもなります。適合性や標準化がなければ、新しい変更のレビューも統合実装の検証も困難になります。
そこでERC-4626はこうした問題を解決し、統合を簡素化することで、DeFi参加者が最終的により安全かつ強固な統一保険庫仕様を採用できるようにします。これにより、複数プロトコル間でのトークン統合における攻撃対象領域（アタックスurface）も減少します。
ERC-4626が防止できるセキュリティ問題とは？
統一された標準を提供することで、ERC-4626はプロトコル横断的な統合構築を加速します。馴染みやすく統一された標準は開発者にとって理解しやすく、コードミスの可能性を低減します。これにより組み合わせに関する問題を防ぐことができます。また、標準化により重複作業も回避され、保険庫の設計を各プロトコルごとに個別に行う必要がなくなり、一度だけ設計すれば済むようになります。このような設計作業は誤りやすい傾向があるため、すでに存在するが広く見られる設計上の欠陥を繰り返さずに済みます。
以下では、ERC-4626がどのような問題を防げるかを示すために、2つのケーススタディを紹介します。
Rari Capital事件
Rari Capitalは約1100万ドル相当のトークンを盗まれ、これはRari Capitalのイーサリアムプールにおけるすべてのユーザー資金の60％に相当しました。
全体として、Rari Capitalのハッキングは、安全でないクロスプロトコル実装が原因でした。同社のイーサリアムプールは、収益戦略としてETHをAlpha FinanceのibETHトークンコントラクトに預ける仕組みになっていました。この戦略では、特定のコントラクトおよび式（具体的にはibETH.totalETH / ibETH.totalSupply関数）を使ってibETH/ETHレートの価値を追跡していましたが、この攻撃シナリオでは、例えばibETH.work()関数を呼び出した際に、負債価値が人為的に膨張される可能性がありました。
攻撃者は、RariFundManagerコントラクト内のdepositおよびwithdraw関数を繰り返し呼び出すだけで、Rari Fund Managerを空にしてしまいました。depositおよびwithdraw関数は、ユーザーに発行するREPTトークンの枚数や支払うETHの金額を計算するためにプールの残高を取得する必要があり、そのためAlphaプールのgetBalance関数を呼び出し、ibETHコントラクトのtotalETH関数を呼び出していました。Rariはこの関数が操作可能であることに気づいていませんでした。
ibETHコントラクトには別の関数ibETH.workも存在します。この関数はユーザーが指定した任意のコントラクトを呼び出すことができます。これにより、Rariのdepositおよびwithdraw関数が再入可能（reentrant）になり、何度も呼び出されてしまうことが可能になりました。
work関数は支払い可能な関数であり、ユーザーがwork関数を通じてibETHコントラクト内のETH量を制御し、totalETH関数の返り値を変更できます。さらに悪いことに、work関数は他の任意のコントラクト（たとえばRariFundManager）の呼び出しもサポートしています。
この関数を利用して、攻撃者は再度ETHを送信してibETHコントラクト内のtotalETH額を増やしながら、RariFundManagerコントラクトのwithdrawを呼び出してより多くの資産を引き出すことができました。
この事件は、DeFiコントラクトにおける不十分な統合や互換性のない設計がもたらす重大なリスクを浮き彫りにしました。ERC-4626のような標準は、重要な安全性と予測可能性のレイヤーを追加することでこうした攻撃を防ぎ、統一された動作と相互理解を促進することを示しています。
Cream Finance事件
Cream Financeは、プラットフォーム内の2つの基本的な弱点——操作可能なハイブリッドオラクルと供給上限のないトークン——を悪用した複雑な攻撃を受けました。攻撃の鍵となったのは、ハイブリッドオラクルの操作であり、これがyUSDトークンの知覚価値に影響を与えました。攻撃者が大量のYearn 4-CurveトークンをyUSD保険庫に送信すると、保険庫が報告する為替レートが変化し、結果としてオラクルによるyUSDトークンの知覚価値にも影響が出ました。
ここでの重要な教訓は、強力で操作不可能な価格オラクルがDeFiプロトコルの安定性にとって極めて重要だということです。時間加重平均価格（TWAP）オラクルは、急激な価格操作に対して耐性を持つため、こうしたハッキング攻撃を防ぐのに役立ちます。
こうした問題やその他の脆弱な設計パターンは、慎重にERC-4626を採用・実装することで緩和可能です。
ERC-4626における潜在的なセキュリティリスク
新しいプロトコルを使用する際には常にトレードオフがあります。トークン化保険庫の場合、スマートコントラクトへの統合時に潜在的な問題が生じる可能性があり、特に注意が必要です。
feeOnTransfer トークンの取り扱い
保険庫がfeeOnTransferトークンをサポートする場合は、資産移動時に保険庫内の金額およびシェアが期待される範囲内にあるか確認してください。
decimals 変数の適切な使用
convertTo 関数はEIP-4626保険庫の decimals 変数を必要としないべきですが、可能な限り基盤となるトークンの decimals を鏡像（mirror）することが強く推奨されます。この慣行は潜在的な混乱を排除し、各種フロントエンドおよびオンチェーン外ユーザーの統合を簡素化します。
四捨五入
仕様によれば、保険庫の実装者は、異なる可変およびビュー関数において特定かつ逆方向の丸め処理が必要であることに留意すべきです。計算プロセスでは、ユーザーではなく保険庫自体を優先することがより安全です。
-
ユーザーが一定量の基盤トークンを提供して得られる株式数を計算する場合、または特定の株式に対応する基盤トークンをユーザーに移転する場合は、切り捨て（ダウンラウンド）を行うべきです。
-
ユーザーが一定量の基盤トークンを得るために必要な株式数、あるいは一定量の株式を得るために必要な基盤トークンの量を計算する場合は、切り上げ（アップラウンド）を行うべきです。
convertTo関数では、どちらの丸め方向を採用すべきか曖昧になる可能性があります。すべてのEIP-4626保険庫実装で一貫性を保つため、これらの関数は常に切り捨て（ダウンラウンド）しなければならないと規定されています。統合側では、たとえば結果に1Weiを加算することで、切り上げバージョンを自ら模倣できます。
ユーザーが保険庫の株式を償還（previewRedeem）して得られる基盤資産の量は、同じ量の株式を発行（previewMint）する際に支払う必要がある量と大きく異なる可能性があります。こうした差異は小さなもの（たとえば丸め誤差によるもの）から大きなもの（たとえば保険庫が引き出し手数料や預入手数料を実装している場合）まであります。したがって、統合者は自分のユースケースに最も適したプレビューメソッドを使用するよう注意し、それらが交換可能であると決して想定してはなりません。
コア機能の上書き
期待される機能を実現または拡張するためには、コア機能を変更するのではなく、既存のフック（hook）を使用することが推奨されます。この方法により、コードのテストや監査がより効果的に行えます。
ゼロ株式
ERC-4626の元の仕様では、保険庫に株式がまったくない極端なケースをどう扱うかについて明記されておらず、保険庫が通常通り動作するべきか、あるいはロールバックすべきかが不明確です。これは混乱やエラーの潜在的要因となります。
保険庫を価格オラクルとして使用すること
オラクル価格操作攻撃のリスクに関して、previewメソッドが返す値は可能な限り正確であるべきですが、これらはチェーン上の条件を変更することで操作可能であり、常に価格オラクルとして安全とは限りません。ERC-4626仕様には、不正確なconvertメソッドおよびtotalAssetsメソッドを許容する規定があり、これにより堅牢な価格オラクルを実装できます。例えば、資産と株式の間の変換時に、時間加重平均価格（TWAP）を用いてconvertメソッドを実装することは正しいアプローチです。
具体的な実装上の問題
統合を進める前に、統合者はあらゆるトークン化保険庫の実装を精査する必要があります。なぜなら、インターフェース仕様には合致しているように見えても、そのコア関数が全く異なる設計に基づいている悪意ある実装が存在する可能性があるためです。
EOAからの直接アクセス
保険庫に直接アクセスする場合、その実装にはスリッページ損失や予期せぬ預入／引き出し制限に対応できる機能が必要です。スマートコントラクトとは異なり、EOAにはトランザクションのロールバックというフォールトトレランス機構がないため、コア関数呼び出し時に正確な出力を実現できなければ、元に戻すことはできません。
保険庫の拡張
ERC-4626標準の採用者が増えるにつれ、この標準向けのさらなる拡張が実装されていくでしょう。たとえば、Superformは試験的なMulti保険庫拡張を開発しており、一つの保険庫コントラクト内で異なる計算手法をサポートしています。当然ながら、実装が元の標準から離れれば離れるほど、新たな脆弱性が導入される可能性が高まります。開発者および監査者は、ユースケースに応じて最適な選択を行い、実際のリスク評価を判断する必要があります。
災害的な出来事を引き起こすのは、必ずしも各プロトコルのわずかな追加機能ではなく、それらが統合された際の総合力であることに注意が必要です。
上記で言及された潜在的攻撃ベクトルは、ERC-4626標準周辺でよく議論される問題の一部です。採用率が高まるにつれて、より多くの実装ユースケースやERC-4626保険庫との統合に適したシナリオが明らかになっていくでしょう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
zellic
