1 tommer revision med fast rentebytte

Genudgivet af Platon

Abonnenter: 0

Februar 15, 2022

Introduktion

1inch team bad os om at gennemgå og revidere deres Fixed Rate Swap smarte kontrakter. Vi kiggede på koden og offentliggør nu vores resultater.

Anvendelsesområde

Vi reviderede forpligtelse b1600f61b77b6051388e6fb2cb0be776c5bcf2d1 af 1inch/fixed-rate-swap depot. I omfang var følgende kontrakt:

- FixedRateSwap.sol

Alle andre projektfiler og mapper, inklusive test, eksterne afhængigheder og projekter, spilteori og incitamentsdesign, blev udelukket fra denne revisions omfang. Ekstern kode og kontraktafhængigheder blev antaget at virke som dokumenteret.

Generel sundhed

Vi fandt, at kodebasen var kompleks og manglede ofte tilstrækkelig dokumentation til at forklare den ikke-trivielle matematik og logik, der blev brugt hele vejen igennem. For en kodebase af denne størrelse betragter vi det store antal problemstillinger, der er inkluderet i denne rapport, for at være tegn på unødvendig kompleksitet. Sammen med mangel på dokumentation er kodebasen ikke på det raffinement, vi ville forvente for et produktionsklart system. At eliminere den, omend smarte, kontinuerlige gebyrfunktion og erstatte den med tre separate lineære funktioner kunne gøre meget af kodebasen langt lettere at ræsonnere om. Et enklere design kunne eliminere mange af de mest komplekse kodeblokke, hvor problemer blev identificeret. Refaktorering og forenkling af protokollen er meget tilrådeligt, i så fald anbefaler vi, at den gennemgår yderligere revisioner.

Alt sagt var 1-tommer-teamet altid klar til at besvare eventuelle spørgsmål under revisionen, og de var meget nemme at arbejde med. De er modtagelige for feedback og forslag til løbende forbedringer.

Overvejelser om gasforbrug

Der er nogle særligt gasintensive dele af kodebasen, som f.eks _powerHelper funktion og binære søgninger, som vi observerede ved at bruge over 400 gas i nogle kanttilfælde. I betragtning af arten af protokollen og de stabile mønter, den har til hensigt at håndtere, kan det høje gasforbrug, som projektets kompleksitet fører til, underminere protokollens formål og helt sikkert påvirke dens generelle anvendelighed.

System overblik

Fixed Rate Swap-protokollen er en Automatic Market Maker (AMM), der bruger en konstant sumpriskurve til at lette swaps mellem aktiver, hvis priser er stabile i forhold til hinanden.
Det implementerer også en variabel gebyrmekanisme, der generelt opkræver 0.01% som gebyrer. Når AMM's token-saldi går til ekstreme forhold, reduceres gebyrerne enten til 0% eller hæves op til 0.2% afhængigt af, om aktiviteten er henholdsvis ønskelig eller ej for puljens aktivsammensætning. Sådanne gebyrer opbevares i puljen, hvor likviditetsudbydere vil drage fordel af dem ved at eje aktierne (AMM's egne ERC20 LP token).

Privilegerede roller

Der er ingen privilegerede roller i den reviderede version af protokollen.

Eksterne afhængigheder og tillidsantagelser

Protokollen har ikke til hensigt at understøtte ERC20 tokens, der opkræver gebyrer ved overførsel.

Det er også værd at nævne, at der kan være aktiver, der afhængigt af deres karakter kan frembringe uventet adfærd svarende til dem, der er beskrevet i denne rapport, f.eks. stabile mønter med et uoverensstemmende antal decimaler mellem hinanden eller aktiver, der kunne tillade ubegrænsede flashlån .

Fund

Her præsenterer vi vores resultater.

Update: 1inch-teamet anvendte adskillige rettelser baseret på vores anbefalinger og gav os et sæt tilsagn, der målrettede de respektive fundne problemer. Disse tilsagn er angivet på hvert enkelt problem, og vi behandler de rettelser, der er introduceret under hver enkelt forpligtelse. Vi har dog kun gennemgået specifikke patches til de problemer, vi rapporterede. Kodebasen undergik nogle andre ændringer, som vi ikke har revideret, og vi anbefaler, at disse ændringer gennemgås i dybden i en fremtidig revision.

Kritisk sværhedsgrad

Ingen.

Høj sværhedsgrad

Ingen.

Medium sværhedsgrad

[M01] Manglende outputsikkerhedsforanstaltninger kan føre til tab af midler

