Analiza bezpieczeństwa inteligentnej umowy ERC 1155 NFT

Czas czytania: 5 minuty

Na pewno słyszałeś o tokenach kryptowalut. Różne tokeny odgrywają istotną rolę w ekosystemie web3. Tokeny te reprezentują własność, bogactwo, wiarygodność i autorytet w kryptowalucie. Zabawne jest to, że możesz również stworzyć swój token kryptowaluty. 

Te tokeny to inteligentne kontrakty obejmujące różne funkcje dla różnych działań, takich jak przelew, sprawdzanie salda itp. Możesz stworzyć swój token, tworząc dla niego inteligentną umowę. Mimo to, aby upewnić się, że Twój token jest bezpieczny i wzbudzić w nim poczucie zaufania, ERC 20 jest najlepszym rozwiązaniem standard inteligentnego kontraktu zaleca się, aby stosować się do tworzenia tokenów zamiennych, a ERC 721 to standard inteligentnej umowy, który jest używany do tworzenia tokenów niezamiennych (NFT).

ERC 20 i ERC 721 to powszechnie akceptowane protokoły smart kontraktów do tworzenia tokenów. Zapewniają bezpieczne i godne zaufania środowisko dla tokenów. A te protokoły ciągle się poprawiają i stają się coraz lepsze. Krok w tym kierunku prowadzi do stworzenia nowego protokołu smart kontraktów ERC 1155 dla tokenów. Zobaczmy, co to jest.

1. Co to jest ERC 1155?

Wszystkie ERC, takie jak 20 i 721, to tylko standardy tworzenia inteligentnych kontraktów, które pasują do różnych okoliczności dla NFT. Mamy ERC 721, a wymienne tokeny, takie jak USDT i DAI, są zgodne ze standardami ERC 20. ERC 1155 to jeden standard obejmujący funkcje i właściwości ERC 20 i ERC 721.

Załóżmy, że chcesz stworzyć program, w którym tworzysz wiele towarów. Na przykład chcesz stworzyć token o nazwie gold, inny token o nazwie silver i jednego króla, a logika mówi, że królem będzie ten, który ma więcej złota i srebra. Król może być tylko jeden. Jest to prosty protokół, ale aby go utworzyć, będziesz musiał wdrożyć 3 kontrakty tylko dla aktywów, jeden dla złotego żetonu, drugi dla srebra i jeden dla króla, który będzie ERC 721. Ale co, jeśli możesz wdrożyć tylko jeden kontrakt wymieniający wszystkie te różne tokeny?

To jeden z takich problemów, który rozwiązuje ERC 1155. Nie musisz wdrażać umowy dla każdego z tokenów, które chcesz w łańcuchu bloków. To był jeden z takich przykładowych kontraktów ERC 1155. Zgadnij, gdzie potrzebujemy tego typu systemu z wieloma zasobami, niektóre zamienne, niektóre niezamienne. Odpowiedzią są gry web3. ERC 1155 umożliwia twórcom gier Web3 skalowalność i płynne tworzenie transakcji w łańcuchu.

1.1 Identyfikatory tokenów w ERC 1155

Musisz być świadomy tego, jak można sprawdzić saldo w różnych tokenach ERC 20, możesz po prostu sprawdzić balanceOf(adres _właściciel) funkcji i możesz uzyskać liczbę tokenów, które zawiera ten adres. Ale ERC 1155 dotyczy różnych tokenów, więc musimy podać różne identyfikatory różnym tokenom. Prawie każda funkcja związana z tokenami przyjmuje co najmniej dwa parametry tokenId(zasób, o który chcesz zapytać) oraz adres, o który chcesz wiedzieć.

Załóżmy na przykład, że kontrakt ma 3 żetony, złoty, srebrny i króla. Aby dowiedzieć się, ile złota ma dany adres w tym protokole, możesz wywołać funkcję balanceOf(adres _właściciel, uint256 _id) w inteligentnej umowie. Załóżmy, że tokenId dla złota ma wartość 1. Wtedy możesz zadzwonić dalej saldo(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Wytyczne audytu dla inteligentnej umowy ERC 1155

ERC 1155 istnieje już od jakiegoś czasu, a niektóre funkcje nie są dostępne w zwykłym protokole ERC 20 lub ERC 721, na przykład przesyłanie wsadowe. Ponadto ERC 1155 jest mniej rozpowszechniony na rynku, przez co ten obszar jest mniej eksplorowany przez wielu programistów. QuillAudits dzieli się kluczowymi spostrzeżeniami na temat protokołów, które chcą BUIDL na ERC 1155, dzięki czemu mogą pomóc w stworzeniu bezpieczniejszego ekosystemu Web3, zabezpieczając się. 

2.1 Interfejs odbiornika ERC 1155

Kiedy nasza umowa ERC 1155 przenosi aktywa do innej umowy, co jest ogólnie wymagane w protokole gry web3, WAŻNE jest posiadanie interfejsu odbiornika ERC1155 w umowie odbierającej, aby transakcja tokenów przebiegła pomyślnie.

Dwie funkcje objęte interfejsem odbiornika ERC 1155 to:

• onERC1155Received(operator, od, id, wartość, dane)
• onERC1155BatchReceived (operator, z, identyfikatory, wartości, dane)

Obie funkcje mają prawie podobną funkcjonalność, z tą różnicą, że ta ostatnia jest wtedy, gdy mamy do czynienia z więcej niż jedną transakcją na raz, stąd nazwa partii, istnieje niewielka różnica między parametrami a zwracanymi wartościami. Ale tutaj porozmawiamy tylko o nimERC1155Odebrano. 

Ta funkcja NIE MOŻE być wywoływana poza procesem mennicy lub transferu. Aby zaakceptować transfer, musi zwrócić bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)), jeśli transfer jest dozwolony.

