可列舉擴充

什麼是可列舉擴充？

可列舉擴充是 ERC-721 非同質化代幣標準中的選用部分，可讓智能合約和加密貨幣應用程式透過鏈上索引查詢，探索 NFT 代幣 ID。

此擴充通常以介面名稱

或實作名稱 識別。

官方 ERC-721 規範將此擴充定義為一種合約可用來公開所有有效 NFT 清單，以及各地址所持有代幣 ID 的方式。

此擴充新增了 3 個函式：

、 和 。

這些函式是 ERC-721 核心所有權與轉移介面的補充。

它們不會取代

、、 或 等函式。

可列舉擴充為選用功能，因此 NFT 合約即使不支援此功能，仍可完全符合 ERC-721 標準。

為什麼稱為「可列舉」？

列舉一個集合，代表透過索引或其他有序方式逐一識別其中的成員。

ERC-721 核心介面可以告訴應用程式已知代幣 ID 的持有人是誰。

它也可以告訴應用程式某個地址持有多少 NFT。

不過，核心介面沒有提供直接的鏈上函式，可用來找出所有現存代幣 ID，或特定持有人所持有的所有代幣 ID。

可列舉擴充透過新增全域集合和各持有人持有項目的索引存取功能，填補了這項缺口。

應用程式可以從索引 0 開始，持續查詢更高的索引，直到達到相關的供應量或持有人餘額。

什麼是可列舉擴充介面 ID？

ERC-721 可列舉擴充的 ERC-165 介面 ID 為

。

相容的合約在以此值呼叫其

函式時，應回傳 。

ERC-165 介面偵測標準可讓應用程式詢問智能合約宣稱支援哪些介面。

ERC-721 核心介面有獨立的介面 ID，因此應用程式可以分別測試核心介面與可列舉擴充的支援情況。

實作可列舉擴充的合約也必須實作 ERC-721 核心介面。

介面偵測回應為肯定，有助於檢查相容性，但不能證明實作正確、安全或可信。

可列舉擴充新增的函式

可列舉擴充只新增 3 個公開查詢函式。

函式會回傳合約目前追蹤的有效 NFT 數量。

函式會從合約的全域代幣清單中回傳一個代幣 ID。

函式會從某位持有人目前持有的代幣中回傳一個代幣 ID。

標準介面中的這 3 個函式都是唯讀的 view 函式。

此擴充不會新增轉移、核准、鑄造、銷毀、metadata 或版稅函式。

totalSupply 函式

函式會回傳目前擁有者不是零地址的有效 NFT 數量。

它回報的是目前的流通供應量，而非可能達到的最大供應量。

例如，某個合約可能回報總供應量為 8,000，但仍保留日後鑄造更多 NFT 的權限。

若 NFT 被銷毀並不再具有有效所有權，回報的總供應量通常會減少。

因此，

不一定等於曾經鑄造過的 NFT 數量。

它也無法證明該系列設有永久供應上限。

使用者必須檢查鑄造邏輯與特殊權限，才能確認稀缺性相關宣稱。

tokenByIndex 函式

函式會回傳合約全域列舉清單中指定位置的代幣 ID。

索引從 0 開始。

有效索引必須小於

回傳的數值。

若總供應量為 100，有效索引為 0 至 99。

使用索引 100 或更大的數字查詢必須失敗。

回傳的代幣 ID 不一定等於索引。

例如，索引 0 可能回傳代幣 ID 500，而索引 1 可能回傳代幣 ID 12。

應用程式絕不可因為列舉索引是連續的，就假設代幣 ID 也是連續的。

tokenOfOwnerByIndex 函式

函式會回傳指定地址所持有的一個代幣 ID。

索引從 0 開始，且必須小於該持有人

函式的回傳值。

若某地址持有 3 個 NFT，其有效持有人索引為 0、1 和 2。

索引超出持有人目前餘額範圍時，函式必須失敗。

提供的持有人若為零地址，函式也必須失敗。

此函式讓鏈上和鏈下應用程式無須搜尋所有可能的代幣 ID，即可列出某地址持有的 NFT。

3 個函式如何搭配運作

應用程式可以呼叫

，了解目前存在多少有效 NFT。

接著，它可以從索引 0 到供應量減 1，逐一呼叫

。

對每個回傳的代幣 ID，應用程式都可以呼叫

，找出目前的持有人。

若要列出某地址持有的代幣，應用程式可以呼叫

，再針對每個有效持有人索引查詢 。

