理解 TON-20 Indexer 架構

TON 區塊鏈上的 indexer 在掃描網路上的所有交易方面發揮著關鍵作用。與使用智能合約在鏈上執行規則的傳統區塊鏈代幣不同，TON-20 代幣完全依賴鏈下 indexers 來解釋和驗證嵌入在交易資料中的代幣操作。

graph TD
    A[TON 區塊鏈<br/>所有分片] -->|持續監控| B[Indexer 掃描<br/>每筆交易]
    B --> C{包含<br/>TON-20 Inscription?}
    C -->|否| D[跳過交易]
    C -->|是| E[提取 JSON 資料]
    E --> F{驗證格式<br/>和操作}
    F -->|無效| G[拒絕並記錄錯誤]
    F -->|有效部署| H[註冊新代幣<br/>先到先得]
    F -->|有效鑄造| I[檢查供應限制]
    F -->|有效轉移| J[驗證餘額]
    H --> K[更新狀態資料庫]
    I --> K
    J --> K
    K --> L[為錢包和 dApps<br/>提供 API 查詢服務]

    style A fill:#2196F3
    style B fill:#FF9800
    style F fill:#9C27B0
    style K fill:#4CAF50
    style L fill:#00BCD4

5 階段索引流程：

  1. 交易監控：持續掃描所有分片
  2. Inscription 檢測：識別 p: "ton-20" JSON 資料
  3. 操作分類：部署/鑄造/轉移驗證
  4. 狀態管理：更新鏈下資料庫中的餘額
  5. API 服務：為應用程式提供餘額查詢

Indexer 的主要功能是解析位址發起的每筆交易的 inscription 內容，其中可能包括部署、鑄造和轉移操作。這種架構的靈感來自 Bitcoin 的 Ordinals 和 BRC-20 標準，其中 inscription 資料嵌入在區塊鏈交易中，但由外部系統解釋。

索引過程：技術深入分析

TON-20 indexer 通過多階段流程運作：

  1. 交易監控：Indexer 持續掃描 TON 區塊鏈，檢查所有分片中的每筆交易。鑑於 TON 的動態分片架構每秒可處理高達 100,000 筆交易，這代表了一個重大的計算挑戰。

  2. Inscription 檢測：當交易包含符合 TON-20 inscription 格式的資料（帶有 p: "ton-20" 的 JSON 資料）時，indexer 提取並驗證 inscription 內容。

  3. 操作分類：Indexer 將 inscriptions 分為三類：

    • 部署操作：建立新的代幣參數
    • 鑄造操作：創建新的代幣單位
    • 轉移操作：在位址之間移動代幣

  4. 狀態管理：Indexer 維護所有代幣狀態的綜合資料庫，包括總供應量、個人餘額和交易歷史。

  5. 驗證邏輯：Indexer 執行「首次部署獲勝」（ticker 的首個部署 inscription 被認可）和部署 inscription 中定義的供應限制等規則。

Indexer 只有在 TON-20 的部署 inscription 發生後才會識別 TON-20 代幣的鑄造和轉移 inscriptions。這種順序依賴性創建了 indexer 必須在可能數百萬筆交易中維護的關鍵排序要求。

關鍵技術觀察

1. 鏈下計算模型

TON-20 部署、鑄造和轉移的 Inscriptions：這些 inscriptions 記錄在區塊鏈上，但不由區塊鏈系統本身計算。這代表了與基於智能合約的代幣（如 Jettons）的根本架構差異：

  • 鏈上：交易資料是不可變的且可公開驗證
  • 鏈下：代幣狀態計算發生在 indexer 的資料庫中
  • 信任假設：用戶必須信任 indexer 的實現和資料完整性

這種設計權衡以犧牲需要可信 indexer 基礎設施為代價，優先考慮簡單性和低交易成本。

2. 順序依賴鏈

代幣操作對 Indexer 的依賴：對於 TON-20 代幣，部署和鑄造交易都必須成功索引；否則，後續交易被視為不成功。

考慮這個場景：

區塊 1000：部署 "NANO" 代幣（最大供應量：2100 萬）
區塊 1001：用戶 A 鑄造 100 NANO
區塊 1002：用戶 A 轉移 50 NANO 給用戶 B

