Uma Audit – vaihe 6

esittely

UMA on alusta, jonka avulla käyttäjät voivat tehdä luotettavuusminimoituja rahoitussopimuksia Ethereum-lohkoketjussa. Olemme auditoineet aiemmin hajautettu oraakkeli, tietty rahoitussopimusmalli, joitakin ad hoc -vetopyyntöjä, Perpetual Multiparty -malli, erilaisia ​​inkrementaalisia vetopyyntöjä pidemmän sitoutumisen aikana ja vakuutettu silta.

Tässä tarkastuksessa tarkastelimme uutta hallintoehdotussopimusta, mekanismia UMA-ekosysteemin laajentamiseksi useisiin ketjuihin, mekanismin palkkioiden jakamiseksi ERC721-merkkien haltijoille ketjun ulkopuolisen eritelmän mukaisesti sekä päivityksen vakuutettuun siltaan WETH:n tukemiseksi. Optimismi-ketjussa.

Tarkastettu sitoumus on 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc ja soveltamisalaan kuuluvat seuraavat sopimukset:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (pois lukien testi- ja polygonisopimukset)
• financial-templates/optimistic-rewarder/* (pois lukien testisopimukset)

Tarkastimme myös solidity-tiedostojen muutokset Vedä pyyntö 3611.

Kaikkien ulkoisten koodien ja sopimusten riippuvuuksien oletettiin toimivan dokumentoidusti.

Järjestelmäkatsaus

Nykyisen Governance Sopimuksen ansiosta Risk Labs Foundation voi ehdottaa uusia hallintotoimia, jotka UMA-tunnuksen haltijat voivat ratifioida. Uusi Proposer Sopimus on tarkoitettu ottamaan ehdotuksen tekijän rooli, jolloin kuka tahansa voi tehdä uusia ehdotuksia, kunhan ne tarjoavat takuun, joka uhrataan, jos ehdotus epäonnistuu. Ehdotusten tekemiseen ei ole erityistä kannustinta. Tarkoituksena on varmistaa, että vain sellaisia ​​toimia ehdotetaan, jotka erittäin todennäköisesti hyväksytään.

Uusi ketjujen välinen mekanismi mahdollistaa hallintoehdotuksen siirtämisen Ethereumin verkkoverkosta Optimism- ja Arbitrum-ketjuihin. Tällä tavalla kerroksen 1 UMA-hallintamekanismia voidaan käyttää ohjaamaan UMA-sopimuksia tuetuissa kerroksen 2 ketjuissa. Mekanismi mahdollistaa myös hintapyyntöjen ja päätöslauselmien välittämisen kerrosten välillä, joten kerroksen 2 ketjujen Optimistic Oracle voidaan suojata verkkotietojen varmistusmekanismilla samalla tavalla kuin kerroksen 1 Optimistic Oracle on suojattu DVM:llä.

On syytä huomata, että nämä viestit lähetetään käyttämällä alkuperäistä siltamekaniikkaa, mikä tarkoittaa, että niitä rajoittavat asiaankuuluvien kerroksen 2 ketjujen ominaisuudet. Erityisesti viestit kerroksesta 2 kerrokseen 1 voivat kestää viikon tai pidempään, ennen kuin ne kulkevat sillan läpi. Lisäksi UMA-hallintamekanismi tukee ehdotuksia, jotka sisältävät useita tilattuja tapahtumia, mutta tämä vain rajoittaa järjestystä, jossa ne voidaan lisätä siltaan. On mahdollista, että jotkin näistä tapahtumista suoritetaan eri järjestyksessä tai ei ollenkaan, tasolla 2.

Optimistic Rewarder -sopimus yksinkertaisesti lyö ERC721-rahakkeita kaikille, jotka niitä pyytävät. Sen avulla kuka tahansa voi liittää mielivaltaisia ​​tietoja mihin tahansa tunnukseen ja tallettaa erilaisia ​​ERC20-tokeneita jaettavaksi palkintoina. Satunnaisten tietojen tulkinta ja odotettu palkkioiden jakautuminen tokeninhaltijoiden kesken määritetään määrittelemättömällä ketjun ulkopuolisella menettelyllä. Kuka tahansa voi väittää, että tietty ERC721-tunnus on velkaa joukon palkintoja, jos hän on valmis tallettamaan joukkovelkakirjalainan. Normaalia Optimistic Oracle -mekanismia käytetään antamaan joku muu kiistaa vaatimuksen, jonka DVM ratkaisee. Vaatimukset, joita ei ole riitautettu ajoissa, oletetaan päteviksi, ja sopimus jakaa palkkiot sen mukaisesti. Ainoa rajoitus (kirjanpidon yksinkertaistamiseksi) on, että Oracle Bond -merkkiä ei voi käyttää palkkion tunnuksena.

Lopuksi PR3611 muokkaa vakuutettua siltamekanismia välttääkseen WETH:n lähettämisen Optimism-merkkisillan yli, jota ei tueta. Sen sijaan Optimismin säilytyslaatikkoon talletettu L2 WETH puretaan L2 ETH:hen ennen sillan kulkemista. Kerroksella 1 ETH muunnetaan WETH:ksi ennen kuin se lähetetään edelleen WETH-siltavaraan.

Kriittinen vakavuus

[C01] Virheellistä palkintoa ei voi kiistää

Kun riitautat palkintopyynnön, OptimisticRewardBase sopimus ensin käynnistää ehdotuksen på den SkinnyOptimisticOracle ja sitten kiistää ehdotuksen. Ehdotus kuitenkin asettaa vanhenemisajan kuin offset nykyisestä (riita) aikaa, kun riita määrittää vanhenemisajan vähennyksenä alkuperäisen palkkiopyynnön ajankohdasta. Useimmissa tapauksissa tämä ristiriita estää oraakkelia tunnistamasta kiistanalaista ehdotusta, mikä tarkoittaa, että päteviä kiistoja ei käsitellä ja virheelliset palkintopyynnöt hyväksytään.

Harkitse kiistautuskutsun päivittämistä kiistanalaisen ehdotuksen määrittämiseksi oikein.

Päivitys: Korjattu sitoumuksesta 9e15557 in PR3690.

[C02] Ratkaise ehdotukset toistuvasti

- resolveProposal toiminto Proposer sopimus yksinkertaisesti vahvistaa että oraakkeli on ratkaissut, mutta ei tarkista, onko joukkovelkakirja jaettu. Tämä tarkoittaa, että sama ehdotus voidaan ratkaista useita kertoja, mikä johtaa päällekkäisiin joukkovelkakirjamaksuihin. Harkitse olemassa olevien ehdotusten merkitsemistä tai poistamista, kun ne on ratkaistu.

Päivitys: Korjattu sitoumuksesta b152718 in PR3689.

Erittäin vakava

Ei mitään.

Keskivaikea

[M01] Virheelliset tapahtumaparametrit

- OptimisticRewarderBase sopimus määrittelee a Requested tapahtumaa varten joka säteilee requestRedemption toimintoa, kun lunastusta pyydetään. Tämä tapahtuma on määritetty lähettämään lunastusajan päättymisaika viimeisenä parametrinaan. Kuitenkin, kun tapahtuma lähetetään, sen viimeinen parametri on asetettu väärin arvoon nykyinen aika.

Samoin Redeemed tapahtumaa varten lukee vanhenemisajan tietueen poistamisen jälkeen, joten se asetetaan väärin nollaan.

Koska tätä tapahtumaa voidaan käyttää ketjun ulkopuolisten laskelmien käynnistämiseen, harkitse lähetetyn arvon päivittämistä asianmukaisesti.

Päivitys: Korjattu sitoumuksesta f04eef9 in PR3694.

Matala vakavuus

[L01] Tapahtumalähetyksen puuttuminen lunastuksen kiistämisen jälkeen

- OptimisticRewarderBase sopimus määrittelee a Disputed tapahtumaa varten joka on tarkoitus käynnistää, jos lunastus kiistaa. Tätä tapahtumaa ei kuitenkaan lähetetä sen sisällä tai ulkopuolella OptimisticRewarderBase sopimus.

Harkitse tapahtuman lähettämistä sen jälkeen, kun arkaluontoiset muutokset tapahtuvat dispute toiminto, helpottaa seurantaa ja ilmoittaa ketjun ulkopuolisille asiakkaille sopimusten toiminnasta.

Päivitys: Korjattu sitoumuksesta c275e92 in PR3695.

[L02] Epäjohdonmukainen paluuvalvonta

- Optimism_ParentMessenger ja Arbitrum_ParentMessenger sopimuksia sovelletaan epäjohdonmukaisesti nonReentrant muuntaja. Harkitse sen sisällyttämistä kaikkiin julkisiin toimintoihin.

Päivitys: Korjattu sitoumuksesta 6275c39 in PR3677.

[L03] Harhaanjohtavat kommentit

Tässä on joitain harhaanjohtavia kommentteja, jotka havaitsimme tarkistuksen aikana:

• ChildMessengerConsumerInterface.sol:
  • line 5 sanoo "vanhemman sanansaattaja" "lapsiviestintä" sijaan
• GovernorSpoke.sol:
  • Rivit 49-51 linkit osoitteeseen a Gnosis tiedostoa, vaikka kommentissa sanotaan, että katkelma on kopioitu Governor.sol. Lisäksi katkelma ei ole identtinen sisällä olevan katkelman kanssa Governor.sol

Päivitys: Korjattu sitoumuksesta cc350f9 in PR3678.

[L04] Lisätietoleima puuttuu

Kun pyydät hintaa OracleSpoke sopimus, toimitetut liitetiedot on leimattu lapsiketjun tunnisteen kanssa. Kuitenkin hasPrice ja getPrice toiminnot eivät leimaa oheistietoja hintapyyntöä tunnistaessaan. Tämä pakottaa solmittavat sopimukset kiinnittämään leiman itse, mikä aiheuttaa epäjohdonmukaisuuden hintapyynnön ja hinnan hakumekanismien välillä. Harkitse leiman käyttöä hasPrice ja getPrice toiminnot.

Päivitys: Korjattu sitoumuksesta fdb845d in PR3668.

[L05] Puuttuva NatSpec-parametri

Monet toiminnot OptimisticRewarderBase sopimus puuttuvat @return parametrin Natural Specification -kommenteissaan. Harkitse sen sisällyttämistä täydellisyyden vuoksi.

Päivitys: Korjattu sitoumuksesta 8920f38 in PR3679.

[L06] Jäännöslisä

Optimistisen oraakkelin luomiseksi OptimisticRewarderBase sopimus myöntää sille symbolisen korvauksen, joten se voi vetää joukkovelkakirjamaksut. Jos ehdotus epäonnistuu, palkinnon lunastus peruutetaan mutta korvausta ei nollata. Siksi Optimistinen Oraakkeli säilyttää tarpeettoman jäännösmäärän, kunnes seuraava riita käynnistetään. Harkitse korvauksen peruuttamista, jos ehdotus epäonnistuu.

Päivitys: Korjattu sitoumuksesta c2d444b in PR3698.

[L07] Virheellinen palautusosoite

Hyvityksen L2-osoite Arbitrum_ParentMessenger on alustettu sopimuksen omistajalle, jonka pitäisi olla L1-kuvernööri. Samoin, setRefundL2Address on kommentti toteamalla, että se pitäisi asettaa kuvernöörille. Kuitenkin, kun viestejä välitetään sillan yli, tämä arvo on asetettu L2-käyttäjäksi, joka on Arbitrumin osoite, joka saa ylimääräiset varat lipun ratkaisemisen jälkeen. Koska L1-kuvernöörin osoite ei ole käytettävissä Arbitrumissa, kaikki tähän osoitteeseen lähetetyt varat menetetään.

Harkitse sen asettamista kelvolliseen L2-osoitteeseen.

Päivitys: Korjattu sitoumuksesta b3f2dd1 in PR3687.

[L08] Mekanismi lapsilähettäjien vaihtamiseksi

- GovernorSpoke ja OracleSpoke sopimus alustaa alilähettimen rakentajassa ilman mekanismia sen päivittämiseksi. Tämä tarkoittaa, että kun lapsiviestintä vaihtuu, molemmat puolasopimukset ovat vanhentuneet.

Koska pinnan sopimus on todennäköisesti vakaampi kuin lähettimet, harkitse mekanismin sisällyttämistä lähettimen päivittämiseksi pinnoihin.

Päivitys: Korjattu sitoumuksesta 7c9e061 in PR3688.

Huomautuksia ja lisätietoja

[N01] Vaihda joukkovelkakirjatunnus

- Proposer sopimus sisältää mekanismi omistaja muuttaa ehdotetun takuun kokoa. Mieti, pitäisikö heidän myös pystyä vaihtamaan joukkovelkakirjamerkkiä. Huomaa, että tämä vaatisi mekanismin oikean joukkovelkakirjavaluutan tunnistamiseksi, kun olemassa olevat ehdotukset ratkaistaan.

Päivitys: Ei ole ongelma. UMA:n lausunto tästä aiheesta:

N01 suosittelee, että ehdottajan sopimus sallitaan vaihtaa joukkovelkakirjamerkki johonkin muuhun kuin UMA:han. Meillä ei ole aikomusta tukea mitään muuta tokenia kuin $UMA tälle toiminnolle, joten olemme päättäneet olla tekemättä muutoksia tähän ongelmaan. Lisäksi yksi tunnus per sopimus pitää tämän logiikan mahdollisimman yksinkertaisena. Lopuksi, jos muutosta tarvitaan (esimerkiksi tunnuksen siirron tapauksessa), voisimme vain ottaa käyttöön uuden ehdotussopimuksen toisen tunnuksen kanssa ja käynnistää ehdotuksen järjestelmän siirtämisestä käyttämään sitä.

[N02] Epätäydellinen käyttöliittymä

- ChildMessengerInterface ei määrittele a processMessageFromCrossChainParent toiminto, vaikka vanhempien lähettiläiden oletetaan sen olevan olemassa. Harkitse sen sisällyttämistä täydellisyyden vuoksi.

Päivitys: Ei korjattu. UMA:n lausunto tästä aiheesta:

Päätimme tarkoituksella jättää tämän käyttöliittymän epäjohdonmukaiseksi, koska sen toteuttaminen ChildMessengerInterfacessa rikkoo yhteensopivuuden Polygon_ChildMessengerin kanssa, koska Polygonin menetelmä muiden ketjujen viestien käsittelyyn vaatii jonkin verran mukautettua logiikkaa, jossa sisäistä menetelmää kutsutaan nimellä _processMessageFromRoot.

[N03] Väärä käyttöliittymä

- GovernorSpoke sopimus väärin käyttää ChildMessengerConsumerInterface tyyppi kuvaamaan sitä messenger muuttuja. Harkitse ChildMessengerInterface sen sijaan.

Päivitys: Korjattu sitoumuksesta f31a527 in PR3680.

[N04] Vedä rahakkeita tallentaa

Jonkin sisällä edellinen auditointi kyseenalaistimme sen tarkoituksen Store sopimukset payOracleFeesErc20 toiminto (numerossa L19). UMA joukkue päätti pitää toiminnon standardoida käyttöliittymä mahdollisia tulevia muutoksia varten. Koska toiminnon tarkoitusta ei ole täysin määritelty, on epäselvää, pitäisikö se laukaista, kun Proposer sopimus takavarikoi joukkovelkakirjalainan. Sitä tulee todennäköisesti käyttää, kun OracleHub maksaa hintapyynnön. Harkitse, pitäisikö toimintoa käyttää kummassakin skenaariossa.

Päivitys: Tunnustettu. UMA:n lausunto tästä aiheesta:

N04 suosittelee käyttämään Kaupan payOracleFeeErc20-menetelmää maksujen maksamiseen sekä Proposer- että OracleHub-sopimuksissa, jotta se olisi yhdenmukainen Kaupan käytön kanssa. Olemme päättäneet olla käyttämättä tätä toimintoa, koska se merkitsisi ylimääräisen käyttöliittymän tuomista (myymälää varten) ja velkasumman siirtämistä FixedPointiin (mikä vaatisi myös lisätuonnin. Jotta koodi olisi yksinkertainen ja puhdas). olemme päättäneet olla tekemättä tätä. OZ:n palaute payOracleFeeErc20:stä auditointivaiheessa 1 huhtikuussa 2020 oli pätevää, että tämä menetelmä ei ole todella hyödyllinen, mikä vaikeuttaa tällaista integraatiota.

[N05] TODO koodissa

Koodikannassa on "TODO"-kommentteja, joita tulisi seurata projektin ongelmatilanteessa. Esimerkiksi:

• linja 37 of Arbitrum_ParentMessenger sopimus
• linja 25 of Optimism_ChildMessenger sopimus
• Linjat 83 ja 146 of OracleHub sopimus.

Kehityksen aikana hyvin kuvatut "TODO"-kommentit helpottavat niiden seurantaa ja ratkaisemista. Ilman näitä tietoja nämä kommentit saattavat taipua mätänemään ja järjestelmän turvallisuuden kannalta tärkeät tiedot saattavat unohtua, kun ne julkaistaan ​​tuotantoon.

Näissä TODO-kommenteissa tulee olla lyhyt kuvaus suoritettavasta tehtävästä ja linkki vastaavaan ongelmaan projektiarkistossa.

Harkitse TODO-kommenttien päivittämistä näiden tietojen lisäämiseksi. Täydellisyyden ja jäljitettävyyden vuoksi voidaan lisätä allekirjoitus ja aikaleima. Esimerkiksi:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Päivitys: Korjattu sitoumuksesta 5d57b5b in PR3684.

[N06] Typografiset virheet

Koodikanta sisältää seuraavat typografiset virheet:

• In Admin_ChildMessenger sopimus, impleenting tulisi olla implementing
• In OptimisticRewarderBase sopimus, timestap tulisi olla timestamp.
• In OptimisticRewarderBase sopimus, liveness liveness tulisi olla liveness.
• In GovernorSpoke sopimus, only called tulisi olla only be called.
• In Optimism_ChildMessenger sopimuksen:

Päivitys: Korjattu sitoumuksesta 9b92b0b in PR3681.

[N07] Käyttämätön tuonti

Voit parantaa koodin luettavuutta poistamalla seuraavat käyttämättömät tuonnit:

Päivitys: Korjattu sitoumuksesta 40b7221 in PR3682.

[N08] L2 tapahtumajärjestys

- Governor varmistaa ehdotuksen sisällä olevat tapahtumat suoritetaan järjestyksessä. Kuitenkin, kun nämä tapahtumat sisältävät ketjujen välisiä tapahtumia, tämä vain takaa, että ne saapuvat L1-siltasopimukseen oikeassa järjestyksessä. Arbitrum-tapauksessa ne voidaan järjestää uudelleen ennen kuin ne on viimeistelty L2:ssa. Siksi hallintoehdotuksia olisi laadittava mahdollistamaan L2-tapahtumien uudelleenjärjestäminen.

Päivitys: Korjattu sitoumuksesta 0fb2e7b in PR3703. GovernorHub voi nyt välittää joukon L2-tapahtumia.

Yhteenveto

Koodikannasta löydettiin kaksi kriittistä ongelmaa. Yksi keskivakava ongelma ja useita pieniä haavoittuvuuksia on löydetty, ja korjaussuosituksia on ehdotettu.

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