December 1, 2021
UMA är en plattform som tillåter användare att ingå förtroendeminimerade finansiella kontrakt på Ethereum blockchain. Vi har tidigare granskat det decentraliserade oraklet, en särskild finansiell kontraktsmall, några ad hoc pull-förfrågningar, mallen Perpetual Multiparty och olika inkrementella pull-förfrågningar över ett längre engagemang. I den här granskningen granskade vi en ny mekanism för att snabbt skicka tokens från en lager 2-kedja till Ethereums huvudnät, och relaterade ändringar i Optimistic Oracle. Granskningen genomfördes av 2 revisorer under 3 veckor.
Omfattning
Det granskade åtagandet är f24ad501c8e813cf685f72217e7f13c8f3c366df
och omfattningen inkluderar följande kontrakt:
- kontrakt/försäkrad-brygga/* (exklusive testkontrakt)
- kontrakt-ovm/försäkrad-brygga/implementering/*
- contracts/common/implementation/AncillaryData.sol
- kontrakt/oracle/implementation/SkinnyOptimisticOracle.sol
Vi har också granskat ändringarna av solidity-filer i Dra förfrågan 3445.
Alla externa kod- och kontraktsberoenden antogs fungera som dokumenterat.
System översikt
De understödda lager 2-kedjorna (L2), Optimism och Arbitrum, tillhandahåller en mekanism för att överföra pengar till Ethereums huvudnät (L1). Av säkerhetsskäl finns det dock en betydande fördröjning innan dessa överföringar slutförs. För att åtgärda detta kan innehavare av L2-token sätta in pengar i ett UMA-kontrakt, insättningsboxen, i vetskap om att tokens så småningom kommer att överföras (som en batch) till ett L1 UMA-kontrakt, Bridge Pool. Det finns en separat bropool för varje token som ska överföras.
Efter en L2-insättning kan vem som helst vidarebefordra detaljerna till L1 Bridge Pool, som väntar en kort period om någon vill bestrida den vidarebefordrade informationen. Alla tvister hanteras av Skinny Optimistic Oracle (beskrivs nedan). Innan de accepterar reläet måste likviditetsleverantörer förfinansiera Bridge Pool-kontraktet i utbyte mot LP-tokens. Obestridda reläer antas vara giltiga, och Bropoolen genomför överföringen med sina egna reserver, där en bråkdel av överföringen avleds till reläet och en bråkdel behålls som likviditetsavgifter. Medlen kommer så småningom att fyllas på när L2-insättningen är klar, och likviditetsavgifterna tilldelas LP-tokeninnehavarna.
Bridge Pool tillåter också vem som helst att individuellt finansiera en överföring (utan Bridge Pool-reserverna) innan tvistperioden löper ut, i utbyte mot en bråkdel av överföringsbeloppet. Eftersom reläet fortfarande kan bestridas skulle dessa medel gå förlorade om reläet bedömdes vara felaktigt. Det förväntas att i de flesta fall kommer denna mekanism att tillåta användare att uppleva omedelbara L2-till-L1-tokenöverföringar.
Skinny Optimistic Oracle är konceptuellt mycket likt det befintliga Optimistic Oracle. Det ger en incitamentmekanism för användare att helt enkelt hävda resultatet av en orakelförfrågan, som antas vara korrekt om den inte bestrids. Tvister hänvisas till den långsammare DVM-mekanism som beskrivs i våra tidigare revisionsrapporter. Den största skillnaden är att den nya versionen kräver att användare tillhandahåller all relevant information när funktionsanrop utförs, så värdena behöver inte sparas eller hämtas från lagringen. Det tar också bort möjligheten för begäranden att ändra konfigurationsparametrar i aktiva förfrågningar.
Vi har tidigare granskat Long-Short-Pair-kontraktet, som ger en generisk mekanism för att skapa olika finansiella instrument. Dessa kontrakt kan lösas när deras utgångstid är nådd och avvecklingspriset är känt. De förändringar som införts av Pull Request 3445 introducerar möjligheten att lösa kontrakten i förtid om avvecklingspriset är känt före utgångstiden.
Privilegierade roller
L2-deponeringsboxarna har flera konfigurationsparametrar, inklusive de tokens som stöds och den maximala hastigheten för att skicka batchade tokens över bryggan till L1. De måste också konfigureras för att säkerställa överensstämmelse mellan L1-tokenkontraktet, L2-tokenkontraktet och motsvarande Bridge Pool. Dessa parametrar ställs in av ett administratörskontrakt på L1, som också parametrerar tvistlösningsprocessen för bryggpoolerna. Kontraktet förväntas kontrolleras av UMA-styrningsmekanismen, så användare måste lita på denna process för att hantera systemet förnuftigt och rättvist.
Ekosystemberoenden
Alla granskade komponenter använder tidsbaserad logik, vilket innebär att de är beroende av Ethereums tillgänglighet. I synnerhet om tvisttransaktioner försenas avsevärt kan ogiltiga reläer eller prisförslag felaktigt bekräftas.
Dessutom antar tokenbryggan implicit att alla medel som skickas till L2-deponeringsboxar så småningom kommer att överföras till motsvarande L1-bryggpool. Detta förlitar sig på att Optimism- och Arbitrumbroarna och deras tvistlösningsmekanismer fungerar korrekt och fortsatt.
Slutligen tilldelas tokens som skickas till L2-depån till bryggpoolen i L1, inte den avsedda mottagaren. För att få ut pengarna från poolen måste innehavare av L1-token först matcha dem med ytterligare tokens. Därför är mekanismen beroende av en tillräckligt djup marknad av L1-tokens för att säkerställa att det alltid finns likviditet.
Kundrapporterade problem
Under granskningen identifierade UMA-teamet oberoende ett antal problem och beteenden som var värda att lyfta fram:
Om parametrarna för Optimistic Oracle eller Bridge Admin ändras under ett reläs utmaningsperiod, raderas reläet genom att bestrida reläet utan någon ytterligare regress för vare sig förslagsställaren eller disputanten. Föreställ dig till exempel att reläet skickas för säkerhetstoken
TOKEN_A
, men mitt i stafettenTOKEN_A
tas bort från säkerhetslistan. En tvist kommer nu att återgå eftersom du inte kan skicka in några prisförfrågningar till OO eller DVM för ovitlistade säkerheter. Eftersom vi inte vill blockera giltiga tvistförfrågningar,BridgePool
kommer att ta bort det väntande reläet förTOKEN_A
vid tvist. Konsekvenserna av detta designbeslut är:
1. En höjning av den slutliga avgiften kommer att leda till att: Alla utestående reläer på denna token kan "avbrytas" genom tvist om rätt eller fel. En avbokning gynnar inte någon av parterna, så det förutsätter att det finns ärliga disputter som är villiga att döda den (sällsynta) dåliga begäran som råkar existera under en slutgiltig avgiftsändring. Detta betyder också att det är möjligt för en sörjande att spendera gas för att avbryta reläer och tvinga dem att återförmedlas.
2. En avvitlistning av identifieraren eller token, som inte bör ske om inte något går väldigt fel skulle orsaka:
3. En förlängd period av obestridliga förfrågningar där varje begäran kan avbrytas och det inte finns några ekonomiska incitament för att bestrida. Detta verkar bättre än alternativet att blockera tvister helt, men det är visserligen ganska dåligt, eftersom alla sörjande kan blockera reläer på obestämd tid genom att betala gas eller skicka dåliga reläer utan bestraffning (annat än gasavgifter).Notera: detta är ett alternativ till att ha OO som "fryser" parametrar som den slutliga avgiften eller vitlistan för säkerheter under en tid, men detta skulle kräva ytterligare samtal till OO, vilket skulle bli kostsamt för den lyckliga vägen.
Reläerna kan snabbas upp via
speedUpRelay()
efter att de passerat livlighet. Även om vi inte ser någon risk med detta, öppnar det upp möjligheten för flashlån + snabba upp + avveckling efter livlighet, vilket ger blixtlåntagaren den omedelbara reläavgiften "gratis". Vi förhindrar detta i detta förslag PR.
On
settle
, omBridgePool
är enWETH
pool och mottagaren är ett kontrakt som inte är detpayable
(kan inte acceptera ETH), alltsåsettle
kommer misslyckas. Vi planerar att fixa detta och fallback på att skickaWETH
, men det finns inget enastående arbete gjort ännu med detta.
In
relayDeposit
, kontrollerar vi attBridgePool
saldot är större än beloppet som ska vidarebefordras PLUS förslagsställarens bindning. Detta är en föråldrad kontroll och för konservativ eftersom förslagsställarens bindning dras från användaren efter kontrollen. Vi tar upp detta i detta förslag PR.
Jag fångade precis en bugg där
chainId
inBridgePool
, ingår som en del avDeposit
struct och som en funktionsingång till alla relärelaterade funktioner (dvsrelayDeposit
,speedUpRelay
,settle
) är typuint8
. Detta är en för liten typ för att hantera till exempel Arbitrum vars ID är 421611. Vi fångade faktiskt den här buggen och fixade den på L2-sidan:BridgeDeposit
har satt sinchainId
skriv tilluint256
. Denna PR kommer att görachainId
onBridgePool
matcha typen påBridgeDepositBox
: UMAprotokoll/protokoll#3463
Tidigare har tvistfunktionen inte dragit av insättningsbeloppet från
pendingReserves
(detta är variabeln som spårar hur mycket av reservpoolen som är låst på grund av reläer som inte har avgjort ännu). Resultatet blev att varje tvist på obestämd tid skulle låsa reläbeloppet i poolen. Den kan inte dras tillbaka av LP-skivor eller användas av framtida reläer. Fix är här: UMAprotokoll/protokoll#3473.
Vi hittade en bugg i
BridgeDepositBox
varhasEnoughTimeElapsedToBridge
kontrollerar inte om enuint256
värdet är lika med0
som standard: Fast i PR 3484
Växelkursmetoden (som är tillståndsmodifierande) anropas mellan tokens som överförs in och LP-tokens präglas i addLiquidity-metoden i bryggpoolkontraktet. Denna beräkning måste flyttas upp till toppen av metoden. Detta orsakar mycket konstiga tillståndsvärden. Se PR här. att fixa.
Visningsmetoden
liquidityUtilizationPostRelay
(som endast används offchain), rapporterar ett felaktigt användningsnummer. Nämnaren på denna rad borde inte vara baraliquidReserves
, bör det istället vara en representation av outnyttjade och utnyttjade reserver. Fast här..
Uppdatering
Utöver problemkorrigeringarna har vi också granskat följande inkrementella ändringar:
- PR3500 tar bort den redundanta token-parametern från
BridgePool
evenemang. - PR3478 lägger till den slutliga DVM-avgiften till listan över lokalt cachade variabler.
- PR3460 står för ett eventuellt negativt fall för likviditetsutnyttjande (utöver att ta itu med N04)
- PR3482 tar bort redundanta filer och uppdaterar OVM-konstanter i enlighet med OVM 2.0-ändringar.
- PR3585 uppdaterar
BridgeDepositBox
gränssnitt för konsekvens och använder OpenZeppelinSafeERC20
bibliotek.
När vi granskade korrigeringarna upptäckte vi ett annat problem. Vid bestämning av värdet på BridgePool
LP-polletter, det finns en mellanberäkning som oväntat skulle kunna negativt spilla, vilket tillfälligt skulle inaktivera att lägga till och ta bort likviditet. Beräkningen bör ändras för att lägga till de utnyttjade reserverna innan de ofördelade avgifterna dras av.
Kritisk svårighetsgrad
[C01] Belöning för instängd förslagsställare
Smakämnen LongShortPair
kontrakt hämtar en förslagsställande belöning från vilken adress som helst som utlöser utgången, vilket används för att stimulera prisförslag i Optimistic Oracle. Men den LongShortPairCreator
kontrakt också hämtar och vidarebefordrar medlen från driftställarens adress. Dessa ytterligare medel överförs inte till det optimistiska oraklet, utan förblir istället instängda inom LongShortPair
avtal.
Överväg att ta bort dubblettöverföringen.
Uppdatering: Fast från och med commit 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Hög svårighetsgrad
[H01] Samtidiga reläer tömmer reserverna
Smakämnen relayDeposit
funktion av BridgePool
kontrakt säkerställer att avtalet har tillräckliga medel för att utföra överföringen. Det tar dock inte hänsyn till de utestående reserverna, som spårar medel som är öronmärkta för aktiva reläer. Därför kan flera samtidiga reläer förlita sig på samma medel, och de kanske inte alla kan lösas omedelbart. I synnerhet, med en stadig ström av överföringar, kan omedelbara reläreturer försenas på obestämd tid.
Överväg att förhindra reläer som skulle få de utestående reserverna att överstiga likvida reserver.
Uppdatering: Fast från och med commit 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Överbryggningsparametergränserna matchar inte
Smakämnen deposit
fungera av BridgeDepositBox
kontrakt, utplacerat på lager 2-kedjor, används för att överbrygga medel mellan L2 och L1. I synnerhet är reläer incitament till relä transaktionsdetaljerna på den associerade L1 BridgePool
. Däremot använder bankot inkluderande gränser att begränsa stafettavgifterna, medan bropoolen använder exklusiva gränser. Detta innebär att vissa insättningar (med 25 % reläavgifter) inte kan vidarebefordras, och medlen kommer att vara otillgängliga på båda lagren.
Överväg att synkronisera valideringarna på båda lagren för att säkerställa att alla giltiga insättningar kan vidarebefordras.
Uppdatering: Fixat i commit 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Detta klassificerades ursprungligen som kritisk svårighetsgrad men nedgraderades när UMA-teamet påpekade att medlen inte skulle vara strikt fångade och kunde frigöras om DVM-väljarna gick med på att acceptera en modifierad reläbeskrivning för påverkade insättningar.
Medel svårighetsgrad
[M01] Återuppringningar till fel adress
Smakämnen SkinnyOptimisticOracle
anropar återuppringningsfunktioner på prisbeställaren, om de finns, så att begäranden kan svara på betydande tillståndsändringar. Återuppringningen åberopas dock felaktigt på prisförslagsställaren istället för prisförfrågaren i d proposePriceFor
fungera. Detta innebär att prissökanden inte kan svara på prisförslag.
Lyckligtvis används inte denna funktion i den nuvarande kodbasen. Överväg ändå att åberopa priceProposed
återuppringning på begäranden.
Uppdatering: Fast vid commit 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Felaktig tilläggsfunktion
Smakämnen appendKeyValueBytes32
fungera bör kombinera sina indata till en formaterad bytes
array. Men den currentAncillaryData
is felaktigt kasserad.
Eftersom de kompletterande uppgifterna påverkar orakelupplösningsprocessen, kan ett felaktigt värde undergräva oraklets resultat. Lyckligtvis finns det bara ett samtal till appendKeyValueBytes32
i kodbasen, och den använder en tom currentAncillaryData
buffert, så felet påverkar inte det här fallet.
Överväg att uppdatera appendKeyValueBytes32
fungerar så att currentAncillaryData
ingår i den returnerade byte-matrisen.
Uppdatering: Fixat i commit 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Ofullständig validering av tilläggsdata
Smakämnen LongShortPair
konstruktör bekräftar att customAncillaryData
är tillräckligt liten. Det tar dock inte hänsyn till tidigt utgångsfält. Det betyder det optimistiska oraklet kan oväntat avvisa prisförfrågningar om tidiga utgångsdatum, vilket skulle inaktivera den här funktionen.
Överväg att uppdatera valideringen för att ta hänsyn till det ytterligare fältet.
Uppdatering: Fast från och med commit 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Felhantering noll tidsstämpel
I LongShortPair
kontrakt, är en noll tidig utgångstidsstämpel används som flagga för att indikera att ingen har utlöst den tidiga utgångsmekanismen. Det är dock möjligt att utlösa den mekanismen med noll tidsstämpel. I detta scenario kommer det optimistiska oraklet att anropas men skydd mot efterföljande prisförfrågningar kommer inte att vara effektiva. Lyckligtvis en gång avräkningspriset väljs, kommer den inte att åsidosättas, så detta leder inte till inkonsekventa uppgörelser. Ändå kan en efterföljande prisförfrågan ändra den inspelade tidiga utgångstidsstämpeln, även om nolltidsstämpeln används för att fastställa avräkningspriset. Det kunde det också avge en vilseledande händelse.
Överväg att förhindra tidig utgång med nolltidsstämpeln.
Uppdatering: Fast från och med commit 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Möjlig nollbindning
Smakämnen requestPrice
funktion av SkinnyOptimisticOracle
kontrakt använder slutavgiften som obligationen om obligationen inte anges. Men den requestAndProposePriceFor
fungera kan använda en nollbindning, vilket motsäger dess @notice
och @param
kommentarer. En nollobligation försvagar incitamentet mot ogiltiga förslag eller tvister.
Lyckligtvis, den ring bara till denna funktion i kodbasen sätter en proposer bond. Överväg ändå att använda den slutliga avgiften om obligationen inte är specificerad.
Uppdatering: Fast från och med commit daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Onödiga administratörsbehörigheter
Smakämnen BridgePool
kontrakt ärver från ExpandedERC20
så att den kan ge ut LP-tokens till likviditetsleverantörer. Detta ärver funktionaliteten hos OpenZeppelin's ERC20
kontrakt och även ger administratörsbehörigheter till kontraktsutvecklaren, vilket gör att de kan prägla och bränna LP-polletter. Denna befogenhet krävs dock inte och kan, om den utnyttjas, på ett orättvist sätt straffa likviditetsleverantörer.
Överväg att ändra BridgePool
att ärva direkt från ERC20
istället för ExpandedERC20
.
Uppdatering: Fixat i commit 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Låg svårighetsgrad
[L01] Kan inte lösas vid utgången
Smakämnen settle
funktion av LongShortPair
kontrakt överväger avvecklingsvillkor när den aktuella tiden är strikt före eller efter utgångens tidsstämpel. Den återgår dock felaktigt när den aktuella tiden matchar utgångstidens stämpel.
Överväg att använda en inkluderande bunden för att matcha postExpiration
modifierare.
Uppdatering: Fixat i commit f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Felmeddelande saknas i kravsatsen
Det finns ett krav uttalande i BridgePool
kontrakt utan felmeddelande.
Överväg att inkludera specifika och informativa felmeddelanden i alla kravsatser.
Uppdatering: Fast från och med commit 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Saknade docstrings
Det finns några fall i hela kodbasen där Ethereum Natural Specifikation saknas eller är ofullständig. Exempel inkluderar:
Överväg att noggrant dokumentera alla funktioner (och deras parametrar) som ingår i kontraktens publika API.
Uppdatering: De markerade kommentarerna fixades i commit e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Vi validerade inte NatSpecs fullständighet i resten av kodbasen.
Anteckningar och ytterligare information
[N01] Samtalsreturvärde ej markerat
I deposit
fungera av L2 BridgeDepositBox
kontrakt det finns ett samtal på låg nivå till l2Token
när l1Token
is l1Weth
. Detta lågnivåsamtal är till deposit()
funktion, som hör till Weth gränssnitt. Om det här l2Token
beter sig precis som WETH det bör aldrig misslyckas. Men i fallet l2Token
beter sig annorlunda och misslyckas, skulle det inte finnas någon återgång eftersom framgångsflaggan för detta lågnivåanrop aldrig kontrolleras.
Överväg att kontrollera och reagera på rätt sätt på returvärdena för alla samtal på låg nivå.
[N02] Brist på indexerade parametrar i händelser
Många av händelserna som definieras i denna kodbas har parametrar som bör indexeras:
Tänk indexeringshändelseparametrar för att undvika att hindra uppgiften med tjänster utanför kedjan att söka och filtrera efter specifika händelser.
Uppdatering: Delvis fixerad i commit d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535. De chainId
parameter för WhitelistToken
uppdaterades inte.
[N03] Implicit gjutningsinkonsekvens
Smakämnen LongShortPair
kontrakt i allmänhet behandlar tidsstämplar som uint64
värden, som är implicit gjutna till uint256
värden när över till det optimistiska oraklet. Men requestTimestamp
parameter för d _requestOraclePrice
fungera är för tidigt gjuten till en uint256
. Detta har inga funktionella konsekvenser.
Icke desto mindre, för konsekvensens intresse, överväg att använda en uint64
för denna parameter och tillåta den att implicit gjutas till en uint256
när den överfördes till det optimistiska oraklet.
Uppdatering: Fixat i commit 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Tidsstämpeln är nu uttryckligen gjuten.
[N04] Fel typ
Smakämnen sendMessage
funktion av iOptimism_CrossDomainMessenger
gränssnitt använder a uint256
gasgräns medan optimismen är OVM_CrossDomainEnabled
använder a uint32
gasgräns.
För konsekvens och förutsägbarhet, överväg att uppdatera iOptimisim_CrossDomainMessenger
sendMessage
funktion för att använda en uint32
gasgräns.
Uppdatering: Fast från och med commit 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Brist på validering
Alla funktioner i BridgeAdmin
det samtalet _relayMessage
anta att transaktionsvärdet matchar l1CallValue
parametern, men detta tillämpas inte.
Överväg att säkerställa rätt msg.value
är inställd.
Uppdatering: Fast från och med commit f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Läsbarhet
Smakämnen _getDepositHash
fungera av BridgePool
kontrakt rullar upp depositData
struct för att interstice the l1Token
som argument i sammansättningen av keccak256
med abi
kodning. Detta gör operationen onödigt omfattande och kan leda till buggar när den implementeras på nytt på andra lager.
Överväg att förenkla argumenten till att helt enkelt vara det ordnade paret depositData
och l1Token
.
Uppdatering: Fast från och med commit 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Återkommande funktion
Smakämnen requestAndProposePriceFor
fungera av SkinnyOptimisticOracle
kontrakt ringer till en obetrodd msg.sender
men bevakas inte av en nonReentrant
modifierare. Även om detta i det här fallet inte verkar vara ett säkerhetsproblem, kan detta leda till oväntat beteende.
Överväg att lägga till nonReentrant
modifierare för alla funktioner som gör anrop till eventuellt opålitliga kontrakt.
Uppdatering: Fixat i commit b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
inte loggat
Smakämnen relayMessage
fungera av Arbitrum_Messenger
kontrakt inte avger en relevant händelse efter att ha utfört en känslig åtgärd. De relayMessage
funktionsanrop som en subrutin sentTxToL2NoAliasing
som själv returnerar uint256
värde seqNum
, men detta returvärde är inte inloggat i relayMessage
funktion.
Överväg att avge händelser efter att känsliga förändringar har ägt rum, för att underlätta spårning och meddela kunder utanför kedjan efter kontraktets aktivitet.
Uppdatering: Fast från och med commit 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Typografiska fel
Kodbasen innehåller följande stavfel:
Överväg att korrigera dessa stavfel för att förbättra kodens läsbarhet.
Uppdatering: Fast från och med commit 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Odokumenterat ERC20-godkännandekrav
Smakämnen requestEarlyExpiration
och expire
funktioner av LongShortPair
kontrakt var och en förutsätter att den som ringer har beviljat kontraktet en ersättning till dra förslagsställarens belöning.
För förutsägbarhetens skull, överväg att dokumentera detta krav i funktionskommentarerna.
Uppdatering: Fixat i commit da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Oanvänd modifierare
I BridgePool
kontraktet onlyFromOptimisticOracle
modifierare är definierad men används aldrig i kodbasen och bör därför tas bort.
Uppdatering: Fixat i commit 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
Slutsatser
2 kritiska och 1 allvarliga problem hittades. Vissa ändringar föreslogs för att följa bästa praxis och minska potentiell attackyta.
- &
- 7
- Konto
- Handling
- aktiv
- Ad
- Annat
- adress
- administration
- Fördel
- Alla
- tillåta
- api
- argument
- revision
- tillgänglighet
- Där vi får lov att vara utan att konstant prestera,
- BÄST
- bästa praxis
- blockchain
- Box
- BRO
- Bug
- fel
- Ring
- fall
- fångas
- Orsak
- utmanar
- byta
- kontroll
- koda
- kommentarer
- konfiguration
- innehåller
- kontrakt
- kontrakt
- kunde
- Aktuella
- datum
- decentraliserad
- fördröja
- Designa
- bestämmande
- DID
- Tvist
- inte
- Tidig
- Ekonomisk
- kant
- Effektiv
- ERC20
- ETH
- ethereum
- Ethereum blockchain
- händelse
- händelser
- exempel
- utbyta
- förväntat
- erfarenhet
- Leverans
- avgifter
- finansiella
- Förnamn
- Fast
- Blixt
- följer
- hittade
- fungera
- fond
- fonder
- framtida
- GAS
- gasavgifter
- Ge
- styrning
- lyckligt
- har
- här.
- Hög
- Markerad
- hållare
- Hur ser din drömresa ut
- HTTPS
- incitament
- ingår
- Inklusive
- Öka
- informationen
- intresse
- Gränssnitt
- problem
- IT
- känd
- leda
- Bibliotek
- Flytande
- Likviditet
- likviditetsleverantörer
- Lista
- Lån
- lokalt
- låst
- LP
- LP
- marknad
- Match
- mest
- öppet
- orakel
- Övriga
- plattform
- poolen
- Pools
- kraft
- förebyggande
- pris
- process
- förslag
- ge
- ger
- allmän
- skäl
- minska
- Rapport
- REST
- Resultat
- återgår
- översyn
- Risk
- säkerhet
- Tjänster
- in
- lösning
- Kort
- signifikant
- liknande
- Small
- So
- fasthet
- någon
- något
- fart
- spendera
- Ange
- .
- förvaring
- framgång
- Som stöds
- yta
- system
- testa
- Genom
- hela
- tid
- token
- tokens
- topp
- Spårning
- transaktion
- Transaktioner
- Litar
- Uppdatering
- Uppdateringar
- POSTEN
- användare
- värde
- utsikt
- vitlista
- VEM
- inom
- utan
- Arbete
- värt
- noll-