Desember 1, 2021
UMA er en plattform som lar brukere inngå tillitsminimerte finansielle kontrakter på Ethereum-blokkjeden. Vi har tidligere revidert det desentraliserte oraklet, en bestemt finansiell kontraktsmal, noen ad hoc pull-forespørsler, den evigvarende flerpartsmalen og ulike inkrementelle pull-forespørsler over et lengre engasjement. I denne revisjonen gjennomgikk vi en ny mekanisme for raskt å sende tokens fra en lag 2-kjede til Ethereum-nettverket, og relaterte endringer til Optimistic Oracle. Gjennomgangen ble gjennomført av 2 revisorer over 3 uker.
Omfang
Den reviderte forpliktelsen er f24ad501c8e813cf685f72217e7f13c8f3c366df
og omfanget inkluderer følgende kontrakter:
- kontrakter/forsikringsbro/* (unntatt testkontrakter)
- kontrakter-ovm/forsikringsbro/implementering/*
- kontrakter/felles/implementering/AncillaryData.sol
- kontrakter/oracle/implementering/SkinnyOptimisticOracle.sol
Vi har også gjennomgått endringene i solidity-filer i Trekk forespørsel 3445.
Alle eksterne kode- og kontraktsavhengigheter ble antatt å fungere som dokumentert.
Systemoversikt
De støttede lag 2 (L2)-kjedene, Optimism og Arbitrum, gir en mekanisme for å overføre midler til Ethereum-nettverket (L1). Av sikkerhetsmessige årsaker er det imidlertid en betydelig forsinkelse før disse overføringene er fullført. For å løse dette kan innehavere av L2-tokener sette inn penger i en UMA-kontrakt, Deposit Box, vel vitende om at tokens til slutt vil bli overført (som en batch) til en L1 UMA-kontrakt, Bridge Pool. Det er en egen Bridge-pool for hvert token som skal overføres.
Etter et L2-innskudd kan hvem som helst videresende detaljene til L1 Bridge Pool, som venter en kort periode i tilfelle noen ønsker å bestride den videresendte informasjonen. Alle tvister håndteres av Skinny Optimistic Oracle (beskrevet nedenfor). Før de aksepterer reléet, må likviditetstilbydere forhåndsfinansiere Bridge Pool-kontrakten i bytte mot LP-tokens. Uomtvistede reléer antas å være gyldige, og Bropoolen gjennomfører overføringen ved bruk av egne reserver, hvor en brøkdel av overføringen viderekobles til reléet og en brøkdel beholdes som likviditetsgebyr. Midlene vil til slutt fylles på når L2-innskuddet er fullført, og likviditetsgebyrene blir tildelt LP-token-innehaverne.
Bridge Pool lar også hvem som helst individuelt finansiere en overføring (uten Bridge Pool-reservene) før tvisteperioden utløper, i bytte mot en brøkdel av overføringsbeløpet. Siden stafetten fortsatt kan bestrides, ville disse midlene gå tapt dersom stafetten ble ansett for å være feil. Det forventes at i de fleste tilfeller vil denne mekanismen tillate brukere å oppleve umiddelbare L2-til-L1-tokenoverføringer.
Skinny Optimistic Oracle er konseptuelt veldig lik det eksisterende Optimistic Oracle. Det gir en insentivmekanisme for brukere til å bare hevde resultatet av en orakelforespørsel, som antas å være nøyaktig hvis den ikke er bestridt. Tvister er henvist til den langsommere DVM-mekanismen beskrevet i våre tidligere revisjonsrapporter. Hovedforskjellen er at den nye versjonen krever at brukere oppgir all relevant informasjon når de utfører funksjonskall, slik at verdiene ikke trenger å lagres eller hentes fra lagring. Det fjerner også muligheten for forespørsler til å endre konfigurasjonsparametere i aktive forespørsler.
Vi har tidligere gjennomgått Long-Short-Pair-kontrakten, som gir en generisk mekanisme for å lage ulike finansielle instrumenter. Disse kontraktene kan løses når deres utløpstid er nådd og oppgjørsprisen er kjent. Endringene introdusert av Pull Request 3445 introduserer muligheten for å løse kontraktene tidlig dersom oppgjørsprisen er kjent før utløpstidspunktet.
Privilegerte roller
L2-innskuddsboksene har flere konfigurasjonsparametere, inkludert støttede tokens og maksimal hastighet for å sende batchede tokens over broen til L1. De må også konfigureres for å sikre konsistens mellom L1-tokenkontrakten, L2-tokenkontrakten og den tilsvarende bropoolen. Disse parametrene er satt av en administratorkontrakt på L1, som også parameteriserer tvisteløsningsprosessen til brobassengene. Kontrakten forventes å bli kontrollert av UMA-styringsmekanismen, så brukere må stole på denne prosessen for å administrere systemet fornuftig og rettferdig.
Økosystemavhengigheter
Alle gjennomgåtte komponenter bruker tidsbasert logikk, noe som betyr at de er avhengige av Ethereum-tilgjengelighet. Spesielt, hvis tvistetransaksjoner blir betydelig forsinket, kan ugyldige releer eller prisforslag være feilaktig bekreftet.
I tillegg antar token-broen implisitt at alle midler som sendes til L2-innskuddsbokser til slutt vil bli overført til den tilsvarende L1-bropoolen. Dette er avhengig av korrekt og fortsatt funksjon av Optimisme- og Arbitrum-broene, og deres tvisteløsningsmekanismer.
Til slutt tildeles tokens som sendes til L2-depotet til brobassenget i L1, ikke den tiltenkte mottakeren. For å hente midlene fra bassenget, må L1-tokenholdere først matche dem med ytterligere tokens. Derfor er mekanismen avhengig av et tilstrekkelig dypt marked av L1-tokens for å sikre at det alltid er likviditet.
Klientrapporterte problemer
Under tilsynet identifiserte UMA-teamet uavhengig en rekke problemer og atferd som er verdt å fremheve:
Hvis Optimistic Oracle- eller Bridge Admin-parametrene endres i løpet av en relés utfordringsperiode, sletter reléet å bestride reléet uten ytterligere regress for verken forslagsstilleren eller tvisten. Tenk deg for eksempel at reléet sendes for sikkerhetstoken
TOKEN_A
, men midt i stafettenTOKEN_A
fjernes fra sikkerhetslisten. En tvist vil nå gå tilbake siden du ikke kan sende inn noen prisforespørsler til OO eller DVM for ikke-hvitelistet sikkerhet. Siden vi ikke ønsker å blokkere gyldige tvisteforespørsler,BridgePool
vil slette det ventende reléet forTOKEN_A
i tilfelle en tvist. Konsekvensene av denne designbeslutningen er:
1. En økning i den endelige avgiften vil føre til: Enhver utestående relé på det tokenet kan "kanselleres" gjennom uenighet om det er riktig eller galt. En kansellering fordeler ikke noen av partene, så den forutsetter eksistensen av ærlige tvister som er villige til å drepe den (sjeldne) dårlige forespørselen som tilfeldigvis eksisterer under en endelig utførelse av gebyrendring. Dette betyr også at det er mulig for en sørgende å bruke gass for å kansellere reléer og tvinge dem til å bli videresendt.
2. En avhvitelisting av identifikatoren eller tokenet, som ikke bør skje med mindre noe går veldig galt, vil føre til:
3. En utvidet periode med ubestridelige forespørsler der enhver forespørsel kan kanselleres og det ikke finnes økonomiske insentiver for å tviste. Dette virker bedre enn alternativet med å blokkere tvister fullstendig, men det er riktignok ganske ille, ettersom enhver som sørger kan blokkere reléer på ubestemt tid ved å betale gass eller sende dårlige reléer uten straff (annet enn gassavgifter).Merk: dette er et alternativ til å ha OO som "fryser" parametere som den endelige avgiften eller hvitelisten for sikkerhetsstillelser i en stund, men dette vil kreve ytterligere oppringninger til OO, noe som vil være kostbart for den lykkelige veien.
Reléer kan øke hastigheten via
speedUpRelay()
etter at de passerer livlighet. Selv om vi ikke ser noen risiko med dette, åpner det opp for muligheten for flashlån + speed ups + oppgjør etter liveness, noe som gir flash-låneren den umiddelbare reléavgiften "gratis". Dette forhindrer vi i dette foreslåtte PR.
On
settle
, hvisBridgePool
er enWETH
pool og mottakeren er en kontrakt som ikke er detpayable
(kan ikke godta ETH), dasettle
vil mislykkes. Vi planlegger å fikse dette og fallback på sendingWETH
, men det er ikke gjort noe enestående arbeid med dette ennå.
In
relayDeposit
, sjekker vi atBridgePool
sin saldo er større enn beløpet som skal videresendes PLUSS forslagsstillerbindingen. Dette er en utdatert sjekk og for konservativ siden forslagsstillerbindingen trekkes fra brukeren etter kontrollen. Dette tar vi opp i dette foreslåtte PR.
Jeg fanget nettopp en feil hvor
chainId
inBridgePool
, inkludert som en del avDeposit
struct og som en funksjonsinngang til alle de relérelaterte funksjonene (dvs.relayDeposit
,speedUpRelay
,settle
) er typeuint8
. Dette er for lite av typen til å håndtere for eksempel Arbitrum hvis ID er 421611. Vi fanget faktisk denne feilen og fikset den på L2-siden:BridgeDeposit
har satt sinchainId
skriv tiluint256
. Denne PR vil gjørechainId
onBridgePool
matche typen påBridgeDepositBox
: UMA-protokoll/protokoll#3463
Tidligere trakk ikke tvistefunksjonen av innskuddsbeløpet fra
pendingReserves
(dette er variabelen som sporer hvor mye av reservebassenget som er låst på grunn av stafetter som ikke har avgjort ennå). Resultatet var at hver tvist ville låse stafettmengden i bassenget på ubestemt tid. Den kan ikke trekkes tilbake av LP-er eller brukes av fremtidige stafetter. Fix er her: UMA-protokoll/protokoll#3473.
Vi fant en feil i
BridgeDepositBox
hvorhasEnoughTimeElapsedToBridge
sjekker ikke om enuint256
verdien er lik0
som standard: Rettet i PR 3484
Valutakursmetoden (som er tilstandsmodifiserende) kalles mellom tokens som overføres og LP-tokens preges i addLiquidity-metoden til bropoolkontrakten. Denne beregningen må flyttes opp til toppen av metoden. Dette forårsaker veldig merkelige tilstandsverdier. Se PR her. å fikse.
Visningsmetoden
liquidityUtilizationPostRelay
(som kun brukes offchain), rapporterer feil bruksnummer. Nevneren på denne linjen bør ikke være rettferdigliquidReserves
, bør det i stedet være en representasjon av uutnyttede og utnyttede reserver. Fikset her..
Oppdater
I tillegg til feilrettingene har vi også gjennomgått følgende inkrementelle endringer:
- PR3500 fjerner den redundante token-parameteren fra
BridgePool
arrangementer. - PR3478 legger den endelige DVM-avgiften til listen over lokalt bufrede variabler.
- PR3460 står for en mulig negativ likviditetsutnyttelseskantsak (i tillegg til å adressere N04)
- PR3482 fjerner overflødige filer og oppdaterer OVM-konstanter i samsvar med OVM 2.0-endringer.
- PR3585 oppdaterer
BridgeDepositBox
grensesnitt for konsistens og bruker OpenZeppelinSafeERC20
bibliotek.
Mens vi gjennomgikk rettelsene, identifiserte vi et annet problem. Ved fastsettelse av verdien av BridgePool
LP tokens, det er en mellomberegning som kan uventet negativt overløp, som midlertidig vil deaktivere å legge til og fjerne likviditet. Beregningen bør omorganiseres for å legge til de utnyttede reservene før de ikke-fordelte avgiftene trekkes fra.
Kritisk alvorlighetsgrad
[C01] Belønning for fanget forslagsstiller
De LongShortPair
kontrakt henter en forslagsstillerbelønning fra hvilken adresse som utløser utløpet, som brukes til å stimulere prisforslag i Optimistic Oracle. Imidlertid LongShortPairCreator
kontrakt også henter og videresender midlene fra distribusjonsadressen. Disse ekstra midlene overføres ikke til det optimistiske oraklet, og forblir i stedet fanget innenfor LongShortPair
kontrakt.
Vurder å fjerne duplikatoverføringen.
Oppdatering: Fast fra og med commit 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Høy alvorlighetsgrad
[H01] Samtidige reléer tømmer reserver
De relayDeposit
funksjon av BridgePool
kontrakt sikrer at kontrakten har tilstrekkelige midler for å utføre overføringen. Det tar imidlertid ikke hensyn til de ventende reservene, som sporer midler som er øremerket aktive stafetter. Derfor kan flere samtidige reléer stole på de samme midlene, og de kan ikke alle gjøres opp umiddelbart. Spesielt, med en jevn strøm av overføringer, kan øyeblikkelig reléretur bli forsinket på ubestemt tid.
Vurder å forhindre releer som vil føre til at de ventende reservene overskrider væskereservene.
Oppdatering: Fast fra og med commit 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Grensene for brokoblingsparameter stemmer ikke overens
De deposit
funksjon av BridgeDepositBox
kontrakt, utplassert på lag 2-kjeder, brukes til å bygge bro mellom L2 og L1. Spesielt er reléer incentivert til relé transaksjonsdetaljene på den tilknyttede L1 BridgePool
. Imidlertid bruker panteboksen inkluderende grenser å begrense stafettavgiftene, mens brubassenget bruker eksklusive grenser. Dette betyr at enkelte innskudd (med 25 % stafettavgift) ikke kan videresendes, og midlene vil være utilgjengelige på begge lag.
Vurder å synkronisere valideringene på begge lag for å sikre at alle gyldige innskudd kan videresendes.
Oppdatering: Rettet i commit 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Dette ble opprinnelig klassifisert som kritisk alvorlighetsgrad, men ble nedgradert da UMA-teamet påpekte at midlene ikke ville være strengt fanget og kunne frigjøres hvis DVM-velgerne gikk med på å godta en modifisert relébeskrivelse for berørte innskudd.
Middels alvorlighetsgrad
[M01] Tilbakeringinger til feil adresse
De SkinnyOptimisticOracle
påkaller tilbakeringingsfunksjoner på prisanmoderen, hvis de finnes, slik at forespørren kan svare på betydelige tilstandsendringer. Tilbakeringingen er imidlertid feilaktig påberopt prisforslagsstilleren i stedet for prisanmoderen i de proposePriceFor
funksjon. Dette betyr at prissøker ikke kan svare på prisforslag.
Heldigvis brukes ikke denne funksjonen i den nåværende kodebasen. Vurder likevel å påkalle priceProposed
tilbakeringing av rekvirenten.
Oppdatering: Rettet ved commit 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Defekt tilleggsfunksjon
De appendKeyValueBytes32
funksjon bør kombinere sine innganger til en formatert bytes
array. Imidlertid currentAncillaryData
is feilaktig kassert.
Siden tilleggsdataene påvirker orakeloppløsningsprosessen, kan en feil verdi undergrave orakelresultatene. Heldigvis er det bare en samtale til appendKeyValueBytes32
i kodebasen, og den bruker en tom currentAncillaryData
buffer, så feilen påvirker ikke denne saken.
Vurder å oppdatere appendKeyValueBytes32
fungerer slik at currentAncillaryData
er inkludert i den returnerte byte-matrisen.
Oppdatering: Rettet i commit 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Ufullstendig validering av tilleggsdata
De LongShortPair
konstruktør bekrefter at customAncillaryData
er liten nok. Det tar imidlertid ikke hensyn til tidlig utløpsfelt. Dette betyr det optimistiske oraklet kan uventet avvise prisforespørsler om tidlig utløp, noe som vil deaktivere denne funksjonen.
Vurder å oppdatere valideringen for å ta hensyn til tilleggsfeltet.
Oppdatering: Fast fra og med commit 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Feilhåndtert null tidsstempel
på LongShortPair
kontrakt, er et null tidsstempel for tidlig utløp brukt som flagg for å indikere at ingen har utløst mekanismen for tidlig utløp. Det er imidlertid mulig å utløse den mekanismen med null tidsstempel. I dette scenariet vil det optimistiske oraklet bli påberopt, men det beskyttelse mot senere prisforespørsler vil ikke være effektiv. Heldigvis en gang avregningspris velges, vil den ikke bli overstyrt, så dette vil ikke føre til inkonsekvente oppgjør. Likevel kunne en påfølgende prisforespørsel endre det registrerte tidsstempelet for tidlig utløp, selv om nulltidsstemplet brukes til å bestemme oppgjørsprisen. Det kunne det også avgir en villedende hendelse.
Vurder å forhindre tidlig utløp ved å bruke null-tidsstemplet.
Oppdatering: Fast fra og med commit 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Mulig nullbinding
De requestPrice
funksjon av SkinnyOptimisticOracle
kontrakt bruker sluttgebyret som obligasjonen dersom obligasjonen ikke er spesifisert. Imidlertid requestAndProposePriceFor
funksjon kan bruke en nullbinding, som motsier dens @notice
og @param
kommentarer. En nullbinding svekker insentivet mot ugyldige forslag eller tvister.
Heldigvis bare kall til denne funksjonen i kodebasen setter en forslagsstillerbinding. Vurder likevel å bruke den endelige avgiften hvis obligasjonen ikke er spesifisert.
Oppdatering: Fast fra og med commit daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Unødvendige administratorrettigheter
De BridgePool
kontrakt arver fra ExpandedERC20
slik at den kan utstede LP-tokens til likviditetstilbydere. Dette arver funksjonaliteten til OpenZeppelin ERC20
kontrakt og også gir administratorrettigheter til kontraktsleverandøren, som lar dem prege og brenne LP-tokens. Denne makten er imidlertid ikke nødvendig, og hvis den utøves, kan den urettferdig straffe likviditetstilbydere.
Vurder å endre BridgePool
å arve direkte fra ERC20
istedenfor ExpandedERC20
.
Oppdatering: Rettet i commit 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Lav alvorlighetsgrad
[L01] Kan ikke avgjøres ved utløp
De settle
funksjon av LongShortPair
kontrakt vurderer oppgjørsforhold når gjeldende tid er strengt tatt før eller etter utløpstidsstempelet. Den går imidlertid tilbake på feil måte når gjeldende tid samsvarer med utløpstidsstempelet.
Vurder å bruke en inkluderende binding for å matche postExpiration
modifier.
Oppdatering: Rettet i commit f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Manglende feilmelding i krav-setningen
Det er en kraverklæring i BridgePool
kontrakt uten feilmelding.
Vurder å inkludere spesifikke og informative feilmeldinger i alle kravutsagn.
Oppdatering: Fast fra og med commit 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Manglende dokumentstrenger
Det er noen tilfeller i hele kodebasen hvor Ethereum naturlig spesifikasjon mangler eller er ufullstendig. Eksempler inkluderer:
Vurder å dokumentere alle funksjoner (og deres parametere) som er en del av kontraktens offentlige API.
Oppdatering: De uthevede kommentarene ble fikset i commit e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Vi validerte ikke fullstendigheten av NatSpec i resten av kodebasen.
Merknader og tilleggsinformasjon
[N01] Anropsreturverdi er ikke merket
på deposit
funksjon av L2 BridgeDepositBox
kontrakt er det et lavt nivå samtale til l2Token
når l1Token
is l1Weth
. Denne samtalen på lavt nivå er til deposit()
funksjon, som tilhører weth grensesnitt. Hvis dette l2Token
oppfører seg akkurat som WETH det bør aldri svikte. Men i tilfellet l2Token
oppfører seg annerledes og mislykkes, vil det ikke være noen tilbakestilling siden suksessflagget til denne samtalen på lavt nivå aldri blir sjekket.
Vurder å sjekke og reagere på riktig måte på returverdiene for alle samtaler på lavt nivå.
[N02] Mangel på indekserte parametere i hendelser
Mange av hendelsene definert i denne kodebasen har parametere som bør indekseres:
Vurder indeksering av hendelsesparametere for å unngå å hindre oppgaven med å søke etter og filtrere etter spesifikke hendelser utenfor kjeden.
Oppdatering: Delvis fikset i commit d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. De chainId
parameter av WhitelistToken
ble ikke oppdatert.
[N03] Implisitt støpeinkonsistens
De LongShortPair
kontrakt generelt behandler tidsstempler som uint64
verdier, som er implisitt støpt til uint256
verdier når overført til det optimistiske oraklet. Imidlertid requestTimestamp
parameter av de _requestOraclePrice
funksjon er for tidlig støpt til en uint256
. Dette har ingen funksjonelle konsekvenser.
Ikke desto mindre, for å oppnå konsistens, bør du vurdere å bruke en uint64
for denne parameteren og lar den implisitt kastes til en uint256
når den ble overført til det optimistiske oraklet.
Oppdatering: Rettet i commit 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Tidsstemplet er nå eksplisitt gitt.
[N04] Feil type
De sendMessage
funksjon av iOptimism_CrossDomainMessenger
grensesnitt bruker a uint256
gassgrense mens Optimismen er OVM_CrossDomainEnabled
bruker a uint32
gassgrense.
For konsistens og forutsigbarhet bør du vurdere å oppdatere iOptimisim_CrossDomainMessenger
sendMessage
funksjon for å bruke en uint32
gassgrense.
Oppdatering: Fast fra og med commit 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Manglende validering
Alle funksjoner i BridgeAdmin
den samtalen _relayMessage
anta at transaksjonsverdien samsvarer med l1CallValue
parameter, men dette håndheves ikke.
Vurder å sikre riktig msg.value
er satt.
Oppdatering: Fast fra og med commit f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Lesbarhet
De _getDepositHash
funksjon av BridgePool
kontrakten ruller ut depositData
struct for å skille mellom l1Token
som et argument i sammensetningen av keccak256
med abi
koding. Dette gjør operasjonen unødvendig omfattende og kan føre til feil når den implementeres på nytt på andre lag.
Vurder å forenkle argumentene til bare å være det ordnede paret depositData
og l1Token
.
Oppdatering: Fast fra og med commit 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Reentrant funksjon
De requestAndProposePriceFor
funksjon av SkinnyOptimisticOracle
kontrakt ringer til en utrustet msg.sender
men er ikke bevoktet av en nonReentrant
modifikator. Selv om dette i dette tilfellet ikke ser ut til å være et sikkerhetsproblem, kan dette introdusere uventet oppførsel.
Vurder å legge til nonReentrant
modifikator til alle funksjoner som ringer til muligens uklarerte kontrakter.
Oppdatering: Rettet i commit b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
ikke logget
De relayMessage
funksjon av Arbitrum_Messenger
kontrakten avgir ikke en relevant hendelse etter å ha utført en sensitiv handling. De relayMessage
funksjonsanrop som en subrutine sentTxToL2NoAliasing
som selv returnerer uint256
verdi seqNum
, men denne returverdien er ikke logget på relayMessage
funksjon.
Vurder å sende ut hendelser etter at sensitive endringer finner sted, for å lette sporing og varsle klienter utenfor kjeden etter kontraktens aktivitet.
Oppdatering: Fast fra og med commit 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Typografiske feil
Kodebasen inneholder følgende skrivefeil:
Vurder å rette disse skrivefeilene for å forbedre kodelesbarheten.
Oppdatering: Fast fra og med commit 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Udokumentert ERC20-godkjenningskrav
De requestEarlyExpiration
og expire
funksjoner av LongShortPair
kontrakt hver forutsetter at den som ringer har gitt kontrakten en godtgjørelse til trekke forslagsstillerens belønning.
Vurder for forutsigbarhetens skyld å dokumentere dette kravet i funksjonskommentarene.
Oppdatering: Rettet i commit da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Ubrukt modifikator
på BridgePool
kontrakt, den onlyFromOptimisticOracle
modifier er definert, men brukes aldri i kodebasen og bør derfor fjernes.
Oppdatering: Rettet i commit 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
Konklusjoner
Det ble funnet 2 kritiske og 1 problemer med høy alvorlighetsgrad. Noen endringer ble foreslått for å følge beste praksis og redusere potensiell angrepsoverflate.
- &
- 7
- Logg inn
- Handling
- aktiv
- Ad
- Ytterligere
- adresse
- admin
- Fordel
- Alle
- tillate
- api
- argumenter
- revisjon
- tilgjengelighet
- være
- BEST
- beste praksis
- blockchain
- Eske
- BRO
- Bug
- bugs
- ring
- saker
- fanget
- Årsak
- utfordre
- endring
- kontroll
- kode
- kommentarer
- Konfigurasjon
- inneholder
- kontrakt
- kontrakter
- kunne
- Gjeldende
- dato
- desentralisert
- forsinkelse
- utforming
- bestemme
- gJORDE
- Tvist
- ikke
- Tidlig
- økonomisk
- Edge
- Effektiv
- ERC20
- ETH
- ethereum
- Ethereum blockchain
- Event
- hendelser
- eksempel
- utveksling
- forventet
- erfaring
- Trekk
- avgifter
- finansiell
- Først
- Fix
- Blitz
- følge
- funnet
- funksjon
- fond
- midler
- framtid
- GAS
- gassavgift
- Giving
- styresett
- lykkelig
- å ha
- her.
- Høy
- Fremhevet
- holdere
- Hvordan
- HTTPS
- incentivise
- inkludert
- Inkludert
- Øke
- informasjon
- interesse
- Interface
- saker
- IT
- kjent
- føre
- Bibliotek
- Flytende
- Likviditet
- likviditetsleverandører
- Liste
- Lån
- lokalt
- låst
- LP
- LP
- marked
- Match
- mest
- åpen
- orakel
- Annen
- plattform
- basseng
- pools
- makt
- hindre
- pris
- prosess
- forslag
- gi
- gir
- offentlig
- grunner
- redusere
- Rapporter
- REST
- Resultater
- avkastning
- anmeldelse
- Risiko
- sikkerhet
- Tjenester
- sett
- bosetting
- Kort
- signifikant
- lignende
- liten
- So
- soliditet
- Noen
- noe
- fart
- bruke
- Tilstand
- Uttalelse
- lagring
- suksess
- Støttes
- overflaten
- system
- test
- Gjennom
- hele
- tid
- token
- tokens
- topp
- Sporing
- Transaksjonen
- Transaksjoner
- Stol
- Oppdater
- oppdateringer
- UPS
- Brukere
- verdi
- Se
- hviteliste
- HVEM
- innenfor
- uten
- Arbeid
- verdt
- null