Patrząc na parametry: -

1. operator:- Adres, który zainicjował transfer (np. msg.sender) 
2. from: - Adres, który wcześniej był właścicielem tokena
3. id: — Identyfikator przesyłanego tokena 
4. wartość: — liczba przesyłanych tokenów 
5. dane:- Dodatkowe dane bez określonego formatu 

2.2 Brak funkcji zatwierdzenia()?

Jeśli kiedykolwiek pracowałeś z ERC 20 lub ERC 721, natknąłbyś się na funkcję accept(), która pozwala niektórym adresom pobrać zatwierdzone tokeny z salda właściciela. Na przykład, jeśli A chce zatwierdzić B wzięcie 100 tokenów DAI, wtedy A może wywołać funkcję zatwierdzania, mówiąc, że B jest uprawniony do 100 tokenów DAI, a później B może wykonać transakcję z tą kwotą.

Ale ERC 1155 nie ma Zatwierdzać funkcja dla pojedynczego tokena. Mamy setApprovalForAll (operator adresu, bool zatwierdzony) funkcja, która jest wywoływana przez właściciela i pobiera operator parametru adresu, czyli adres wydającego lub tego, któremu chcemy zatwierdzić nasze tokeny. Nie możemy więc zadzwonić do Zatwierdzać lub udzielić zatwierdzenia dla pojedynczego tokena z naszej listy tokenów ERC 1155, ale zamiast tego cały dostęp do tokena zostanie zatwierdzony jednocześnie. Zespół programistów musi być tego świadomy. Jeśli zostanie to zignorowane, może to prowadzić do ogromnych strat i zagrozić protokołowi.

2.3 Niektóre regularne kontrole

Powyższe dwie sekcje dotyczyły dwóch unikalnych kontroli związanych z ERC 1155. W tej sekcji omówimy kilka regularnych kontroli, które nie wymagają bardzo szczegółowego wyjaśnienia.

1. Pamiętaj o identyfikatorach: - Każda zewnętrzna funkcja lub interfejs, który współpracuje z ERC 1155, musi mieć określony identyfikator tokena, aby traktować go jako dane wejściowe.
2. Burn/Mint: - Za każdym razem, gdy te funkcje są wywoływane, mogą zmieniać tylko saldo i totalSupply dla określonego identyfikatora tokena.
3. Podobieństwo do ERC 20: - Wiele właściwości przypomina standard tokena ERC 20. Pomocne w tej kwestii będzie również przejrzenie wytycznych bezpieczeństwa dla ERC 20.
4. Ponowne wejście: - Jak omówiono, ERC 1155 sprawdza obsługiwany interfejs w logice transferu. W związku z tym mogą wystąpić różne scenariusze, które mogą skutkować podatność na ponowne wejście. Zaleca się zachowanie modyfikatorów ochrony przed ponownym wejściem na odpowiednich funkcjach.

3. Wniosek

Ekosystem Web3 jest stale rozwijany w regularnych standardach w celu zwiększenia bezpieczeństwa i funkcjonalności. ERC 1155 to krok w tym kierunku. Ale kiedy pojawiają się nowe standardy, powstaje luka w wiedzy obejmująca niezbyt powszechne standardy w protokołach i wiąże się z ryzykiem mniejszej przestrzeni próbnej dla środków bezpieczeństwa. Wtedy do akcji wkracza QuillAudits z zespołem ekspertów. Zajmujemy się, analizujemy i znajdujemy różne sposoby naruszenia protokołu oraz zabezpieczamy protokół naszych klientów z niewiarygodnymi wynikami. Odwiedź naszą stronę internetową i zabezpiecz swój projekt Web3!

17 odwiedzajacy

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. Dostęp tutaj.
• Źródło: https://blog.quillhash.com/2023/02/20/security-analysis-of-the-erc-1155-nft-smart-contract/