摘要

歡迎來到 GCC Research 專欄「加密公地悲劇」系列。

本系列將專注於加密世界中位居樞紐、卻逐漸失序的「公共財」。這些基礎設施支撐整個生態，卻經常面臨激勵不足、治理失衡甚至逐漸中心化的困境。加密技術追求的理想與現實中的冗餘穩定性，正於這些環節接受嚴峻考驗。

本期文章聚焦以太坊生態最具話題性的應用之一：Polymarket 及其資料索引工具。尤其今年以來，圍繞川普勝選、烏克蘭稀土交易預言機操控、澤連斯基西服顏色政治賭局等事件，使 Polymarket 多次成為輿論中心，涉入資金規模與市場影響力更讓相關爭議不可忽視。

然而，這款代表「去中心化預測市場」的產品，其關鍵基礎模組——資料索引，真的實現了去中心化嗎？為何像 The Graph 這類公共基礎設施未能發揮預期作用？一個真正可用且可持續的資料索引型公共財，究竟應具備什麼特質？

一、一個中心化資料平台當機引發的連鎖反應

2024 年 7 月，Goldsky 發生連續六小時的當機（Goldsky 是一個面向 Web3 開發者的即時區塊鏈資料基礎設施平台，提供索引、子圖（SubGraph）與串流資料服務，協助快速打造資料驅動的去中心化應用），導致以太坊生態系多項專案無法運作。舉例而言，DeFi 前端無法顯示用戶倉位及餘額，預測市場 Polymarket 資料錯誤，無數專案於用戶端看來幾乎完全不可用。

這種現象本不應出現於去中心化應用場域。畢竟，區塊鏈技術設計的初衷，即在於消除單點故障。Goldsky 事件揭示了一項令人不安的事實：區塊鏈本身雖然已最大程度去中心化，但其上應用所仰賴的基礎設施，往往仍包含大量中心化服務。

究其原因，區塊鏈資料索引與檢索屬「非排他、非競爭性」的數位公共財，使用者普遍期望免費或極低費率，但其背後卻需持續投入高強度硬體、儲存、頻寬及運維人力。缺乏可持續獲利模式時，市場容易出現贏家通吃的集中化格局：只要某服務商在速度與資本上取得優勢，開發者便傾向將所有使用量導向該服務，最終又形成單點依賴。Gitcoin 等公益專案已反覆強調，「開源基礎設施創造數十億美元價值，作者本身卻難以償還房貸」。

這提醒我們，去中心化世界亟需藉由公共財資助、再分配或社群驅動措施，來增加 Web3 基礎設施的多樣性，否則中心化問題將更趨嚴重。本文同時呼籲 DApp 開發者設計本地優先（local-first）產品，技術社群也宜於 DApp 規劃階段思考資料檢索服務失效時的應變，以保障用戶即使沒有索引基礎設施，仍能互動應用專案。

二、你在 Dapp 看到的資料從哪裡來

要理解 Goldsky 事件原因，須先深入 DApp 背後的運作機制。對一般用戶來說，DApp 通常只包括鏈上合約與前端頁面。多數人已習慣透過 Etherscan 等工具查詢鏈上交易狀態，並在前端獲取重要資訊或發起交易與合約互動。但這些在前端顯示的資料，究竟從何而來？

不可或缺的資料檢索服務

假設讀者正在打造一個借貸協議，需顯示用戶持倉與每筆倉位的保證金及債務情況。一個直覺解法是前端直接讀取鏈上資料。但實際上，借貸協議合約無法直接以用戶地址查詢持倉，只允許用倉位 ID 查詢具體資料。若前端要顯示用戶持倉，就需要先檢索所有倉位，再篩選出屬於用戶的資料。這相當於必須人工搜尋數百萬頁帳本，雖技術上可行，但效率極低。事實是，這種檢索流程前端難以勝任，大型 DeFi 專案即使在伺服器上依靠本地節點檢索也常需數小時。