FixedRateSwap kontrakt letter bytte af en stabil mønt for en anden, og giver også brugerne mulighed for det depositum , tilbagekalde aktiver til "aktier" i likviditetspuljen (LP-tokens).

Hverken swaps, udbetalinger eller indskud giver dog en mekanisme til, at brugere kan indstille minimumsacceptable afkastværdier fra interaktioner med puljen.

Puljen vurderer variable gebyrer baseret på, hvordan interaktioner påvirker puljens sammensætning. Ikke desto mindre er der med dette design, da vurderede gebyrer vil gå direkte til puljeaktionærer, et økonomisk incitament for majoritetsaktionæren til at frontløbe store token-swaps, der manipulerer puljesammensætningen for at fremtvinge højere gebyrer.

På samme måde kunne front-running også bruges til at drage fordel af protokolafrunding inden for token-outputberegninger. Selvom det er usandsynligt i betragtning af den nuværende tilstand af økosystemet med hensyn til populære stabile mønter, hvis fromBalance af et token i puljen kunne manipuleres til at være i størrelsesordenen 1e36 * inputAmount for enhver given swap, så denne linje af _getReturn funktion ville blive afkortet til zero, hvilket fører til en nulværdi outputAmount.

Men fordi nul-værdi swaps er beskyttet mod, trunkering inden for outputAmount beregning ville ske før de værst tænkelige input. Konkret, en fromBalance hvor som helst inden for området af [1e26 til 1e35] * the input amount kunne føre til trunkering og en reduktion af outputAmount som kunne være rentabelt for puljeaktionærer på bekostning af brugerne.

Selvom et sådant scenario i øjeblikket kan være usandsynligt, kan fremtidige økosystemændringer og ubegrænsede flashlån gøre dette til en mere levedygtig angrebsvektor.

For at undgå utilsigtet tab af midler og afbøde mulige frontløbende angreb, bør du overveje at tillade brugere at angive den mindste acceptable afkastværdi for enhver interaktion med protokollen, der har monetære implikationer.

Update: Rettet ind begå ea75a86. Der er dog ikke tilføjet nogen specifik test for at validere, at rettelsesimplementeringen forhindrer dette angreb.

Lav sværhedsgrad

[L01] Indskud kan vende tilbage ved underløb

Hvis en pulje er dramatisk ubalanceret, vil indskud vende tilbage under beregningen af og shift variabel i _getVirtualAmountsForDepositImpl funktion medmindre det samlede indskudte beløb er større end 1/1000 af den eksisterende saldo i puljen.

For eksempel forsøg på at indbetale et forhold mellem tokens på i alt mindre end 10 i en pulje med eksisterende saldi på 10,000 token0 og .0001 token1, vender tilbage. Indbetaling af et større beløb vil lykkes.

Dette kunne bruges til at skabe en barriere for at forhindre andre brugere i at deltage i poolen. I et sådant scenarie er det stadig muligt at trække sig fra og bytte tokens via puljen. Det er også muligt at indbetale til nøjagtig samme forhold af puljen. Hvis poolen skifter til at være mindre ensidig, bliver mindre aflejringer igen mulige.

For at undgå potentialet for lammelsesangreb, bør du overveje at revidere kodebasen for bedre at imødekomme disse kantsager. Overvej i det mindste eksplicit at tjekke for disse betingelser og returnere nyttige fejlmeddelelser, når du vender tilbage.

Update: Rettet ind begå 4aa5210.

[L02] Ufuldstændige hændelsemissioner

Swap hændelse udsendes, hver gang protokollen letter et token-swap.

Der er dog flere offentlige metoder tilgængelige til at udføre token-swaps. Det swap0To1 , swap1To0 funktioner sender resultatet af byttet direkte til msg.sender, Men swap0To1For , swap1To0For funktioner sender resultaterne af byttet til en adresse, der udtrykkeligt er angivet af to parameter.

Siden den samme hændelse, som den udsendte i begge tilfælde, har parterne uden for kæden ingen måde at skelne mellem, hvilken slags bytte der blev udført, eller hvem resultatet af byttet blev leveret til.

På samme måde er Deposit , Withdrawal begivenheder accepterer kun en enkelt user adresseparameter, selvom de også udsendes i funktioner, hvor msg.sender kan være anderledes end den part, der modtager tokens.

Overvej at tilføje en indekseret recipient adresseparameter til begivenhederne, så de mere fuldstændigt kan formidle, hvilke handlinger protokollen tager.

