DeFi が成長し成熟するにつれて、スケーラブルなインフラストラクチャとコンポーザビリティが開発者の最優先事項になります。 Ethereum Requests for Comments (または ERC) — 広く使用されているトークン標準など、Ethereum ベースのアプリを構築するための標準化されたツールキット ERC20 — 開発者がゼロから始めることなくエコシステムに貢献するための一貫したガイドラインを提供するという重要な役割を果たします。 今年これまでに、トークン化されたボールト標準 ERC4626 利回りトークン間の相互互換性を促進するために作成されました。 実装の詳細を標準化することで、差し迫った構成可能性の問題にも対処できるため、プロトコルの統合が容易になり、最終的にエラーが発生しにくくなります。

いくつかの DeFi プロジェクトはすでに 採択 ボールトの構成可能性を高めることを目指しており、エコシステム全体でより広く採用されることが予想されます。 ただし、既存のボールトを適応させると、いくつかの成長する痛みが生じます。 重大なことに、特定の実装エラーは、攻撃の新しいターゲットを公開する可能性があります。 小さなエラー (標準インターフェースの誤解のような小さなもの) でさえ、セキュリティとユーザー エクスペリエンスの両方に重大な結果をもたらす可能性があり、特により構成可能な DeFi エコシステム内で、より多くのセキュリティ ツールと手段の必要性を強調しています。 

幸いなことに、単純なエラーは、悪用される前に (理想的には展開される前に) 検出されれば、比較的単純な解決策を持つことができます。 そのために、リリースしました ERC4626 プロパティ テスト ファジングとシンボリック実行のために、vault ビルダーが標準違反を検出するのに役立ちます。これらの違反は、統合を壊したり、将来的に脆弱性につながる可能性があります。 この投稿では、動機付けの問題を説明し、アプローチを順を追って説明し、実行可能なアドバイスで締めくくります。

まず、ERC4626 標準の背景を少し説明します

XNUMX月に確定し、 ERC4626 トークン化されたボールトの標準です。 広く使われている機能を拡張するために導入されました。 ERC20 標準 (現在、数百のトークンのベース) を生成し、利回りのあるボールト全体で標準化を促進し、それらとやり取りする必要があるアプリとプロトコル (利回りアグリゲーターなど) の構成可能性を確保します。 つまり、ERC4626 Vault で構築されたアプリは、他の ERC4626 Vault で動作するように簡単に拡張できます。 

トークン化されたボールトにより、ユーザーは資産を自由に入金してボールト共有を作成し、後でそれらの共有を償還してボールトから元本と利息を引き出すことができます。 これらのボールト シェアは ERC20 トークンであるため、簡単に取引したり、他の資産を借りるための担保として使用したりできます。 たとえば、ユーザーは資産を Yearn ボールトに預けて yVault トークンを作成し、Uniswap で取引したり、追加の利回りを得るためにステーキングしたり、融資プロトコルの担保として使用したりできます。

利回りを生成して分配する (および株価を決定する) ためのビジネス ロジックは、実装によって異なる場合があります。 可能な限り多くのボールトをカバーするために (それらを相互運用可能にすることと同一にすることを目標に)、ERC4626 標準はユーザー インターフェイスの記述に重点を置き、実装の詳細のほとんどを未指定のままにしています。 これにより、ボールトがインターフェイスの特定の要件を満たしている限り、ビジネス ロジックのバリエーションが可能になり、 多くの異なる種類のアプリと ERC4626 ボールトの種類にわたる相互運用性。

より多くのボールトが作成されるにつれて、最初から ERC4626 標準に従って実装されることを期待しています。 しかし、私たちは現在、やや過渡的な段階にあり、より優れたコンポーザビリティを利用しようとしている開発者は、標準に準拠するように既存のボールト、アプリ、およびプロトコルを更新する必要があります. そして、アップグレードするにつれて、多くの複雑さと課題に取り組みます。 

標準準拠の課題 (および準拠しない場合の落とし穴)

新しい標準に従うことは、必ずしも簡単ではありません。 すべての ERC4626 Vault は、説明されている標準の要件を忠実に (そして正確に) 実装する必要があります。 それ以外の場合、ERC4626 ボールトの統合は、さまざまなバリエーションを考慮するためにますます複雑になります。 この複雑さにより、統合は本質的にエラーが発生しやすくなります。 また、将来性が十分でないため、時間の経過とともにセキュリティの脆弱性につながる可能性があります。

非標準 ERC20 トークン (Tether USD など) では、多くの DeFi システムがトークン転送を実行する際に追加のライブラリ (SafeERC20 など) を使用して分岐動作に安全に対処する必要があります (たとえば、転送が成功した場合にリターンではなく何も返さないなど)。 true）。 これは、これらのトークンと対話するシステムは、システムが「返品の欠落」のケースを適切に処理するように設計されていない場合、脆弱になる可能性があることを意味します. これらのシナリオでは、一般的なセキュリティの落とし穴が発生する可能性があり、開発とメンテナンスの全体的なコストが増加する可能性があります (問題を軽減するために必要な追加のロジックと依存関係を考慮する場合)。 したがって、標準に準拠することは、個々の実装だけでなく、エコシステム全体のセキュリティにとっても重要です。 XNUMX つのシステムまたは依存関係の XNUMX つの脆弱性が、広範な問題を引き起こす可能性があります。

