Scroll Rollup流程全解析從交易打包到有效性證明生成【免費下載鏈接】scroll-documentationThis is the frontend for the Scroll documentation項目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentationScroll 是首個基于 zkEVM 的以太坊二層L2網(wǎng)絡它的Scroll Rollup流程堪稱 zk-rollup 技術的教科書級實現(xiàn)。這篇文章將用最通俗的語言帶你完整走一遍 Scroll Rollup流程從用戶提交交易、執(zhí)行節(jié)點打包區(qū)塊到交易分批提交上鏈再到 zkEVM 生成有效性證明并最終確認。全程不需要寫代碼看完全文你就明白 Layer 2 是如何踩著以太坊的肩膀高效運轉的。Scroll 是什么一張圖看懂二層網(wǎng)絡的三層架構要理解 Rollup 流程先要知道 Scroll 的總體架構。它的核心思路是把計算和狀態(tài)放到 L2 上執(zhí)行把數(shù)據(jù)與安全性交給 L1 以太坊保證。整個系統(tǒng)分為三層結算層Settlement Layer以太坊主網(wǎng)部署著跨鏈橋合約與 Rollup 合約是最終裁決者。排序?qū)覵equencing Layer由執(zhí)行節(jié)點Execution Node與 Rollup 節(jié)點Rollup Node組成負責出塊與打包。證明層Proving Layer由協(xié)調(diào)器Coordinator與兩類證明者Prover組成負責生成有效性證明。這三層各司其職、環(huán)環(huán)相扣共同支撐起完整的 Scroll Rollup流程。Scroll Rollup 流程第一步交易執(zhí)行與區(qū)塊生成一切的起點是用戶提交交易。在 Scroll 上你有兩種提交方式直接提交給 L2 排序器像用普通錢包一樣連接 Scroll 的 RPC 端點即可。在 L1 橋合約上發(fā)起交易比如存款、強制交易這類消息會進入 L1 的L1MessageQueue消息隊列。隨后執(zhí)行節(jié)點內(nèi)的三個模塊開始協(xié)同工作Sync Service同步服務持續(xù)監(jiān)聽 L1 橋合約事件發(fā)現(xiàn)新消息就生成對應的L1MessageTx交易放入 L1 隊列Mempool交易池收集用戶直接提交到 L2 的交易Executor執(zhí)行器同時從 L1 隊列和 L2 交易池拉取交易執(zhí)行并打包成新的 L2 區(qū)塊。上圖完整展示了 Scroll Rollup流程的各個環(huán)節(jié)。交易被打進區(qū)塊后就進入了**已確認Confirmed**狀態(tài)但這只是漫長旅程的開始。第二步交易打包Batching——Chunk 與 Batch 的分層設計Scroll 最有特色的設計就是它的多層交易打包機制。交易并不是直接一股腦提交到 L1 的而是像套娃一樣逐級聚合Block區(qū)塊一組有序交易打包而成是 L2 的最小賬本單元Chunk分塊一系列連續(xù)區(qū)塊聚合而成是 zkEVM 電路證明的基本單位Batch批次一系列連續(xù) Chunk 聚合而成是 L1 數(shù)據(jù)提交與證明驗證的基本單位。為什么要搞這么復雜的層級答案是為了省錢。以太坊對交易 payload 有 128KB 的硬性限制而且每次在 L1 上提交數(shù)據(jù)、驗證證明都要消耗 gas。把交易聚合得越大塊單位交易攤分的成本就越低同時還能規(guī)避 zkEVM 電路的容量上限。打包完成后Rollup 節(jié)點中的Relayer會向 L1 的ScrollChain合約提交一筆Commit 交易提交交易把該 Batch 的區(qū)塊信息與交易數(shù)據(jù)在 Bernoulli 升級后以 EIP-4844 Blob 形式上鏈確保數(shù)據(jù)可用性Data Availability。這筆交易中包含了關鍵的dataHash它將成為后續(xù)證明驗證的公共輸入之一——相當于給這批數(shù)據(jù)蓋了一個內(nèi)容指紋。第三步有效性證明生成——zkEVM 如何自證清白數(shù)據(jù)提交上鏈后真正的重頭戲來了生成有效性證明。Rollup 的信任基礎就在于——任何人都可以依據(jù) L1 上公開的數(shù)據(jù)重新執(zhí)行而 Scroll 用密碼學證明保證了執(zhí)行結果的唯一正確。這個過程由**協(xié)調(diào)器Coordinator**調(diào)度每產(chǎn)生一個新 Chunk協(xié)調(diào)器就會從執(zhí)行節(jié)點拉取該 Chunk 內(nèi)所有區(qū)塊的執(zhí)行軌跡Execution Trace把Chunk 證明任務隨機派發(fā)給某個 zkEVM 證明者每產(chǎn)生一個新 Batch協(xié)調(diào)器會從數(shù)據(jù)庫收集該 Batch 內(nèi)所有 Chunk 的證明把Batch 證明任務派發(fā)給聚合證明者Aggregator Prover由它把多個 Chunk 證明聚合成一個 Batch 證明。zkEVM 證明的本質(zhì)是證明執(zhí)行軌跡是正確的每個操作碼都按以太坊黃皮書的規(guī)范執(zhí)行且初始狀態(tài)經(jīng)過這些步驟后確實變成了最終狀態(tài)。這個證明過程把 EVM 的執(zhí)行拆解為一條條指令級記錄再交由 zkEVM 電路驗證最終生成一個可在鏈上快速驗證的密碼學證明。最終確認Finalize 交易與提款解鎖證明生成后Relayer 會把證明與結果提交給 L1 的ScrollChain合約執(zhí)行Finalize 交易最終確認交易。這筆交易包含該 Batch 的有效性證明執(zhí)行前的狀態(tài)根prevStateRoot與執(zhí)行后的狀態(tài)根postStateRoot提款根withdrawRoot。合約會將chainId、前后狀態(tài)根、提款根與 Batch 的dataHash組合成publicInputHash交給 Plonk 驗證器驗證。驗證通過的那一刻新的狀態(tài)根成為 L2 的官方賬本該 Batch 內(nèi)的提款交易用戶可以在 L1 上用 Merkle 證明直接領取資產(chǎn)。也就是說只有走到這一步你的資產(chǎn)跨鏈才是真正落袋為安的?？焖僮圆槲业慕灰滋幱谀膫€階段理解了整個流程就能輕松判斷一筆 Scroll 交易的進展了。三個階段對比如下狀態(tài)觸發(fā)時機含義? Confirmed已確認交易被打進 L2 區(qū)塊交易已被執(zhí)行但尚未提交到 L1 Committed已提交Commit 交易在 L1 確認交易數(shù)據(jù)已上鏈任何人都可自行驗證狀態(tài) Finalized已最終確認Finalize 交易驗證通過有效性證明通過狀態(tài)根可信任可提款對普通用戶而言日常轉賬看到Confirmed就已足夠而當你進行跨鏈提款時則需要耐心等待到Finalized資產(chǎn)才能真正到達 L1?？偨Y一條完整的 Scroll Rollup 流水線回顧整個 Scroll Rollup流程可以用一句話概括L2 負責執(zhí)行L1 負責記賬zkEVM 負責背書。交易從用戶手中出發(fā)經(jīng)過區(qū)塊、Chunk、Batch 三級打包數(shù)據(jù)先提交到 L1 保證可用性證明隨后生成并驗證最終狀態(tài)被 L1 鎖定——整個過程環(huán)環(huán)相扣兼顧了性能、安全與成本。如果你想深入了解每個環(huán)節(jié)的技術細節(jié)Scroll 官方文檔倉庫提供了完整的英文技術文檔建議按以下路徑查閱Rollup 流程總覽src/content/docs/en/technology/chain/rollup.mdx交易打包與生命周期src/content/docs/en/technology/chain/transactions.mdxRollup 節(jié)點與 Chunk/Batch 約束src/content/docs/en/technology/sequencer/rollup-node.mdx執(zhí)行節(jié)點與電路容量檢查src/content/docs/en/technology/sequencer/execution-node.mdxzkEVM 證明原理src/content/docs/en/technology/zkevm/zkevm-overview.mdx看完這篇文章相信你已經(jīng)對 Scroll 的 Rollup流程有了整體認知。下一次使用 Scroll 跨鏈時不妨想象一下那筆交易正在流水線上經(jīng)歷打包、提交與證明的完整旅程是不是覺得它更酷了一點【免費下載鏈接】scroll-documentationThis is the frontend for the Scroll documentation項目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentation創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Scroll Rollup流程全解析：從交易打包到有效性證明生成
Scroll Rollup流程全解析從交易打包到有效性證明生成【免費下載鏈接】scroll-documentationThis is the frontend for the Scroll documentation項目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentationScroll 是首個基于 zkEVM 的以太坊二層L2網(wǎng)絡它的Scroll Rollup流程堪稱 zk-rollup 技術的教科書級實現(xiàn)。這篇文章將用最通俗的語言帶你完整走一遍 Scroll Rollup流程從用戶提交交易、執(zhí)行節(jié)點打包區(qū)塊到交易分批提交上鏈再到 zkEVM 生成有效性證明并最終確認。全程不需要寫代碼看完全文你就明白 Layer 2 是如何踩著以太坊的肩膀高效運轉的。Scroll 是什么一張圖看懂二層網(wǎng)絡的三層架構要理解 Rollup 流程先要知道 Scroll 的總體架構。它的核心思路是把計算和狀態(tài)放到 L2 上執(zhí)行把數(shù)據(jù)與安全性交給 L1 以太坊保證。整個系統(tǒng)分為三層結算層Settlement Layer以太坊主網(wǎng)部署著跨鏈橋合約與 Rollup 合約是最終裁決者。排序?qū)覵equencing Layer由執(zhí)行節(jié)點Execution Node與 Rollup 節(jié)點Rollup Node組成負責出塊與打包。證明層Proving Layer由協(xié)調(diào)器Coordinator與兩類證明者Prover組成負責生成有效性證明。這三層各司其職、環(huán)環(huán)相扣共同支撐起完整的 Scroll Rollup流程。Scroll Rollup 流程第一步交易執(zhí)行與區(qū)塊生成一切的起點是用戶提交交易。在 Scroll 上你有兩種提交方式直接提交給 L2 排序器像用普通錢包一樣連接 Scroll 的 RPC 端點即可。在 L1 橋合約上發(fā)起交易比如存款、強制交易這類消息會進入 L1 的L1MessageQueue消息隊列。隨后執(zhí)行節(jié)點內(nèi)的三個模塊開始協(xié)同工作Sync Service同步服務持續(xù)監(jiān)聽 L1 橋合約事件發(fā)現(xiàn)新消息就生成對應的L1MessageTx交易放入 L1 隊列Mempool交易池收集用戶直接提交到 L2 的交易Executor執(zhí)行器同時從 L1 隊列和 L2 交易池拉取交易執(zhí)行并打包成新的 L2 區(qū)塊。上圖完整展示了 Scroll Rollup流程的各個環(huán)節(jié)。交易被打進區(qū)塊后就進入了**已確認Confirmed**狀態(tài)但這只是漫長旅程的開始。第二步交易打包Batching——Chunk 與 Batch 的分層設計Scroll 最有特色的設計就是它的多層交易打包機制。交易并不是直接一股腦提交到 L1 的而是像套娃一樣逐級聚合Block區(qū)塊一組有序交易打包而成是 L2 的最小賬本單元Chunk分塊一系列連續(xù)區(qū)塊聚合而成是 zkEVM 電路證明的基本單位Batch批次一系列連續(xù) Chunk 聚合而成是 L1 數(shù)據(jù)提交與證明驗證的基本單位。為什么要搞這么復雜的層級答案是為了省錢。以太坊對交易 payload 有 128KB 的硬性限制而且每次在 L1 上提交數(shù)據(jù)、驗證證明都要消耗 gas。把交易聚合得越大塊單位交易攤分的成本就越低同時還能規(guī)避 zkEVM 電路的容量上限。打包完成后Rollup 節(jié)點中的Relayer會向 L1 的ScrollChain合約提交一筆Commit 交易提交交易把該 Batch 的區(qū)塊信息與交易數(shù)據(jù)在 Bernoulli 升級后以 EIP-4844 Blob 形式上鏈確保數(shù)據(jù)可用性Data Availability。這筆交易中包含了關鍵的dataHash它將成為后續(xù)證明驗證的公共輸入之一——相當于給這批數(shù)據(jù)蓋了一個內(nèi)容指紋。第三步有效性證明生成——zkEVM 如何自證清白數(shù)據(jù)提交上鏈后真正的重頭戲來了生成有效性證明。Rollup 的信任基礎就在于——任何人都可以依據(jù) L1 上公開的數(shù)據(jù)重新執(zhí)行而 Scroll 用密碼學證明保證了執(zhí)行結果的唯一正確。這個過程由**協(xié)調(diào)器Coordinator**調(diào)度每產(chǎn)生一個新 Chunk協(xié)調(diào)器就會從執(zhí)行節(jié)點拉取該 Chunk 內(nèi)所有區(qū)塊的執(zhí)行軌跡Execution Trace把Chunk 證明任務隨機派發(fā)給某個 zkEVM 證明者每產(chǎn)生一個新 Batch協(xié)調(diào)器會從數(shù)據(jù)庫收集該 Batch 內(nèi)所有 Chunk 的證明把Batch 證明任務派發(fā)給聚合證明者Aggregator Prover由它把多個 Chunk 證明聚合成一個 Batch 證明。zkEVM 證明的本質(zhì)是證明執(zhí)行軌跡是正確的每個操作碼都按以太坊黃皮書的規(guī)范執(zhí)行且初始狀態(tài)經(jīng)過這些步驟后確實變成了最終狀態(tài)。這個證明過程把 EVM 的執(zhí)行拆解為一條條指令級記錄再交由 zkEVM 電路驗證最終生成一個可在鏈上快速驗證的密碼學證明。最終確認Finalize 交易與提款解鎖證明生成后Relayer 會把證明與結果提交給 L1 的ScrollChain合約執(zhí)行Finalize 交易最終確認交易。這筆交易包含該 Batch 的有效性證明執(zhí)行前的狀態(tài)根prevStateRoot與執(zhí)行后的狀態(tài)根postStateRoot提款根withdrawRoot。合約會將chainId、前后狀態(tài)根、提款根與 Batch 的dataHash組合成publicInputHash交給 Plonk 驗證器驗證。驗證通過的那一刻新的狀態(tài)根成為 L2 的官方賬本該 Batch 內(nèi)的提款交易用戶可以在 L1 上用 Merkle 證明直接領取資產(chǎn)。也就是說只有走到這一步你的資產(chǎn)跨鏈才是真正落袋為安的?？焖僮圆槲业慕灰滋幱谀膫€階段理解了整個流程就能輕松判斷一筆 Scroll 交易的進展了。三個階段對比如下狀態(tài)觸發(fā)時機含義? Confirmed已確認交易被打進 L2 區(qū)塊交易已被執(zhí)行但尚未提交到 L1 Committed已提交Commit 交易在 L1 確認交易數(shù)據(jù)已上鏈任何人都可自行驗證狀態(tài) Finalized已最終確認Finalize 交易驗證通過有效性證明通過狀態(tài)根可信任可提款對普通用戶而言日常轉賬看到Confirmed就已足夠而當你進行跨鏈提款時則需要耐心等待到Finalized資產(chǎn)才能真正到達 L1?？偨Y一條完整的 Scroll Rollup 流水線回顧整個 Scroll Rollup流程可以用一句話概括L2 負責執(zhí)行L1 負責記賬zkEVM 負責背書。交易從用戶手中出發(fā)經(jīng)過區(qū)塊、Chunk、Batch 三級打包數(shù)據(jù)先提交到 L1 保證可用性證明隨后生成并驗證最終狀態(tài)被 L1 鎖定——整個過程環(huán)環(huán)相扣兼顧了性能、安全與成本。如果你想深入了解每個環(huán)節(jié)的技術細節(jié)Scroll 官方文檔倉庫提供了完整的英文技術文檔建議按以下路徑查閱Rollup 流程總覽src/content/docs/en/technology/chain/rollup.mdx交易打包與生命周期src/content/docs/en/technology/chain/transactions.mdxRollup 節(jié)點與 Chunk/Batch 約束src/content/docs/en/technology/sequencer/rollup-node.mdx執(zhí)行節(jié)點與電路容量檢查src/content/docs/en/technology/sequencer/execution-node.mdxzkEVM 證明原理src/content/docs/en/technology/zkevm/zkevm-overview.mdx看完這篇文章相信你已經(jīng)對 Scroll 的 Rollup流程有了整體認知。下一次使用 Scroll 跨鏈時不妨想象一下那筆交易正在流水線上經(jīng)歷打包、提交與證明的完整旅程是不是覺得它更酷了一點【免費下載鏈接】scroll-documentationThis is the frontend for the Scroll documentation項目地址: https://gitcode.com/gh_mirrors/sc/scroll-documentation創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考