因此，必須依賴資料索引基礎設施加速資料存取。Goldsky 等公司正是提供這種資料索引服務。下圖展示資料索引服務為應用帶來的資料型態：

有些讀者可能會疑惑，以太坊生態內似乎已有去中心化索引平台 TheGraph；它與 Goldsky 有何聯繫？為何眾多 DeFi 專案不選用 TheGraph，而改採 Goldsky 提供資料？

TheGraph / Goldsky 與子圖（SubGraph）的關係

要解答上述疑問，需釐清幾個技術概念。

• 子圖（SubGraph）是一個開發框架，開發者可用於讀取與整理鏈上資料，並以特定方法將資料讀入並展示於前端。
• TheGraph 是早期去中心化資料檢索平台，開發了基於 AssemblyScript 的 SubGraph 框架，可用於捕捉合約事件並將其寫入資料庫，用戶可通過 Graphql 或直接以 SQL 查詢資料。
• 我們通常將執行 SubGraph 的服務商稱為 SubGraph 運營商；TheGraph 和 Goldsky 都是 SubGraph 的代管商。SubGraph 僅為開發框架，相關程式須在伺服器運行。Goldsky 文件也有相關說明：

有些讀者可能會問，為何 SubGraph 有多家運營商？

這是因為 SubGraph 框架僅定義資料如何從區塊讀取並寫入資料庫。

至於最終資料流向何種資料庫，需由 SubGraph 運營商自行設計實現。

一般來說，運營商會調整節點設計以加快速度，不同運營商（如 TheGraph、Goldsky）有各自技術策略。

TheGraph 目前採用 Firehouse 技術方案（Firehouse），導入後提升資料檢索速度，Goldsky 則未公開其 SubGraph 執行核心程式原始碼。

正如前述，TheGraph 是去中心化資料索引平台，以 Unisawp v3 subgraph 為例，可見有多家運營商為 Uniswap v3 提供檢索服務，因此 TheGraph 可視為運營商整合平台，用戶將自編 SubGraph 程式交由 TheGraph，內部有多家運營商協助檢索。

Goldsky 的收費模式

Goldsky 屬於中心化平台，收費模式簡單明瞭，依使用資源計費，這是網路產業最常見的 SaaS 平台方案，多數技術人員熟悉。下圖展示 Goldsky 價格計算器：

TheGraph 的收費模式

TheGraph 運用完全不同於傳統的計費方案，係與 GRT 代幣經濟學連動，詳見下圖 GRT 整體經濟設計：

• DApp 或錢包向某 SubGraph 請求資料時，查詢費用（Query Fee）會自動拆分：1 % 銷毀、約 10 % 流入該策展池（Curator Pool）、剩餘 89 % 依指數返利分給索引者（Indexer）與其委託者（Delegator）。
• 索引者（Indexer）首先需自質押不少於 100,000 GRT 才能上線；若回傳錯誤資料會被懲罰。委託者（Delegator）委託 GRT 給索引者，按比例分得 89 % 收益。
• 策展（Curator，通常為開發者）透過信號（Signal）在自家 SubGraph 債券曲線上質押 GRT，Signal 數高者愈能吸引索引者資源分配。社群建議自備 5,000–10,000 GRT 可吸引多名索引者。策展人能取得剩餘 10 % 版稅（Royalty）。

TheGraph 按次查詢費：

於後台註冊 API 金鑰，透過該金鑰向 TheGraph 運營商請求資料，每次請求都計費，開發者需預先儲值部分 GRT 代幣作 API 請求成本。

TheGraph Signal 質押費：

SubGraph 部署者如需運營商協助資料檢索，須依上述收益分配模式，宣傳自家查詢服務優勢並質押 GRT。這有點類似廣告或擔保，才能吸引合作資源。