這套流程讓應用程式可透過標準化的鏈上函式探索代幣。

大型系列仍可能需要許多 RPC 呼叫，因此正式環境中的應用程式通常會使用分頁、批次處理、快取或事件索引。

列舉順序不受保證

ERC-721 規範沒有規定

或 必須採用特定排序方式。

回傳順序不必依照代幣 ID、鑄造時間、轉移時間、稀有度、metadata 或持有時間排列。

當另一個代幣被轉移或銷毀時，合約可能會變更某個代幣的位置。

應用程式不得將列舉索引視為永久識別碼。

代幣 ID 是合約中的穩定識別碼，而索引僅代表目前的查詢位置。

若介面需要排序結果，應在鏈下依照自己的規則排序回傳的代幣 ID。

Swap-and-Pop 列舉方式

一種常見的實作方式是使用稱為 swap-and-pop 的技術，從陣列中有效率地移除代幣 ID。

移除代幣時，實作會將最後一個代幣放到被移除代幣原本所在的陣列位置。

接著刪除陣列最後一個項目。

這種方式不必移動後續所有代幣，因此能讓移除作業維持相對低的複雜度。

不過，這會改變其餘代幣 ID 的順序。

目前的 OpenZeppelin ERC721Enumerable 實作會在全域索引和持有人專屬索引中使用此方法。

因此，若長時間列舉期間發生所有權變更，應用程式應重新開始分頁，或仔細比對並同步結果。

全系列列舉範例

假設某個 ERC-721 合約回報總供應量為 4。

應用程式以索引 0、1、2 和 3 呼叫

。

合約回傳的代幣 ID 分別是 18、42、7 和 105。

即使代幣 ID 並非連續，應用程式現在仍能得知所有有效代幣 ID。

應用程式可以針對每個 ID 呼叫

和 ，以顯示所有權與 metadata。

若代幣 ID 42 之後被銷毀，全域列舉可能會回傳 18、105 和 7，因為實作可能會將最後一個項目移至被移除的位置。

這種變更符合標準，因為標準並未保證列舉順序。

持有人列舉範例

假設 Alice 在可列舉 NFT 合約中持有代幣 ID 9、30 和 88。

合約的

函式會回傳 Alice 地址的餘額為 3。

應用程式透過

查詢持有人索引 0、1 和 2。

合約會回傳 Alice 持有的 3 個代幣 ID。

接著，Alice 將代幣 ID 30 轉給 Bob。

Alice 的餘額降至 2，她剩餘代幣 ID 的索引順序也可能改變。

應用程式在重新列舉持有人代幣前，應先讀取更新後的餘額。

可列舉擴充與 ERC-721 核心標準的比較

ERC-721 核心標準提供所有權、轉移、核准、事件和安全接收者檢查功能。

它可以確認已知代幣 ID 是否存在，以及由誰持有。

但它沒有提供標準化的鏈上清單，列出所有代幣 ID。

可列舉擴充新增了這項探索功能。

沒有列舉功能的系列仍可正常轉移 NFT，並與相容 ERC-721 的錢包搭配使用。

不支援列舉不代表 NFT 無效或不符合標準。

若要廣泛相容 ERC-721，應用程式必須同時支援可列舉與不可列舉的系列。

可列舉擴充與 Metadata 擴充的比較

可列舉擴充用於識別現存代幣 ID 和持有人所持有的代幣。

Metadata 擴充則提供系列名稱、符號和代幣 URI。

列舉功能不會描述 NFT 相關的圖像、屬性、標題或外部內容。

支援 metadata 也不代表可以取得完整代幣清單。

合約可以實作其中一種擴充、同時實作兩種擴充，或兩種都不實作，但仍符合 ERC-721 核心行為。

應用程式應分別檢查各介面。

可列舉擴充與僅有 totalSupply 的比較

有些 NFT 合約會新增自訂的

函式，但沒有實作完整的可列舉擴充。

函式名稱相同，不代表合約支援

或 。

自訂供應量函式的意義也可能不同於 ERC-721 列舉標準中的定義。

它可能回報曾經鑄造的數量、下一個代幣 ID、系列最大數量，或其他專案自行定義的數值。

應用程式應使用 ERC-165 測試完整的可列舉介面，而非只依賴單一函式選擇器。

為什麼可列舉擴充會增加 Gas 費

列舉功能需要合約維護額外的儲存結構。

常見的實作方式會儲存一個包含所有現存代幣 ID 的陣列。

