Uma Audit – Fas 6

Beskrivning

UMA är en plattform som tillåter användare att ingå förtroendeminimerade finansiella kontrakt på Ethereum blockchain. Vi har tidigare granskat det decentraliserade oraklet, en särskild finansiell kontraktsmall, några ad hoc pull-förfrågningar, mallen Perpetual Multiparty, olika inkrementella pull-förfrågningar över ett längre engagemang och den försäkrade bron.

I denna granskning granskade vi ett nytt förslag till förvaltningsavtal, en mekanism för att utöka UMA-ekosystemet över flera kedjor, en mekanism för att distribuera belöningar till ERC721-tokeninnehavare i enlighet med en off-chain-specifikation och en uppdatering av den försäkrade bron för att stödja WETH på Optimismkedjan.

Det granskade åtagandet är 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc och omfattningen inkluderar följande kontrakt:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (exklusive test- och polygonkontrakt)
• financial-templates/optimistic-rewarder/* (exklusive testkontrakt)

Vi har också granskat ändringarna av solidity-filer i Dra förfrågan 3611.

Alla externa kod- och kontraktsberoenden antogs fungera som dokumenterat.

System översikt

Den nuvarande Governance kontraktet tillåter Risk Labs Foundation att föreslå nya styrningsåtgärder som kan ratificeras av UMA-tokeninnehavarna. Den nya Proposer kontraktet är avsett att ta rollen som förslagsställare, vilket gör det möjligt för vem som helst att lägga fram nya förslag så länge de ger en garanti som kommer att offras om förslaget misslyckas. Det finns inga särskilda incitament för att lägga fram förslag. Avsikten är att säkerställa att endast de åtgärder som med stor sannolikhet kommer att accepteras kommer att föreslås.

Den nya tvärkedjemekanismen gör det möjligt för styrelseförslag att överföras från Ethereums huvudnät till Optimism- och Arbitrum-kedjorna. På detta sätt kan UMA-styrningsmekanismen på lager 1 användas för att styra UMA-kontrakt på de stödda lager 2-kedjorna. Mekanismen tillåter också att prisförfrågningar och upplösningar vidarebefordras mellan lagren, så Optimistic Oracles på lager 2-kedjorna kan säkras av mainnet Data Verification Mechanism på samma sätt som lager 1 Optimistic Oracle säkras av DVM.

Det är värt att notera att dessa meddelanden skickas med hjälp av den ursprungliga bryggmekaniken, vilket innebär att de begränsas av egenskaperna hos de relevanta lager 2-kedjorna. I synnerhet kan meddelanden från lager 2 till lager 1 ta en vecka eller längre att passera bron. Dessutom stöder UMA-styrningsmekanismen förslag som inkluderar flera beställda transaktioner, men detta begränsar bara i vilken ordning de kan läggas till i bryggan. Det är möjligt för vissa av dessa transaktioner att utföras i en annan ordning, eller inte alls, på lager 2.

Optimistic Rewarder-kontraktet skapar helt enkelt ERC721-tokens för alla som begär dem. Det tillåter också vem som helst att associera godtycklig data med vilken token som helst och att sätta in olika ERC20-tokens för att delas ut som belöningar. Tolkningen av de godtyckliga uppgifterna och den förväntade fördelningen av belöningar mellan tokeninnehavarna bestäms med hjälp av en ospecificerad procedur utanför kedjan. Vem som helst kan göra anspråk på att en specifik ERC721-token är skyldig en uppsättning belöningar om de är villiga att sätta in en obligation. Standardmekanismen för Optimistic Oracle används för att tillåta någon annan att bestrida anspråket, vilket kommer att lösas av DVM. Anspråk som inte bestrids i tid antas vara giltiga, och avtalet fördelar belöningen därefter. Den enda begränsningen (för att förenkla redovisningen) är att oracle bond token inte kan användas som en belöning token.

Slutligen modifierar PR3611 den försäkrade bryggmekanismen för att undvika att skicka WETH över Optimism-tokenbryggan, som inte stöds. Istället packas eventuell L2 WETH som deponeras i Optimism-depån upp till L2 ETH innan den passerar bron. På lager 1 omvandlas ETH till WETH innan den vidarebefordras till WETH-bryggpoolen.

Kritisk svårighetsgrad

[C01] Kan inte bestrida ogiltig belöning

När du bestrider en begäran om belöning, OptimisticRewardBase kontrakt först utlöser ett förslag på SkinnyOptimisticOracle och då bestrider det förslaget. Dock förslaget ställer in utgångstiden som en förskjutning från den aktuella (tvist)tiden, medan tvisten anger utgången som en offset från tidpunkten för den ursprungliga belöningsbegäran. I de flesta fall kommer denna diskrepans att hindra oraklet från att identifiera förslaget som ska bestridas, vilket innebär att giltiga tvister inte kommer att behandlas och ogiltiga belöningsförfrågningar kommer att accepteras.

Överväg att uppdatera tvistanropet för att korrekt specificera förslaget som ska bestridas.

Uppdatering: Fast från och med commit 9e15557 in PR3690.

[C02] Lös förslag upprepade gånger

Smakämnen resolveProposal funktion av Proposer kontrakt bekräftar helt enkelt att oraklet har löst sig, men kontrollerar inte om obligationen har delats ut. Detta innebär att samma förslag kan lösas flera gånger, vilket resulterar i dubbla obligationsbetalningar. Överväg att flagga eller ta bort befintliga förslag när de är lösta.

Uppdatering: Fast från och med commit b152718 in PR3689.

Hög svårighetsgrad

Inga.

Medel svårighetsgrad

[M01] Felaktiga händelseparametrar

Smakämnen OptimisticRewarderBase kontrakt definierar en Requested händelse som emitteras från requestRedemption funktion när en inlösen begärs. Denna händelse är definierad för att avge förfallotiden för inlösen som dess sista parameter. Dock, när händelsen sänds ut, dess sista parameter är felaktigt inställd på aktuell tid.

På samma sätt Redeemed händelse läser utgångstiden efter att posten raderats, så den kommer att vara felaktigt inställd på noll.

Med tanke på att denna händelse kan användas för att utlösa beräkningar utanför kedjan, överväg att uppdatera det utsända värdet på lämpligt sätt.

Uppdatering: Fast från och med commit f04eef9 in PR3694.

Låg svårighetsgrad

[L01] Brist på händelseutsläpp efter att ha bestridit en inlösen

Smakämnen OptimisticRewarderBase kontrakt definierar en Disputed händelse som är avsedd att utlösas om en inlösen bestrids. Denna händelse sänds dock inte ut inom eller utanför OptimisticRewarderBase avtal.

Överväg att sända händelsen efter att känsliga förändringar har skett i dispute fungera, för att underlätta spårning och meddela kunder utanför kedjan efter kontraktens aktivitet.

Uppdatering: Fast från och med commit c275e92 in PR3695.

[L02] Inkonsekvent återinträdesvakt

Smakämnen Optimism_ParentMessenger och Arbitrum_ParentMessenger kontrakt tillämpar inkonsekvent nonReentrant modifierare. Överväg att inkludera det på alla offentliga funktioner.

Uppdatering: Fast från och med commit 6275c39 in PR3677.

[L03] Vilseledande kommentarer

Här är några vilseledande kommentarer som vi identifierade under vår granskning:

• ChildMessengerConsumerInterface.sol:
  • Linje 5 säger "förälderbud" istället för "barnbud"
• GovernorSpoke.sol:
  • Linjer 49-51 länkar till en Gnosis fil trots att kommentaren säger att kodavsnittet kopierades från Governor.sol. Dessutom är kodavsnittet inte identiskt med det i Governor.sol

Uppdatering: Fast från och med commit cc350f9 in PR3678.

[L04] Tilläggsdatastämpel saknas

När du begär ett pris på OracleSpoke kontrakt, de tillhandahållna tilläggsuppgifterna är stämplat med den underordnade kedjans identifierare. Men den hasPrice och getPrice funktioner stämplar inte extradata när prisförfrågan identifieras. Detta tvingar anropande kontrakt att själva applicera stämpeln, vilket orsakar en inkonsekvens mellan prisförfrågan och prisåterställningsmekanismer. Överväg att applicera stämpeln i hasPrice och getPrice funktioner.

Uppdatering: Fast från och med commit fdb845d in PR3668.

[L05] Saknar NatSpec-parameter

Många funktioner i OptimisticRewarderBase kontrakt saknar @return parametern i deras Natural Specification-kommentarer. Överväg att inkludera det för fullständighetens skull.

Uppdatering: Fast från och med commit 8920f38 in PR3679.

[L06] Restbidrag

För att åberopa det optimistiska oraklet, OptimisticRewarderBase kontrakt ger det ett symboliskt bidrag, så det kan dra obligationsbetalningarna. Om förslaget misslyckas, belöningsinlösen avbryts men ersättningen återställs inte. Därför kommer Optimistic Oracle att behålla en onödig restersättning tills nästa gång en tvist utlöses. Överväg att dra in bidraget om förslaget misslyckas.

Uppdatering: Fast från och med commit c2d444b in PR3698.

[L07] Ogiltig återbetalningsadress

Återbetalning L2-adressen för Arbitrum_ParentMessenger initieras till kontraktsägaren, som bör vara L1-guvernören. På samma sätt setRefundL2Address har en kommentar anger att det bör ställas till guvernören. Men när meddelanden skickas över bryggan är detta värde inställd som L2-användare, vilket är adressen på Arbitrum som tar emot överskjutande medel efter att biljetten är löst. Eftersom L1-guvernörsadressen inte kommer att vara tillgänglig på Arbitrum, kommer alla medel som skickas till denna adress att gå förlorade.

Överväg att ställa in den till en giltig L2-adress.

Uppdatering: Fast från och med commit b3f2dd1 in PR3687.

[L08] Mekanism för att byta barnbudbärare

Smakämnen GovernorSpoke och OracleSpoke kontrakt varje initialisera den underordnade budbäraren i konstruktorn, utan någon mekanism för att uppdatera den. Detta innebär att när barnbudet ändras, båda ekerkontrakten blir föråldrade.

Eftersom ekerkontraktet sannolikt är mer stabilt än budbärarna, överväg att inkludera en mekanism för att uppdatera budbäraren på ekrarna.

Uppdatering: Fast från och med commit 7c9e061 in PR3688.

Anteckningar och ytterligare information

[N01] Byt obligationsbevis

Smakämnen Proposer kontrakt omfattar en mekanism för ägaren att ändra storleken på förslagsförbindelsen. Fundera på om de också ska kunna ändra obligationstoken. Observera att detta skulle kräva en mekanism för att identifiera den korrekta obligationsvalutan när befintliga förslag är lösta.

Uppdatering: Inte ett problem. UMA:s uttalande för denna fråga:

N01 rekommenderar att man gör det möjligt för förslagsställarens kontrakt att ändra obligationstoken till något annat än UMA. Vi har inte för avsikt att stödja någon annan token än $UMA för den här funktionen och har därför valt att inte göra några ändringar för det här problemet. Dessutom håller en enda token per kontrakt denna logik så enkel som möjligt. Slutligen, om en ändring behövdes (till exempel vid en tokenmigrering), kunde vi bara distribuera ett nytt förslagsställarkontrakt med den andra tokenen och initiera ett förslag om att migrera systemet för att använda det.

[N02] Ofullständigt gränssnitt

Smakämnen ChildMessengerInterface anger inte a processMessageFromCrossChainParent funktion, även om den antas existera av föräldrabudbärare. Överväg att inkludera det för fullständighetens skull.

Uppdatering: Inte fixad. UMA:s uttalande för denna fråga:

Vi valde avsiktligt att lämna detta gränssnitt inkonsekvent eftersom implementering av detta inom ChildMessengerInterface bryter kompatibiliteten med Polygon_ChildMessenger eftersom Polygons metod för att bearbeta meddelanden från andra kedjor kräver något anpassad logik där en intern metod kallas _processMessageFromRoot.

[N03] Felaktigt gränssnitt

Smakämnen GovernorSpoke kontrakt felaktigt använder ChildMessengerConsumerInterface Typ att beskriva dess messenger variabel. Överväg att använda ChildMessengerInterface istället.

Uppdatering: Fast från och med commit f31a527 in PR3680.

[N04] Dra polletter till Store

I en tidigare revision vi ifrågasatte syftet med Store kontrakt payOracleFeesErc20 fungera (i nummer L19). UMA-teamet valde att behålla funktionen att standardisera gränssnittet för potentiella framtida ändringar. Eftersom syftet med funktionen inte är helt specificerat är det oklart om den ska utlösas när Proposer kontrakt beslagtar en borgen. Det bör troligen användas när OracleHub betalar för en prisförfrågan. Fundera på om funktionen ska användas i något av scenarierna.

Uppdatering: Erkänd. UMA:s uttalande för denna fråga:

N04 rekommenderar att du använder butikens payOracleFeeErc20-metod för att betala avgifter i både förslagsställaren och OracleHub-kontrakten för att överensstämma med butiksanvändningen. Vi har valt att inte använda den här funktionen eftersom det skulle innebära att behöva importera ett extra gränssnitt (för butiken) och kräva casting av obligationsbeloppet till en FixedPoint (vilket också skulle kräva en extra import. För att hålla koden enkel och ren vi har valt att inte göra detta OZ-feedbacken om payOracleFeeErc20 i revisionsfas 1 i april 2020 var giltig att den här metoden inte är riktigt användbar, vilket gör den här typen av integration svårare att resonera kring.

[N05] TODOs i kod

Det finns "TODO"-kommentarer i kodbasen som bör spåras i projektets problembacklog. Till exempel:

• linje 37 of Arbitrum_ParentMessenger kontrakt
• linje 25 of Optimism_ChildMessenger kontrakt
• Linjer 83 och 146 of OracleHub avtal.

Under utvecklingen kommer väl beskrivna "TODO"-kommentarer att göra processen att spåra och lösa dem lättare. Utan den informationen kan dessa kommentarer tendera att ruttna och viktig information för systemets säkerhet kan glömmas bort när den släpps till produktion.

Dessa TODO-kommentarer bör ha en kort beskrivning av den pågående uppgiften och en länk till motsvarande problem i projektförrådet.

Överväg att uppdatera TODO-kommentarerna för att lägga till denna information. För fullständighet och spårbarhet kan en signatur och en tidsstämpel läggas till. Till exempel:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Uppdatering: Fast från och med commit 5d57b5b in PR3684.

[N06] Typografiska fel

Kodbasen innehåller följande typografiska fel:

• I Admin_ChildMessenger avtal, impleenting bör vara implementing
• I OptimisticRewarderBase avtal, timestap bör vara timestamp.
• I OptimisticRewarderBase avtal, liveness liveness bör vara liveness.
• I GovernorSpoke avtal, only called bör vara only be called.
• I Optimism_ChildMessenger kontrakt:

Uppdatering: Fast från och med commit 9b92b0b in PR3681.

[N07] Oanvänd import

För att förbättra läsbarheten för koden, överväg att ta bort följande oanvända importer:

Uppdatering: Fast från och med commit 40b7221 in PR3682.

[N08] L2 transaktionsbeställning

Smakämnen Governor säkerställer transaktioner inom ett förslag utförs i ordning. Men när dessa transaktioner involverar transaktioner över kedjan, garanterar detta bara att de kommer fram till L1-bryggkontraktet i rätt ordning. I Arbitrum-fallet kan de beställas om innan de slutförs på L2. Därför bör förvaltningsförslag utformas för att möjliggöra möjligheten till omordnade L2-transaktioner.

Uppdatering: Fast från och med commit 0fb2e7b in PR3703. De GovernorHub kan nu vidarebefordra en rad L2-transaktioner.

Slutsats

Två kritiska problem hittades i kodbasen. Ett medelsvårt problem och flera mindre sårbarheter har hittats, och rekommendationer för korrigeringar har föreslagits.

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