Løsningene for de fatale feilene

MasterChef har visse feil som kan fikses under bruk, men bare hvis brukerne er klar over dem og hva de kan gjøre. Her er løsningen, ifølge Gleb Zykov og Vlad Korovnikov av HashEx.

Desentraliserte utvekslinger (DEXer) pleide å være ganske sjeldne for bare to korte år siden, og i dag ser det ut til at de er overalt. Tallrike prosjekter som har sine egne personlige DEX-er. Dette skjedde fordi når et blokkjedeprosjekt bestemmer seg for å lansere en DEX, gjør de det ikke helt fra bunnen av. I stedet er grunnlaget for DEX-koden ofte en gaffel av en av to store DEX-er - Sushi Bytt or PannekakeSwap.

Masterchef Smart Kontrakt

Disse to børsene revolusjonerte stort sett DEX-området takket være en spesiell smart kontrakt kalt MasterChef. MasterChef dukker opp i begge, og slik dukker den også opp i enhver DEX som ble laget som en gaffel av en av disse to. Hver ny DEX får dele de samme funksjonene. Men det betyr også at den deler MasterChefs mangler og sårbarheter. 

Så la oss ta en titt på hvilke problemer brukere og utviklere kan støte på når de arbeider med MasterChef. Hva bør de være oppmerksomme på? Og hvordan bør de tilnærmes?

Hvordan fungerer DEXer?

Det første å merke seg er at en MasterChef-kontrakt er en smart kontrakt skrevet i Solidity som kontrollerer hva en gård kan gjøre, og hvordan den kan gjøre det. I de fleste prosjekter er det flere smarte kontrakter som deler ansvaret og arbeidet. Men når det kommer til MasterChef-baserte protokoller, er det denne enkeltkontrakten som tar seg av alt angående oppdrett.

Desentraliserte børser lar deg veksle kryptovalutaer uten å måtte sette inn penger i børsens lommebok. I stedet setter du inn penger til smarte kontrakter fra din egen lommebok. Du er den eneste personen som kontrollerer det og kan få tilgang til dine egne midler hvis kontraktene ikke har bakdører eller sårbarheter.

En annen forskjell ligger i det faktum at CEXer bruker ordrebøker for kjøp og salg. Dette betyr at de matcher kjøpere med selgere, mens DEXer bruker AMM (Automated Market Maker) protokoller for handel, som beregner prisen på eiendelene avhengig av hvor mye likviditet som er investert.

Likviditet kommer fra likviditetspooler, som er puljer som brukere kan sette inn midler til spesifikke par og gjøre midler tilgjengelig for protokollen. Så, når noen prøver å kjøpe eiendeler ved å bruke det paret, blir ordren deres umiddelbart oppfylt ved å bruke midlene fra poolen. I mellomtiden får folk som har satt inn midler til likviditetspoolen LP-tokens for den spesifikke poolen. Dette gir dem rett til å dele belønninger.

Og hvis de noen gang ønsker å få pengene sine tilbake, er alt de trenger å gjøre å gi tilbake LP-tokenene de mottok.

Som du kanskje vet, er det flere måter å generere rentene fra kryptobeholdning. Gårder gir ekstra belønning for å gi likviditet. Brukere legger til likviditet til DEX-er, får LP-tokens og satser dem i gårder.

MasterChef: Sårbarheter og feil

Vi har dekket hvordan DEXer fungerer og hvordan likviditetspooler fungerer. Så la oss se nærmere på hvor MasterChef-sårbarhetene kommer inn, hvordan de påvirker prosessen, samt hvilken tilnærming du må ta for å sikre at ting fortsetter å gå jevnt.

Kompromitterte kontoer

Et av de største problemene å se opp for dreier seg om at eierkontoene blir kompromittert. I utgangspunktet oppfant SushiSwap en metode som tillot den å få en fordel mot Uniswap. Denne metoden dreier seg om å migrere eiendeler fra en børs til en annen. Dette håndteres av kontrakten ved hjelp av en egen funksjon som kun er tilgjengelig for kontraktens eier.

Imidlertid kan denne migreringen ende opp med å bli innstilt på i utgangspunktet hvilken som helst kontrakt, uten noen begrensninger, noe som endte opp med å bli en stor forglemmelse. Så hvis eierkontoen er kompromittert, kan dette resultere i en ny migrasjonskontrakt som vil sende alle basis-LP-tokenene i alle oppdrettspoolene til en vilkårlig adresse. Dette vil føre til et massivt tap av investerte eiendeler.

