Uma Audit – Fase 6

Introduksjon

UMA er en plattform som lar brukere inngå tillitsminimerte finansielle kontrakter på Ethereum-blokkjeden. Vi har tidligere revidert det desentraliserte oraklet, en bestemt finansiell kontraktsmal, noen ad hoc pull-forespørsler, den evigvarende flerpartsmalen, ulike inkrementelle pull-forespørsler over et lengre engasjement og den forsikrede broen.

I denne revisjonen gjennomgikk vi en ny styringsforslagskontrakt, en mekanisme for å utvide UMA-økosystemet på tvers av flere kjeder, en mekanisme for å distribuere belønninger til ERC721-tokenholdere i samsvar med en off-chain-spesifikasjon, og en oppdatering av den forsikrede broen for å støtte WETH på Optimisme-kjeden.

Den reviderte forpliktelsen er 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc og omfanget inkluderer følgende kontrakter:

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

Vi har også gjennomgått endringene i solidity-filer i Trekk forespørsel 3611.

Alle eksterne kode- og kontraktsavhengigheter ble antatt å fungere som dokumentert.

Systemoversikt

Den nåværende Governance kontrakten lar Risk Labs Foundation foreslå nye styringshandlinger som kan ratifiseres av UMA-tokenholderne. Den nye Proposer Kontrakten er ment å ta forslagsstillerrollen, slik at alle kan komme med nye forslag så lenge de gir en binding som vil bli ofret hvis forslaget mislykkes. Det er ingen spesifikke insentiv for å komme med forslag. Hensikten er å sikre at bare de handlingene som med stor sannsynlighet vil bli akseptert vil bli foreslått.

Den nye tverrkjedemekanismen gjør at styringsforslag kan overføres fra Ethereum-nettverket til Optimism- og Arbitrum-kjedene. På denne måten kan UMA-styringsmekanismen på lag 1 brukes til å styre UMA-kontrakter på de støttede lag 2-kjedene. Mekanismen gjør det også mulig å videresende prisforespørsler og oppløsninger mellom lagene, slik at Optimistic Oracles på lag 2-kjedene kan sikres av mainnet Data Verification Mechanism på samme måte som lag 1 Optimistic Oracle er sikret av DVM.

Det er verdt å merke seg at disse meldingene sendes ved hjelp av den opprinnelige bromekanikken, noe som betyr at de er begrenset av egenskapene til de relevante lag 2-kjedene. Spesielt kan meldingene fra lag 2 til lag 1 ta en uke eller lenger å passere broen. Dessuten støtter UMA-styringsmekanismen forslag som inkluderer flere bestilte transaksjoner, men dette begrenser bare rekkefølgen de kan legges til i broen. Det er mulig for noen av disse transaksjonene å bli utført i en annen rekkefølge, eller ikke i det hele tatt, på lag 2.

Optimistic Rewarder-kontrakten preger ganske enkelt ERC721-tokens for alle som ber om dem. Den lar også hvem som helst assosiere vilkårlige data med et hvilket som helst token, og å sette inn ulike ERC20-tokens som skal distribueres som belønninger. Tolkningen av de vilkårlige dataene og den forventede fordelingen av belønninger blant token-innehaverne bestemmes ved hjelp av en uspesifisert prosedyre utenfor kjeden. Hvem som helst kan påstå at et spesifikt ERC721-token skylder et sett med belønninger hvis de er villige til å sette inn en obligasjon. Standard Optimistic Oracle-mekanismen brukes til å tillate noen andre å bestride kravet, som vil bli løst av DVM. Krav som ikke er bestridt i tide, antas å være gyldige, og kontrakten fordeler belønningene deretter. Den eneste begrensningen (for å forenkle regnskapet) er at orakelobligasjonstokenet ikke kan brukes som belønningstoken.

Til slutt endrer PR3611 den forsikrede bromekanismen for å unngå å sende WETH over Optimism-tokenbroen, som ikke støttes. I stedet pakkes eventuell L2 WETH som er deponert i Optimism-depotet ut til L2 ETH før den passerer broen. På lag 1 konverteres ETH til WETH før den videresendes til WETH brobasseng.