測試階段，開發者可免費將 SubGraph 部署於 TheGraph 平台，由官方協助檢索、提供免費測試額度，惟僅適用測試環境。若測試順利，可發布至公開網路，等待運營商參與檢索。開發者無法直接向特定運營商付費以保證檢索服務，必須令多家運營商競逐，避免單點依賴。此流程需以 GRT 代幣對自家 SubGraph 進行策展（Curating，即 Signal 操作），須於部署的 SubGraph 上質押一定數量 GRT，且質押量達 10,000 GRT 門檻時，運營商才會加入檢索。

糟糕收費體驗，令開發者和會計頭痛

多數專案開發者認為，採用 TheGraph 往往繁複，購買 GRT 代幣對 Web3 專案尚算容易，但部署的 SubGraph 需策展並等待運營商介入，流程低效且不確定。具體有二大痛點：

• 質押 GRT 數量及吸引運營商所需時間充滿不確定性。筆者曾諮詢 TheGraph 社群大使確定質押數量，但對多數開發者而言難以取得精確數據，且即使質押充足，運營商介入仍有延遲。
• 成本核算及會計複雜性。因 TheGraph 採用代幣經濟設計收費，導致開發者成本計算困難。若企業需做會計核算，會計人員可能難以解析成本結構。

「還是中心化的比較好？」

對絕大多數開發者而言，直接選用 Goldsky 更為便利，收費模式簡單，付費即用，大幅降低不確定性，促使區塊鏈資料索引與檢索服務出現單一依賴現象。

TheGraph 複雜的 GRT 代幣經濟學，影響了其全面普及。雖然代幣經濟本可具複雜性，但這些細節不該攤開給用戶，例如 GRT 策展質押機制應直接以簡化付費頁面呈現。

上述對 TheGraph 的批評並非筆者個人看法，知名智能合約工程師暨 Sablier 創辦人 Paul Razvan Berg 亦於推文 中指出，SubGraph 發布與 GRT 計費用戶體驗極糟。

三、現存部分解決方案

針對資料檢索單點故障，前文已提及開發者可嘗試採用 TheGraph，流程較為繁瑣，需購買 GRT 代幣進行質押策展與支付 API 費用。

目前 EVM 生態存在大量資料檢索軟體，可參考 Dune 撰寫的The State of EVM Indexing 或 rindexer 的EVM 資料檢索軟體總覽，另有較新討論可參考此推文。

本文不討論 Glodsky 故障原因，依Glodsky 報告，Glodsky 已掌握主因，但僅向企業級用戶披露，第三方目前無法得知實際故障狀況。據其報告內容推測，可能是資料檢索後寫入資料庫時出現問題，簡要報告亦提及無法存取資料庫，與 AWS 合作後才恢復。

以下介紹其他解決策略：

• ponder 是易於部署、開發體驗佳、流程簡單的資料檢索軟體，開發者可自行租用伺服器部署。
• 本地優先（local-first）是近年重要的開發理念，鼓勵開發者即使斷網時仍能提供良好用戶體驗。在區塊鏈場景下，可適度放寬 local-first 限制，只要用戶可連接區塊鏈即可維持體驗。

ponder

筆者推薦 ponder 而非其他軟體，理由如下：

• Ponder 不依賴任何供應商。初期由個人開發，僅需填入以太坊遠端程序呼叫（RPC）URL 及 postgres 資料庫連結即可運作。
• Ponder 開發體驗優秀，筆者多次實測，因以 TypeScript 編寫、核心庫採 viem，開發順暢。
• Ponder 效能高度優異。

但仍有挑戰，ponder 處於高速迭代期，開發者可能因版本更新導致舊專案無法運作。本文非技術入門文，詳細開發資訊請自行參閱 官方文件。

此外，ponder 正推行部分商業化路徑，且非常契合上一篇文章所述的「隔離理論」。

簡述隔離理論：公共財可服務無限用戶，唯徵收費用時，部分用戶會放棄使用，社會利益不再最大化（即「非帕累托最優」）。理論上可對每人差別訂價，但執行成本高於盈餘。現實中，公共財免費開放，是因收費後反而傷害整體利益。隔離理論主張，透過某種方式隔離部分同質群體並收費，不阻擋所有人免費使用，只向特定群體收取費用。

