1. Dezember 2021
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 und verschiedene inkrementelle Pull-Requests über einen längeren Zeitraum. In diesem Audit haben wir einen neuen Mechanismus zum schnellen Senden von Token von einer Layer-2-Kette an das Ethereum-Mainnet und damit verbundene Änderungen am optimistischen Orakel überprüft. Die Überprüfung wurde von 2 Auditoren über 3 Wochen durchgeführt.
Geltungsbereich
Das geprüfte Commit ist f24ad501c8e813cf685f72217e7f13c8f3c366df
und der Geltungsbereich umfasst die folgenden Verträge:
- Verträge/Insured-Bridge/* (ohne Testverträge)
- verträge-ovm/versicherte-brücke/implementierung/*
- Contracts/common/implementation/AncillaryData.sol
- Contracts/Oracle/Implementation/SkinnyOptimisticOracle.sol
Wir haben auch die Änderungen an Solidity-Dateien in überprüft Pull-Request 3445.
Es wurde angenommen, dass alle externen Code- und Vertragsabhängigkeiten wie dokumentiert funktionieren.
Systemübersicht
Die unterstützten Layer-2-Ketten (L2), Optimism und Arbitrum, bieten einen Mechanismus zur Überweisung von Geldern an das Ethereum-Mainnet (L1). Aus Sicherheitsgründen gibt es jedoch eine erhebliche Verzögerung, bevor diese Übertragungen abgeschlossen sind. Um dies zu beheben, können L2-Token-Inhaber Gelder in einen UMA-Vertrag, die Deposit Box, einzahlen, in dem Wissen, dass die Token schließlich (als Stapel) in einen L1-UMA-Vertrag, den Bridge Pool, übertragen werden. Für jeden zu übertragenden Token gibt es einen eigenen Bridge Pool.
Nach einer L2-Einzahlung kann jeder die Details an den L1 Bridge Pool weiterleiten, der eine kurze Zeit wartet, falls jemand die weitergeleiteten Informationen anfechten möchte. Alle Streitigkeiten werden vom Skinny Optimistic Oracle (unten beschrieben) behandelt. Vor der Annahme des Relais müssen Liquiditätsanbieter den Bridge-Pool-Vertrag im Austausch gegen LP-Token vorfinanzieren. Unbestrittene Weiterleitungen werden als gültig angenommen, und der Bridge-Pool schließt die Übertragung unter Verwendung seiner eigenen Reserven ab, wobei ein Bruchteil der Übertragung an den Weitervermittler umgeleitet wird und ein Bruchteil als Liquiditätsgebühren einbehalten wird. Die Mittel werden schließlich wieder aufgefüllt, wenn die L2-Einzahlung abgeschlossen ist, und die Liquiditätsgebühren werden den LP-Token-Inhabern zugewiesen.
Der Bridge-Pool ermöglicht es auch jedem, einen Transfer (ohne die Bridge-Pool-Reserven) vor Ablauf der Anfechtungsfrist gegen einen Bruchteil des Transferbetrags individuell zu finanzieren. Da die Weiterleitung immer noch angefochten werden kann, würden diese Gelder verloren gehen, wenn die Weiterleitung als falsch erachtet würde. Es wird erwartet, dass dieser Mechanismus es den Benutzern in den meisten Fällen ermöglicht, sofortige L2-zu-L1-Token-Übertragungen zu erleben.
Das Skinny Optimistic Oracle ist dem bestehenden Optimistic Oracle konzeptionell sehr ähnlich. Es bietet Benutzern einen Anreizmechanismus, einfach das Ergebnis einer Orakelanfrage zu bestätigen, von der angenommen wird, dass sie korrekt ist, wenn sie nicht bestritten wird. Streitigkeiten werden an den langsameren DVM-Mechanismus verwiesen, der in unseren vorherigen Prüfberichten beschrieben wurde. Der Hauptunterschied besteht darin, dass die Benutzer in der neuen Version beim Ausführen von Funktionsaufrufen alle relevanten Informationen angeben müssen, sodass die Werte nicht gespeichert oder aus dem Speicher abgerufen werden müssen. Es entfernt auch die Möglichkeit für Anforderer, Konfigurationsparameter in aktiven Anforderungen zu ändern.
Wir haben zuvor den Long-Short-Pair-Vertrag überprüft, der einen allgemeinen Mechanismus zur Erstellung verschiedener Finanzinstrumente bietet. Diese Kontrakte können aufgelöst werden, wenn ihre Ablaufzeit erreicht ist und der Abrechnungspreis bekannt ist. Die durch Pull Request 3445 eingeführten Änderungen führen die Möglichkeit ein, die Kontrakte vorzeitig aufzulösen, wenn der Abrechnungspreis vor der Ablaufzeit bekannt ist.
Privilegierte Rollen
Die L2-Einzahlungsboxen haben mehrere Konfigurationsparameter, einschließlich der unterstützten Token und der maximalen Rate für das Senden von gestapelten Token über die Bridge an L1. Sie müssen auch konfiguriert werden, um die Konsistenz zwischen dem L1-Token-Vertrag, dem L2-Token-Vertrag und dem entsprechenden Bridge-Pool zu gewährleisten. Diese Parameter werden durch einen Administratorvertrag auf L1 festgelegt, der auch den Streitbeilegungsprozess der Bridge-Pools parametrisiert. Es wird erwartet, dass der Vertrag vom UMA-Governance-Mechanismus kontrolliert wird, sodass die Benutzer diesem Prozess vertrauen müssen, um das System vernünftig und fair zu verwalten.
Ökosystemabhängigkeiten
Alle überprüften Komponenten verwenden eine zeitbasierte Logik, was bedeutet, dass sie von der Verfügbarkeit von Ethereum abhängen. Insbesondere wenn strittige Transaktionen erheblich verzögert werden, können ungültige Weiterleitungen oder Preisvorschläge fälschlicherweise bestätigt werden.
Darüber hinaus geht die Token-Bridge implizit davon aus, dass alle Gelder, die an L2-Depositboxen gesendet werden, schließlich an den entsprechenden L1-Bridge-Pool übertragen werden. Dies hängt vom korrekten und fortgesetzten Funktionieren der Optimismus- und Arbitrum-Brücken und ihrer Streitbeilegungsmechanismen ab.
Schließlich werden Token, die an das L2-Depositfach gesendet werden, dem Bridge-Pool in L1 zugewiesen, nicht dem beabsichtigten Empfänger. Um die Gelder aus dem Pool abzurufen, müssen L1-Token-Inhaber sie zuerst mit zusätzlichen Token abgleichen. Daher stützt sich der Mechanismus auf einen ausreichend tiefen Markt von L1-Token, um sicherzustellen, dass immer Liquidität vorhanden ist.
Von Kunden gemeldete Probleme
Während des Audits identifizierte das UMA-Team unabhängig eine Reihe von Problemen und Verhaltensweisen, die es wert sind, hervorgehoben zu werden:
Wenn sich die Optimistic Oracle- oder Bridge Admin-Parameter während der Challenge-Periode eines Relays ändern, wird das Relay durch das Anfechten des Relays gelöscht, ohne dass der Proposer oder der Disputer weitere Rückgriffe nehmen muss. Stellen Sie sich zum Beispiel vor, dass das Relay für das Collateral-Token gesendet wird
TOKEN_A
, aber in der Mitte der StaffelTOKEN_A
wird von der Whitelist für Sicherheiten entfernt. Ein Streitfall wird nun zurückgesetzt, da Sie keine Preisanfragen an den OO oder DVM für nicht auf der weißen Liste stehende Sicherheiten stellen können. Da wir gültige Einspruchsanfragen nicht blockieren möchten, wird dieBridgePool
löscht die anstehende Weiterleitung fürTOKEN_A
im Streitfall. Die Konsequenzen dieser Designentscheidung sind:
1. Eine Erhöhung der endgültigen Gebühr bewirkt: Jede ausstehende Weiterleitung auf diesem Token kann durch Streitigkeiten, ob richtig oder falsch, „storniert“ werden. Eine Stornierung ist für keine der Parteien von Vorteil, daher wird davon ausgegangen, dass es ehrliche Streiter gibt, die bereit sind, die (seltene) schlechte Anfrage, die zufällig während einer endgültigen Gebührenänderungsausführung besteht, zu töten. Das bedeutet auch, dass es für einen Griefer möglich ist, Benzin auszugeben, um Staffeln abzubrechen und eine erneute Staffelung zu erzwingen.
2. Ein De-Whitelisting der Kennung oder des Tokens, das nicht passieren sollte, es sei denn, etwas geht sehr schief, würde Folgendes bewirken:
3. Ein längerer Zeitraum unbestreitbarer Anfragen, in denen jede Anfrage storniert werden kann und es keine wirtschaftlichen Anreize für eine Anfechtung gibt. Dies scheint besser zu sein als die Alternative, Streitigkeiten vollständig zu blockieren, aber es ist zugegebenermaßen ziemlich schlecht, da jeder Griefer Staffeln auf unbestimmte Zeit blockieren kann, indem er Gas bezahlt, oder schlechte Staffeln ohne Strafe (außer Gasgebühren) senden kann.Hinweis: Dies ist eine Alternative dazu, dass der OO Parameter wie die endgültige Gebühr oder die Sicherheiten-Whitelist für einige Zeit „einfriert“, aber dies würde zusätzliche Anrufe beim OO erfordern, was für den glücklichen Pfad kostspielig wäre.
Relais können über beschleunigt werden
speedUpRelay()
nachdem sie die Lebendigkeit überschritten haben. Obwohl wir darin kein Risiko sehen, eröffnet es die Möglichkeit für Flash-Darlehen + Beschleunigung + Abwicklung nach Liveness, wodurch der Flash-Darlehensnehmer die sofortige Staffelgebühr „kostenlos“ erhält. Wir verhindern dies in diesem Vorschlag PR.
On
settle
Wenn dieBridgePool
ist eineWETH
Pool und der Empfänger ist ein Vertrag, der nicht istpayable
(kann ETH nicht akzeptieren), dannsettle
wird versagen. Wir planen, dies zu beheben und auf das Senden zurückzugreifenWETH
, aber dazu gibt es noch keine herausragenden Arbeiten.
In
relayDeposit
, wir prüfen, ob dieBridgePool
Das Guthaben von ist größer als der zu überweisende Betrag PLUS die Anbieteranleihe. Dies ist eine veraltete Überprüfung und zu konservativ, da der Vorschlager-Bond dem Benutzer nach der Überprüfung entzogen wird. Darauf gehen wir in diesem Vorschlag ein PR.
Ich habe gerade einen Fehler entdeckt, wo
chainId
inBridgePool
, enthalten als Teil derDeposit
struct und als Funktionseingang für alle relaisbezogenen Funktionen (dhrelayDeposit
,speedUpRelay
,settle
) ist Typuint8
. Dies ist ein zu kleiner Typ, um beispielsweise Arbitrum mit der ID 421611 zu handhaben. Wir haben diesen Fehler tatsächlich entdeckt und auf der L2-Seite behoben:BridgeDeposit
hat seine eingestelltchainId
tippen Sie aufuint256
. Diese PR wird das machenchainId
onBridgePool
stimmen mit dem Typ übereinBridgeDepositBox
: UMA-Protokoll/Protokoll Nr. 3463
Bisher zog die Dispute-Funktion den Einzahlungsbetrag nicht ab
pendingReserves
(Dies ist die Variable, die verfolgt, wie viel des Reservepools aufgrund von Relais, die noch nicht abgerechnet wurden, gesperrt ist). Das Ergebnis war, dass jeder Streit den Staffelbetrag auf unbestimmte Zeit im Pool sperren würde. Es kann nicht von LPs zurückgezogen oder von zukünftigen Staffeln verwendet werden. Fix ist hier: UMA-Protokoll/Protokoll Nr. 3473.
Wir haben einen Fehler darin gefunden
BridgeDepositBox
woherhasEnoughTimeElapsedToBridge
prüft nicht, ob auint256
Wert ist gleich0
standardmäßig: Behoben in PR 3484
Die Wechselkursmethode (die zustandsmodifizierend ist) wird zwischen Tokens, die hinein übertragen werden, und LP-Tokens, die in der addLiquidity-Methode des Bridge-Pool-Vertrags geprägt werden, aufgerufen. Diese Berechnung muss an den Anfang der Methode verschoben werden. Dies führt zu sehr merkwürdigen Zustandswerten. Siehe PR hier reparieren.
Die Ansichtsmethode
liquidityUtilizationPostRelay
(der nur offchain verwendet wird), meldet eine falsche Nutzungsnummer. Der Nenner auf diese Linie sollte nicht gerecht seinliquidReserves
, sollte es stattdessen eine Darstellung von ungenutzten und genutzten Reserven sein. Fest hier.
Aktualisierung
Zusätzlich zu den Problembehebungen haben wir auch die folgenden inkrementellen Änderungen überprüft:
- PR3500 entfernt den redundanten Token-Parameter aus
BridgePool
Veranstaltungen. - PR3478 fügt die endgültige DVM-Gebühr zur Liste der lokal zwischengespeicherten Variablen hinzu.
- PR3460 Berücksichtigung eines möglichen Randfalls einer negativen Liquiditätsauslastung (zusätzlich zur Adressierung von N04)
- PR3482 entfernt überflüssige Dateien und aktualisiert OVM-Konstanten gemäß OVM 2.0-Änderungen.
- PR3585 aktualisiert die
BridgeDepositBox
Schnittstelle für Konsistenz und nutzt OpenZeppelinSafeERC20
Bibliothek.
Bei der Überprüfung der Fehlerbehebungen haben wir ein weiteres Problem festgestellt. Bei der Wertermittlung von BridgePool
LP-Token gibt es an Zwischenrechnung, die unerwartet negativ überlaufen könnte, wodurch das Hinzufügen und Entfernen von Liquidität vorübergehend deaktiviert würde. Die Berechnung sollte neu geordnet werden, um die genutzten Reserven zu addieren, bevor die nicht ausgeschütteten Gebühren abgezogen werden.
Kritische Schwere
[C01] Belohnung für gefangene Antragsteller
Das LongShortPair
Vertrag ruft eine Proposer-Belohnung ab von welcher Adresse auch immer der Ablauf ausgelöst wird, der verwendet wird, um Preisvorschläge im optimistischen Orakel anzuregen. Allerdings ist die LongShortPairCreator
Vertrag auch ruft das Geld ab und leitet es weiter von der Anbieteradresse. Diese zusätzlichen Gelder werden nicht an das Optimistische Orakel weitergegeben, sondern bleiben stattdessen in der Falle LongShortPair
Vertrag.
Erwägen Sie, die doppelte Übertragung zu entfernen.
Update: Behoben ab Commit 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Hoher Schweregrad
[H01] Gleichzeitige Relais erschöpfen die Reserven
Das relayDeposit
Funktion des BridgePool
Vertrag stellt sicher, dass der Vertrag über ausreichende Mittel verfügt um die Überweisung auszuführen. Es wird jedoch nicht berücksichtigt die schwebenden Reserven, das Gelder nachverfolgt, die für aktive Relais vorgesehen sind. Daher können sich mehrere gleichzeitige Weiterleitungen auf dieselben Geldmittel stützen, und sie können möglicherweise nicht alle sofort abgerechnet werden. Insbesondere bei einem stetigen Strom von Überweisungen können sich sofortige Relayer-Rückgaben auf unbestimmte Zeit verzögern.
Erwägen Sie, Weiterleitungen zu verhindern, die dazu führen würden, dass die ausstehenden Reserven die flüssigen Reserven übersteigen.
Update: Behoben ab Commit 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Bridging-Parametergrenzen stimmen nicht überein
Das deposit
Funktion dauert ebenfalls 3 Jahre. Das erste Jahr ist das sog. BridgeDepositBox
Vertrag, der auf Layer-2-Ketten eingesetzt wird, wird verwendet, um Mittel zwischen L2 und L1 zu überbrücken. Insbesondere Relayer werden dazu animiert Relais die Transaktionsdetails auf dem zugehörigen L1 BridgePool
. Allerdings nutzt das Schließfach inklusive Grenzen die Relay-Gebühren zu beschränken, während der Bridge-Pool verwendet wird exklusive Grenzen. Dies bedeutet, dass einige Einzahlungen (mit 25 % Relaisgebühren) nicht weitergeleitet werden können und die Gelder auf beiden Ebenen nicht zugänglich sind.
Erwägen Sie, die Validierungen auf beiden Ebenen zu synchronisieren, um sicherzustellen, dass alle gültigen Einzahlungen weitergeleitet werden können.
Update: Im Commit behoben 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Dies wurde ursprünglich als kritischer Schweregrad eingestuft, wurde aber herabgestuft, als das UMA-Team darauf hinwies, dass die Gelder nicht streng gefangen würden und freigegeben werden könnten, wenn die DVM-Wähler zustimmten, eine geänderte Relaisbeschreibung für betroffene Einlagen zu akzeptieren.
Mittlere Schwere
[M01] Rückrufe an falsche Adresse
Das SkinnyOptimisticOracle
ruft Rückruffunktionen auf dem Preisanforderer auf, falls vorhanden, damit der Anforderer auf signifikante Zustandsänderungen reagieren kann. Der Rückruf wird jedoch fälschlicherweise auf dem Preisvorschlager statt auf dem Preisanforderer in aufgerufen proposePriceFor
Funktion. Das bedeutet, dass der Preisanfrager nicht auf Preisvorschläge reagieren kann.
Glücklicherweise wird diese Funktion in der aktuellen Codebasis nicht verwendet. Erwägen Sie dennoch, die aufzurufen priceProposed
Rückruf beim Anforderer.
Update: Beim Commit behoben 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Fehlerhafte Append-Funktion
Das appendKeyValueBytes32
Funktion sollte seine Eingaben zu einer formatierten kombinieren bytes
Array. Allerdings ist die currentAncillaryData
is falsch entsorgt.
Da die Nebendaten beeinflusst den Orakelauflösungsprozess, könnte ein falscher Wert die Oracle-Ergebnisse untergraben. Glücklicherweise gibt es nur ein Anruf bei appendKeyValueBytes32
in der Codebasis, und es verwendet eine leere currentAncillaryData
Puffer, sodass der Fehler diesen Fall nicht betrifft.
Erwägen Sie die Aktualisierung der appendKeyValueBytes32
Funktion, so dass die currentAncillaryData
ist im zurückgegebenen Bytes-Array enthalten.
Update: Im Commit behoben 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Unvollständige Validierung der Zusatzdaten
Das LongShortPair
Konstruktor bestätigt, dass die customAncillaryData
ist klein genug,. Es berücksichtigt jedoch nicht die Feld für frühes Verfallsdatum. Gemeint ist damit das optimistische Orakel unerwartet ablehnen kann Preisanfragen mit vorzeitigem Ablauf, wodurch diese Funktion deaktiviert würde.
Erwägen Sie, die Validierung zu aktualisieren, um das zusätzliche Feld zu berücksichtigen.
Update: Behoben ab Commit 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Fehlerhafter Null-Zeitstempel
Im LongShortPair
Vertrag, ein Zeitstempel für einen vorzeitigen Ablauf von null ist als Fahne verwendet um anzuzeigen, dass niemand den vorzeitigen Ablaufmechanismus ausgelöst hat. Es ist jedoch möglich löst diesen Mechanismus aus mit einem Zeitstempel von Null. In diesem Szenario wird das Optimistische Orakel aber aufgerufen Schutz vor nachträglichen Preisanfragen wird nicht wirksam sein. Zum Glück einmal der Abrechnungspreis gewählt wird, wird es nicht überschrieben, sodass dies nicht zu inkonsistenten Abrechnungen führt. Trotzdem wäre eine nachträgliche Preisanfrage möglich den aufgezeichneten frühen Ablaufzeitstempel ändern, auch wenn der Zeitstempel Null zur Bestimmung des Abrechnungspreises verwendet wird. Es könnte auch ein irreführendes Ereignis ausgeben.
Erwägen Sie, den vorzeitigen Ablauf mithilfe des Zeitstempels Null zu verhindern.
Update: Behoben ab Commit 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Mögliche Nullbindung
Das requestPrice
Funktion des SkinnyOptimisticOracle
Vertrag verwendet die Abschlussgebühr als Kaution wenn die Bindung nicht angegeben ist. Allerdings ist die requestAndProposePriceFor
Funktion kann eine Nullbindung verwenden, was ihr widerspricht @notice
und @param
Bemerkungen. Ein Zero-Bond schwächt den Anreiz gegen ungültige Vorschläge oder Streitigkeiten.
Glücklicherweise nur Aufruf dieser Funktion in der Codebasis wird eine Proposer-Anleihe festgelegt. Ziehen Sie dennoch in Betracht, die endgültige Gebühr zu verwenden, wenn die Kaution nicht angegeben ist.
Update: Behoben ab Commit daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Unnötige Administratorrechte
Das BridgePool
Vertrag erbt von ExpandedERC20
damit es LP-Token an Liquiditätsanbieter ausgeben kann. Dies erbt die Funktionalität von OpenZeppelin ERC20
Vertrag und auch bietet Administratorrechte an den Vertragsbereitsteller, der es ihm ermöglicht, LP-Token zu prägen und zu verbrennen. Diese Befugnis ist jedoch nicht erforderlich und könnte, wenn sie ausgeübt wird, Liquiditätsanbieter unfair bestrafen.
Erwägen Sie eine Änderung BridgePool
direkt von erben ERC20
statt ExpandedERC20
.
Update: Im Commit behoben 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Geringe Schwere
[L01] Abrechnung bei Verfall nicht möglich
Das settle
Funktion des LongShortPair
Vertrag berücksichtigt die Abwicklungsbedingungen wenn die aktuelle Zeit genau vor oder nach dem Ablaufzeitstempel liegt. Es wird jedoch fälschlicherweise zurückgesetzt, wenn die aktuelle Zeit mit dem Ablaufzeitstempel übereinstimmt.
Erwägen Sie die Verwendung einer inklusiven Grenze, um die abzugleichen postExpiration
Modifikator.
Update: Im Commit behoben f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Fehlende Fehlermeldung in der Anforderungsanweisung
Es gibt eine require-Anweisung in der BridgePool
Vertrag ohne Fehlermeldung.
Erwägen Sie, spezifische und informative Fehlermeldungen in alle require-Anweisungen aufzunehmen.
Update: Behoben ab Commit 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Fehlende Dokumentzeichenfolgen
Es gibt einige Fälle in der Codebasis, in denen die Ethereum Natural-Spezifikation fehlt oder ist unvollständig. Beispiele beinhalten:
Erwägen Sie, alle Funktionen (und ihre Parameter), die Teil der öffentlichen API der Verträge sind, gründlich zu dokumentieren.
Update: Die hervorgehobenen Kommentare wurden im Commit behoben e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Wir haben die NatSpec-Vollständigkeit im Rest der Codebasis nicht validiert.
Hinweise und zusätzliche Informationen
[N01] Call-Rückgabewert nicht geprüft
Im deposit
Funktion des L2 BridgeDepositBox
Vertrag gibt es einen Low-Level-Aufruf an den l2Token
wenn das l1Token
is l1Weth
. Dieser Low-Level-Aufruf ist an die deposit()
Funktion, die zu den gehört WETH Schnittstelle. Wenn dies l2Token
verhält sich genau wie WETH, es sollte niemals fehlschlagen. Aber in dem Fall l2Token
sich anders verhält und fehlschlägt, gäbe es kein Zurück, da das Erfolgs-Flag dieses Low-Level-Aufrufs nie überprüft wird.
Erwägen Sie, die Rückgabewerte aller Low-Level-Aufrufe zu überprüfen und angemessen darauf zu reagieren.
[N02] Mangel an indizierten Parametern in Ereignissen
Viele der in dieser Codebasis definierten Ereignisse haben Parameter, die indiziert werden sollten:
Geht davon Indizieren von Ereignisparametern um zu vermeiden, dass Off-Chain-Dienste bei der Suche und Filterung nach bestimmten Ereignissen behindert werden.
Update: Teilweise im Commit behoben d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535dem „Vermischten Geschmack“. Seine chainId
Parameter von WhitelistToken
wurde nicht aktualisiert.
[N03] Implizite Casting-Inkonsistenz
Das LongShortPair
Vertrag allgemein behandelt Zeitstempel als uint64
Werte, die implizit umgewandelt werden uint256
Werte wann an das optimistische Orakel weitergegeben. Jedoch die requestTimestamp
Parameter von _requestOraclePrice
Funktion wird vorzeitig zu a gecastet uint256
. Dies hat keine funktionellen Konsequenzen.
Ziehen Sie jedoch im Interesse der Konsistenz die Verwendung von a in Betracht uint64
für diesen Parameter und ermöglicht, dass er implizit in a umgewandelt wird uint256
wenn sie an das optimistische Orakel weitergegeben werden.
Update: Im Commit behoben 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Der Zeitstempel wird nun explizit gecastet.
[N04] Falscher Typ
Das sendMessage
Funktion des iOptimism_CrossDomainMessenger
Schnittstelle verwendet ein uint256
Gaslimit während Optimismus OVM_CrossDomainEnabled
verwendet ein uint32
Gaslimit.
Aus Gründen der Konsistenz und Vorhersehbarkeit sollten Sie die Aktualisierung der iOptimisim_CrossDomainMessenger
sendMessage
Funktion zur Verwendung von a uint32
Gasgrenze.
Update: Behoben ab Commit 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Fehlende Validierung
Alle Funktionen drin BridgeAdmin
dieser Anruf _relayMessage
davon aus, dass der Transaktionswert mit dem übereinstimmt l1CallValue
-Parameter, aber dies wird nicht erzwungen.
Erwägen Sie, das Richtige sicherzustellen msg.value
wird gesetzt.
Update: Behoben ab Commit f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Lesbarkeit
Das _getDepositHash
Funktion dauert ebenfalls 3 Jahre. Das erste Jahr ist das sog. BridgePool
Vertrag entrollt die depositData
struct, um die zu verstecken l1Token
als Argument in der Zusammensetzung von keccak256
an. Nach der Installation können Sie HEIC-Dateien mit der abi
Codierung. Dies macht den Vorgang unnötig ausführlich und kann zu Fehlern führen, wenn er auf anderen Ebenen erneut implementiert wird.
Erwägen Sie, die Argumente so zu vereinfachen, dass sie einfach das geordnete Paar sind depositData
und l1Token
.
Update: Behoben ab Commit 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Reentrant-Funktion
Das requestAndProposePriceFor
Funktion dauert ebenfalls 3 Jahre. Das erste Jahr ist das sog. SkinnyOptimisticOracle
Vertrag ruft einen nicht vertrauenswürdigen an msg.sender
wird aber nicht von a bewacht nonReentrant
Modifikator. Obwohl dies in diesem Fall kein Sicherheitsproblem zu sein scheint, kann dies zu unerwartetem Verhalten führen.
Erwägen Sie das Hinzufügen der nonReentrant
Modifikator für alle Funktionen, die möglicherweise nicht vertrauenswürdige Verträge aufrufen.
Update: Im Commit behoben b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
nicht eingeloggt
Das relayMessage
Funktion dauert ebenfalls 3 Jahre. Das erste Jahr ist das sog. Arbitrum_Messenger
Vertrag gibt nach Ausführung einer sensiblen Aktion kein relevantes Ereignis aus. Das relayMessage
Funktionsaufrufe als Unterprogramm sentTxToL2NoAliasing
die selbst die zurückgibt uint256
Wert seqNum
, aber dieser Rückgabewert wird nicht in der protokolliert relayMessage
Funktion.
Erwägen Sie das Ausgeben von Ereignissen, nachdem sensible Änderungen stattgefunden haben, um die Nachverfolgung zu erleichtern und Kunden außerhalb der Kette nach der Vertragsaktivität zu benachrichtigen.
Update: Behoben ab Commit 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Tippfehler
Die Codebasis enthält die folgenden Tippfehler:
Erwägen Sie, diese Tippfehler zu korrigieren, um die Lesbarkeit des Codes zu verbessern.
Update: Behoben ab Commit 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Undokumentierte ERC20-Zulassungspflicht
Das requestEarlyExpiration
und expire
Funktionen dauert ebenfalls 3 Jahre. Das erste Jahr ist das sog. LongShortPair
Vertrag jeweils davon ausgehen, dass der Anrufer dem Vertrag eine Gegenleistung gewährt hat Ziehen Sie die Proposer-Belohnung.
Aus Gründen der Vorhersagbarkeit sollten Sie diese Anforderung in den Funktionskommentaren dokumentieren.
Update: Im Commit behoben da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Unbenutzter Modifikator
Im BridgePool
Vertrag, die onlyFromOptimisticOracle
Modifikator ist definiert, wird aber nie in der Codebasis verwendet und sollte daher entfernt werden.
Update: Im Commit behoben 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
Schlussfolgerungen
Es wurden 2 kritische und 1 Problem mit hohem Schweregrad gefunden. Einige Änderungen wurden vorgeschlagen, um Best Practices zu folgen und die potenzielle Angriffsfläche zu reduzieren.
- &
- 7
- Konto
- Action
- aktiv
- Ad
- Zusätzliche
- Adresse
- Administrator
- Vorteil
- Alle
- Zulassen
- Bienen
- Argumente
- Prüfung
- Verfügbarkeit
- Sein
- BESTE
- Best Practices
- Blockchain
- Box
- BRIDGE
- Fehler
- Bugs
- rufen Sie uns an!
- Fälle
- gefangen
- Verursachen
- challenges
- Übernehmen
- Überprüfung
- Code
- Bemerkungen
- Konfiguration
- enthält
- Vertrag
- Verträge
- könnte
- Strom
- technische Daten
- dezentralisiert
- verzögern
- Design
- Festlegung
- DID
- Streit
- Tut nicht
- Früh
- Wirtschaftlich
- Edge
- Effektiv
- ERC20
- ETH
- Astraleum
- Ethereum Blockchain
- Event
- Veranstaltungen
- Beispiel
- Austausch-
- erwartet
- ERFAHRUNGEN
- Merkmal
- Honorare
- Revolution
- Vorname
- Fixieren
- Blinken (Flash)
- folgen
- gefunden
- Funktion
- Fonds
- Mittel
- Zukunft
- GAS
- Gasgebühren
- Unterstützung
- Governance
- glücklich
- mit
- hier
- GUTE
- Besondere
- Inhaber
- Ultraschall
- HTTPS
- Anreize
- inklusive
- Einschließlich
- Erhöhung
- Information
- Interesse
- Schnittstelle
- Probleme
- IT
- bekannt
- führen
- Bibliothek
- Flüssigkeit
- Liquidity
- Liquiditätsanbieter
- Liste
- Kredite
- örtlich
- verschlossen
- LP
- LPs
- Markt
- Spiel
- vor allem warme
- XNUMXh geöffnet
- Orakel
- Andere
- Plattform
- Pool
- Pools
- Werkzeuge
- Verhütung
- Preis
- Prozessdefinierung
- Angebot
- die
- bietet
- Öffentlichkeit
- Gründe
- Veteran
- Meldungen
- REST
- Die Ergebnisse
- Rückgabe
- Überprüfen
- Risiko
- Sicherheitdienst
- Dienstleistungen
- kompensieren
- Siedlung
- Short
- signifikant
- ähnlich
- klein
- So
- solide
- Jemand,
- etwas
- Geschwindigkeit
- verbringen
- Bundesstaat
- Erklärung
- Lagerung
- Erfolg
- Unterstützte
- Oberfläche
- System
- Test
- Durch
- während
- Zeit
- Zeichen
- Tokens
- Top
- Tracking
- Transaktion
- Transaktionen
- Vertrauen
- Aktualisierung
- Updates
- UPS
- Nutzer
- Wert
- Anzeigen
- Whitelist
- WHO
- .
- ohne
- Arbeiten
- wert
- Null