📢 Gate廣場 #MBG任务挑战# 發帖贏大獎活動火熱開啓!
想要瓜分1,000枚MBG?現在就來參與,展示你的洞察與實操,成爲MBG推廣達人!
💰️ 本期將評選出20位優質發帖用戶,每人可輕鬆獲得50枚MBG!
如何參與:
1️⃣ 調研MBG項目
對MBG的基本面、社區治理、發展目標、代幣經濟模型等方面進行研究,分享你對項目的深度研究。
2️⃣ 參與並分享真實體驗
參與MBG相關活動(包括CandyDrop、Launchpool或現貨交易),並曬出你的參與截圖、收益圖或實用教程。可以是收益展示、簡明易懂的新手攻略、小竅門,也可以是現貨行情點位分析,內容詳實優先。
3️⃣ 鼓勵帶新互動
如果你的帖子吸引到他人參與活動,或者有好友評論“已參與/已交易”,將大幅提升你的獲獎概率!
MBG熱門活動(帖文需附下列活動連結):
Gate第287期Launchpool:MBG — 質押ETH、MBG即可免費瓜分112,500 MBG,每小時領取獎勵!參與攻略見公告:https://www.gate.com/announcements/article/46230
Gate CandyDrop第55期:CandyDrop x MBG — 通過首次交易、交易MBG、邀請好友註冊交易即可分187,500 MBG!參與攻略見公告:https://www.gate.com/announcements
為何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。