合約也會儲存各持有人的索引代幣清單，以及記錄代幣位置的對應資料。

鑄造時，必須將新代幣加入全域清單和持有人清單。

轉移時，必須將代幣從前一位持有人的清單中移除，再加入新持有人的清單。

銷毀時，必須從持有人清單和全域清單中移除代幣。

這些額外的儲存寫入會提高狀態變更交易的 Gas 費。

目前的 ERC-721 實作指南指出，此擴充通常會被省略，因為它會帶來相當可觀的 Gas 額外開銷。

列舉查詢是免費的嗎？

使用者可以透過 RPC 端點呼叫 view 函式，而無須提交區塊鏈交易。

在這種情況下，節點會在本機模擬讀取，因此不需要支付鏈上 Gas 費。

不過，節點仍須進行運算，也可能設有限流或請求限制。

若另一個智能合約在交易期間呼叫列舉函式，該運算會消耗交易 Gas。

在鏈上以迴圈查詢數百或數千個代幣索引，可能會變得過於昂貴而無法完成。

開發者不應將鏈下免 Gas 讀取誤認為鏈上運算不受限制。

迴圈與區塊 Gas 上限

智能合約應避免在狀態變更函式中，逐一迴圈處理系列內所有 NFT，或不受限制地址持有的所有 NFT。

迴圈次數可能隨時間增加，直到交易超過區塊 Gas 上限。

Solidity 安全文件警告，依賴儲存資料的迴圈最終可能導致合約操作無法完成。

透過鏈下呼叫的 view 函式不會產生相同的交易費用，但仍可能造成 RPC 服務供應商負載過重。

對於大型資料集，應用程式應採用有範圍限制的分頁、個別索引查詢或鏈下索引。

以鏈下事件索引作為替代方案

每個符合 ERC-721 標準的合約，在 NFT 被鑄造、轉移或銷毀時都會發出

事件。

鏈下索引器可以從合約部署區塊開始處理這些事件，重建目前的所有權資訊。

鑄造通常會以從零地址轉出的事件表示。

銷毀通常會以轉入零地址的事件表示。

一般轉移則會在兩個非零地址之間轉移所有權。

事件索引可避免鏈上列舉所需的額外儲存寫入。

對大型系列來說，事件索引也能更有效率地支援搜尋、排序、篩選和分頁。

取捨之處在於，使用者必須信任索引系統或自行營運該系統，並確保系統持續同步。

可列舉擴充與事件索引的比較

鏈上列舉可讓智能合約直接標準化存取代幣索引。

事件索引則能提供功能更豐富、擴充性更高的鏈下探索方式。

若另一個智能合約必須在不依賴外部資料庫的情況下驗證或選取代幣 ID，列舉功能就很有用。

對錢包介面、系列頁面、分析工具和歷史搜尋而言，事件索引通常更實用。

專案可以同時支援這兩種方式。

最佳選擇取決於鏈上可探索性帶來的價值，是否足以抵銷每次鑄造、轉移和銷毀時增加的 Gas 費。

列舉功能有提供分頁嗎？

此擴充未定義可一次回傳一頁代幣 ID 的函式。

它會針對每次索引查詢提供一個代幣 ID。

鏈下應用程式可以透過請求有限範圍的索引，自行建立分頁功能。

例如，第一頁可以查詢索引 0 至 49，第二頁則查詢索引 50 至 99。

應用程式在翻頁時，必須考量供應量和順序可能發生變化。

轉移或銷毀可能會讓代幣在索引之間移動，導致長時間執行的分頁流程漏掉或重複讀取某個 ID。

若 RPC 系統支援歷史區塊查詢，使用固定區塊高度的資料可提供較一致的快照。

列舉功能會列出所有持有人嗎？

此擴充會列出全域代幣 ID，以及已知持有人持有的代幣 ID。

它沒有提供回傳所有唯一持有人地址的函式。

應用程式可以呼叫每個代幣 ID 的

，或處理轉移事件，以取得持有人資訊。

同一位持有人可能會重複出現，因為一個地址可以持有多個 NFT。

因此，建立不重複的持有人清單通常屬於鏈下索引工作。

列舉功能能證明代幣真實性嗎？

不能。列舉功能只會回報特定智能合約追蹤的代幣 ID。

任何人都可以部署可列舉的 ERC-721 合約，並複製其他合約的名稱、圖像、符號或 metadata。

區塊鏈網路和完整合約地址仍是 NFT 身分的重要組成部分。