如果 indexer 未能處理區塊 1001，儘管區塊 1002 中的轉移已記錄在鏈上，但它變得無效。這創造了一個關鍵的單點故障，indexer 停機或不同步可能使原本有效的交易失效。

3. 有狀態餘額聚合

TON-20 代幣的餘額計算：個人 TON-20 代幣餘額的計算依賴於 indexer，它聚合來自部署和鑄造交易的資料。

Indexer 通過累積操作維護複雜狀態：

  • 從創世區塊開始，按時間順序處理每筆相關交易
  • 對於每個位址，計算：餘額 = Σ(鑄造) + Σ(轉入) - Σ(轉出)
  • 這需要掃描可能數百萬筆歷史交易來計算當前餘額

與智能合約代幣餘額儲存在合約狀態中不同，TON-20 餘額必須從交易歷史中重新計算。這使得餘額查詢計算成本高昂並引入延遲。

4. 樂觀交易模型

不經 Indexer 驗證的交易：用戶可以在不諮詢 indexer 餘額的情況下發起交易，這可能導致成功發起但因資金不足而不被 indexer 認可的交易。

這種「樂觀」模型創建了幾種邊緣情況：

  • 用戶可以廣播餘額不足的轉移交易
  • 交易在鏈上成功（消耗 gas 費用）但被 indexer 拒絕
  • 用戶因無效交易損失 gas 費用
  • 錢包應用程式必須在允許交易前查詢 indexers 以防止這種情況

這與智能合約代幣不同，後者由合約本身在允許轉移前驗證餘額是否充足。

Indexer 中心化的關鍵挑戰

對中心化 indexer 基礎設施的依賴引入了幾個系統性風險和技術挑戰：

透明度和完整性問題

雖然區塊鏈資料是公開可用的，但無法保證 indexer 已捕獲所有交易。幾個因素可能導致索引缺口：

  • 網路分區：在 2023 年 12 月 TON-20 激增期間，分片不同步導致約 250 萬筆交易暫時未處理
  • 實現錯誤：不同的 indexer 實現可能以不同方式解釋邊緣情況，導致代幣狀態不一致
  • 歷史缺口：如果 indexer 在創世區塊後開始同步，它必須重放所有歷史交易——任何遺漏的區塊都會造成永久不一致

即時性和實時處理

確保即時索引交易在 TON 的規模下是至關重要但具有挑戰性的：

  • 吞吐量瓶頸：由於 TON 能夠達到 100,000 tps，indexers 必須比創建交易更快地處理交易以避免落後
  • 分片複雜性：TON 的動態分片意味著 indexers 必須同時監控多個分片並維護跨分片的正確交易排序
  • 重組處理：區塊鏈重組（雖然在 TON 上很少見）需要 indexer 回滾狀態並重新處理交易

計算準確性和驗證

即使有即時索引，indexer 使用的計算功能的正確性也必須得到驗證：

  • 開源要求：為了無信任驗證，indexer 原始碼必須是公開且可審計的
  • 確定性重放：運行相同程式碼的不同 indexers 應產生相同的代幣狀態
  • 邊緣情況覆蓋：Indexer 必須正確處理格式錯誤的 inscriptions、重複的 ticker 符號和對抗性輸入

現實世界的例子：如果兩個用戶同時為 ticker「DOGE」部署 inscriptions，indexer 必須根據區塊高度和交易索引一致地只認可第一個。

餘額更新的延遲

當前 indexer 執行的 TON-20 餘額計算存在顯著延遲和不準確：

  • 查詢回應時間：餘額查詢可能需要幾秒鐘，因為 indexer 從數千筆交易中計算累積狀態
  • 緩存失效：當新交易到達時，緩存的餘額變得過時，必須重新計算
  • 競態條件：在處理交易時查詢餘額的用戶可能會看到不一致的狀態

解決方案和未來增強

為了增強 TON-20 代幣操作的效能和準確性，社群正在探索幾種技術方法：

去中心化 Indexer 網路

