作者：shew
來源：GCC Research
摘要
歡迎來到 GCC Research 專欄的「加密公地悲劇」系列。
在這個系列中，我們將聚焦那些加密世界中處于關鍵節點卻逐漸失范的「公共物品」。它們是整個生態的基礎設施，但往往面臨激勵不足、治理失衡、甚至逐漸中心化的困境。加密技術所追求的理想和現實中的冗余穩定性，正在這些角落里經歷嚴峻的考驗。
本期，我們聚焦以太坊生態中最為「出圈」的應用之一：Polymarket 及其數據索引工具。尤其是今年以來，圍繞特朗普勝選、烏克蘭稀土交易的預言機操控、澤連斯基西服顏色的政治賭注等事件，使得 Polymarket 多次成為輿論焦點，它所承載的資金規模和市場影響力更是讓這些爭議變得不容忽視。
然而，這個代表「去中心化預測市場」的產品，它的關鍵基礎模塊——數據索引，真的實現了去中心化嗎？為什么像 The Graph 這樣的公共基礎設施未能承擔起預期的角色？一個真正可用、可持續的數據索引公共物品，又應具備怎樣的形態？
一、一個中心化數據平臺宕機引發的連鎖反應
2024 年 7 月，Goldsky 發生了長達六小時的宕機事故（ Goldsky 是一家面向 Web3 開發者的實時區塊鏈數據基礎設施平臺，提供索引、子圖與流式數據服務，幫助快速構建數據驅動的去中心化應用），導致以太坊生態系統的很大一部分項目陷入癱瘓，比如 DeFi 前端無法顯示用戶的倉位以及余額數據，預測市場 Polymarket 無法顯示正確的數據，無數項目在前端用戶看來似乎已經完全無法使用。
這在去中心化應用的世界里本不應該發生。畢竟，區塊鏈技術的設計的最初目的不就是消除單點故障嗎？Goldsky 事件暴露了一個令人不安的事實：雖然區塊鏈本身已經盡可能實現了去中心化的，但是構建在鏈上的應用使用的基礎設施往往包含了大量的中心化服務。
究其原因，區塊鏈數據索引與檢索屬于「非排他、非競爭性」的數字公共產品，使用者往往期望免費或極低費率，但其背后卻需要持續投入高強度的硬件、存儲、帶寬與運維人力。缺乏可持續盈利模式時，就會出現贏家通吃的集中化格局：只要一家服務商在速度和資本上取得先發優勢，開發者便傾向把所有查詢流量導向該服務，從而重新形成單點依賴。Gitcoin 等公益項目已反復強調，「開源基礎設施能創造數十億美元價值，但作者卻往往無法靠它償還房貸」 。
這警醒我們，去中心化世界迫切需要通過公共產品資助、再分配或社區驅動的舉措來豐富 Web3 基礎設施的多樣性，否則會出現中心化的問題。我們呼吁 DApp 開發者構建本地優先的產品，也呼吁技術社區在 DApp 設計時考慮數據檢索服務失效的情況，保證用戶在無數據檢索基礎設施的情況下仍可以與項目交互。
二、你在 Dapp 看到的數據，是從哪兒來的
要理解為什么會發生 Goldsky 這樣的事件，我們需要深入了解 DApp 在幕后的工作機制。對普通用戶而言，DApp 通常只由兩部分構成：鏈上合約和前端頁面。大部分用戶已經習慣使用 Etherscan 等工具查找鏈上交易狀態，并在前端獲取必要信息，同時使用前端發起交易與合約交互。但這些在用戶前端顯示的數據究竟從何而來？
不可或缺的數據檢索服務
假設讀者正在構建一個借貸協議，該協議需要顯示用戶的持倉情況以及每個倉位的保證金和債務狀況。一個樸素的想法是前端直接從鏈上讀取這些數據。但在實踐中，借貸協議的合約不允許使用戶地址查詢倉位數據，合約會提供使用倉位 ID 查詢倉位的具體數據的函數。所以假如我們要在前端顯示用戶的倉位情況，那么我們需要把當前系統內所有的倉位都檢索出來，然后查找那些倉位屬于當前用戶。這就像要求某人手動搜索數百萬頁賬本來查找特定信息——技術上可行，但極其緩慢且低效。事實上，前端是很難完成這一檢索流程的，大型 DeFi 項目的檢索即使在服務器上直接依靠本地節點執行數據檢索任務往往也需要長達數小時的時間。
因此，我們必須引入基礎設施來加速數據獲取。Goldsky 等公司正是向用戶提供這些數據索引服務。下圖展示了數據索引服務可以為應用提供的數據類型。
在此處，可能有讀者好奇以太坊生態內似乎存在一個去中心化的數據檢索平臺 TheGraph，該平臺與 Goldsky 有哪些聯系？以及為什么大量的 DeFi 項目沒有使用更加去中心化的 TheGraph 而是使用 Goldsky 作為數據提供商？
TheGraph / Goldsky 與 SubGraph 的關系
要回答上述問題，我們需要先了解一些技術概念。
這里可能有讀者好奇為什么 SubGraph 存在多個運營商？
這是因為 SubGraph 框架其實只是約定了數據的如何從區塊內讀取和寫入數據庫。
對于數據如何流入 SubGraph 程序以及最終的輸出結果寫入到哪種數據庫其實都沒有進行實現，這些內容需要 SubGraph 運營商自己實現。
一般來說，SubGraph 運營商都會進行節點修改等實現更快的速度，不同的運營商（如 TheGraph，Goldsky ）存在不同的策略和技術方案。
TheGraph 目前使用了 Firehouse 技術方案，該技術方案引入后，TheGraph 可以實現比過去更加快速的數據檢索，而 Goldsky 并沒有對外開源公開其 SubGraph 運行的核心程序。
正如上文所述，TheGraph 是一個去中心化的數據檢索平臺，以 Unisawp v3 subgraph 為例，我們可以看到存在大量的運營商為 Uniswap v3 提供數據檢索，為次我們也可以將 TheGraph 視為一個 SubGraph 運營商的集成平臺，用戶可以將自己編寫的 SubGraph 代碼發送給 TheGraph，然后 TheGraph 內部存在一些運營商可以幫助用戶檢索數據。
Goldsky 的收費模式
對于 Goldsky 這種集中化平臺而言，Goldsky 存在一個簡單的計費標準，基于使用資源的計費，這是互聯網中最常見的 SaaS 平臺的計費方式，大部份技術人員對對在這種方式十分熟悉。下圖展示了 Goldsky 的價格計算器:
TheGraph 的收費模式
TheGraph 則有一套完全與常規計費方式不同的費用方案，這套費用方案與 GRT 的代幣經濟學有關，下圖展示了 GRT 的整體代幣經濟學：
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) 時，運營商才加入 SubGraph 的檢索工作。
糟糕收費體驗，難倒開發者和傳統會計
對于大部份的項目開發者而言，使用 TheGraph 其實是一件相對麻煩的事情，購買 GRT 代幣對于 Web3 項目而言還算容易，但是對已部署的 SubGraph 進行 Curating 操作等待運營商的過程就是相當低效的環節。這一環節至少存在以下兩個問題:
「贊的，還是中心化的好？」
顯然，對于大部份開發者而言，直接選擇 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 合作后才獲得了數據庫的訪問權。
在本節中，我們主要介紹其他的解決方法:
ponder
此處筆者為什么推薦使用 ponder 而不是其他軟件？具體原因包含以下幾點:
當然也會存在一些問題，ponder 目前其實仍處于快速開發時期，開發者可能會遇到由于版本破壞性更新導致之前項目無法運行的情況。考慮到本文并不是一篇技術入門文章，所以本文不會進一步討論 ponder 的開發細節，具有技術背景的讀者可以自行閱讀 文檔。
ponder 更有趣的細節是目前 ponder 也開始了部分商業化，但是 ponder 的商業化途徑與非常契合上一篇文章內討論的「隔離理論」。
在此處，我們簡單介紹「隔離理論」。我們認為公共物品的公共性使其可以服務任意多用戶，所以只要對公共物品收費就會導致部分用戶不再使用公共物品，此時社會利益并不是最大化的 ( 經濟學術語描述為「不再是帕累托最優」)。理論上，公共物品可以對每一個人進行區別定價來征收費用，但是區別定價所花費的成本極有可能大于區別定價帶來的盈余。所以公共物品免費開放的原因是并不是公共物品應該是天然免費，而是任何征收固定費用的行為都會導致社會利益受損，并且目前沒有一種廉價的方法可以對每一個人進行區別定價。隔離理論提出了一種可以在公共物品內定價的方法，即通過某一種方法將一部份同質人群隔離出來，對這部分同質人群征收費用。首先，隔離理論不會阻擋所有人對公共物品的免費享用，但是隔離理論提出了一種方法對部分人群征收費用。
ponder 就是用了類似隔離理論的方法：
顯然這是一種對「隔離理論」的應用，這些不愿意自己運維 ponder 服務的開發者被隔離出來，這些開發者可以通過付費獲得 ponder 服務的簡化部署。當然，marble 平臺的出現也沒有影響其他開發者免費使用 ponder 框架并且自托管部署。
ponder 和 Goldsky 的受眾？
兩者都存在一些風險點，從最近的 Goldsky 事件來看，開發者最好自行維護一套自己的 ponder 服務，以隨時應對可能的第三方服務宕機。以及使用 ponder 時可能要考慮 RPC 返回數據的有效性問題，不久前 safe 就報告了一次因為 RPC 返回錯誤數據導致檢索器崩潰的 情況。雖然沒有直接證據表明 Goldsky 事件也與 RPC 返回無效事件有關，但筆者懷疑 Goldsky 可能也遇到了類似事件。
local-first 開發理念
Local-first 是過去幾年一直被人討論的話題。簡單來說，Local-first 要求軟件具有以下功能:
目前大部份與 local-first 相關的技術討論都會涉及到 CRDT(Conflict-free Replicated Data Type) 技術，所謂 CRDT 是一種無沖突的數據格式，該格式允許用戶在多端操作時自動合并沖突以保持數據的完整性。一種簡單的看法是可以將 CRDT 視為一種帶有簡單共識協議的數據類型，在分布式情況下，CRDT 可以保證數據的完整性和一致性。
但在區塊鏈開發中，我們可以放寬上述 Local-first 對軟件要求的限制。我們僅要求在沒有項目開發者提供的后端索引數據時，用戶在前端仍可以保持最低限度的可用性。同時，local-first 對跨客戶端協同的要求實際上已經由區塊鏈解決了。
在 DApp 的場景下，local-first 理念可以這樣實現：
這種 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 前端在無數據檢索服務的情況仍可運行。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
