作者：shew

摘要

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

在這個系列中，我們將聚焦在那些加密世界中處於關鍵節點卻逐漸失範的「公共財」。它們是整個生態的基礎設施，但往往面臨激勵不足、治理失衡、甚至逐漸中心化的困境。加密技術所追求的理想和現實中的冗餘穩定性，正在這些角落經歷嚴峻的考驗。

本期，我們聚焦在以太坊生態中最「出圈」的應用之一：Polymarket 及其資料索引工具。尤其是今年以來，圍繞著川普勝選、烏克蘭稀土交易的預言機操控、澤連斯基西服顏色的政治賭注等事件，使得Polymarket 多次成為輿論焦點，它所承載的資金規模和市場影響力更是讓這些爭議變得不容忽視。

然而，這個代表「去中心化預測市場」的產品，它的關鍵基礎模組——資料索引，真的實現了去中心化嗎？為什麼像The Graph 這樣的公共基礎設施未能承擔起預期的角色？一個真正可用、可持續的資料索引公共物品，又應具備怎樣的形態？

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

2024 年7 月，Goldsky 發生了長達六小時的宕機事故（ Goldsky 是一家面向Web3 開發者的即時區塊鏈數據基礎設施平台，提供索引、子圖與串流數據服務，幫助快速構建數據驅動的去中心化應用），導致以太坊生態系統的很大一部分項目陷入癱瘓，例如DeFi 無法顯示用戶的市場以及前端市場以及前端無法顯示正確的數據，無數項目在前端使用者看來似乎已經完全無法使用。

這在去中心化應用的世界裡本來不應該發生。畢竟，區塊鏈技術的設計的最初目的不就是消除單點故障嗎？ Goldsky 事件暴露了一個令人不安的事實：雖然區塊鏈本身已經盡可能實現了去中心化的，但是構建在鏈上的應用使用的基礎設施往往包含了大量的中心化服務。

究其原因，區塊鏈資料索引與檢索屬於「非排他、非競爭性」的數位公共產品，使用者往往期望免費或極低費率，但背後卻需要持續投入高強度的硬體、儲存、頻寬與維運人力。缺乏可持續獲利模式時，就會出現贏家通吃的集中化格局：只要一家服務商在速度和資本上取得先發優勢，開發者便傾向把所有查詢流量導向該服務，從而重新形成單點依賴。 Gitcoin 等公益計畫已一再強調，「開源基礎設施能創造數十億美元價值，但作者卻往往無法靠它償還房貸」 。

這警醒我們，去中心化世界迫切需要透過公共產品資助、再分配或社區驅動的舉措來豐富Web3 基礎設施的多樣性，否則會出現中心化的問題。我們呼籲DApp 開發者建構本地優先的產品，也呼籲技術社群在DApp 設計時考慮資料檢索服務失效的情況，保證使用者在無資料檢索基礎架構的情況下仍可以與專案互動。

二、你在Dapp 看到的數據，是從哪裡來的

要理解為什麼會發生Goldsky 這樣的事件，我們需要深入了解DApp 在幕後的工作機制。對一般使用者而言，DApp 通常只由兩部分構成：鏈上合約和前端頁面。大部分用戶已經習慣使用Etherscan 等工具查找鏈上交易狀態，並在前端獲取必要信息，同時使用前端發起交易與合約交互。但這些在使用者前端顯示的數據究竟是從何而來？

不可或缺的資料檢索服務

假設讀者正在建立一個借貸協議，該協議需要顯示用戶的持倉情況以及每個部位的保證金和債務狀況。一個樸素的想法是前端直接從鏈上讀取這些資料。但在實踐中，借貸協議的合約不允許使用戶地址查詢倉位數據，合約會提供使用倉位ID 查詢倉位的具體數據的函數。所以如果我們要在前端顯示使用者的部位狀況，那麼我們需要把目前系統內所有的倉位都檢索出來，然後找出那些倉位屬於目前使用者。這就像要求某人手動搜尋數百萬頁帳本來查找特定資訊一樣——技術上可行，但極其緩慢且低效。事實上，前端是很難完成這項檢索流程的，大型DeFi 專案的擷取即使在伺服器上直接依賴本機節點執行資料擷取任務往往也需要長達數小時的時間。

