---
id: 15
title: Bitroot 定位：樂觀平行 EVM 的 Layer 1 邊界
slug: bitroot-positioning
date: 2026/09/01
summary: Bitroot 選擇投入樂觀平行 EVM 的 Layer 1，意味著在結算域、相容性與平行策略上同時取捨。本文用邊界而非口號說明它解決什麼、不解決什麼，以及技術組合如何互相支撐。
keywords: Bitroot,樂觀平行EVM,Layer1,產品定位,Pipeline BFT
heroImage: /images/community-bg.png
---

只談吞吐數字的公鏈故事，很容易被下一組更大的數字蓋過。更經得起追問的是座標：在擴容地圖上佔哪一格、在三條平行路線裡選哪一條，以及這些選擇承認了哪些代價。前面幾篇已經鋪好框架——單執行緒天花板、分層擴容、確定性 / 樂觀 / 物件模型、OCC 的資料庫骨架。本稿把框架收束到 Bitroot：它宣稱自己是什麼、邊界在哪裡，以及哪些說法仍應留在測試與工程驗證的語境裡。

## 一句話定位，拆開每個詞

Bitroot 定位為樂觀平行 EVM 的高效能 Layer 1，面向支付結算、可組合 DeFi 與大規模鏈上協作等需要更高執行寬度的場景。每個詞都是取捨。

做 Layer 1 而不是 Rollup，意味著要自行維護共識與驗證者集合，不能把安全性簡單描述成「繼承以太坊」；換來的是結算與執行同域，少一層預設橋接跳轉。選樂觀平行而不是確定性預先宣告，意味著把依賴發現留給執行環境，換取開發者繼續用熟悉的 Solidity 方式寫合約。堅持 EVM 相容而不是改採物件模型換棧，意味著放棄一部分由資料模型帶來的結構性平行，把難題交給排程、衝突偵測與狀態組織。

同賽道裡，其他樂觀平行 EVM 專案也在用不同的工程組合追求相近的敘事：共識與執行解耦、亞秒級最終性目標、結算層定位等。Bitroot 的差異應落在具體的機制組合上，而不是「唯一發明了平行」這類無法查核的說法。

## 三層組合：共識、執行、狀態

理解 Bitroot，不宜只看執行引擎的宣傳標語，而應看三層如何協同。

共識層採用 Pipeline BFT 這類流水線拜占庭協議思路：把提案、投票、提交等階段流水線化，让不同高度的工作可以重叠；並用領導者輪換與簽章聚合等手段，抑制驗證者集合擴大時的通訊爆炸。目標是讓「快速確定交易順序」不成為吞吐量的第一道牆。機制細節見既有技術文對 Pipeline BFT 的拆解；此處強調分工——共識負責順序與最終性路徑，不負責在協議裡解釋每一筆 EVM 呼叫。

執行層是樂觀平行 EVM：在區塊內既定順序的約束下推測執行，收集讀寫集，偵測到衝突後對受影響的交易重新執行，使最終狀態與串列語意等價。動態分組、多層衝突偵測等工程選擇，旨在把樂觀假設失效時的代價局部化，避免「一處衝突、整批作廢」。公開展示或測試網環境中的吞吐量與延遲數字，必須連同硬體、交易類型與衝突率假設一起解讀；它們是工程進度的證據，不是對主網混合負載的保證。

狀態層關注帳戶或儲存的分區、快取與大物件策略，緩解「執行已經平行，但單一狀態結構與磁碟路徑仍屬串列」的下一道瓶頸。跨分區通訊與熱點資料放置，會直接決定可組合 DeFi 能否吃到平行紅利——這與工作負載熱點分析是同一類問題。

三層的關係是解耦協同：順序可以先定，執行再非同步收斂到該順序對應的狀態根，避免「共識空等執行」的假串列。缺任一環，定位都會塌成單點最佳化。

| 層級 | 機制重心 | 主要對治的問題 |
|------|----------|----------------|
| 共識 | 流水線 BFT、領導者輪換、簽章聚合 | 經典 BFT 階段串列與通訊開銷 |
| 執行 | 樂觀平行、讀寫集、衝突後重新執行 | 單執行緒 EVM 執行寬度 |
| 狀態 | 分區、快取、大物件策略 | 單點狀態與儲存路徑瓶頸 |

## 明確不選什麼

不選「放棄 EVM、改物件模型換平行」：遷移與稽核成本被判定高於執行環境的排程成本。不選「強制存取清單的確定性 EVM」：與現有位元組碼生態衝突。不選「只做 L2、把硬問題全部推回以太坊 DA 與結算」：產品要的是同域結算與自主的效能迭代，儘管這意味著要自己承擔驗證者去中心化與安全假設的溝通責任。

這些「不選」比口號更能定義邊界。Bitroot 不是通用 DA 層，也不取代以太坊作為最大流動性與結算錨的生態位；它提供的是一條不同的 L1 結算域，用樂觀平行換取執行寬度，用 EVM 相容換取遷移摩擦的降低。

## 場景：什麼負載真正考驗定位

支付與結算類負載若讀寫集相對分散，樂觀平行最容易兌現；此時延遲穩定性與費用可預測性，往往比峰值 TPS 更有產品意義。

可組合 DeFi 是壓力測試。一筆路由可能連續觸碰多個池與金庫，寫入衝突上升，引擎若不能縮小重新執行的範圍，吞吐量會迅速回落。選擇直面這個場景，等於承認：結算層不能只在「無關轉帳基準」裡好看。熱點如何形成、如何度量，見工作負載相關討論。

大規模協作與複雜狀態機則把壓力導向狀態組織與跨分區協議。執行平行解決的是 CPU 寬度；狀態跟不上，寬度會被 I/O 與鎖式爭用吃回去。

## 仍在驗證中的判斷

截至可公開追蹤的資訊，相關效能與穩定性結論大量來自測試網、基準測試與分階段展示。驗證者規模、客戶端成熟度、主網級對抗條件，都會改變「定位是否站得住」的答案。去中心化與效能之間的張力不會因為選了 OCC 就消失——節點硬體門檻、頻寬與狀態成長，仍需單獨誠實討論。

把 Bitroot 放回地圖：它佔據的是「L1 + 執行層樂觀平行 + EVM 相容」這一格，而不是「擴容」一詞下的所有格子。下一步自然要問：所謂 EVM 相容，到底相容到位元組碼、預編譯還是工具鏈的哪一層——因為相容性縮水時，前面為生態支付的代價會一併失效。

## 延伸閱讀

- 前置閱讀：[《樂觀並行控制（OCC）入門：從資料庫到鏈上執行》](/zh-Hant/blog/optimistic-concurrency-control-intro)
- 下一篇：[《EVM 相容意味著什麼：位元組碼、預編譯與工具鏈》](/zh-Hant/blog/evm-compatibility-explained)
- 相關閱讀：[《Bitroot 平行化 EVM 技術解析：樂觀平行化》](/zh-Hant/blog/bitrootevm-)、[《深入解析 Bitroot 多引擎平行執行設計：突破 EVM 效能瓶頸》](/zh-Hant/blog/bitroot-evm)、[《深入解析 Bitroot：Pipeline BFT 與多引擎平行執行的協同架構》](/zh-Hant/blog/bitroot-pipeline-bft)、[《去中心化與效能的張力：驗證者門檻、硬體與地理分布》](/zh-Hant/blog/decentralization-performance-tradeoff)