可列舉介面正確，不代表發行方擁有作品、控制所宣稱的資產，或具有誠信。

使用者應透過權威的專案資訊確認合約，並自行檢查其權限。

totalSupply 能證明稀缺性嗎？

目前的供應量不代表永久最大供應量已確定。

合約可能包含公開鑄造函式、管理員鑄造角色、跨鏈橋鑄造系統或升級權限。

目前沒有持有人的代幣 ID，日後也可能仍可鑄造。

可升級合約可能在部署後變更供應規則。

使用者在相信稀缺性宣稱之前，應檢查程式碼與存取控制機制。

列舉功能讓目前供應量更容易查詢，但不會強制執行經濟承諾。

鑄造與列舉

鑄造新的 NFT 時，可列舉實作必須將代幣 ID 加入全域索引和首位持有人的索引。

總供應量隨之增加 1。

依照實作方式，代幣 ID 可以出現在任何有效的全域索引位置。

採用連續鑄造規則，不代表列舉索引必須持續等於代幣 ID。

自訂鑄造邏輯必須一致地更新所有必要的列舉結構。

若更新不完整，餘額、所有權紀錄、總供應量和列舉結果可能會彼此不一致。

轉移與列舉

一般轉移通常不會改變總供應量。

代幣 ID 會從前一位持有人的列舉清單中移除，並加入接收者的清單。

全域代幣清單通常會繼續包含相同的代幣 ID。

移除過程可能會改變持有人專屬索引中的位置。

自我轉移需要謹慎處理，因為傳送者和接收者是同一個地址。

經過審查的實作會處理此情況，避免錯誤移除或重複加入代幣。

銷毀與列舉

銷毀會移除代幣的有效 ERC-721 所有權。

可列舉實作會將被銷毀的代幣 ID 從持有人清單和全域代幣清單中移除。

總供應量會減少。

不應再使用該代幣原本的全域索引和持有人索引。

其他代幣可能會透過 swap-and-pop 移至這些位置。

若歷史應用程式需要記錄已銷毀的 NFT，應使用事件，而非目前的列舉結果。

批次鑄造相容性

有些 ERC-721 實作支援在合約建構期間進行壓縮或連續批次鑄造。

這類系統可能會在不透過一般列舉更新邏輯逐一記錄代幣的情況下計算所有權。

目前的 OpenZeppelin 實作警告，其連續鑄造擴充會與

衝突，不應同時使用。

其目前的可列舉實作也會拒絕不支援的批次餘額更新路徑。

開發者不應只因為各擴充單獨運作正常，就將它們組合使用。

必須一併檢查繼承、儲存、事件、餘額和更新 hook 的行為。

列舉與可升級合約

若治理系統允許，可升級 NFT 合約在部署後新增或修改邏輯。

在已存在許多 NFT 後新增列舉功能，需要特別謹慎。

即使核心合約已追蹤數千個代幣，新的列舉儲存資料仍可能是空的。

可能需要透過遷移流程填入全域索引和持有人專屬索引。

大型鏈上遷移迴圈可能超過 Gas 上限。

儲存配置錯誤也可能損壞既有的所有權或核准資料。

升級管理員應使用經測試的遷移程序、有範圍限制的交易，以及獨立安全審查。

列舉與自訂 balanceOf 邏輯

持有人列舉仰賴正確的 ERC-721 餘額資訊。

若擴充透過自訂或壓縮方式計算

，可能會與已儲存的持有人索引衝突。

目前的實作指南特別警告，使用自訂餘額邏輯的擴充可能與列舉功能不相容。

開發者必須確認每次鑄造、轉移和銷毀都會透過相容的程式路徑更新所有權數量和索引。

若合約回報持有人餘額為 5，但只儲存 4 個索引代幣 ID，合約內部資料便不一致。

整合應用程式的安全風險

應用程式在呼叫擴充函式前，應先確認合約支援列舉功能。

應用程式應處理索引超出範圍的錯誤，不應假設先前查到的索引仍然有效。

應用程式不應依賴列舉順序進行稀有度、優先順序或財務計算。

若分頁期間狀態發生變化，應用程式應防範結果重複或遺漏。

應用程式也應確認每個回傳的代幣 ID 都屬於預期的合約和網路。

若涉及高價值決策，應用程式可能需要一致的區塊快照和適當的最終確認層級。

RPC 與資料一致性

依網路與請求設定，RPC 端點可能會回傳來自近期、安全、已完成最終確認或歷史區塊的列舉資料。

