opBNB：基於 OP Stack 的全新高速低成本 L2

TL;DR:

1. opBNB 是強化 BNB 智能鏈 (BSC) 網路效能與擴展性的第 2 層解決方案。opBNB 運用 Optimism OP Stack Bedrock，一套能夠彈性修改以符合 BSC 生態系標準的開源模組化樂觀匯總框架。
2. BSC 與以太坊等第 1 層網路經常面臨高燃料費與網路壅塞等挑戰，這些都會影響大型應用的效能與可擴展性。opBNB 專案的目標是解決這些 BNB 生態系的問題，為開發人員與用戶提供快速、安全且低成本的解決方案。
3. 透過引入 OP Stack 最佳化 (包含執行、挖礦流程與 Batcher 最佳化)，opBNB 能達到 4000+ TPS 與區塊時間 1 秒的速度，且轉帳交易手續費可低於 $0.005。
4. 透過最佳化採用，我們期望同時為 BNB 生態系與樂觀匯總社群創造價值。我們對 Optimism OP Stack 的貢獻反映了我們對第 2 層生態系開發的投入。

為甚麼 BSC 需要全新的 L2？

第 1 層網路是提供用於數據傳輸與驗證基礎架構的底層網路，例如 BSC 與以太坊。這些網路面臨了尖峰時段網路壅塞的挑戰，任何熱門應用程式進行促銷活動或流量激增時都會發生壅塞。而網路壅塞會導致交易手續費增加、交易變慢與糟糕的用戶體驗，為克服上述挑戰，第 1 層網路必須增加擴展性，即在不影響安全性的前提下每秒處理更多交易的能力。

舉例而言，2021 年，BSC 在 BNB 智能鏈 (BSC) 上推行了一款 Web3 遊戲，每天產生超過 800 萬筆交易。

1. 理論上這會大幅超過 BSC 的流通量上限，導致交易速度緩慢、交易確定延遲以及遊戲玩家與其他 DApp 用戶體驗不佳。

2. 這種交易量水準的每日燃料費可能上漲至超過 6,800 BNB (300 萬美元)，對遊戲的可用性與永續性構成顯著障礙。

以 BSC 當前形式而言，如此巨大規模的 DApp 所產生的大量交易負載，似乎無法有效率地處理。BSC 將會需要大幅度的最佳化與擴展解決方案，才能支援此類 DApp，且不造成全網路的效能降級與不合理的高成本。

為甚麼選擇 OP Stack 作為 opBNB 的基礎？

opBNB 網路建立在 BSC 上，係基於OP Stack 的第 2 層擴展解決方案。

OP Stack 是能夠打造可擴展且可互通的第 2 層解決方案框架，其設計基於功用、簡易性與擴充性原則。選擇 OP Stack 作為 opBNB 的基礎有多種好處，包含：

• 模組化框架：opBNB 多數模組都能夠自定義，例如效能最佳化的彈性執行客戶端、為強化數據擴展性替換不同的數據存取層，以及採用多種證明生成邏輯 (包含 zk 證明) 等。
• 開放生態系：OP Stack 同時培養了開放而合作的生態系，不同專案皆能同時運行並互利。透過運用 OP Stack，opBNB 成為了第 2 層鏈網路的一份子，能夠與其他鏈共享相同的技術堆疊，並互通有無。
• 對 OP Stack optimism 的貢獻：BNB 鏈社群尊重所有 Optimism 在 Op Stack 框架中的努力與創新。opBNB 採用的最佳化與創新能讓生態系受益，因此也能對 OP Stack 做出貢獻，促進整個行業樂觀匯總的發展。

opBNB 如何達成高效能與低燃料費？

opBNB 測試網強化了 OP Stack 環境中強調的 OP Stack 「執行層」與「衍生層」效能。

執行層最佳化

開發 opBNB 協定中的一項主要挑戰便是確保高交易流通量。為達到這項目標，opBNB 運用了先前為 BSC 實行的執行最佳化技巧。

EVM 狀態資料存取最佳化

深入探討最佳化細節之前，讓我們先了解 EVM 如何處理狀態資料。下圖說明了 EVM 如何存取狀態資料。EVM 首先在記憶體快取中尋找資料。若沒有找到資料，EVM 會使用 LevelDB，當中涉及磁碟 IO。

透過增加快取效率與加速資料庫讀寫速度，opBNB 實現效能與可擴展性的可觀提升，令節點營運商與終端用戶皆受益。

(與標準以太坊世界狀態資訊儲存模型相比，BNB 引入了「SharedPool」作為 L1.5 快取，增加快取命中率)

透過增加 L2： Diff 層當中的 Bloom Filter 精確度，迴避不必要的快取遞迴存取

Bloom Filter 是一種機率資料結構，能夠快速驗證元素是否存在於資料集當中。為存取狀態資料，EVM 會使用 Bloom Filter 驗證鍵-值對是否在 Diff 層中，並遞迴搜尋快取直到找到為止，若沒有找到，EVM 會直接自 levelDB 讀取資料。

