由 Eberhart 
加密貨幣世界的公地悲劇：Polymarket 的數據索引困境
歡迎來到這場幣圈深度歷險！這次咱們不聊暴富神話，不談一夜歸零，而是要深入探討一個攸關整個加密貨幣生態系統命脈，卻經常被忽視的角落：數據索引。想像一下，如果整個網路世界失去了 Google，你還能找到你想看的迷因嗎？同樣的道理，在去中心化的世界裡，如果沒有穩固、可靠的數據索引，那些酷炫的 DApp、DeFi 協議，甚至連預測市場 Polymarket 都會像斷了線的風箏，不知飄向何方。
Polymarket，這個以「預測未來」為賣點的平台，近年來可謂是出盡了風頭。從川普大爺能否再次入主白宮，到烏克蘭的稀土礦產究竟花落誰家，甚至是澤連斯基穿什麼顏色的西裝出席國際會議，都能在這上面下注。這玩意兒聽起來是不是有點扯？但別小看這些看似無厘頭的賭局，背後可是牽動著真金白銀的資金流動，以及左右輿論走向的潛在力量。然而，當我們把目光聚焦到 Polymarket 那光鮮亮麗的外表下，卻發現它賴以生存的數據基礎設施，正悄悄地走向一場「公地悲劇」。簡單來說，就是大家都想用，但卻沒人願意好好維護，最終導致資源枯竭，大家一起遭殃。
Goldsky 宕機事件：去中心化夢想的裂縫
當中心化數據平台罷工，DeFi 世界瞬間崩塌
想像一下，你是一位 DeFi 玩家，每天早上醒來的第一件事，就是打開你的錢包，看看昨天又賺了多少。結果，你發現前端一片空白，你的倉位消失了，餘額也歸零了！別慌，這不是你的錢被盜了，而是因為你所依賴的數據索引服務，也就是 Goldsky，它…宕機了！
今年七月，Goldsky 發生了一場長達六小時的「技術性故障」，直接導致以太坊生態系統中的大量項目陷入癱瘓。DeFi 前端無法顯示用戶的倉位和餘額數據，預測市場 Polymarket 無法顯示正確的賭盤信息。在用戶看來，這些 DApp 就像是突然得了失憶症，完全無法使用了。這場事故簡直就是一場小型災難，讓無數 Web3 開發者和用戶欲哭無淚。
免費的最貴：區塊鏈數據索引的盈利難題
區塊鏈技術的核心精神之一，就是去中心化。但 Goldsky 事件卻暴露了一個令人尷尬的事實：雖然區塊鏈本身力求去中心化，但建立在鏈上的應用程式，往往高度依賴中心化的基礎設施服務。這就像在一座號稱「永不沉沒」的巨輪上，卻發現救生艇只有一艘，而且還掌握在少數人手中。
究其原因，區塊鏈數據索引與檢索屬於典型的「非排他、非競爭性」數字公共產品。簡單來說，就是誰都可以用，而且用的人越多，它的價值就越高。但問題是，這種公共產品的背後，需要持續投入大量的硬件、存儲、帶寬和人力維護。使用者都希望免費或者以極低的價格使用，導致業者難以找到可持續的盈利模式。長期下來，就容易出現「贏家通吃」的局面：只要一家服務商在速度和資本上取得先發優勢，開發者便會傾向於將所有查詢流量導向該服務，從而重新形成單點依賴。這就像大家都在免費蹭 WiFi，結果電信公司倒閉了，所有人都沒網可用。
Gitcoin 等公益項目早就苦口婆心地呼籲：「開源基礎設施能創造數十億美元的價值，但作者卻往往無法靠它償還房貸」。這句話聽起來是不是很心酸？
DApp 開發者的自救指南：本地優先與容錯設計
Goldsky 事件無疑給我們敲響了警鐘。去中心化世界迫切需要通過公共產品資助、重新分配或社區驅動的舉措，來豐富 Web3 基礎設施的多樣性，否則中心化的問題只會愈演愈烈。我們呼籲 DApp 開發者構建本地優先的產品，也呼籲技術社群在 DApp 設計時考慮數據檢索服務失效的情況，保證用戶在無數據檢索基礎設施的情況下仍可以與項目交互。這就像在設計建築物時，除了考慮美觀和舒適，更要考慮地震和火災等突發狀況，確保建築物在任何情況下都能保障住戶的安全。
解構 DApp 的幕後英雄：數據從哪裡來？
數據檢索：DApp 的生命線
對於廣大的韭菜…啊不，是加密貨幣愛好者來說，DApp 通常只由兩個部分組成：鏈上合約和前端頁面。我們習慣用 Etherscan 查詢交易狀態，然後在 DApp 前端上獲取各種資訊，再通過前端發起交易，與智能合約互動。但你有沒有想過，那些顯示在前端的酷炫圖表、實時數據，甚至是你的帳戶餘額，究竟是從哪裡來的呢？難道是憑空冒出來的嗎？
別傻了！這些數據可不是天上掉下來的，而是 DApp 通過各種複雜的技術手段，從區塊鏈上「撈」出來的。這個「撈」的過程，就是我們所說的數據檢索。數據檢索對於 DApp 來說，就像是人體的血液循環系統，負責將營養物質（數據）輸送到身體的各個器官（前端），維持 DApp 的正常運轉。如果沒有數據檢索，DApp 就會變成一具空殼，什麼都做不了。
The Graph、Goldsky 與 Subgraph 的愛恨情仇
假設你是一位雄心勃勃的開發者，想要打造一個劃時代的借貸協議。這個協議需要向用戶展示他們的持倉情況，以及每個倉位的保證金和債務狀況。一個最直觀的想法是，前端直接從鏈上讀取這些數據。但理想很豐滿，現實很骨感。區塊鏈上的數據就像是一堆雜亂無章的檔案，你需要花費大量的時間和精力，才能從中找到你想要的資訊。
更糟糕的是，借貸協議的智能合約通常不允許使用戶地址直接查詢倉位數據，而是需要通過倉位 ID 才能查詢具體信息。這就像你要在浩瀚的書海中找到一本特定的書，但圖書館卻不提供目錄檢索功能，你只能一本本地翻，直到找到為止。這簡直就是一場噩夢！
因此，我們需要引入一些「黑科技」，來加速數據獲取。Goldsky 等公司，正是向用戶提供這種數據索引服務的。它們就像是圖書館的目錄檢索系統，可以幫助你快速找到你想要的數據。簡單來說，就是 Goldsky 幫你把鏈上的數據整理好，然後你就可以直接從 Goldsky 那裡獲取你需要的資訊，而不用自己去區塊鏈上撈了。
SubGraph 運營商：幕後的數據魔術師
看到這裡，有些同學可能會問：以太坊生態不是有一個去中心化的數據檢索平台 The Graph 嗎？它和 Goldsky 有什麼區別？為什麼這麼多 DeFi 項目不用 The Graph，反而選擇 Goldsky 呢？要回答這些問題，我們需要先了解一些技術概念。
- SubGraph: 這是一個開發框架，開發者可以使用它來編寫代碼，讀取並匯總鏈上數據，然後將這些數據顯示在前端。
- The Graph: 這是一個去中心化的數據檢索平台，它開發了一個叫做 SubGraph 的框架。開發者可以使用這個框架編寫程序，捕捉合約事件，然後將這些事件寫入到數據庫中。之後，用戶就可以利用 Graphql 方法讀取這些數據，或者直接使用 SQL 代碼讀取數據庫。
- SubGraph 運營商: 我們通常將運行 SubGraph 的服務提供商稱為 SubGraph 運營商。The Graph 和 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，然後 TheGraph 內部存在一些運營商可以幫助用戶檢索數據。
收費模式大亂鬥：Goldsky 的簡明 vs. The Graph 的玄妙
Goldsky：簡單粗暴，童叟無欺的 SaaS 模式
讓我們從 Goldsky 開始。他們的收費模式簡直可以用「簡單粗暴」來形容：就像你在 AWS 或 Google Cloud 上租用雲服務一樣，根據你使用的資源（例如 CPU、內存、存儲空間和帶寬）來計費。你用了多少，就付多少，清清楚楚，明明白白。對於那些習慣了傳統 Web2 開發模式的工程師來說，這種收費方式簡直是親切到家了，完全沒有學習成本。
The Graph：GRT 代幣經濟學的華麗冒險
接下來，讓我們看看 The Graph。他們的收費模式就比較…嗯…有個性了。它與 GRT 代幣的經濟模型緊密相連，涉及到 Indexer、Delegator、Curator 等各種角色，以及質押、Signal、Query Fee 等各種概念。如果你不是一個對加密貨幣有深入了解的技術專家，很可能會被搞得一頭霧水。
簡單來說，每次 DApp 或錢包向 Subgraph 發起請求，所支付的 Query Fee 會被自動拆分：1% 燒毀，約 10% 流入 Subgraph 的策展池（Curator / 開發者），其餘 ≈ 89% 按照指數返利機制打給提供算力的 Indexer 及其 Delegator。Indexer 需要先自質押 ≥ 100k GRT 才能上線；若返回錯誤數據將被懲罰（slashing）。Delegator 把 GRT 委託給 Indexer，按比例分得上述 89% 的大頭。Curator（通常就是開發者）通過 Signal 在自家 Subgraph 的債券曲線上質押 GRT；Signal 數越高，越能吸引 Indexer 分配資源。社區經驗建議自籌 5k–10k GRT 可保證數個 Indexer 接單。與此同時，策展人還能拿到那 10% Royalty。
除了上述复杂的收益分配机制，The Graph 还有两种收费方式：按次查詢費和 Signal 質押費。前者是指在 The Graph 後台註冊 API KEY，然後使用該 KEY 請求 The Graph 內運營商檢索的數據，這部分請求是按照請求次數收費的。你需要預先在平台內存入一部分 GRT 代幣，作為 API 請求的開銷。後者則是針對 Subgraph 的部署者，如果你希望 The Graph 平台內的運營商幫助你檢索數據，就需要質押 GRT，類似於打廣告以及給自己擔保有收益，大家才會來。
糟糕的體驗：開發者與會計的噩夢
對於大部分項目開發者來說，使用 The Graph 其實是一件相當麻煩的事情。購買 GRT 代幣對於 Web3 項目而言還算容易，但是對已部署的 Subgraph 進行 Curating 操作，等待運營商的過程就相當低效了。這一環節至少存在以下兩個問題：
- 質押 GRT 數量和吸引運營商所需時間的不確定性問題。筆者在過去部署 Subgraph 時直接諮詢了 The Graph 的社區大使，才確定了質押 GRT 的數量。但是對於大部分開發者而言，這個數據並不好獲得。另外，即使質押了充足的 GRT，運營商介入檢索也需要一段時間。
- 成本核算和會計的複雜性問題。由於 The Graph 使用代幣經濟學機制設計收費標準，這對大部分開發者而言，使成本計算變得複雜。更實際的問題是，如果企業要對該筆支出進行會計核算，會計可能也無法理解這部分成本構成。
去中心化萬歲？開發者：「給我一個中心化的懷抱吧！」
顯然，對於大部分開發者而言，直接選擇 Goldsky 才是更加簡單的事情。計費方式所有人都可以理解，同時只要付費幾乎可以立即可用，不確定性大幅度降低。這也導致了區塊鏈數據索引與檢索服務上，出現了依賴於單一產品的情況。一句話概括：The Graph 的代幣經濟學玩脫了！
代幣經濟學本身並沒有錯，它可以為項目帶來激勵和增長。但 The Graph 的問題在於，它把過多的複雜性暴露給了用戶。例如，GRT 的策展質押機制就不應該讓用戶直接參與，The Graph 更好的做法是直接給用戶一個簡化的付費頁面，讓他們像使用 AWS 一樣輕鬆上手。
順帶一提，這並不是我個人的觀點。知名智能合約工程師與 Sablier 項目創始人 Paul Razvan Berg 也曾在推文內表達過類似的看法，批評 The Graph 的 Subgraph 發布和 GRT 計費體驗非常糟糕。
數據檢索的救贖之路：尋找去中心化的替代方案
The Graph：理想很豐滿，現實很骨感？
在上一節中，我們狠狠地吐槽了 The Graph 的收費模式。但公平地說，The Graph 作為一個去中心化的數據檢索平台，其理念和願景是非常值得稱讚的。它試圖通過代幣經濟學，激勵更多的人參與到數據索引和檢索的過程中，從而構建一個更加開放、透明、抗審查的 Web3 數據基礎設施。
然而，理想很豐滿，現實很骨感。The Graph 的複雜收費模式，以及由此帶來的糟糕用戶體驗，嚴重阻礙了它的普及。很多開發者寧願選擇中心化的 Goldsky，也不願意花費大量的時間和精力，去學習和適應 The Graph 的那一套規則。這就像一個很有理想的餐廳，但菜單卻複雜到讓人看不懂，最終只能眼睜睜地看著顧客流向隔壁那家簡單粗暴的快餐店。
EVM 索引工具大觀園：百花齊放，各顯神通
除了 The Graph 和 Goldsky 之外，EVM 生態系統中還存在著大量的數據檢索工具。它們各有特色，各有優勢，可以滿足不同場景下的需求。如果你想了解更多關於這些工具的信息，可以參考 Dune 編寫的 The State of EVM Indexing，或者 rindexer 編寫的 EVM 數據檢索軟體匯總。當然，你也可以在 Google 上搜索 “EVM indexing tools”，找到更多相關資源。
另外，最近還有一些關於數據檢索的新討論，例如這篇推文就提出了一些有趣的觀點。總之，在數據檢索這個領域，可選擇的方案還是非常多的，關鍵在於找到最適合你自己的那一個。
Ponder：簡潔、高效、開發者友好的新選擇
Ponder 的三大優勢：擺脫依賴、極致體驗、卓越性能
在眾多數據檢索方案中，筆者今天要特別推薦一個叫做 Ponder 的工具。它就像一位默默耕耘的技術宅，不善於拋頭露面，但實力卻不容小覷。相比於其他商業公司提供的數據檢索服務，Ponder 最大的優勢在於：它沒有供應商依賴！換句話說，你不需要依賴任何第三方服務，就可以搭建自己的數據索引和檢索系統。
Ponder 最初是由個人開發者構建的項目，它只需要你填入以太坊 RPC URL 和 postgres 數據庫鏈接，就可以開始工作。這意味著，你可以完全掌控你的數據，避免被中心化服務商所綁架。這種感覺就像是自己種菜，雖然辛苦一點，但吃得放心。
除了擺脫依賴之外，Ponder 還提供了極佳的開發體驗。它使用 Typescript 編寫，並且核心庫主要依賴 Viem，這使得開發者可以非常輕鬆地上手。如果你是一位熟悉 Javascript 和 Typescript 的 Web3 開發者，那麼你一定會愛上 Ponder 的簡潔和優雅。
更重要的是，Ponder 具有更高的性能。它可以更快地檢索數據，並且可以處理更大的數據量。這意味著，你可以用 Ponder 構建更加快速、高效的 DApp。
Ponder 的商業化野心：隔離理論的完美應用
當然，Ponder 也不是完美的。它目前仍處於快速開發階段，可能會遇到一些 Bug 或者不兼容的問題。但總體來說，Ponder 是一個非常有潛力的數據檢索工具，值得每一個 Web3 開發者關注。
更值得一提的是，Ponder 已經開始了部分商業化。但與其他項目不同的是，Ponder 的商業化途徑非常巧妙，完美契合了上一篇文章內討論的「隔離理論」。
簡單回顧一下，「隔離理論」認為，公共物品的公共性使其可以服務任意多用戶，所以只要對公共物品收費，就會導致部分用戶不再使用公共物品，此時社會利益並不是最大化的。但如果我們能夠通過某種方法，將一部分同質人群隔離出來，然後對這部分人群徵收費用，就可以在不損害公共利益的前提下，實現商業化。
Ponder 正是運用了類似的思路。首先，Ponder 的部署仍然需要一定的技術知識，開發者需要提供 RPC、數據庫等外部依賴。同時，在部署完成後，開發者需要持續維護 Ponder 應用，例如使用 Proxy 系統進行負載均衡，避免數據請求影響 Ponder 在後台线程內檢索鏈上數據。這些對於一般的開發者來說，都稍有複雜。
但如果你不想自己部署和維護 Ponder，那麼你可以選擇使用 Ponder 官方提供的全自動部署服務 Marble。你只需要將代碼交付給 Marble 平台，就可以實現自動部署。這顯然是一種對「隔離理論」的應用：那些不願意自己維護 Ponder 服務的開發者被隔離出來，然後通過付費獲得 Ponder 服務的簡化部署。但同時，Marble 平台的出現也沒有影響其他開發者免費使用 Ponder 框架，並且自託管部署。
Ponder vs. Goldsky：誰才是你的真命天子？
那麼，Ponder 和 Goldsky 到底適合哪些用戶呢？總體來說，Ponder 這種完全沒有供應商依賴的公共物品，比其他依賴供應商的數據檢索服務，在開發小型項目時更加流行。而某些運營有大型項目的開發者，並不一定會選擇 Ponder 框架，因為大型項目往往要求檢索服務具有充分的性能，Goldsky 等服務提供商往往提供了充分的可用性保障。
但無論你選擇 Ponder 還是 Goldsky，都存在一些風險點。從最近的 Goldsky 事件來看，開發者最好自行維護一套自己的 Ponder 服務，以隨時應對可能的第三方服務宕機。以及使用 Ponder 時，可能要考慮 RPC 返回數據的有效性問題。不久前，Safe 就報告了一次因為 RPC 返回錯誤數據導致檢索器崩潰的情況。雖然沒有直接證據表明 Goldsky 事件也與 RPC 返回無效事件有關，但筆者懷疑 Goldsky 可能也遇到了類似事件。
Local-First：即使世界崩塌，也要保持可用！
Local-First 的真諦：離線工作與協同至上
Local-first 是一個在過去幾年一直被人津津樂道的話題。簡單來說，它指的是一種以本地為先的軟體開發理念，強調軟體應該能夠在離線狀態下正常工作，並且能夠跨客戶端協同。這就像你在使用 Google Docs 時，即使斷網了，你仍然可以繼續編輯文檔，並且在恢復連接後，你的修改會自動同步到雲端。
目前大部分與 local-first 相關的技術討論，都會涉及到 CRDT (Conflict-free Replicated Data Type) 技術。所謂 CRDT，是一種無衝突的數據格式，該格式允許用戶在多端操作時自動合併衝突，以保持數據的完整性。你可以把 CRDT 視為一種帶有簡單共識協議的數據類型，在分布式情況下，它可以保證數據的完整性和一致性。
區塊鏈世界的 Local-First：緩存、降級與韌性
但在區塊鏈開發中，我們可以稍微放寬 Local-first 對軟體要求的限制。我們僅要求在沒有項目開發者提供的後端索引數據時，用戶在前端仍然可以保持最低限度的可用性。同時，local-first 對跨客戶端協同的要求，實際上已經由區塊鏈解決了。因為區塊鏈本身就是一個去中心化的數據庫，它可以保證數據在多個客戶端之間的一致性。
那麼，如何在 DApp 的場景下實現 local-first 呢？筆者認為，可以從以下幾個方面入手：
- 緩存關鍵數據： 前端應該緩存用戶的重要數據，例如餘額、持倉信息等。即使索引服務不可用，用戶仍然能看到最後已知的狀態。這就像你在手機上瀏覽網頁時，即使沒有網路連接，你仍然可以查看之前緩存的頁面。
- 降級功能設計： 當後端索引服務不可用時，DApp 可以提供基礎功能。例如，在數據檢索服務不可用時，部分數據可以考慮直接利用 RPC 讀取鏈上數據，以保證用戶看到已有部分數據的最新情況。這就像你在使用地圖導航時，如果 GPS 信號不好，地圖仍然可以根據你輸入的目的地，提供大致的路線。
極致 Local-First：在本地跑節點，自己動手，豐衣足食
當然，如果你是一位追求極致的 Web3 開發者，那麼你可以考慮在本地運行節點，然後使用類似 TrueBlocks 的工具，在本地檢索數據。這種方式可以讓你完全掌控你的數據，並且可以避免對任何第三方服務的依賴。但同時，它也需要你具備一定的技術知識，並且需要你付出更多的時間和精力。
總之，local-first 的 DApp 設計理念能夠顯著提高應用的韌性，避免在數據檢索服務崩潰後，應用無法使用的尷尬局面。關於去中心化檢索或本地檢索的一些討論，可以參考這篇推文：Literally no one cares about decentralized frontends and indexers。
警鐘長鳴：Web3 基礎設施的脆弱性
Goldsky 六小時宕機事件，就像一顆投入平靜湖面的石子，激起了層層漣漪，也為整個 Web3 生態敲響了警鐘。雖然區塊鏈本身具有去中心化和抗單點故障的特性，但構建在其上的應用生態系統，仍然高度依賴中心化的基礎設施服務。這種依賴，就像一顆不定時炸彈，隨時可能引爆，給整個生態系統帶來系統性風險。
本文簡單介紹了早有盛名的去中心化檢索服務 The Graph，以及它為什麼在今天並沒有被廣泛使用。我們特別討論了 GRT 代幣經濟學帶來的一些複雜性，並指出這種複雜性阻礙了 The Graph 的普及。此外，本文還討論了如何構建更加健壯的數據檢索基礎設施，鼓勵開發者使用 Ponder 自託管的數據檢索開發框架作為應急響應選項，同時也介紹了 Ponder 的商業化路徑。
最後，本文還討論了 Local-first 的開發理念，鼓勵開發者構建在無數據檢索服務下仍然可以使用的應用。總之，我們希望通過本文，喚起更多開發者對 Web3 基礎設施的關注，並鼓勵他們積極參與到去中心化數據檢索服務的構建中來。
從目前來看，不少 Web3 的開發者都已經意識到了數據檢索服務的單點故障問題。GCC 希望更多的開發者關注這一基礎設施，並嘗試構建去中心化的數據檢索服務，或者設計一套框架，使得 DApp 前端在無數據檢索服務的情況下仍然可以運行。