Säkerhetsanalys av ERC 1155 NFT Smart Contract

Säkerhetsanalys av ERC 1155 NFT Smart Contract

Tidsstämpel: 20 februari 2023 7:21
Säkerhetsanalys av ERC 1155 NFT Smart Contract PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.

Lästid: 5 minuter

Du måste ha hört talas om cryptocurrency-tokens. Olika tokens där ute spelar en viktig roll i web3-ekosystemet. Dessa tokens representerar ägande, rikedom, trovärdighet och auktoritet inom kryptovaluta. Det roliga är att du även kan göra din kryptovaluta token. 

Dessa tokens är smarta kontrakt som involverar olika funktioner för olika åtgärder som överföring, balanskontroll, etc. Du kan skapa din token genom att skapa ett smart kontrakt för den. Ändå, för att säkerställa att din token är säker och fästa en känsla av tillit till den, är ERC 20 smart avtalsstandard som rekommenderas att följas för att skapa fungibla tokens, och ERC 721 är den smarta kontraktsstandarden som används för att skapa icke-fungibla tokens (NFT).

ERC 20 och ERC 721 är allmänt accepterade smarta kontraktsprotokoll för att skapa token. De ger en säker och pålitlig miljö för tokens. Och dessa protokoll fortsätter att förbättras och blir bättre. Ett steg i den riktningen leder till skapandet av ett nytt ERC 1155 smart kontraktsprotokoll för tokens. Låt oss se vad det är.

1. Vad är ERC 1155?

Alla ERC, som 20 och 721, är bara standarder för att skapa smarta kontrakt som passar olika omständigheter för NFT. Vi har ERC 721, och fungibla tokens som USDT och DAI följer ERC 20-standarder. ERC 1155 är en standard som involverar ERC 20 och ERC 721 funktioner och egenskaper.

Anta att du vill skapa ett program där du skapar flera varor. Till exempel, du vill skapa en token som heter guld, en annan token som heter silver och en kung, och logiken säger att den med mer guld och silver kommer att bli kungen. Det kan bara finnas en kung. Det är ett enkelt protokoll, men för att skapa detta måste du distribuera 3 kontrakt bara för tillgångar, ett för en guldtoken, ett annat för silver och ett för kungen, vilket kommer att vara ERC 721. Men tänk om du bara kan distribuera ett kontrakt som listar alla dessa olika tokens?

Detta är ett sådant problem som ERC 1155 löser. Du behöver inte distribuera ett kontrakt för var och en av de tokens du vill ha på blockkedjan. Detta var ett sådant ERC 1155-kontraktsexempel. Gissa var vi behöver den här typen av system med flera tillgångar, vissa utbytbara, vissa icke-fungibla. Svaret är web3-spel. ERC 1155 ger Web3-spelutvecklare skalbarhet och smidig utveckling för transaktioner i kedjan.

1.1 Token-ID:n i ERC 1155

Du måste vara medveten om hur saldot i olika ERC 20-tokens kan kontrolleras, du kan bara ringa balanceOf(adress _ägare) funktion, och du kan se hur många tokens den adressen innehåller. Men ERC 1155 hanterar olika tokens, så vi måste tillhandahålla olika ID till olika tokens. Nästan varje funktion relaterade till tokens tar i minst två parametrar tokenId (tillgång du vill fråga om) och adressen som du vill veta om.