Kritisk alvorlighetsgrad

[C01] Kan ikke bestride ugyldig belønning

Når du bestrider en belønningsforespørsel, OptimisticRewardBase kontrakt først utløser et forslag på SkinnyOptimisticOracle og deretter bestrider forslaget. Imidlertid forslaget setter utløpstiden som en forskyvning fra gjeldende (tvist)tidspunkt, mens tvisten spesifiserer utløpet som en forskyvning fra tidspunktet for den opprinnelige belønningsforespørselen. I de fleste tilfeller vil dette avviket hindre oraklet i å identifisere forslaget som skal bestrides, noe som betyr at gyldige tvister ikke vil bli behandlet og ugyldige belønningsforespørsler vil bli akseptert.

Vurder å oppdatere tvistepåkallelsen for å spesifisere forslaget som skal bestrides korrekt.

Oppdatering: Fast fra og med commit 9e15557 in PR3690.

[C02] Løs forslag gjentatte ganger

De resolveProposal funksjon av Proposer kontrakt rett og slett bekrefter at oraklet har løst seg, men sjekker ikke om obligasjonen er fordelt. Dette betyr at det samme forslaget kan løses flere ganger, noe som resulterer i dupliserte obligasjonsbetalinger. Vurder å flagge eller slette eksisterende forslag når de er løst.

Oppdatering: Fast fra og med commit b152718 in PR3689.

Høy alvorlighetsgrad

Ingen.

Middels alvorlighetsgrad

[M01] Feil hendelsesparametere

De OptimisticRewarderBase kontrakt definerer en Requested hendelse som slippes ut fra requestRedemption funksjon når en innløsning blir bedt om. Denne hendelsen er definert til å sende ut utløpstidspunktet for innløsningen som siste parameter. Derimot, når hendelsen sendes ut, den siste parameteren er feil satt til nåværende tid.

Tilsvarende Redeemed hendelse leser utløpstiden etter at posten er slettet, så den blir feil satt til null.

Gitt at denne hendelsen kan brukes til å utløse beregninger utenfor kjeden, bør du vurdere å oppdatere den utsendte verdien på riktig måte.

Oppdatering: Fast fra og med commit f04eef9 in PR3694.

Lav alvorlighetsgrad

[L01] Mangel på hendelsesutslipp etter å ha bestridt en innløsning

De OptimisticRewarderBase kontrakt definerer en Disputed hendelse som er ment å utløses hvis en innløsning er omtvistet. Denne hendelsen sendes imidlertid ikke ut innenfor eller utenfor OptimisticRewarderBase kontrakt.

Vurder å sende ut hendelsen etter at sensitive endringer finner sted i dispute funksjon, for å lette sporing og varsle klienter utenfor kjeden etter kontraktenes aktivitet.

Oppdatering: Fast fra og med commit c275e92 in PR3695.

[L02] Inkonsekvent tilbakeføringsvakt

De Optimism_ParentMessenger og Arbitrum_ParentMessenger kontrakter gjelder inkonsekvent nonReentrant modifikator. Vurder å inkludere det på alle offentlige funksjoner.

Oppdatering: Fast fra og med commit 6275c39 in PR3677.

[L03] Villedende kommentarer

Her er noen villedende kommentarer vi identifiserte under gjennomgangen vår:

• ChildMessengerConsumerInterface.sol:
  • Linje 5 sier "foreldrebud" i stedet for "barnebud"
• GovernorSpoke.sol:
  • Linjer 49-51 lenker til en Gnosis fil selv om kommentaren sier at kodebiten ble kopiert fra Governor.sol. I tillegg er ikke kodebiten identisk med den i Governor.sol

Oppdatering: Fast fra og med commit cc350f9 in PR3678.

[L04] Manglende hjelpedatastempel

Når du ber om en pris på OracleSpoke kontrakt, de oppgitte tilleggsdataene er stemplet med barnekjedeidentifikatoren. Imidlertid hasPrice og getPrice funksjoner stempler ikke tilleggsdataene når de identifiserer prisforespørselen. Dette tvinger innkallende kontrakter til å påføre stempelet selv, noe som forårsaker en inkonsistens mellom prisforespørselen og prisinnhentingsmekanismene. Vurder å bruke stempelet i hasPrice og getPrice funksjoner.

