# 為什麼 Web3 讀不了？
再幾年前，業界還在爭論如何提升區塊鏈的吞吐量。如今，許多網路已能處理數以萬計的交易，而有些則宣稱能達到數十萬。然而，結果證明：把資料寫進區塊鏈只完成任務的一半。還得把它找出來、建索引、驗證並交付給應用程式。
因此，資料產生速度在某些地方已超過其處理能力。區塊鏈為此會如何改變——ForkLog 已整理。
大約十年前，人們常用所謂「可擴展性三難困境」來描述區塊鏈的發展。根據這一概念，網路被迫在安全性、去中心化與效能之間尋找折衷。但到了 2026 年，顯而易見的是：即使吞吐量問題能夠被部分解決，也會出現新的挑戰。
區塊鏈本身沒有使用者介面。這個角色由各種應用程式承擔。而它們反過來必須持續取得資料：
網路運作得越快，這類資料就需要被處理得越多
在使用者之間，流傳著一個普遍誤解：只要資訊已寫入區塊鏈，就表示很容易取得。實際上恰恰相反。要在即時的情況下直接從區塊鏈讀取「原始」資料，是一個緩慢、昂貴且在技術上相當複雜的流程。在 Web3 生態系中，廣泛存在一層中介的基礎設施，用來把錢包連到 dapp 應用程式。
例如，一個錢包應用程式要讓使用者在幾分之一秒內看到自己的餘額，會向 RPC 供應商、索引器（indexers）、分析平台、快取伺服器、專用資料庫等發出請求。
整個流程如下：
事實上，多數熱門的 Web3 應用程式都會透過額外的資訊處理層運作。想像如果區塊鏈每秒處理 50,000 筆交易（TPS），而數百萬個錢包同時送出 RPC 請求以更新畫面。供應商的伺服器無法承受這種負載。為使用者讀取、建索引並排序資料，這是最困難的計算任務。索引器與資料存取服務，往往也會比網路的最新狀態落後數個區塊，因為資料的處理、結構化與交付都需要額外時間。問題不只是「過時的基礎設施」（當然，這當中也確實存在這種情況）。更關鍵的是 Web2 與 Web3 的架構之間存在深層的衝突
使用者與應用程式與區塊鏈的互動頻率，就如同在傳統網路中追求即時回應那樣積極且頻繁。當你捲動社群媒體的動態時，應用程式會在每秒向伺服器發出成千上萬次請求，以更新按讚、留言與圖片。在 Web2 中，交易機器人每分鐘甚至可能向交易所伺服器查詢數百萬次。Google 或 Amazon 的伺服器能輕鬆承受，因為它們是集中式的：資料大致存放在同一個巨大的資料庫中，從那裡可以立刻複製到全世界成千上萬台的鏡像伺服器。
但區塊鏈的運作方式不同，它在硬體層面也不支援這種做法。直到不久之前，區塊鏈速度的主要阻礙還是數學與密碼學。必須讓全世界的成千上萬台電腦能夠快速達成一致（共識），確認交易是正確的。開發者透過「教會」機器進行平行執行，並把共識與執行分離，解決了這個問題。例如 Solana、Monad 與 Aptos 支援平行執行相互獨立的交易；不同於以太坊的經典逐筆順序模型。與此同時，Monad 特別清楚地把交易順序的協調與其後續執行分開，而在 Solana 與 Aptos 中，平行性是透過 runtime 架構與依狀態進行衝突管理來實現的。
因此，就可以在每秒核准數以萬計的交易（TPS）。但陷阱就在這裡。
從歷史上看，區塊鏈同時扮演著四種功能：
效能提升會讓這四種功能同時承受更大的負載。系統產生資料的速度，比基礎設施讀取資料的速度更快，於是就出現所謂的 indexer gap。
在 Helius（Solana 生態系中最大型的基礎設施供應商之一）的文件中，甚至直接指出：區塊鏈的序列式結構很適合用於確保資料完整性與高吞吐量，但它會讓歷史查詢變慢且無效率。因此，多數公司被迫在區塊鏈之上自建索引器與獨立資料庫。
ChainScore Labs 的分析師稱 indexer gap 是 Solana 生態系的關鍵問題之一。依他們的評估，傳統的索引方法難以應對這種網路架構：高頻出塊與平行交易執行會產生龐大的資料流。
於是形成這樣的效果：網路可以幾乎瞬間地確認交易，但應用程式卻需要更多時間來處理這些交易的後果。
更準確地說，是卡在處理器、硬碟與網路纜線的吞吐量。原來區塊鏈的可擴展性並不等於其周邊基礎設施的可擴展性。必須盡快把這件事解決。
假設有一個網路，每秒 100,000 TPS。你不只要把交易寫入，還得：
因此，高吞吐量會在共識、交易執行以及網路之上的基礎設施服務之間，形成對資源的競爭。
參與其中的一些技術的並行發展，迫使這個問題得在現在就被解決。對人而言，延遲到幾秒甚至幾分鐘可能還算可忍受。對 AI 代理、交易系統與自動化服務而言，則不行。如果一台機器的決策基於鏈上資料，那麼過時資訊就意味著錯誤、失去機會，甚至是直接的財務損失。
同時，Ethereum Foundation 在 2026 年更新的文件中指出：歸檔節點需要 3 到 12 TB 的磁碟空間，而即使在相當強的硬體上，初始同步也可能需要長達 1 個月。限制因素在於 SSD 速度、記憶體容量與處理器效能。
此外，Geth 的開發者也分別描述了舊的歸檔儲存模型：以太坊的資料庫大小可能超過 20 TB，且同步需要數月。正因如此，才不得不打造新的 path-based 儲存架構。
也就是說，是的，「硬體」——處理器、網路吞吐量、CPU——確實是資訊成長競賽中的真實物理限制。但這不是唯一的。現代伺服器已能處理龐大的資料量。問題在於：成千上萬個獨立參與者，必須為此付出多少代價？
例如，如果完整參與生態系需要數十 TB 的 SSD、數百 GB 的 RAM、昂貴的通訊頻道，那麼基礎設施營運者的數量必然會縮減。於是就形成了新的中心化。
在形式上，處理資料是做得到的，但同時要做到又便宜又去中心化，卻不可能。資訊處理成本開始成長得比交易本身的成本更快。
參與競速的人已經明白：最後的贏家將是那些能更快、更便宜、更可靠地把交易轉成可用資訊的網路。而在今年，市場的關注點卻出現了意外的轉移：轉向模組化區塊鏈。
如果第一代網路嘗試把所有任務都在同一個系統中完成，那麼新一代會把職責分配給不同的專用層。取代單一網路，出現了分離的各層：
開發者把這個過程類比成資料中心的演化。過去，一台伺服器同時完成所有功能。今天，運算、資料儲存與網路服務可以彼此獨立地擴展。
市場中成長最快的方向之一，是 DA 網路。乍看之下，這個想法有點怪：為什麼要建立一條用於暫時儲存另一條區塊鏈資料的獨立區塊鏈？但其實正是如此。在模組化架構中，交易執行與資料儲存可以分開存在。Rollup 把資料發布到外部的 DA 層，而不是主網路。這能大幅降低擴展成本並提高吞吐量。
再過幾年前，RPC 還只是技術細節。如今，它已是最重要的加密基礎設施元素之一。2026 年 5 月，Triton One 與 Solana Foundation 共同發布了更新版的 RPC 2.0 公告——這是一種新的網路資料讀取架構方法。
它的核心想法在於把「網路的當前狀態」與「其歷史」的存取分離。為此，引入兩個彼此獨立的模組：一個模組會在即時索引帳戶狀態，另一個則會優化對歷史資料的處理。系統不再需要對整條區塊鏈進行完整掃描，而是會根據特定應用程式的請求建立自適應的索引，從而降低延遲與處理成本。
因此 Triton 與 Solana 正在嘗試消除一系列系統性限制：昂貴且低效率的 RPC 節點單體式架構、JSON-RPC 標準請求的種類過於狹窄，以及開發者對自有或專有解決方案來處理資料的依賴。在新的讀取模型中，讀取可以獨立於共識來擴展，而歷史的存取也能因使用欄柱式儲存與預先排序的資料而變得更快。
該計畫依賴已在生態系中落地的工具——包括從驗證者（Geyser、Yellowstone gRPC）進行資料串流傳輸，以及處理歷史的解決方案。整個基礎設施以開源形式散佈，並在 Solana Foundation 的參與下協調其發展。
結果是，Solana 實際上正試圖從「通用型」RPC，轉向模組化且專門化的資料基礎設施；據稱它能降低開發者的門檻，並讓處理區塊鏈資料的便利性接近傳統資料庫。
如果 Solana 能成功標準化讀取層，那可能會強化它作為「具有成熟應用基礎設施的網路」而不只是「吞吐量高」的地位。但同時，它也會加劇與獨立 RPC 供應商及基礎設施平台的競爭：這些夥伴要嘛得配合新的標準，要嘛就得在其上再提供額外服務。
模組化架構能消除部分基礎設施限制，但也把它們轉移到了系統的其他層。降低成本、簡化資料存取的需求是明確的；沒有這些就無法運作 DeFi、NFT、錢包、分析以及合規（compliance）工具。然而，似乎 Web3 的本質中就內建了「級聯式複雜化」的效果：解決一個任務，必然會產生新的挑戰。
新的方案顯然需要更複雜的基礎設施上層：包含索引器、儲存、快取、獨立的管線，以及新的失效點。生態系可能不再只有一個單一、簡單的 RPC 層，而是得到數個平行的實作、彼此不相容的最佳化，以及對基礎設施供應商更大的依賴。在這種情況下，形式上開放的架構未必一定代表真正對所有人都開放且好用的存取模型。
目前，我們仍處在市場從「誰能更好地從網路取得資料」的競爭，轉為「誰會最先用這些資料做出產品」的階段。誰要付多少錢——可能我們很快就會知道了
118.41萬 熱度
23.24萬 熱度
77.04萬 熱度
18.67萬 熱度
23.8萬 熱度
為什麼 Web3 不會讀取－ForkLog
再幾年前，業界還在爭論如何提升區塊鏈的吞吐量。如今，許多網路已能處理數以萬計的交易，而有些則宣稱能達到數十萬。然而，結果證明：把資料寫進區塊鏈只完成任務的一半。還得把它找出來、建索引、驗證並交付給應用程式。
因此，資料產生速度在某些地方已超過其處理能力。區塊鏈為此會如何改變——ForkLog 已整理。
越快，越久
大約十年前，人們常用所謂「可擴展性三難困境」來描述區塊鏈的發展。根據這一概念，網路被迫在安全性、去中心化與效能之間尋找折衷。但到了 2026 年，顯而易見的是：即使吞吐量問題能夠被部分解決，也會出現新的挑戰。
區塊鏈本身沒有使用者介面。這個角色由各種應用程式承擔。而它們反過來必須持續取得資料：
網路運作得越快，這類資料就需要被處理得越多
在使用者之間，流傳著一個普遍誤解：只要資訊已寫入區塊鏈，就表示很容易取得。實際上恰恰相反。要在即時的情況下直接從區塊鏈讀取「原始」資料，是一個緩慢、昂貴且在技術上相當複雜的流程。在 Web3 生態系中，廣泛存在一層中介的基礎設施，用來把錢包連到 dapp 應用程式。
例如，一個錢包應用程式要讓使用者在幾分之一秒內看到自己的餘額，會向 RPC 供應商、索引器（indexers）、分析平台、快取伺服器、專用資料庫等發出請求。
整個流程如下：
事實上，多數熱門的 Web3 應用程式都會透過額外的資訊處理層運作。想像如果區塊鏈每秒處理 50,000 筆交易（TPS），而數百萬個錢包同時送出 RPC 請求以更新畫面。供應商的伺服器無法承受這種負載。為使用者讀取、建索引並排序資料，這是最困難的計算任務。索引器與資料存取服務，往往也會比網路的最新狀態落後數個區塊，因為資料的處理、結構化與交付都需要額外時間。問題不只是「過時的基礎設施」（當然，這當中也確實存在這種情況）。更關鍵的是 Web2 與 Web3 的架構之間存在深層的衝突
使用者與應用程式與區塊鏈的互動頻率，就如同在傳統網路中追求即時回應那樣積極且頻繁。當你捲動社群媒體的動態時，應用程式會在每秒向伺服器發出成千上萬次請求，以更新按讚、留言與圖片。在 Web2 中，交易機器人每分鐘甚至可能向交易所伺服器查詢數百萬次。Google 或 Amazon 的伺服器能輕鬆承受，因為它們是集中式的：資料大致存放在同一個巨大的資料庫中，從那裡可以立刻複製到全世界成千上萬台的鏡像伺服器。
但區塊鏈的運作方式不同，它在硬體層面也不支援這種做法。直到不久之前，區塊鏈速度的主要阻礙還是數學與密碼學。必須讓全世界的成千上萬台電腦能夠快速達成一致（共識），確認交易是正確的。開發者透過「教會」機器進行平行執行，並把共識與執行分離，解決了這個問題。例如 Solana、Monad 與 Aptos 支援平行執行相互獨立的交易；不同於以太坊的經典逐筆順序模型。與此同時，Monad 特別清楚地把交易順序的協調與其後續執行分開，而在 Solana 與 Aptos 中，平行性是透過 runtime 架構與依狀態進行衝突管理來實現的。
因此，就可以在每秒核准數以萬計的交易（TPS）。但陷阱就在這裡。
從歷史上看，區塊鏈同時扮演著四種功能：
效能提升會讓這四種功能同時承受更大的負載。系統產生資料的速度，比基礎設施讀取資料的速度更快，於是就出現所謂的 indexer gap。
在 Helius（Solana 生態系中最大型的基礎設施供應商之一）的文件中，甚至直接指出：區塊鏈的序列式結構很適合用於確保資料完整性與高吞吐量，但它會讓歷史查詢變慢且無效率。因此，多數公司被迫在區塊鏈之上自建索引器與獨立資料庫。
ChainScore Labs 的分析師稱 indexer gap 是 Solana 生態系的關鍵問題之一。依他們的評估，傳統的索引方法難以應對這種網路架構：高頻出塊與平行交易執行會產生龐大的資料流。
於是形成這樣的效果：網路可以幾乎瞬間地確認交易，但應用程式卻需要更多時間來處理這些交易的後果。
Web3 的速度卡在了樸素的物理（不只如此）
更準確地說，是卡在處理器、硬碟與網路纜線的吞吐量。原來區塊鏈的可擴展性並不等於其周邊基礎設施的可擴展性。必須盡快把這件事解決。
假設有一個網路，每秒 100,000 TPS。你不只要把交易寫入，還得：
因此，高吞吐量會在共識、交易執行以及網路之上的基礎設施服務之間，形成對資源的競爭。
參與其中的一些技術的並行發展，迫使這個問題得在現在就被解決。對人而言，延遲到幾秒甚至幾分鐘可能還算可忍受。對 AI 代理、交易系統與自動化服務而言，則不行。如果一台機器的決策基於鏈上資料，那麼過時資訊就意味著錯誤、失去機會，甚至是直接的財務損失。
同時，Ethereum Foundation 在 2026 年更新的文件中指出：歸檔節點需要 3 到 12 TB 的磁碟空間，而即使在相當強的硬體上，初始同步也可能需要長達 1 個月。限制因素在於 SSD 速度、記憶體容量與處理器效能。
此外，Geth 的開發者也分別描述了舊的歸檔儲存模型：以太坊的資料庫大小可能超過 20 TB，且同步需要數月。正因如此，才不得不打造新的 path-based 儲存架構。
也就是說，是的，「硬體」——處理器、網路吞吐量、CPU——確實是資訊成長競賽中的真實物理限制。但這不是唯一的。現代伺服器已能處理龐大的資料量。問題在於：成千上萬個獨立參與者，必須為此付出多少代價？
例如，如果完整參與生態系需要數十 TB 的 SSD、數百 GB 的 RAM、昂貴的通訊頻道，那麼基礎設施營運者的數量必然會縮減。於是就形成了新的中心化。
在形式上，處理資料是做得到的，但同時要做到又便宜又去中心化，卻不可能。資訊處理成本開始成長得比交易本身的成本更快。
市場如何反應
參與競速的人已經明白：最後的贏家將是那些能更快、更便宜、更可靠地把交易轉成可用資訊的網路。而在今年，市場的關注點卻出現了意外的轉移：轉向模組化區塊鏈。
如果第一代網路嘗試把所有任務都在同一個系統中完成，那麼新一代會把職責分配給不同的專用層。取代單一網路，出現了分離的各層：
開發者把這個過程類比成資料中心的演化。過去，一台伺服器同時完成所有功能。今天，運算、資料儲存與網路服務可以彼此獨立地擴展。
市場中成長最快的方向之一，是 DA 網路。乍看之下，這個想法有點怪：為什麼要建立一條用於暫時儲存另一條區塊鏈資料的獨立區塊鏈？但其實正是如此。在模組化架構中，交易執行與資料儲存可以分開存在。Rollup 把資料發布到外部的 DA 層，而不是主網路。這能大幅降低擴展成本並提高吞吐量。
再過幾年前，RPC 還只是技術細節。如今，它已是最重要的加密基礎設施元素之一。2026 年 5 月，Triton One 與 Solana Foundation 共同發布了更新版的 RPC 2.0 公告——這是一種新的網路資料讀取架構方法。
它的核心想法在於把「網路的當前狀態」與「其歷史」的存取分離。為此，引入兩個彼此獨立的模組：一個模組會在即時索引帳戶狀態，另一個則會優化對歷史資料的處理。系統不再需要對整條區塊鏈進行完整掃描，而是會根據特定應用程式的請求建立自適應的索引，從而降低延遲與處理成本。
因此 Triton 與 Solana 正在嘗試消除一系列系統性限制：昂貴且低效率的 RPC 節點單體式架構、JSON-RPC 標準請求的種類過於狹窄，以及開發者對自有或專有解決方案來處理資料的依賴。在新的讀取模型中，讀取可以獨立於共識來擴展，而歷史的存取也能因使用欄柱式儲存與預先排序的資料而變得更快。
該計畫依賴已在生態系中落地的工具——包括從驗證者（Geyser、Yellowstone gRPC）進行資料串流傳輸，以及處理歷史的解決方案。整個基礎設施以開源形式散佈，並在 Solana Foundation 的參與下協調其發展。
結果是，Solana 實際上正試圖從「通用型」RPC，轉向模組化且專門化的資料基礎設施；據稱它能降低開發者的門檻，並讓處理區塊鏈資料的便利性接近傳統資料庫。
模組化真的解決問題嗎？
如果 Solana 能成功標準化讀取層，那可能會強化它作為「具有成熟應用基礎設施的網路」而不只是「吞吐量高」的地位。但同時，它也會加劇與獨立 RPC 供應商及基礎設施平台的競爭：這些夥伴要嘛得配合新的標準，要嘛就得在其上再提供額外服務。
模組化架構能消除部分基礎設施限制，但也把它們轉移到了系統的其他層。降低成本、簡化資料存取的需求是明確的；沒有這些就無法運作 DeFi、NFT、錢包、分析以及合規（compliance）工具。然而，似乎 Web3 的本質中就內建了「級聯式複雜化」的效果：解決一個任務，必然會產生新的挑戰。
新的方案顯然需要更複雜的基礎設施上層：包含索引器、儲存、快取、獨立的管線，以及新的失效點。生態系可能不再只有一個單一、簡單的 RPC 層，而是得到數個平行的實作、彼此不相容的最佳化，以及對基礎設施供應商更大的依賴。在這種情況下，形式上開放的架構未必一定代表真正對所有人都開放且好用的存取模型。
目前，我們仍處在市場從「誰能更好地從網路取得資料」的競爭，轉為「誰會最先用這些資料做出產品」的階段。誰要付多少錢——可能我們很快就會知道了