Låt oss till exempel säga att kontraktet har 3 polletter, guld, silver och kung. För att veta hur mycket guld en viss adress har i det protokollet kan du anropa funktionen balanceOf(adress _ägare, uint256 _id) på det smarta kontraktet. Anta att tokenId för guld är specificerat till 1. Då kan du ringa på balans Av(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Revisionsriktlinjer för smart kontrakt ERC 1155

ERC 1155 har funnits ett tag, och vissa funktioner är inte tillgängliga i det vanliga ERC 20- eller ERC 721-protokollet, som batchöverföring. Dessutom är ERC 1155 mindre utbredd på marknaden, vilket gör detta område lite mindre utforskat för många utvecklare. QuillAudits delar med sig av avgörande insikter för de protokoll som söker BUIDL på ERC 1155, så att de kan hjälpa till att skapa ett säkrare web3-ekosystem genom att skydda sig själva. 

2.1 ERC 1155-mottagargränssnitt

När vårt ERC 1155-kontrakt överför tillgångar till något annat kontrakt, vilket i allmänhet är ett krav i web3-spelprotokollet, är det VIKTIGT att ha ERC1155Receiver Interface i mottagningskontraktet för framgångsrik transaktion av tokens.

Två funktioner som ingår i ERC 1155-mottagarens gränssnitt är:

  • onERC1155Received(operatör, från, id, värde, data)
  • onERC1155BatchReceived(operatör, från, ids, värden, data)

Båda funktionerna har nästan liknande funktionalitet, den enda skillnaden är att den senare är när vi har att göra med mer än en transaktion åt gången, alltså namnpartiet, det finns en liten skillnad mellan parametrar och returvärden. Men här kommer vi bara att prata om onERC1155Recieved. 

Denna funktion FÅR INTE anropas utanför en mynt- eller överföringsprocess. För att acceptera överföringen måste den returnera bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)) om överföringen är tillåten.

Titta på parametrarna: -

  1. operatör:- Adressen som initierade överföringen (dvs. msg.sender) 
  2. från:- Adressen som tidigare ägde token
  3. id:- ID för token som överförs 
  4. värde:- Antalet tokens som överförs 
  5. data:- Ytterligare data utan specificerat format 

2.2 Ingen approve() funktion?

Om du någonsin arbetat med ERC 20 eller ERC 721, skulle du ha stött på approve()-funktionen, som tillåter någon adress att ta de godkända tokens från ägarens saldo. Till exempel, om A vill godkänna B att ta 100 tokens av DAI, då kan A anropa godkännandefunktionen och säga att B har rätt till 100 DAI-tokens, och senare kan B göra en transaktion med det beloppet.

Men ERC 1155 har inte en godkänna funktion för en enda token. Vi har en setApprovalForAll(adressoperatör, bool godkänd) funktion, som anropas av ägaren och tar in en adressparameteroperator, som är adressen till spendern eller den vi vill godkänna våra tokens till. Så vi kan inte ringa en godkänna funktion eller bevilja godkännande för en enskild token från vår ERC 1155-lista över tokens, men istället kommer all token-åtkomst att godkännas på en gång. Utvecklingsteamet måste vara medvetet om detta. Om det ignoreras kan detta leda till stora förluster och äventyra protokollet.

2.3 Vissa regelbundna kontroller

Ovanstående två avsnitt utforskade två av de unika ERC 1155-relaterade kontrollerna. I det här avsnittet kommer vi att gå igenom några regelbundna kontroller som inte behöver en särskilt djupgående förklaring.

  1. Tänk på ID:n: Varje extern funktion eller gränssnitt som fungerar med ERC 1155 måste ha ett token-ID specificerat för att ta det som indata.
  2. Burn/Mint:- Närhelst dessa funktioner anropas, får de bara ändra balansen och totalförsörjningen för det angivna token-ID.
  3. ERC 20 likhet: - Många egenskaper är som ERC 20 token standard. Att gå igenom säkerhetsriktlinjerna för ERC 20 kommer också att hjälpa i denna fråga.
  4. Återinträde:- Som diskuterats kontrollerar ERC 1155 efter gränssnitt som stöds i överföringslogiken. Det kan alltså finnas olika scenarier som kan resultera i sårbarhet vid återinträde. Det rekommenderas att behålla modifierare för icke-återinträde på de tillämpliga funktionerna.

3. Slutsats

Web3 ecosystem ser kontinuerlig utveckling av vanliga standarder för att förbättra säkerhet och funktionalitet. ERC 1155 är ett steg i den riktningen. Men när de nya standarderna släpps skapar det en kunskapslucka som involverar inte så mycket vanliga standarder i protokoll och kommer med en risk för mindre provutrymme för säkerhetsåtgärder. Det är då QuillAudits kommer in i bilden med ett team av experter. Vi tar itu med, analyserar och hittar olika sätt som protokollet kan äventyras och säkrar våra kunders protokoll med otroliga resultat. Besök vår hemsida och få ditt Web3-projekt säkrat!

17 Visningar

Tidsstämpel:

Mer från Pilbåt