若兩次呼叫使用不同區塊高度，供應量或持有人清單可能會不同。

剛轉移的 NFT 可能會在尚未同步的資料來源中顯示為由不同持有人持有。

若一致性很重要，應用程式在多次呼叫列舉時應記錄所使用的區塊編號。

關鍵系統可以比對多個節點，或自行營運經獨立驗證的節點。

列舉功能可降低對特定系列 API 的依賴，但無法消除所有 RPC 信任相關考量。

可列舉擴充的優點

此擴充提供標準化方式，讓應用程式探索所有目前的代幣 ID。

它讓另一個智能合約無須外部索引器，就能查詢持有人的 NFT。

它提供標準化的目前供應量函式。

它可以簡化小型系列、鏈上遊戲、會員系統，以及需要直接選取代幣的應用程式。

即使專案網站或私人資料庫消失，它也能提供基本 NFT 庫存查詢功能。

可列舉擴充的限制

此擴充會增加鑄造、轉移和銷毀的 Gas 費。

它不保證代幣順序固定。

它沒有內建分頁、排序、篩選或持有人列舉功能。

它回報目前的代幣，而非完整的歷史紀錄。

它可能與壓縮批次鑄造或自訂餘額系統不相容。

大型鏈上迴圈仍受交易 Gas 限制。

它也不提供 metadata、版稅、價格、真實性或供應上限保證。

專案何時應使用列舉功能？

若智能合約必須直接在鏈上探索代幣 ID，專案可能會受益於列舉功能。

若系列規模較小，且可以接受額外的轉移成本，使用列舉也可能合理。

若遊戲合約邏輯必須依索引選取玩家的某個 NFT，便可使用列舉功能。

若會員合約中的鏈上流程需要檢查持有人目前的會員代幣，也可使用此功能。

專案仍應限制迴圈範圍，並考量較簡單的 mapping 或應用程式專屬索引是否更有效率。

專案何時可能避免使用列舉功能？

大型 NFT 系列可能會避免使用列舉，以降低每次鑄造、轉移和銷毀的成本。

若所有探索和搜尋功能都已仰賴鏈下事件索引器，專案也可能選擇不使用列舉。

壓縮批次鑄造系統可能採用無法有效搭配標準列舉儲存的所有權模型。

若專案從未需要在鏈上列出代幣，可能不值得為永久鏈上索引支付額外費用。

應根據實際應用需求做出決定，而非假設每個選用擴充都是必要的。

開發者應如何實作此擴充

開發者應採用持續維護且經過審查的 ERC-721 可列舉實作。

他們應確認

會回報 。

每條鑄造、轉移和銷毀路徑都必須正確更新全域和持有人專屬列舉資料。

必須檢查自訂擴充是否與所有權、餘額、批次鑄造、包裝、暫停和升級功能衝突。

測試應涵蓋第一個與最後一個索引、超出範圍的索引、自我轉移、銷毀、允許時的重新鑄造，以及重複的所有權變更。

不變量測試應確認

等於全域可列舉代幣的數量。

測試也應確認各持有人的可列舉代幣數量等於

的回傳值。

使用者如何檢查是否支援列舉

第一步是確認 NFT 合約地址和區塊鏈網路。

第二步是以

呼叫 。

第三步是確認合約也支援 ERC-721 核心介面。

第四步是將

與少量有效索引的查詢結果進行比對。

第五步是將持有人的

結果與持有人列舉回傳的代幣 ID 進行比對。

這些檢查可以找出明顯的不一致，但不能取代完整的合約審查。

可列舉擴充常見錯誤

一個常見錯誤是以為每個 ERC-721 合約都支援列舉功能。

另一個錯誤是將列舉索引視為永久代幣 ID。

第三個錯誤是以為代幣 ID 會依數字或鑄造順序排列。

第四個錯誤是將

視為永久供應上限。

第五個錯誤是在狀態變更交易中，對不受限制的系列進行迴圈處理。

第六個錯誤是忽略分頁期間順序可能發生變化。

第七個錯誤是以為自訂的

函式就能證明合約支援完整擴充。

第八個錯誤是將不相容的批次鑄造與列舉實作組合使用。

第九個錯誤是在可升級系列中新增列舉功能，卻沒有遷移先前的代幣。

第十個錯誤是將可列舉介面支援視為 NFT 系列真實或具有價值的證明。

常見問題

加密貨幣中的可列舉擴充是什麼意思？

通常是指 ERC-721 的選用擴充，可讓應用程式列出目前所有 NFT 代幣 ID，以及指定地址持有的代幣 ID。

