เหตุใด 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 smart contract บน L1 ตรวจสอบการจับคู่ Commit Hash และยืนยันแฮช 7) สร้าง Verified หลังจากจับคู่สำเร็จ ธุรกรรม Transaction จะถูกอัปโหลดไปยังเชนในที่สุด 8) หากการจับคู่ล้มเหลว Commit Hash ดั้งเดิมจะถูกใช้ไม่ได้ และ Sequencer จะส่งแบทช์ใหม่และผ่านกระบวนการอีกครั้ง .

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

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

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

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

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

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