理想的には、標準はあいまいさなしに正式に指定されます (例: ERC20の正式仕様)、すべての実装は、標準仕様に対して正式に検証できます。 ただし、実際には、これを短期間で達成するのは容易ではありません。これは、コミュニティからのコストと労力が必要になるためです。

適合性の問題を特定するための実行可能なERC4626プロパティの導入 

理想的な状態 (厳格な形式仕様に対して正式に検証されたすべてのボールト) に向けて作業を進める中で、ERC4626 標準を作成しました。 プロパティ 標準要件の微妙で見逃しやすい詳細の不一致を検出します。  

Vault 開発者はテストを実行して、展開前に実装における潜在的な標準違反を検出できます。 また、ボールト インテグレーターは、システムにそれらを統合する前に、指定されたボールトが標準に準拠しているかどうかを確認できます。 プロパティは、メインネット フォーク テストを介して、メインネットに既にデプロイされているライブ コンテナーに対してテストすることもできます。 ライブ ボールトのテストは、特にボールトが最近展開またはアップグレードされた場合に、すべてのシステム パラメータが正しく設定されていることを確認するのに役立ちます。 

プロパティを実行可能 (つまりテスト可能) にするために、Foundry で記述され、そのファザーですぐに実行できるプロパティ ベースのテストを選択しました。 将来的には、指定されたボールトがすべての可能な入力と条件のプロパティを満たしていることを正式に検証するために、シンボリック実行またはモデル チェック ツールによって実行される可能性もあります。

プロパティは、さまざまなビジネス ロジックを実装するさまざまなボールトに適用できるように、十分に一般的なものとして記述しました。 実装の詳細に依存しないようにするために、パブリック インターフェイス関数のみを使用しました。 (ただし、この制限により、実装固有の内部データを参照する特定の標準要件がプロパティから省略されました。)

たとえば、次のプロパティは、 convertToShares() 関数、 "呼び出し元に応じてバリエーションを表示してはなりません」 XNUMX つのアカウント アドレスと金額を指定すると、各アカウントの呼び出しが行われます。 convertToShares() XNUMX つの戻り値が等しくなるようにします。 このプロパティは、実装の詳細とは無関係です convertToShares()、Vault によって異なり、ERC4626 を実装するすべての Vault によって満たされる必要があります。 このプロパティは、特定の入力値 (単体テスト用)、多数のランダム入力 (ファズ テスト用)、またはシンボリック値 (シンボリック実行とフォーマル検証用) を提供することによって実行できます。 また、ローカルで、またはメインネット フォークに対して (統合テスト用に) 実行することもできます。

ユース ケース: 丸め誤差をテストするプロパティ

