Uma audit – 6. etapp

Sissejuhatus

UMA on platvorm, mis võimaldab kasutajatel Ethereumi plokiahelas sõlmida minimaalse usaldusega finantslepinguid. Oleme varem auditeerinud detsentraliseeritud oraakel, konkreetne finantslepingu mall, mõned ad hoc tõmbetaotlused, Perpetual Multiparty mall, mitmesugused järkjärgulised tõmbamistaotlused pikema seotuse jooksul ja kindlustatud sild.

Selles auditis vaatasime läbi uue juhtimisettepaneku lepingu, mehhanismi UMA ökosüsteemi laiendamiseks mitme ahela vahel, mehhanismi ERC721 märgiomanikele auhindade jagamiseks vastavalt ahelavälisele spetsifikatsioonile ja kindlustatud silla värskenduse, et toetada WETH-i. Optimismi ketis.

Auditeeritud kohustus on 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc ja ulatus hõlmab järgmisi lepinguid:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (välja arvatud test- ja polügoonilepingud)
• financial-templates/optimistic-rewarder/* (v.a testlepingud)

Vaatasime üle ka tugevusfailide muudatused Tõmmake päring 3611.

Eeldati, et kõik välised koodi- ja lepingusõltuvused töötavad dokumenteeritud viisil.

Süsteemi ülevaade

Praegune Governance Leping võimaldab Risk Labsi sihtasutusel teha ettepanekuid uute juhtimismeetmete kohta, mille UMA märgiomanikud saavad ratifitseerida. Uus Proposer Leping on ette nähtud võtma ettepaneku esitaja rolli, võimaldades igaühel teha uusi ettepanekuid, kui nad pakuvad tagatist, mis ohverdatakse, kui ettepanek ebaõnnestub. Puudub konkreetne stiimul ettepanekute tegemiseks. Eesmärk on tagada, et pakutaks välja ainult need meetmed, mis suure tõenäosusega heaks kiidetakse.

Uus ahelatevaheline mehhanism võimaldab juhtimisettepaneku edastada Ethereumi põhivõrgust Optimismi ja Arbitumi kettidele. Sel viisil saab 1. kihi UMA juhtimismehhanismi kasutada UMA lepingute juhtimiseks toetatud 2. kihi ahelates. Mehhanism võimaldab ka hinnapäringuid ja resolutsioone kihtide vahel edastada, nii et 2. kihi ahelates olevaid Optimistic Oracle'i saab turvata põhivõrgu andmete kontrollimise mehhanismiga samal viisil, nagu 1. kihi Optimistic Oracle'i turvab DVM.

Väärib märkimist, et need sõnumid saadetakse natiivse sillamehaanika abil, mis tähendab, et need on piiratud vastava kihi 2 ahelate omadustega. Eelkõige võib sõnumite 2. kihilt 1. kihile kuluda silla ülekandmiseks nädal või kauem. Lisaks toetab UMA juhtimismehhanism ettepanekuid, mis sisaldavad mitut tellitud tehingut, kuid see piirab ainult nende sillale lisamise järjekorda. On võimalik, et mõnda neist tehingutest teostatakse 2. kihis teises järjekorras või üldse mitte.

Optimistic Rewarder leping lihtsalt vermib ERC721 märgid kõigile, kes neid soovivad. Samuti võimaldab see igaühel seostada suvalisi andmeid mis tahes märgiga ja hoiustada erinevaid ERC20 märke, mida preemiatena jagada. Suvaliste andmete tõlgendamine ja preemiate eeldatav jaotus žetoonide omanike vahel määratakse kindlaks määramata ahelavälise protseduuri abil. Igaüks võib väita, et konkreetne ERC721 märk on võlgu teatud hüvesid, kui ta on nõus võlakirja deponeerima. Standardset Optimistic Oracle'i mehhanismi kasutatakse selleks, et keegi teine ​​saaks nõude vaidlustada, mille lahendab DVM. Nõuded, mida õigeaegselt ei vaidlustata, loetakse kehtivaks ja vastavalt leping jaotab preemiad. Ainus piirang (arvestuse lihtsustamiseks) on see, et oraakli võlakirja tokenit ei saa kasutada preemiamärgina.

Lõpuks muudab PR3611 kindlustatud silla mehhanismi, et vältida WETH saatmist üle Optimismi märgisilla, mida ei toetata. Selle asemel pakitakse kõik Optimismi hoiukasti hoiustatud L2 WETH enne silla läbimist lahti L2 ETH-ks. Esimesel kihil teisendatakse ETH enne WETH-i sillakogumisse edastamist WETH-ks.

Kriitiline raskusaste

[C01] Kehtetut preemiat ei saa vaidlustada

Preemiataotluse vaidlustamisel OptimisticRewardBase kõigepealt leping käivitab ettepaneku kohta SkinnyOptimisticOracle ja siis vaidlustab selle ettepaneku. Siiski ettepanek määrab aegumisaja kompensatsioonina praegusest (vaidluse) ajast, samas kui vaidlus määrab aegumise tasaarvestusena algse preemiataotluse esitamise ajast. Enamikul juhtudel takistab see lahknevus oraaklil vaidlustatavat ettepanekut tuvastada, mis tähendab, et kehtivaid vaidlusi ei töödelda ja kehtetuid preemiataotlusi aktsepteeritakse.

Kaaluge vaidluse kutse värskendamist, et vaidlustatav ettepanek õigesti täpsustada.

Värskenda: Kinnitatud alates kohustusest 9e15557 in PR3690.

[C02] Lahenda ettepanekuid korduvalt

. resolveProposal funktsioon Proposer leping lihtsalt kinnitab et oraakel on lahendanud, kuid ei kontrolli, kas võlakiri on laiali jagatud. See tähendab, et sama ettepanekut saab lahendada mitu korda, mille tulemuseks on topeltvõlakirjamaksed. Kaaluge olemasolevate ettepanekute märgistamist või kustutamist, kui need on lahendatud.

Värskenda: Kinnitatud alates kohustusest b152718 in PR3689.

Kõrge raskusastmega

Puudub.

Keskmise raskusastmega

[M01] Valed sündmuse parameetrid

. OptimisticRewarderBase leping määratleb a Requested sündmus mis eraldub requestRedemption funktsioon, kui palutakse lunastada. See sündmus on määratud kiirgama lunastamise aegumistähtaeg selle viimase parameetrina. Kuid, kui sündmus väljastatakse, on selle viimane parameeter valesti seatud hetkel.

Samamoodi ka Redeemed sündmus loeb aegumisaja pärast kirje kustutamist, nii et see seatakse valesti nullile.

Arvestades, et seda sündmust saab kasutada ahelaväliste arvutuste käivitamiseks, kaaluge väljastatud väärtuse sobivat värskendamist.

Värskenda: Kinnitatud alates kohustusest f04eef9 in PR3694.

Madal raskusaste

[L01] Sündmuse emissiooni puudumine pärast lunastamise vaidlustamist

. OptimisticRewarderBase leping määratleb a Disputed sündmus mis on mõeldud käivitamiseks, kui lunastamine on vaidlustatud. Seda sündmust ei edastata aga selle sees ega väljaspool OptimisticRewarderBase leping.

Kaaluge sündmuse väljastamist pärast tundlikke muudatusi dispute funktsioon, et hõlbustada jälgimist ja teavitada ahelaväliseid kliente lepingute tegevusest.

Värskenda: Kinnitatud alates kohustusest c275e92 in PR3695.

[L02] Ebajärjekindel sissepääsuvalve

. Optimism_ParentMessenger ja Arbitrum_ParentMessenger lepingutes kohaldatakse ebajärjekindlalt nonReentrant modifikaator. Kaaluge selle lisamist kõikidele avalikele funktsioonidele.

Värskenda: Kinnitatud alates kohustusest 6275c39 in PR3677.

[L03] Eksitavad kommentaarid

Siin on mõned eksitavad kommentaarid, mille ülevaatuse käigus tuvastasime:

• ChildMessengerConsumerInterface.sol:
  • Line 5 ütleb "lapsesõnumitooja" asemel "vanemsõnum"
• GovernorSpoke.sol:
  • Read 49–51 lingid aadressile a Gnosis faili, kuigi kommentaar ütleb, et jupp on kopeeritud Governor.sol. Lisaks ei ole koodilõik sees olevaga identne Governor.sol

Värskenda: Kinnitatud alates kohustusest cc350f9 in PR3678.

[L04] Lisaandmete tempel puudub

Hinna küsimisel OracleSpoke leping, esitatud lisaandmed on tembeldatud koos alamahela identifikaatoriga. Siiski, hasPrice ja getPrice funktsioonid ei tembelda hinnapäringu tuvastamisel lisaandmeid. See sunnib lepingute sõlmimisel ise templit peale panema, mis põhjustab ebakõla hinnapäringu ja hinna otsimise mehhanismide vahel. Kaaluge templi kasutamist hasPrice ja getPrice funktsioone.

Värskenda: Kinnitatud alates kohustusest fdb845d in PR3668.

[L05] NatSpec parameeter puudub

Paljud funktsioonid OptimisticRewarderBase leping puuduvad @return parameetrit oma loomuliku spetsifikatsiooni kommentaarides. Kaaluge selle lisamist täielikkuse huvides.

Värskenda: Kinnitatud alates kohustusest 8920f38 in PR3679.

[L06] Jääktoetus

Optimistliku oraakli esilekutsumiseks OptimisticRewarderBase leping annab talle sümboolse toetuse, nii et see võib tõmmata võlakirjamakseid. Kui ettepanek ebaõnnestub, preemia lunastamine tühistatakse kuid toetust ei nullita. Seetõttu säilitab Optimistic Oracle tarbetu jääktoetuse kuni järgmise vaidluse käivitamiseni. Kaaluge toetuse tühistamist, kui ettepanek ebaõnnestub.

Värskenda: Kinnitatud alates kohustusest c2d444b in PR3698.

[L07] Vigane tagasimakse aadress

Toetuse L2 aadress Arbitrum_ParentMessenger initsialiseeritakse lepingu omanikule, kelleks peaks olema L1 kuberner. Samamoodi on setRefundL2Address on kommentaar märkides, et see tuleks määrata kubernerile. Sõnumite edastamisel üle silla on see väärtus aga määrata L2 kasutajaks, mis on Arbitumi aadress, mis saab pärast pileti lahendamist üleliigsed rahalised vahendid. Kuna L1 kuberneri aadress ei ole Arbitrumis juurdepääsetav, lähevad kõik sellele aadressile saadetud rahalised vahendid kaotsi.

Kaaluge selle seadistamist kehtivale L2-aadressile.

Värskenda: Kinnitatud alates kohustusest b3f2dd1 in PR3687.

[L08] Lapssõnumite vahetamise mehhanism

. GovernorSpoke ja OracleSpoke leping iga initsialiseerib alamsõnumi konstruaatoris, ilma selle värskendamise mehhanismita. See tähendab, et kui lapssõnum on muutunud, mõlemad kodaralepingud aeguvad.

Kuna kodarate leping on tõenäoliselt stabiilsem kui sõnumitoojad, kaaluge kodaratele mehhanismi lisamist Messengeri värskendamiseks.

Värskenda: Kinnitatud alates kohustusest 7c9e061 in PR3688.

Märkused ja lisateave

[N01] Muuda võlakirja tunnust

. Proposer leping sisaldab mehhanism omanikul võlakirja suurust muuta. Mõelge, kas neil peaks olema võimalik ka võlakirja tokenit muuta. Pange tähele, et selleks oleks vaja mehhanismi õige võlakirja valuuta tuvastamiseks, kui olemasolevad ettepanekud lahendatakse.

Värskenda: Pole probleem. UMA avaldus selle probleemi kohta:

N01 soovitab lubada pakkuja lepingul muuta võlakirja märk millekski muuks peale UMA. Meil ei ole kavatsust selle funktsiooni jaoks toetada ühtegi muud tunnust peale $UMA ja seetõttu oleme otsustanud selles probleemis muudatusi mitte teha. Veelgi enam, üks märk lepingu kohta hoiab selle loogika võimalikult lihtsana. Lõpuks, kui vaja on muudatust (näiteks loa migratsiooni korral), võiksime lihtsalt juurutada teise lubaga uue pakkuja lepingu ja algatada ettepaneku süsteemi migreerimiseks seda kasutada.

[N02] Mittetäielik liides

. ChildMessengerInterface ei täpsusta a processMessageFromCrossChainParent funktsiooni, isegi kui vanemad sõnumitoojad eeldavad selle olemasolu. Kaaluge selle lisamist täielikkuse huvides.

Värskenda: Pole parandatud. UMA avaldus selle probleemi kohta:

Otsustasime tahtlikult jätta selle liidese ebajärjekindlaks, kuna selle rakendamine ChildMessengerInterface'is katkestab ühilduvuse Polygon_ChildMessengeriga, kuna Polygoni meetod teistest ahelatest pärinevate sõnumite töötlemiseks nõuab mõnevõrra kohandatud loogikat, kus sisemist meetodit nimetatakse _processMessageFromRootiks.

[N03] Vale liides

. GovernorSpoke leping valesti sõlmida kasutab ChildMessengerConsumerInterface tüüp selle kirjeldamiseks messenger muutuv. Kaaluge ChildMessengerInterface asemel.

Värskenda: Kinnitatud alates kohustusest f31a527 in PR3680.

[N04] Tõmmake märgid poodi

Aastal eelmine audit seadsime kahtluse alla selle eesmärgi Store lepingud payOracleFeesErc20 funktsioon (numbris L19). UMA meeskond otsustas funktsiooni säilitada liidese standardiseerimiseks võimalike tulevaste muudatuste jaoks. Kuna funktsiooni eesmärk pole täielikult määratletud, on ebaselge, kas see tuleks käivitada, kui Proposer leping konfiskeerib võlakirja. Tõenäoliselt tuleks seda kasutada, kui OracleHub maksab hinnapäringu eest. Mõelge, kas funktsiooni tuleks kummagi stsenaariumi korral kasutada.

Värskenda: Tunnistanud. UMA avaldus selle probleemi kohta:

N04 soovitab nii pakkuja kui ka OracleHubi lepingutes tasude maksmiseks kasutada Poe meetodit PayOracleFeeErc20, et olla kooskõlas poekasutusega. Otsustasime seda funktsiooni mitte kasutada, kuna see tähendaks täiendava liidese importimist (poe jaoks) ja võlakirjasumma ülekandmist FixedPointi (see nõuaks ka täiendavat importi. Et kood oleks lihtne ja puhas). otsustasime seda mitte teha. OZ-i tagasiside payOracleFeeErc20 kohta auditi 1. faasis 2020. aasta aprillis kinnitas, et see meetod pole tegelikult kasulik, mistõttu on sellist integratsiooni raskem põhjendada.

[N05] Ülesanded koodis

Koodibaasis on "TODO" kommentaarid, mida tuleks jälgida projekti probleemide mahajäämuses. Näiteks:

• joon 37 of Arbitrum_ParentMessenger leping
• joon 25 of Optimism_ChildMessenger leping
• Liinid 83 ja 146 of OracleHub leping.

Arenduse käigus on “TODO” kommentaaride hästi kirjeldamine hõlbustanud nende jälgimist ja lahendamist. Ilma selle teabeta võivad need kommentaarid kippuda mädanema ja süsteemi turvalisuse jaoks oluline teave võib selle tootmisse jõudmise ajaks ununeda.

Nendes TODO kommentaarides peaks olema ülesande lühikirjeldus ja link projekti hoidlas olevale vastavale probleemile.

Selle teabe lisamiseks kaaluge TODO kommentaaride värskendamist. Täielikkuse ja jälgitavuse huvides saab lisada allkirja ja ajatempli. Näiteks:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Värskenda: Kinnitatud alates kohustusest 5d57b5b in PR3684.

[N06] Trükivead

Koodibaas sisaldab järgmisi trükivigu:

• aasta Admin_ChildMessenger leping, impleenting peaks olema implementing
• aasta OptimisticRewarderBase leping, timestap peaks olema timestamp.
• aasta OptimisticRewarderBase leping, liveness liveness peaks olema liveness.
• aasta GovernorSpoke leping, only called peaks olema only be called.
• aasta Optimism_ChildMessenger leping:

Värskenda: Kinnitatud alates kohustusest 9b92b0b in PR3681.

[N07] Kasutamata import

Koodi loetavuse parandamiseks kaaluge järgmise kasutamata impordi eemaldamist.

Värskenda: Kinnitatud alates kohustusest 40b7221 in PR3682.

[N08] L2 tehingute tellimine

. Governor tagab tehingud tehakse ettepaneku raames. Kui need tehingud hõlmavad aga ahelatevahelisi tehinguid, tagab see vaid selle, et need jõuavad L1 sildlepinguni õiges järjekorras. Arbitrumi puhul võidakse neid enne L2 lõplikku vormistamist ümber järjestada. Seetõttu tuleks koostada juhtimisettepanekud, et võimaldada teisejärguliste tehingute järjekorda.

Värskenda: Kinnitatud alates kohustusest 0fb2e7b in PR3703. GovernorHub saab nüüd edastada L2 tehingute massiivi.

Järeldus

Koodibaasist leiti kaks kriitilist probleemi. Leiti üks keskmise raskusastmega probleem ja mitu väiksemat turvaauku ning soovitati lahendusi.

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