วิวัฒนาการฉันทามติของ Sui: จาก Tusk สู่ Mysticeti

Sui ได้เปลี่ยนแกนกลางของฉันทามติมาแล้วสองครั้ง และเครือข่ายไม่เคยต้องการ hard fork เลย

บทความนี้เป็นส่วนหนึ่งของซีรีส์เกี่ยวกับ Sui:

• Discovering Sui: A Blockchain With Multiple Innovations
• Under the Hood of Sui: Validators, Consensus and Staking
• Sui: The Object Model, or Rethinking Blockchains Through Data
• Sui Governance: Upgrading Without Breaking
• Sui's Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5 Seconds

สาเหตุมาจากการเลือกสถาปัตยกรรม Narwhal ซึ่งเป็นเลเยอร์ที่รับผิดชอบการเผยแพร่ธุรกรรมระหว่าง validator และจัดระเบียบเป็น DAG ยังคงเสถียรตลอดทั้งสามโปรโตคอล เหนือขึ้นไป กลไกที่รับผิดชอบการเรียงลำดับธุรกรรมสามารถสลับเปลี่ยนได้ Tusk, Bullshark และ Mysticeti ต่างเสียบเข้ากับรากฐานเดียวกัน ในขณะที่บล็อกเชนอื่นจะต้องสร้างใหม่ตั้งแต่ต้น Sui เพียงแค่เปลี่ยนเลเยอร์เดียว

มีประเด็นด้านคำศัพท์ที่ควรชี้แจงไว้ก่อน Sui จัดการธุรกรรมสองประเภทแตกต่างกัน และความแตกต่างนั้นไม่เกี่ยวข้องกับโปรโตคอลฉันทามติที่กำลังทำงานอยู่ ออบเจกต์ที่เป็นเจ้าของโดยฝ่ายเดียว เช่น การโอนอย่างง่าย จะข้ามฉันทามติทั้งหมดผ่าน Byzantine Consistent Broadcast ซึ่งเร็วกว่า เฉพาะออบเจกต์ที่ใช้ร่วมกันเท่านั้นที่ต้องการฉันทามติสำหรับการเรียงลำดับ กลไกนี้มีมาตั้งแต่เปิดตัว Sui และทำงานโดยไม่คำนึงว่าโปรโตคอลฉันทามติใดกำลังทำงาน ไม่ควรสับสนกับวิวัฒนาการของโปรโตคอลฉันทามติเอง ซึ่งเป็นหัวข้อของบทความนี้

Tusk: จุดเริ่มต้นแบบ Asynchronous

Tusk ถูกออกแบบมาสำหรับเครือข่ายที่ไม่สามารถสมมติอะไรเกี่ยวกับเวลาส่งข้อความได้ ไม่มีขอบเขตเวลา ไม่มีสมมติฐานด้านการซิงโครไนซ์ นั่นคือสถานการณ์ที่ยากที่สุด และยังเป็นสถานการณ์ที่สมจริงที่สุดสำหรับเครือข่ายทั่วโลกที่สภาพแวดล้อมแตกต่างกันอย่างมากจาก validator หนึ่งไปยัง อีก validator หนึ่ง

แนวคิดหลัก: เมื่อ DAG ของ Narwhal ถูกสร้างขึ้นแล้ว ฉันทามติจะบรรลุโดยไม่ต้องสื่อสารเพิ่มเติม validator แต่ละตัวใช้อัลกอริทึมเดียวกันที่กำหนดได้กับมุมมองท้องถิ่นของ DAG และได้ผลการเรียงลำดับเหมือนกันกับ validator อื่นทุกตัว ไม่มีรอบการลงคะแนน ไม่มีการประสานงานอย่างชัดเจน ลำดับถูกอ่านจากโครงสร้างอ้างอิงเอง โดยการระบุจุดยึดที่ทำหน้าที่เป็น commit markers

