Uma-audit – fase 6

Introductie

UMA is een platform waarmee gebruikers financiële contracten met een minimaal vertrouwen op de Ethereum-blockchain kunnen aangaan. We hebben eerder gecontroleerd het gedecentraliseerde orakel, een bepaald financieel contractsjabloon, enkele ad-hoc pull-verzoeken, de eeuwigdurende multiparty-sjabloon, verschillende incrementele pull-verzoeken over een langere betrokkenheid en de verzekerde brug.

In deze audit hebben we een nieuw bestuursvoorstelcontract beoordeeld, een mechanisme om het UMA-ecosysteem over meerdere ketens uit te breiden, een mechanisme om beloningen te verdelen onder ERC721-tokenhouders in overeenstemming met een off-chain-specificatie, en een update van de verzekerde brug om WETH te ondersteunen op de Optimisme-keten.

De gecontroleerde commit is 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc en het toepassingsgebied omvat de volgende contracten:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (exclusief test- en Polygon-contracten)
• financial-templates/optimistic-rewarder/* (exclusief proefcontracten)

We hebben ook de wijzigingen in solidity-bestanden beoordeeld in Trekverzoek 3611.

Alle externe code en contractafhankelijkheden werden verondersteld te werken zoals gedocumenteerd.

Systeem overzicht

De huidige Governance contract stelt de Risk Labs Foundation in staat om nieuwe bestuursacties voor te stellen die kunnen worden bekrachtigd door de UMA-tokenhouders. De nieuwe Proposer contract is bedoeld om de rol van indiener op zich te nemen, zodat iedereen nieuwe voorstellen kan doen zolang ze een band bieden die zal worden opgeofferd als het voorstel mislukt. Er is geen specifieke prikkel om voorstellen te doen. Het is de bedoeling ervoor te zorgen dat alleen de acties worden voorgesteld die zeer waarschijnlijk zullen worden aanvaard.

Met het nieuwe cross-chain-mechanisme kan het bestuursvoorstel worden doorgegeven van het Ethereum-mainnet naar de Optimism- en Arbitrum-ketens. Op deze manier kan het UMA-governancemechanisme op laag 1 worden gebruikt om UMA-contracten op de ondersteunde laag 2-ketens te besturen. Het mechanisme maakt het ook mogelijk prijsaanvragen en resoluties tussen de lagen door te sturen, zodat Optimistic Oracles op de laag 2-ketens kunnen worden beveiligd door het mainnet Data Verification Mechanism op dezelfde manier als het Optimistic Oracle van laag 1 wordt beveiligd door de DVM.

Het is vermeldenswaard dat deze berichten worden verzonden met behulp van de native bridge-mechanica, wat betekent dat ze worden beperkt door de kenmerken van de relevante laag 2-ketens. Met name de berichten van laag 2 naar laag 1 kunnen een week of langer duren om de brug te passeren. Bovendien ondersteunt het UMA-governancemechanisme voorstellen die meerdere geordende transacties bevatten, maar dit beperkt alleen de volgorde waarin ze aan de brug kunnen worden toegevoegd. Het is mogelijk dat sommige van die transacties in een andere volgorde of helemaal niet worden uitgevoerd op laag 2.

Het Optimistic Rewarder-contract geeft eenvoudig ERC721-tokens voor iedereen die erom vraagt. Het stelt iedereen ook in staat willekeurige gegevens aan een token te koppelen en verschillende ERC20-tokens te storten om als beloningen te worden gedistribueerd. De interpretatie van de willekeurige gegevens en de verwachte verdeling van beloningen onder de tokenhouders worden bepaald met behulp van een niet-gespecificeerde off-chain procedure. Iedereen kan beweren dat een specifiek ERC721-token een reeks beloningen verschuldigd is als ze bereid zijn een obligatie te storten. Het standaard Optimistic Oracle-mechanisme wordt gebruikt om iemand anders in staat te stellen de claim te betwisten, die zal worden opgelost door de DVM. Claims die niet tijdig worden betwist, worden geacht geldig te zijn en het contract verdeelt de beloningen dienovereenkomstig. De enige beperking (om de boekhouding te vereenvoudigen) is dat het orakel-obligatie-token niet kan worden gebruikt als beloningstoken.

Ten slotte wijzigt PR3611 het verzekerde brugmechanisme om te voorkomen dat WETH over de Optimism-tokenbrug wordt gestuurd, wat niet wordt ondersteund. In plaats daarvan wordt elke L2 WETH die in de Optimism-depot wordt gedeponeerd, uitgepakt in L2 ETH voordat de brug wordt overgestoken. Op laag 1 wordt de ETH geconverteerd naar WETH voordat deze wordt doorgestuurd naar de WETH-bridgepool.

Kritieke ernst

[C01] Kan ongeldige beloning niet betwisten

Bij het betwisten van een beloningsverzoek, OptimisticRewardBase eerst contracteren triggert een voorstel op de SkinnyOptimisticOracle en betwist dat voorstel. Het voorstel is echter stelt de vervaltijd in als een compensatie van de huidige (geschil) tijd, terwijl het geschil specificeert de vervaldatum als een compensatie vanaf het moment van het oorspronkelijke beloningsverzoek. In de meeste gevallen zal deze discrepantie voorkomen dat het orakel het te betwisten voorstel identificeert, wat betekent dat geldige geschillen niet worden verwerkt en ongeldige beloningsverzoeken worden geaccepteerd.

Overweeg om het beroep op het geschil bij te werken om het te betwisten voorstel correct te specificeren.

update: Vast vanaf commit 9e15557 in PR3690.

[C02] Voorstellen herhaaldelijk oplossen

De resolveProposal functie van de Proposer contract valideert eenvoudig dat het orakel heeft opgelost, maar niet controleert of de band is verdeeld. Dit betekent dat hetzelfde voorstel meerdere keren kan worden opgelost, wat resulteert in dubbele obligatiebetalingen. Overweeg om bestaande voorstellen te markeren of te verwijderen wanneer ze zijn opgelost.

update: Vast vanaf commit b152718 in PR3689.

Hoge ernst

Geen.

Middelmatige ernst

[M01] Onjuiste gebeurtenisparameters

De OptimisticRewarderBase contract definieert een Requested gebeurtenis die wordt uitgezonden door de requestRedemption functie wanneer een aflossing wordt aangevraagd. Deze gebeurtenis is gedefinieerd om de . uit te zenden vervaltijd van de aflossing als de laatste parameter. Echter, wanneer de gebeurtenis wordt uitgezonden, de laatste parameter is onjuist ingesteld op de huidige tijd.

Evenzo de Redeemed gebeurtenis leest de vervaltijd nadat het record is verwijderd, dus het wordt onjuist op nul gezet.

Aangezien deze gebeurtenis kan worden gebruikt om berekeningen buiten de keten te activeren, kunt u overwegen de uitgezonden waarde op de juiste manier bij te werken.

update: Vast vanaf commit f04eef9 in PR3694.

Lage ernst

[L01] Gebrek aan gebeurtenisemissie na betwisting van een verzilvering

De OptimisticRewarderBase contract definieert een Disputed gebeurtenis die bedoeld is om te worden geactiveerd als een aflossing wordt betwist. Deze gebeurtenis wordt echter niet uitgezonden binnen of buiten de OptimisticRewarderBase contract.

Overweeg de gebeurtenis uit te zenden nadat gevoelige wijzigingen hebben plaatsgevonden in de dispute functie, om het volgen te vergemakkelijken en klanten buiten de keten op de hoogte te stellen van de activiteit van de contracten.

update: Vast vanaf commit c275e92 in PR3695.

[L02] Inconsistente re-entry guard

De Optimism_ParentMessenger en Arbitrum_ParentMessenger contracten passen inconsequent de nonReentrant modificator. Overweeg het op te nemen in alle openbare functies.

update: Vast vanaf commit 6275c39 in PR3677.

[L03] Misleidende opmerkingen

Hier zijn enkele misleidende opmerkingen die we tijdens onze beoordeling hebben geïdentificeerd:

• ChildMessengerConsumerInterface.sol:
  • Lijn 5 zegt "ouderboodschapper" in plaats van "kindboodschapper"
• GovernorSpoke.sol:
  • Lijnen 49-51 linkt naar een Gnosis bestand, ook al staat in de opmerking dat het fragment is gekopieerd van Governor.sol. Bovendien is het fragment niet identiek aan dat in Governor.sol

update: Vast vanaf commit cc350f9 in PR3678.

[L04] Stempel van aanvullende gegevens ontbreekt

Bij het aanvragen van een prijs op de OracleSpoke contract, de verstrekte aanvullende gegevens is gestempeld met de onderliggende keten-ID. echter, de hasPrice en getPrice functies stempelen de aanvullende gegevens niet bij het identificeren van de prijsaanvraag. Dit dwingt contracten om de stempel zelf aan te brengen, wat een inconsistentie veroorzaakt tussen het prijsverzoek en het prijsophaalmechanisme. Overweeg de stempel aan te brengen in de hasPrice en getPrice functies.

update: Vast vanaf commit fdb845d in PR3668.

[L05] Ontbrekende NatSpec-parameter

Veel functies in de OptimisticRewarderBase contract missen de @return parameter in hun opmerkingen over natuurlijke specificatie. Overweeg om het voor de volledigheid op te nemen.

update: Vast vanaf commit 8920f38 in PR3679.

[L06] Resterende toeslag

Om het Optimistische Orakel aan te roepen, OptimisticRewarderBase contract verleent het een symbolische vergoeding, zodat het de obligatiebetalingen kan trekken. Als het voorstel niet lukt, het inwisselen van de beloning is geannuleerd maar de toeslag wordt niet gereset. Daarom behoudt het Optimistic Oracle een onnodige resterende vergoeding tot de volgende keer dat een geschil ontstaat. Overweeg de toeslag in te trekken als het voorstel niet lukt.

update: Vast vanaf commit c2d444b in PR3698.

[L07] Ongeldig retouradres

Het restitutie L2-adres van de Arbitrum_ParentMessenger is geïnitialiseerd aan de contracteigenaar, die de L1-gouverneur zou moeten zijn. Evenzo is de setRefundL2Address heeft een reactie waarin staat dat het moet worden ingesteld bij de gouverneur. Bij het doorgeven van berichten over de brug is deze waarde echter instellen als de L2-gebruiker, het adres op Arbitrum dat overtollige bedragen ontvangt nadat het ticket is opgelost. Aangezien het adres van de gouverneur van L1 niet toegankelijk zal zijn op Arbitrum, gaan alle fondsen die naar dit adres worden verzonden, verloren.

Overweeg om het in te stellen op een geldig L2-adres.

update: Vast vanaf commit b3f2dd1 in PR3687.

[L08] Mechanisme om kindboodschappers te veranderen

De GovernorSpoke en OracleSpoke contract elk initialiseert de onderliggende boodschapper in de constructor, zonder mechanisme om het bij te werken. Dit betekent dat wanneer de kind messenger is gewijzigd, worden beide spaakcontracten overbodig.

Aangezien het spaakcontract waarschijnlijk stabieler is dan de boodschappers, overweeg dan om een ​​mechanisme op te nemen om de boodschapper op de spaken bij te werken.

update: Vast vanaf commit 7c9e061 in PR3688.

Opmerkingen en aanvullende informatie

[N01] Wijzig obligatie-token

De Proposer contract omvat: een mechanisme voor de eigenaar om de grootte van de voorgestelde obligatie te wijzigen. Overweeg of ze ook het obligatie-token moeten kunnen wijzigen. Merk op dat dit een mechanisme zou vereisen om de juiste obligatievaluta te identificeren wanneer bestaande voorstellen worden opgelost.

update: Geen probleem. UMA's verklaring voor dit probleem:

N01 beveelt aan om het contract van de indiener in staat te stellen het obligatie-token te wijzigen in iets anders dan UMA. We zijn niet van plan om een ​​ander token dan $UMA voor deze functie te ondersteunen en hebben er daarom voor gekozen om geen wijzigingen aan te brengen voor dit probleem. Bovendien houdt een enkele token per contract deze logica zo eenvoudig mogelijk. Ten slotte, als er een wijziging nodig was (in het geval van een tokenmigratie, bijvoorbeeld), konden we gewoon een nieuw voorstelcontract met het andere token implementeren en een voorstel initiëren om het systeem te migreren om dat token te gebruiken.

[N02] Onvolledige interface

De ChildMessengerInterface specificeert geen a processMessageFromCrossChainParent functie, ook al wordt aangenomen dat deze bestaat door ouderboodschappers. Overweeg om het voor de volledigheid op te nemen.

update: Niet gemaakt. UMA's verklaring voor dit probleem:

We hebben er bewust voor gekozen om deze interface inconsistent te laten, omdat de implementatie hiervan binnen de ChildMessengerInterface de compatibiliteit met de Polygon_ChildMessenger verbreekt, aangezien de methode van Polygon voor het verwerken van berichten van andere ketens enigszins aangepaste logica vereist waarbij een interne methode _processMessageFromRoot wordt genoemd.

[N03] Onjuiste interface

De GovernorSpoke verkeerd contracteren gebruikt ChildMessengerConsumerInterface type dan: om het te beschrijven messenger variabel. Overweeg het gebruik van de ChildMessengerInterface gebruiken.

update: Vast vanaf commit f31a527 in PR3680.

[N04] Trek tokens naar winkel

In een vorige audit we twijfelden aan het doel van de Store contract payOracleFeesErc20 functie (in uitgave L19). Het UMA-team ervoor gekozen om de functie te behouden om de interface te standaardiseren voor mogelijke toekomstige wijzigingen. Aangezien het doel van de functie niet volledig is gespecificeerd, is het onduidelijk of deze moet worden geactiveerd wanneer de Proposer contract neemt een obligatie in beslag. Het moet waarschijnlijk worden gebruikt wanneer de OracleHub betaalt voor een prijsaanvraag. Overweeg of de functie in beide scenario's moet worden gebruikt.

update: Erkend. UMA's verklaring voor dit probleem:

N04 raadt aan om de payOracleFeeErc20-methode van de Store te gebruiken voor het betalen van vergoedingen in zowel de Proposer- als de OracleHub-contracten om consistent te zijn met het Store-gebruik. We hebben ervoor gekozen om deze functie niet te gebruiken omdat dit zou betekenen dat we een extra interface (voor de winkel) moeten importeren en het bedrag van de obligatie naar een FixedPoint moeten casten (wat ook een extra import zou vereisen. Om de code eenvoudig en schoon te houden we hebben ervoor gekozen om dit niet te doen.De feedback van OZ op payOracleFeeErc20 in auditfase 1 in april 2020 was valide dat deze methode niet echt nuttig is, waardoor dit soort integratie moeilijker te redeneren is.

[N05] TODO's in code

Er zijn "TODO"-opmerkingen in de codebasis die moeten worden bijgehouden in de achterstand van het project. Bijvoorbeeld:

• Lijn 37 of Arbitrum_ParentMessenger contract
• Lijn 25 of Optimism_ChildMessenger contract
• lijnen 83 en 146 of OracleHub contract.

Tijdens de ontwikkeling zal het hebben van goed beschreven "TODO"-opmerkingen het proces van het volgen en oplossen ervan gemakkelijker maken. Zonder die informatie kunnen deze opmerkingen de neiging hebben om te rotten en kan belangrijke informatie voor de beveiliging van het systeem vergeten zijn tegen de tijd dat het voor productie wordt vrijgegeven.

Deze TODO-opmerkingen moeten een korte beschrijving bevatten van de taak die nog moet worden uitgevoerd en een link naar het bijbehorende probleem in de projectrepository.

Overweeg om de TODO-opmerkingen bij te werken om deze informatie toe te voegen. Voor volledigheid en traceerbaarheid kan een handtekening en een tijdstempel worden toegevoegd. Bijvoorbeeld:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

update: Vast vanaf commit 5d57b5b in PR3684.

[N06] Typografische fouten

De codebase bevat de volgende typografische fouten:

• In het Admin_ChildMessenger contract, impleenting moet implementing
• In het OptimisticRewarderBase contract, timestap moet timestamp.
• In het OptimisticRewarderBase contract, liveness liveness moet liveness.
• In het GovernorSpoke contract, only called moet only be called.
• In het Optimism_ChildMessenger contract:

update: Vast vanaf commit 9b92b0b in PR3681.

[N07] Ongebruikte invoer

Om de leesbaarheid van de code te verbeteren, kunt u overwegen de volgende ongebruikte importen te verwijderen:

update: Vast vanaf commit 40b7221 in PR3682.

[N08] L2 transactie bestellen

De Governor waarborgt transacties binnen een voorstel worden op volgorde uitgevoerd. Wanneer die transacties echter cross-chaintransacties omvatten, garandeert dit alleen dat ze in de juiste volgorde tot het L1-overbruggingscontract komen. In de Arbitrum-zaak kunnen ze opnieuw worden gerangschikt voordat ze definitief zijn op L2. Daarom moeten bestuursvoorstellen worden opgesteld om de mogelijkheid van herschikte L2-transacties mogelijk te maken.

update: Vast vanaf commit 0fb2e7b in PR3703. De GovernorHub kan nu een reeks L2-transacties doorgeven.

Conclusie

Er zijn twee kritieke problemen gevonden in de codebase. Er zijn één probleem met gemiddelde ernst en verschillende kleine kwetsbaarheden gevonden en er zijn aanbevelingen voor oplossingen voorgesteld.

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