Uma-Audit – Phase 6

Einleitung

UMA ist eine Plattform, die es Benutzern ermöglicht, vertrauensminimierte Finanzverträge auf der Ethereum-Blockchain abzuschließen. Wir haben vorher auditiert Das dezentrale Orakel, eine bestimmte Finanzvertragsvorlage, einige Ad-hoc-Pull-Requests, die Perpetual Multiparty-Vorlage, verschiedene inkrementelle Pull-Requests über einen längeren Zeitraum und die versicherte Brücke.

In dieser Prüfung haben wir einen neuen Governance-Vorschlagsvertrag, einen Mechanismus zur Erweiterung des UMA-Ökosystems über mehrere Chains, einen Mechanismus zur Verteilung von Belohnungen an ERC721-Token-Inhaber gemäß einer Off-Chain-Spezifikation und eine Aktualisierung der versicherten Bridge zur Unterstützung von WETH überprüft auf der Optimismus-Kette.

Das geprüfte Commit ist 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc und der Geltungsbereich umfasst die folgenden Verträge:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (ausgenommen Test- und Polygonverträge)
• financial-templates/optimistic-rewarder/* (ausgenommen Testverträge)

Wir haben auch die Änderungen an Solidity-Dateien in überprüft Pull-Request 3611.

Es wurde angenommen, dass alle externen Code- und Vertragsabhängigkeiten wie dokumentiert funktionieren.

Systemübersicht

Die aktuelle Governance Der Vertrag ermöglicht es der Risk Labs Foundation, neue Governance-Maßnahmen vorzuschlagen, die von den UMA-Token-Inhabern ratifiziert werden können. Das neue Proposer Der Vertrag soll die Rolle des Vorschlagenden übernehmen und es jedem ermöglichen, neue Vorschläge zu machen, solange er eine Bindung bietet, die geopfert wird, wenn der Vorschlag fehlschlägt. Es gibt keinen besonderen Anreiz, Vorschläge zu machen. Es soll sichergestellt werden, dass nur die Maßnahmen vorgeschlagen werden, die mit hoher Wahrscheinlichkeit akzeptiert werden.

Der neue Cross-Chain-Mechanismus ermöglicht es, Governance-Vorschläge vom Ethereum-Mainnet an die Optimism- und Arbitrum-Chains weiterzugeben. Auf diese Weise kann der UMA-Governance-Mechanismus auf Layer 1 verwendet werden, um UMA-Verträge auf den unterstützten Layer-2-Ketten zu steuern. Der Mechanismus ermöglicht auch die Weiterleitung von Preisanfragen und Auflösungen zwischen den Schichten, sodass optimistische Orakel auf den Layer-2-Ketten durch den Mainnet-Datenverifizierungsmechanismus auf die gleiche Weise gesichert werden können, wie das optimistische Orakel auf Layer 1 durch die DVM gesichert wird.

Es ist erwähnenswert, dass diese Nachrichten unter Verwendung der nativen Bridge-Mechanik gesendet werden, was bedeutet, dass sie durch die Eigenschaften der relevanten Layer-2-Ketten begrenzt sind. Insbesondere die Nachrichten von Schicht 2 zu Schicht 1 könnten eine Woche oder länger brauchen, um die Brücke zu passieren. Darüber hinaus unterstützt der UMA-Governance-Mechanismus Vorschläge, die mehrere geordnete Transaktionen enthalten, aber dies schränkt lediglich die Reihenfolge ein, in der sie der Brücke hinzugefügt werden können. Es ist möglich, dass einige dieser Transaktionen auf Schicht 2 in einer anderen Reihenfolge oder gar nicht ausgeführt werden.

Der Optimistic Rewarder-Vertrag prägt einfach ERC721-Token für jeden, der sie anfordert. Es erlaubt auch jedem, beliebige Daten mit jedem Token zu verknüpfen und verschiedene ERC20-Token zu hinterlegen, die als Belohnungen verteilt werden. Die Interpretation der willkürlichen Daten und die erwartete Verteilung der Belohnungen unter den Token-Inhabern werden mithilfe eines nicht spezifizierten Off-Chain-Verfahrens bestimmt. Jeder kann behaupten, dass einem bestimmten ERC721-Token eine Reihe von Belohnungen geschuldet wird, wenn er bereit ist, eine Anleihe zu hinterlegen. Der Standardmechanismus von Optimistic Oracle wird verwendet, um es jemand anderem zu ermöglichen, den Anspruch anzufechten, der von der DVM gelöst wird. Nicht rechtzeitig bestrittene Ansprüche werden als gültig angenommen, und der Vertrag verteilt die Belohnungen entsprechend. Die einzige Einschränkung (um die Buchhaltung zu vereinfachen) besteht darin, dass der Oracle-Bond-Token nicht als Belohnungstoken verwendet werden kann.

Schließlich modifiziert PR3611 den versicherten Bridge-Mechanismus, um zu vermeiden, dass WETH über die Optimism-Token-Bridge gesendet wird, was nicht unterstützt wird. Stattdessen wird jedes L2 WETH, das in der Optimism-Depositbox deponiert wird, in L2 ETH ausgepackt, bevor es die Brücke passiert. Auf Schicht 1 wird die ETH in WETH konvertiert, bevor sie an den WETH-Bridge-Pool weitergeleitet wird.

Kritische Schwere

[C01] Ungültige Prämie kann nicht angefochten werden

Bei der Anfechtung einer Prämienanfrage wird die OptimisticRewardBase Vertrag zuerst löst einen Vorschlag aus auf die SkinnyOptimisticOracle und dann bestreitet diesen Vorschlag. Allerdings der Vorschlag legt die Ablaufzeit fest als Ausgleich von der aktuellen (Streit-)Zeit, während der Streit legt das Ablaufdatum fest als Ausgleich zum Zeitpunkt der ursprünglichen Belohnungsanfrage. In den meisten Fällen hindert diese Diskrepanz das Orakel daran, den anzufechtenden Vorschlag zu identifizieren, was bedeutet, dass gültige Anfechtungen nicht bearbeitet und ungültige Belohnungsanfragen akzeptiert werden.

Erwägen Sie, die Aufforderung zur Anfechtung zu aktualisieren, um den anzufechtenden Vorschlag korrekt anzugeben.

Update: Behoben ab Commit 9e15557 in PR3690.

[C02] Vorschläge wiederholt lösen

Das resolveProposal Funktion des Proposer Vertrag bestätigt einfach dass das Orakel aufgelöst hat, prüft aber nicht, ob die Anleihe verteilt wurde. Dies bedeutet, dass derselbe Vorschlag mehrmals gelöst werden kann, was zu doppelten Kautionszahlungen führt. Erwägen Sie, vorhandene Vorschläge zu kennzeichnen oder zu löschen, wenn sie gelöst sind.

Update: Behoben ab Commit b152718 in PR3689.

Hoher Schweregrad

Keiner.

Mittlere Schwere

[M01] Falsche Ereignisparameter

Das OptimisticRewarderBase Vertrag definiert a Requested Event die von der emittiert wird requestRedemption Funktion, wenn eine Einlösung angefordert wird. Dieses Ereignis ist so definiert, dass es die ausgibt Ablaufzeit der Rückzahlung als letzten Parameter. Jedoch, wenn das Ereignis ausgegeben wird, sein letzter Parameter ist fälschlicherweise auf gesetzt aktuelle Uhrzeit.

Ebenso die Redeemed Event liest die Ablaufzeit, nachdem der Datensatz gelöscht wurde, sodass sie fälschlicherweise auf Null gesetzt wird.

Da dieses Ereignis zum Auslösen von Off-Chain-Berechnungen verwendet werden kann, sollten Sie den ausgegebenen Wert entsprechend aktualisieren.

Update: Behoben ab Commit f04eef9 in PR3694.

Geringe Schwere

[L01] Fehlende Emission von Ereignissen nach Anfechtung einer Einlösung

Das OptimisticRewarderBase Vertrag definiert a Disputed Event die ausgelöst werden soll, wenn eine Rückzahlung bestritten wird. Dieses Ereignis wird jedoch nicht innerhalb oder außerhalb von ausgegeben OptimisticRewarderBase Vertrag.

Erwägen Sie, das Ereignis auszusenden, nachdem vertrauliche Änderungen in der vorgenommen wurden dispute Funktion, um die Nachverfolgung zu erleichtern und Kunden außerhalb der Kette über die Aktivität der Verträge zu informieren.

Update: Behoben ab Commit c275e92 in PR3695.

[L02] Inkonsistente Wiedereintrittsüberwachung

Das Optimism_ParentMessenger und Arbitrum_ParentMessenger Verträge gelten uneinheitlich nonReentrant Modifikator. Erwägen Sie, es bei allen öffentlichen Funktionen einzubeziehen.

Update: Behoben ab Commit 6275c39 in PR3677.

[L03] Irreführende Kommentare

Hier sind einige irreführende Kommentare, die wir während unserer Überprüfung identifiziert haben:

• ChildMessengerConsumerInterface.sol:
  • Linie 5 sagt „Eltern-Messenger“ statt „Kinder-Messenger“
• GovernorSpoke.sol:
  • Zeilen 49-51 Links zu a Gnosis Datei, obwohl der Kommentar besagt, dass das Snippet kopiert wurde Governor.sol. Außerdem ist das Snippet nicht identisch mit dem in Governor.sol

Update: Behoben ab Commit cc350f9 in PR3678.

[L04] Fehlender Zusatzdatenstempel

Bei einer Preisanfrage auf der OracleSpoke Vertrag, die bereitgestellten Nebendaten ist gestempelt mit der untergeordneten Kettenkennung. Allerdings ist die hasPrice und getPrice Funktionen stempeln die Zusatzdaten bei der Identifizierung der Preisanfrage nicht. Dies zwingt aufrufende Verträge dazu, den Stempel selbst anzubringen, was zu einer Inkonsistenz zwischen der Preisanforderung und den Preisabrufmechanismen führt. Erwägen Sie, den Stempel in der anzuwenden hasPrice und getPrice Funktionen.

Update: Behoben ab Commit fdb845d in PR3668.

[L05] Fehlender NatSpec-Parameter

Viele Funktionen im OptimisticRewarderBase Vertrag fehlen die @return -Parameter in ihren Natural-Spezifikationskommentaren. Erwägen Sie es der Vollständigkeit halber.

Update: Behoben ab Commit 8920f38 in PR3679.

[L06] Restbetrag

Um das optimistische Orakel anzurufen, muss die OptimisticRewarderBase Vertrag gewährt ihm eine Token-Zulage, damit es die Anleihezahlungen ziehen kann. Wenn der Vorschlag scheitert, Die Prämieneinlösung wird storniert aber die Zulage wird nicht zurückgesetzt. Daher behält das optimistische Orakel einen unnötigen Restbetrag ein, bis das nächste Mal ein Streit ausgelöst wird. Erwägen Sie, die Genehmigung zu widerrufen, wenn der Vorschlag fehlschlägt.

Update: Behoben ab Commit c2d444b in PR3698.

[L07] Ungültige Rückerstattungsadresse

Die Rückerstattungs-L2-Adresse der Arbitrum_ParentMessenger wird initialisiert an den Vertragseigentümer, der der L1-Governor sein sollte. Ebenso die setRefundL2Address hat einen Kommentar besagt, dass es an den Gouverneur eingestellt werden sollte. Wenn jedoch Nachrichten über die Brücke geleitet werden, ist dieser Wert als L2-Benutzer festgelegt, das ist die Adresse auf Arbitrum, die überschüssige Gelder erhält, nachdem das Ticket gelöst wurde. Da die Adresse des L1-Governors auf Arbitrum nicht zugänglich ist, gehen alle an diese Adresse gesendeten Gelder verloren.

Erwägen Sie die Einstellung auf eine gültige L2-Adresse.

Update: Behoben ab Commit b3f2dd1 in PR3687.

[L08] Mechanismus zum Ändern von untergeordneten Boten

Das GovernorSpoke und OracleSpoke Vertrag jeweils den untergeordneten Messenger im Konstruktor initialisieren, ohne dass es einen Mechanismus gibt, um ihn zu aktualisieren. Das bedeutet, wenn die Kind-Messenger wird geändert, werden beide Speichenverträge hinfällig.

Da der Spoke-Vertrag wahrscheinlich stabiler ist als die Messenger, sollten Sie einen Mechanismus zum Aktualisieren des Messengers auf den Spokes einbeziehen.

Update: Behoben ab Commit 7c9e061 in PR3688.

Hinweise und zusätzliche Informationen

[N01] Bindungstoken ändern

Das Proposer Vertrag beinhaltet ein Mechanismus für den Eigentümer, die Größe der Vorschlagsanleihe zu ändern. Überlegen Sie, ob sie auch in der Lage sein sollten, den Bond-Token zu ändern. Beachten Sie, dass dies einen Mechanismus erfordern würde, um die korrekte Anleihewährung zu identifizieren, wenn bestehende Vorschläge beschlossen werden.

Update: Kein Problem. UMAs Erklärung zu dieser Ausgabe:

N01 empfiehlt, dem Proposer-Vertrag zu ermöglichen, den Bond-Token in etwas anderes als UMA zu ändern. Wir haben nicht die Absicht, andere Token als $UMA für diese Funktion zu unterstützen, und haben uns daher entschieden, keine Änderungen für dieses Problem vorzunehmen. Darüber hinaus hält ein einziger Token pro Vertrag diese Logik so einfach wie möglich. Wenn schließlich eine Änderung erforderlich wäre (z. B. im Fall einer Token-Migration), könnten wir einfach einen neuen Proposer-Vertrag mit dem anderen Token bereitstellen und einen Vorschlag zur Migration des Systems zur Verwendung dieses Tokens initiieren.

[N02] Unvollständige Schnittstelle

Das ChildMessengerInterface gibt kein a an processMessageFromCrossChainParent funktionieren, obwohl sie von übergeordneten Messengern angenommen wird. Erwägen Sie es der Vollständigkeit halber.

Update: Nicht behoben. UMAs Erklärung zu dieser Ausgabe:

Wir haben uns bewusst dafür entschieden, diese Schnittstelle inkonsistent zu lassen, da die Implementierung innerhalb der ChildMessengerInterface die Kompatibilität mit Polygon_ChildMessenger unterbricht, da die Methode von Polygon zum Verarbeiten von Nachrichten aus anderen Ketten eine etwas benutzerdefinierte Logik erfordert, bei der eine interne Methode mit dem Namen _processMessageFromRoot aufgerufen wird.

[N03] Falsche Schnittstelle

Das GovernorSpoke Vertrag falsch verwendet das ChildMessengerConsumerInterface tippe seine zu beschreiben messenger Variable. Erwägen Sie die Verwendung von ChildMessengerInterface stattdessen.

Update: Behoben ab Commit f31a527 in PR3680.

[N04] Tokens zum Laden ziehen

In einer vorherige Prüfung Wir hinterfragten den Zweck der Store Vertrag payOracleFeesErc20 Funktion (in Ausgabe L19). Das UMA-Team entschieden, die Funktion beizubehalten die Schnittstelle für mögliche zukünftige Modifikationen zu standardisieren. Da der Zweck der Funktion nicht vollständig spezifiziert ist, ist unklar, ob sie wann ausgelöst werden soll Proposer Vertrag beschlagnahmt eine Anleihe. Es sollte wahrscheinlich verwendet werden, wenn die OracleHub zahlt für eine Preisanfrage. Überlegen Sie, ob die Funktion in beiden Szenarien verwendet werden sollte.

Update: Anerkannt. UMAs Erklärung zu dieser Ausgabe:

N04 empfiehlt die Verwendung der payOracleFeeErc20-Methode des Stores zur Zahlung von Gebühren sowohl in den Proposer- als auch in den OracleHub-Verträgen, um mit der Store-Nutzung konsistent zu sein. Wir haben uns entschieden, diese Funktion nicht zu verwenden, da dies bedeuten würde, dass eine zusätzliche Schnittstelle (für das Geschäft) importiert werden müsste und der Bindungsbetrag in einen FixedPoint umgewandelt werden müsste (was auch einen zusätzlichen Import erfordern würde). Um den Code einfach und sauber zu halten Wir haben uns entschieden, dies nicht zu tun.Das OZ-Feedback zu payOracleFeeErc20 in Auditphase 1 im April 2020 war gültig, dass diese Methode nicht wirklich nützlich ist, was es schwieriger macht, über diese Art der Integration nachzudenken.

[N05] TODOs im Code

Es gibt „TODO“-Kommentare in der Codebasis, die im Problemrückstand des Projekts nachverfolgt werden sollten. Zum Beispiel:

• Line 37 of Arbitrum_ParentMessenger Vertrag
• Line 25 of Optimism_ChildMessenger Vertrag
• Linien 83 und 146 of OracleHub Vertrag.

Wenn Sie während der Entwicklung gut beschriebene „TODO“-Kommentare haben, wird der Prozess der Verfolgung und Lösung einfacher. Ohne diese Informationen könnten diese Kommentare verrotten und wichtige Informationen für die Sicherheit des Systems könnten vergessen werden, wenn es für die Produktion freigegeben wird.

Diese TODO-Kommentare sollten eine kurze Beschreibung der anstehenden Aufgabe und einen Link zum entsprechenden Problem im Projekt-Repository enthalten.

Erwägen Sie, die TODO-Kommentare zu aktualisieren, um diese Informationen hinzuzufügen. Zur Vollständigkeit und Nachvollziehbarkeit können eine Signatur und ein Zeitstempel hinzugefügt werden. Zum Beispiel:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Update: Behoben ab Commit 5d57b5b in PR3684.

[N06] Tippfehler

Die Codebasis enthält die folgenden Tippfehler:

• Im Admin_ChildMessenger Vertrag, impleenting sollte sein implementing
• Im OptimisticRewarderBase Vertrag, timestap sollte sein timestamp.
• Im OptimisticRewarderBase Vertrag, liveness liveness sollte sein liveness.
• Im GovernorSpoke Vertrag, only called sollte sein only be called.
• Im Optimism_ChildMessenger Vertrag:

Update: Behoben ab Commit 9b92b0b in PR3681.

[N07] Ungenutzte Importe

Um die Lesbarkeit des Codes zu verbessern, sollten Sie die folgenden nicht verwendeten Importe entfernen:

Update: Behoben ab Commit 40b7221 in PR3682.

[N08] L2-Transaktionsreihenfolge

Das Governor sorgt Transaktionen innerhalb eines Angebots werden der Reihe nach ausgeführt. Wenn es sich bei diesen Transaktionen jedoch um Cross-Chain-Transaktionen handelt, garantiert dies lediglich, dass sie in der richtigen Reihenfolge beim L1-Brückenvertrag ankommen. Im Arbitrum-Fall können sie neu geordnet werden, bevor sie auf L2 abgeschlossen werden. Daher sollten Governance-Vorschläge erstellt werden, um die Möglichkeit neu geordneter L2-Transaktionen zu ermöglichen.

Update: Behoben ab Commit 0fb2e7b in PR3703dem „Vermischten Geschmack“. Seine GovernorHub kann jetzt ein Array von L2-Transaktionen weiterleiten.

Zusammenfassung

In der Codebasis wurden zwei kritische Probleme gefunden. Es wurden ein Problem mit mittlerem Schweregrad und mehrere kleinere Sicherheitslücken gefunden, und es wurden Empfehlungen für Korrekturen vorgeschlagen.

Quelle: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6