เกณฑ์มาตรฐานในเอกสารต้นฉบับ วัดจาก 20 validator ให้ปริมาณงานประมาณ 160,000 ธุรกรรมต่อวินาที ด้วยความหน่วงประมาณ 3 วินาที ในขณะนั้น นั่นถือว่าล้ำหน้ากว่าที่ระบบคลาสสิกจะทำได้

ยังคงมีสองปัญหา ประการแรก ความหน่วง: 3 วินาทีใช้งานได้สำหรับหลายกรณี แต่เป็นอุปสรรคสำหรับการซื้อขายหรือเกมแบบเรียลไทม์ ประการที่สอง ความเป็นธรรม ในสภาพแวดล้อม asynchronous อย่างสมบูรณ์ validator ที่มีการเชื่อมต่อดีกว่าจะเห็นธุรกรรมของตนถูกรวมบ่อยกว่าตัวอื่น ซึ่งเป็นความไม่สมดุลเชิงโครงสร้างที่เอื้อต่อโหนดที่เร็วที่สุด

Tusk ส่วนใหญ่อยู่ในงานวิจัยและบน testnet เมื่อ mainnet ของ Sui เปิดตัวในปี 2023 Bullshark เข้ามารับหน้าที่แล้ว

Bullshark: Partial Synchrony

การก้าวกระโดดทางแนวคิดของ Bullshark ขึ้นอยู่กับสมมติฐานเดียว: ส่วนใหญ่แล้ว เครือข่ายทำงานได้ตามปกติ แทนที่จะเตรียมรับมือกับสถานการณ์เลวร้ายที่สุดตลอดเวลา โปรโตคอลจะใช้ประโยชน์จากช่วงเวลาที่ข้อความมาถึงภายในความล่าช้าที่เหมาะสม นี่คือโมเดล partially synchronous: สมมติขอบเขตเวลาภายใต้สภาวะปกติ ความทนทานแบบ asynchronous จะเข้ามาเมื่อเครือข่ายเสื่อมสภาพ

จากสมมติฐานนั้น ตามมาด้วย fast path ที่แท้จริงของ Bullshark ซึ่งไม่ควรสับสนกับความแตกต่างของออบเจกต์ที่เป็นเจ้าของ/ใช้ร่วมกันที่กล่าวถึงข้างต้น ในช่วง synchronous โปรโตคอลสามารถ commit ได้เร็วขึ้น โดยไม่ต้องรอหลายรอบเหมือนในโหมดที่เสื่อมสภาพ มันเป็นทางลัดความหน่วงที่ขึ้นอยู่กับสภาพของเครือข่าย

Bullshark ยังแก้ปัญหาความเป็นธรรมที่ Tusk ยังไม่ได้แก้ไข ผ่าน weak links ลิงก์เหล่านี้ช่วยให้ validator ที่ช้าชั่วคราวถูกรวมในฉันทามติสุดท้าย แม้ว่า validator ที่เร็วกว่ายังไม่ได้อ้างอิงถึงมัน ไม่มี validator ที่ซื่อสัตย์ถูกปฏิเสธเพราะการเชื่อมต่อที่ไม่ดี โปรโตคอลยังปรับปรุงการเลือก anchor และการล้างหน่วยความจำ ซึ่งทำให้รับโหลดได้ยาวนานขึ้น

ต้นทุน: ความซับซ้อนที่มากขึ้น Weak links และการปรับตัวของเครือข่ายทำให้เกิด edge cases และค่าใช้จ่ายในการคำนวณ เอกสารรายงาน 125,000 TPS ที่ความหน่วง 2 วินาทีจาก 50 ฝ่าย ซึ่งต่ำกว่า Tusk บนกระดาษ แต่การเปรียบเทียบนั้นทำให้เข้าใจผิด: Tusk วัดจาก 20 validator และปริมาณงานลดลงตามกลไกเมื่อเครือข่ายเติบโต ตัวเลขทั้งสองไม่สามารถเปรียบเทียบโดยตรงได้ ส่วนความหน่วง ยังคงอยู่ในช่วงหนึ่งวินาที ซึ่งยังช้าเกินไปสำหรับแอปพลิเคชันที่ต้องการมากที่สุด

