Sikkerhetsanalyse av ERC 1155 NFT Smart Contract

Lesetid: 5 minutter

Du må ha hørt om kryptovaluta-tokens. Ulike tokens der ute spiller en viktig rolle i web3-økosystemet. Disse tokenene representerer eierskap, rikdom, troverdighet og autoritet innen kryptovaluta. Den morsomme delen er at du også kan lage ditt kryptovaluta-token. 

Disse tokenene er smarte kontrakter som involverer ulike funksjoner for ulike handlinger som overføring, balansekontroll osv. Du kan lage din token ved å opprette en smart kontrakt for den. Likevel, for å sikre at tokenet ditt er trygt og knytte en følelse av tillit til det, er ERC 20 smart kontraktstandard som anbefales å følges for å lage fungible tokens, og ERC 721 er den smarte kontraktsstandarden som brukes til å lage ikke-fungible tokens (NFT).

ERC 20 og ERC 721 er allment aksepterte smarte kontraktsprotokoller for token-oppretting. De gir et trygt og pålitelig miljø for tokens. Og disse protokollene blir stadig bedre og blir stadig bedre. Et skritt i den retningen fører til opprettelsen av en ny ERC 1155 smart kontraktsprotokoll for tokens. La oss se hva det er.

1. Hva er ERC 1155?

Alle ERC-er, som 20 og 721, er bare standarder for å lage smarte kontrakter som passer til forskjellige omstendigheter for NFT-er. Vi har ERC 721, og fungible tokens som USDT og DAI følger ERC 20-standarder. ERC 1155 er en standard som involverer ERC 20 og ERC 721 funksjoner og egenskaper.

Anta at du vil lage et program der du lager flere varer. Du vil for eksempel lage et symbol kalt gull, et annet symbol kalt sølv og en konge, og logikken sier at den med mer gull og sølv vil være kongen. Det kan bare være én konge. Det er en enkel protokoll, men for å lage dette, må du distribuere 3 kontrakter bare for eiendeler, en for et gulltoken, en annen for sølv og en for kongen, som vil være ERC 721. Men hva om du bare kan distribuere en kontrakt som viser alle de forskjellige tokenene?

Dette er et slikt problem som ERC 1155 løser. Du trenger ikke å distribuere en kontrakt for hver av tokenene du vil ha på blokkjeden. Dette var et slikt ERC 1155-kontrakteksempel. Gjett hvor vi trenger denne typen system med flere eiendeler, noen fungible, noen ikke-fungible. Svaret er web3-spill. ERC 1155 gir Web3-spillutviklere skalerbarhet og jevn utvikling for transaksjoner i kjeden.

1.1 Token-ID-er i ERC 1155

Du må være klar over hvordan saldoen i forskjellige ERC 20 tokens kan sjekkes, du kan bare ringe balanceOf(adresse _eier) funksjon, og du kan se hvor mange tokens den adressen inneholder. Men ERC 1155 omhandler forskjellige tokens, så vi må gi forskjellige IDer til forskjellige tokens. Nesten hver funksjon relatert til tokens tar inn i minst to parametere tokenId (aktiva du ønsker å spørre om) og adressen du vil vite om.

La oss for eksempel si at kontrakten har 3 tokens, gull, sølv og konge. For å vite hvor mye gull en bestemt adresse har i den protokollen, kan du bruke funksjonen balanceOf(adresse _Eieren, uint256 _id) på smartkontrakten. Anta at tokenId for gull er spesifisert til å være 1. Da kan du ringe på balanseOf(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Revisjonsretningslinjer for smart kontrakt ERC 1155

ERC 1155 har eksistert en stund, og noen funksjoner er ikke tilgjengelige i den vanlige ERC 20- eller ERC 721-protokollen, som batchoverføring. Dessuten er ERC 1155 mindre utbredt i markedsområdet, noe som gjør dette området litt mindre utforsket for mange utviklere. QuillAudits deler viktig innsikt for protokollene som søker BUIDL på ERC 1155, slik at de kan bidra til å skape et tryggere web3-økosystem ved å beskytte seg selv. 

2.1 ERC 1155 mottakergrensesnitt

Når vår ERC 1155-kontrakt overfører eiendeler til en annen kontrakt, som vanligvis er et krav i web3-spillprotokollen, er det VIKTIG å ha ERC1155-mottakergrensesnittet i mottakskontrakten for vellykket transaksjon av tokens.

To funksjoner som kommer under ERC 1155 mottakergrensesnitt er: -

• onERC1155Received(operatør, fra, id, verdi, data)
• onERC1155BatchReceived(operatør, fra, ids, verdier, data)

Begge funksjonene har nesten lik funksjonalitet, den eneste forskjellen er at sistnevnte er når vi har å gjøre med mer enn én transaksjon om gangen, og dermed navnegruppen, er det en liten forskjell mellom parameterne og returverdiene. Men her skal vi bare snakke om onERC1155Mottatt. 

Denne funksjonen MÅ IKKE kalles utenfor en mynt- eller overføringsprosess. For å godta overføringen, må den returnere bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)) hvis overføringen er tillatt.