因此，我們必須引入基礎設施來加速資料取得。 Goldsky 等公司正是提供這些資料索引服務給使用者。下圖展示了資料索引服務可以為應用程式提供的資料類型。

在此處，可能有讀者好奇以太坊生態內似乎存在一個去中心化的資料擷取平台TheGraph，該平台與Goldsky 有哪些關聯？以及為什麼大量的DeFi 專案沒有使用更去中心化的TheGraph 而是使用Goldsky 作為資料提供者？

TheGraph / Goldsky 與SubGraph 的關係

要回答上述問題，我們需要先了解一些技術概念。

1. SubGraph 是一個開發框架，開發者可以使用該框架編寫程式碼來讀取並匯總鏈上數據，並且使用某些方法將這些數據讀取並顯示到前端。
2. TheGraph 是較早的去中心化資料檢索平台，該平台開發了使用AssemblyScript 編寫的SubGraph 框架，開發者可以使用subgraph 框架編寫程式來捕獲合約事件並將這些合約事件寫入到資料庫中，之後用戶可以利用Graphql 方法讀取這些資料或直接利用SQL 程式碼讀取資料庫。
3. 我們一般將運行SubGraph 的服務供應商稱為SubGraph 運營商。 TheGraph 和Goldsky 其實都是SubGraph 的託管商。因為SubGraph 只是一個開發框架，而這個框架所開發的程式需要在伺服器內運作。我們可以看到Goldsky 文件內存在以下內容:

這裡可能有讀者好奇為什麼SubGraph 存在多個業者？

這是因為SubGraph 框架其實只是約定了資料的如何從區塊內讀取和寫入資料庫。

對於資料如何流入SubGraph 程式以及最終的輸出結果寫入到哪種資料庫其實都沒有實現，這些內容需要SubGraph 運營商自己實現。

一般來說，SubGraph 運營商都會進行節點修改等實現更快的速度，不同的運營商（如TheGraph，Goldsky ）存在不同的策略和技術方案。

TheGraph 目前使用了Firehouse 技術方案，引入後，TheGraph 可以實現比過去更加快速的資料檢索，而Goldsky 並沒有對外開源公開其SubGraph 運行的核心程式。

如上文所述，TheGraph 是一個去中心化的資料檢索平台，以Unisawp v3 subgraph 為例，我們可以看到存在大量的運營商為Uniswap v3 提供資料檢索，為次我們也可以將TheGraph 視為一個SubGraph 運營商的集成平台，用戶可以將自己編寫的SubGraph 代碼發送給TheGraph 代碼

Goldsky 的收費模式

對於Goldsky 這種集中化平台而言，Goldsky 存在一個簡單的計費標準，基於使用資源的計費，這是互聯網中最常見的SaaS 平台的計費方式，大部份技術人員對對在這種方式十分熟悉。下圖展示了Goldsky 的價格計算器:

TheGraph 的收費模式

TheGraph 則有一套完全與常規計費方式不同的費用方案，這套費用方案與GRT 的代幣經濟學有關，下圖展示了GRT 的整體代幣經濟學：

1. 每當DApp 或錢包向某個Subgraph 發起請求，所付的Query Fee 會被自動分割：1 % 燒毀、約10 % 流入該Subgraph 的策展池（Curator / 開發者），其餘≈ 89 % 按指數返利機制打給提供算力的Indexer 及其Delegator。
2. Indexer 要先自質押≥ 100 k GRT 才能上線；若回傳錯誤資料將被懲罰（slashing）。 Delegator 把GRT 委託給Indexer，按比例分得上述89 % 的大頭。
3. Curator（通常是開發者）透過Signal 在自家Subgraph 的債券曲線上質押GRT；Signal 數越高，越能吸引Indexer 分配資源。社區經驗建議自籌5 k–10 k GRT 可保證數個Indexer 接單。同時，策展人還能拿到那10 % Royalty。