Det skal bemerkes at denne funksjonen nå er kjent for utviklere, og at den ender opp med å bli fjernet med en gang i gafler. Men hvis det forblir til stede, bør det umiddelbart tas som et rødt flagg.

En annen ting å merke seg er at i noen MasterChef-gafler kan eieren av kontrakten endre utslippsraten uten noen begrensninger. Hvis kontoen blir kompromittert, kan imidlertid en angriper sette en veldig høy utslippsrate, noe som vil føre til devaluering av tokenet.

Det er en ganske enkel måte å løse dette på ganske enkelt ved å sikre at alle funksjoner som er tilgjengelige for eieren av kontrakten krever multisignaturautorisasjon. På den måten, hvis en enkelt adresse er kompromittert, ville dårlige skuespillere ikke kunne gjøre mye med den. En annen ting å gjøre er å legge til en midlertidig blokkering (Timelock-kontrakt) for å kalle migreringsfunksjonen. På denne måten har brukeren mer tid til å ta en avgjørelse, og børsen vil måtte varsle deg om migreringen eller enhver annen mistenkelig transaksjon.

Legger til identiske oppdrettsbassenger

Et annet ganske åpenbart, men oversett problem dukker opp når den opprinnelige kontrakten ikke tar for seg behandling av identiske oppdrettsbassenger, noe som betyr at kontrakten truer med å beregne oppdrettsbelønningen feil.

Dette er ikke et stort problem hvis MasterChef brukes riktig, siden eieren ikke vil legge til identiske bassenger med vilje. Faktisk, i riktig fungerende børser, blir disse tingene verifisert, og det er på det sterkeste forbudt å opprette en duplikatpool. Så hvis du starter opprettelsen av bassenget og du er på vei nedover veien for å lage et duplikat av det eksisterende bassenget, bør systemet kunne rapportere en feil. Eller foreslå at du legger pengene dine til den eksisterende poolen i stedet for å lage en ny.

Beregner ikke antallet innsatte tokens

Av en eller annen grunn har folk en tendens til å glemme å vurdere hva som kan skje hvis tokens med provisjoner på overføringer eller rebase-tokens legges til som pools til MasterChef-kontrakten. Det som skjer er et sammenbrudd i måten belønningene beregnes på, siden kontraktskoden legger til eiendeler til puljer bare ved å kalle bestemte funksjoner. Dette betyr at å legge til tokens til adressen vil kombinere dem med eiendelene som allerede er i bassenget. Men beregningene for belønninger for slike tokens kan bli ødelagt, noe som fører til sårbarheter.

Riktig fungerende plattformer bør beregne mengden midler som overføres til oppdrett separat ved å sjekke det faktiske overførte beløpet som tar hensyn til provisjoner. På denne måten gjøres belønningsberegningene riktig.

MasterChef: Konklusjon

MasterChef er en enkelt smart kontrakt som brukes for jordbruksutbytte ved å gi likviditet i DEX-er. Dessverre har den visse feil som kan fikses under bruk, men bare hvis brukerne er klar over dem og hva de kan gjøre. 

Ovenfor har vi dekket flere ting som kan skje og hvordan disse problemene kan unngås. Men det skal bemerkes at det er flere av dem, for eksempel utvanning av belønninger hvis tokens sendes direkte til kontraktsadressen, problemer med startblokkendringer, gassoptimaliseringer og mer. 

Det er med andre ord sårbarheter og problemstillinger å huske på og holde øye med. Men totalt sett er MasterChef en revolusjonerende kontrakt som stort sett har muliggjort desentraliserte utvekslinger. Så så lenge du fortsetter å bruke den forsiktig og er klar over dens feil og hvordan du kan fikse dem, bør du ha det bra.

Om forfatterne

Gleb Zykov er medgründer og CTO ved a Defi sikkerhet og analyseselskap HashEx.

​​Vlad Korovnikov er Junior Smart Contract revisor og utvikler.

Har noetHva å si om Masterchef-løsninger eller noe annet? Skriv til oss eller delta i diskusjonen i vår Telegram kanal. Du kan også ta oss på Tik Tok, Facebook eller Twitter.

Ansvarsfraskrivelse

All informasjonen på nettstedet vårt er kun publisert i god tro og kun for generell informasjon. Enhver handling som leseren tar på informasjonen som finnes på nettstedet vårt, er strengt på egen risiko.