たとえば、丸め誤差は、いくつかの系列に影響を与える可能性のある (一見マイナーな) バグの重要なクラスです。 ERC4626 の基礎となる会計ロジック (たとえば、鋳造される株式数や引き出される資産額の計算) は、固定小数点演算を使用して実装されます。丸め誤差は避けられません。 為に セキュリティただし、標準では、各インターフェイス関数の優先丸め方向が明示的に指定されていますが、エラーの範囲は指定されておらず、実装に依存しています。 具体的には、 deposit() & redeem() 関数は 下-正確な値の近似、一方で mint() & withdraw() 関数は が-近似。 たとえば、現在の株価 (つまり、2 株あたりの資産額) が XNUMX の場合、 deposit() 3 wei の資産では、最大 1 wei の株式のみを鋳造する必要があります (つまり、 floor(3/2)ながら、 withdraw() 資産が 3 ウェイの場合、少なくとも 2 ウェイの株式をバーンする必要があります (つまり、 ceil(3/2)).

丸め関連のプロパティは、ブラック ボックスとして扱うことで、基礎となる会計ロジックから独立するように記述しました。 具体的には、XNUMX つの相反する機能間の関係を記述する、いわゆる「往復」特性としてそれらを定式化しました。 たとえば、次のプロパティは、N 株の発行によってエスクローされたばかりの資産を引き出すには、N 株以上をバーンする必要があることを指定します。 換言すれば、鋳造と出金を繰り返して、資産と保管庫の共有を行ったり来たりして、無料で利益を上げることは誰にもできません。

実際、メインネット上のいくつかの ERC4626 Vault は、丸め誤差のために上記の特性を満たしていないことがわかりました。 これは、たとえば、単純に (そして繰り返し) 鋳造と引き出しを行い、ゆっくりと保管庫を空にすることで、誰でも数サトシ BTC (執筆時点で 1 サトシ ~= 0.02 セント) を獲得できることを意味します。 これは、非常に低いガス料金を享受するチェーン (Fantom など)、または資産価格が将来的に十分に高くなった場合に実際に利益をもたらす可能性があります。

ERC4626 標準を実際にテストする

メインネット上の最大 100 個の ERC4626 ボールトに対してプロパティをテストしたところ、標準要件に従わない多くのボールトが見つかりました。これは主に丸めエラーが原因です (たとえば、説明したように、上限が必要な場合にフロアの丸めを使用するなど)。 具体的には、特定のボールトは、サーバーによって要求された正確な数の共有を作成できませんでした。 mint() 関数、ただし標準では明示的に要求されています この. それらのいくつかはまた、一貫性のない Deposit ログに記録されたデータが実際に作成されたものと異なるイベント。 驚いたことに、一部のボールトはその場でまったく鋳造されませんでした。 代わりに、ミント リクエストをキューに入れ、後で別のトランザクションとしてバッチで処理します。

これらの多様な動作は、それ自体が悪用されることはありませんでしたが、標準的な動作のみを期待する他のシステムに統合されると、脆弱になる可能性があります。 これらの問題は、vault の統合をさらに困難にし、進行中の取り組みを無力化し、標準化の背後にある動機を促進する可能性があります。

当社のプロパティ テスト、および標準準拠に向けたその他の実行可能な手順の使用

標準に正確に従うことで、異なる動作を防ぐことができます (理想的には、展開される前に)。 いくつかの追加のアクション アイテムとともに、プロパティが役立つことを願っています。 ERC4626 ボールトの開発および/または統合を行っている人向け:

• 私たちは私たちのプロパティを実行することを強くお勧めします テスト あなたのボールトに対して。 標準に対する明確な違反がある場合、問題を迅速に発見します。
• また、 プロパティ 標準要件の理解度をクロスチェックし、意図しない矛盾がある場合は実装を調整します。
• ボールトが標準から逸脱する必要がある場合は、非標準の動作を明確に文書化することをお勧めします。これにより、他の人がボールトと統合するときにこれらの逸脱を適切に処理できるようになります。 これは最後の手段と考えてください。

***
ERC4626 Vault は、近い将来、DeFi の重要なビルディング ブロックになる可能性があります。また、構成可能性のために、新規および既存の Vault の両方が標準に従うことが重要です。 標準に従って新しい実装が登場するため、既存のボールトを標準化するのに今ほど適した時期はありません。 

理想的な状態 (さまざまなボールトが均一に構成可能) に向けて作業を進めるにつれて、ERC4626 プロパティ テストを実行して、ボールトの実装における標準違反をより簡単に検出できます。 プロパティ テスト (ドキュメントと例を含む) はすべて、Github で公開されています。 倉庫. フィードバックと貢献をお待ちしております。

***
ここに示されている見解は、引用された個々の AH Capital Management, LLC (「a16z」) の見解であり、a16z またはその関連会社の見解ではありません。 ここに含まれる特定の情報は、a16z が管理するファンドのポートフォリオ企業を含む第三者の情報源から入手したものです。 a16z は、信頼できると思われる情報源から取得したものですが、そのような情報を独自に検証しておらず、情報の現在または永続的な正確性、または特定の状況に対するその適切性について表明するものではありません。 さらに、このコンテンツにはサードパーティの広告が含まれる場合があります。 a16z はそのような広告を確認しておらず、そこに含まれる広告コンテンツを推奨していません。

このコンテンツは情報提供のみを目的として提供されており、法律、ビジネス、投資、または税務に関するアドバイスとして信頼されるべきではありません。 これらの問題については、ご自身のアドバイザーにご相談ください。 証券またはデジタル資産への言及は、説明のみを目的としたものであり、投資の推奨または投資顧問サービスの提供を構成するものではありません。 さらに、このコンテンツは、投資家または将来の投資家による使用を目的としたものではなく、a16zが管理するファンドへの投資を決定する際にいかなる状況においても信頼されない場合があります。 （a16zファンドへの投資の申し出は、私募覚書、サブスクリプション契約、およびそのようなファンドの他の関連文書によってのみ行われ、その全体を読む必要があります。）言及、参照、または記載されているのは、a16zが管理する車両へのすべての投資を代表するものではなく、投資が有益である、または将来行われる他の投資が同様の特性または結果をもたらすという保証はありません。 アンドリーセンホロウィッツが管理するファンドが行った投資のリスト（発行者がa16zに公開を許可していない投資、および公開されているデジタル資産への未発表の投資を除く）は、https：//a16z.com/investmentsで入手できます。 /。

内部で提供されているチャートとグラフは、情報提供のみを目的としており、投資決定を行う際に依存すべきではありません。 過去のパフォーマンスは、将来の結果を示すものではありません。 内容は、示された日付の時点でのみ話します。 これらの資料に記載されている予測、見積もり、予測、目標、見通し、および/または意見は、予告なしに変更される可能性があり、他の人が表明した意見とは異なるか、または反対である可能性があります。 その他の重要な情報については、https://a16z.com/disclosures を参照してください。