--- id: 6 title: 去中心化 AI 堆疊：為什麼執行層決定 Web3 與 AI 能否協同 slug: aibitrootweb3ai date: 2026/07/28 summary: Web3 與 AI 的融合不只是敘事疊加。本文從 AI Agent 的鏈上行為、算力排程與結果可驗證三條線索，說明執行層為什麼成為去中心化 AI 堆疊的瓶頸，以及 Bitroot 相關能力如何各司其職。 keywords: 去中心化AI堆疊,Web3,AI Agent,執行層,Bitroot heroImage: /cms-media/file/1The%20Future%20of%20Decentralized%20AI%20Stack.jpg --- 把 Web3 和 AI 寫進同一張簡報很容易，真正難的是讓兩者在同一條鏈上協同工作。AI 需要吞吐量、低延遲和可編排的運算資源；Web3 需要可驗證、抗操縱與明確的權責邊界。兩邊的目標並不天然相容。本文不討論口號，而是把「去中心化 AI 堆疊」拆成幾層，說明執行層為什麼往往是最先卡住的那一層。 ## AI 側缺的不是模型，是可信的執行環境 主流大模型的訓練與推論仍高度集中在少數雲端廠商。問題不只是供應商鎖定，更在於：呼叫方很難獨立核驗「用了哪個模型版本、吃了哪些輸入、產出是否被竄改」。對普通的聊天應用，這或許可以接受；對要自動調倉、結算、觸發合約的 AI Agent 而言，黑箱就是系統性風險。 Web3 本應補上可驗證性，但多數公鏈的執行層仍按「人類使用者偶爾點一次交易」來設計。Agent 可能在短時間內發出大量相互依賴的交易：詢價、拆單、跨協議呼叫、事後對帳。若鏈上確認慢、衝突處理粗暴、費用波動大，Agent 要嘛退化成鏈下編排偶爾上鏈，要嘛在壅塞時失效。關於單執行緒 EVM 為何撐不住這類負載，可參見 [《EVM 單執行緒瓶頸》](/zh-Hant/blog/evm-single-thread-bottleneck)。 ## 堆疊視角：五層各管一件事 用堆疊而不是「全棧敘事」來看，去中心化 AI 大致需要五層能力，且層與層之間應解耦： 1. **結算與合約執行層**：決定狀態誰先誰後、衝突如何收斂。沒有足夠快且可預期的最終性，上層的 Agent 編排就沒有意義。 2. **算力排程層**：把訓練/推論任務分發給異構 GPU 或邊緣節點，記錄任務中繼資料與完成證明，而不是假裝「鏈上直接訓練千億參數模型」。 3. **可驗證運算層**：用零知識證明、TEE 或 MPC 等手段，讓「算過什麼」可被第三方抽查，細節見 [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework)。 4. **資料與模型確權層**：貢獻者、模型版本、收益分成需要可執行的規則，而不是白皮書承諾，見 [《AI 資產確權》](/zh-Hant/blog/ai-data-ownership)。 5. **應用與 Agent 層**：策略、風控、人機協同邏輯；應盡量把重運算放在鏈下或專用算力網路，把結算與關鍵狀態變更留在鏈上。 Bitroot 的敘事落點，主要在第 1 層（樂觀平行 EVM）以及與第 2、3 層的銜接：鏈負責排序與結算，算力網路負責重負載，可信運算負責抽查與隱私邊界。產品定位的完整說明見 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。算力介面的邊界見 [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)；「AI 原生」能力清單見 [《AI 原生區塊鏈》](/zh-Hant/blog/ai-native-blockchain)。 ## 為什麼「執行層」特別關鍵 很多人把 AI × 鏈的瓶頸歸咎於「Gas 太貴」或「沒有原生 AI opcode」。更常見的失敗模式其實是：共識已經給出交易順序，執行卻跟不上，或者一遇到熱點合約就退化成近似串列。對 Agent 而言，這意味著： - **延遲不可預期**：同一策略在不同壅塞程度下行為漂移，難以做風控。 - **可組合性打折**：多協議的原子操作更容易觸發衝突與重新執行，吞吐量被熱點拖垮，參見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 - **驗證成本上升**：節點若無法高效重放平行結果，去中心化驗證會變成紙上承諾。 因此，平行執行、共識與執行解耦，以及明確的衝突偵測，不是「為了刷 TPS」，而是給自動化實體一個可規劃的結算基板。機制地圖見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)、[《Pipeline BFT 與執行解耦》](/zh-Hant/blog/bitroot-pipeline-bft)、[《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-)。 Bitroot 在測試網口徑下披露過單分片數千至數萬 TPS 量級、確認延遲約秒級乃至亞秒級的工程目標與測試結果；具體數字依賴硬體、負載與衝突率，不代表主網的穩定表現，也不構成任何收益承諾。讀指標的方式見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。 ## 該警惕的敘事陷阱 - **鏈上訓練神話**：完整的預訓練幾乎必然發生在鏈下或專用網路；鏈更適合記錄任務、支付與驗證摘要。 - **把算力挖礦寫成理財**：分散式 GPU 網路可以降低閒置率，但不等於穩定收益。 - **用相容性口號代替工程**：真正的 EVM 相容要落實到位元組碼與工具鏈，見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。 - **用「融合」掩蓋信任缺口**：缺口清單見 [《Web3 與 AI 融合》](/zh-Hant/blog/web3-ai-convergence)。 ## 落地時先建哪一層 若資源有限，建議的順序是：先讓結算延遲在自動化負載下可預期，再掛上任務/支付與最薄的驗收，然後按威脅模型引入 TEE 或 ZK，最後做複雜確權與市集。反過來先做模型商城而結算仍會抖動，只會放大爭議。去中心化與效能的張力見 [《去中心化與效能的權衡》](/zh-Hant/blog/decentralization-performance-tradeoff)；讀者入口見 [《誰該讀平行 EVM》](/zh-Hant/blog/who-should-read-parallel-evm)。 ## 層與層之間的失敗如何傳染 堆疊的價值在於解耦，失敗卻會沿著介面傳染。算力層的驗收含糊時，結算層只會忠實地執行錯誤的分帳；確權層缺失時，Agent 應用層只能把平台條款當成最終真相；執行層的衝突失控時，上層再完美的策略編排也會在費用與延遲上崩潰。因此「先畫五層」不是為了多寫幾個模組名稱，而是為了給每個介面規定：輸入是什麼、驗收是什麼、失敗時狀態停在哪裡。 對開發者而言，優先整合的順序建議是：先在平行 EVM 上把任務/支付狀態機跑穩，再接算力排程與證明，最後才做面向終端的 Agent 體驗。反過來從聊天機器人倒推上鏈，幾乎總會在確認延遲與不可驗證的輸出上返工。相容與工具鏈的約束見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。 ## 評估清單：讀專案資料時看什麼 遇到「去中心化 AI」專案時，建議至少核對：結算層是否給出衝突率與重放成本，而不只是峰值 TPS；算力層是否描述驗收與挑戰，而不只是 GPU 數量；確權層是否有撤銷與分帳狀態機，而不只是鑄造圖片；可信運算是否寫明對手模型，而不只是名詞堆疊。 Bitroot 的相關材料應放在同一份清單下閱讀：平行 EVM 與 Pipeline BFT 負責結算基板，算力與可信運算負責鏈下重負載與抽查，確權負責規則執行。任何把四者合併成一句「AI 公鏈已就緒」的表述，都值得拆回清單逐項打勾。定位見 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。 堆疊地圖的用處是減少範疇錯誤：不要用結算層解決訓練問題，不要用算力層解決最終性問題，不要用確權 NFT 解決驗收問題。分清範疇之後，Web3 與 AI 的協同才有可討論的介面。 ## 與系列機制文的閱讀順序 若目標是理解結算基板，建議順序為：單執行緒瓶頸與擴容地圖 → 三條平行路線與 OCC 入門 → 本文的堆疊地圖 → 平行 EVM 架構概覽與定位。若目標是 AI 產品，則在堆疊地圖之後讀信任缺口、可信運算、算力網路與確權。兩條路徑都指向同一件事實：沒有可預期的執行層，上層敘事就無法穩定交付。 ## 小結 去中心化 AI 堆疊能否成立，取決於能否把「智慧」放在可驗證的邊界內，同時把「結算」做得夠快、夠確定。執行層是這條鏈路上最先被 Agent 壓測的部分。後續文章分別展開平行架構、可信運算與確權；本文只建立分層地圖，避免把所有問題塞進一句「Web3 + AI」。 ## 延伸閱讀 - [《Web3 與 AI 融合：信任缺口在哪裡》](/zh-Hant/blog/web3-ai-convergence) - [《Bitroot 平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm) - [《AI 原生區塊鏈需要哪些能力》](/zh-Hant/blog/ai-native-blockchain)