Løsningerne for de fatale fejl

MasterChef har visse fejl, som kan rettes under brug, men kun hvis brugerne er opmærksomme på dem, og hvad de kan gøre. Her er løsningen ifølge Gleb Zykov og Vlad Korovnikov af HashEx.

Decentraliserede udvekslinger (DEX'er) plejede at være ret sjældne for kun to korte år siden, og i dag ser det ud til, at de er overalt. Talrige projekter med deres egne personlige DEX'er. Dette skete, fordi når et blockchain-projekt beslutter sig for at lancere en DEX, laver de det ikke helt fra bunden. I stedet er grundlaget for DEX'ens kode ofte en forgrening af en af ​​to store DEX'er - SushiByt or PandekageSwap.

Masterchef Smart Kontrakt

Disse to børser revolutionerede stort set DEX-området takket være en speciel smart kontrakt kaldet MasterChef. MasterChef optræder i dem begge, og så optræder det også i enhver DEX, der blev lavet som en gaffel af en af ​​disse to. Hver ny DEX får de samme funktioner. Men det betyder også, at den deler MasterChefs mangler og sårbarheder. 

Så lad os tage et kig på, hvilke problemer brugere og udviklere kan støde på, når de beskæftiger sig med MasterChef. Hvad skal de være opmærksomme på? Og hvordan skal de gribes an?

Hvordan virker DEX'er?

Den første ting at bemærke er, at en MasterChef-kontrakt er en smart kontrakt skrevet i Solidity, der styrer, hvad en gård kan gøre, og hvordan den kan gøre det. I de fleste projekter er der flere smarte kontrakter, der deler ansvaret og arbejdet. Men når det kommer til MasterChef-baserede protokoller, er det denne enkelt kontrakt, der tager sig af alt vedrørende landbruget.

Decentraliserede børser giver dig mulighed for at udveksle kryptovalutaer uden at skulle indbetale penge i børsens pung. I stedet indbetaler du penge til smarte kontrakter fra din egen tegnebog. Du er den eneste person, der kontrollerer det og kan få adgang til dine egne midler, hvis kontrakterne ikke har bagdøre eller sårbarheder.

En anden forskel ligger i, at CEX'er bruger ordrebøger til køb og salg. Det betyder, at de matcher købere med sælgere, mens DEX'er bruger AMM (Automated Market Maker) protokoller til handel, som beregner prisen på aktiverne afhængig af hvor meget likviditet der er investeret.

Likviditet kommer fra likviditetspuljer, som er puljer, hvortil brugere kan indbetale midler til specifikke par og stille midler til rådighed for protokollen. Når nogen derefter forsøger at købe aktiver ved hjælp af dette par, bliver deres ordre straks opfyldt ved hjælp af midlerne fra puljen. I mellemtiden får folk, der har indbetalt midler til likviditetspuljen LP-tokens til den specifikke pulje. Dette giver dem ret til at dele belønninger.

Og hvis de nogensinde ønsker at få deres penge tilbage, skal de blot give de LP-tokens tilbage, som de har modtaget.

Som du måske ved, er der flere måder at generere på udbytter fra kryptobeholdninger. Gårde giver yderligere belønninger for at levere likviditet. Brugere tilføjer likviditet til DEX'er, får LP-tokens og satser dem i gårde.

MasterChef: Sårbarheder og fejl

Vi har dækket, hvordan DEX'er fungerer, og hvordan likviditetspuljer fungerer. Så lad os se nærmere på, hvor MasterChef-sårbarhederne kommer ind, hvordan de påvirker processen, samt hvilken tilgang du skal tage for at sikre, at tingene fortsætter glat.

Kompromitterede konti

Et af de største problemer, man skal holde øje med, drejer sig om, at ejerkonti bliver kompromitteret. Grundlæggende opfandt SushiSwap en metode, der gjorde det muligt for den at få en fordel i forhold til Uniswap. Denne metode drejer sig om at migrere aktiver fra en børs til en anden. Dette håndteres af kontrakten ved hjælp af en separat funktion, som kun er tilgængelig for kontraktens ejer.

Denne migrering kan dog ende med at blive tunet til stort set enhver kontrakt, uden nogen begrænsninger, hvilket endte med at blive en stor forglemmelse. Så hvis ejerkontoen kompromitteres, kan dette resultere i en ny migreringskontrakt, der sender alle basis-LP-tokens i alle landbrugspuljer til en vilkårlig adresse. Dette ville føre til et massivt tab af investerede aktiver.

Det skal bemærkes, at denne funktion nu er kendt for udviklere, og så ender den med at blive fjernet med det samme i gafler. Men hvis det forbliver til stede, bør det øjeblikkeligt tages som et rødt flag.

En anden ting at bemærke er, at i nogle MasterChef-gafler kan ejeren af ​​kontrakten ændre emissionshastigheden uden nogen begrænsninger. Hvis kontoen er kompromitteret, kan en angriber dog sætte en meget stor emissionsrate, hvilket ville føre til devaluering af tokenet.

Der er en ret nem måde at løse dette på blot ved at sikre, at alle funktioner, der er tilgængelige for ejeren af ​​kontrakten, kræver multi-signatur-autorisation. På den måde, hvis en enkelt adresse er kompromitteret, ville dårlige skuespillere ikke være i stand til at gøre meget med den. En anden ting at gøre er at tilføje en midlertidig blokering (Timelock-kontrakt) for at kalde migreringsfunktionen. På denne måde har brugeren mere tid til at træffe en beslutning, og børsen skal underrette dig om migreringen eller enhver anden mistænkelig transaktion.

Tilføjelse af identiske landbrugspuljer

Et andet ret åbenlyst, men overset problem dukker op, når den oprindelige kontrakt ikke tager højde for behandling af identiske landbrugspuljer, hvilket betyder, at kontrakten truer med at beregne landbrugsbelønningen forkert.

Dette er ikke et stort problem, hvis MasterChef bruges korrekt, da ejeren ikke vil tilføje identiske pools med vilje. Faktisk er disse ting verificeret i korrekt fungerende børser, og det er stærkt forbudt at oprette en duplikatpulje. Så hvis du starter oprettelsen af ​​poolen, og du er på vej ned ad stien til at oprette en duplikat af den eksisterende pool, burde systemet være i stand til at rapportere en fejl. Eller foreslå, at du tilføjer dine midler til den eksisterende pulje i stedet for at lave en ny.

Beregner ikke mængden af ​​deponerede tokens

Af en eller anden grund har folk en tendens til at glemme at overveje, hvad der kan ske, hvis tokens med provision på overførsler eller rebase-tokens tilføjes som puljer til MasterChef-kontrakten. Hvad der sker, er en opdeling i den måde, belønningerne beregnes på, da kontraktkoden kun tilføjer aktiver til puljer ved at kalde visse funktioner. Det betyder, at tilføjelse af tokens til adressen vil kombinere dem med de aktiver, der allerede er i puljen. Men beregningerne for belønninger for sådanne tokens kan blive brudt, hvilket fører til sårbarheder.

Korrekt fungerende platforme bør beregne mængden af ​​midler, der overføres til landbrug, separat ved at kontrollere det faktiske overførte beløb, der tager hensyn til provisioner. På denne måde udføres belønningsberegningerne korrekt.

MasterChef: Konklusion

MasterChef er en enkelt smart kontrakt, der bruges til landbrugsudbytte ved at levere likviditet i DEX'er. Desværre har den visse fejl, som kan rettes under brug, men kun hvis brugerne er opmærksomme på dem, og hvad de kan gøre. 

Ovenfor har vi dækket flere ting, der kan ske, og hvordan disse problemer kan undgås. Men det skal bemærkes, at der er flere af dem, såsom udvanding af belønninger, hvis tokens sendes direkte til kontraktadressen, problemer med startblokændringer, gasoptimeringer og mere. 

Der er med andre ord sårbarheder og problemer, man skal huske på og holde øje med. Men samlet set er MasterChef en revolutionær kontrakt, der stort set har muliggjort decentraliserede udvekslinger. Så så længe du bliver ved med at bruge det omhyggeligt og forbliver opmærksom på dets fejl og hvordan du løser dem, burde du have det fint.

Om forfatterne

Gleb Zykov er medstifter og CTO hos a Defi sikkerhed og analysevirksomhed HashEx.

â € <â € <Vlad Korovnikov er Junior Smart Contract revisor og udvikler.

Fik noglethvad at sige om Masterchef-løsninger eller noget andet? Skriv til os eller deltag i diskussionen i vores Telegram kanal. Du kan også fange os Tik Tok, Facebook eller Twitter.

Ansvarsfraskrivelse

Alle oplysninger på vores websted offentliggøres i god tro og kun til generelle informationsformål. Enhver handling, som læseren foretager sig på oplysningerne på vores websted, er strengt på deres egen risiko.