TheGraph 的按次查詢費用：

在TheGraph 後台內註冊API KEY，並使用該API KEY 請求TheGraph 內運營商檢索的數據，這部分請求是按照請求次數收費，開發者需要預先在平台內存入一部分GRT 代幣作為API 請求的開銷。

TheGraph 的Signal 質押費：

對於SubGraph 的部署者，需要TheGraph 平台內的運營商幫助檢索數據，按照上面提到的收益分配方式，需要告訴其他參與者我的查詢服務更好，可以分到更多錢，就需要質押GRT，類似於打廣告以及給自己擔保有收益，大家才會來。

測試的時候，開發者可以免費將SubGraph 部署到TheGraph 平台，此時TheGraph 官方會幫助用戶進行一些檢索，提供一個用於測試的免費額度，並無法用於生產環境。如果開發者認為SubGraph 在TheGraph 官方的測試環境內運作良好，就可以發佈到公開網路內等待其他業者參與檢索。開發者不能直接向某一個業者付費，並獲得檢索的保障，而是讓多個業者競相提供服務，避免形成單點依賴這。這個過程需要使用GRT 代幣對自己的SubGraph 進行策展(Curating) 操作（也可以稱為Signal 操作），也就是開發者向自己部署的SubGraph 內質押一定數量的GRT，但質押的GRT 數量到達一定量級（此前諮詢的數據是10000 GRT) 時，運行商才加入一定量的工作。

糟糕收費體驗，難倒開發者和傳統會計

對於大部份的專案開發者而言，使用TheGraph 其實是一件相對麻煩的事情，購買GRT 代幣對於Web3 專案而言還算容易，但是對已部署的SubGraph 進行Curating 操作等待運營商的過程就是相當低效的環節。這一環節至少存在以下兩個問題:

1. 質押GRT 數量和吸引營運商所需時間的不確定性問題。筆者在過去部署SubGraph 時直接諮詢了TheGraph 的社區大使確定了質押GRT 的數量，但是對於大部份開發者而言，這一數據並不好獲得，另外質押充足的GRT 後，運營商介入檢索也需要一段時間
2. 成本會計和會計的複雜性問題。由於TheGraph 使用代幣經濟學機制設計收費標準，這對大部分開發者而言使成本計算變得複雜。更實際的問題是，如果企業要對該筆支出進行會計核算，會計也可能無法理解這部分成本組成。

「讚的，還是中心化的好？」

顯然，對於大部份開發者而言，直接選擇Goldsky 是更加簡單的事情，計費方式所有人都可以理解，同時只要付費幾乎可以立即可用，不確定性大幅度降低，這也導致了區塊鏈資料索引與檢索服務上，出現了依賴於單一產品的情況。

顯然TheGraph 複雜的GRT 代幣經濟學影響了TheGraph 的廣泛應用。代幣經濟學可以具有複雜性，但是顯然這些複雜性並不應該暴露給用戶，例如GRT 的策展質押機制就不應該暴露給用戶，TheGraph 更好的手段是直接給用戶一個簡化的付費頁面。

上述對TheGraph 的貶低並不是我個人的觀點，知名智能合約工程師與Sablier 專案創辦人Paul Razvan Berg 也曾在推文內表達這一觀點。該推文提到發布SubGraph 和GRT 計費的用戶體驗是極為糟糕的。

三、一些現存的解決方案

對於資料擷取單點故障如何解決，上文內其實已經提到了一點，即開發者可以考慮使用TheGraph 服務，只是流程會較為複雜，開發者需要買入GRT 代幣進行質押策展和支付API 費用。

