December 1, 2021
UMA je platforma, ki uporabnikom omogoča vpisovanje finančnih pogodb z minimalnim zaupanjem v verigo blokov Ethereum. Prej smo revidirali decentraliziran orakelj, posebno predlogo finančne pogodbe, nekaj ad hoc zahtev za vleko, predlogo Perpetual Multiparty in različne inkrementalne zahteve za vleko v daljšem sodelovanju. V tej reviziji smo pregledali nov mehanizem za hitro pošiljanje žetonov iz verige plasti 2 v glavno omrežje Ethereum in s tem povezane spremembe v Optimistic Oracle. Pregled sta v 2 tednih opravila 3 revizorja.
področje uporabe
Revidirana potrditev je f24ad501c8e813cf685f72217e7f13c8f3c366df
in obseg vključuje naslednje pogodbe:
- contracts/insured-bridge/* (razen testnih pogodb)
- contracts-ovm/insured-bridge/implementation/*
- contracts/common/implementation/AncillaryData.sol
- contracts/oracle/implementation/SkinnyOptimisticOracle.sol
Pregledali smo tudi spremembe datotek trdnosti v Zahteva za vlečenje 3445.
Predpostavljalo se je, da vse zunanje kode in pogodbene odvisnosti delujejo, kot je dokumentirano.
Pregled sistema
Podprti verigi sloja 2 (L2), Optimism in Arbitrum, zagotavljata mehanizem za prenos sredstev v glavno omrežje Ethereum (L1). Vendar zaradi varnostnih razlogov pride do velike zamude, preden se ti prenosi dokončajo. Za obravnavo tega lahko imetniki žetonov L2 položijo sredstva v pogodbo UMA, Deposit Box, pri čemer vedo, da bodo žetoni sčasoma preneseni (kot serija) v pogodbo L1 UMA, Bridge Pool. Za vsak žeton, ki ga je treba prenesti, obstaja ločen mostni bazen.
Po nakazilu L2 lahko kdor koli posreduje podrobnosti L1 Bridge Poolu, ki počaka kratek čas, če želi kdo izpodbijati posredovane informacije. Vse spore obravnava Skinny Optimistic Oracle (opisano spodaj). Preden sprejmejo prenos, morajo ponudniki likvidnosti vnaprej financirati pogodbo Bridge Pool v zameno za žetone LP. Predvideva se, da so nesporni posredniki veljavni, Bridge Pool pa dokonča prenos z uporabo lastnih rezerv, pri čemer se del prenosa preusmeri na posrednika, del pa zadrži kot likvidnostna nadomestila. Sredstva bodo sčasoma napolnjena, ko bo depozit L2 dokončan in bodo likvidnostne provizije dodeljene imetnikom žetonov LP.
Bridge Pool prav tako omogoča vsakomur, da individualno financira prenos (brez rezerv Bridge Poola) pred iztekom obdobja spora v zameno za delček zneska nakazila. Ker je rele še vedno mogoče izpodbijati, bi bila ta sredstva izgubljena, če bi bil rele ocenjen kot nepravilen. Pričakuje se, da bo v večini primerov ta mehanizem uporabnikom omogočil takojšnje prenose žetonov L2 na L1.
Skinny Optimistic Oracle je konceptualno zelo podoben obstoječemu Optimistic Oracle. Zagotavlja spodbujevalni mehanizem za uporabnike, da preprosto potrdijo rezultat orakeljske zahteve, za katerega se predpostavlja, da je točen, če ni izpodbijan. Spori so preneseni na počasnejši mehanizem DVM, opisan v naših prejšnjih revizijskih poročilih. Glavna razlika je v tem, da nova različica od uporabnikov zahteva, da zagotovijo vse pomembne informacije pri izvajanju funkcijskih klicev, tako da vrednosti ni treba shranjevati ali pridobivati iz pomnilnika. Odstrani tudi zmožnost vlagateljem zahtev, da spremenijo konfiguracijske parametre v aktivnih zahtevah.
Prej smo pregledali pogodbo Dolgi-Kratki-Pair, ki zagotavlja splošen mehanizem za ustvarjanje različnih finančnih instrumentov. Te pogodbe je mogoče razrešiti, ko je dosežen čas njihovega izteka in je znana poravnalna cena. Spremembe, ki jih uvaja Pull Request 3445, uvajajo možnost predčasne razrešitve pogodb, če je poravnalna cena znana pred časom poteka.
Privilegirane vloge
Depozitni predali L2 imajo več konfiguracijskih parametrov, vključno s podprtimi žetoni in najvišjo hitrostjo za pošiljanje paketnih žetonov prek mostu na L1. Prav tako jih je treba konfigurirati za zagotavljanje skladnosti med pogodbo žetona L1, pogodbo žetona L2 in ustreznim premostitvenim bazenom. Ti parametri so nastavljeni s skrbniško pogodbo na L1, ki parametrira tudi postopek reševanja sporov premostitvenih skupin. Pričakuje se, da bo pogodbo nadzoroval mehanizem upravljanja UMA, zato morajo uporabniki zaupati temu procesu, da bo sistem upravljal razumno in pošteno.
Odvisnosti ekosistema
Vse pregledane komponente uporabljajo časovno zasnovano logiko, kar pomeni, da so odvisne od razpoložljivosti Ethereuma. Zlasti, če so sporne transakcije znatno zakasnjene, so lahko neveljavni releji ali predlogi cen nepravilno potrjeni.
Poleg tega žetonski most implicitno predvideva, da bodo vsa sredstva, poslana v depozitne predale L2, sčasoma prenesena v ustrezen mostni bazen L1. To je odvisno od pravilnega in neprekinjenega delovanja mostov Optimism in Arbitrum ter njunih mehanizmov za reševanje sporov.
Nazadnje so žetoni, poslani v depozitni predal L2, dodeljeni premostitvenemu bazenu v L1 in ne predvidenemu prejemniku. Za pridobitev sredstev iz sklada jih morajo imetniki žetonov L1 najprej uskladiti z dodatnimi žetoni. Zato se mehanizem opira na dovolj globok trg žetonov L1, da zagotovi vedno likvidnost.
Težave, o katerih so poročale stranke
Med revizijo je ekipa UMA neodvisno identificirala številne težave in vedenja, ki jih je vredno izpostaviti:
Če se parametri Optimistic Oracle ali Bridge Admin spremenijo med obdobjem izziva releja, potem izpodbijanje releja izbriše rele brez dodatnih sredstev za predlagatelja ali izpodbijalca. Na primer, predstavljajte si, da je rele poslan po stranski žeton
TOKEN_A
, ampak sredi štafeteTOKEN_A
je odstranjen s seznama dovoljenih zavarovanj. Spor se bo zdaj vrnil, ker OO ali DVM ne morete predložiti nobenih zahtev za ceno za zavarovanje, ki ni na seznamu dovoljenih. Ker ne želimo blokirati veljavnih zahtev za spore, jeBridgePool
bo izbrisal čakajoči rele zaTOKEN_A
v primeru spora. Posledice te oblikovalske odločitve so:
1. Zvišanje končne pristojbine bo povzročilo: Vsak neporavnan prenos na tem žetonu bo "preklican" s sporom, ne glede na to, ali je pravilen ali napačen. Preklic ne koristi nobeni strani, zato predpostavlja obstoj poštenih nasprotnikov, ki so pripravljeni uničiti (redko) slabo zahtevo, ki se slučajno pojavi med izvršitvijo končne spremembe pristojbine. To tudi pomeni, da je možno, da žalostnež porabi plin, da prekliče releje in jih prisili k ponovnemu vklopu.
2. Odprava identifikatorja ali žetona s seznama dovoljenih, kar se ne bi smelo zgoditi, razen če gre kaj zelo narobe, bi povzročilo:
3. Podaljšano obdobje neizpodbitnih zahtevkov, kjer je vsako zahtevo mogoče preklicati in ni nobenih ekonomskih spodbud za izpodbijanje. To se zdi boljše kot alternativa popolnega blokiranja sporov, vendar je res precej slabo, saj lahko vsak žalostnik blokira releje za nedoločen čas s plačilom plina ali pošlje slabe releje brez kazni (razen pristojbin za plin).Opomba: to je alternativa temu, da OO za nekaj časa "zamrzne" parametre, kot je končna pristojbina ali seznam dovoljenih zavarovanj, vendar bi to zahtevalo dodatne klice OO, kar bi bilo drago za srečno pot.
Releje je mogoče pospešiti prek
speedUpRelay()
potem ko minejo živost. Čeprav v tem ne vidimo nobenega tveganja, odpira možnost za hitra posojila + pospešitve + poravnavo po oživitvi, kar hitro posojilojemalcu daje takojšnjo provizijo za »brezplačno«. To preprečimo v tem predlaganem PR.
On
settle
, čeBridgePool
jeWETH
pool in prejemnik je pogodba, ki nipayable
(ne more sprejeti ETH), potemsettle
ne bo uspelo. To nameravamo popraviti in se vrniti k pošiljanjuWETH
, vendar na tem področju še ni opravljenega izjemnega dela.
In
relayDeposit
, preverimo, ali jeBridgePool
Stanje je večje od zneska za posredovanje PLUS obveznice predlagatelja. To je zastarel ček in preveč konzervativen, saj se obveznica predlagatelja po čeku odvzame od uporabnika. To obravnavamo v tem predlogu PR.
Kje sem pravkar ujel napako
chainId
inBridgePool
, vključen kot delDeposit
struct in kot funkcijski vhod za vse funkcije, povezane z releji (tjrelayDeposit
,speedUpRelay
,settle
) je vrstauint8
. To je premajhen tip, da bi na primer obravnaval Arbitrum, katerega ID je 421611. Pravzaprav smo ujeli to napako in jo popravili na strani L2:BridgeDeposit
je postavila svojochainId
vnesite vuint256
. Ta PR bo naredilchainId
onBridgePool
ujemajo z vrsto naBridgeDepositBox
: UMAprotocol/protocol#3463
Prej funkcija spora ni odštela zneska pologa od
pendingReserves
(to je spremenljivka, ki spremlja, koliko rezervnega bazena je zaklenjenega zaradi relejev, ki se še niso poravnali). Posledica je bila, da bi vsak spor za nedoločen čas zaklenil znesek prenosa v bazenu. LP-ji ga ne morejo umakniti ali uporabiti prihodnji releji. Popravek je tukaj: UMAprotocol/protocol#3473.
Našli smo napako v
BridgeDepositBox
KjehasEnoughTimeElapsedToBridge
ne preveri, če auint256
vrednost je enaka0
privzeto: Popravljeno v PR 3484
Metoda menjalnega tečaja (ki spreminja stanje) se kliče med žetoni, ki se prenašajo, in žetoni LP, ki se kovajo v metodi addLiquidity pogodbe o premostitvenem bazenu. Ta izračun je treba premakniti na vrh metode. To povzroča zelo čudne vrednosti stanja. Glej PR tukaj popraviti.
Metoda pogleda
liquidityUtilizationPostRelay
(ki se uporablja samo zunaj verige), poroča o napačni številki uporabe. Imenovalec na ta vrstica ne bi smelo biti samoliquidReserves
, bi morala biti namesto tega predstavitev neizkoriščenih in porabljenih rezerv. Popravljeno tukaj.
Nadgradnja
Poleg popravkov težav smo pregledali tudi naslednje postopne spremembe:
- PR3500 odstrani odvečni parameter žetona iz
BridgePool
dogodki. - PR3478 doda končno pristojbino DVM na seznam lokalno predpomnjenih spremenljivk.
- PR3460 upošteva možen robni primer negativne izkoriščenosti likvidnosti (poleg obravnavanja N04)
- PR3482 odstrani odvečne datoteke in posodobi konstante OVM v skladu s spremembami OVM 2.0.
- PR3585 posodablja
BridgeDepositBox
vmesnik za doslednost in uporablja OpenZeppelinSafeERC20
knjižnica.
Med pregledovanjem popravkov smo odkrili še eno težavo. Pri določanju vrednosti BridgePool
LP žetoni, obstaja vmesni izračun, ki bi lahko nepričakovano negativno prelil, kar bi začasno onemogočilo dodajanje in odvzemanje likvidnosti. Izračun je treba preurediti, da se dodajo porabljene rezerve, preden se odštejejo nerazporejene provizije.
Kritična resnost
[C01] Nagrada ujetega predlagatelja
O LongShortPair
Naročilo pridobi nagrado predlagatelja s katerega koli naslova sproži potek, ki se uporablja za spodbujanje ponudb cen v Optimističnem oraklu. Vendar pa je LongShortPairCreator
tudi pogodba pridobi in posreduje sredstva z naslova izvajalca. Ta dodatna sredstva se ne posredujejo Optimističnemu oraklu, temveč ostanejo ujeta znotraj LongShortPair
pogodba.
Razmislite o odstranitvi podvojenega prenosa.
Posodobitev: Popravljeno ob objavi 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Visoka resnost
[H01] Sočasni releji praznijo rezerve
O relayDeposit
funkcija BridgePool
Naročilo zagotavlja, da ima pogodba dovolj sredstev za izvedbo nakazila. Vendar pa ne upošteva čakajoče rezerve, ki spremlja sredstva, ki so namenjena aktivnim relejem. Zato se lahko več sočasnih relejev zanaša na ista sredstva in morda ne bo vseh mogoče takoj poravnati. Zlasti pri stalnem toku prenosov se lahko takojšnji povratki posrednika odložijo za nedoločen čas.
Razmislite o preprečevanju relejev, ki bi povzročili, da čakajoče rezerve presežejo tekoče rezerve.
Posodobitev: Popravljeno ob objavi 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Meje premostitvenega parametra se ne ujemajo
O deposit
funkcija od BridgeDepositBox
pogodba, razporejena v verigah plasti 2, se uporablja za premostitev sredstev med L2 in L1. Predvsem so posredniki spodbujeni, da rele podrobnosti transakcije na povezanem L1 BridgePool
. Vendar pa depozitni predal uporablja vključujoče meje za omejitev pristojbin za rele, medtem ko uporablja bazen za most izključne meje. To pomeni, da nekaterih depozitov (s 25-odstotnimi provizijami za prenos) ni mogoče posredovati, sredstva pa bodo nedostopna na obeh ravneh.
Razmislite o sinhronizaciji preverjanj na obeh ravneh, da zagotovite, da se lahko vsi veljavni depoziti posredujejo.
Posodobitev: Popravljeno v objavi 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. To je bilo prvotno razvrščeno kot kritična resnost, vendar je bilo znižano, ko je ekipa UMA poudarila, da sredstva ne bodo strogo ujetja in se lahko sprostijo, če se volivci DVM strinjajo, da sprejmejo spremenjen opis releja za prizadete depozite.
Srednja resnost
[M01] Povratni klici na napačen naslov
O SkinnyOptimisticOracle
prikliče funkcije povratnega klica na zahtevniku cen, če obstajajo, tako da se lahko zahtevnik odzove na pomembne spremembe stanja. Vendar je povratni klic nepravilno priklican na predlagatelju cene namesto na vlagatelju zahteve za ceno o proposePriceFor
funkcija. To pomeni, da se vlagatelj zahteve za ceno ne more odzvati na predloge cen.
Na srečo ta funkcija ni uporabljena v trenutni kodni bazi. Kljub temu razmislite o sklicu na priceProposed
povratni klic na prosilca.
Posodobitev: Popravljeno ob potrditvi 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Napačna funkcija dodajanja
O appendKeyValueBytes32
funkcija bi moral svoje vnose združiti v oblikovano bytes
niz. Vendar pa je currentAncillaryData
is nepravilno zavržen.
Ker so pomožni podatki vpliva na postopek reševanja Oracle, bi lahko nepravilna vrednost spodkopala rezultate Oracle. Na srečo obstaja le en klic na appendKeyValueBytes32
v zbirki kode in uporablja prazno currentAncillaryData
medpomnilnik, tako da napaka ne vpliva na ta primer.
Razmislite o posodobitvi appendKeyValueBytes32
deluje tako, da currentAncillaryData
je vključen v vrnjeno matriko bajtov.
Posodobitev: Popravljeno v objavi 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Nepopolna validacija pomožnih podatkov
O LongShortPair
konstruktor potrjuje, da customAncillaryData
je dovolj majhna. Vendar pa ne upošteva polje zgodnjega izteka. To pomeni optimistični orakelj lahko nepričakovano zavrne zahteve po ceni predčasnim iztekom, kar bi onemogočilo to funkcijo.
Razmislite o posodobitvi preverjanja, da bo upoštevalo dodatno polje.
Posodobitev: Popravljeno ob objavi 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Nepravilno obdelan ničelni časovni žig
v LongShortPair
pogodbe je časovni žig predčasnega izteka nič uporablja kot zastavo pomeni, da nihče ni sprožil mehanizma predčasnega izteka. Vendar pa je mogoče sproži ta mehanizem z ničelnim časovnim žigom. V tem scenariju bo priklican optimistični orakelj, vendar zaščita pred poznejšimi zahtevami po ceni ne bo učinkovito. Na srečo enkrat izbrana je poravnalna cena, ne bo razveljavljen, tako da to ne bo povzročilo nedoslednih poravnav. Kljub temu bi lahko naknadno povpraševanje po ceni spremenite zabeleženi časovni žig predčasnega poteka, tudi če se za določitev cene poravnave uporabi ničelni časovni žig. Lahko bi tudi oddajo zavajajoč dogodek.
Razmislite o preprečevanju predčasnega poteka z ničelnim časovnim žigom.
Posodobitev: Popravljeno ob objavi 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Možna ničelna vez
O requestPrice
funkcija SkinnyOptimisticOracle
Naročilo uporabi končno provizijo kot obveznico če vezava ni določena. Vendar pa je requestAndProposePriceFor
funkcija lahko uporablja ničelno vez, kar je v nasprotju z njenim @notice
in @param
komentarji. Ničelna vezava oslabi spodbudo za neveljavne predloge ali spore.
Na srečo, na kliče samo to funkcijo v osnovi kode nastavi obveznico predlagatelja. Kljub temu razmislite o uporabi končne provizije, če obveznica ni navedena.
Posodobitev: Popravljeno ob objavi daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Nepotrebne skrbniške pravice
O BridgePool
Naročilo podeduje od ExpandedERC20
tako da lahko izda žetone LP ponudnikom likvidnosti. To podeduje funkcionalnost OpenZeppelina ERC20
pogodbo in tudi zagotavlja skrbniške pravice pogodbenemu izvajalcu, ki jim omogoča kovanje in zapisovanje žetonov LP. Vendar to pooblastilo ni potrebno in bi lahko, če bi se izvajalo, nepravično kaznovalo ponudnike likvidnosti.
Razmislite o spremembi BridgePool
neposredno dedovati ERC20
Namesto ExpandedERC20
.
Posodobitev: Popravljeno v objavi 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Nizka resnost
[L01] Ni mogoče poravnati ob izteku
O settle
funkcija LongShortPair
Naročilo upošteva pogoje poravnave ko je trenutni čas strogo pred ali za časovnim žigom poteka. Vendar pa se nepravilno vrne, ko se trenutni čas ujema s časovnim žigom poteka.
Razmislite o uporabi vključujoče vezave za ujemanje z postExpiration
sprememba.
Posodobitev: Popravljeno v objavi f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Manjkajoče sporočilo o napaki v zahtevku
Obstaja zahtevana izjava v BridgePool
Naročilo brez sporočila o napaki.
Razmislite o vključitvi posebnih in informativnih sporočil o napakah v vse zahteve.
Posodobitev: Popravljeno ob objavi 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Manjkajoči nizi dokumentov
Obstaja nekaj primerov v celotni kodni bazi, kjer je Ethereum Natural Specification manjka ali je nepopoln. Primeri vključujejo:
Razmislite o temeljitem dokumentiranju vseh funkcij (in njihovih parametrov), ki so del javnega API-ja pogodbe.
Posodobitev: Označeni komentarji so bili popravljeni v objavi e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Popolnosti NatSpec v preostali bazi kode nismo preverili.
Opombe in dodatne informacije
[N01] Vrednost povratnega klica ni preverjena
v deposit
funkcija L2 BridgeDepositBox
pogodba obstaja klic na nizki ravni l2Token
ko l1Token
is l1Weth
. Ta klic na nizki ravni je namenjen deposit()
funkcijo, ki pripada WETH vmesnik. Če to l2Token
obnaša se natanko tako kot WETH, ne bi smel nikoli odpovedati. Toda v primeru, l2Token
obnaša drugače in ne uspe, ne bi prišlo do vrnitve, ker zastavica uspeha tega klica na nizki ravni ni nikoli preverjena.
Razmislite o preverjanju in ustreznem odzivu na povratne vrednosti vseh klicev nizke ravni.
[N02] Pomanjkanje indeksiranih parametrov v dogodkih
Številni dogodki, definirani v tej kodni bazi, imajo parametre, ki jih je treba indeksirati:
Razmislite indeksiranje parametrov dogodka da bi se izognili oviranju nalog storitev zunaj verige, ki iščejo in filtrirajo določene dogodke.
Posodobitev: Delno popravljeno v objavi d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. chainId
parameter WhitelistToken
ni bil posodobljen.
[N03] Implicitna nedoslednost pri ulivanju
O LongShortPair
pogodba na splošno obravnava časovne žige kot uint64
vrednosti, ki so implicitno uvrščeni v uint256
vrednosti, ko prenesel na Optimistični orakelj. Vendar pa requestTimestamp
parameter o _requestOraclePrice
funkcija je predčasno oddan v a uint256
. To nima funkcionalnih posledic.
Kljub temu zaradi doslednosti razmislite o uporabi a uint64
za ta parameter in omogočanje njegove implicitne pretvorbe v a uint256
ko se posreduje Optimističnemu Oraklju.
Posodobitev: Popravljeno v objavi 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Časovni žig je zdaj eksplicitno ustvarjen.
[N04] Napačna vrsta
O sendMessage
funkcija iOptimism_CrossDomainMessenger
vmesnik uporablja a uint256
meja plina medtem ko je Optimizem OVM_CrossDomainEnabled
uporablja a uint32
meja plina.
Za doslednost in predvidljivost razmislite o posodobitvi iOptimisim_CrossDomainMessenger
sendMessage
funkcija za uporabo a uint32
omejitev plina.
Posodobitev: Popravljeno ob objavi 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Pomanjkanje validacije
Vse funkcije v BridgeAdmin
ta klic _relayMessage
predpostavimo, da se vrednost transakcije ujema z l1CallValue
parameter, vendar ta ni uveljavljen.
Razmislite o zagotavljanju pravilnega msg.value
je nastavljeno.
Posodobitev: Popravljeno ob objavi f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Berljivost
O _getDepositHash
funkcija od BridgePool
pogodba odvija depositData
struct interstice the l1Token
kot argument v sestavi keccak256
s abi
kodiranje. Zaradi tega je operacija po nepotrebnem podrobna in lahko pri ponovni implementaciji na drugih ravneh povzroči napake.
Razmislite o poenostavitvi argumentov, da bodo preprosto urejeni par depositData
in l1Token
.
Posodobitev: Popravljeno ob objavi 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Funkcija ponovnega vstopa
O requestAndProposePriceFor
funkcija od SkinnyOptimisticOracle
pogodba pokliče osebo, ki ji ne zaupa msg.sender
vendar ga ne varuje a nonReentrant
modifikator. Čeprav se v tem primeru zdi, da to ni varnostna skrb, lahko povzroči nepričakovano vedenje.
Razmislite o dodajanju nonReentrant
modifikator za vse funkcije, ki kličejo morebitne nezaupljive pogodbe.
Posodobitev: Popravljeno v objavi b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
ni prijavljen
O relayMessage
funkcija od Arbitrum_Messenger
pogodba po izvedbi občutljivega dejanja ne sproži ustreznega dogodka. The relayMessage
funkcijske klice kot podprogram sentTxToL2NoAliasing
ki sama vrne uint256
vrednost seqNum
, vendar ta vrnjena vrednost ni prijavljena v relayMessage
Funkcija.
Razmislite o oddajanju dogodkov, potem ko pride do občutljivih sprememb, da olajšate sledenje in obvestite stranke izven verige po dejavnosti pogodbe.
Posodobitev: Popravljeno ob objavi 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Tiskarske napake
Baza kode vsebuje naslednje tipkarske napake:
Razmislite o popravku teh tipkarskih napak, da izboljšate berljivost kode.
Posodobitev: Popravljeno ob objavi 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Nedokumentirana zahteva za odobritev ERC20
O requestEarlyExpiration
in expire
funkcije od LongShortPair
Vsaka pogodba predvideva, da je klicatelj pogodbi dodelil dodatek potegnite nagrado predlagatelja.
Zaradi predvidljivosti razmislite o dokumentiranju te zahteve v komentarjih funkcij.
Posodobitev: Popravljeno v objavi da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Neuporabljen modifikator
v BridgePool
pogodba, onlyFromOptimisticOracle
sprememba je definiran, vendar se nikoli ne uporablja v kodni bazi in ga je zato treba odstraniti.
Posodobitev: Popravljeno v objavi 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
Sklepi
Najdeni sta bili 2 kritični in 1 zelo resna težava. Nekatere spremembe so bile predlagane zaradi upoštevanja najboljših praks in zmanjšanja potencialne površine napadov.
- &
- 7
- Račun
- Ukrep
- aktivna
- Ad
- Dodatne
- Naslov
- admin
- Prednost
- vsi
- Dovoli
- API
- Argumenti
- Revizija
- razpoložljivost
- počutje
- BEST
- najboljše prakse
- blockchain
- Pasovi
- MOST
- Bug
- hrošči
- klic
- primeri
- ujete
- Vzrok
- izziv
- spremenite
- preverjanje
- Koda
- komentarji
- konfiguracija
- Vsebuje
- Naročilo
- pogodbe
- bi
- Trenutna
- datum
- Decentralizirano
- zamuda
- Oblikovanje
- določanje
- DID
- Spor
- Ne
- Zgodnje
- Gospodarska
- Edge
- Učinkovito
- ERC20
- ETH
- ethereum
- ethereum blockchain
- Event
- dogodki
- Primer
- Izmenjava
- Pričakuje
- izkušnje
- Feature
- pristojbine
- finančna
- prva
- fiksna
- Flash
- sledi
- je pokazala,
- funkcija
- Sklad
- Skladi
- Prihodnost
- GAS
- pristojbine za plin
- Giving
- upravljanje
- srečna
- ob
- tukaj
- visoka
- Poudarjeno
- imetniki
- Kako
- HTTPS
- incentivize
- vključeno
- Vključno
- Povečajte
- Podatki
- obresti
- vmesnik
- Vprašanja
- IT
- znano
- vodi
- Knjižnica
- Tekočina
- likvidnostno
- ponudniki likvidnosti
- Seznam
- Posojila
- lokalno
- zaklenjeno
- LP
- LP
- Tržna
- Stave
- Najbolj
- odprite
- Oracle
- Ostalo
- platforma
- bazen
- Bazeni
- moč
- preprečevanje
- Cena
- Postopek
- snubitev
- zagotavljajo
- zagotavlja
- javnega
- Razlogi
- zmanjša
- Poročila
- REST
- Rezultati
- vrne
- pregleda
- Tveganje
- varnost
- Storitve
- nastavite
- naselje
- Kratke Hlače
- pomemben
- Podoben
- majhna
- So
- trdnost
- nekdo
- Nekaj
- hitrost
- preživeti
- Država
- Izjava
- shranjevanje
- uspeh
- Podprti
- Površina
- sistem
- Test
- skozi
- vsej
- čas
- žeton
- Boni
- vrh
- Sledenje
- transakcija
- Transakcije
- Zaupajte
- Nadgradnja
- posodobitve
- UPS
- Uporabniki
- vrednost
- Poglej
- whitelist
- WHO
- v
- brez
- delo
- vredno
- nič