然而， Bloom Filter 可能會發生偽陽狀況。此外，Bloom Filter 評估的資料集拓展時，偽陽率亦會上升。考量 opBNB 的資料集較以太坊更大，偽陽的機率也可能更大。

偽陽可能導致不必要之遞迴存取。為減輕這種狀況，opBNB 將 Diff 層等級自預設的 128 減少至可調整參數 32。減少參數，便可縮減資料集的大小，進而降低偽陽的可能性，避免不必要的費時作業，增加狀態擷取的效率。

提升 L1.5 與其上層快取模型的預先擷取效益

預先擷取是增加交易執行效能的技巧，預先將資料自磁碟載入快取即可達成。當一個區塊必須以完全同步模式處理或以挖礦模式挖掘時，opBNB 節點將啟動 N 個執行緒，以進行預先擷取。執行緒會執行區塊或 TxPool 的交易並捨棄結果，但將資料物件保存在快取中。如此一來，當節點需要存取資料時，便更容易在快取中而非磁碟上找到所需資料，進而改善快取命中率。

然而，原先的預先擷取設計存在效能限制。它利用獨立的狀態資料庫進行預先擷取與主要處理程序。預先擷取執行緒只能將預先擷取的資訊儲存在 L2 Diff 層中 (請見先前解說的 3 層快取模型)。為存取這項資訊，主程序必須經過 L1、L2 甚至 L3 層，對高效能第 2 層鏈而言太過緩慢。

新設計透過在預先擷取與主 EVM 程序間共享儲存完整世界狀態 (originStorage) 的資料池增加效能。如此一來，預先擷取執行緒便能將預先擷取資訊直接放入 L1.5 (快取模型的上層)，讓主程序能更快速存取。詳細過程請見下方。

挖礦流程最佳化

挖掘 OP Stack L2 區塊的流程如圖所示。它包含匯總驅動 (opNode) 匯入上一個區塊，並調用引擎 API (op-geth) 在第 2 層產生新區塊的迴圈。

匯總驅動 (opNode) 透過呼叫引擎 API(op-geth)上的 engine_forkChoiceUpdatedv1 API，在 op-geth 開始區塊產生流程。這會指示引擎 API(op-geth) 透過執行交易，開始產生初始區塊。 (請見表格中的「引擎 API：開始產生區塊」)。引擎 API(op-geth) 接著傳回負載 ID 給匯總驅動 (opNode)。

然而，當引擎 API(op-geth) 自匯總驅動 (opNode) 收到 engine_newPayloadV1 呼叫提交區塊時，必須再次執行交易，重複作業而且耗時。這可能需要數百毫秒才能完成。

為最佳化效能，我們添加了快取層，在初始區塊產生步驟中儲存執行結果。如此一來，當 op-geth 收到 engine_newPayloadV1 呼叫時，便能自快取提取資料，而非再次執行交易。這能為系統節省時間與資源。

衍生層最佳化

Batcher 最佳化 - 確認非同步

Batcher 效能瓶頸源自於提交下一批交易前，必須等待 15 個區塊 (45 秒)，讓第 1 層 (BSC) 確認每個批次的交易。這是因為第 1 層鏈能夠進行重組。為解決這個問題，我們引入了非同步提交功能，讓 Batcher 能夠不等待確認便提交批次。一個獨立監控程序會追蹤第 1 層，並在重組發生時通知 Batcher，以利重新提交受影響的交易。這項功能改善了 Batcher 的效率。上述改動仍在開發中，尚未在測試網發布，但會在 opBNB 主網上部署。

回饋開源社群

OpBNB 運用了可靠且適應性強的 OPstack 框架，讓部署第 2 層基礎架構更為簡單快速。這些 opBNB 的主要最佳化不但對 BNB 鏈社群有益，也對更廣泛的第 2 層開源生態系有益。以下是已經提交至 OP Stack 的範例。

去除 addSafeAttributes 功能

去除 LastL2Time 功能

中止失敗的載荷確認

opBNB 程式碼庫完全開源，且所有在 opBNB 當中進行的最佳化都能在其他樂觀匯總實行中重複利用。我們希望這項工作能在 EVM-兼容區塊鏈開發人員與用戶之間啟發更多合作與創新。

展望

OpBNB 是 BNB 鏈大規模採用的部份願景之一，著重於用戶體驗：高效能、更便宜且安全的區塊鏈生態系。opBNB 測試網僅僅是開始。opBNB 將會持續在不同模組上最佳化 OP Stack，包含替換不同的 BNB Greenfield 資料存取層，以增加資料擴展性、採用 zk proof 多種證明生成等。

我們邀請所有的開發人員與專案以 opBNB 測試網進行實驗。不論您想要打造高交易量去中心化 App、遊戲平台還是社群網路，opBNB 都能提供理想環境，讓您的創意自由展現。您的成就不但能裨益您的專案，也會對更廣泛的 BSC 與 L2 生態系有所貢獻。