Update: Anerkendt, og vil ikke rette.

[L03] Manglende inputvalidering

public getReturn funktionen mangler en vis inputvalidering. Specifikt:

Det bekræfter ikke, at tokenFrom , tokenTo adresser er de tokens, der udgør puljen.
Det bekræfter ikke, at inputAmount parameter er ikke-nul.
Det bekræfter ikke, at fromBalance + toBalance værdien er ikke-nul.

Derudover er hverken withdrawFor eller withdrawForWithRatio funktioner beregner, om en bruger har nok aktier til at hæve deres anmodede beløb. I begge tilfælde vil en tilbagetrækning gå tilbage, hvis betingelsen ikke er opfyldt, men fejlmeddelelserne er uklare og udsendes først efter at have forbrugt unødvendig gas.

Endelig withdrawForWithRatio funktion forsømmer at sikre, at de værdier, der bruges til virtuel saldoberegninger, er mindre end eller lig med kontraktens faktiske saldi. Et sådant scenarie ville føre til en kryptisk aritmetisk tilbagevenden ved beregning balanceX , balanceY for _getRealAmountsForWithdrawImpl funktion.

Manglende validering af brugerkontrollerede parametre kan resultere i fejlagtige eller mislykkede transaktioner, som er svære at fejlfinde. For at undgå dette bør du overveje at forbedre klarheden af fejlmeddelelser og tilføje inputvalidering for at imødegå de problemer, der er rejst ovenfor.

Update: Delvist fastgjort begå 63b6a95 , begå 7c0ade7. Det er kun blevet valideret, hvis inputAmount værdien er nul, og rækkefølgen af operationer er blevet flyttet til at fejle tidligt, når der brændes LP-tokens for at reducere gasomkostningerne. 1inch teams erklæring for dette problem:

tokenFrom og tokenTo validering er ikke obligatorisk, da de i swap-metoden erstattes af konstanter

[L04] Konstanter er ikke angivet eller tydeligt navngivet

I FixedRateSwap kontrakt, de bogstavelige værdier 998, 1000og 1002, som bruges til at træde gennem gebyrer i _getRealAmountsForWithdrawImpl , _getVirtualAmountsForDepositImpl funktioner, har ingen medfølgende forklaring eller inline dokumentation.

Desuden påvirker en mangel på inline-dokumentation også tvetydigt navngivne konstanter som bruges i beregninger i hele kodebasen.

For at forbedre kodens læsbarhed og lette refactoring, overveje at definere en konstant for hver "magiske værdi" og sikre, at alle konstanter har klare og selvforklarende navne. For komplekse værdier kan du overveje at tilføje inline-dokumentation, der forklarer, hvordan de blev beregnet, eller hvorfor de blev valgt.

Update: Rettet ind begå 7091076.

[L05] Vildledende eller ufuldstændig inline-dokumentation

Igennem kodebasen blev nogle få tilfælde af vildledende og/eller ufuldstændig inline-dokumentation identificeret og bør rettes.

Følgende er tilfælde af ufuldstændig inline-dokumentation:

Følgende er tilfælde af vildledende indlejret dokumentation:

beregninger af den private funktion _powerHelper angiv ikke eksplicit, at resultatet af multiplikationen er divideret med 1e18 for at forhindre dobbeltskalering af værdien. Ydermere matcher eksponenten af skaleringsfaktoren også den styrke, som funktionen giver, hvilket kan frembringe yderligere forvirring, hvis det ikke noteres.

Tydelig inline-dokumentation er grundlæggende for at skitsere kodens intentioner. Uoverensstemmelser mellem den inline-dokumentation og implementeringen kan føre til alvorlige misforståelser om, hvordan systemet forventes at opføre sig. Overvej at rette eventuelle fejl og tilføje yderligere dokumentation, hvor det er identificeret, for at undgå forvirring for både udviklere, brugere og revisorer.

Update: Anerkendt, og vil ikke rette.

[L06] Ingen tilgængelig dækningsrapport

selvom README fil peger på en dækningsrapport, den er utilgængelig.

Derudover er der ingen instruktioner til at køre testdækningsscripts.

Overvej at gøre dækningsrapporten tilgængelig og eksplicit dokumentere, hvordan man kører testdækningsscripts.

Update: Delvist fast. Dækningsrapporten er nu tilgængelig, dog README fil forklarer stadig ikke, hvordan man kører scripts.

[L07] Potentielt usikker ukontrolleret matematik