Ser på parameterne: -

1. operatør:- Adressen som startet overføringen (dvs. msg.sender) 
2. fra:- Adressen som tidligere eide tokenet
3. id:- IDen til tokenet som overføres 
4. verdi:- Antall tokens som overføres 
5. data:- Ytterligere data uten spesifisert format 

2.2 Ingen approve() funksjon?

Hvis du noen gang har jobbet med ERC 20 eller ERC 721, ville du ha kommet over approve()-funksjonen, som lar en adresse ta de godkjente tokenene fra eierens saldo. For eksempel, hvis A ønsker å godkjenne B for å ta 100 tokens av DAI, så kan A kalle på godkjenningsfunksjonen og si at B har rett til 100 DAI-tokens, og senere kan B gjøre en transaksjon med det beløpet.

Men ERC 1155 har ikke en godkjenne funksjon for et enkelt token. Vi har en setApprovalForAll(adresseoperatør, bool godkjent) funksjon, som kalles opp av eieren og tar inn en adresseparameter-operator, som er adressen til brukeren eller den vi ønsker å godkjenne våre tokens til. Så vi kan ikke ringe en godkjenne funksjon eller gi godkjenning for et enkelt token fra vår ERC 1155-liste over tokens, men i stedet vil all tokentilgang bli godkjent på en gang. Utviklingsteamet må være klar over dette. Hvis det ignoreres, kan dette føre til store tap og kompromittere protokollen.

2.3 Noen regelmessige kontroller

De to ovennevnte delene utforsket to av de unike ERC 1155-relaterte sjekkene. I denne delen vil vi gå gjennom noen regelmessige kontroller som ikke trenger en veldig dyp forklaring.

1. Vær oppmerksom på ID-ene: Hver ekstern funksjon eller grensesnitt som fungerer med ERC 1155 må ha token-ID-en spesifisert for å ta det som input.
2. Burn/Mint:- Hver gang disse funksjonene kalles, må de bare endre balansen og totalforsyningen for den angitte token-ID.
3. ERC 20-likhet: - Mange egenskaper er som ERC 20-tokenstandard. Å gå gjennom sikkerhetsretningslinjene for ERC 20 vil også hjelpe i denne saken.
4. Re-entrance:- Som diskutert sjekker ERC 1155 for støttet grensesnitt i overføringslogikken. Det kan derfor være ulike scenarier som kan resultere i sårbarhet ved gjeninntreden. Det anbefales å beholde ikke-reentrancy guard modifikatorer på gjeldende funksjoner.

3. konklusjon

Web3 økosystem ser kontinuerlig utvikling i vanlige standarder for å forbedre sikkerhet og funksjonalitet. ERC 1155 er et skritt i den retningen. Men når de nye standardene slippes, skaper det et kunnskapsgap som involverer ikke-så-svært-vanlige standarder i protokoller og kommer med en risiko for mindre prøveplass for sikkerhetstiltak. Det er da QuillAudits kommer inn i bildet med et team av eksperter. Vi takler, analyserer og finner forskjellige måter protokollen kan bli kompromittert og sikrer våre klienters protokoll med utrolige resultater. Besøk nettsiden vår og få Web3-prosjektet ditt sikret!

17 Visninger

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://blog.quillhash.com/2023/02/20/security-analysis-of-the-erc-1155-nft-smart-contract/