時間：2023-05-03|瀏覽：244
本文嘗試從演化角度討論 Rollup Layer?2 的發(fā)展以及演進，主要解答以下幾個問題：
Rollup 是如何工作的
Rollup 的模塊化演進
模塊化帶來的可能性
模塊化應(yīng)用的技術(shù)趨勢
總結(jié)
區(qū)塊鏈的“三難問題”一直是困擾業(yè)界的一個難題，如果我們認(rèn)為 Layer?1 區(qū)塊鏈應(yīng)該首先保證“去中心化”和“安全”，那將“擴展性”方案從 Layer?1 遷移出來就是自然的選擇了，于是有了 Layer?2?。那新的難題就是如何通過 Layer?1 來保證 Layer?2 的安全。
最初有一種想法是定時將 Layer?2 應(yīng)用的狀態(tài)樹根寫到 Layer?1?，這樣可以通過狀態(tài)證明來校驗應(yīng)用的狀態(tài)，類似于交易所儲備金證明。但這種方式第三方無法通過公開的方式驗證兩次狀態(tài)轉(zhuǎn)換是正確的。
為了更深入的探討這個問題，我們抽象一下，任何程序的狀態(tài)都可以通過一個狀態(tài)轉(zhuǎn)換公式表達(dá)：
σt+?1 ≡ Υ(σt, T)
這個公式來自于 Ethereum 黃皮書，但它可以代表任意的程序。在這里 Υ 代表程序，σ 代表狀態(tài)。狀態(tài) σt+?1 由程序 Y 通過狀態(tài) σt 和交易 T 計算得出。交易 T 代表程序的輸入。任意時候，如果 σt 是確定的，程序 Y 是確定的，T 是確定的，那 σt+?1 就是確定的。
所以要提供公開的可驗證性，關(guān)鍵是 Y 要公開可用，歷史上所有的 T 要公開可用并且順序確定，中間的狀態(tài)可通過 Y 和 T 重新計算得到。而程序的公開可用我們可以通過開源來實現(xiàn)，關(guān)鍵是 T 公開可用如何保證，這就引入了數(shù)據(jù)可用性（DA）的概念。
數(shù)據(jù)可用性需要有個公開的不可篡改的賬本來記錄應(yīng)用的交易。自然想到，區(qū)塊鏈賬本就是這樣一個系統(tǒng)，于是將 Layer?2 的交易寫回 Layer?1?，保證數(shù)據(jù)可用性，這也就是 Rollup 名稱的來源。
所以 Layer?2 系統(tǒng)中需要有個角色收集用戶的交易，進行排序并寫入到 DA，這個角色叫?定序器（Sequencer）。這里的交易序列叫?Canonical Transaction Chain。
保證了數(shù)據(jù)的可用性，每個人都可以通過自己運行程序執(zhí)行交易來得到最終的狀態(tài)。但這里并沒有達(dá)成共識，因為每個人不確定自己得到的結(jié)果是否和其他人的結(jié)果一致，畢竟軟件或者硬件故障也可能導(dǎo)致數(shù)據(jù)不一致。所以需要另外一個角色將交易執(zhí)行后的狀態(tài)樹根定時公布出來，供大家校驗自己的狀態(tài)，這個角色叫?提案者（Proposer）。這里每次提交的狀態(tài)也構(gòu)成了一個狀態(tài)序列，和交易序列對應(yīng)，叫?State Commitment Chain。
到這里，我們達(dá)到了應(yīng)用的可驗證性。如果某個人運行的結(jié)果和 Proposer 提交的狀態(tài)不一致，并確定不是自己的問題，那就是 Proposer 作弊或者出錯了，那怎么讓別人也知道呢？這就需要引入**仲裁者（Arbitrator）**的角色。仲裁者需要是一個可信第三方，鏈上合約正好可以承擔(dān)這個角色。
仲裁有兩個方案：
Proposer 每次提交狀態(tài)的時候，同時提供與前一次狀態(tài)之間的狀態(tài)轉(zhuǎn)換有效證明（Validity Proof），鏈上的仲裁合約進行校驗。有效證明一般通過 Zero knowledge 技術(shù)生成，這種叫 ZK Rollup。
先假定 Proposer 的結(jié)果是對的，但如果發(fā)現(xiàn)不一致，則提交欺詐證明（Fraud Proof），由仲裁合約進行判定。如果仲裁合約判定 Proposer 作弊，則對 Proposer 進行懲罰，并將 State Commitment Chain 回滾到欺詐交易之前的狀態(tài)。當(dāng)然，為了保證安全，一般會設(shè)置一個比較長的挑戰(zhàn)周期來達(dá)到鏈上交易結(jié)算的最終確定性。這種叫 Optimistic Rollup。
我們還需要實現(xiàn) Layer?1 和 Layer?2 之間的資產(chǎn)互通。于是構(gòu)建一個 Layer?1 到 Layer?2 之間的橋，通過狀態(tài)證明來進行資產(chǎn)結(jié)算。而 Layer?2 在 Layer?1 的狀態(tài)根由 Layer?1 的仲裁合約保證，我們可以認(rèn)為這個橋的安全也受仲裁合約保證。
至此，我們得到了一個由 Layer?1 保證安全，并且可以和 Layer?1 進行資產(chǎn)互通的 Rollup Layer?2 方案。
當(dāng)然，Rollup 方案也做了一些妥協(xié)：
將交易寫入 Layer?1?，也就代表 Layer?2 的擴展性依然受 Layer?1 區(qū)塊大小限制。以 Ethereum 為例，某個 Layer?2 完全占據(jù) Ethereum 的所有區(qū)塊，能提供的平均 TPS 也才數(shù)百，擴展性受 DA 限制。
為了節(jié)省 Gas 費，Sequencer 會將交易批量寫入 DA，而在寫入 DA 之前，Sequencer 有可能通過調(diào)整交易的順序來作弊。
這里總結(jié)一下 Layer?2 的安全以及交易的最終確定性：
如果用戶自己運行了一個 Layer?2 的節(jié)點，并且忠實地按照 DA 的交易順序執(zhí)行，用戶可以認(rèn)為交易是即時確認(rèn)并且達(dá)到最終確定的，因為如果用戶執(zhí)行的結(jié)果和 Proposer 不一樣，說明 Proposer 作弊，需要回滾鏈上的狀態(tài)，最終會和用戶自己的節(jié)點執(zhí)行的結(jié)果一樣。 這里主要的風(fēng)險點在于前面提到的，如果實時從 Sequencer 同步數(shù)據(jù)， Sequencer 調(diào)整尚未寫入 DA 的交易的順序帶來的風(fēng)險。
如果用戶自己無法運行節(jié)點，需要依賴一個 RPC 提供方，用戶需要承擔(dān)一定的信任風(fēng)險。但這個風(fēng)險和用戶信任 Layer?1 的 RPC 節(jié)點帶來的風(fēng)險類似。這里額外的風(fēng)險依然是 Sequencer 丟棄交易或者重排交易帶來的風(fēng)險。
如果 Proposer 出錯，但沒有節(jié)點發(fā)起挑戰(zhàn)，超過了挑戰(zhàn)期，這時候錯誤的狀態(tài)無法回滾，只能通過社會共識硬分叉方式來修復(fù)狀態(tài)。
根據(jù)前面的分析，Rollup 解決方案中，鏈上的多個合約承擔(dān)不同的職能，代表不同的模塊。那自然想到，能否將模塊拆分到多個鏈，從而獲得更高的擴展性。這就是模塊化區(qū)塊鏈以及模塊化 Rollup 的思路。
模塊化在這里有兩層含義：
通過模塊化設(shè)計，讓系統(tǒng)變?yōu)橐粋€可拔插的系統(tǒng)。開發(fā)者可以通過模塊的組裝，滿足不同的應(yīng)用場景需求。
基于 1 提供的能力，模塊層的實現(xiàn)并不綁定在同一個 Layer?1 上，從而得到更好的擴展性。
我們可以認(rèn)為有三個主要的模塊層：
數(shù)據(jù)可用層（Data Availability）： 保證執(zhí)行層的交易數(shù)據(jù)可以通過公開的方式獲取，以及保證交易的序列。
結(jié)算層（Settlement）：實現(xiàn) Layer?1 和 Layer?2 之間的資產(chǎn)和狀態(tài)結(jié)算。它包含 State Commitment Chain 和 Bridge。
仲裁層（Arbitration）：校驗欺詐證明，并做出裁決（Optimistic）或者校驗有效證明（ZK）。仲裁層要有能力操控 State Commitment Chain。
將 DA 職能遷移出來，用一個獨立的解決方案，獲得的首要好處是 Layer?2 的交易 Gas 費至少降低一個數(shù)量級。
從安全方面來看，即便是 DA 鏈的去中心化弱于 Ethereum，但 DA 層對安全的保證主要是挑戰(zhàn)期內(nèi)的交易，過了挑戰(zhàn)期后，DA 主要是為了方便其他節(jié)點同步數(shù)據(jù)，對安全并沒有保障作用，所以去中心化的要求可以降低一個層次。
DA 專用鏈可以提供更高的存儲帶寬和更低的存儲成本，并且針對多個應(yīng)用共享 DA 進行專門的設(shè)計。這也是當(dāng)前如 Celestia、Polygon Avail 這樣的 DA 鏈的立足點。
將 DA 層拆分出去后，我們得到了下圖的架構(gòu)：
上圖中由 DA 來承擔(dān)保存 Canonical Transaction Chain 的職責(zé)，而給 Layer?1 留了一個 L1?To?L2 Transaction Queue 來實現(xiàn) Layer?1 和 Layer?2 之間的消息通信，用戶也可以直接寫交易給這個 Queue，確保 Layer?2 的 Permissionless，Sequencer 無法審核用戶或者交易。
但這里會引入一個新的難題，如果 Sequencer 寫入 DA 的交易序列和 Proposer 執(zhí)行的交易序列不一致，仲裁合約如何判定？一種方案是 DA 鏈和仲裁鏈之間有一個跨鏈橋，實現(xiàn)在仲裁合約中校驗 DA 鏈提供的數(shù)據(jù)證明。但這種方案依賴 DA 和其他鏈之間的跨鏈橋的實現(xiàn)，DA 的方案選型會受限制。另外一種方案是引入排序證明。
我們可以認(rèn)為 Sequencer 實際上也屬于 DA 方案的一部分，它相當(dāng)于一個 App-Specific 的 DA，主要基于以下理由：
Sequencer 需要提供批量寫入 DA 鏈之前這段時間內(nèi)的 DA 保證。
Sequencer 需要負(fù)責(zé)交易的驗證，排序，以及最終寫入 DA。
如果要求 Sequencer 給每個交易生成一個 Sequence Proof，則可以解決兩個問題：
對尚未寫入 DA 鏈的交易提供了保證，使 Sequencer 不敢隨意調(diào)整交易的順序或者丟棄交易。
如果 DA 鏈和仲裁鏈之間沒有跨鏈橋，則可以通過 Sequence Proof 的挑戰(zhàn)機制來保證數(shù)據(jù)可用。
Sequence Proof?具有以下特性：
它攜帶 Sequencer 的簽名，證明它是某個 Sequencer 發(fā)出的。
它可以證明某個交易在全部交易序列中的位置。
它是累加器（Accumulator）證明的一種。每個交易累加后會生成新的累加結(jié)果，與該交易之前所有歷史交易相關(guān)，使得其難以篡改。累加器的可選方案之一是默克爾累加器（Merkle Accumulator），累加結(jié)果表現(xiàn)為默克爾樹的根。
Sequence Proof 的工作原理：
用戶或者執(zhí)行節(jié)點提交交易給 Sequencer，Sequencer 將 Sequence Proof 返回給用戶，同時同步給其他節(jié)點。如果 Sequencer 在提交給 DA 之前丟棄或者篡改了交易的順序，用戶或者其他節(jié)點可以提交 Sequence Proof 給仲裁合約，從而懲罰 Sequencer。仲裁合約需要從 State Commitment Chain 合約中讀取交易累加器的根，從而校驗 Sequence Proof。
分場景探討一下：
Sequencer 丟棄或者重排了用戶交易。這會導(dǎo)致 Sequencer 在同一個位置生成了兩個 Sequence Proof。用戶提交 Sequence Proof 給仲裁合約，Sequencer 需要提供該交易被包含在最新的交易累加器的根中的證明，如果不能給出，則懲罰 Sequencer。
Sequencer 沒有正確地將交易寫入 DA 鏈，和 Proposer 合謀隱藏交易。如果仲裁鏈和 DA 鏈有橋，則通過橋來驗證，懲罰 Sequencer。否則用戶可以發(fā)起挑戰(zhàn)，要求 Sequencer 給出某個位置的交易的證明以及原始信息。但這種情況仲裁合約無法判斷用戶是否是惡意挑戰(zhàn)，所以如果 Sequencer 給出數(shù)據(jù)則不懲罰 Sequencer。而對用戶來說，惡意挑戰(zhàn)損人損己，也缺少經(jīng)濟動力。
我們通過引入 Sequence Proof 讓 Layer?2 的協(xié)議變得更安全。
將 Sequencer 劃分給 DA，只負(fù)責(zé)交易的驗證和排序，帶來的另外一個好處是容易實現(xiàn)交易的流水線以及并行執(zhí)行。
驗證交易時，需要驗證簽名和是否有足夠的 Gas 費，而 Gas 費的校驗需要依賴狀態(tài)。如果我們?yōu)榱吮ＷC驗證交易不會被執(zhí)行交易阻塞，允許 Sequencer 驗證交易依賴的狀態(tài)和最新狀態(tài)之間有一定的延遲（秒級），會導(dǎo)致 Gas 校驗會不太準(zhǔn)確，有被 DDoS 攻擊的風(fēng)險。
但我們認(rèn)為 Sequencer 屬于 DA 是一個正確的方向，所以值得我們進一步研究。比如可以將交易費中 DA 部分拆分出來，通過 UTXO（Sui Move Object） 表達(dá)，則可以降低 Gas 費檢測成本。
Sequencer 給交易排序然后輸出成交易流水線，然后同步給 Proposer 以及其他節(jié)點。每個節(jié)點可以根據(jù)自己的服務(wù)器情況來選擇并行方案。每個節(jié)點需要保證：只并行沒有因果關(guān)系的交易，有因果關(guān)系的交易必須按 Sequencer 的順序執(zhí)行，那最終的結(jié)果就是一致的。
Proposer 需要定時提交狀態(tài)樹的根，以及累加器的根到鏈上的 State Commitment Chain 合約中。
于是我們得到了一個低 Gas 費，高 TPS，并且更安全的模塊化 Layer?2?：?Rooch。
MoveOS：它包含 MoveVM 以及 StateDB，是系統(tǒng)的執(zhí)行以及狀態(tài)存儲引擎。StateDB 由兩層稀疏默克爾樹構(gòu)建，可以提供狀態(tài)證明。根據(jù)前面的分析可得出，狀態(tài)樹以及狀態(tài)證明是 Rollup 應(yīng)用不可或缺的組件。
RPC：對外提供查詢，提交交易，以及訂閱服務(wù)?？梢酝ㄟ^代理方式兼容其他鏈的 RPC 接口。
Sequencer：驗證交易，給交易排序，提供 Sequence Proof，將交易流式輸出到 Transaction Pipeline。
Proposer：從 Transaction Pipeline 獲取交易，批量執(zhí)行，定期提交到鏈上的 State Commitment Chain。
Challenger：從 Transaction Pipeline 獲取交易，批量執(zhí)行，和 State Commitment Chain 比較，決定是否發(fā)起挑戰(zhàn)。
DA & Settlement & Arbitration Interface：對不同的模塊層的抽象和封裝，保證在不同的實現(xiàn)之間切換時不影響上層業(yè)務(wù)邏輯。
Optimistic Rollup 方案中，鏈上的仲裁合約如何判定鏈下的交易執(zhí)行出錯，一直是一個難題。最初的想法是 Layer?1 上重新執(zhí)行一遍 Layer?2 的交易，但這種方案的難題是 Layer?1 的合約要模擬 Layer?2 的交易執(zhí)行，成本很高，也會限制 Layer?2 交易的復(fù)雜度。
最后業(yè)界摸索出一種交互式證明的方案。因為任何復(fù)雜的交易，最終會轉(zhuǎn)換成機器指令執(zhí)行，如果我們找到產(chǎn)生分歧的指令，則只需要在鏈上模擬執(zhí)行指令即可。
還用上面那個狀態(tài)轉(zhuǎn)換公式：
σt+?1 ≡ Υ(σt, T)
這里 Υ 代表指令，T 代表指令輸入，σ 代表指令所依賴的內(nèi)存狀態(tài)。如果在執(zhí)行過程中，給每個 σ 都生成一個狀態(tài)證明。 控辯雙方可以通過交互，發(fā)現(xiàn)雙方的分歧點 m，將 m-1 的狀態(tài) σ 以及指令 m 提交到鏈上仲裁合約模擬執(zhí)行，仲裁合約執(zhí)行后就可以給出判定。
所以剩下的問題就是通過什么方式來生成證明，主要有兩個方案：
直接在合約語言虛擬機中實現(xiàn)，比如 Arbitrum 的 AVM，F(xiàn)uel 的 FuelVM。
基于已有的指令集實現(xiàn)一個模擬器，在模擬器中提供證明能力。如 Optimism 的基于 MIPS 指令的 cannon，Arbitrum 新的基于 WASM 指令的 Nitro，以及 Rooch 的基于 MIPS 指令的 OMO。
OMO 是一個擁有單步狀態(tài)證明能力的通用字節(jié)碼模擬器，為多鏈執(zhí)行環(huán)境設(shè)計。有了 OMO 的支持，可以實現(xiàn)仲裁層的模塊化。任意支持圖靈完備合約的鏈，都可以在合約中模擬 OMO 的指令，作為仲裁層。
業(yè)界一直在爭論 Optimistic Rollup 和 ZK Rollup 孰優(yōu)孰劣，但我們認(rèn)為將二者結(jié)合起來可以兼得兩種方案的優(yōu)點。
在前面的 Optimistic 方案基礎(chǔ)上，我們再引入一個新的角色，ZK Prover。它批量給 Proposer 提交的交易狀態(tài)生成有效證明，并提交給仲裁合約。仲裁合約驗證后，就可以判定該交易在 Layer?1 上達(dá)到了最終確定性，可以進行 Layer?2 到 Layer?1 的提款交易的結(jié)算。
這種方案的優(yōu)點：
不會因為 ZK 的性能問題限制 Layer?2 的整體吞吐。
可以通過 ZK 縮短 Optimistic 的挑戰(zhàn)周期，提升用戶體驗。
在 ZK 的方案以及硬件加速成熟之前，我們可以先通過 Optimistic 構(gòu)建生態(tài)，同時模塊化方案可以讓 ZK 最后無縫接入進來。
如果我們進一步思考模塊化的趨勢，自然想到，既然 DA 可以遷移到別的鏈，那結(jié)算層是否也可以部署到別的鏈？
Layer?1 和 Layer?2 之間的資產(chǎn)結(jié)算主要依賴兩個組件，一個是 Bridge，一個是 State Commitment Chain，從 Bridge 結(jié)算的時候，需要依賴 State Commitment Chain 校驗 Layer?2 的狀態(tài)證明。 Bridge 當(dāng)然可以部署到多個鏈，但 State Commitment Chain 只能有一個權(quán)威的版本，由仲裁合約保證安全。
這個方向還需要深入研究，但有個初步的方案。其他鏈上的 State Commitment Chain 都是仲裁鏈（Ethereum）上的鏡像。這個鏡像并不需要同步全部的 Layer?2 State Root 到其他鏈，而是用戶按需通過 Ethereum 的狀態(tài)證明做映射。
當(dāng)然，其他鏈上還需要能校驗 Ethereum 上的狀態(tài)證明，所以需要知道 Ethereum 上的狀態(tài)根。當(dāng)前，將 Ethereum 上的狀態(tài)根同步到其他節(jié)點有兩個方案：?1. 依賴 Oracle。2. 嵌入 Ethereum 輕節(jié)點，校驗 Ethereum 的區(qū)塊頭。
這樣我們就可以得到一個支持多鏈結(jié)算，但安全由 Ethereum 保證的 Layer?2 方案。
這種方案和跨鏈的區(qū)別：
如果是依賴中繼鏈的跨鏈方案，可以認(rèn)為 Layer?2 替代了中繼鏈，是一個安全受仲裁合約保證的中繼層。
如果是鏈間互相校驗狀態(tài)證明的跨鏈方案，多鏈結(jié)算方案和它共享狀態(tài)根同步的技術(shù)方案，但簡化了許多。因為在多鏈結(jié)算方案中，狀態(tài)根的同步需求是單向的，只需要從仲裁鏈同步到其他鏈，不是兩兩互相同步。
通過模塊化，開發(fā)者可以通過 Rooch 組合出不同的應(yīng)用。
Rooch Ethereum Layer?2??= Rooch + Ethereum(Settlement+Arbitration) + DA
這是 Rooch 首先要運行的網(wǎng)絡(luò)。提供一個由 Ethereum 安全保證的，可以和 Ethereum 上的資產(chǎn)互通的 Move 運行平臺。未來可以擴展到多鏈結(jié)算。
Rooch Layer?3 Rollup DApp?= Rooch + DApp Move Contract + Rooch Ethereum Layer?2(Settlement + Arbitration) + DA 如果應(yīng)用把自己的結(jié)算和仲裁部署到 Rooch Layer?2?，它就是一個 Rooch 的 Layer?3 應(yīng)用。
XChain Rollup DApp?= Rooch + DApp Move Contract + XChain(Settlement + Arbitration) + DA 任意鏈都可以通過 Rooch 來給開發(fā)者提供一套基于 Move 語言的 Rollup DApp 工具包。開發(fā)者只需要通過 Move 語言編寫自己的應(yīng)用邏輯，就可以運行一個安全受 XChain 保障的，資產(chǎn)可以和 XChain 互通的，獨立環(huán)境的 Rollup 應(yīng)用。當(dāng)然這個需要和各公鏈的開發(fā)者來協(xié)同開發(fā)。
Sovereign Rollup DApp?= Rooch + DApp Move Contract + DA 應(yīng)用也可以將 Rooch 作為 Sovereign Rollup SDK，不部署 Bridge 以及 Arbitration 合約，State Commitment Chain 也保存在 DA，保證可驗證性，由社會共識保證安全。
Arweave SCP DApp?= Rooch + DApp Move Contract + DA（Arweave） SCP 和 Sovereign Rollup 思路類似，SCP 要求應(yīng)用程序的代碼也要保存到 DA。而 Rooch 中合約部署和升級都是交易，合約代碼在交易中，都會寫到 DA 層，所以我們認(rèn)為符合 SCP 的標(biāo)準(zhǔn)。
Move DApp Chain?= Cosmos SDK + MoveOS + DApp Move Contract MoveOS 可以作為一個獨立的 Move 運行環(huán)境嵌入到任意的鏈的運行環(huán)境中，去構(gòu)建應(yīng)用鏈或者新的公鏈。
非區(qū)塊鏈項目 非區(qū)塊鏈項目，可以把 MoveOS 作為一個可以帶有數(shù)據(jù)校驗?zāi)芰σ约按鎯ψC明能力的數(shù)據(jù)庫使用。比如用它做一個本地的博客系統(tǒng)，數(shù)據(jù)結(jié)構(gòu)和業(yè)務(wù)邏輯通過 Move 表達(dá)。等未來基礎(chǔ)設(shè)施成熟，則可以直接和區(qū)塊鏈生態(tài)對接起來。再比如可以用它做云計算中的 FaaS 服務(wù)，開發(fā)者通過 Move 編寫 FaaS 中的 Function，平臺托管狀態(tài)，用戶間的 Function 還可以互相組合調(diào)用。更多的可能性需要大家探索。
Rooch 的模塊化方案可以適應(yīng)于不同類型以及階段的應(yīng)用。比如開發(fā)者可以先通過部署合約在 Rooch Ethereum Layer?2 上驗證自己的想法，等成長起來后，將應(yīng)用遷移到獨立的基于 Rooch 搭建的 App-Specific Rollup 中。
再或者開發(fā)者直接通過 Sovereign Rollup 方式啟動應(yīng)用，因為應(yīng)用早期對安全性要求不高，也沒有和其他鏈互通資產(chǎn)的需求，先做到可驗證。等應(yīng)用成長起來，有了互通資產(chǎn)的需求，對安全性要求變高，這時候可以啟用結(jié)算以及仲裁模塊從而保證資產(chǎn)的安全。
由前面的分析可以看出，無論哪種組合方式，都依賴 DA。DA 在去中心化應(yīng)用中扮演的角色類似于 Web2 系統(tǒng)的日志平臺，可以用來做審計，支持大數(shù)據(jù)分析，進行 AI 訓(xùn)練等。未來會有很多應(yīng)用和服務(wù)圍繞 DA 建立起來。當(dāng)前已有 Celestia，Polygoin avail，未來還會有 EigenLayer，Ethereum danksharding 等。
根據(jù)前面的分析，我們得出 Sequencer 的角色應(yīng)該屬于 DA 的一部分，如果 DA 層能為應(yīng)用提供交易校驗?zāi)芰?，并且有足夠的性能，實際上完全可以由 DA 來承擔(dān) Sequencer 的職責(zé)，用戶直接寫交易到 DA。當(dāng)然能否使用應(yīng)用的 Token 付 DA 的 Gas 費是另外一個需要解決的問題。
新的應(yīng)用形態(tài)會促使新的編程語言爆發(fā)，這在 Web2 時代已經(jīng)驗證。而 Move 會成為構(gòu)建 Web3 DApp 的最佳語言。除了 Move 本身的語言特性外，還基于以下理由：
DApp 用同一種語言可以快速積累應(yīng)用所需要的基礎(chǔ)庫，形成生態(tài)聚集效應(yīng)。所以一開始支持多語言不是個好策略。
去中心化應(yīng)用至少要保證可驗證性，而智能合約語言可以讓開發(fā)者在保證可驗證性方面減少許多心智負(fù)擔(dān)。
Move 的平臺無關(guān)性，可以讓它很容易適配到不同的平臺，不同的應(yīng)用中。
Move 的狀態(tài)是結(jié)構(gòu)化的，有利于 DApp 的數(shù)據(jù)結(jié)構(gòu)表達(dá)以及存儲檢索。
我在 17 年底進入?yún)^(qū)塊鏈領(lǐng)域，當(dāng)時業(yè)界有非常多的團隊嘗試在區(qū)塊鏈領(lǐng)域構(gòu)建應(yīng)用。可惜當(dāng)時基礎(chǔ)設(shè)施尚不完備，業(yè)界尚未摸索出一個可復(fù)制的構(gòu)建應(yīng)用的模式，大多數(shù)應(yīng)用類項目以失敗告終，打擊了開發(fā)者和投資者。區(qū)塊鏈上的應(yīng)用應(yīng)該如何構(gòu)建出來？這個問題一直讓我思考了五年。
而現(xiàn)在，隨著 Layer?1?，Layer?2 以及智能合約，模塊化基礎(chǔ)設(shè)施的成熟，這個問題的答案也逐漸清晰起來。
希望在即將到來的 Web3 DApp 爆發(fā)潮中， Rooch 可以助開發(fā)者一臂之力，讓應(yīng)用更快的構(gòu)建，真正的落地。
來源：星球日報
熱點：rollup
非小號行情