Hele FixedRateSwap kontrakt, der er mange anvendelser af unchecked matematik. Hovedårsagen til at bruge unchecked matematik er at fjerne overløbs-/underløbstjek i tilfælde, der enten er afhængige af sådan adfærd eller vides ikke at underløbe/overløbe. Dette har fordelen ved at spare gas, men hvis det bruges forkert, kan det føre til uventede resultater og potentielle sårbarheder.

Forekomster af unchecked aritmetik, der potentielt kan underløbe/overløbe, blev identificeret. For eksempel:

De nødvendige værdier, der kræves for at overløbe disse beregninger, parret med rimelige valideringer i hele kodebasen, forhindrer ofte disse overløb i at blive opnåelige i praksis, men de er stadig teoretisk muligt. Overvej ikke at bruge unchecked matematik undtagen når muligheden for overløb kan være fuldstændig udelukket, for at forhindre uventede resultater og reducere protokollens overordnede angrebsoverflade.

Update: Anerkendt, og vil ikke rette.

[L08] Usikker eksplicit støbning af heltal

Swap begivenhed tager en address og to int256 parametre, og det udsendes i swap0To1, swap1To0, swap0To1Forog swap1To0For funktioner.

Under emission bliver de heltalværdier, der sendes til begivenheden, dog eksplicit castet fra uint256 til int256 værdier.

Selvom det er usandsynligt, at det er problematisk i praksis i dag, kan økosystemudviklinger såsom ubegrænsede flashlån af stablecoin-aktiver få dette design til at udvise uønsket adfærd i fremtiden. På en given stor nok uint256 værdi, eksplicit støbning ind i en int256 type ville afkorte dens værdi. Som følge heraf kan systemer uden for kæden, afhængigt af hændelsesemissionens nøjagtighed, blive vildledt.

Overvej at omdefinere Swap begivenhed at forholde sig direkte til uint256 værdier, så de funktioner, der udsender begivenheden, kan give afkald på de eksplicitte kast.

Update: Rettet ind begå 8436c6c. 1 tommer hold importerede OpenZeppelin'erne SafeCast bibliotek for sikkert at støbe de nævnte sager.

[L09] Tilbagetrækningsprocessen kan resultere i gulvbelægning

Når en aktionær bruger enten withdraw eller withdrawFor funktioner, kontrakten beregner mængden af aktiver at de har ret til at få en antal aktier. Disse aktiver overføres derefter til den angivne modtager.

Men siden if udsagn bliver brugt snarere end require erklæringer for at validere, om et aktiv skal sendes til modtageren, hvis puljen er ubalanceret og mængden af andele er lille, kan kontrakten bunde værdien, der skal sendes for enten det ene eller begge aktiverne.

I betragtning af at de involverede værdier nødvendigvis ville være ret små, og i betragtning af det faktum, at protokollen ikke helt kan begrænse udbetalinger, hvor et token-output faktisk kan være nul, bør du overveje at dokumentere denne potentielle afrundingsadfærd, så brugerne er opmærksomme på det, når de trækker sig tilbage.

Update: Anerkendt, og vil ikke rette.

Bemærkninger og yderligere oplysninger

[N01] Forældede projektafhængigheder

Under installationen af projektets afhængigheder, advarer NPM om, at en af de installerede pakker, Highlight, "vil ikke længere blive understøttet eller modtage sikkerhedsopdateringer i fremtiden".

Selvom det er usandsynligt, at denne pakke kan forårsage en sikkerhedsrisiko, kan du overveje at opgradere den afhængighed, der bruger denne pakke, til en vedligeholdt version.

Update: Rettet ind begå 0a2b55d. Installationen kræver dog nu brug af -force flag på aktuelle LTS-versioner af node for at lykkes.

[N02] Poolgebyrer kan tilskynde til ubalancerede indskud

Ved indbetaling i FixedRateSwap kontrakt, den _getVirtualAmountsForDeposit funktion beregner den virtuelle værdi af indbetalingen. Virtuelle beløb er de oprindelige beløb, der skaleres efter opkrævning af gebyret i henhold til puljens aktuelle aktivforhold.

Hvis en bruger indbetaler penge på nuværende forhold mellem aktiver i puljen så bliver de ikke opkrævet gebyrer. Ellers bliver de opkrævet gebyrer baseret på forskellen mellem deres indlånsforhold og puljens nuværende formueforhold.

