YBB Capital：瘋狂的多鏈宇宙，瘋狂的OP Stack
前言
前言
一級標題
圖片描述
前言
一級標題
一級標題
一級標題
一級標題
OP Stack 可理解為一組開源的軟件組件，使任何人都可以使用Optimistic rollups 在以太坊之上構建自己的Layer 2 區塊鏈。它將大部分計算和存儲移至鏈外，同時依賴以太坊來確保安全性和最終性，從技術層面來講，Optimism 主要體現在它切實地為用戶節省了大量鏈上費用。 OP Stack 由四個主要組件組成：
二級標題
相兼容；
圖片描述
合約：實現OP Stack 核心邏輯和功能的智能合約。 OP 合約包括狀態轉換系統（STS）、欺詐證明者(FP)、狀態承諾鏈（SCC）以及規範交易鏈（CTC）；
二級標題
標準化"標準化"圖片描述
二級標題
YBB Capital Researcher Ac-Core 自製
OP Stack （Over Powered Stack）將成為超級鏈背後統一的模塊化開發堆棧，且它們之間是無數可相互鏈接、可通信的區塊鏈。 OP Stack 堆棧由專門的Optimism Collective 負責整體的開發和維護，並支持用於部署新匯總網絡的共享開源系統。與此同時它也是一套標準化的開源模塊。這樣一聽它豈不是一個完全基於以太坊安全性的Cosmos！當初說好的ETH 與ATOM 兩者互補，現在卻讓OP Stack 成為了Cosmos 殺手？接下來讓我們把OP Stack 的定義給拆解一下：
標準化
標準化
意味著對一個模塊的標準有共識，並且它可以被所有人實現。同時完全開源意味著它可以免費提供給任何人進行開發迭代和消息請求。開發人員有能力在一個鏈的不同執行層、共識層、結算層和數據可用性層進行切換模塊。
二級標題
二級標題
簡潔：利用可複用的代碼和現成開發套件，以增強安全性和降低維護的複雜性，達到整體降低門檻的作用；
二級標題
可擴展：Optimism Collective 將會完整開源OP Stack 的主要代碼。
在架構上，OP Stack 可自下而上分為六層，分別是DA Layer 數據可用層、Sequencing Layer 排序層、Derivation Layer 衍生層、Execution Layer 執行層、Settlement Layer 結算層、Governance Layer 治理層。 OP Stack 的每一層都是模塊化的API 組建，可以隨意進行組合和解耦。其中最為關鍵的是DA 數據可用層、執行層和結算層，三者構成了OP Stack 的主要工作流程。
DA 數據可用性層：是OP Stack 的原始數據來源，可使用單個或多個數據可用性模塊來獲取輸入數據，目前以太坊是最主要的DA 層，但未來也會有更多的鏈加入進來；
執行層：OP Stack 中的狀態結構，可為EVM 或其他VM 提供可能性，增加了在以太坊上發起的Layer 2 交易的支持，同時為每筆交易增加額外的Layer 1 數據費用，向以太坊發布交易的綜合成本。
二級標題
二級標題
OP Stack 法則：
YBB Capital Researcher Ac-Core 自製
以太坊的無限區塊空間是實現大規模應用的關鍵一步，但這種擴散也帶來了分裂，無權限部署也迎來了新挑戰，如今，每個新的OP Stack 鏈都在自己的領域中獨立生長，沒有分享標準和改進的直接方法。用戶和建設者也面臨著巨大的挑戰：根據安全性、質量和中立性對眾多不同的鏈進行單獨評估。為了實現超級鏈，需將OP Stack 從獨立、分散的區塊空間轉變為一個統一的鏈集體，共同致力於開放、去中心化的區塊空間。 “鏈法則”為樂觀主義治理和超級鏈制定了指導原則。樂觀主義治理從管理單個鏈轉變為管理多個鏈共享的標準，從而定義了成為超級鏈一部分所需的屬性，同時優先保護用戶在超級鏈上進行交易。從根本上講，“鏈法則”是一份社會契約（而非法律契約），因此積極的社區討論至關重要。它的存在將使超級鏈能夠保證以下特性：
確保區塊空間保持同質、中立和開放： 對鏈法的承諾就是對保護鏈的用戶、開發者和其他利益相關者的承諾。無論大小的鏈，如果是超級鏈的一部分，都可以在樂觀主義治理的支持下，可信地證明其區塊空間的同質性、中立性和開放性；
受益於不斷改進： 共享升級意味著超級鏈可以始終獲得最好的技術，而無需自己操心維護；
二級標題
二級標題
OP Stack 和ZK Stack 的區別：
一級標題
圖片描述
ZK Stack：多鏈多選擇
二級標題
圖片描述
圖片描述
圖片描述
二級標題
二級標題
為OP 實現零知識證明（ZKP）：
圖片描述
圖片描述
YBB Capital Researcher Ac-Core 自製
完成這項任務意味著需要實現一個零知識證明（ZKP）系統，該系統可以使用golang 編譯器（如MIPS、RISC-V 或WASM）支持的指令集架構（ISA）來證明OP 防錯程序[ 2 ] 。此外，該證明系統還必須證明標準配置OP Stack 鏈的兩個區塊之間狀態轉換，從而證明其在實踐中是可行的。除了證明ISA 的標準執行軌跡外，對防錯程序的支持還引入了額外的要求[ 1 ] 。
領導選舉[ 6 ]是指在分佈式系統中使用不同的領導者負責創建下一個規範狀態轉換的能力。在區塊鏈中，領袖選舉可以讓不同的區塊生產者在不同的時間產生區塊，同時領導選舉算法可以是競爭性的也可以是無競爭性的。
一級標題
二級標題
以太坊的工作原理：
在工作量證明情況下，競爭性領導選舉算法是指在同一時間內有許多潛在的單位爭相成為領導者。無競爭領導者選舉算法是指在某一特定時間點只有一個已知的領導者，在以太坊Gasper 的情況下，無競爭性領導選舉算法是指在特定時間點只有一個已知的單位，並沒有其他方式讓另一個潛在單位在那個時間成為領導者。
在將提議者網絡和構建者網絡分離的情況下（即區塊構建者網絡只負責選擇交易排序，提議者網絡只負責簽署區塊），會將原本負責在某一時刻產生區塊的單一實體轉變為許多可能存在的實體，且讓它們在競爭這某一時刻內構建者網絡中最具盈利的潛力區塊，與此同時由於MEV 的存在，會導致這種競爭性再次回歸。
以太坊的工作原理：
圖片描述
二級標題
以太坊的原理是，每個節點都存儲且執行用戶提交給它的每筆交易，這種高級別的安全方式也導致整個網絡十分昂貴，所以需要為整個網絡擴容而採取了Rollup 解決方案。簡單來說Rollup = Layer 1 的一組合約+ Layer 2 的自身網絡節點，即鏈上智能合約+ 鏈下聚合器，將結算，共識，數據可用性均依賴以太坊，自己僅負責執行Rollup。
二級標題
圖片描述
二級標題
OP Stack:
二級標題
二級標題
圖片描述
二級標題
ZK Stack：
二級標題
圖片描述
圖片描述
圖片描述
二級標題
二級標題
下面我們來探討一下ZK Stack，在ZK rollup 網絡中，存在著Prover 節點，它專門負責為排序器發布交易批次，同時生成有效性證明。這些有效性證明在Layer 1 上有專門的驗證合約。只要交易批次及其對應的StateRoot/StateDiff 的證明通過Verifier 合約驗證，交易便得到最終確認。它與OP Stack 有所不同的是，ZK rollup 在解決排序器欺詐問題時除了依賴Layer 2 全節點外，還利用了Validity Proof（有效性證明）。 ZK rollup 的官方橋樑也只會允許通過有效性證明驗證的提款交易執行，從安全性方面來看，這顯然比Optimism 要可靠得多，即上文中“OP Stack 和ZK Stack 的區別”小節中提出的：ZK Stack 是多鏈多選擇。
從理論來考慮，ZK rollup 的安全由Layer 1 上的Verifier 合約保證或可以說是由Layer 1 節點完成交易最終確認。與OP rollup 的安全性靠最少單個能發布欺詐證明的誠實Layer 2 全節點相對比，他們都是繼承了Layer 1(ETH)的安全性，但事實或許嚴格意義來講並非如此，不過這已是目前最優解決方案，相比於其他公鏈，以太坊經歷這麼多年的發展歷程，安全性毋庸置疑是最值得信賴的。
速度問題：ZK rollup 面臨著一個挑戰，即生成有效性證明的速度較慢。儘管排序器可以在1 秒內執行數千筆交易，但為這些交易生成有效性證明可能需要幾個小時的時間；
- Single Sequencer & POA
- Based rollup
- DVT x Sequencer
- Shared Sequencer
- Bootstrap a New Sequencer Set
一級標題
圖片描述
成本問題：為了降低整體成本，很多ZK rollup 方案採取了“聚合多個Proof，再一次性發到Layer 1 上”的策略。這意味著Prover 不會立即在生成一個Proof 後就發送到Layer 1 ，而是等待多個Proof 都生成完畢後，將它們聚合在一起，並一次性發給Layer 1 上的Verifier 合約；
一級標題
參考文章：
[ 1 ]https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md#fault-proof-program
[ 2 ]https://github.com/ethereum-optimism/ecosystem-contributions/issues/61
[ 3 ]https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md#pre-image-oracle
[ 4 ]https://en.wikipedia.org/wiki/System_call
[ 5 ]https://github.com/ethereum-optimism/optimism/blob/develop/specs/fault-proof.md#fault-proof-vm
[ 6 ]https://github.com/ethereum-optimism/ecosystem-contributions/issues/63
參考文章：
https://mp.weixin.qq.com/s/ezSpKkoUoyFtoYd2cLoOzw
