เหตุใด zkSync จึง "หยุดทำงาน" เสมอ บทความเกี่ยวกับเวิร์กโฟลว์ zkSync

ฉันเห็นเพื่อนบางคนบ่นว่า zkSync หยุดทำงานตลอดเวลา อันที่จริง การเรียกมันว่า "ดาวน์ไทม์" นั้นเป็นการพูดเกินจริงไปเล็กน้อย พูดให้ชัดๆ ก็คือ "การสร้างบล็อกที่ไม่เสถียร" โดยพื้นฐานแล้ว เวลายืนยันสุดท้ายของธุรกรรมที่ส่งโดย Sequencer ไม่เสถียร แต่การรับรู้ของผู้ใช้ไม่ชัดเจนที่ส่วนท้ายแบบโต้ตอบ เนื่องจากการออกแบบการยืนยันของ zkSync มีความล่าช้าในการยืนยัน ** ความไม่แน่นอนในขั้นตอนการกระจายอำนาจในอนาคตจะบรรเทาลง ฉันวาดเวิร์กโฟลว์เพื่อหารือกับคุณ

สาเหตุที่ผู้ใช้มองว่า "ดาวน์ไทม์" อาจเป็นความล้มเหลวในการทำธุรกรรมที่เกิดจาก DApps บางตัวและความเข้ากันได้ของเชน ท้ายที่สุด การพัฒนา DApps บน zkSync เองถือเป็นความท้าทายที่ยิ่งใหญ่ ฉันใช้เวลาประมาณ 30 นาที-1 ชั่วโมงในการสังเกตการเปลี่ยนแปลงสถานะจาก Commit เป็น Verified จากเบราว์เซอร์อย่างเป็นทางการ และ DApp แบบโต้ตอบฝั่งผู้ใช้แทบจะไม่ได้รับผลกระทบจากสิ่งนี้ บทความนี้มุ่งเน้นไปที่ตรรกะพื้นฐานของเทคโนโลยี zkSync ทางวิทยาศาสตร์ที่เป็นที่นิยม เพื่อให้คุณเข้าใจอย่างชัดเจนเกี่ยวกับ zkSync

ตามที่แสดงในเวิร์กโฟลว์ zkSync จะทำงานตามขั้นตอนต่อไปนี้:

1. ผู้ใช้ส่งธุรกรรมแบทช์ไปยังตัวเรียงลำดับ Sequencer ผ่านการส่งต่อรีเลย์

2. Sequencer มีหน้าที่รับผิดชอบในการเรียงลำดับธุรกรรม การรวมและการบรรจุแบทช์ลงใน Merkle tree

3. zkPorter สร้างหลักฐาน zk-SNARK จาก Merkle tree;

4. zk-SNARK พิสูจน์ว่ารีเลย์สร้าง Commit Hash ไปยัง L2 Validators และ L1 main chain ตามลำดับ

5. Validator มีหน้าที่ตรวจสอบความถูกต้องของหลักฐาน zk-SNARK และส่งไปยัง L1 smart contract เพื่อสร้าง Verify Hash หากถูกต้อง

6. สัญญาสมาร์ท zkSync บน L1 ตรวจสอบการจับคู่ของ Commit Hash และ Verify Hash;

7. หลังจากการจับคู่สำเร็จ ธุรกรรมธุรกรรมที่ได้รับการยืนยันจะถูกสร้างขึ้นและอัปโหลดไปยังเชนในที่สุด

8. หากการจับคู่ล้มเหลว Commit Hash ดั้งเดิมจะใช้งานไม่ได้ และ Sequencer จะส่งแบทช์ใหม่และผ่านกระบวนการอีกครั้ง

จำเป็นต้องเน้นที่นี่ว่า **zkSync ใช้ "การคอมมิตแบบสองเฟส (2PC)" และสุดท้ายกำหนดชุดธุรกรรมทางกฎหมายผ่านการตรวจสอบแฮชของสองขั้นตอนของคอมมิตแฮชและตรวจสอบแฮช ในแง่หนึ่งสิ่งนี้สามารถรับประกันความสอดคล้องของข้อมูลและความปลอดภัยในกระบวนการทำงานของระบบในความเข้าใจส่วนตัวของฉันมันเป็นการแสดงให้เห็นถึงแนวคิดของการกระจายอำนาจที่ จำกัด ส่วนประกอบสองระบบคือ Sequencer และ Validator และคุ้มค่า ของการสรรเสริญ **

เวิร์กโฟลว์ของ zkSync มีบทบาทหลักสี่ประการ: Relay, Sequencer, zkPorter และ Validator จะมี "ปัจจัยที่ไม่เสถียร" มากมายในการทำงานประสานงาน สามารถสรุปได้ว่าเป็นความเสถียรของฟังก์ชันโหนด ความเสถียรของการทำงานร่วมกันของโหนด และความซับซ้อนของอัลกอริทึมและโปรโตคอลพื้นฐาน ข้อผิดพลาดในลิงก์ใด ๆ อาจทำให้เกิดความล่าช้าในการบล็อก ความล้มเหลวทางเทคนิคของ Arbitrum Sequencer เป็นเรื่องปกติ และ zkSync จะเผชิญกับความท้าทายมากขึ้นเท่านั้น

สำหรับความซับซ้อนของอัลกอริทึม นี่คือชะตากรรมของห่วงโซ่ zkSync และนักพัฒนาระบบนิเวศจำเป็นต้องทำงานอย่างหนักเพื่อเอาชนะมัน สำหรับความเสถียรของ **node intelligence และการทำงานร่วมกัน ผมคิดว่าหลังจากการมาถึงของขั้นตอนการกระจายอำนาจในอนาคต มันจะได้รับการปรับปรุงอย่างมีประสิทธิภาพ **ตรรกะก็ง่ายเช่นกัน:

1) โหนดแบบกระจายหลายจุดสามารถหลีกเลี่ยงความไม่เสถียรของเครือข่ายที่เกิดจากความล้มเหลวเพียงจุดเดียว ซึ่งเกิดจากความทนทานของระบบ

**2) กลไกจูงใจโทเค็นแบบกระจายสามารถให้นักพัฒนามีแรงจูงใจในการรักษาความเสถียรของโหนด **

เมื่อคิดจากอีกมุมมองหนึ่ง **การ Verifing ที่ยาวนานไม่ใช่ปัญหาในช่วงแรกของระบบนิเวศน์ มันสามารถปรับปรุงความปลอดภัยของ chain ได้อย่างมีประสิทธิภาพและป้องกันบางโหนดในระบบไม่ให้ทำสิ่งชั่วร้าย ** กล่าวโดยสรุป หากคุณอธิบายกระบวนการทำงานทั้งหมดของ zkSync และเข้าใจความซับซ้อนทางเทคนิคของเลเยอร์ 2 และกลไก "พิเศษ" ที่ออกแบบมาเพื่อความปลอดภัยมากขึ้น คุณจะรวมความเชื่อมั่นในเส้นทางทางเทคนิค L2 ได้ ทุกคนสามารถส่งต่อและแชร์ DM ฉันได้ตลอดเวลา และมาแลกเปลี่ยนและศึกษา zkSync ในเชิงลึกกัน