目前，EVM 生態內有大量資料擷取軟體，具體可以參考Dune 編寫的The State of EVM Indexing 或rindexer 編寫的EVM 資料檢索軟體匯總，另一個較新的討論可以參考此推文。

此文並不會討論Glodsky 的產生問題的具體原因，因為目前根據Glodsky 報告內的內容，Glodsky 知道具體的原因，但只準備向企業級用戶披露具體原因。這意味著任何第三方都無法在目前知道Glodsky 到底發生何種故障。根據其報告內容可以推測，可能是檢索後的資料寫入資料庫時出現了問題，在這份簡要報告內，Glodsky 提及資料庫無法正常訪問，在與AWS 合作後才獲得了資料庫的存取權。

在本節中，我們主要介紹其他的解決方法:

1. ponder 是一個簡單、開發體驗較好且部署簡單的資料擷取服務軟體，開發者可以自行租用伺服器部署
2. local-first 是一個有趣的開發理念，該理念呼籲開發者即使在缺失網路的情況下仍可為使用者提供良好體驗。在存在區塊鏈的情況下，我們可以在某種程度上放寬local-first 的限制，保證用戶在可以連接區塊鏈時可以獲得良好體驗。

ponder

此處筆者為何建議使用ponder 而非其他軟體？具體原因包含以下幾點:

1. Ponder 沒有供應商依賴。最初ponder 是個人開發者建構的項目，所以相較於其他企業提供的資料檢索軟體，ponder 只需要使用者填入以太坊RPC URL 和postgres 資料庫連結即可
2. Ponder 提供良好的開發體驗，筆者在過去曾多次使用ponder 進行開發，由於ponder 是由typescript 編寫，同時核心庫主要依賴viem，開發體驗非常優秀
3. Ponder 具有更高的性能

當然也會存在一些問題，ponder 目前其實仍處於快速開發時期，開發者可能會遇到由於版本破壞性更新導致先前專案無法運作的情況。考慮到本文並不是一篇技術入門文章，所以本文不會進一步討論ponder 的開發細節，具有技術背景的讀者可以自行閱讀文件。

ponder 更有趣的細節是目前ponder 也開始了部分商業化，但是ponder 的商業化途徑與非常契合上一篇文章內討論的「隔離理論」。

在此處，我們簡單介紹「隔離理論」。我們認為公共財的公共性使其可以服務任意多用戶，所以只要對公共財收費就會導致部分用戶不再使用公共物品，此時社會利益並不是最大化的( 經濟學術語描述為“不再是帕累托最優”)。理論上，公共財可以對每一個人進行區別定價來徵收費用，但是區別定價所花費的成本極有可能大於區別定價帶來的盈餘。所以公共物品免費開放的原因是不是公共物品應該是天然免費，而是任何徵收固定費用的行為都會導致社會利益受損，目前沒有一種廉價的方法可以對每一個人進行區別定價。隔離理論提出了一種可以在公共財內定價的方法，即透過某一種方法將一部分同質性人群隔離出來，對這部分同質人群徵收費用。首先，隔離理論不會阻擋所有人對公共物品的免費享用，但是隔離理論提出了一種方法對部分人群徵收費用。

ponder 就是用了類似隔離理論的方法：

1. 首先，ponder 的部署仍需要一定的知識，開發者在部署過程中需要提供RPC 、資料庫等外部依賴。
2. 同時在部署完成後，開發者需要持續運作維ponder 應用，例如使用proxy 系統進行負載平衡避免資料請求影響ponder 在後台執行緒內擷取鏈上資料。這些對於一般的開發者來說都稍有複雜。
3. 目前ponder 在內測全自動部署服務marble，使用者只需要將程式碼交付給該平台就可以實現自動部署。

顯然這是一種「隔離理論」的應用，這些不願意自己運維ponder 服務的開發者被隔離出來，這些開發者可以透過付費獲得ponder 服務的簡化部署。當然，marble 平台的出現也沒有影響其他開發者免費使用ponder 框架並且自架部署。

