Hacker?Dōjō Web3前沿技術(shù) workshop文稿

資助金額：120 USDT

Bounty鏈接：https://dorahacks.io/daobounty/156

Workshop回顧：https://b23.tv/Vl6wndS

內(nèi)容貢獻(xiàn)者：@0x7ac61a

本項(xiàng)目由Hacker Dōjō 資助，文章轉(zhuǎn)載請(qǐng)注明出處。

??學(xué)習(xí)量子計(jì)算、密碼學(xué)、Space等Web3前沿技術(shù)

??認(rèn)領(lǐng)Bounty，賺取賞金

??參與Hackathon，獲得資助

更多Web3精彩技術(shù)分享盡在Dōjō??

WeChat: @HackerDojo0

Optimistic Rollup基本概念

1、區(qū)塊鏈擴(kuò)容方案Rollup

有兩種方法可以擴(kuò)展區(qū)塊鏈生態(tài)系統(tǒng)：

• 可以讓區(qū)塊鏈本身?yè)碛懈叩慕灰啄芰?/p>

• 可以改變使用區(qū)塊鏈的方式

Rollup屬于第二種方法，通過(guò)將計(jì)算移到鏈下，在鏈上保留每個(gè)交易的一些數(shù)據(jù)的方式來(lái)更快、更便宜地使用區(qū)塊鏈，實(shí)現(xiàn)擴(kuò)展。
Rollup的原理：在鏈上會(huì)存在一個(gè)智能合約，其中包含一個(gè)狀態(tài)根（state root）。

任何人都可以發(fā)布一批匯總交易 (batch)，這是一個(gè)經(jīng)由高度壓縮的交易集合，其中包含之前的狀態(tài)根和處理交易之后的新默克爾根。合約會(huì)檢查批處理中的前一個(gè)狀態(tài)根是否與其當(dāng)前的狀態(tài)根相匹配，如果匹配則將狀態(tài)根切換到新的狀態(tài)根。

關(guān)于如何知道一個(gè)batch執(zhí)行后提交的新root是正確的，存在著兩種Rollups的解決方案：

• Optimistic rollup：利用欺詐證明（fraud proofs）

• ZK rollup：利用有效性證明（validity proofs）

2、Optimistic Rollup工作流程

OP Rollup中目前有2種類型的節(jié)點(diǎn)，sequencer（排序器）和verifier（驗(yàn)證器）。sequencer和verifier節(jié)點(diǎn)都運(yùn)行L2Geth（由Optimism創(chuàng)建的Geth的輕微修改版本）。
當(dāng)User提交一個(gè)L2 Transaction給sequencer時(shí)，sequencer處理這筆交易，將新的狀態(tài)根提交給L1，同時(shí)其他L2節(jié)點(diǎn)在其L2副本上處理交易。為了確保L1新的狀態(tài)是正確的，驗(yàn)證著節(jié)點(diǎn)會(huì)將自己的心狀態(tài)根與sequencer提交的狀態(tài)根進(jìn)行比較。如果存在差異會(huì)開(kāi)始欺詐證明，存在欺詐行為開(kāi)始的state root均要被刪除，Sequencer需要重新計(jì)算丟失的state root。

在L2提交交易：

• 用戶將交易發(fā)送給sequencer節(jié)點(diǎn)，如果是有效交易，sequencer會(huì)立即將其添加到L2鏈中。L2的塊大小僅1 個(gè)事務(wù)，因此能立即將一個(gè)新塊與新事務(wù)一起添加到鏈中

• 然后在 sequencer 向L2鏈添加一些交易后，它將調(diào)用 L1 上的智能合約（CanonicalTransactionChain.sol）并將這些 L2 交易的交易數(shù)據(jù)與執(zhí)行過(guò)交易后L2的新state roots

• L1 上的智能合約將交易數(shù)據(jù)和state roots存儲(chǔ)在另一個(gè)智能合約中（StateCommitmentChain.sol）

• 交易數(shù)據(jù)存儲(chǔ)在L1之后，validator節(jié)點(diǎn)將把交易包含在它們的 L2 鏈副本中。驗(yàn)證者也可以選擇從L2同步，可以將直接從sequencer獲得新交易

