Sikkerhedsanalyse af ERC 1155 NFT Smart Contract

Læsetid: 5 minutter

Du må have hørt om cryptocurrency tokens. Forskellige tokens derude spiller en afgørende rolle i web3-økosystemet. Disse tokens repræsenterer ejerskab, rigdom, troværdighed og autoritet inden for kryptovaluta. Det sjove er, at du også kan lave dit kryptovaluta-token. 

Disse tokens er smarte kontrakter, der involverer forskellige funktioner til forskellige handlinger som overførsel, balancekontrol osv. Du kan lave dit token ved at oprette en smart kontrakt for det. Alligevel, for at sikre, at dit token er sikkert og knytte en følelse af tillid til det, er ERC 20 smart kontraktstandard det anbefales at følge for at skabe fungible tokens, og ERC 721 er den smarte kontraktstandard, som bruges til at skabe ikke-fungible tokens (NFT'er).

ERC 20 og ERC 721 er bredt accepterede smarte kontraktprotokoller til token-oprettelse. De giver et sikkert og troværdigt miljø for tokens. Og disse protokoller bliver ved med at blive bedre og bliver bedre. Et skridt i den retning fører til oprettelsen af ​​en ny ERC 1155 smart kontraktprotokol for tokens. Lad os se, hvad det er.

1. Hvad er ERC 1155?

Alle ERC'er, som 20 og 721, er kun standarder for at skabe smarte kontrakter, der passer til forskellige omstændigheder for NFT'er. Vi har ERC 721, og fungible tokens som USDT og DAI følger ERC 20-standarderne. ERC 1155 er en standard, der involverer ERC 20 og ERC 721 funktioner og egenskaber.

Antag, at du vil oprette et program, hvor du opretter flere varer. For eksempel vil du oprette et token ved navn guld, et andet token ved navn sølv og en konge, og logikken siger, at den med mere guld og sølv bliver kongen. Der kan kun være én konge. Det er en simpel protokol, men for at oprette dette skal du implementere 3 kontrakter kun for aktiver, en for et guldbrik, en anden for sølv og en for kongen, som vil være ERC 721. Men hvad nu hvis du bare kan implementere en kontrakt med alle de forskellige tokens?

Dette er et sådant problem, som ERC 1155 løser. Du behøver ikke at implementere en kontrakt for hver af de tokens, du ønsker på blockchain. Dette var et sådant ERC 1155 kontrakteksempel. Gæt hvor vi har brug for denne type system med flere aktiver, nogle fungible, nogle ikke-fungible. Svaret er web3-spil. ERC 1155 giver Web3-spiludviklere skalerbarhed og problemfri udvikling til on-chain-transaktioner.

1.1 Token-id'er i ERC 1155

Du skal være opmærksom på hvordan saldoen i forskellige ERC 20 tokens kan tjekkes, du kan bare ringe balanceOf(adresse _ejer) funktion, og du kan se, hvor mange tokens den adresse indeholder. Men ERC 1155 omhandler forskellige tokens, så vi skal give forskellige ID'er til forskellige tokens. Næsten hver funktion, der er relateret til tokens, tager mindst to parametre ind i tokenId (aktivet, du vil forespørge om) og adressen, som du ønsker at vide om.

Lad os f.eks. sige, at kontrakten har 3 tokens, guld, sølv og konge. For at vide, hvor meget guld en bestemt adresse har i den protokol, kan du bruge funktionen balanceOf(adresse _ejer, uint256 _id) på den smarte kontrakt. Antag, at tokenId for guld er angivet til at være 1. Så kan du kalde på balanceOf(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Revisionsretningslinjer for smart kontrakt ERC 1155

ERC 1155 har eksisteret i nogen tid, og nogle funktioner er ikke tilgængelige i den almindelige ERC 20- eller ERC 721-protokol, såsom batchoverførsel. Desuden er ERC 1155 mindre udbredt på markedet, hvilket gør dette område lidt mindre udforsket for mange udviklere. QuillAudits deler afgørende indsigt for de protokoller, der søger BUIDL på ERC 1155, så de kan hjælpe med at skabe et sikrere web3-økosystem ved at beskytte sig selv. 

2.1 ERC 1155 modtagergrænseflade

Når vores ERC 1155-kontrakt overfører aktiver til en anden kontrakt, hvilket generelt er et krav i web3-spilprotokollen, er det VIGTIGT at have ERC1155Receiver Interface i modtagekontrakten for vellykket transaktion af tokens.

To funktioner, der kommer under ERC 1155-modtagergrænsefladen er: -

• onERC1155Received(operatør, fra, id, værdi, data)
• onERC1155BatchReceived(operatør, fra, id'er, værdier, data)

Begge funktioner har næsten ens funktionalitet, den eneste forskel er, at sidstnævnte er, når vi har at gøre med mere end én transaktion ad gangen, og dermed navnebatchen, er der en lille forskel mellem parametrene og returværdierne. Men her vil vi kun tale om onERC1155Recieved. 

Denne funktion MÅ IKKE kaldes uden for en mint- eller overførselsproces. For at acceptere overførslen skal den returnere bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)), hvis overførslen er tilladt.

Ser man på parametrene: -

1. operatør:- Den adresse, der startede overførslen (dvs. msg.sender) 
2. fra:- Adressen, som tidligere ejede tokenet
3. id:- ID'et for det token, der overføres 
4. værdi:- Antallet af tokens, der overføres 
5. data:- Yderligere data uden specificeret format 

2.2 Ingen approve() funktion?

Hvis du nogensinde har arbejdet med ERC 20 eller ERC 721, ville du have stødt på approve()-funktionen, som tillader en adresse at tage de godkendte tokens fra ejerens saldo. For eksempel, hvis A ønsker at godkende B til at tage 100 tokens DAI, så kan A kalde på godkendelsesfunktionen og sige, at B har ret til 100 DAI tokens, og senere kan B foretage en transaktion med det beløb.

Men ERC 1155 har ikke en Godkend funktion for et enkelt token. Vi har en setApprovalForAll(adresseoperatør, bool godkendt) funktion, som kaldes af ejeren og tager en adresseparameteroperator ind, som er adressen på brugeren eller den, vi ønsker at godkende vores tokens til. Så vi kan ikke ringe til en Godkend funktion eller give godkendelse til et enkelt token fra vores ERC 1155-liste over tokens, men i stedet vil al tokenadgang blive godkendt på én gang. Udviklingsteamet skal være opmærksomme på dette. Hvis det ignoreres, kan dette føre til massive tab og kompromittere protokollen.

2.3 Nogle regelmæssige kontroller

Ovenstående to afsnit udforskede to af de unikke ERC 1155-relaterede kontroller. I dette afsnit vil vi gennemgå nogle regelmæssige kontroller, som ikke behøver en særlig dyb forklaring.

1. Vær opmærksom på ID'erne:- Hver ekstern funktion eller grænseflade, der fungerer med ERC 1155, skal have token-id'et angivet for at tage det som input.
2. Burn/Mint:- Når disse funktioner kaldes, må de kun ændre balancen og totalforsyningen for det angivne token-id.
3. ERC 20 lighed: - Mange egenskaber er som ERC 20 token standard. At gennemgå sikkerhedsretningslinjerne for ERC 20 vil også hjælpe i denne sag.
4. Genindgang:- Som diskuteret kontrollerer ERC 1155 for understøttet grænseflade i overførselslogikken. Der kan således være forskellige scenarier, som kan resultere i sårbarhed ved genindgang. Det tilrådes at beholde modifikatorer til ikke-tilbagekomstbeskyttelse på de relevante funktioner.

3. konklusion

Web3 økosystem ser løbende udvikling i almindelige standarder for at forbedre sikkerhed og funktionalitet. ERC 1155 er et skridt i den retning. Men når de nye standarder frigives, skaber det et vidensgab, der involverer ikke så meget almindelige standarder i protokoller og kommer med en risiko for mindre prøveplads til sikkerhedsforanstaltninger. Det er her, QuillAudits kommer ind i billedet med et team af eksperter. Vi tackler, analyserer og finder forskellige måder, hvorpå protokollen kan blive kompromitteret og sikrer vores kunders protokol med utrolige resultater. Besøg vores hjemmeside og få dit Web3-projekt sikret!

17 Views

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://blog.quillhash.com/2023/02/20/security-analysis-of-the-erc-1155-nft-smart-contract/