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 技術賽道的信心。

原文連結