跨鏈交易：L1->L2
從L1到L2的交易速度很快，在這個(gè)過(guò)程中只需依靠sequencer將消息中繼到L2鏈，用戶需要將他們的交易數(shù)據(jù)發(fā)送到 L1 上的智能合約（L1StandardBridge.sol）。例如，如果用戶想發(fā)送10 ETH到他們?cè)贚2上的地址，步驟如下：

• 用戶向 L1 上的橋接合約（L1StandardBridge.sol）發(fā)送 10 ETH

• 合約將ETH鎖定在L1上

• 合約將用戶的交易添加到交易隊(duì)列中（CanonicalTransactionChain.sol->enqueue）

• sequencer處理此交易，并將ETH存入用戶的L2帳戶。

跨鏈交易：L2->L1

用戶會(huì)將交易發(fā)送到L2上的特定智能合約，然后中繼器將讀取它并將其發(fā)送到 L1。例如用戶想將他們?cè)?L2 上的 10 WETH 轉(zhuǎn)移回他們 L1 地址上的 ETH，步驟如下：

• 用戶將10 WETH發(fā)送到 L2 上的橋接合約（L2StanderBridger.sol）

• 橋接合約銷毀WETH并將交易信息發(fā)送到另一個(gè)稱為L(zhǎng)2ToL1MessagePasser的智能合約。該智能合約記錄了需要從L2發(fā)送到L1的交易數(shù)據(jù)。

• 中繼節(jié)點(diǎn)從L2ToL1MessagePasser讀取此交易數(shù)據(jù)，并等待欺詐證明窗口（7 天）完成，然后再將交易發(fā)送到 L1。

• 隨后交易在L1上處理，用戶可以從L1中當(dāng)時(shí)鎖定資產(chǎn)的橋接合約（L1StandardBridge.sol）中鎖提取 ETH提取他們的ETH。
  

存儲(chǔ)在L1上的狀態(tài)：

由于每個(gè)交易的交易數(shù)據(jù)和結(jié)果狀態(tài)根必須存儲(chǔ)在L1上，因此最小化此數(shù)據(jù)的大小對(duì)于降低系統(tǒng)的存儲(chǔ)成本至關(guān)重要。這就是術(shù)語(yǔ)“rollup”的由來(lái)。以下步驟解釋了每個(gè) L2 事務(wù)的數(shù)據(jù)如何存儲(chǔ)在 L1 上：

• sequencer獲取許多順序L2事務(wù)的調(diào)用數(shù)據(jù)，并將它們組合成一個(gè)batch

• sequencer將這個(gè)batch發(fā)送到CanonicalTransactionChain合約

• 合約對(duì)每個(gè)交易的調(diào)用數(shù)據(jù)進(jìn)行哈希處理，并創(chuàng)建這些哈希值的merkel tree

• CanonicalTransactionChain獲取該批次的merkle根并將其發(fā)送到專門(mén)用于存儲(chǔ)的智能合約中
  

3、欺詐證明

欺詐證明是Optimism系統(tǒng)的一個(gè)非常重要的部分，這可以保證sequencer的誠(chéng)實(shí)性。
Optimistic Rollup對(duì)狀態(tài)轉(zhuǎn)移的保證是在一定時(shí)間窗口內(nèi)，允許挑戰(zhàn)者提交欺詐證明，在此期間任何人都可以對(duì)狀態(tài)轉(zhuǎn)換提出異議，并開(kāi)始仲裁。仲裁有兩種方式：

• 非交互式欺詐證明

• 如果sequencer將欺詐狀態(tài)根發(fā)布到L1，則驗(yàn)證者節(jié)點(diǎn)可以啟動(dòng)欺詐證明并在L1上執(zhí)行相應(yīng)的L2交易

• Optimism OVM1.0

• 交互式欺詐證明

• 在L2上由雙方進(jìn)行多輪交互后鎖定某條存疑指令后在 L1 仲裁

• Arbitrum/Optimism cannon（2022.3）

在 Optimism 實(shí)現(xiàn)中，一個(gè)L2區(qū)塊只包含一筆交易，使得區(qū)塊的 stateRoot 實(shí)際就是這筆交易的 stateRoot；即每筆交易都會(huì)有一個(gè)對(duì)應(yīng)的狀態(tài)被提交到 L1，因此它可以被單獨(dú)挑戰(zhàn)。

結(jié)合代碼分析