ponder 便是應用了隔離理論：

• 部署 ponder 需要一定技術，開發者需提供 RPC、資料庫等外部依賴。
• 部署後，開發者需持續運維應用，例如以 proxy 負載均衡，避免資料請求影響後台資料檢索，對一般開發者來說門檻略高。
• 目前 ponder 內測全自動部署服務marble，用戶僅需提交程式碼即可一鍵部署。

這正是隔離理論的典型應用：無意自維 ponder 服務的開發者被隔離，可付費享有簡化部署；marble 的出現不影響其他人免費使用 ponder 框架並自行託管部署。

Ponder 與 Goldsky 的適用場景？

• 完全無供應商依賴的 ponder，於開發小型專案時尤為流行。
• 大型專案開發者未必選用 ponder，主因檢索服務要求極高效能，Goldsky 等服務商能保障高可用性。

兩者皆有風險。Goldsky 事件提醒開發者應自行維護 ponder 服務，以應對第三方服務當機。使用 ponder 時也須考慮 RPC 回傳資料效度，不久前 safe 曾通報因 RPC 回應錯誤導致檢索器崩潰的案例。雖尚無直接證據證明 Goldsky 事件與 RPC 無效回應相關，但筆者推測可能有類似狀況。

本地優先（local-first）開發理念

Local-first 是近年熱門議題。簡而言之，Local-first 軟體應具備：

• 可離線運作
• 支援跨裝置協同

多數 local-first 技術討論會觸及無衝突複製資料型態（CRDT）技術，此類資料型態可無衝突同步，使用者在多端操作時可自動合併衝突、確保完整性。簡單來說，CRDT 就像具備共識協定的資料類型，在分散環境保障一致性。

在區塊鏈開發場景，可適度放寬 local-first 軟體要求，只需保障缺乏開發者後端索引時，前端仍有最低限度可用性。跨裝置協同事實上由區塊鏈本身解決。

DApp 應用下，local-first 理念可具體落實為：

• 快取核心資料：前端快取用戶餘額、持倉等重要資訊，即使索引服務停擺，仍可呈現最後一次狀態。
• 功能降級設計：索引服務中斷時，DApp 提供基礎功能，例如索引不可用時，部分資料可直接以 RPC 讀取鏈上資料，保障用戶能看到最新部分結果。

local-first DApp 設計能顯著提升應用韌性，避免檢索服務當機造成全域停擺。若無須考慮易用性，最佳 local-first 應用是讓用戶在本地運行節點，並以 trueblocks 類工具自本地檢索資料。關於去中心化或本地檢索討論，可參閱相關推文。

四、結語

Goldsky 六小時當機事件為整體生態敲響警鐘。區塊鏈本身具備去中心化與抗單點故障特性，應用生態系卻高度依賴中心化基礎設施服務，帶來系統性風險。

本文簡要剖析廣為人知的去中心化檢索服務 TheGraph 為何未普及，並探討 GRT 代幣經濟學帶來的複雜性。最後，介紹如何打造強健的資料檢索基礎設施，建議開發者採用 ponder 自行託管開發框架作為備案，並分析 ponder 商業化路徑，同時說明本地優先（local-first）開發理念，鼓勵打造即使缺乏資料檢索服務也可運作的應用。

目前，不少 Web3 開發者已意識到資料檢索服務的單點故障問題，GCC 希望更多開發者重視基礎設施，並嘗試建構去中心化檢索服務，或設計框架確保 DApp 前端在無檢索服務時仍可正常運作。

聲明：

1. 本文轉載自 [TechFlow]，著作權歸原作者 [shew] 所有；如對轉載有任何異議，請聯絡 Gate Learn 團隊，團隊將依據相關流程盡速處理。
2. 聲明：本文所表達之觀點與意見僅代表作者個人立場，不構成任何投資建議。
3. 本文其他語言版本由 Gate Learn 團隊翻譯，未明確註明 Gate 的情形下，請勿轉載、傳播或抄襲經翻譯內容。