สำหรับ Sui การเปลี่ยนผ่านนี้มีคุณค่าหลักประการเดียว: พิสูจน์ว่าเครือข่ายสามารถเปลี่ยนฉันทามติโดยไม่เกิดการหยุดชะงัก เป็นสัญญาณความเชื่อมั่นที่มีความหมายสำหรับนักพัฒนาที่สร้างบน มัน

Mysticeti: การละทิ้ง Explicit Certification

Mysticeti ไม่ได้ขยาย Bullshark แต่เปลี่ยนตรรกะพื้นฐาน ทั้ง Tusk และ Bullshark ต้องพึ่งพา DAG ที่ผ่าน การรับรอง: แต่ละบล็อกต้องได้รับการลงนามโดย quorum ของ validator ก่อนที่จะถือว่าพร้อมใช้งาน การรับรองนั้นมีค่าใช้จ่ายสูง ทั้งในด้านลายเซ็นที่ต้องผลิตและตรวจสอบ และในการส่งข้อมูลผ่านเครือข่าย มันเป็นคอขวดที่ทั้งสองรุ่นก่อนหน้ามีร่วมกัน

Mysticeti ลบขั้นตอนนั้นออกทั้งหมด มันทำงานบน DAG ที่ไม่ผ่านการรับรอง: validator ลงนามและเผยแพร่บล็อกของตน และนั่นก็เพียงพอแล้ว ข้อตกลงไม่ได้ถูกลงคะแนนอีกต่อไป แต่ถูกอนุมาน เมื่อ validator อ้างอิงบล็อกของอีกตัวหนึ่งในผลลัพธ์ของตนเอง การอ้างอิงนั้นถือเป็นการอนุมัติโดยนัย ฉันทามติได้มาจากพฤติกรรมการอ้างอิง โดยไม่มีข้อความลงคะแนนโดยเฉพาะเลย

ผลลัพธ์แสดงให้เห็นในสองมิติ ด้านความหน่วง Mysticeti commit ในสามรอบของข้อความ ซึ่งเป็นค่าต่ำสุดตามทฤษฎี เทียบได้กับ BFT ในทางปฏิบัติ ด้านทรัพยากร การกำจัดลายเซ็นหลายพันรายการต่อรอบช่วยลดภาระ CPU ได้อย่างมีนัยสำคัญ: ลดลงประมาณ 40% ในการผลิต (จาก ~48% เหลือ ~29% ใน validator ที่ใช้งานจริง) โปรโตคอลยังรัน leader หลายตัวพร้อมกันในแต่ละรอบ ซึ่งลดความหน่วงค่ามัธยฐานและ tail latency และรองรับการขาดหายของ leader โดยไม่หยุดชะงัก

ตัวแปรหนึ่ง Mysticeti-FPC เพิ่ม fast commit path สำหรับการโอนสินทรัพย์ คุณสมบัติเด่นคือการถักรวมธุรกรรมเหล่านั้นโดยตรงเข้าไปใน DAG แทนที่จะจัดการแยกต่างหาก ซึ่งประหยัดลายเซ็นและข้อความ นี่คือที่ที่ fast commit path ที่แท้จริงซึ่งฝังอยู่ในโครงสร้างอยู่ ไม่ใช่ใน Bullshark

ตัวเลขที่วัดในสภาพแวดล้อมที่ควบคุม: 300,000 TPS ด้วย 10 โหนด และ 400,000 TPS ด้วย 50 โหนด ก่อนที่ความหน่วงจะเกินหนึ่งวินาที ภายใต้โหลดต่อเนื่อง การ commit เกิดขึ้นประมาณ 0.5 วินาทีที่ 200,000 TPS ในการทดสอบเดียวกัน โปรโตคอลชั้นนำอื่น ๆ สูงสุดต่ำกว่า 150,000 TPS ด้วยความหน่วงเริ่มต้นประมาณ 2 วินาที