L1與L2上涉及的主要合約：

位置：optimism/packages/contracts/contracts

1、 L1->L2

在使用L2之前，用戶首先需要在L1StandardBridge進(jìn)行充值。用戶通過(guò)四個(gè)deposit函數(shù)可以存入對(duì)應(yīng)的ETH或ERC20代幣到L1StandardBridge合約。

或存入ERC20 token：

其中在_initiateETHDeposit函數(shù)中，設(shè)置了到L2的時(shí)候需要調(diào)用的函數(shù)

sendCrossDomainMessage函數(shù)觸發(fā)L1CrossDomainMessenger.sol中的sendMessage函數(shù)：

首先，在這個(gè)函數(shù)中encodeXDomainCalldata構(gòu)造了在L2中對(duì)應(yīng)的L2CrossDomainMessenger.sol合約中，會(huì)調(diào)用relayMessage函數(shù)：

其次，在_sendXDomainMessag內(nèi)部調(diào)用了CanonicalTransactionChain合約的enqueue函數(shù)：

CanonicalTransactionChain中的enqueue接收，經(jīng)過(guò)了以下幾個(gè)步驟：

• 首先，如果攻擊者在提交L1->L2的交易時(shí)將_gasLimit設(shè)置的很大，然后在 L2 合約中消耗，可能會(huì)導(dǎo)致Sequencer性能下降。于是Optimism設(shè)置了閾值enqueueL2GasPrepaid，_gasLimit超過(guò)閾值的部分合約將根據(jù)超出的大小按比例燃燒gas。

• msg.sender的說(shuō)法：對(duì)于 L1->L2 消息，如果 msg.sender 為合約，那么在 L2 執(zhí)行時(shí)，Origin 會(huì)被加上偏移。

• 將交易壓入queueElements隊(duì)列中

• 觸發(fā)TransactionEnqueued事件

  
  

data-transport-layer會(huì)監(jiān)聽(tīng)事件并存入數(shù)據(jù)庫(kù)，由Sequencer查詢TransactionEnqueued，轉(zhuǎn)換為交易并挖出對(duì)應(yīng)的區(qū)塊。
在L2中的L2CrossDomainMessenger合約中的relayMessage函數(shù)會(huì)對(duì)應(yīng)的處理這個(gè)交易，首先對(duì)交易進(jìn)行如下檢查：

• 首先檢查了msg.sender，msg.sender需要是L1CrossDomainMessenger

• 并且同一條消息之前沒(méi)有處理過(guò)

• 保證消息的target不是L2_TO_L1_MESSAGE_PASSER，防止L2的消息又回環(huán)到L1

隨后會(huì)調(diào)用到L2StandardBridge.sol中的finalizeDeposit函數(shù)，在這個(gè)函數(shù)中最終實(shí)現(xiàn)mint操作：

2、L2->L1

當(dāng)用戶需要在L2上銷毀一些代幣并在L1上使用它們時(shí)，用戶可以調(diào)用L2StandardBridge.sol中的withdraw函數(shù)：

或用戶或合約在L2調(diào)用入口函數(shù)L2CrossDomainMessenger.sendMessage()：

sendMessage會(huì)進(jìn)一步進(jìn)一步調(diào)用OVM_L2ToL1MessagePasser.passMessageToL1()，它計(jì)算消息哈希并更新合約狀態(tài)：

batch-submitter會(huì)監(jiān)聽(tīng) L2 區(qū)塊，進(jìn)行兩個(gè)操作：

• 打包批量交易 txBatch 提交到 L1

• 打包批量狀態(tài) stateBatch 提交到 L1

每隔幾秒鐘Sequencer就會(huì)檢查接收到的新交易，將它們與所需的任何其他元數(shù)據(jù)分批匯總，然后利用CanonicalTransactionChain.appendSequencerBatch()函數(shù)進(jìn)行提交。appendSequencerBatch沒(méi)有任何參數(shù)。批次以緊密打包的格式提交，避免了ABI編碼的低效率。
appendSequencerBatch函數(shù)：

• 首先計(jì)算批次頭，然后計(jì)算其哈希值

• 然后計(jì)算出批次的上下文

• 然后將哈希值和上下文存儲(chǔ)在存儲(chǔ)器中（batchesRef）