Oppdatering: Fast fra og med commit fdb845d in PR3668.

[L05] Manglende NatSpec-parameter

Mange funksjoner i OptimisticRewarderBase kontrakt mangler @return parameter i deres Natural Specification-kommentarer. Vurder å inkludere det for fullstendighet.

Oppdatering: Fast fra og med commit 8920f38 in PR3679.

[L06] Restgodtgjørelse

For å påkalle det optimistiske oraklet, OptimisticRewarderBase kontrakt gir det en symbolsk godtgjørelse, slik at det kan trekke obligasjonsbetalingene. Hvis forslaget mislykkes, belønningsinnløsningen kanselleres men godtgjørelsen tilbakestilles ikke. Derfor vil Optimistic Oracle beholde en unødvendig restgodtgjørelse til neste gang en tvist utløses. Vurder å tilbakekalle godtgjørelsen hvis forslaget mislykkes.

Oppdatering: Fast fra og med commit c2d444b in PR3698.

[L07] Ugyldig refusjonsadresse

Refusjons L2-adressen til Arbitrum_ParentMessenger er initialisert til kontraktseieren, som bør være L1-guvernøren. På samme måte setRefundL2Address har en kommentar som sier at det skal stilles til guvernøren. Men når du sender meldinger over broen, er denne verdien satt som L2-bruker, som er adressen på Arbitrum som mottar overskytende midler etter at billetten er løst. Siden L1-guvernøradressen ikke vil være tilgjengelig på Arbitrum, vil alle midler som sendes til denne adressen gå tapt.

Vurder å sette den til en gyldig L2-adresse.

Oppdatering: Fast fra og med commit b3f2dd1 in PR3687.

[L08] Mekanisme for å endre barnebude

De GovernorSpoke og OracleSpoke kontrakt hver initialiser den underordnede messenger i konstruktøren, uten noen mekanisme for å oppdatere den. Dette betyr at når barnebudet endres, begge eikkontraktene blir foreldet.

Siden eikerkontrakten sannsynligvis er mer stabile enn messengers, bør du vurdere å inkludere en mekanisme for å oppdatere messenger på eikene.

Oppdatering: Fast fra og med commit 7c9e061 in PR3688.

Merknader og tilleggsinformasjon

[N01] Endre obligasjonstoken

De Proposer kontrakt inkluderer en mekanisme for eieren å endre størrelsen på forslagsobligasjonen. Vurder om de også skal kunne endre obligasjonstoken. Merk at dette vil kreve en mekanisme for å identifisere riktig obligasjonsvaluta når eksisterende forslag er løst.

Oppdatering: Ikke et problem. UMAs uttalelse for denne saken:

N01 anbefaler at forslagsstillerkontrakten kan endre obligasjonstoken til noe annet enn UMA. Vi har ingen intensjon om å støtte andre token enn $UMA for denne funksjonen, og har derfor valgt å ikke gjøre noen endringer for dette problemet. Dessuten holder et enkelt token per kontrakt denne logikken så enkel som mulig. Til slutt, hvis det var nødvendig med en endring (i tilfelle av en token-migrering, for eksempel), kunne vi bare distribuere en ny forslagsstillerkontrakt med det andre tokenet og sette i gang et forslag om å migrere systemet for å bruke det.

[N02] Ufullstendig grensesnitt

De ChildMessengerInterface angir ikke en processMessageFromCrossChainParent funksjon, selv om den antas å eksistere av overordnede budbringere. Vurder å inkludere det for fullstendighet.

Oppdatering: Ikke fikset. UMAs uttalelse for denne saken:

Vi valgte med vilje å la dette grensesnittet være inkonsekvent da implementering av dette i ChildMessengerInterface bryter kompatibiliteten med Polygon_ChildMessenger, da Polygons metode for å behandle meldinger fra andre kjeder krever noe tilpasset logikk der en intern metode kalles _processMessageFromRoot.

