Uma Audit – 6. fázis

Bevezetés

UMA egy olyan platform, amely lehetővé teszi a felhasználók számára, hogy bizalmi alapú pénzügyi szerződéseket kössenek az Ethereum blokkláncon. Korábban auditáltunk a decentralizált orákulum, egy adott pénzügyi szerződéssablon, néhány ad hoc lehívási kérés, a Perpetual Multiparty sablon, különböző inkrementális húzási kérések egy hosszabb elköteleződés során és a a biztosított híd.

Ebben az ellenőrzésben áttekintettünk egy új irányítási javaslati szerződést, egy mechanizmust az UMA ökoszisztéma több láncra való kiterjesztésére, egy mechanizmust, amely a jutalmakat osztja el az ERC721 tokentulajdonosok között a láncon kívüli specifikáció szerint, valamint a biztosított híd frissítését a WETH támogatására. az Optimizmus láncon.

Az ellenőrzött kötelezettségvállalás az 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc és a hatály a következő szerződéseket foglalja magában:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (kivéve a teszt- és sokszögszerződéseket)
• financial-templates/optimistic-rewarder/* (kivéve a tesztszerződéseket)

Áttekintettük a szilárdsági fájlok módosításait is Húzza le a 3611-es számot.

Feltételezték, hogy minden külső kód- és szerződésfüggőség a dokumentált módon működik.

Rendszer áttekintő

A jelenlegi Governance szerződés lehetővé teszi a Risk Labs Foundation számára, hogy új irányítási intézkedéseket javasoljon, amelyeket az UMA tokentulajdonosai ratifikálhatnak. Az új Proposer A szerződés a javaslattevő szerepét hivatott betölteni, lehetővé téve bárki számára, hogy új javaslatokat tegyen mindaddig, amíg olyan kötvényt biztosít, amelyet feláldoznak, ha az ajánlat meghiúsul. Nincs konkrét ösztönzés a javaslattételre. A cél annak biztosítása, hogy csak azokat a tevékenységeket javasolják, amelyeket nagy valószínűséggel elfogadnak.

Az új láncokon átívelő mechanizmus lehetővé teszi az irányítási javaslatok átadását az Ethereum mainnetről az Optimism és Arbitrum láncokhoz. Ily módon az 1. réteg UMA irányítási mechanizmusa használható az UMA-szerződések szabályozására a támogatott 2. rétegbeli láncokon. A mechanizmus lehetővé teszi az árkérések és a felbontások továbbítását is a rétegek között, így a 2. réteg láncain lévő Optimistic Oracle-eket ugyanúgy biztosíthatja a mainnet Data Verification Mechanism, mint az 1. réteg Optimistic Oracle-ét a DVM.

Érdemes megjegyezni, hogy ezeket az üzeneteket a natív hídmechanika segítségével küldik el, ami azt jelenti, hogy a vonatkozó 2. rétegbeli láncok jellemzői korlátozzák őket. Különösen a 2. rétegtől az 1. rétegig terjedő üzenetek áthaladása a hídon egy hétig vagy tovább tarthat. Ezenkívül az UMA irányítási mechanizmusa támogatja azokat a javaslatokat, amelyek több megrendelt tranzakciót is tartalmaznak, de ez csak korlátozza a hídhoz való hozzáadásának sorrendjét. Előfordulhat, hogy egyes tranzakciók más sorrendben, vagy egyáltalán nem hajtódnak végre a 2. rétegen.

Az Optimistic Rewarder szerződés egyszerűen ERC721 tokeneket ver mindenki számára, aki kéri. Azt is lehetővé teszi, hogy bárki tetszőleges adatot társítson bármely tokenhez, és különféle ERC20 tokeneket helyezzen el, amelyeket jutalomként osztanak ki. Az önkényes adatok értelmezését és a jutalmak várható elosztását a tokentulajdonosok között egy nem meghatározott láncon kívüli eljárással határozzák meg. Bárki állíthatja, hogy egy adott ERC721 token jutalomcsomaggal tartozik, ha hajlandó letétbe helyezni egy kötvényt. A szabványos Optimistic Oracle mechanizmus arra szolgál, hogy valaki más vitathassa a követelést, amelyet a DVM old meg. Az időben nem vitatott igényeket érvényesnek tekintjük, és a szerződés ennek megfelelően osztja fel a jutalmakat. Az egyetlen korlátozás (az elszámolás egyszerűsítése érdekében), hogy az oracle kötvény token nem használható jutalom tokenként.

Végül a PR3611 módosítja a biztosított hídmechanizmust, hogy elkerülje a WETH küldését az Optimism token hídon keresztül, ami nem támogatott. Ehelyett az Optimism letéti dobozban elhelyezett L2 WETH kicsomagolásra kerül L2 ETH-ba, mielőtt áthaladna a hídon. Az 1. rétegben az ETH-t WETH-vé alakítják, mielőtt továbbítják a WETH-hídkészletbe.

Kritikus súlyosság

[C01] Az érvénytelen jutalom nem vitatható

Jutalomigény vitatásakor a OptimisticRewardBase szerződést először javaslatot vált ki a SkinnyOptimisticOracle és azután vitatja ezt a javaslatot. A javaslat azonban beállítja a lejárati időt az aktuális (vita)időhöz képest eltolásként, míg a vita meghatározza a lejáratot beszámításként az eredeti jutalomigénylés időpontjához képest. A legtöbb esetben ez az eltérés megakadályozza, hogy az orákulum azonosítsa a vitatott ajánlatot, ami azt jelenti, hogy az érvényes vitákat nem dolgozzák fel, és az érvénytelen jutalomkérelmeket elfogadják.

Fontolja meg a vitafelhívás frissítését, hogy helyesen határozza meg a vitatott javaslatot.

Frissítés: A véglegesítés időpontjában javítva 9e15557 in PR3690.

[C02] Javaslatok ismételt megoldása

A resolveProposal funkció Proposer szerződés egyszerűen érvényesíti hogy az orákulum megoldotta, de nem ellenőrzi, hogy a kötvény kiosztásra került-e. Ez azt jelenti, hogy ugyanazt az ajánlatot többször is meg lehet oldani, ami kétszeres kötvénykifizetést eredményez. Fontolja meg a meglévő javaslatok megjelölését vagy törlését, amikor megoldásra kerültek.

Frissítés: A véglegesítés időpontjában javítva b152718 in PR3689.

Magas súlyosság

Egyik sem.

Közepes súlyosságú

[M01] Helytelen eseményparaméterek

A OptimisticRewarderBase szerződés meghatározza a Requested esemény amelyet kibocsát a requestRedemption funkciót, ha visszaváltást kérnek. Ez az esemény úgy van meghatározva, hogy a a visszaváltás lejárati ideje utolsó paramétereként. Azonban, az esemény kibocsátásakor, az utolsó paramétere helytelenül van beállítva a aktuális idő.

Hasonlóan a Redeemed esemény beolvassa a lejárati időt a rekord törlése után, így helytelenül nullára lesz állítva.

Tekintettel arra, hogy ez az esemény láncon kívüli számítások indítására használható, fontolja meg a kibocsátott érték megfelelő frissítését.

Frissítés: A véglegesítés időpontjában javítva f04eef9 in PR3694.

Alacsony súlyosság

[L01] Eseménykibocsátás hiánya a visszaváltás vitatása után

A OptimisticRewarderBase szerződés meghatározza a Disputed esemény amelyet a visszaváltás vitatása esetén kívánnak kiváltani. Ez az esemény azonban nem kerül kibocsátásra sem belül, sem azon kívül OptimisticRewarderBase szerződés.

Fontolja meg az esemény kibocsátását, miután érzékeny változások történtek a dispute funkció, hogy megkönnyítse a nyomon követést és a láncon kívüli ügyfelek értesítését a szerződések tevékenységéről.

Frissítés: A véglegesítés időpontjában javítva c275e92 in PR3695.

[L02] Inkonzisztens visszatérési őr

A Optimism_ParentMessenger és a Arbitrum_ParentMessenger szerződések következetlenül alkalmazzák a nonReentrant módosító. Fontolja meg ennek az összes nyilvános funkcióba való bevonását.

Frissítés: A véglegesítés időpontjában javítva 6275c39 in PR3677.

[L03] Félrevezető megjegyzések

Íme néhány félrevezető megjegyzés, amelyeket felülvizsgálatunk során azonosítottunk:

• ChildMessengerConsumerInterface.sol:
  • vonal 5 azt mondja, hogy „parent messenger” a „child messenger” helyett
• GovernorSpoke.sol:
  • 49-51. Sor linkek a Gnosis fájlt, bár a megjegyzés szerint a részletet másolták Governor.sol. Ezenkívül a kódrészlet nem azonos a bejövővel Governor.sol

Frissítés: A véglegesítés időpontjában javítva cc350f9 in PR3678.

[L04] Hiányzik a kiegészítő adatbélyegző

Ár kérésekor a OracleSpoke szerződést, a megadott mellékadatokat le van bélyegezve a gyermeklánc azonosítójával. Azonban a hasPrice és a getPrice A funkciók nem bélyegzik le a járulékos adatokat az árkérés azonosításakor. Ez arra kényszeríti a szerződéskötést, hogy maguknak bélyegzőt alkalmazzanak, ami inkonzisztenciát okoz az árkérés és az árlekérési mechanizmusok között. Fontolja meg a bélyegző alkalmazását a hasPrice és a getPrice funkciókat.

Frissítés: A véglegesítés időpontjában javítva fdb845d in PR3668.

[L05] Hiányzó NatSpec paraméter

Számos funkció a OptimisticRewarderBase szerződés hiányoznak a @return paramétert a Natural Specifikáció megjegyzéseiben. A teljesség érdekében fontolja meg a felvételét.

Frissítés: A véglegesítés időpontjában javítva 8920f38 in PR3679.

[L06] Maradék juttatás

Az Optimista Orákulum megidézése érdekében a OptimisticRewarderBase szerződés jelképes juttatást ad neki, így meg tudja húzni a kötvénykifizetéseket. Ha a javaslat sikertelen, a jutalom beváltása törlésre kerül de a pótlékot nem állítják vissza. Ezért az Optimistic Oracle megtartja a szükségtelen maradék juttatást a következő vita kiváltásáig. Fontolja meg a pótlék visszavonását, ha a javaslat nem sikerül.

Frissítés: A véglegesítés időpontjában javítva c2d444b in PR3698.

[L07] Érvénytelen visszatérítési cím

A visszatérítés L2 címe a Arbitrum_ParentMessenger inicializálva van a szerződés tulajdonosának, akinek az L1 kormányzónak kell lennie. Hasonlóképpen a setRefundL2Address megjegyzése van kimondva, hogy a kormányzónak kell beállítani. Az üzenetek hídon való átadásakor azonban ez az érték beállítva L2 felhasználónak, amely az Arbitrumon az a cím, amelyre többletpénz érkezik a jegy rendezése után. Mivel az L1 kormányzói cím nem lesz elérhető az Arbitrumon, az erre a címre küldött pénzeszközök elvesznek.

Fontolja meg egy érvényes L2-cím beállítását.

Frissítés: A véglegesítés időpontjában javítva b3f2dd1 in PR3687.

[L08] A gyermek hírvivők cseréjének mechanizmusa

A GovernorSpoke és a OracleSpoke A szerződés mindegyike inicializálja a gyermek üzenetküldőt a konstruktorban, anélkül, hogy azt frissítené. Ez azt jelenti, hogy amikor a gyermek hírnök megváltozott, mindkét küllős szerződés elavulttá válik.

Mivel a küllős szerződés valószínűleg stabilabb, mint a hírvivők, fontolja meg egy mechanizmus beépítését a hírvivő frissítésére a küllőkön.

Frissítés: A véglegesítés időpontjában javítva 7c9e061 in PR3688.

Megjegyzések és további információk

[N01] Kötvény token módosítása

A Proposer szerződés tartalmazza egy mechanizmus hogy a tulajdonos módosítsa az ajánlati kötvény nagyságát. Fontolja meg, hogy a kötvény tokent is módosíthatják-e. Vegye figyelembe, hogy ehhez egy olyan mechanizmusra lenne szükség, amely azonosítani tudja a megfelelő kötvénydevizát, amikor a meglévő javaslatokat megoldják.

Frissítés: Nem probléma. Az UMA nyilatkozata ezzel a kérdéssel kapcsolatban:

Az N01 azt javasolja, hogy engedélyezze az ajánlattevő szerződésnek, hogy a kötvény tokent az UMA-tól eltérőre változtassa. Nem áll szándékunkban a $UMA-n kívül más tokent támogatni ehhez a funkcióhoz, ezért úgy döntöttünk, hogy nem változtatunk ezen a problémán. Sőt, szerződésenként egyetlen token a lehető legegyszerűbben tartja ezt a logikát. Végül, ha változtatásra volt szükség (például jogkivonat migrációja esetén), egyszerűen telepíthetnénk egy új ajánlattevői szerződést a másik tokennel, és kezdeményezhetnénk egy javaslatot a rendszer áttelepítésére annak használatára.

[N02] Hiányos interfész

A ChildMessengerInterface nem határozza meg a processMessageFromCrossChainParent funkciót, még akkor is, ha a szülő üzenetküldők feltételezik, hogy létezik. A teljesség érdekében fontolja meg a felvételét.

Frissítés: Nincs kijavítva. Az UMA nyilatkozata ezzel a kérdéssel kapcsolatban:

Szándékosan úgy döntöttünk, hogy ezt a felületet inkonzisztensnek hagyjuk, mivel ennek a ChildMessengerInterface-en belüli megvalósítása megszakítja a kompatibilitást a Polygon_ChildMessenger-rel, mivel a Polygon metódusa más láncokból származó üzenetek feldolgozására némileg egyéni logikát igényel, ahol a belső metódust _processMessageFromRoot-nak hívják.

[N03] Hibás interfész

A GovernorSpoke hibásan köt szerződést használja az ChildMessengerConsumerInterface típus annak leírására messenger változó. Fontolja meg a ChildMessengerInterface helyette.

Frissítés: A véglegesítés időpontjában javítva f31a527 in PR3680.

[N04] Húzza a tokeneket a tároláshoz

egy korábbi audit megkérdőjeleztük a célját Store szerződés payOracleFeesErc20 funkció (L19 számban). Az UMA csapata a funkció megtartása mellett döntött az interfész szabványosítása a lehetséges jövőbeni módosításokhoz. Mivel a funkció célja nincs teljesen meghatározva, nem világos, hogy ki kell-e indítani, amikor a Proposer szerződés elkoboz egy kötvényt. Valószínűleg akkor kell használni, amikor a OracleHub kifizeti az árkérést. Fontolja meg, hogy a függvényt használni kell-e bármelyik forgatókönyvben.

Frissítés: Elismert. Az UMA nyilatkozata ezzel a kérdéssel kapcsolatban:

Az N04 azt javasolja, hogy az Áruház payOracleFeeErc20 módszerét használja a díjak kifizetésére a Javaslattevő és az OracleHub szerződésben is, hogy összhangban legyen az Áruház használatával. Úgy döntöttünk, hogy nem használjuk ezt a funkciót, mivel ez azt jelentené, hogy egy további interfészt kellene importálni (az üzlet számára), és a kötvény összegét egy FixedPointba kell átadni (ami szintén további importálást igényelne. A kód egyszerű és tiszta tartása érdekében úgy döntöttünk, hogy ezt nem tesszük meg. Az OZ visszajelzése a payOracleFeeErc20-ról az 1. audit fázisban 2020 áprilisában érvényes volt, hogy ez a módszer nem igazán hasznos, így az ilyen típusú integrációt nehezebb megindokolni.

[N05] TODO-k a kódban

Vannak „TODO” megjegyzések a kódbázisban, amelyeket nyomon kell követni a projekt problémahátralékában. Például:

• vonal 37 of Arbitrum_ParentMessenger szerződés
• vonal 25 of Optimism_ChildMessenger szerződés
• Lines 83 és a 146 of OracleHub szerződés.

A fejlesztés során a jól leírt „TODO” megjegyzések megkönnyítik azok nyomon követését és megoldását. Ezen információk hiányában ezek a megjegyzések megrohadhatnak, és a rendszer biztonsága szempontjából fontos információk elfelejthetők, mire kiadják azokat.

Ezeknek a TODO-megjegyzéseknek tartalmazniuk kell egy rövid leírást a függőben lévő feladatról, valamint egy hivatkozást a megfelelő problémára a projekttárban.

Fontolja meg a TODO megjegyzések frissítését az információ hozzáadásához. A teljesség és a nyomon követhetőség érdekében aláírás és időbélyeg is adható hozzá. Például:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

Frissítés: A véglegesítés időpontjában javítva 5d57b5b in PR3684.

[N06] Nyomdai hibák

A kódbázis a következő tipográfiai hibákat tartalmazza:

• A Admin_ChildMessenger szerződés, impleenting kell lennie implementing
• A OptimisticRewarderBase szerződés, timestap kell lennie timestamp.
• A OptimisticRewarderBase szerződés, liveness liveness kell lennie liveness.
• A GovernorSpoke szerződés, only called kell lennie only be called.
• A Optimism_ChildMessenger szerződés:

Frissítés: A véglegesítés időpontjában javítva 9b92b0b in PR3681.

[N07] Fel nem használt import

A kód olvashatóságának javítása érdekében fontolja meg a következő nem használt importok eltávolítását:

Frissítés: A véglegesítés időpontjában javítva 40b7221 in PR3682.

[N08] L2 tranzakció rendelés

A Governor biztosítja Az ajánlaton belüli tranzakciók sorrendben kerülnek végrehajtásra. Ha azonban ezek a tranzakciók láncokon átívelő tranzakciókat foglalnak magukban, ez csupán azt garantálja, hogy a megfelelő sorrendben érkeznek meg az L1 hídszerződéshez. Az Arbitrum-ügyben átsorolhatók az L2-es véglegesítés előtt. Ezért olyan irányítási javaslatokat kell készíteni, amelyek lehetővé teszik az L2-tranzakciók átsorolását.

Frissítés: A véglegesítés időpontjában javítva 0fb2e7b in PR3703 Az GovernorHub most közvetítheti L2 tranzakciók tömbjét.

Következtetés

Két kritikus hibát találtunk a kódbázisban. Egy közepes súlyosságú problémát és több kisebb sebezhetőséget találtak, és javaslatokat tettek a javításra.

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