同時(shí)在sequencer執(zhí)行L2->L1交易時(shí)，將修改OVM_L2ToL1MessagePasser狀態(tài)樹(shù)(sentMessages[slot])，因而進(jìn)導(dǎo)致?tīng)顟B(tài)的變化，反應(yīng)在區(qū)塊頭部的stateRoot字段。batch-submitter隨后通過(guò)appendStateBatch函數(shù)打包批量狀態(tài)到state batch：

在_appendBatch函數(shù)中：

• Lib_MerkleTree.getMerkleRoot(_batch)計(jì)算這個(gè)batch的merkel root

• Lib_OVMCodec.ChainBatchHeader生成這個(gè)batch的header

• 然后存儲(chǔ)batch到數(shù)組中

在經(jīng)過(guò)預(yù)定的欺詐證明期并與StateCommitmentChain核實(shí)后，任何人都可以調(diào)用relayMessage函數(shù)，并在L1上最終完成提款。同時(shí)relayMessage也是一個(gè)可以pause的函數(shù)。

• _verifyXDomainMessage函數(shù)負(fù)責(zé)驗(yàn)證L2->L1交易存在

• 證明 交易 存在 stateRoot 中

• 證明 stateRoot 存在 batchRoot中

_verifyStateRootProof：

• 驗(yàn)證是否在欺詐證明周期中

• verifyStateCommitment函數(shù)驗(yàn)證_proof.stateRoot, _proof.stateRootBatchHeader, _proof.stateRootProof之間的一致性

_verifyStorageProof驗(yàn)證

• 信息是由L2CrossDomainMessenger通過(guò)L2_TO_L1_MESSAGE_PASSER發(fā)送

• 并且與_proof一致。

在relayMessage的剩余部分驗(yàn)證

• 之前沒(méi)有relay過(guò)相同的交易

• 確保這個(gè)交易沒(méi)有被Optimism阻止。

• target不是CanonicalTransactionChain，因此L2->L1消息不能被回送到L2

• 在調(diào)用前修改sender

• 觸發(fā)合約調(diào)用

• 調(diào)用成功后標(biāo)記為已經(jīng)吊用

3、OVM1.0與OVM2.0

前面提到，欺詐證明存有兩種實(shí)現(xiàn)方式：

• 非交互式欺詐證明

• 交互式欺詐證明

OVM1.0

由于OP Rollup依賴于欺詐證明，所以如果一條交易存在爭(zhēng)議，就需要重放該交易以證明交易的結(jié)果是否正確，但是有些EVM操作碼依賴于系統(tǒng)范圍內(nèi)的參數(shù)，這些參數(shù)可能會(huì)改變（例如存儲(chǔ)狀態(tài)或時(shí)間戳），這會(huì)導(dǎo)致交易在L1與L2間產(chǎn)生不同的行為。
因此Optimsim實(shí)現(xiàn)了OVM來(lái)處理L1上的L2爭(zhēng)端的機(jī)制，這個(gè)機(jī)制保證可以重現(xiàn)在L1上執(zhí)行L2事務(wù)時(shí)存在的 任何“上下文”，并且在理想情況下不引入太多開(kāi)銷。OVM是通過(guò)將上下文相關(guān)的EVM操作碼替換為其對(duì)應(yīng)的OVM操作碼來(lái)實(shí)現(xiàn)的。

OVM2.0

cannon的欺詐證明解決方案：

??關(guān)于Dorahacks

DoraHacks 是一個(gè)全球范圍內(nèi)的極客運(yùn)動(dòng)、全球黑客馬拉松組織者，也是全球最活躍的多鏈 Web3 開(kāi)發(fā)者平臺(tái)之一。DoraHacks.io平臺(tái)使得世界各地的Hacker和開(kāi)源開(kāi)發(fā)者可以參與黑客馬拉松、Bounty、Grant、Grant DAO，以及公共物品質(zhì)押等加密原生協(xié)議和基礎(chǔ)設(shè)施進(jìn)行協(xié)作并獲得資助。到目前為止，DoraHacks 社區(qū)的 4000 多個(gè)項(xiàng)目已經(jīng)獲得了來(lái)自全球行業(yè)支持者超過(guò) 3000 萬(wàn)美元的資助。大量開(kāi)源社區(qū)、DAO 和 超過(guò)50個(gè)主要區(qū)塊鏈生態(tài)系統(tǒng)正在積極使用 Dora 的基礎(chǔ)設(shè)施（DoraHacks.io）進(jìn)行開(kāi)源融資和社區(qū)治理。