[N03] Feil grensesnitt

De GovernorSpoke kontrakt feil bruker ChildMessengerConsumerInterface typen å beskrive det messenger variabel. Vurder å bruke ChildMessengerInterface i stedet.

Oppdatering: Fast fra og med commit f31a527 in PR3680.

[N04] Trekk tokens til Store

I en tidligere revisjon vi stilte spørsmål ved hensikten med Store kontraktens payOracleFeesErc20 funksjon (i utgave L19). UMA-teamet valgte å beholde funksjonen for å standardisere grensesnittet for potensielle fremtidige modifikasjoner. Siden formålet med funksjonen ikke er fullt spesifisert, er det uklart om den skal utløses når Proposer kontrakt inndrar en obligasjon. Den bør sannsynligvis brukes når OracleHub betaler for en prisforespørsel. Vurder om funksjonen skal brukes i begge scenariene.

Oppdatering: Anerkjente. UMAs uttalelse for denne saken:

N04 anbefaler å bruke butikkens payOracleFeeErc20-metode for å betale gebyrer i både forslagsstiller- og OracleHub-kontraktene for å være konsistente med Store-bruken. Vi har valgt å ikke bruke denne funksjonen da det ville bety å importere et ekstra grensesnitt (for butikken) og kreve casting av obligasjonsbeløpet til et FixedPoint (som også vil kreve en ekstra import. For å holde koden enkel og ren vi har valgt å ikke gjøre dette. OZ-tilbakemeldingen om payOracleFeeErc20 i revisjonsfase 1 i april 2020 var gyldig at denne metoden egentlig ikke er nyttig, noe som gjør denne typen integrasjon vanskeligere å resonnere rundt.

[N05] TODOs i kode

Det er "TODO"-kommentarer i kodebasen som bør spores i prosjektets problemstillinger. For eksempel:

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

Under utviklingen vil det å ha godt beskrevet "TODO"-kommentarer gjøre prosessen med å spore og løse dem enklere. Uten den informasjonen kan disse kommentarene ha en tendens til å råtne og viktig informasjon for sikkerheten til systemet kan være glemt når den slippes til produksjon.

Disse TODO-kommentarene bør ha en kort beskrivelse av oppgaven som venter på å utføre, og en lenke til det tilsvarende problemet i prosjektdepotet.

Vurder å oppdatere TODO-kommentarene for å legge til denne informasjonen. For fullstendighet og sporbarhet kan en signatur og et tidsstempel legges til. For eksempel:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Oppdatering: Fast fra og med commit 5d57b5b in PR3684.

[N06] Typografiske feil

Kodebasen inneholder følgende typografiske feil:

• på Admin_ChildMessenger kontrakt, impleenting bør være implementing
• på OptimisticRewarderBase kontrakt, timestap bør være timestamp.
• på OptimisticRewarderBase kontrakt, liveness liveness bør være liveness.
• på GovernorSpoke kontrakt, only called bør være only be called.
• på Optimism_ChildMessenger kontrakt:

Oppdatering: Fast fra og med commit 9b92b0b in PR3681.

[N07] Ubrukte importvarer

For å forbedre lesbarheten til koden bør du vurdere å fjerne følgende ubrukte importer:

Oppdatering: Fast fra og med commit 40b7221 in PR3682.

[N08] L2 transaksjonsbestilling

De Governor sikrer transaksjoner innenfor et forslag utføres i rekkefølge. Men når disse transaksjonene involverer transaksjoner på tvers av kjeder, garanterer dette bare at de kommer frem til L1-brokontrakten i riktig rekkefølge. I Arbitrum-saken kan de ombestilles før de er ferdigbehandlet på L2. Derfor bør styringsforslag konstrueres for å tillate muligheten for omorganiserte L2-transaksjoner.

Oppdatering: Fast fra og med commit 0fb2e7b in PR3703. De GovernorHub kan nå videresende en rekke L2-transaksjoner.

konklusjonen

To kritiske problemer ble funnet i kodebasen. Ett middels alvorlig problem og flere mindre sårbarheter er funnet, og anbefalinger for reparasjoner er foreslått.

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