--- id: 9 title: AI 原生區塊鏈需要哪些能力：指令擴充、混合執行與算力網路邊界 slug: ai-native-blockchain date: 2026/08/17 summary: 說明「AI 原生」若要成立，通常需要哪些可核對的能力：可選的指令/預編譯擴充、混合執行路徑、分散式算力排程，以及與樂觀平行結算層、可信運算的分工；並區分工程目標與主網承諾。 keywords: AI原生區塊鏈,混合執行,指令擴充,分散式算力,Bitroot heroImage: /images/community-bg.png --- 「AI 原生」容易被寫成功能清單：多幾個 opcode、掛一張 GPU 網、再貼上 ZK。更有用的問法是：鏈上狀態機到底要原生承擔哪些 AI 相關職責、哪些必須留在鏈下，以及結算層吞吐量為什麼仍然是前置條件。本文按能力邊界拆解，而不是按願景堆形容詞。 ## 「原生」相對於什麼 常見的淺層整合是：合約透過預言機或中心化 API 拉一次模型結果，再把結果寫進狀態。延遲、信任假設與可組合性都落在預言機一側；鏈本身對「用了哪個模型、輸入是否被替換」幾乎沒有約束。 更偏「原生」的路徑通常至少包含三件事： 1. **合約可表達的 AI 相關原語**（擴充指令、預編譯或標準介面），而不是每次都發明私有橋； 2. **混合執行**：輕量可驗證的步驟可走鏈上/近鏈路徑，重訓練與大推論走算力網路，結果以證明或挑戰期回到結算層； 3. **與結算層解耦清晰**：平行 EVM 解決的是合約狀態轉換的寬度，不是把千億參數的訓練塞進區塊執行。 堆疊總圖見 [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)；信任缺口清單見 [《Web3 與 AI 融合》](/zh-Hant/blog/web3-ai-convergence)。 ## 指令集或預編譯擴充：相容優先 若要在虛擬機層暴露張量或深度學習原語，合理的約束是： - **超集而非分叉**：標準 EVM 位元組碼路徑保持可用，現有 DeFi / NFT 合約不因「AI 鏈」而失效；擴充佔用獨立的操作碼或預編譯地址空間。 - **映射到硬體加速**：原語最終落到 SIMD / GPU 等，而不是在解譯器裡用純軟體慢速模擬「原生」。 - **工具鏈可驗證**：模型轉換、量化（如 INT8/FP16）、SDK 與剖析工具要能重現同一結果；否則「原生」只對白皮書成立。 公開資料裡常見「準確率小幅下降換數倍推論吞吐」這類工程經驗，應標為特定模型與硬體下的觀測，不是通用 SLA。EVM 相容邊界本身見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)。 需要警惕的表述：暗示任意大模型可在全部驗證者集合上做完整的前向傳播並寫入規範狀態。那會把非確定性、硬體異構與頻寬成本直接灌進共識的安全假設裡。 ## 混合執行：按複雜度分流 並非所有 AI 運算都適合上鏈。更穩妥的分流直覺是： | 任務形態 | 更合理的路徑 | 鏈上留下什麼 | |----------|--------------|--------------| | 小規模、可重複的約束檢查 | 鏈上或預編譯 | 狀態變更本身 | | 中等推論 / 微調切片 | 鏈下執行 + 輕量驗收 | 任務雜湊、驗收結果、支付 | | 大規模訓練 | 算力網路 + 強驗收（抽樣/ZK/TEE） | 任務與證明承諾、分帳 | 排程節點時可用信譽、質押與可驗證隨機（VRF）降低人為操縱；關鍵任務可引入多方獨立執行與多數一致。這些是系統設計的選項，落地的強度取決於威脅模型，而不是功能開關的數量。 混合執行與 [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)、[《可信運算框架》](/zh-Hant/blog/trusted-computing-framework) 是同一問題的不同切面：前者談任務生命週期，後者談證明假設。 ## 分散式算力網路：拼網，不拼神話 資料平行、模型平行、流水線平行是成熟的分散式訓練詞彙；拜占庭梯度過濾、檢查點與故障遷移也是工程常識。把它們寫進鏈的敘事時，仍要守住邊界： - 網路互連與顯示記憶體（VRAM）頻寬的限制不會因「上鏈」而消失； - 激勵若只按在線時長發放，會滑向通膨挖礦，而不是可稽核的運算市場； - 結算層（樂觀平行 EVM）提供的是任務狀態機與支付的吞吐量與最終性預期，見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm) 與 [《Bitroot 定位》](/zh-Hant/blog/bitroot-positioning)。 測試網或工程目標中的確認延遲、TPS，描述的是結算基板的能力，不能直接翻譯成「訓練速度」。讀指標的方式見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。 ## 可信運算與確權：原生堆疊的另外兩塊 可驗證的完整性、機密性與多方聯合運算，靠 ZK / TEE / MPC 組合，而不是靠再加一句「企業級安全」。資料與模型的收益若要可執行，需要鏈上中繼資料、授權與分帳狀態機，見 [《AI 資產確權》](/zh-Hant/blog/ai-data-ownership)。 ## 交付順序建議 更穩妥的順序通常是：結算可預期 → 任務/支付與薄驗收 → 按威脅模型導入 TEE/ZK → 複雜確權與市集。測試披露應分開：鏈上結算基準（標註衝突率）、算力完成時延（標註硬體）、證明耗時（標註電路/enclave）。混成一張「AI 鏈 TPS」海報，會同時誤導協議方與應用方。熱點負載見 [《平行 EVM 工作負載熱點》](/zh-Hant/blog/parallel-evm-workload-hotspots)。 對遷移中的以太坊應用而言，AI 原生不應以犧牲工具鏈作為預設代價。擴充預編譯可以加速證明驗證，但主要路徑仍應讓 Hardhat/Foundry 與現有稽核假設成立。否則「原生」會變成「重寫」。相容邊界見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)；樂觀平行機制見 [《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-)。 ## 開發者工具鏈決定「原生」是否可交付 沒有可重現的轉換、量化、模擬與除錯工具，指令擴充只會停留在規範草案。開發者需要：在本機以確定性方式重放含擴充原語的交易；在測試網觀察混合執行的路由決策；以及在證明缺失時明確失敗，而不是默默回退到中心化 API。工具鏈的成熟度應與 opcode 清單一起披露。 同時，原生擴充不得破壞現有 Solidity 合約的位元組碼預期與稽核假設。新增預編譯的 gas 計價、錯誤碼與升級治理，都要寫進規範，否則「AI 原生」會變成硬分叉的驚喜。相容細節見 [《EVM 相容意味著什麼》](/zh-Hant/blog/evm-compatibility-explained)；結算層的平行背景見 [《樂觀平行化機制》](/zh-Hant/blog/bitrootevm-)。 ## 非確定性與規範狀態的紅線 AI 原生擴充若引入依賴硬體的非確定性浮點運算，規範狀態會分叉。必須約定：哪些原語允許出現在共識關鍵路徑，哪些只能在鏈下執行後以承諾上鏈；量化與捨入模式是否強制；以及節點缺少 GPU 時如何驗證或跳過。沒有這些約定，「原生」會變成隱含地信任高性能節點。 測試網應專門覆蓋：沒有加速器的節點之驗證路徑、擴充交易的確定性重放，以及混合執行錯誤路由時的失敗可見性。工程目標中的吞吐數字，應標明是否包含擴充原語的負載，避免與純轉帳基準混用。指標見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。 「AI 原生」若可交付，應表現為規範、工具鏈與混合執行路由均可獨立重現；若不可交付，應誠實降級為預編譯實驗與算力市場介面。兩者都有價值，但不應共用同一套絕對化的措辭。 ## 階段性交付比一次定義更重要 可先交付：預編譯實驗、任務結算合約，以及帶抽查的推論市場；再迭代指令集的覆蓋面與更強的證明。把「完整 AI 指令集 + 全球訓練網 + 萬能確權」綁成同一個里程碑，會讓每一項都無法單獨驗收。分階段並公布每個階段的威脅模型與效能條件，才是工程上的 AI 原生路徑。 ## 小結 AI 原生區塊鏈若可核對，應表現為：擴充原語在相容約束下可重現、混合執行按成本分流、算力網路有驗收、結算層對 Agent 與任務狀態機足夠快且可預期。四者缺一，「原生」就會退回預言機拼裝。本文不構成投資建議；任何吞吐與延遲數字均應視為測試或工程目標，直至在主網對抗條件下可獨立重現。 ## 延伸閱讀 - [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai) - [《可信運算框架》](/zh-Hant/blog/trusted-computing-framework) - [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)