1. December, 2021
UMA er en platform, der giver brugerne mulighed for at indgå tillidsminimerede finansielle kontrakter på Ethereum blockchain. Vi har tidligere revideret det decentraliserede orakel, en bestemt finansiel kontraktskabelon, nogle ad hoc pull-anmodninger, Perpetual Multiparty skabelonen , forskellige inkrementelle pull-anmodninger over et længere engagement. I denne revision gennemgik vi en ny mekanisme til hurtigt at sende tokens fra en lag 2-kæde til Ethereum-netværket og relaterede ændringer til det optimistiske Oracle. Gennemgangen blev gennemført af 2 revisorer over 3 uger.
Anvendelsesområde
Den reviderede forpligtelse er f24ad501c8e813cf685f72217e7f13c8f3c366df
og omfanget omfatter følgende kontrakter:
- kontrakter/forsikringsbro/* (ekskl. testkontrakter)
- kontrakter-ovm/forsikret-bro/implementering/*
- kontrakter/fælles/implementering/AncillaryData.sol
- kontrakter/oracle/implementation/SkinnyOptimisticOracle.sol
Vi gennemgik også ændringerne til solidity-filer i Træk anmodning 3445.
Alle eksterne kode- og kontraktafhængigheder blev antaget at fungere som dokumenteret.
Systemoversigt
De understøttede lag 2 (L2) kæder, Optimism og Arbitrum, giver en mekanisme til at overføre midler til Ethereum mainnet (L1). Af sikkerhedsmæssige årsager er der dog en betydelig forsinkelse, før disse overførsler er afsluttet. For at løse dette kan indehavere af L2-tokens indsætte midler i en UMA-kontrakt, Deposit Box, velvidende at tokens til sidst vil blive overført (som en batch) til en L1 UMA-kontrakt, Bridge Pool. Der er en separat Bridge Pool for hver token, der skal overføres.
Efter en L2-indbetaling kan enhver videresende detaljerne til L1 Bridge-puljen, som venter en kort periode, hvis nogen ønsker at bestride de videresendte oplysninger. Alle tvister håndteres af Skinny Optimistic Oracle (beskrevet nedenfor). Før de accepterer relæet, skal likviditetsudbydere forudfinansiere Bridge Pool-kontrakten i bytte for LP-tokens. Ubestridte relæer antages at være gyldige, og Bropuljen gennemfører overførslen med egne reserver, hvor en brøkdel af overførslen omdirigeres til relæet, og en brøkdel tilbageholdes som likviditetsgebyr. Midlerne vil i sidste ende blive genopfyldt, når L2-indbetalingen er afsluttet, og likviditetsgebyrerne tildeles LP-token-indehaverne.
Bridge-puljen giver også enhver mulighed for individuelt at finansiere en overførsel (uden Bridge-puljen-reserverne) inden tvistperioden udløber, til gengæld for en brøkdel af overførselsbeløbet. Da relæet stadig kan bestrides, ville disse midler gå tabt, hvis relæet blev anset for at være forkert. Det forventes, at denne mekanisme i de fleste tilfælde vil tillade brugere at opleve øjeblikkelige L2-til-L1-tokenoverførsler.
Skinny Optimistic Oracle er konceptuelt meget lig det eksisterende Optimistic Oracle. Det giver en incitamentmekanisme for brugere til blot at hævde resultatet af en orakelanmodning, som antages at være nøjagtig, hvis den ikke bestrides. Tvister henvises til den langsommere DVM-mekanisme, der er beskrevet i vores tidligere revisionsrapporter. Den væsentligste forskel er, at den nye version kræver, at brugerne angiver alle relevante oplysninger, når de udfører funktionskald, så værdierne ikke skal gemmes eller hentes fra lageret. Det fjerner også muligheden for, at rekvirenter kan ændre konfigurationsparametre i aktive anmodninger.
Vi har tidligere gennemgået Long-Short-Pair-kontrakten, som giver en generisk mekanisme til at skabe forskellige finansielle instrumenter. Disse kontrakter kan løses, når deres udløbstid er nået, og afregningsprisen er kendt. Ændringerne introduceret af Pull Request 3445 introducerer muligheden for at løse kontrakterne tidligt, hvis afregningsprisen kendes inden udløbstidspunktet.
Privilegerede roller
L2-indbetalingsboksene har flere konfigurationsparametre, herunder de understøttede tokens og den maksimale hastighed for at sende batchede tokens over broen til L1. De skal også konfigureres til at sikre overensstemmelse mellem L1-tokenkontrakten, L2-tokenkontrakten og den tilsvarende Bridge Pool. Disse parametre er fastsat af en administratorkontrakt på L1, som også parametrerer tvistbilæggelsesprocessen for bropuljerne. Kontrakten forventes at blive kontrolleret af UMA-styringsmekanismen, så brugerne skal stole på, at denne proces kan styre systemet fornuftigt og retfærdigt.
Økosystemafhængigheder
Alle gennemgåede komponenter bruger tidsbaseret logik, hvilket betyder, at de afhænger af Ethereums tilgængelighed. Især hvis tvisttransaktioner forsinkes væsentligt, kan ugyldige relæer eller prisforslag blive bekræftet forkert.
Derudover antager token-broen implicit, at alle midler, der sendes til L2-indbetalingsbokse, i sidste ende vil blive overført til den tilsvarende L1-bropulje. Dette er afhængigt af den korrekte og fortsatte funktion af Optimisme- og Arbitrum-broerne og deres tvistbilæggelsesmekanismer.
Til sidst tildeles tokens, der sendes til L2-deponeringsboksen, til bropuljen i L1, ikke den tilsigtede modtager. For at hente midlerne fra puljen skal indehavere af L1-tokens først matche dem med yderligere tokens. Derfor er mekanismen afhængig af et tilstrækkeligt dybt marked af L1-tokens til at sikre, at der altid er likviditet.
Kunderapporterede problemer
Under revisionen identificerede UMA-teamet uafhængigt en række problemer og adfærd, der er værd at fremhæve:
Hvis Optimistic Oracle- eller Bridge Admin-parametrene ændrer sig i løbet af et relæs udfordringsperiode, sletter relæet relæet uden yderligere klagemuligheder for hverken forslagsstilleren eller disputeren. Forestil dig f.eks., at relæet sendes efter sikkerhedsdokumentet
TOKEN_A
, men midt i stafettenTOKEN_A
fjernes fra hvidlisten for sikkerhedsstillelse. En tvist vil nu vende tilbage, da du ikke kan indsende nogen prisanmodninger til OO eller DVM for ikke-hvidlistet sikkerhed. Da vi ikke ønsker at blokere gyldige tvistanmodninger,BridgePool
vil slette det afventende relæ forTOKEN_A
i tilfælde af en tvist. Konsekvenserne af denne designbeslutning er:
1. En stigning i det endelige gebyr vil medføre: Ethvert udestående relæ på dette token kan "annulleres" gennem uenighed om det er rigtigt eller forkert. En annullering gavner ikke nogen af parterne, så den forudsætter eksistensen af ærlige tvister, som er villige til at dræbe den (sjældne) dårlige anmodning, der tilfældigvis eksisterer under en endelig udførelse af gebyrændringer. Dette betyder også, at det er muligt for en sørgende at bruge benzin på at annullere relæer og tvinge dem til at blive videresendt.
2. En afhvidlistning af identifikatoren eller tokenet, som ikke bør ske, medmindre noget går meget galt, vil medføre:
3. En forlænget periode med ubestridelige anmodninger, hvor enhver anmodning kan annulleres, og der ikke eksisterer økonomiske incitamenter til at bestride. Dette virker bedre end alternativet med at blokere tvister fuldstændigt, men det er ganske vist ret slemt, da enhver sørgende kan blokere relæer på ubestemt tid ved at betale gas eller sende dårlige relæer uden straf (bortset fra gasgebyrer).Bemærk: dette er et alternativ til at have OO, der "fryser" parametre såsom det endelige gebyr eller sikkerhedsstillelse hvidliste i nogen tid, men dette ville kræve yderligere opkald til OO, hvilket ville være dyrt for den lykkelige vej.
Relæer kan speedes op via
speedUpRelay()
efter at de passerer livlighed. Selvom vi ikke ser nogen risiko ved dette, åbner det op for muligheden for flashlån + speed ups + afregning efter livlighed, hvilket giver flash-låneren det øjeblikkelige relægebyr "gratis". Det forhindrer vi i dette foreslåede PR.
On
settle
HvisBridgePool
er enWETH
pulje og modtageren er en kontrakt, der ikke erpayable
(kan ikke acceptere ETH), såsettle
vil mislykkes. Vi planlægger at rette op på dette og gå tilbage til afsendelseWETH
, men der er endnu ikke udført noget udestående arbejde på dette.
In
relayDeposit
, kontrollerer vi, atBridgePool
saldoen er større end det beløb, der skal videresendes PLUS forslagsstillerens obligation. Dette er en forældet check og for konservativ, da forslagsstillerbindingen trækkes fra brugeren efter checken. Det behandler vi i dette forslag PR.
Jeg har lige fanget en fejl hvor
chainId
inBridgePool
, inkluderet som en del afDeposit
struct og som funktionsinput til alle de relærelaterede funktioner (dvsrelayDeposit
,speedUpRelay
,settle
) er typeuint8
. Dette er for lille af typen til at håndtere Arbitrum, for eksempel hvis ID er 421611. Vi fangede faktisk denne fejl og rettede den på L2-siden:BridgeDeposit
har sat sitchainId
skriv tiluint256
. Denne PR vil gørechainId
onBridgePool
match typen påBridgeDepositBox
: UMAprotokol/protokol#3463
Tidligere trak tvistfunktionen ikke depositumsbeløbet fra
pendingReserves
(dette er den variabel, der sporer, hvor meget af reservepuljen, der er låst op på grund af relæer, der ikke er afviklet endnu). Resultatet var, at hver tvist ville låse stafetten i puljen på ubestemt tid. Det kan ikke trækkes tilbage af LP'er eller bruges af fremtidige stafetter. Fix er her: UMAprotokol/protokol#3473.
Vi fandt en fejl i
BridgeDepositBox
hvorhasEnoughTimeElapsedToBridge
tjekker ikke om enuint256
værdi er lig med0
som standard: Rettet i PR 3484
Valutakursmetoden (som er tilstandsmodificerende) kaldes mellem tokens, der overføres til, og LP-tokens, der præges i addLiquidity-metoden i bropuljekontrakten. Denne beregning skal flyttes op til toppen af metoden. Dette forårsager meget mærkelige tilstandsværdier. Se PR link. at fikse.
Visningsmetoden
liquidityUtilizationPostRelay
(som kun bruges offchain), melder et forkert brugsnummer. Nævneren på denne linje burde ikke være ligeliquidReserves
, bør det i stedet være en repræsentation af uudnyttede og udnyttede reserver. Fast link..
Opdatering
Ud over fejlrettelserne har vi også gennemgået følgende trinvise ændringer:
- PR3500 fjerner den redundante token-parameter fra
BridgePool
begivenheder. - PR3478 tilføjer DVM's endelige gebyr til listen over lokalt cachelagrede variabler.
- PR3460 tegner sig for en mulig negativ likviditetsudnyttelseskantsag (udover at adressere N04)
- PR3482 fjerner redundante filer og opdaterer OVM-konstanter i overensstemmelse med OVM 2.0-ændringer.
- PR3585 opdaterer
BridgeDepositBox
grænseflade for konsistens og bruger OpenZeppelinSafeERC20
bibliotek.
Mens vi gennemgik rettelserne, identificerede vi et andet problem. Ved bestemmelse af værdien af BridgePool
LP tokens, der er en mellemregning, der uventet kunne negativt overløb, hvilket midlertidigt ville deaktivere tilføjelse og fjernelse af likviditet. Beregningen bør omarrangeres for at tilføje de udnyttede reserver, før de ikke-uddelte gebyrer fratrækkes.
Kritisk sværhedsgrad
[C01] Fanget forslagsstiller-belønning
LongShortPair
kontrakt henter en forslagsstillerbelønning fra hvilken adresse der udløser udløbet, som bruges til at stimulere prisforslag i Optimistic Oracle. Imidlertid LongShortPairCreator
kontrakt også henter og videresender midlerne fra installatørens adresse. Disse yderligere midler overføres ikke til det optimistiske oraklet, og forbliver i stedet fanget inden for LongShortPair
kontrakt.
Overvej at fjerne den duplikerede overførsel.
Update: Fast fra commit 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Høj sværhedsgrad
[H01] Samtidige relæer opbruger reserver
relayDeposit
funktion af BridgePool
kontrakt sikrer, at kontrakten har tilstrækkelige midler at udføre overførslen. Det tager dog ikke højde for de udestående reserver, som sporer midler, der er øremærket til aktive stafetter. Derfor kan flere samtidige relæer stole på de samme midler, og de kan ikke alle afregnes med det samme. Især med en konstant strøm af overførsler kan øjeblikkelige relæreturer blive forsinket på ubestemt tid.
Overvej at forhindre relæer, der ville få de udestående reserver til at overstige de likvide reserver.
Update: Fast fra commit 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Brydningsparametergrænserne stemmer ikke overens
deposit
funktion af BridgeDepositBox
kontrakt, implementeret på lag 2-kæder, bruges til at bygge bro mellem L2 og L1. Især er relæerne tilskyndet til relæ transaktionsoplysningerne på den tilknyttede L1 BridgePool
. Pengekassen bruger dog inklusive grænser at begrænse stafetafgifterne, mens bropuljen benytter eksklusive grænser. Det betyder, at nogle indskud (med 25 % relægebyrer) ikke kan videresendes, og midlerne vil være utilgængelige på begge lag.
Overvej at synkronisere valideringerne på begge lag for at sikre, at alle gyldige indbetalinger kan videresendes.
Update: Rettet i commit 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Dette blev oprindeligt klassificeret som kritisk sværhedsgrad, men blev nedgraderet, da UMA-teamet påpegede, at midlerne ikke ville være strengt fanget og kunne frigives, hvis DVM-vælgerne gik med til at acceptere en ændret relæbeskrivelse for berørte indskud.
Medium sværhedsgrad
[M01] Tilbagekald til forkert adresse
SkinnyOptimisticOracle
aktiverer tilbagekaldsfunktioner på prisanmoderen, hvis de findes, så rekvirenten kan reagere på væsentlige tilstandsændringer. Tilbagekaldet er dog fejlagtigt påberåbt prisstilleren i stedet for prisanmoderen i og proposePriceFor
funktion. Det betyder, at prisanmoderen ikke er i stand til at svare på prisforslag.
Heldigvis bruges denne funktion ikke i den nuværende kodebase. Overvej ikke desto mindre at påberåbe sig priceProposed
tilbagekald på rekvirenten.
Update: Rettet ved commit 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Defekt tilføjelsesfunktion
appendKeyValueBytes32
funktion skal kombinere sine input til en formateret bytes
array. Imidlertid currentAncillaryData
is forkert kasseret.
Siden de supplerende data påvirker orakelopløsningsprocessen, kan en forkert værdi underminere orakelresultaterne. Heldigvis er der kun et opkald til appendKeyValueBytes32
i kodebasen, og den bruger en tom currentAncillaryData
buffer, så fejlen påvirker ikke denne sag.
Overvej at opdatere appendKeyValueBytes32
fungere, så currentAncillaryData
er inkluderet i det returnerede bytes-array.
Update: Rettet i commit 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Ufuldstændig validering af hjælpedata
LongShortPair
konstruktør bekræfter, at customAncillaryData
er lille nok. Det tager dog ikke højde for tidligt udløbsfelt. Det betyder det optimistiske oraklet kan uventet afvise prisanmodninger om tidlig udløb, hvilket ville deaktivere denne funktion.
Overvej at opdatere valideringen for at tage højde for det ekstra felt.
Update: Fast fra commit 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Mishandlet nul tidsstempel
I LongShortPair
kontrakt, er et nul tidligt udløbstidsstempel bruges som flag for at indikere, at ingen har udløst den tidlige udløbsmekanisme. Det er dog muligt at udløse den mekanisme med nul tidsstempel. I dette scenarie vil det optimistiske oraklet blive påberåbt, men den beskyttelse mod efterfølgende prisanmodninger vil ikke være effektiv. Heldigvis en gang afregningsprisen vælges, vil det ikke blive tilsidesat, så dette vil ikke føre til inkonsekvente forlig. Ikke desto mindre kunne en efterfølgende prisanmodning evt ændre det registrerede tidsstempel for tidlig udløb, selvom nultidsstemplet bruges til at bestemme afregningsprisen. Det kunne det også udsende en vildledende begivenhed.
Overvej at forhindre tidlig udløb ved at bruge nul-tidsstemplet.
Update: Fast fra commit 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Mulig nulbinding
requestPrice
funktion af SkinnyOptimisticOracle
kontrakt bruger det endelige gebyr som obligationen hvis obligationen ikke er specificeret. Imidlertid requestAndProposePriceFor
funktion kan bruge en nulbinding, hvilket modsiger dens @notice
, @param
kommentarer. En nulbinding svækker incitamentet mod ugyldige forslag eller ugyldige tvister.
Heldigvis ring kun til denne funktion i kodebasen sætter en forslagsstillerbinding. Overvej ikke desto mindre at bruge det endelige gebyr, hvis obligationen ikke er specificeret.
Update: Fast fra commit daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Unødvendige administratorrettigheder
BridgePool
kontrakt arver fra ExpandedERC20
så den kan udstede LP-tokens til likviditetsudbydere. Dette arver funktionaliteten fra OpenZeppelin's ERC20
kontrakt og også giver administratorrettigheder til kontraktudvikleren, som giver dem mulighed for at præge og brænde LP-poletter. Denne beføjelse er dog ikke påkrævet, og hvis den udnyttes, kan den uretfærdigt straffe likviditetsudbydere.
Overvej at ændre BridgePool
at arve direkte fra ERC20
i stedet for ExpandedERC20
.
Update: Rettet i commit 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Lav sværhedsgrad
[L01] Kan ikke afregne ved udløb
settle
funktion af LongShortPair
kontrakt overvejer afregningsbetingelser når det aktuelle tidspunkt er strengt før eller efter udløbstidsstemplet. Den vender dog forkert tilbage, når det aktuelle tidspunkt matcher udløbstidsstemplet.
Overvej at bruge en inklusiv bundet til at matche postExpiration
modifier.
Update: Rettet i commit f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Manglende fejlmeddelelse i kræve-erklæringen
Der er en kraverklæring i BridgePool
kontrakt uden fejlmeddelelse.
Overvej at inkludere specifikke og informative fejlmeddelelser i alle krævede erklæringer.
Update: Fast fra commit 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Manglende docstrings
Der er nogle tilfælde i hele kodebasen, hvor Ethereum Natural Specifikation mangler eller er ufuldstændig. Eksempler omfatter:
Overvej grundigt at dokumentere alle funktioner (og deres parametre), der er en del af kontrakternes offentlige API.
Update: De fremhævede kommentarer blev rettet i commit e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Vi validerede ikke NatSpecs fuldstændighed i resten af kodebasen.
Bemærkninger og yderligere oplysninger
[N01] Opkaldsreturværdi ikke kontrolleret
I deposit
funktion af L2 BridgeDepositBox
kontrakt er der et lavt niveau opkald til l2Token
når l1Token
is l1Weth
. Dette opkald på lavt niveau er til deposit()
funktion, som hører til Weth interface. Hvis dette l2Token
opfører sig præcis som WETH det aldrig burde fejle. Men i tilfældet l2Token
opfører sig anderledes og fejler, ville der ikke være nogen tilbagevenden, da succesflaget for dette lavniveau-opkald aldrig kontrolleres.
Overvej at kontrollere og reagere korrekt på returværdierne for alle opkald på lavt niveau.
[N02] Mangel på indekserede parametre i hændelser
Mange af hændelserne defineret i denne kodebase har parametre, der bør indekseres:
Overvej indeksering af hændelsesparametre for at undgå at hindre opgaven med off-chain-tjenester, der søger og filtrerer efter specifikke begivenheder.
Update: Delvist fast i commit d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. Det chainId
parameter af WhitelistToken
blev ikke opdateret.
[N03] Implicit støbeinkonsistens
LongShortPair
kontrakt generelt behandler tidsstempler som uint64
værdier, som implicit er støbt til uint256
værdier hvornår videregivet til det optimistiske orakel. Men den requestTimestamp
parameter af og _requestOraclePrice
funktion er for tidligt støbt til en uint256
. Dette har ingen funktionelle konsekvenser.
Ikke desto mindre, af hensyn til sammenhængen, bør du overveje at bruge en uint64
for denne parameter og tillader den at blive implicit castet til en uint256
når den blev overført til det optimistiske oraklet.
Update: Rettet i commit 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Tidsstemplet er nu eksplicit afgivet.
[N04] Forkert type
sendMessage
funktion af iOptimism_CrossDomainMessenger
grænseflade bruge til uint256
gasgrænse mens optimismen er OVM_CrossDomainEnabled
bruge til uint32
gasgrænse.
For at opnå konsistens og forudsigelighed bør du overveje at opdatere iOptimisim_CrossDomainMessenger
sendMessage
funktion for at bruge en uint32
gasgrænse.
Update: Fast fra commit 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Manglende validering
Alle funktioner i BridgeAdmin
det opkald _relayMessage
antag, at transaktionsværdien matcher l1CallValue
parameter, men dette håndhæves ikke.
Overvej at sikre det rigtige msg.value
er indstillet.
Update: Fast fra commit f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Læsbarhed
_getDepositHash
funktion af BridgePool
kontrakt udruller den depositData
struct at interstice l1Token
som argument i sammensætningen af keccak256
med abi
indkodning. Dette gør operationen unødvendigt omfattende og kan føre til fejl, når den genimplementeres på andre lag.
Overvej at forenkle argumenterne til blot at være det ordnede par depositData
, l1Token
.
Update: Fast fra commit 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Reentrant funktion
requestAndProposePriceFor
funktion af SkinnyOptimisticOracle
kontrakt foretager et opkald til en ikke-betroet msg.sender
men er ikke bevogtet af en nonReentrant
modifikator. Selvom dette i dette tilfælde ikke ser ud til at være et sikkerhedsproblem, kan dette introducere uventet adfærd.
Overvej at tilføje nonReentrant
modifikator til alle funktioner, der foretager opkald til kontrakter, der ikke er tillid til.
Update: Rettet i commit b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
ikke logget
relayMessage
funktion af Arbitrum_Messenger
kontrakten udsender ikke en relevant begivenhed efter at have udført en følsom handling. Det relayMessage
funktionskald som en underrutine sentTxToL2NoAliasing
som selv returnerer uint256
værdi seqNum
, men denne returværdi er ikke logget i relayMessage
funktion.
Overvej at udsende hændelser, efter at følsomme ændringer har fundet sted, for at lette sporing og underrette kunder uden for kæden efter kontraktens aktivitet.
Update: Fast fra commit 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Trykfejl
Kodebasen indeholder følgende tastefejl:
Overvej at rette disse tastefejl for at forbedre kodelæsbarheden.
Update: Fast fra commit 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Udokumenteret ERC20-godkendelseskrav
requestEarlyExpiration
, expire
funktioner af LongShortPair
kontrakt hver antager, at den, der ringer, har givet kontrakten en godtgørelse til trække forslagsstillerens belønning.
Overvej for forudsigelighedens skyld at dokumentere dette krav i funktionskommentarerne.
Update: Rettet i commit da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Ubrugt modifikator
I BridgePool
kontrakt, den onlyFromOptimisticOracle
modifier er defineret, men bruges aldrig i kodebasen og bør derfor fjernes.
Update: Rettet i commit 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
konklusioner
Der blev fundet 2 kritiske og 1 højsværhedsproblemer. Nogle ændringer blev foreslået for at følge bedste praksis og reducere den potentielle angrebsoverflade.
- &
- 7
- Konto
- Handling
- aktiv
- Ad
- Yderligere
- adresse
- admin
- Fordel
- Alle
- tillade
- api
- argumenter
- revision
- tilgængelighed
- være
- BEDSTE
- bedste praksis
- blockchain
- Boks
- BRIDGE
- Bug
- bugs
- ringe
- tilfælde
- fanget
- Årsag
- udfordre
- lave om
- kontrol
- kode
- kommentarer
- Konfiguration
- indeholder
- kontrakt
- kontrakter
- kunne
- Nuværende
- data
- decentral
- forsinkelse
- Design
- bestemmelse
- DID
- Bestride
- Er ikke
- Tidligt
- Økonomisk
- Edge
- Effektiv
- ERC20
- ETH
- ethereum
- Ethereum blockchain
- begivenhed
- begivenheder
- eksempel
- udveksling
- forventet
- erfaring
- Feature
- Gebyrer
- finansielle
- Fornavn
- Fix
- Blink
- følger
- fundet
- funktion
- fond
- fonde
- fremtiden
- GAS
- gas gebyrer
- Give
- regeringsførelse
- Gem
- have
- link.
- Høj
- Fremhævet
- holdere
- Hvordan
- HTTPS
- incitament
- medtaget
- Herunder
- Forøg
- oplysninger
- interesse
- grænseflade
- spørgsmål
- IT
- kendt
- føre
- Bibliotek
- Flydende
- Likviditet
- udbydere af likviditet
- Liste
- Lån
- lokalt
- låst
- LP
- lp'er
- Marked
- Match
- mest
- åbent
- oracle
- Andet
- perron
- pool
- Pools
- magt
- forebyggelse
- pris
- behandle
- forslag
- give
- giver
- offentlige
- årsager
- reducere
- Rapporter
- REST
- Resultater
- afkast
- gennemgå
- Risiko
- sikkerhed
- Tjenester
- sæt
- afregning
- Kort
- signifikant
- lignende
- lille
- So
- soliditet
- Nogen
- noget
- hastighed
- tilbringe
- Tilstand
- Statement
- opbevaring
- succes
- Understøttet
- overflade
- systemet
- prøve
- Gennem
- hele
- tid
- token
- Tokens
- top
- Sporing
- transaktion
- Transaktioner
- Stol
- Opdatering
- opdateringer
- UPS
- brugere
- værdi
- Specifikation
- whitelist
- WHO
- inden for
- uden
- Arbejde
- værd
- nul