Joulukuu 1, 2021
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 ja erilaisia inkrementaalisia vetopyyntöjä pidemmän sitoutumisen aikana. Tässä auditoinnissa tarkastelimme uutta mekanismia, jolla tokenit lähetetään nopeasti kerroksen 2 ketjusta Ethereum-verkkoon, ja siihen liittyviä muutoksia Optimistic Oracle -järjestelmään. Tarkastuksen suoritti 2 tilintarkastajaa 3 viikon aikana.
Laajuus
Tarkastettu sitoumus on f24ad501c8e813cf685f72217e7f13c8f3c366df
ja soveltamisalaan kuuluvat seuraavat sopimukset:
- sopimukset/insured-bridge/* (pois lukien testisopimukset)
- sopimukset-ovm/insured-bridge/toteutus/*
- contracts/common/implementation/AncillaryData.sol
- sopimukset/oracle/implementation/SkinnyOptimisticOracle.sol
Tarkastimme myös solidity-tiedostojen muutokset Vedä pyyntö 3445.
Kaikkien ulkoisten koodien ja sopimusten riippuvuuksien oletettiin toimivan dokumentoidusti.
Järjestelmäkatsaus
Tuetut kerroksen 2 (L2) ketjut, Optimism ja Arbitrum, tarjoavat mekanismin varojen siirtämiseksi Ethereumin verkkoon (L1). Turvallisuussyistä näiden siirtojen loppuun saattaminen kestää kuitenkin huomattavan viiveen. Tämän ratkaisemiseksi L2-tokenin haltijat voivat tallettaa varoja UMA-sopimukseen, Talletuslaatikkoon, tietäen, että rahakkeet lopulta siirretään (eränä) L1 UMA -sopimukseen, Bridge Pooliin. Jokaiselle siirrettävälle tokenille on erillinen Bridge Pool.
L2-talletuksen jälkeen kuka tahansa voi välittää tiedot L1 Bridge Pooliin, joka odottaa hetken, jos joku haluaa kiistää välitetyt tiedot. Kaikki riidat käsittelee Skinny Optimistic Oracle (kuvattu alla). Likviditeetin tarjoajien on ennen välityksen hyväksymistä rahoitettava Bridge Pool -sopimus etukäteen LP-tokeneita vastaan. Kiistattomat välitykset oletetaan päteviksi, ja Bridge Pool suorittaa siirron omilla varoillaan, jolloin osa siirrosta ohjataan välittäjälle ja murto-osa jää likviditeettipalkkioksi. Varoja täydennetään lopulta, kun L2-talletus on viimeistelty, ja likviditeettimaksut osoitetaan LP-merkkien haltijoille.
Bridge Pool antaa myös mahdollisuuden rahoittaa henkilökohtaisesti siirron (ilman Bridge Pool -varauksia) ennen riita-ajan umpeutumista vastineeksi murto-osasta siirtosummasta. Koska rele voidaan edelleen kiistää, nämä varat menetetään, jos rele katsottaisiin virheelliseksi. Odotetaan, että useimmissa tapauksissa tämä mekanismi antaa käyttäjille mahdollisuuden kokea välittömiä L2-L1-tunnusten siirtoja.
Skinny Optimistic Oracle on käsitteellisesti hyvin samanlainen kuin olemassa oleva Optimistic Oracle. Se tarjoaa käyttäjille kannustimen yksinkertaisesti vahvistaa oraakkelipyynnön tulos, jonka oletetaan olevan tarkka, jos sitä ei kiistata. Kiistat siirretään aiemmissa tarkastusraporteissamme kuvattuun hitaampaan DVM-mekanismiin. Suurin ero on, että uusi versio edellyttää, että käyttäjät antavat kaikki asiaankuuluvat tiedot suorittaessaan funktiokutsuja, joten arvoja ei tarvitse tallentaa tai hakea muistista. Se poistaa myös pyynnön esittäjiltä mahdollisuuden muuttaa aktiivisten pyyntöjen määritysparametreja.
Olemme aiemmin käyneet läpi Long-Short-Pair-sopimuksen, joka tarjoaa yleisen mekanismin erilaisten rahoitusinstrumenttien luomiseen. Nämä sopimukset voidaan ratkaista, kun niiden voimassaoloaika on saavutettu ja selvityshinta on tiedossa. Pull Request 3445:n tuomat muutokset mahdollistavat sopimusten ennenaikaisen purkamisen, jos selvityshinta on tiedossa ennen eräpäivää.
Etuoikeutetut roolit
L2-pankkilaatikoilla on useita konfigurointiparametreja, mukaan lukien tuetut tunnukset ja maksiminopeus erillisten tokenien lähettämiselle sillan yli L1:lle. Ne on myös määritettävä varmistamaan johdonmukaisuus L1-tunnussopimuksen, L2-tunnussopimuksen ja vastaavan siltavarannon välillä. Nämä parametrit asetetaan L1:n ylläpitäjäsopimuksella, joka myös parametroi siltapoolien riitojenratkaisuprosessin. Sopimusta valvotaan UMA-hallintamekanismilla, joten käyttäjien on luotettava tähän prosessiin hallitakseen järjestelmää järkevästi ja oikeudenmukaisesti.
Ekosysteemiriippuvuudet
Kaikki tarkistetut komponentit käyttävät aikaperusteista logiikkaa, mikä tarkoittaa, että ne riippuvat Ethereumin saatavuudesta. Erityisesti, jos kiistatapahtumat viivästyvät merkittävästi, virheelliset välitykset tai hintaehdotukset voivat vahvistua virheellisesti.
Lisäksi token-silta olettaa implisiittisesti, että kaikki L2-siltalokeroihin lähetetyt varat siirretään lopulta vastaavaan L1-siltapooliin. Tämä perustuu Optimism- ja Arbitrum-siltojen ja niiden riitojenratkaisumekanismien oikeaan ja jatkuvaan toimintaan.
Lopuksi L2-säilytyslaatikkoon lähetetyt tunnukset osoitetaan L1:n siltapoolille, ei aiotulle vastaanottajalle. L1-merkkisten haltijoiden on ensin yhdistettävä ne lisätokeneilla saadakseen varoja poolista. Siksi mekanismi luottaa riittävän syvään L1-tokenien markkinoihin varmistaakseen, että likviditeetti on aina olemassa.
Asiakkaiden ilmoittamia ongelmia
Auditoinnin aikana UMA-tiimi tunnisti itsenäisesti useita huomionarvoisia ongelmia ja käyttäytymismalleja:
Jos Optimistic Oracle- tai Bridge Admin -parametrit muuttuvat releen haastejakson aikana, välityksen riitauttaminen poistaa välityksen ilman, että ehdottaja tai riitauttaja voi käyttää muita keinoja. Kuvittele esimerkiksi, että välitys lähetetään vakuustunnusta varten
TOKEN_A
, mutta releen keskelläTOKEN_A
poistetaan vakuuksien sallittujen luettelosta. Kiista palautuu nyt, koska et voi lähettää OO:lle tai DVM:lle hintapyyntöjä ei-valtuutetuista vakuuksista. Koska emme halua estää kelvollisia kiistapyyntöjä,BridgePool
poistaa odottavan releen kohteelleTOKEN_A
riitatapauksessa. Tämän suunnittelupäätöksen seuraukset ovat:
1. Lopullisen maksun korotus aiheuttaa: Kaikki tämän tunnuksen jäljellä olevat välitykset voidaan "peruuttaa" kiistana, onko se oikea vai väärä. Peruutus ei hyödytä kumpaakaan osapuolta, joten se olettaa rehellisten riidanhaltijoiden olemassaoloa, jotka ovat valmiita tappamaan (harvinaisen) huonon pyynnön, joka sattuu olemaan viimeisen maksun muutoksen toimeenpanon aikana. Tämä tarkoittaa myös sitä, että sureja voi kuluttaa kaasua releiden peruuttamiseksi ja pakottaakseen ne välittämään uudelleen.
2. Tunnisteen tai tunnuksen poistaminen sallittujen luettelosta, jonka ei pitäisi tapahtua, ellei jokin mene hyvin pieleen, aiheuttaisi:
3. Kiistattomien pyyntöjen pidennetty aika, jolloin mikä tahansa pyyntö voidaan peruuttaa eikä riitauttamiseen ole taloudellisia kannustimia. Tämä näyttää paremmalta kuin vaihtoehto estää kiistat kokonaan, mutta se on kieltämättä melko huono, koska kuka tahansa sureja voi estää releet loputtomiin maksamalla kaasua tai lähettää huonoja releitä ilman rangaistusta (muita kuin kaasumaksuja).Huomautus: tämä on vaihtoehto OO:lle, joka "jäädyttää" parametrit, kuten lopullisen maksun tai vakuuden sallittujen listan joksikin aikaa, mutta tämä vaatisi lisäpuheluita OO:lle, mikä olisi kallista onnellisen polun kannalta.
Releitä voidaan nopeuttaa kautta
speedUpRelay()
sen jälkeen, kun ne ovat eläneet. Vaikka emme näe tässä mitään riskiä, se avaa mahdollisuuden flash-lainoihin + nopeuksiin + elävyyden jälkeiseen selvitykseen, jolloin flash-lainaaja saa välittömän välitysmaksun "ilmaiseksi". Esämme tämän tässä ehdotuksessa PR.
On
settle
, josBridgePool
onWETH
pool ja vastaanottaja on sopimus, joka ei olepayable
(ei voi hyväksyä ETH:ta), sittensettle
tulee epäonnistumaan. Aiomme korjata tämän ja peruuttaa lähettämisenWETH
, mutta tässä asiassa ei ole vielä tehty merkittävää työtä.
In
relayDeposit
, tarkistamme, ettäBridgePool
saldo on suurempi kuin summa, joka välitetään PLUS ehdottajan joukkovelkakirjalaina. Tämä on vanhentunut shekki ja liian konservatiivinen, koska ehdottajan sitoumus poistetaan käyttäjältä tarkistuksen jälkeen. Käsittelemme tätä tässä ehdotuksessa PR.
Sain juuri bugin mistä
chainId
inBridgePool
, sisältyy osanaDeposit
struct ja funktiosyötteenä kaikkiin releisiin liittyviin toimintoihin (esimrelayDeposit
,speedUpRelay
,settle
) on tyyppiuint8
. Tämä on liian pieni tyyppi käsittelemään esimerkiksi Arbitumia, jonka tunnus on 421611. Itse asiassa havaitsimme tämän bugin ja korjasimme sen L2-puolella:BridgeDeposit
on asettanut senchainId
kirjoitauint256
. Tämä PR tekeechainId
onBridgePool
vastaa tyyppiäBridgeDepositBox
: UMA-protokolla/protokolla#3463
Aiemmin kiistatoiminto ei vähentänyt talletuksen määrää
pendingReserves
(tämä on muuttuja, joka seuraa kuinka suuri osa reservivarannosta on lukittuna välineiden vuoksi, jotka eivät ole vielä asettuneet). Tuloksena oli, että jokainen riita lukitsi välitysmäärän määräämättömäksi ajaksi pooliin. LP:t eivät voi poistaa sitä tai käyttää tulevat releet. Korjaus löytyy täältä: UMA-protokolla/protokolla#3473.
Löysimme virheen
BridgeDepositBox
jossahasEnoughTimeElapsedToBridge
ei tarkista jos auint256
arvo on yhtä suuri kuin0
oletuksena: Korjattu PR 3484:ään
Valuuttakurssimenetelmää (joka on tilaa muokkaava) kutsutaan sisään siirrettävien ja lyövien LP-tokenien välillä siltapoolisopimuksen addLiquidity-menetelmässä. Tämä laskenta on siirrettävä menetelmän alkuun. Tämä aiheuttaa hyvin outoja valtion arvoja. Katso PR tätä korjata.
Katselumenetelmä
liquidityUtilizationPostRelay
(jota käytetään vain offchainissa), ilmoittaa väärän käyttönumeron. Nimittäjä päällä tämä rivi ei pitäisi olla vainliquidReserves
, sen pitäisi sen sijaan olla esitys käyttämättömistä ja käytetyistä varoista. Korjattu tätä.
Päivitykset
Ongelmankorjausten lisäksi tarkistimme myös seuraavat vaiheittaiset muutokset:
- PR3500 poistaa redundantin tunnusparametrin kohteesta
BridgePool
Tapahtumat. - PR3478 lisää DVM:n lopullisen maksun paikallisesti välimuistissa olevien muuttujien luetteloon.
- PR3460 ottaa huomioon mahdollisen negatiivisen likviditeetin käyttöedun tapauksen (n04:n lisäksi)
- PR3482 poistaa ylimääräiset tiedostot ja päivittää OVM-vakiot OVM 2.0 -muutosten mukaisesti.
- PR3585 päivittää
BridgeDepositBox
käyttöliittymä johdonmukaisuuden vuoksi ja käyttää OpenZeppeliniaSafeERC20
kirjasto.
Tarkastellessamme korjauksia havaitsimme toisen ongelman. Arvoa määritettäessä BridgePool
LP-merkkejä, on olemassa välilaskelma, joka voi odottamattoman negatiivisen ylivuodon, mikä estää väliaikaisesti likviditeetin lisäämisen ja poistamisen. Laskelma tulee järjestää uudelleen niin, että käytetyt varaukset lisätään ennen jakamattomien maksujen vähentämistä.
Kriittinen vakavuus
[C01] Loukkuun jääneen ehdottajan palkinto
- LongShortPair
sopimus noutaa ehdottajan palkinnon mistä tahansa osoitteesta, joka laukaisee vanhenemisen, jota käytetään hintaehdotusten kannustamiseen Optimistic Oraclessa. Kuitenkin LongShortPairCreator
sopimus myös hakee ja välittää varat käyttöönoton osoitteesta. Näitä lisävaroja ei siirretä Optimistiselle Oraakkelille, vaan ne jäävät loukkuun LongShortPair
sopimus.
Harkitse kaksoissiirron poistamista.
Päivitys: Korjattu sitoumuksesta 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Erittäin vakava
[H01] Samanaikaiset releet kuluttavat varantoja
- relayDeposit
toiminto BridgePool
sopimus varmistaa, että sopimuksessa on riittävästi varoja suorittaa siirron. Se ei kuitenkaan ota huomioon vireillä olevat varat, joka seuraa varoja, jotka on varattu aktiivisille releille. Tästä syystä useat samanaikaiset välitykset voivat olla riippuvaisia samoista varoista, eivätkä ne kaikki välttämättä ole selvitettävissä välittömästi. Erityisesti tasaisella siirtovirralla välittömät välittäjäpalaut voivat viivästyä määräämättömäksi ajaksi.
Harkitse sellaisten releiden estämistä, jotka saattaisivat vireillä olevat varat ylittää nestevarannot.
Päivitys: Korjattu sitoumuksesta 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Siltaparametrien rajat eivät täsmää
- deposit
toiminto että BridgeDepositBox
kerroksen 2 ketjuissa käytettyä sopimusta käytetään yhdistämään varoja L2:n ja L1:n välillä. Erityisesti välittäjiä kannustetaan rele tapahtumatiedot liittyvästä L1:stä BridgePool
. Kuitenkin säilytyslokero käyttää kattavat rajat rajoittaa viestimaksuja silta-altaan käytössä yksinomaiset rajat. Tämä tarkoittaa, että joitain talletuksia (25 %:n välityspalkkiolla) ei voida välittää, ja varat eivät ole käytettävissä molemmilla tasoilla.
Harkitse molempien tasojen vahvistusten synkronointia varmistaaksesi, että kaikki kelvolliset talletukset voidaan välittää.
Päivitys: Kiinteä sitoutuminen 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Tämä luokiteltiin alun perin kriittiseksi vakavuusasteeksi, mutta sitä alennettiin, kun UMA-tiimi huomautti, että varat eivät olisi tiukasti loukussa ja ne voitaisiin vapauttaa, jos DVM-äänestäjät suostuivat hyväksymään muokatun välityskuvauksen vaikuttaville talletuksille.
Keskivaikea
[M01] Takaisinsoitot väärään osoitteeseen
- SkinnyOptimisticOracle
kutsuu takaisinsoittotoimintoja hinnan pyytäjässä, jos sellaisia on, jotta pyytäjä voi vastata merkittäviin tilan muutoksiin. Takaisinsoittoa vedotaan kuitenkin virheellisesti hintaehdotuksen tekijältä sisään tulleen hinnan pyytäjän sijaan Ishayoiden opettaman proposePriceFor
toiminto. Tämä tarkoittaa, että hinnan pyytäjä ei voi vastata hintaehdotuksiin.
Onneksi tätä ominaisuutta ei käytetä nykyisessä koodikannassa. Harkitse kuitenkin vetoamista priceProposed
takaisinsoitto pyytäjälle.
Päivitys: Korjattu sitoutuessa 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Viallinen lisäystoiminto
- appendKeyValueBytes32
toiminto pitäisi yhdistää sen syötteet muotoilluksi bytes
joukko. Kuitenkin currentAncillaryData
is väärin heitetty pois.
Koska lisätiedot vaikuttaa oraakkelin ratkaisuprosessiin, väärä arvo voi heikentää oraakkelin tuloksia. Onneksi on vain yksi puhelu appendKeyValueBytes32
koodikannassa, ja se käyttää tyhjää currentAncillaryData
puskuri, joten bugi ei vaikuta tähän tapaukseen.
Harkitse appendKeyValueBytes32
toimivat niin, että currentAncillaryData
sisältyy palautettuun tavutaulukkoon.
Päivitys: Kiinteä sitoutuminen 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Epätäydellinen lisätietojen validointi
- LongShortPair
rakentaja vahvistaa, että customAncillaryData
on riittävän pieni. Se ei kuitenkaan ota huomioon ennenaikaisen vanhenemisen kenttä. Tämä tarkoittaa Optimistista Oraakkelia saattaa yllättäen hylätä ennenaikaisen vanhenemisen hintapyynnöt, jotka poistavat tämän ominaisuuden käytöstä.
Harkitse vahvistuksen päivittämistä lisäkentän huomioon ottamiseksi.
Päivitys: Korjattu sitoumuksesta 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Väärin käsitelty nolla-aikaleima
In LongShortPair
Sopimuksen aikaisen päättymisen aikaleima on nolla käytetään lippuna osoittamaan, että kukaan ei ole käynnistänyt aikaista vanhenemismekanismia. On kuitenkin mahdollista käynnistää sen mekanismin nolla aikaleimalla. Tässä skenaariossa Optimistic Oracle vedetään, mutta suoja myöhempiä hintapyyntöjä vastaan ei tule olemaan tehokasta. Onneksi kerran sovitushinta valitaan, sitä ei ohiteta, joten tämä ei johda epäjohdonmukaisiin ratkaisuihin. Siitä huolimatta myöhempi hintapyyntö voisi olla mahdollista muuttaa tallennettua ennenaikaisen vanhenemisen aikaleimaa, vaikka nolla-aikaleimaa käytettäisiin selvityshinnan määrittämiseen. Se voisi myös antaa harhaanjohtavan tapahtuman.
Harkitse ennenaikaisen vanhenemisen estämistä käyttämällä nolla-aikaleimaa.
Päivitys: Korjattu sitoumuksesta 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Mahdollinen nollasidos
- requestPrice
toiminto SkinnyOptimisticOracle
sopimus käyttää lopullista maksua vakuudeksi jos lainaa ei ole määritelty. Kuitenkin requestAndProposePriceFor
toiminto voi käyttää nollasidosta, mikä on ristiriidassa sen kanssa @notice
ja @param
kommentteja. Nollalaina heikentää kannustimia virheellisiin ehdotuksiin tai riita-asioihin.
Onneksi kutsua vain tätä toimintoa koodipohjassa asettaa ehdottajan joukkovelkakirjalainan. Harkitse kuitenkin lopullisen maksun käyttämistä, jos lainaa ei ole määritelty.
Päivitys: Korjattu sitoumuksesta daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Tarpeettomat järjestelmänvalvojan oikeudet
- BridgePool
sopimus perii ExpandedERC20
jotta se voi antaa LP-tokeneita likviditeetin tarjoajille. Tämä perii OpenZeppelinin toimivuuden ERC20
sopimus ja myös tarjoaa järjestelmänvalvojan oikeudet sopimuksen käyttöönottajalle, jonka avulla he voivat lyödä ja polttaa LP-tokeneita. Tätä toimivaltaa ei kuitenkaan vaadita, ja jos sitä käytetään, se voi rangaista likviditeetin tarjoajia epäoikeudenmukaisesti.
Harkitse muokkaamista BridgePool
periä suoraan ERC20
sijasta ExpandedERC20
.
Päivitys: Kiinteä sitoutuminen 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Matala vakavuus
[L01] Ei voida maksaa erääntyessä
- settle
toiminto LongShortPair
sopimus ottaa huomioon ratkaisuehdot kun nykyinen aika on ehdottomasti ennen vanhenemisaikaleimaa tai sen jälkeen. Se kuitenkin palautuu virheellisesti, kun nykyinen aika vastaa vanhenemisen aikaleimaa.
Harkitse inklusiivisen sidoksen käyttämistä vastaamaan postExpiration
muutos.
Päivitys: Kiinteä sitoutuminen f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Puuttuva virheilmoitus vaadi-lauseesta
Asiakirjassa on vaadittava lausunto BridgePool
sopimus ilman virheilmoitusta.
Harkitse erityisten ja informatiivisten virheilmoitusten sisällyttämistä kaikkiin vaatimuksiin.
Päivitys: Korjattu sitoumuksesta 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Puuttuvat dokumentit
Koko koodikannassa on joitain tapauksia, joissa Ethereum Natural -määritys puuttuu tai on epätäydellinen. Esimerkkejä:
Harkitse kaikkien sopimusten julkiseen sovellusliittymään kuuluvien toimintojen (ja niiden parametrien) perusteellista dokumentointia.
Päivitys: Korostetut kommentit korjattiin sitomisessa e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Emme vahvistaneet NatSpecin täydellisyyttä muussa koodikannassa.
Huomautuksia ja lisätietoja
[N01] Puhelun palautusarvoa ei ole tarkistettu
In deposit
toiminto L2 BridgeDepositBox
sopimus on matalan tason puhelu l2Token
kun l1Token
is l1Weth
. Tämä matalan tason puhelu on deposit()
toiminto, joka kuuluu Weth käyttöliittymä. Jos tämä l2Token
käyttäytyy aivan kuten WETH, sen ei pitäisi koskaan epäonnistua. Mutta tapauksessa l2Token
käyttäytyy eri tavalla ja epäonnistuu, palautusta ei olisi, koska tämän matalan tason puhelun onnistumislippua ei koskaan tarkisteta.
Harkitse kaikkien matalan tason puheluiden palautusarvojen tarkistamista ja reagoimista asianmukaisesti.
[N02] Indeksoitujen parametrien puute tapahtumissa
Monilla tässä koodikannassa määritellyillä tapahtumilla on parametreja, jotka tulisi indeksoida:
Harkita tapahtumaparametrien indeksointi välttääksesi ketjun ulkopuolisten palveluiden haun ja suodatuksen tiettyjen tapahtumien estämistä.
Päivitys: Osittain kiinteä sitomisessa d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. chainId
parametri WhitelistToken
ei päivitetty.
[N03] Implisiittinen valun epäjohdonmukaisuus
- LongShortPair
sopimus yleensä käsittelee aikaleimoja nimellä uint64
arvot, jotka on implisiittisesti valettu uint256
arvot milloin siirtyi Optimistiselle Oraakkelille. Kuitenkin requestTimestamp
parametri Ishayoiden opettaman _requestOraclePrice
toiminto on ennenaikaisesti valettu a uint256
. Tällä ei ole toiminnallisia seurauksia.
Harkitse kuitenkin johdonmukaisuuden vuoksi a uint64
tälle parametrille ja sallien sen implisiittisen suoratoiston a uint256
kun se siirrettiin Optimistiselle Oraakkelille.
Päivitys: Kiinteä sitoutuminen 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Aikaleima on nyt valettu erikseen.
[N04] Väärä tyyppi
- sendMessage
toiminto iOptimism_CrossDomainMessenger
liitäntä käyttää a uint256
kaasun raja kun taas optimismi OVM_CrossDomainEnabled
käyttää a uint32
kaasun raja.
Johdonmukaisuuden ja ennustettavuuden vuoksi harkitse tiedoston päivittämistä iOptimisim_CrossDomainMessenger
sendMessage
toimintoa a uint32
kaasun raja.
Päivitys: Korjattu sitoumuksesta 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Vahvistuksen puute
Kaikki toiminnot sisään BridgeAdmin
tuo puhelu _relayMessage
oletetaan, että tapahtuman arvo vastaa l1CallValue
parametri, mutta tätä ei pakoteta.
Harkitse oikean asian varmistamista msg.value
on asetettu.
Päivitys: Korjattu sitoumuksesta f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Luettavuus
- _getDepositHash
toiminto että BridgePool
sopimus purkaa depositData
rakenne väliin l1Token
argumenttina koostumuksessa keccak256
jossa abi
koodaus. Tämä tekee toiminnasta tarpeettoman monisanaista ja voi johtaa virheisiin, kun se toteutetaan uudelleen muilla tasoilla.
Harkitse argumenttien yksinkertaistamista yksinkertaisesti järjestetyksi pariksi depositData
ja l1Token
.
Päivitys: Korjattu sitoumuksesta 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Reentrant-toiminto
- requestAndProposePriceFor
toiminto että SkinnyOptimisticOracle
sopimus soittaa epäluotettavalle msg.sender
mutta sitä ei vartioi a nonReentrant
muuntaja. Vaikka tässä tapauksessa tämä ei näytä olevan turvallisuusongelma, se voi aiheuttaa odottamatonta toimintaa.
Harkitse lisäämistä nonReentrant
muokkaaja kaikkiin toimintoihin, jotka kutsuvat mahdollisesti epäluotettavia sopimuksia.
Päivitys: Kiinteä sitoutuminen b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
ei kirjattu
- relayMessage
toiminto että Arbitrum_Messenger
sopimus ei lähetä merkityksellistä tapahtumaa arkaluonteisen toimenpiteen suorittamisen jälkeen. The relayMessage
funktiokutsuja aliohjelmana sentTxToL2NoAliasing
joka itse palauttaa uint256
arvo seqNum
, mutta tätä palautusarvoa ei ole kirjattu sisään relayMessage
toiminto.
Harkitse tapahtumien lähettämistä arkaluonteisten muutosten jälkeen helpottaaksesi seurantaa ja ilmoittaaksesi ketjun ulkopuolisille asiakkaille sopimuksen toiminnasta.
Päivitys: Korjattu sitoumuksesta 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Typografiset virheet
Koodikanta sisältää seuraavat kirjoitusvirheet:
Harkitse näiden kirjoitusvirheiden korjaamista koodin luettavuuden parantamiseksi.
Päivitys: Korjattu sitoumuksesta 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Dokumentoimaton ERC20-hyväksyntävaatimus
- requestEarlyExpiration
ja expire
tehtävät että LongShortPair
Kukin sopimus olettaa, että soittaja on myöntänyt sopimukselle korvauksen nosta ehdottajan palkinto.
Ennustettavuuden vuoksi harkitse tämän vaatimuksen dokumentointia funktion kommenteissa.
Päivitys: Kiinteä sitoutuminen da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Käyttämätön modifikaattori
In BridgePool
sopimus onlyFromOptimisticOracle
muutos on määritelty, mutta sitä ei koskaan käytetä koodikannassa, joten se tulisi poistaa.
Päivitys: Kiinteä sitoutuminen 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
Päätelmät
2 kriittistä ja 1 erittäin vakava ongelma havaittiin. Joitakin muutoksia ehdotettiin parhaiden käytäntöjen noudattamiseksi ja mahdollisen hyökkäyspinnan vähentämiseksi.
- &
- 7
- Tili
- Toiminta
- aktiivinen
- Ad
- lisä-
- osoite
- admin
- Etu
- Kaikki
- Salliminen
- api
- perustelut
- tilintarkastus
- saatavuus
- ovat
- PARAS
- parhaat käytännöt
- blockchain
- Laatikko
- SILTA
- Vika
- Bugs
- soittaa
- tapauksissa
- kiinni
- Aiheuttaa
- haaste
- muuttaa
- tarkkailun
- koodi
- kommentit
- Konfigurointi
- sisältää
- sopimus
- sopimukset
- voisi
- Nykyinen
- tiedot
- hajautettu
- viivyttää
- Malli
- määritetään
- DID
- riita
- ei
- Varhainen
- Taloudellinen
- reuna
- Tehokas
- ERC20
- ETH
- ethereum
- Ethereum blockchain
- tapahtuma
- Tapahtumat
- esimerkki
- Vaihdetaan
- odotettu
- experience
- Ominaisuus
- Maksut
- taloudellinen
- Etunimi
- Korjata
- salama
- seurata
- löytyi
- toiminto
- rahasto
- varat
- tulevaisuutta
- GAS
- kaasumaksut
- Antaminen
- hallinto
- onnellinen
- ottaa
- tätä
- Korkea
- Korostettu
- haltijat
- Miten
- HTTPS
- kannustaa
- mukana
- Mukaan lukien
- Kasvaa
- tiedot
- korko
- liitäntä
- kysymykset
- IT
- tunnettu
- johtaa
- Kirjasto
- Neste
- likviditeetti
- likviditeetin tarjoajat
- Lista
- Lainat
- paikallisesti
- lukittu
- LP
- LP:
- markkinat
- ottelu
- eniten
- avata
- oraakkeli
- Muut
- foorumi
- pool
- Altaat
- teho
- estää
- hinta
- prosessi
- ehdotus
- toimittaa
- tarjoaa
- julkinen
- syistä
- vähentää
- Raportit
- REST
- tulokset
- Tuotto
- arviot
- Riski
- turvallisuus
- Palvelut
- setti
- tilitys
- Lyhyt
- merkittävä
- samankaltainen
- pieni
- So
- kiinteys
- Joku
- jotain
- nopeus
- viettää
- Osavaltio
- Lausunto
- Levytila
- menestys
- Tuetut
- pinta
- järjestelmä
- testi
- Kautta
- kauttaaltaan
- aika
- symbolinen
- tokens
- ylin
- Seuranta
- kauppa
- Liiketoimet
- Luottamus
- Päivitykset
- Päivitykset
- UPS
- Käyttäjät
- arvo
- Näytä
- whitelist
- KUKA
- sisällä
- ilman
- Referenssit
- arvoinen
- nolla-