zkSync運行機制梳理，它並非頻繁地「宕機」

看有朋友吐槽@zkSync 總是宕機，其實稱「宕機」略微言過其辭了，準確說是「出塊不穩定」。

本質上是，Sequencer 提交的交易，最終Verified 的時間不穩定，但用戶在交互端感知並不明顯，因為zkSync 的Verify 設計就存在確認滯後性。

未來去中心化階段不穩定性會得到緩解。我畫了個workflow 和大家探討下。

之所以有用戶感知「宕機」，可能是某些DApp 和鏈底層兼容性導致的交易失敗問題，畢竟在zkSync 上開發DApp 本身挑戰就很大。

我從官方瀏覽器觀察Commit 到Verified 的Status 改變大致需要30min-1 小時左右，而用戶端交互DApp 幾乎不受此影響。

此文重點在科普zkSync 的技術底層邏輯，帶大家清晰地認識zkSync。

如workflow 所示，zkSync 運行分以下步驟：

1、User 通過relay 轉發向Sequencer 排序器發送批量交易；

2、Sequencer 負責對交易進行排序、聚合打包batch 成Merkle 樹；

3、zkPorter 將Merkle 樹生成zk-SNARK 證明；zk-SNARK 證明分別relay 給L2 的Validators 和L1 主鏈生成Commit Hash；Validator 負責驗證

4、zk-SNARK 證明的正確性，無誤後提交給L1 智能合約生成Verify Hash；

5、L1 上的zkSync 智能合約校驗Commit Hash 和Verify Hash 的匹配性；

6、成功匹配後生成Verified Transaction 交易最終上鍊；

7、若匹配失敗，原來的Commit Hash 作廢，由Sequencer 重新提交batch 再走一遍流程。

這裡需要強調下，zkSync 採用了「二階段提交（2PC）」，通過前後Commit Hash 和Verify Hash 兩個階段的Hash 校驗最終確定合法交易批次。

這樣做一方面可以確保系統運轉流程中的數據一致性安全，我個人理解，也是一種讓Sequencer 和Validator 兩個系統組件互相約束的去中心化思想顯現，值得點贊。

zkSync 的Workflow 主要有Relay、Sequencer、zkPorter、Validator 四大角色，協調工作中會存在諸多「不穩定因素」。

可概括為節點職能穩定性，節點協作穩定性，及算法和底層協議複雜性等。任一環節出現差錯，都可能導致出塊延遲。常見的Arbitrum Sequencer 技術故障就是典型，zkSync 面臨的挑戰只會更多。

至於算法複雜性，這是zkSync 鏈的天命所歸，需要生態開發者們鉚足勁去克服。而節點智能和協作的穩定性，我覺得未來去中心化階段到來後，會得到有效改善。邏輯也簡單：

多分佈式節點，可避免單點故障帶來的網絡不穩定，系統魯棒性使然；分佈式通證激勵機制可給開發者維護節點穩定提供源動力。

換個角度思考，Verifing 時間長在生態初期並非問題，可以有效提升鏈的安全性，避免系統中若干節點作惡。

總之，若釐清zkSync 的整個運營流程，進一步了解下layer 2 的技術複雜性和其中為安全性所設計的「特殊」機制，能鞏固對L2 技術賽道的信心。