??關(guān)于Dorahacks DAO Bounty
Dorahacks DAO Bounty，為各類DAO和組織賦能！
Bounty計(jì)劃為DAO和組織提供了一個(gè)強(qiáng)大的平臺(tái)，通過(guò)社區(qū)激勵(lì)的形式，發(fā)布問(wèn)題，協(xié)調(diào)任務(wù)，鼓勵(lì)用戶積極參與。
作為Bounty發(fā)布者，您可以根據(jù)我們的指南，發(fā)布社區(qū)相關(guān)的懸賞任務(wù)，解決問(wèn)題的同時(shí)，提升社區(qū)活躍度：https://dorahacks.io/blog/guides/publish-a-bounty/
作為賞金獵人，您可以在DAO Bounty計(jì)劃中發(fā)揮自己的專長(zhǎng)和能力，認(rèn)領(lǐng)懸賞，解決問(wèn)題，獲得酬金：https://dorahacks.io/daobounty

??關(guān)于Hacker Dōjō
Hacker Dōjō是由Hacker共建的加密、Web3前沿技術(shù)開(kāi)源知識(shí)社區(qū)。Dōjō會(huì)以直播/音頻/文字等形式定期組織分享session，內(nèi)容包括Web3領(lǐng)域前沿技術(shù)論文解讀、技術(shù)研討、工作坊、技術(shù)領(lǐng)袖研討會(huì)等。歡迎在Hacker Dōjo社區(qū)討論、學(xué)習(xí)和交流：Dora Dōjo - Dora Community Forum: https://community.dorahacks.io/c/buidl-dorahacks-io/6

目前Hacker Dōjō已分享的主題有：

• 密碼學(xué)：基礎(chǔ)專題（對(duì)稱加密算法、哈希函數(shù)、群和公鑰加密、數(shù)字簽名和KZG承諾、零知識(shí)證明、非對(duì)稱密碼算法、分布式密碼學(xué)）

• 密碼學(xué)：算法代碼專題（Halo、Halo2、Plonk、Groth16、分布式密鑰生成）

• 密碼學(xué)：抗量子計(jì)算破解算法專題

• Layer1架構(gòu)：Move系列、模塊化公鏈、共識(shí)協(xié)議Bullshark、內(nèi)存池協(xié)議Narwhal和共識(shí)協(xié)議Tusk、Aptos共識(shí)與交易并行執(zhí)行

• Layer2架構(gòu)：zkSync研究、Layer2的支付通道擴(kuò)容方法、Polygon Hermez、Optimism、StarkWare技術(shù)與生態(tài)梳理

• IRS系列：Interest Rate Swap and DeFi Platforms、Interest Rate Swap and Perpetual Swap、The Future Dencentralized Interest Rate Swap

• 量子計(jì)算系列：量子計(jì)算基礎(chǔ)、Qiskit專題（Qiskit入門(mén)、Deutsch-Jozsa算法、Bernstein-Vazirani算法、Simon算法、量子卷積神經(jīng)網(wǎng)絡(luò)、量子傅立葉變換、量子相位）、Pennylane專題（利用變分量子電路擬合傅里葉級(jí)數(shù)）、實(shí)驗(yàn)法觀測(cè)宏觀量子疊加態(tài)

• AIGC系列：ChatGPT比較語(yǔ)料評(píng)測(cè)、GPT-4論文解讀

加入Dōjō的Hacker可以提出自己的學(xué)習(xí)期望，主動(dòng)提案自己擅長(zhǎng)的技術(shù)話題，由Dōjō組織分享。同時(shí)，Hacker Dōjō推出Web3前沿課題研究計(jì)劃，定期選題，由Hacker進(jìn)行研究和講解，并以bounty形式獎(jiǎng)勵(lì)研究貢獻(xiàn)者。歡迎各位Hacker認(rèn)領(lǐng)Bounty：https://dorahacks.io/zh/daobounty

聯(lián)系我們：

Telegram:?@DoraDojo0

WeChat:?@HackerDojo0

E-mail:?hackerdojo0@gmail.com