Dette design indebærer, at når forholdet mellem aktiver i puljen er ubalanceret, vil brugerne blive tilskyndet til at indbetale med det samme ubalancerede forhold i stedet for at indsætte med et forhold, der ville gøre puljen mere afbalanceret.

For at tilskynde til en mere afbalanceret pulje, overveje at incitamentere indskud, der balancerer poolen i stedet for at straffe dem. Alternativt, hvis dette ikke er muligt, kan du overveje at forklare hvorfor i projektets dokumentation.

Update: Anerkendt, og vil ikke rette.

[N03] Udokumenterede implicitte godkendelseskrav

FixedRateSwap kontrakten forudsætter implicit, at den er blevet tildelt en passende godtgørelse, før den udføres swaps , indskud som nødvendigvis overfører tokens.

Til fordel for eksplicithed og for at forbedre den overordnede klarhed af kodebasen, overveje at dokumentere alle godkendelseskrav i de relevante funktioners inline-dokumentation.

Update: Anerkendt, og vil ikke rette.

[N04] Forvirrende implicit validering af `outputAmount`

getReturn funktion leveres med tre parametre, nemlig et token til at bytte fra (tokenFrom), et token at bytte til (tokenTo), og et inputbeløb (inputAmount værdien af tokenFrom aktiv). Den tilsvarende outputAmount værdi (det resulterende beløb for tokenTo aktiv) er derefter beregnet og returneret.

Før beregningen, funktionen Kræver at inputAmount værdien er mindre end eller lig med puljens symbolske saldo på tokenTo aktiv. Imidlertid outputAmount værdi, formentlig den mere intuitive værdi at kontrollere mod tokenTo aktivsaldo, kontrolleres aldrig eksplicit for den samme tilstand.

I virkeligheden, matematikken brugt til at beregne outputAmount værdi sikrer, at den vil være strengt mindre end eller lig med inputAmount værdi.

Men intentionaliteten af denne adfærd er uklar, dvs. det er ikke indlysende, om dette design blot er beregnet til at fejle hurtigere under udførelsen for at reducere gasomkostningerne eller ej. Overvej eksplicit at dokumentere begrundelsen for den nøjagtige anvendte kontrol. Overvej desuden at validere, om saldoen på to aktiv er større end outputAmount værdi i modsætning til inputAmount værdi.

Update: Rettet ind begå 10f4d9c.

[N05] Navngivningsinkonsistens

FixedRateSwap kontrakt angiver en eksplicit par tokens at swap-, udbetalings- og indbetalingsoperationerne er beregnet til at fungere med. Gennem hele kodebasen er disse tokens mærket med et indeks på enten 0 or 1, som i token0 , token1. Funktioner, der er beskrivende navngivet for at formidle detaljer om brug, gør også brug af disse token-indekser, som f.eks. swap0To1 funktion.

Dog for withdrawForWithRatio funktion, den parameter, der definerer den andel, der skal modtages af token0 mod token1 er navngivet firstTokenShare hvilket kunne skabe forvirring, at det er en henvisning til token1 aktiv og ikke token0 aktiv.

For at forbedre den overordnede læsbarhed og reducere potentiel forvirring bør du overveje at holde navnekonventionerne konsistente gennem hele kodebasen.

Update: Rettet ind begå 57ad4cd.

[N06] Tilbagestillingsmeddelelser er inkonsekvent formateret

require udsagn i konstruktøren af FixedRateSwap kontrakt er formateret anderledes end alle de andre require udsagn i kontrakten.

Da inkonsekvent formaterede returmeddelelser kan skabe unødvendig forvirring, bør du overveje at sikre, at alle require erklæringer har tilbagevendende meddelelser, der er konsekvent formaterede, nøjagtige, informative og brugervenlige.

Update: Rettet ind begå 0aa4e9d.

[N07] Inkonsekvent brug af navngivne returvariabler

Der er en inkonsekvent brug af navngivne returvariabler i FixedRateSwap kontrakt.

Specifikt, mens de fleste funktioner returnerer navngivne variabler decimals, _getVirtualAmountsForDepositImpl, _getRealAmountsForWithdrawImplog _checkVirtualAmountsFormula funktioner returnerer eksplicitte værdier.

Overvej at anvende en ensartet tilgang til returneringsværdier i hele kodebasen ved at fjerne alle navngivne returvariabler, eksplicit erklære dem som lokale variabler og tilføje de nødvendige retursætninger, hvor det er relevant. Dette ville forbedre både eksplicititeten og læsbarheden af koden, og det kan også hjælpe med at reducere regressioner under fremtidige koderefaktorer.