開發多個獨立的 Indexers：與其依賴單一 indexer，生態系統受益於多個獨立的實現：

  • 共識機制：多個 indexers 可以交叉驗證代幣狀態，分歧被標記為需要手動審查
  • 冗餘：如果一個 indexer 失敗或落後，其他 indexers 可以繼續提供查詢服務
  • 開源競爭：多個團隊構建 indexers 推動創新和錯誤發現

像 ton-nft-explorer 和各種社群 indexers 等項目已經出現，提供替代實現。

增強透明度

計算邏輯的透明度：公開揭示餘額計算背後的邏輯，允許所有用戶進行透明和精確的驗證：

  • 開源儲存庫：所有 indexer 程式碼應在 GitHub 上公開可審計
  • 狀態快照：發布定期狀態快照（例如，區塊高度 X 時的所有餘額）使獨立驗證成為可能
  • API 標準：標準化的 indexer API 允許錢包在 indexers 之間無縫切換

效能優化

快速準確的餘額檢索：確保用戶能夠快速準確地存取其 TON-20 餘額至關重要：

  • 資料庫索引：優化的資料庫模式，在位址和 ticker 欄位上有適當的索引
  • 緩存策略：多層緩存（記憶體、Redis、CDN）以即時服務頻繁查詢
  • 增量更新：與其重新計算所有餘額，不如維護增量狀態變更
  • 平行處理：將索引分佈到多個工作線程以跟上區塊鏈吞吐量

與其他 Inscription 系統的比較

TON-20 的 indexer 架構與其他基於 inscription 的代幣系統有相似之處，但具有獨特特徵：

特性 TON-20 BRC-20 (Bitcoin) Runes (Bitcoin)
共識機制 PoS（快速最終性） PoW（10 分鐘區塊） PoW（10 分鐘區塊）
吞吐量挑戰 潛在 100K+ tps ~7 tps ~7 tps
分片 動態分片 單鏈 單鏈
Indexer 複雜性 高（多分片） 中等 中等
重組風險 低 中等 中等

由於 TON 的高吞吐量和分片，TON-20 indexers 面臨獨特的擴展挑戰，但受益於更快的最終性減少重組問題。

用戶和開發者的實際影響

對代幣持有者

  • 多個 Indexer 查詢：在執行大額轉帳前跨多個 indexers 檢查餘額
  • 交易確認：等待 indexer 確認（不僅僅是區塊鏈確認）後才認為轉帳完成
  • 可信介面：使用與可靠、維護良好的 indexers 整合的錢包應用程式

對開發者

  • 錯誤處理：為 indexer API 失敗實現穩健的重試邏輯
  • 餘額驗證：在允許用戶發起轉帳前始終查詢 indexer 餘額
  • Indexer 選擇：為用戶提供選擇其偏好 indexer 的選項
  • 本地驗證：考慮為關鍵應用程式運行輕量 indexer 客戶端

對 Indexer 運營者

  • 監控：為索引延遲、錯誤率和狀態一致性實施全面監控
  • 災難恢復：維護定期狀態備份以實現快速故障恢復
  • API 速率限制：保護基礎設施同時確保合法應用程式的公平存取
  • 文檔：為開發者提供清晰的 API 文檔和狀態頁面

結論：前進的道路

這項詳細檢視闡明了 TON 區塊鏈內 TON-20 代幣操作的複雜運作。基於 indexer 的架構代表了代幣系統的創新方法，優先考慮簡單性和低交易成本，靈感來自 Bitcoin 的 OP_RETURN inscriptions。

本文強調了 indexer 在管理代幣操作中的關鍵角色，以及需要提高其效率和透明度以確保區塊鏈上交易的可靠性和準確性。隨著 TON 生態系統的成熟，我們預期會看到：

  1. 標準化：社群驅動的 indexer 行為和 API 標準
  2. 去中心化：多個獨立的 indexers 提供冗餘
  3. 優化：效能改進使亞秒級餘額查詢成為可能
  4. 混合方法：可能與智能合約整合進行關鍵驗證

TON-20 索引基礎設施的演進對於基於 inscription 的代幣在 TON 區塊鏈上更廣泛採用至關重要，平衡去中心化、效能和用戶體驗之間的權衡。