แล้วยังมีตัวเลขที่ถูกอ้างถึงอย่างกว้างขวาง "ลดความหน่วง 80% เมื่อเทียบกับ Bullshark" (จาก ~1.9 วินาที เหลือ ~400ms) ตัวเลขนี้ถูกต้อง แต่เป็นการเปรียบเทียบในกรณีที่ดีที่สุด: เปรียบ Bullshark ในสภาวะเสื่อมสภาพกับ Mysticeti ในสภาวะที่เหมาะสมที่สุด ภายใต้โหลดออบเจกต์ที่ใช้ร่วมกันทั่วไป ผลประโยชน์นั้นน้อยลง แม้ว่าจะไม่มีการวัดสาธารณะที่ระบุตัวเลขที่แน่ชัด ควรจำไว้ด้วยว่า: ตัวเลข 200,000–400,000 TPS มาจากเกณฑ์มาตรฐานที่ควบคุม บน mainnet ภายใต้สภาวะจริง ปริมาณงานที่สังเกตได้ต่ำกว่ามาก

สิ่งที่วิถีแสดงให้เห็น

เมื่อเรียงลำดับสามรุ่น ความก้าวหน้าชัดเจน ตราบใดที่อ่านตัวเลขในบริบท

ปริมาณงานเพิ่มขึ้นจาก ~160,000 TPS (Tusk, 20 validator) เป็น 125,000 TPS (Bullshark, 50 ฝ่าย) และจากนั้นเป็น 300,000–400,000 TPS ขึ้นอยู่กับการกำหนดค่า (Mysticeti) จำนวนโหนดแตกต่างกัน ดังนั้นค่าเหล่านี้ไม่สามารถเปรียบเทียบจุดต่อจุดได้: ให้ลำดับขนาด ไม่ใช่การจัดอันดับที่เข้มงวด ส่วนความหน่วง ลดลงอย่างชัดเจน: จาก 3 วินาที เหลือประมาณ 0.5 วินาที ผ่าน ~2 วินาทีสำหรับ Bullshark ด้านการสื่อสาร ความก้าวหน้าเคลื่อนจากศูนย์ overhead หลังจาก DAG ถูกสร้าง (แต่มีการรับรองที่มีราคาแพงก่อนหน้า) ไปสู่การรับรองโดยนัยที่กำจัดการรับส่งข้อมูลการลงคะแนนส่วนใหญ่

จุดเปลี่ยนที่แท้จริงไม่ได้อยู่ระหว่าง Tusk และ Bullshark ทั้งคู่อยู่ในตระกูลเดียวกัน: DAG ที่ผ่านการรับรอง, explicit certification, การปรับปรุงทีละน้อย การแตกหักอยู่ระหว่าง Bullshark และ Mysticeti ด้วยการละทิ้ง certification Tusk และ Bullshark ปรับปรุงขั้นตอน Mysticeti กำจัดมัน

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

Mysticeti อาจไม่ใช่คำสุดท้าย แนวทางของ Sui คือการเปลี่ยนส่วนประกอบเมื่อมีตัวที่ดีกว่าเกิดขึ้น โดยไม่แตะส่วนที่เหลือ หากรุ่นที่สี่มาถึง มันก็จะเสียบเข้ากับ Narwhal เดิม

แหล่งที่มา

• Tusk — Danezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021). arXiv · PDF
• Bullshark — Spiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical (2022). arXiv · PDF
• Mysticeti — Babel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs (2023, NDSS 2025). arXiv · PDF

Sui's Consensus Evolution: From Tusk to Mysticeti ได้รับการเผยแพร่ครั้งแรกใน Coinmonks บน Medium ซึ่งผู้คนกำลังสนทนาต่อโดยการไฮไลต์และตอบกลับเรื่องราวนี้