work 関数は支払い可能な関数です。つまり、ユーザーは work 関数を通じて ibETH コントラクト内の ETH の量を制御でき、それによって totalETH 関数によって返される値が変更されます。さらに悪いことに、作業関数は、RariFundManager などの他のコントラクトの呼び出しもサポートしています。
この機能を通じて、攻撃者は再度 ETH を送信し、ibETH コントラクト内の合計 ETH 量を増加させると同時に、RariFundManager コントラクト内のdrawal を呼び出してより多くの資産を償還することができます。
ERC-4626 を 1 つの記事で理解する: DeFi トークン化保管庫の新しい標準
TLDR: ERC-4626 は、トークン化された保管庫の標準です。
ERC-4626 が導入される前は、各ボールトには独自の仕様と実装の詳細がありました。これにより、統合が困難になり、エラーが発生しやすくなり、リソースが無駄になります。
ERC-4626 は、ERC-20 と同様に、統合の労力を軽減し、より一貫性のある堅牢な実装モデルを作成するために、標準仕様でこの問題を解決しようとします。
ERC-4626 とは何ですか?
ERC-4626 は、イールド ボールトの技術パラメータを向上させる規格です。これは、単一の基礎となる ERC-20 トークンのシェアを表すイールド ボールト用の標準 API を提供します。
トークン化された保管庫は、DeFi において非常に一般的なモデルとなっています。利回りアグリゲーター、融資市場、ステーキングデリバティブ、その他多くの dApp は、トークン化された保管庫を活用し、それに依存しています。トークン化されたボールトの例には、 Yearn や Balancer などがあります。 Yearn Vault は利回りアグリゲーターとして、ユーザーがデジタル資産を預けて利回りを獲得できるようにします。 Balancer は、ビジネス ロジックの中核でボールトに依存する、自動化されたポートフォリオ マネージャーおよび流動性プロバイダーです。これらのボールトは、さまざまなプールのトークンを管理します。同時に、トークン管理をプール自体のロジックから分離します。
このプロトコルは、保管庫をトークン化することで流動性と柔軟性を強化します。トークン化された保管庫により、DeFi プラットフォームでの資産の取引と使用が容易になります。さらに、相互接続された多様な金融商品の作成も可能になります。業界は、しばしば「マネーレゴ」と呼ばれるこのパラダイムを擁護してきました。
ただし、適切な適応性や標準化がなければ、構成可能性には課題が生じます。開発者が ERC-20 などの業界標準に準拠することが困難になるだけでなく、新規開発者が混乱する可能性もあります。適切な適応や標準化がなければ、新しい変更をレビューしたり、統合の実装の詳細を検証したりすることは困難です。
そこでERC-4626は、この問題を解決して統合を簡素化し、同時にDeFi参加者が最終的により安全で堅牢な統合ボールト仕様を採用できるようにするために提案されました。これにより、複数のプロトコルにわたるトークンを統合しながら、プロトコルの潜在的な攻撃対象領域が減少します。
ERC-4626 ではどのようなセキュリティ問題を防ぐことができますか?
ERC-4626 は統一規格を提供することで、クロスプロトコル統合の構築を加速します。使い慣れた一貫した標準は開発者にとっても理解しやすく、コーディング エラーの可能性が減ります。これは、コンポーザビリティの問題を防ぐのに役立ちます。標準化により、コミュニティはプロトコルごとに個別にボールトを設計するのではなく、ボールトを 1 回設計するだけで済むため、作業の重複も防止できます。この設計作業はエラーが発生しやすいため、確立されているものの蔓延している設計上の欠陥の重複を避けるのに役立ちます。
ここでは、ERC-4626 によってどのような問題が防止できるかを示す 2 つのケーススタディを紹介します。
ラリキャピタルイベント
約1,100万ドル相当のトークンがRari Capitalから盗まれました。これは、Rari Capital Ethereumプール内の全ユーザー資金の60％に相当します。
全体として、Rari Capital は、安全でないクロスプロトコルの実装が原因でハッキングされました。そのイーサリアムプールは、出力戦略としてアルファファイナンスのibETHトークン契約にETHを取り込みます。この特定の戦略は、特定のコントラクトと計算式 (特に ibETH.totalETH / ibETH.totalSupply 関数) を通じて ibETH/ETH 為替レートの値を追跡します。この攻撃シナリオでは、たとえば ibETH.work を呼び出すときに誤った出力が得られる可能性があります。 ( ) 関数により、負債の価値が人為的に膨らむ可能性があります。
攻撃者は、RariFundManager コントラクトの入金および出金関数を繰り返し呼び出すだけで、Rari Fund Manager を使い果たす可能性があります。入金関数と出金関数は、呼び出し元に発行される REPT トークンの数、または呼び出し元に発行される ETH の量を計算するために、プールの残高を取得する必要があります。この操作は、アルファ プールの getBalance 関数を呼び出します。 、ibETH コントラクトとその totalETH 関数を呼び出します。ラリは、この機能を操作できる可能性には気づいていません。
ibETH コントラクトには、ibETH.work という別の関数があります。この関数は、ユーザーが指定した任意のコントラクトを呼び出すことができます。これにより、Rari の入金および出金関数を再入可能にして複数回呼び出すことができます。
work 関数は支払い可能な関数です。つまり、ユーザーは work 関数を通じて ibETH コントラクト内の ETH の量を制御でき、それによって totalETH 関数によって返される値が変更されます。さらに悪いことに、作業関数は、RariFundManager などの他のコントラクトの呼び出しもサポートしています。
この機能を通じて、攻撃者は再度 ETH を送信し、ibETH コントラクト内の合計 ETH 量を増加させると同時に、RariFundManager コントラクト内のdrawal を呼び出してより多くの資産を償還することができます。
この事件は、DeFi契約における不十分な統合と互換性のない設計によってもたらされる重大なリスクを浮き彫りにしました。 ERC-4626 のような標準がセキュリティと予測可能性の重要な層を追加することでそのような攻撃をどのように防止し、均一な動作と相互理解を促進できるかを強調しています。
Cream Finance 事件
Cream Finance は、操作された混合オラクルと上限のないトークン供給という、プラットフォームの 2 つの根本的な弱点を悪用した高度な攻撃を受けました。攻撃の重要な部分は、yUSD トークンの知覚価値に影響を与えるミキシングオラクルの操作でした。攻撃者が大量の Yearn 4-Curve トークンを yUSD 保管庫に送信したとき、保管庫によって報告される為替レートを変更したため、オラクルに対する yUSD トークンの知覚価値にも影響を与えました。
ここでの重要な教訓は、堅牢で操作不可能な価格オラクルが DeFi プロトコルの安定性にとって重要であるということです。時間加重平均価格 (TWAP) オラクルは、突然の価格操作に対する耐性が高いため、このようなハッキングを防ぐのに役立ちます。
これらの問題およびその他の脆弱な設計パターンは、ERC-4626 を慎重に採用および実装することで軽減できます。
ERC-4626 の潜在的なセキュリティ リスク
新しいプロトコルの使用には常にいくつかのトレードオフが伴います。トークン化された保管庫の場合、それらをスマート コントラクトに統合する際に特別な注意が必要な潜在的な問題が発生する可能性があります。
FeeOnTransfer トークンを管理する
ボールトが FeeOnTransfer トークンをサポートするように設計されている場合は、資産を転送するときにボールト内の金額とシェアが予想範囲内であることを確認してください。
10 進数変数の適切な使用
ConvertTo 関数では EIP-4626 ボールトの小数点変数を使用する必要はありませんが、可能な場合は基礎となるトークンの小数点をミラーリングすることを強くお勧めします。この実践は、潜在的な混乱の原因を排除し、さまざまなフロントエンドおよびオフチェーン ユーザーの統合を簡素化するのに役立ちます。
丸め
仕様によれば、Vault の実装者は、計算中にユーザーよりも Vault 自体を優先する方が安全であるため、さまざまな可変メソッドとビュー メソッドで特定の逆の丸め方向が必要であることに注意する必要があります。
ユーザーが提供する原トークンの量に応じてユーザーに発行される株式数を計算している場合、または原トークンの特定のシェアをユーザーに譲渡するように運営されている場合は、切り捨てられる必要があります。
一定量のベース トークンを取得するためにユーザーが提供する必要があるシェアの数を計算している場合、または特定の数のシェアを取得するためにユーザーが提供しなければならないベース トークンの数を計算している場合は、次のようにする必要があります。切り上げられる。
推奨される丸め方向があいまいになるのは、convertTo 関数です。すべての EIP-4626 ボールト実装間で一貫性を確保するには、これらの関数が常に切り捨てられるように指定します。インテグレータは、たとえば結果に Wei を追加するなどして、ラウンドアップ バージョンを自分自身で模倣することができます。
ユーザーがボールト内のステークを償還することで受け取る原資産の額 (previewRedeem) は、同じ量のステークを発行するために支払わなければならない金額 (previewMint) とは大幅に異なる場合があります。これらの差異は小さい場合もあります (例: 丸め誤差による)、または大きい場合もあります (例: 金庫の出金または入金手数料が発生する)。したがって、インテグレーターは、ユースケースに最も適したプレビュー機能を使用するよう注意する必要があり、それらが互換性があると想定しないでください。
コア機能をオーバーライドする
意図した機能を実装または拡張するには、コア機能を変更するのではなく、既存のフックを使用することをお勧めします。これにより、効率的なコードのテストと監査のための証跡がより管理しやすくなります。
ゼロシェア
ERC-4626 の元の仕様には、ボールト内に共有がないという特殊なケースの処理方法と、ボールトが通常どおり動作するかロールバックするかについての概要が記載されていませんでした。これは混乱や間違いの原因となる可能性があります。
価格のオラクルとしての Vault
オラクル価格操作攻撃のリスクに関しては、これらのプレビュー メソッドによって返される値は可能な限り正確に近い値です。そのため、チェーン上の条件を変更することで動作する可能性があり、価格オラクルとして使用するのが常に安全であるとは限りません。 ERC-4626 仕様には、不正確を許容する Convert メソッドと totalAssets メソッドが含まれているため、強力な価格オラクルとして実装できます。たとえば、資産と株式の間で変換する場合、時間加重平均価格を使用して変換メソッドを実装するのは正しいことです。
具体的な実装上の問題
インテグレータは、インターフェイス仕様に準拠しているように見えても、そのコア機能が完全に異なる設計仕様で構成されている悪意のある実装が存在する可能性があるため、さらに統合する前にトークン化されたボールトの実装をレビューする必要があります。
EOA ダイレクト アクセス
ボールトに直接アクセスする場合、その実装には、スリッページ損失や偶発的な入出金制限に対応するために使用できる機能が必要です。スマート コントラクトとは異なり、EOA にはトランザクション ロールバックのためのフェイルセーフ メカニズムがありません。コア関数の呼び出し時に正確な出力が得られない場合、ロールバックする方法はありません。
拡張ボールト
より多くのプレーヤーが ERC-4626 標準を採用し始めると、この標準に対してさらに多くの拡張機能が実装されることになるでしょう。たとえば、Superform は、単一の Vault コントラクト内でさまざまな計算の使用をサポートする実験的な Multi Vault 拡張機能を開発しました。当然のことながら、実装が元の標準から逸脱すればするほど、新たな脆弱性が発生する可能性が高くなります。開発者と監査人は、ユースケースに基づいて最適なオプションを見つけて、リスクにさらされている実際の価値を判断できます。
壊滅的な出来事を引き起こすのは、各プロトコルの最小の追加ではなく、統合された場合のそれらの合計であることに注意することが重要です。
上で述べた潜在的な攻撃ベクトルは、ERC-4626 標準に関してよく議論されている問題の一部です。導入が増えるにつれて、より多くの実装ユース ケースと、ERC-4626 コンテナーとの統合に適したシナリオを確実に検討していきます。