Uma監査–フェーズ6

概要

UMA は、ユーザーがイーサリアム ブロックチェーン上で信頼を最小限に抑えた金融契約を締結できるプラットフォームです。以前に監査を行った 分散型オラクル, 特定の金融契約テンプレート, いくつかのアドホックプルリクエスト, 無期限マルチパーティ テンプレート, 長期にわたるエンゲージメントにわたるさまざまな増分プル リクエスト & 保険をかけられた橋.

この監査では、新しいガバナンス提案契約、UMA エコシステムを複数のチェーンに拡張するメカニズム、オフチェーン仕様に従って ERC721 トークン所有者に報酬を分配するメカニズム、WETH をサポートするための保険付きブリッジの更新をレビューしました。楽観主義の連鎖に沿って。

監査されたコミットは次のとおりです 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc 範囲には次の契約が含まれます。

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (テスト契約およびポリゴン契約を除く)
• financial-templates/optimistic-rewarder/* （テスト契約を除く）

また、Solidity ファイルへの変更も確認しました。 プルリクエスト 3611.

すべての外部コードとコントラクトの依存関係は、文書化されているとおりに機能すると想定されていました。

システム概要

現在 Governance この契約により、Risk Labs Foundation は UMA トークン所有者が承認できる新しいガバナンス措置を提案することができます。新しい Proposer 契約は提案者の役割を担うことを目的としており、提案が失敗した場合に犠牲となる保証金を提供する限り、誰でも新しい提案を行うことができます。提案に対する特別なインセンティブはありません。その目的は、受け入れられる可能性が非常に高いアクションのみが提案されるようにすることです。

新しいクロスチェーンメカ​​ニズムにより、ガバナンス提案をイーサリアムメインネットからオプテ​​ィミズムチェーンとアービトラムチェーンに渡すことができます。このようにして、レイヤー 1 の UMA ガバナンス メカニズムを使用して、サポートされているレイヤー 2 チェーン上の UMA コントラクトを管理できます。このメカニズムでは、価格リクエストと解決策をレイヤー間で転送することもできるため、レイヤー 2 の Optimistic Oracle が DVM によって保護されるのと同じ方法で、レイヤー 1 チェーン上の Optimistic Oracle をメインネットのデータ検証メカニズムによって保護できます。

これらのメッセージはネイティブ ブリッジ メカニズムを使用して送信されることに注意してください。これは、メッセージが関連するレイヤー 2 チェーンの特性によって制限されることを意味します。特に、レイヤー 2 からレイヤー 1 へのメッセージがブリッジを通過するのに 2 週​​間以上かかる場合があります。さらに、UMA ガバナンス メカニズムは、複数の順序付けされたトランザクションを含むプロポーザルをサポートしますが、これはブリッジに追加できる順序を制限するだけです。これらのトランザクションの一部は、レイヤー XNUMX で異なる順序で実行されるか、まったく実行されない可能性があります。

Optimistic Rewarder コントラクトは、要求した人のために ERC721 トークンを発行するだけです。また、誰でも任意のデータを任意のトークンに関連付けることができ、報酬として配布するさまざまな ERC20 トークンを預けることができます。任意のデータの解釈とトークン所有者間での予想される報酬の分配は、不特定のオフチェーン手順を使用して決定されます。保証金を預ける意思があれば、誰でも特定の ERC721 トークンに一連の報酬を支払う義務があると主張することができます。標準の Optimistic Oracle メカニズムを使用して、他の人が申し立てに異議を申し立てることができ、DVM によって解決されます。期限までに争われなかった請求は有効であるとみなされ、契約によりそれに応じて報酬が分配されます。 (会計を簡素化するための) 唯一の制限は、Oracle Bond トークンを報酬トークンとして使用できないことです。

最後に、PR3611 は、サポートされていない Optimism トークン ブリッジを介して WETH が送信されるのを避けるために、保証されたブリッジ メカニズムを変更します。代わりに、Optimism 預けボックスに預けられた L2 WETH は、ブリッジを通過する前に L2 ETH にアンラップされます。レイヤ 1 では、ETH は WETH ブリッジ プールに転送される前に WETH に変換されます。

重大な重大度

[C01] 無効な報酬に異議を唱えることはできません

報酬の要求に異議を唱える場合、 OptimisticRewardBase まずは契約する プロポーズのきっかけとなる SkinnyOptimisticOracle その後 その提案に異議を唱える。ただし、その提案は、 有効期限を設定します 現在（紛争）時刻からのオフセットとして、紛争中 有効期限を指定します 元の報酬リクエストの時間からのオフセットとして。ほとんどの場合、この矛盾により、オラクルは異議の対象となる提案を特定できなくなります。つまり、有効な異議は処理されず、無効な報酬リクエストが受け入れられます。

異議申し立ての呼び出しを更新して、異議申し立ての対象となる提案を正しく指定することを検討してください。

アップデート： コミット時点で修正済み 9e15557 in PR3690-Reef.

[C02] 提案を繰り返し解決する

　 resolveProposal の機能 Proposer 縮小することはできません。 単純に検証する オラクルは解決しましたが、債券が分配されたかどうかはチェックしません。これは、同じ提案が複数回解決され、保証金の支払いが重複する可能性があることを意味します。既存の提案が解決されたら、フラグを立てるか削除することを検討してください。

アップデート： コミット時点で修正済み b152718 in PR3689-Reef.

重大度が高い

なし。

中程度の重大度

[M01] イベントパラメータが正しくありません

　 OptimisticRewarderBase 契約で定義されるのは、 Requested イベント から発せられるのは requestRedemption 償還が要求されたときに機能します。このイベントは、 引き換えの有効期限 最後のパラメータとして。しかし、 イベントが発行されるとき、最後のパラメータが誤って設定されています。 現在の時刻.

同様に、 Redeemed イベント はレコードが削除された後に有効期限を読み取るため、誤ってゼロに設定されます。

このイベントを使用してオフチェーン計算をトリガーできることを考慮して、発行された値を適切に更新することを検討してください。

アップデート： コミット時点で修正済み f04eef9 in PR3694-Reef.

重大度が低い

[L01] 償還に関する異議申し立て後のイベント発行の欠如

　 OptimisticRewarderBase 契約で定義されるのは、 Disputed イベント これは、償還が争われた場合に発動されることを目的としています。ただし、このイベントは内部または外部で発行されません。 OptimisticRewarderBase 契約する。

機密性の高い変更が行われた後にイベントを発行することを検討してください。 dispute function、追跡を容易にし、契約のアクティビティ後にオフチェーンクライアントに通知します。

アップデート： コミット時点で修正済み c275e92 in PR3695-Reef.

[L02] 一貫性のないリエントラント ガード

　 Optimism_ParentMessenger & Arbitrum_ParentMessenger 契約に一貫性のない適用がある nonReentrant 修飾子。すべての公開機能にこれを含めることを検討してください。

アップデート： コミット時点で修正済み 6275c39 in PR3677-Reef.

[L03] 誤解を招くコメント

以下に、レビュー中に特定した誤解を招くコメントをいくつか示します。

• ChildMessengerConsumerInterface.sol:
  • ライン5 「子メッセンジャー」ではなく「親メッセンジャー」と言う
• GovernorSpoke.sol:
  • 行49-51 へのリンク Gnosis コメントにはスニペットがコピーされたと書かれているにもかかわらず、 Governor.sol。さらに、スニペットは次のスニペットと同一ではありません。 Governor.sol

アップデート： コミット時点で修正済み cc350f9 in PR3678-Reef.

[L04] アンシラリーデータスタンプがありません

価格をリクエストするときは、 OracleSpoke 契約、提供された補助データ 刻印されています 子チェーン識別子を使用します。しかし hasPrice & getPrice 関数は、価格リクエストを識別するときに補助データをスタンプしません。これにより、呼び出し側コントラクト自体にスタンプを適用することが強制され、価格リクエストと価格取得メカニズムの間に不一致が生じます。にスタンプを適用することを検討してください。 hasPrice & getPrice 機能します。

アップデート： コミット時点で修正済み fdb845d in PR3668-Reef.

[L05] NatSpec パラメータがありません

の多くの機能 OptimisticRewarderBase 縮小することはできません。 が欠けています @return Natural 仕様のコメント内のパラメータ。完全を期すためにこれを含めることを検討してください。

アップデート： コミット時点で修正済み 8920f38 in PR3679-Reef.

[L06]残余引当金

楽観的なオラクルを呼び出すには、 OptimisticRewarderBase 縮小することはできません。 トークン許容量を付与します, したがって、債券の支払いを引き出すことができます。提案が失敗した場合、 特典引き換えはキャンセルされます ただし、許容量はリセットされません。したがって、オプティミスティック・オラクルは、次回紛争が引き起こされるまで、不必要な残存引当金を保持します。提案が不成立となった場合には、手当の取り消しを検討してください。

アップデート： コミット時点で修正済み c2d444b in PR3698-Reef.

[L07] 返金先住所が無効です

返金先の L2 アドレス Arbitrum_ParentMessenger 初期化されています 契約所有者 (L1 ガバナー) に送信します。同様に、 setRefundL2Address コメントがあります それは知事に設定されるべきであると述べています。ただし、ブリッジ経由でメッセージを渡す場合、この値は L2ユーザーとして設定、これは、チケットが解決された後に余剰資金を受け取る Arbitrum 上のアドレスです。 L1 ガバナーのアドレスは Arbitrum ではアクセスできなくなるため、このアドレスに送られた資金は失われます。

有効な L2 アドレスに設定することを検討してください。

アップデート： コミット時点で修正済み b3f2dd1 in PR3687-Reef.

[L08] 子メッセンジャーを変更する仕組み

　 GovernorSpoke & OracleSpoke コントラクトはそれぞれ、コンストラクターで子メッセンジャーを初期化しますが、それを更新するメカニズムはありません。これは、次のときを意味します。 子メッセンジャーが変更されました、両方のスポーク コントラクトが廃止されます。

スポーク コントラクトはメッセンジャーよりも安定している可能性が高いため、スポークにメッセンジャーを更新するメカニズムを組み込むことを検討してください。

アップデート： コミット時点で修正済み 7c9e061 in PR3688-Reef.

メモと追加情報

[N01] ボンドトークンの変更

　 Proposer 契約には以下が含まれます 仕組み 所有者がプロポーザル保証金のサイズを変更できるようにします。結合トークンも変更できるようにするかどうかを検討してください。これには、既存の提案が解決されるときに正しい債券通貨を識別するメカニズムが必要になることに注意してください。

アップデート： 問題ない。この問題に対するUMAの声明は以下の通り。

N01 では、提案者コントラクトでボンド トークンを UMA 以外のものに変更できるようにすることをお勧めします。この関数に対して $UMA 以外のトークンをサポートするつもりはないため、この問題に対しては変更を加えないことにしました。さらに、コントラクトごとに XNUMX つのトークンを使用することで、このロジックを可能な限りシンプルに保ちます。最後に、変更が必要な場合 (たとえば、トークンの移行の場合)、他のトークンを使用して新しいプロポーザー コントラクトをデプロイし、そのトークンを使用するようにシステムを移行する提案を開始するだけです。

[N02] 不完全なインターフェース

　 ChildMessengerInterface を指定しません processMessageFromCrossChainParent たとえ親メッセンジャーによって存在すると想定されていても、この関数は機能しません。完全を期すためにこれを含めることを検討してください。

アップデート： 未修理。この問題に対するUMAの声明は以下の通り。

他のチェーンからのメッセージを処理する Polygon のメソッドには、_processMessageFromRoot と呼ばれる内部メソッドが呼び出されるカスタム ロジックが必要であるため、ChildMessengerInterface 内でこれを実装すると Polygon_ChildMessenger との互換性が損なわれるため、意図的にこのインターフェイスを一貫性のないままにすることにしました。

[N03] インターフェースが正しくありません

　 GovernorSpoke 間違って契約する 使用 ChildMessengerConsumerInterface type それを説明する messenger 変数。の使用を検討してください。 ChildMessengerInterface を代わりにお使いください。

アップデート： コミット時点で修正済み f31a527 in PR3680-Reef.

[N04] トークンをストアにプルします

で 前回の監査 私たちはその目的に疑問を呈した Store 契約の payOracleFeesErc20 function （L19号掲載）。 UMAチーム 機能を維持することを選択した 将来の変更に備えてインターフェイスを標準化します。関数の目的が完全に指定されていないため、次の場合に関数をトリガーする必要があるかどうかは不明です。 Proposer 縮小することはできません。 保証金を没収する。おそらく次の場合に使用する必要があります。 OracleHub 価格要求に対して支払います。どちらのシナリオでも関数を使用する必要があるかどうかを検討してください。

アップデート： 了承しました。この問題に対するUMAの声明は以下の通り。

N04では、ストアの使用状況と一致するように、プロポーザ契約とOracleHub契約の両方で料金の支払いにストアのpayOracleFeeErc20メソッドを使用することを推奨します。この関数を使用しないことを選択しました。これは、(ストア用の) 追加のインターフェイスをインポートする必要があり、固定点へのボンド量のキャストが必要になることを意味するためです (追加のインポートも必要になります。コードをシンプルかつクリーンに保つため)。 20 年 1 月の監査フェーズ 2020 での payOracleFeeErcXNUMX に関する OZ のフィードバックは、この方法は実際には役に立たないというものであり、この種の統合を推論するのは難しくなりました。

[N05]コード内のTODO

コードベースには「TODO」コメントがあり、プロジェクトの問題バックログで追跡する必要があります。例えば：

• LINE 37 of Arbitrum_ParentMessenger 縮小することはできません。
• LINE 25 of Optimism_ChildMessenger 縮小することはできません。
• ラインズ 83 & 146 of OracleHub 契約する。

開発中に「TODO」コメントを明確に説明すると、コメントの追跡と解決のプロセスが容易になります。その情報がなければ、これらのコメントは腐りがちになり、システムのセキュリティに関する重要な情報が実稼働環境にリリースされるまでに忘れられてしまう可能性があります。

これらの TODO コメントには、実行が保留されているタスクの簡単な説明と、プロジェクト リポジトリ内の対応する問題へのリンクが含まれている必要があります。

この情報を追加するには、TODO コメントを更新することを検討してください。完全性と追跡可能性を確保するために、署名とタイムスタンプを追加できます。例えば：

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

アップデート： コミット時点で修正済み 5d57b5b in PR3684-Reef.

[N06]誤植

コードベースには次のタイプミスが含まれています。

• Admin_ChildMessenger 契約する、 impleenting でなければなりません implementing
• OptimisticRewarderBase 契約する、 timestap でなければなりません timestamp.
• OptimisticRewarderBase 契約する、 liveness liveness でなければなりません liveness.
• GovernorSpoke 契約する、 only called でなければなりません only be called.
• Optimism_ChildMessenger 契約する：

アップデート： コミット時点で修正済み 9b92b0b in PR3681-Reef.

【N07】輸入未使用品

コードの読みやすさを向上させるために、次の未使用のインポートを削除することを検討してください。

アップデート： コミット時点で修正済み 40b7221 in PR3682-Reef.

[N08] L2トランザクションの順序付け

　 Governor 確実に プロポーザル内のトランザクションは順番に実行されます。ただし、それらのトランザクションにクロスチェーン トランザクションが含まれる場合、これはトランザクションが正しい順序で L1 ブリッジ コントラクトに到着することを保証するだけです。 Arbitrum の場合、L2 で最終決定される前に並べ替えられる可能性があります。したがって、ガバナンス提案は、再順序付けされた L2 トランザクションの可能性を許可するように構築される必要があります。

アップデート： コミット時点で修正済み 0fb2e7b in PR3703-Reefを選択します。 GovernorHub 一連の L2 トランザクションを中継できるようになりました。

まとめ

コードベースで 2 つの重大な問題が見つかりました。重大度が中程度の問題が 1 つと、軽微な脆弱性がいくつか見つかり、修正の推奨事項が提案されています。

出典：https：//blog.openzeppelin.com/uma-audit-phase-6/？utm_source = rss＆utm_medium = rss＆utm_campaign = uma-audit-phase-6