ponder 和Goldsky 的受眾？

1. ponder 這種完全沒有供應商依賴的公共物品比其他依賴供應商的資料檢索服務在開發小型專案時更受歡迎。
2. 某些營運有大型專案的開發者不一定選擇ponder 框架，因為大型專案往往要求檢索服務具有充分的效能，Goldsky 等服務提供者往往提供了充分的可用性保障。

兩者都存在一些風險點，從最近的Goldsky 事件來看，開發者最好自行維護一套自己的ponder 服務，以隨時應對可能的第三方服務宕機。以及使用ponder 時可能要考慮RPC 回傳資料的有效性問題，不久前safe 就報告了一次因為RPC 回傳錯誤資料導致檢索器崩潰的情況。雖然沒有直接證據顯示Goldsky 事件也與RPC 回傳無效事件有關，但筆者懷疑Goldsky 可能也遇到了類似事件。

local-first 開發理念

Local-first 是過去幾年一直被人討論的話題。簡單來說，Local-first 要求軟體具有以下功能:

1. 離線工作
2. 跨客戶端協同

目前大部分與local-first 相關的技術討論都會涉及到CRDT(Conflict-free Replicated Data Type) 技術，所謂CRDT 是一種無衝突的資料格式，該格式允許使用者在多端操作時自動合併衝突以保持資料的完整性。一個簡單的看法是可以將CRDT 視為一種具有簡單共識協定的資料類型，在分散式情況下，CRDT 可以保證資料的完整性和一致性。

但在區塊鏈開發中，我們可以放寬上述Local-first 對軟體需求的限制。我們僅要求在沒有專案開發者提供的後端索引資料時，使用者在前端仍可以保持最低限度的可用性。同時，local-first 對跨客戶端協同的要求實際上已經由區塊鏈解決了。

在DApp 的場景下，local-first 理念可以這樣實現：

1. 快取關鍵數據：前端應該快取用戶的重要數據，如餘額、持倉資訊等，即使索引服務不可用，用戶仍能看到最後已知的狀態。
2. 降級功能設計：當後端索引服務不可用時，DApp 可以提供基礎功能，例如在數據檢索服務不可用時，部分數據可以考慮直接利用RPC 讀取鏈上數據，可以保證用戶看到已有部分數據的最新情況

這種local-first 的DApp 設計理念能夠顯著提升應用程式的韌性，並避免在資料擷取服務崩潰後的應用程式無法使用。在不考慮易用性的情況下，最好的local-first 應用程式應該是要求使用者在本地運行節點，然後使用類似trueblocks 的工具在本地檢索資料。關於去中心化檢索或本地檢索的一些討論，可以參考推文Literally no one cares about decentralized frontends and indexers。

四、寫在最後

Goldsky 六小時宕機事件為生態敲響了警鐘。雖然區塊鏈本身俱有去中心化和抗單點故障的特性，但建構在其上的應用生態系統仍然高度依賴中心化的基礎設施服務。這種依賴為整個生態系統帶來了系統性風險。

本文簡單介紹了早有盛名的去中心化檢索服務TheGraph 為什麼在如今並沒有被廣泛使用，特別討論了GRT 代幣經濟學帶來的一些複雜性。最後，本文討論如何建構更健壯的資料擷取基礎設施，筆者鼓勵開發者使用ponder 自託管的資料檢索開發框架作為緊急應變選項，同時也介紹ponder 良好的商業化路徑。最後，本文討論local-first 的開發理念，鼓勵開發者建構在無資料檢索服務下仍可使用的應用。

從目前來看，不少Web3 的開發者都意識到了資料檢索服務的單點故障問題，GCC 希望更多開發者關注這一基礎設施，並嘗試構建去中心化的資料檢索服務或設計一套框架使得DApp 前端在無資料檢索服務的情況仍可運作。