@liwi 22 February 2022 more from that month

關於 ERC721Enumerable 的 tokenByIndex() / tokenOfOwnerByIndex() 的一些想法 細究 ERC721Enumerable 後覺得是蠻全面的深思熟慮的架構， 但對目前一般 NFT 的發行方式來說就有點畫蛇添足。 ERC721Enumerable 要支援三個介面函式： totalSupply() tokenByIndex() tokenOfOwnerByIndex() totalSupply() 的部分很好做，如果是序列發行且設定為不可變異的合約，直接回傳現在的 tokenID 序號也就搞定了。 tokenByIndex() 的部分乍看之下跟 tokenID 功能重複，但細想之後設計這個介面的人的想法應該是 "ID" 不見得等於一串數字（雖然 uint256 就是一串數字）。這個 ID 的意義應該要更近於 identifier，可以是 token 內容的 hash 等等。 也就是說，一般 NFT 合約裡基本上是把 tokenID 降級成 tokenIndex 在用。那也就不意外為什麼 tokenID ERC721 規格裡規劃用了 uint256 ，一個「一個一個數的話根本用不到的數量級」。（一般合約情境用 uint16 或 uint24 應該就遠遠足夠了。） 另一方面，如果要徹底運用 ERC721Enumerable 的完整架構，以 Smart Waifu 來說，或許可以把生成用的 SLP TokenID 作 keccak256 後設成 tokenID。 而一般的運用情形呢，如果是用 IPFS 的話或許可以嘗試把 CIDv1 設成 tokenID 來省瓦斯。 抓 NFT 內容時，用 index 去抓 id = ipfs-hash (in bytes32)。 tokenOfOwnerByIndex() 的話則是方便找出某個位址究竟擁有多少 token。介面規格沒有直接給串列長度，所以推測設計的概念是 "Enumerable"，從 0 開始 call，一直 call 到 execution reverted 為止。 Edit: 要查位址有多少個token用 ERC721 的 balanceOf() 就可以了 ERC721Enumerable 的原設計意義看起來應該是這樣。但目前看起來就是被很多 NFT 合約跟平台誤用了。說是誤用也不太對，因為論普遍支援性與擴充性來說平台的做法是對的，規格存在畢竟有其意義。 所以一般的 NFT 的折衷之道或許是可以在 tokenByIndex() 那邊動手腳。像我寫的一個合約，tokenID 從 1 開始向上跑，那其實 tokenIndex 就是 從 0 開始向上跑。 至於 tokenOfOwnerByIndex 看起來就沒辦法偷雞只能乖乖燒瓦斯拜佛了