Update: Anerkendt, og vil ikke rette.

[N08] Gasoptimeringer

Inden for FixedRateSwap kontrakt, er der muligheder for et par simple gasforbrugsreduktioner. For eksempel:

_getVirtualAmountsForDeposit private funktion kaldes kun fra ét sted i kodebasen, og det er depositFor fungere. Indenfor depositFor funktion der er opkald til token0.balanceOf(address(this)) , token1.balanceOf(address(this)). Men de nøjagtige samme opkald foretages øverst på _getVirtualAmountsForDeposit fungere. Sidstnævnte funktion kunne blot bestå de nødvendige værdier, i stedet for at aflæse saldierne to gange pr depositFor opkald.
Inden for _getRealAmountsForWithdrawImpl private funktion, den secondTokenShare variabel er defineret som _ONE - firstTokenShare. På den aller næste linje, udføres den nøjagtig samme subtraktion igen, når den blot kunne bruge secondTokenShare variabel.

For at reducere gasomkostningerne og yderligere forenkle kodebasen, overveje at tage fat på de tilfælde, der er nævnt ovenfor.

Update: Rettet ind begå 34974ee.

[N09] Forkert funktionssynlighed

withdrawWithRatio funktion kaldes ikke internt af nogen af funktionerne i FixedRateSwap kontrakt. Overvej at indstille synlighed til external i stedet for public.

Update: Rettet ind begå cb852f5.

[N10] Afhængighed af matchning `decimals` kan være problematisk

Protokollen kræver implicit, at begge tokens inde i en pool understøtter decimals metode for at poolbyggeriet bliver en succes. I virkeligheden er denne metode næsten allestedsnærværende, men den er teknisk set, en valgfri komponent i ERC20-specifikationen, hvori det udtrykkeligt er angivet, at kontrakter "IKKE MÅ forvente, at disse værdier er til stede". I øjeblikket er alle tokens, der ikke understøtter det valgfrie decimals metoden vil ikke være anvendelig i protokollen.

Måske mere problematisk, som en del af disse opfordringer til token decimals, kræver protokollen yderligere, at begge tokens returnerer identiske værdier.

Det stabile mønt-tokenrum er dog ikke homogent i denne henseende. Den består af mange tokens, der returnerer en række forskellige værdier for decimals. For eksempel mens USDT , USDC rapport 6 decimaler, DAI rapporterer 18 decimaler.

Hvis disse er bevidste begrænsninger af protokollen, kan du overveje at berøre dem eksplicit og give korte begrundelser via den inline-dokumentation. Overvej også at give bedre fejlmeddelelser på byggetidspunktet for tokens, der ikke understøtter decimals metode. Alternativt kan du overveje at gøre protokollen mere robust, så den kan håndtere tokens, der ikke understøtter decimals metode eller par rapportering forskellig decimals i samme pool.

Update: Rettet ind begå b49d808. Inline dokumentation blev tilføjet.

[N11] Typografisk fejl

Vi har identificeret følgende typografiske fejl i kodebasen:

Tilbagemeldingsmeddelelsen tændt line 92 of FixedRateSwap.sol starter uden stort bogstav, hvilket gør det inkonsistent med resten af koden.

For at forbedre den overordnede konsistens og læsbarhed af kodebasen bør du overveje at rette denne og eventuelle andre typografiske fejl i hele kodebasen.

Update: Rettet ind begå a92d16a.

[N12] Unødvendigt `virtual` funktion

FixedRateSwap kontrakt arver fra OpenZeppelin's ERC20 kontrakt men det tilsidesætter dens ERC20.decimals funktion. Dette er påkrævet, fordi FixedRateSwap's likviditetspuljetoken, der er afhængig af decimals af de aktiver, der udgør puljen, nødvendigvis er dynamisk.

Men selvom denne overordnede implementering af funktionen skulle være endelig, er den det defineret med virtual søgeord, hvilket signalerer, at det ikke nødvendigvis er en endelig implementering og giver mulighed for at tilsidesætte den igen.

For at undgå forvirring og præcisere hensigten, overveje at fjerne virtual søgeord eller dokumentere årsagerne til at beholde det.

Update: Rettet ind begå 8bce5ec.

konklusioner

Der blev ikke fundet nogen alvorlige problemer. Nogle ændringer blev foreslået for at følge bedste praksis og reducere den potentielle angrebsoverflade.

Tidsstempel: Februar 15, 2022