Uma Audit – Fase 6

Introduktion

UMA er en platform, der giver brugerne mulighed for at indgå tillidsminimerede finansielle kontrakter på Ethereum blockchain. Vi har tidligere revideret det decentraliserede orakel, en bestemt finansiel kontraktskabelon, nogle ad hoc pull-anmodninger, Perpetual Multiparty skabelonen, forskellige inkrementelle pull-anmodninger over et længere engagement , den forsikrede bro.

I denne revision gennemgik vi en ny styringsforslagskontrakt, en mekanisme til at udvide UMA-økosystemet på tværs af flere kæder, en mekanisme til at distribuere belønninger til ERC721-tokenholdere i overensstemmelse med en off-chain-specifikation og en opdatering af den forsikrede bro for at understøtte WETH på Optimisme-kæden.

Den reviderede forpligtelse er 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc og omfanget omfatter følgende kontrakter:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (eksklusive test- og polygonkontrakter)
• financial-templates/optimistic-rewarder/* (eksklusive testkontrakter)

Vi gennemgik også ændringerne til solidity-filer i Træk anmodning 3611.

Alle eksterne kode- og kontraktafhængigheder blev antaget at fungere som dokumenteret.

Systemoversigt

Den aktuelle Governance kontrakt giver Risk Labs Foundation mulighed for at foreslå nye styringshandlinger, der kan ratificeres af UMA-tokenindehaverne. Den nye Proposer Kontrakten er beregnet til at påtage sig forslagsstillerrollen, hvilket giver enhver mulighed for at fremsætte nye forslag, så længe de giver en binding, der vil blive ofret, hvis forslaget mislykkes. Der er ikke noget specifikt incitament til at stille forslag. Hensigten er at sikre, at kun de handlinger, der med stor sandsynlighed vil blive accepteret, vil blive foreslået.

Den nye tværkædemekanisme gør det muligt at videregive forslag til styring fra Ethereum-netværket til Optimisme- og Arbitrum-kæderne. På denne måde kan UMA-styringsmekanismen på lag 1 bruges til at styre UMA-kontrakter på de understøttede lag 2-kæder. Mekanismen gør det også muligt at videresende prisanmodninger og opløsninger mellem lagene, så Optimistic Oracles på lag 2-kæderne kan sikres af mainnet Data Verification Mechanism på samme måde som lag 1 Optimistic Oracle er sikret af DVM.

Det er værd at bemærke, at disse meddelelser sendes ved hjælp af den oprindelige bromekanik, hvilket betyder, at de er begrænset af egenskaberne for de relevante lag 2-kæder. Især meddelelserne fra lag 2 til lag 1 kunne tage en uge eller længere at passere broen. Desuden understøtter UMA-styringsmekanismen forslag, der inkluderer flere bestilte transaktioner, men dette begrænser blot rækkefølgen, hvori de kan tilføjes til broen. Det er muligt for nogle af disse transaktioner at blive udført i en anden rækkefølge, eller slet ikke, på lag 2.

Optimistic Rewarder-kontrakten præger simpelthen ERC721-tokens for alle, der anmoder om dem. Det giver også enhver mulighed for at knytte vilkårlige data til ethvert token og at indbetale forskellige ERC20-tokens, der skal distribueres som belønninger. Fortolkningen af ​​de vilkårlige data og den forventede fordeling af belønninger blandt token-indehaverne bestemmes ved hjælp af en uspecificeret off-chain-procedure. Enhver kan påstå, at et specifikt ERC721-token skylder et sæt belønninger, hvis de er villige til at indbetale en obligation. Standard Optimistic Oracle-mekanismen bruges til at give en anden mulighed for at bestride kravet, som vil blive løst af DVM. Krav, der ikke bestrides rettidigt, antages at være gyldige, og kontrakten fordeler belønningen i overensstemmelse hermed. Den eneste begrænsning (for at forenkle regnskabet) er, at orakelobligationstokenet ikke kan bruges som belønningstoken.

Endelig ændrer PR3611 den forsikrede bromekanisme for at undgå at sende WETH over Optimism-tokenbroen, som ikke understøttes. I stedet pakkes enhver L2 WETH, der er deponeret i Optimism-deponeringsboksen, ud til L2 ETH, før den passerer broen. På lag 1 konverteres ETH til WETH, inden den videresendes til WETH-bropuljen.

Kritisk sværhedsgrad

[C01] Kan ikke bestride ugyldig belønning

Når du bestrider en anmodning om belønning, skal OptimisticRewardBase kontrakt først udløser et forslag på den SkinnyOptimisticOracle og så bestrider dette forslag. Dog forslaget indstiller udløbstiden som en offset fra det aktuelle (tvist)tidspunkt, mens tvisten angiver udløbet som en modregning fra tidspunktet for den oprindelige belønningsanmodning. I de fleste tilfælde vil denne uoverensstemmelse forhindre oraklet i at identificere det forslag, der skal bestrides, hvilket betyder, at gyldige tvister ikke vil blive behandlet, og ugyldige belønningsanmodninger vil blive accepteret.

Overvej at opdatere tvistindkaldelsen for korrekt at specificere det forslag, der skal bestrides.

Update: Fast fra commit 9e15557 in PR3690.

[C02] Løs forslag gentagne gange

resolveProposal funktion af Proposer kontrakt validerer simpelthen at oraklet har løst, men kontrollerer ikke, om obligationen er blevet uddelt. Det betyder, at det samme forslag kan løses flere gange, hvilket resulterer i dobbelte obligationsbetalinger. Overvej at markere eller slette eksisterende forslag, når de er løst.

Update: Fast fra commit b152718 in PR3689.

Høj sværhedsgrad

Ingen.

Medium sværhedsgrad

[M01] Forkerte hændelsesparametre

OptimisticRewarderBase kontrakt definerer en Requested begivenhed som udsendes fra requestRedemption funktion, når der anmodes om indløsning. Denne hændelse er defineret til at udsende udløbstidspunktet for indløsningen som sidste parameter. Imidlertid, når begivenheden udsendes, dens sidste parameter er forkert indstillet til nuværende tid.

Tilsvarende Redeemed begivenhed aflæser udløbstiden efter at posten er slettet, så den bliver forkert sat til nul.

I betragtning af, at denne hændelse kan bruges til at udløse off-chain-beregninger, bør du overveje at opdatere den udsendte værdi korrekt.

Update: Fast fra commit f04eef9 in PR3694.

Lav sværhedsgrad

[L01] Manglende begivenhedsudsendelse efter at have bestridt en indløsning

OptimisticRewarderBase kontrakt definerer en Disputed begivenhed der er beregnet til at blive udløst, hvis en indløsning bestrides. Denne begivenhed udsendes dog ikke inden for eller uden for OptimisticRewarderBase kontrakt.

Overvej at udsende begivenheden efter følsomme ændringer har fundet sted i dispute funktion, for at lette sporing og underrette kunder uden for kæden efter kontrakternes aktivitet.

Update: Fast fra commit c275e92 in PR3695.

[L02] Inkonsekvent genindgangsvagt

Optimism_ParentMessenger , Arbitrum_ParentMessenger kontrakter gælder inkonsekvent nonReentrant modifikator. Overvej at inkludere det på alle offentlige funktioner.

Update: Fast fra commit 6275c39 in PR3677.

[L03] Vildledende kommentarer

Her er nogle vildledende kommentarer, vi identificerede under vores gennemgang:

• ChildMessengerConsumerInterface.sol:
  • Linje 5 siger "forældrebud" i stedet for "barnebud"
• GovernorSpoke.sol:
  • Linjer 49-51 links til en Gnosis fil, selvom kommentaren siger, at uddraget er kopieret fra Governor.sol. Derudover er uddraget ikke identisk med det i Governor.sol

Update: Fast fra commit cc350f9 in PR3678.

[L04] Manglende hjælpedatastempel

Ved anmodning om en pris på OracleSpoke kontrakt, de angivne supplerende data er stemplet med underordnet kæde-id. Imidlertid hasPrice , getPrice funktioner stempler ikke de supplerende data, når de identificerer prisanmodningen. Dette tvinger indkaldende kontrakter til selv at anvende stemplet, hvilket forårsager en uoverensstemmelse mellem prisanmodningen og prissøgningsmekanismerne. Overvej at anvende stemplet i hasPrice , getPrice funktioner.

Update: Fast fra commit fdb845d in PR3668.

[L05] Manglende NatSpec-parameter

Mange funktioner i OptimisticRewarderBase kontrakt mangler @return parameter i deres Natural Specification-kommentarer. Overvej at inkludere det for fuldstændighedens skyld.

Update: Fast fra commit 8920f38 in PR3679.

[L06] Restgodtgørelse

For at påberåbe sig det optimistiske oraklet, OptimisticRewarderBase kontrakt giver det en symbolsk godtgørelse, så det kan trække obligationsbetalingerne. Hvis forslaget mislykkes, belønningsindløsningen annulleres men godtgørelsen nulstilles ikke. Derfor vil Optimistic Oracle beholde en unødvendig restgodtgørelse indtil næste gang en tvist udløses. Overvej at tilbagekalde godtgørelsen, hvis forslaget mislykkes.

Update: Fast fra commit c2d444b in PR3698.

[L07] Ugyldig refusionsadresse

Refusions L2-adressen på Arbitrum_ParentMessenger er initialiseret til kontraktejeren, som skulle være L1-guvernøren. Tilsvarende setRefundL2Address har en kommentar med angivelse af, at den skal indstilles til guvernøren. Men når du sender beskeder over broen, er denne værdi indstillet som L2-bruger, som er adressen på Arbitrum, der modtager overskydende midler, efter at billetten er løst. Da L1-guvernøradressen ikke vil være tilgængelig på Arbitrum, vil alle midler, der sendes til denne adresse, gå tabt.

Overvej at indstille den til en gyldig L2-adresse.

Update: Fast fra commit b3f2dd1 in PR3687.

[L08] Mekanisme til at skifte børnebude

GovernorSpoke , OracleSpoke kontrakt hver initialiser den underordnede messenger i konstruktøren, uden nogen mekanisme til at opdatere den. Det betyder, at når børnebud er ændret, begge egerkontrakter bliver forældede.

Da eger-kontrakten sandsynligvis er mere stabil end messengers, kan du overveje at inkludere en mekanisme til at opdatere messenger på egerne.

Update: Fast fra commit 7c9e061 in PR3688.

Bemærkninger og yderligere oplysninger

[N01] Skift obligationstoken

Proposer kontrakten omfatter en mekanisme for ejeren at ændre størrelsen af ​​forslagsobligationen. Overvej om de også skal kunne ændre obligationstokenen. Bemærk, at dette ville kræve en mekanisme til at identificere den korrekte obligationsvaluta, når eksisterende forslag er løst.

Update: Ikke et problem. UMA's erklæring til dette spørgsmål:

N01 anbefaler at give forslagsstillerkontrakten mulighed for at ændre obligationstokenet til noget andet end UMA. Vi har ingen intentioner om at understøtte andre tokens end $UMA for denne funktion, og vi har derfor valgt ikke at foretage nogen ændringer for dette problem. Desuden holder et enkelt token per kontrakt denne logik så enkel som muligt. Til sidst, hvis en ændring var nødvendig (i tilfælde af en token-migrering, for eksempel), kunne vi bare implementere en ny forslagsstillerkontrakt med det andet token og indlede et forslag om at migrere systemet til at bruge det.

[N02] Ufuldstændig grænseflade

ChildMessengerInterface angiver ikke en processMessageFromCrossChainParent funktion, selvom det antages at eksistere af forældrebudbringere. Overvej at inkludere det for fuldstændighedens skyld.

Update: Ikke fikset. UMA's erklæring til dette spørgsmål:

Vi valgte med vilje at lade denne grænseflade være inkonsekvent, da implementering af dette i ChildMessengerInterface bryder kompatibiliteten med Polygon_ChildMessenger, da Polygons metode til at behandle beskeder fra andre kæder kræver noget tilpasset logik, hvor en intern metode kaldes _processMessageFromRoot.

[N03] Forkert interface

GovernorSpoke kontrakt forkert anvender ChildMessengerConsumerInterface typen at beskrive dens messenger variabel. Overvej at bruge ChildMessengerInterface i stedet.

Update: Fast fra commit f31a527 in PR3680.

[N04] Træk tokens til Store

I en tidligere revision vi stillede spørgsmålstegn ved formålet med Store kontraktens payOracleFeesErc20 funktion (i udgave L19). UMA-holdet valgt at beholde funktionen at standardisere grænsefladen til potentielle fremtidige ændringer. Da formålet med funktionen ikke er fuldt specificeret, er det uklart, om den skal udløses, når Proposer kontrakt konfiskerer en obligation. Det skal sandsynligvis bruges, når OracleHub betaler for en prisanmodning. Overvej om funktionen skal bruges i begge scenarier.

Update: Anerkendt. UMA's erklæring til dette spørgsmål:

N04 anbefaler at bruge butikkens payOracleFeeErc20-metode til at betale gebyrer i både forslagsstilleren og OracleHub-kontrakterne for at være i overensstemmelse med butiksbrugen. Vi har valgt ikke at bruge denne funktion, da det ville betyde at skulle importere en ekstra grænseflade (til butikken) og kræve casting af obligationsbeløbet til et FixedPoint (hvilket også ville kræve en ekstra import. For at holde koden enkel og ren vi har valgt ikke at gøre dette. OZ-feedbacken om payOracleFeeErc20 i revisionsfase 1 i april 2020 var gyldig, at denne metode ikke er rigtig brugbar, hvilket gør denne form for integration sværere at ræsonnere omkring.

[N05] TODOs i kode

Der er "TODO"-kommentarer i kodebasen, som bør spores i projektets problembacklog. For eksempel:

• Line (linje) 37 of Arbitrum_ParentMessenger kontrakt
• Line (linje) 25 of Optimism_ChildMessenger kontrakt
• Lines 83 , 146 of OracleHub kontrakt.

Under udviklingen vil velbeskrevne "TODO"-kommentarer gøre processen med at spore og løse dem lettere. Uden disse oplysninger kan disse kommentarer have en tendens til at rådne, og vigtig information for systemets sikkerhed kan være glemt, når den frigives til produktion.

Disse TODO-kommentarer skal have en kort beskrivelse af opgaven, der skal udføres, og et link til det tilsvarende problem i projektarkivet.

Overvej at opdatere TODO-kommentarerne for at tilføje disse oplysninger. For fuldstændigheden og sporbarheden kan der tilføjes en signatur og et tidsstempel. For eksempel:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Update: Fast fra commit 5d57b5b in PR3684.

[N06] Trykfejl

Kodebasen indeholder følgende typografiske fejl:

• I Admin_ChildMessenger kontrakt, impleenting være implementing
• I OptimisticRewarderBase kontrakt, timestap være timestamp.
• I OptimisticRewarderBase kontrakt, liveness liveness være liveness.
• I GovernorSpoke kontrakt, only called være only be called.
• I Optimism_ChildMessenger kontrakt:

Update: Fast fra commit 9b92b0b in PR3681.

[N07] Ubrugte importvarer

For at forbedre kodens læsbarhed bør du overveje at fjerne følgende ubrugte importer:

Update: Fast fra commit 40b7221 in PR3682.

[N08] L2 transaktionsbestilling

Governor sikrer transaktioner inden for et forslag udføres i rækkefølge. Men når disse transaktioner involverer transaktioner på tværs af kæden, garanterer dette blot, at de når frem til L1-brokontrakten i den rigtige rækkefølge. I Arbitrum-sagen kan de ombestilles, før de færdiggøres på L2. Derfor bør styringsforslag konstrueres for at tillade muligheden for omarrangerede L2-transaktioner.

Update: Fast fra commit 0fb2e7b in PR3703. Det GovernorHub kan nu videresende en række L2-transaktioner.

Konklusion

To kritiske problemer blev fundet i kodebasen. Der er fundet et middelsværhedsproblem og flere mindre sårbarheder, og anbefalinger til rettelser er blevet foreslået.

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