@liwi 10 February 2022 more from that month

在想 NFT 發行平台合約的部分 / NFT 標準 NFT 標準的部分板友們提到了： - 用ERC-1155會不會比較適合? https://noise.cash/post/l34750gr - 上Oasis要支援ERC721Enumerable https://noise.cash/post/l347vm9k - 有可能會有ERC-721A嗎? 聽說可一次購買多組 https://noise.cash/post/l4x7w2rm （感謝噪咖們的建議與提醒） ERC-1155 在我的理解裡大略等同 ERC-20 + ERC-721 那一開始只是想做 NFT 所以就沒特別考慮 雖然我在猜想 ERC-1155 可能在使用上可以節省瓦斯費 那我現在有一些結合 ERC-20 的想法 所以說不定可以重新考慮（但原則上應該不需要） 這會再發另一篇說明 ERC721Enumerable 我在設計合約時也有注意到 但我不太知道為什麼這些資料需要用 state variables 直接存在鏈上 我的看法跟這則 reddit 很像： urnium_93: the only useability i can see is if there's an apocalypse and people wont be able to run off-chain servers to sync data and keep track of ownership using events and instead rely on on-chain data. https://www.reddit.com/r/ethdev/comments/qbsmz2/what_are_the_benefits_to_using_the/ 這則 reddit 串裡也提到社群當初的倡議 認為不應該把 Enumerable 設為預設： EnumerableSet and EnumerableMap heavily rely on sstore & sload, which are very expensive operations. At the same time, the Enumerable aspect can be tracked offchain using tools like thegraph. https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2511 我到目前為止還沒專門去研究瓦斯最佳化過 但如果有程式跟資料結構經驗的話就還蠻容易可以猜想什麼東西是比較耗資源的 就上面 reddit 所述，Enumerable 的瓦斯費 3倍於非 Enumerable。 （目前 frens 合約鑄造的瓦斯費大概在 0.0002X 左右的樣子） 回到 Oasis 對非 Enumerable 的支援上 技術上來說應該也只是要不要做 另外這個支援指的應該是網站前端的展示 合約的部分就我了解並沒有這樣的需求 那麼 ERC-721A 呢？ 這看起來是個很新的規格 https://github.com/chiru-labs/ERC721A 官方的說法是多重鑄造時的瓦斯費幾乎等於單一鑄造 官方比較的對象是 ERC721Enumerable 單鑄時比 ERC721Enumerable 省約一半 鑄越多省越多 就 frens 平台合約來說我懶人覺得 ERC721 大概還是不錯 Oasis 陳列支援問題應該可以用替代方式來解決