ERC-721 是否要求支援可列舉擴充？

不需要。NFT 合約即使不支援列舉，仍可符合 ERC-721 核心標準。

可列舉擴充的介面 ID 是什麼？

ERC-165 介面 ID 為

。

此擴充新增了哪些函式？

它新增

、 和 。

totalSupply 會回傳什麼？

它會回傳合約目前追蹤的有效 NFT 數量。

totalSupply 會顯示可能的最大供應量嗎？

不會。它回報目前供應量，無法證明未來不可能再鑄造代幣。

tokenByIndex 會回傳什麼？

它會回傳指定全域列舉索引所對應的代幣 ID。

tokenOfOwnerByIndex 會回傳什麼？

它會回傳指定地址在指定持有人索引位置所持有的一個代幣 ID。

列舉索引從 0 開始嗎？

是。有效索引從 0 開始，並在相關供應量或餘額少 1 的位置結束。

列舉索引和代幣 ID 相同嗎？

不同。索引是暫時的清單位置，代幣 ID 則是合約內識別 NFT 的 ID。

回傳的代幣 ID 會依數字順序排列嗎？

不會。標準未要求特定的列舉順序。

列舉順序可能改變嗎？

可能。轉移和銷毀可能改變索引位置，尤其是使用 swap-and-pop 移除方式的實作。

銷毀 NFT 會降低 totalSupply 嗎？

會。正確實作的可列舉合約會移除被銷毀的 NFT，並降低目前總供應量。

轉移 NFT 會改變 totalSupply 嗎？

不會。一般轉移會改變持有人列舉資料，但不會改變現存 NFT 數量。

為什麼此擴充成本較高？

因為合約在鑄造、轉移和銷毀時，必須額外寫入儲存資料以維護全域和持有人專屬代幣索引。

列舉呼叫免費嗎？

鏈下 RPC 讀取不需要支付鏈上 Gas 費，但交易期間發生的智能合約呼叫會消耗 Gas。

合約可以迴圈處理每個可列舉 NFT 嗎？

可以嘗試，但不受限制的鏈上迴圈最終可能超過區塊 Gas 上限。

此擴充有提供分頁功能嗎？

沒有。應用程式會透過查詢選定的索引範圍自行建立分頁。

此擴充會列出所有 NFT 持有人嗎？

不會。它會列出全域代幣 ID 和已知持有人持有的代幣 ID，但不會回傳所有持有人地址的不重複清單。

事件索引可以取代列舉功能嗎？

可以。鏈下索引器可以透過 ERC-721 Transfer 事件重建代幣供應量和所有權。

列舉功能包含 NFT metadata 嗎？

不包含。metadata 由另一個 ERC-721 選用擴充提供。

列舉功能能證明 NFT 真實性嗎？

不能。任何人都可以部署可列舉合約，因此使用者必須確認網路、合約地址、發行方和權限。

部署後可以新增列舉功能嗎？

可升級合約可以新增，但必須安全地將既有代幣遷移至新的索引結構。

ERC721Enumerable 與所有 ERC-721 擴充都相容嗎？

不相容。壓縮批次鑄造和自訂餘額實作可能與標準列舉儲存結構衝突。

可列舉擴充在什麼情況下最有用？

當合約或應用程式需要標準化的鏈上存取，以取得目前代幣清單或持有人代幣 ID 時，最適合使用此擴充。

結論

可列舉擴充是 ERC-721 的選用功能，可透過標準化的鏈上查詢探索 NFT 代幣 ID。

其介面 ID 為

。

此擴充新增

、 和 。

這些函式可以列出目前的系列代幣，以及已知地址持有的代幣 ID。

列舉索引不是永久識別碼，且標準不保證索引順序。

此擴充也不提供 metadata、版稅、持有人清單、歷史紀錄或固定供應量證明。

維護全域和持有人專屬索引需要額外儲存寫入，因此會提高鑄造、轉移和銷毀的 Gas 費。

大型應用程式通常使用 ERC-721 Transfer 事件和鏈下索引，而非支付完整鏈上列舉的成本。

實作此擴充的開發者必須確保每條狀態變更路徑中的所有權、餘額和索引結構都保持同步。

使用者應自行確認介面支援、合約身分、鑄造權限、升級權限和目前供應量。

了解可列舉擴充，有助於加密貨幣使用者區分直接鏈上 NFT 探索、metadata、所有權歷史、稀缺性與鏈下索引服務。