為何zkSync總是“宕機”？一文探討zkSync Workflow

看有朋友吐槽**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證明；

4）zk-SNARK證明分別relay給L2的Validators和L1 主鏈生成Commit Hash

5）Validator負責驗證zk-SNARK證明的正確性，無誤後提交給L1智能合約生成Verify Hash；

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

7）成功匹配後生成Verified Transaction交易最終上鍊；

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

這裡需要強調下，**zkSync採用了“二階段提交（2PC）”，通過前後Commit Hash 和Verify Hash兩個階段的Hash校驗最終確定合法交易批次。這樣做一方面可以確保系統運轉流程中的數據一致性安全，我個人理解，也是一種讓Sequencer和Validator兩個系統組件互相約束的去中心化思想顯現，值得點贊。 **

zkSync的Workflow主要有Relay、Sequencer、zkPorter、Validator四大角色，協調工作中會存在諸多“不穩定因素”。可概括為節點職能穩定性，節點協作穩定性，及算法和底層協議複雜性等。任一環節出現差錯，都可能導致出塊延遲。常見的Arbitrum Sequencer技術故障就是典型，zkSync面臨的挑戰只會更多。

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

1）多分佈式節點，可避免單點故障帶來的網絡不穩定，系統魯棒性使然；

**2）分佈式通證激勵機制可給開發者維護節點穩定提供源動力。 **

換個角度思考，**Verifing時間長在生態初期並非問題，可以有效提升鏈的安全性，避免系統中若干節點作惡。 ** 總之，若釐清zkSync的整個運營流程，進一步了解下layer 2的技術複雜性和其中為安全性所設計的“特殊”機制，能鞏固對L2技術賽道的信心。歡迎大家轉發分享，隨時DM我，一起深入交流學習zkSync。