คู่มือเทคโนโลยี: คำอธิบายที่สมบูรณ์เกี่ยวกับกลุ่มเทคโนโลยีบล็อกเชน Supra
สรุป
Supra ผสมผสานนวัตกรรมที่สั่งสมมานานหลายปีเข้ากับสถาปัตยกรรมที่ทรงพลังและมีประสิทธิภาพสูง ซึ่งบูรณาการในแนวตั้งอย่างสมบูรณ์กับการสนับสนุนสัญญาอัจฉริยะ MultiVM และบริการดั้งเดิม รวมถึงการคาดการณ์ราคา หมายเลขสุ่มบนเครือข่าย การสื่อสารข้ามสายโซ่ และความสามารถด้านระบบอัตโนมัติ
บนพื้นฐานนี้ บทความจะให้รายละเอียดเกี่ยวกับกระบวนการทำธุรกรรมแบบ end-to-end ของ Supra blockchain และแสดงวิธีลดความเสี่ยงจากการเซ็นเซอร์และภัยคุกคามจากการโจมตี Maximum Extractable Value (MEV) ได้อย่างมีประสิทธิภาพ
เครือข่าย Supra ให้บริการและความสามารถที่หลากหลายโดยอิงตามแพลตฟอร์มความปลอดภัยที่ใช้ร่วมกัน ซึ่งรวมถึงเทคโนโลยีที่เป็นนวัตกรรม: Distributed Oracle Protocol (DORA), Distributed Verifiable Random Functions (DVRF), เครือข่ายอัตโนมัติแบบ Zero-block Latency, สถาปัตยกรรมคอนเทนเนอร์ที่ได้รับแรงบันดาลใจจาก AppChain, การสนับสนุน multi-VM และเพิ่มประสิทธิภาพผ่านการดำเนินการบล็อกการประมวลผลธุรกรรมแบบขนาน นอกจากนี้ การออกแบบข้ามสายโซ่ของ Supra อย่าง HyperLoop และ HyperNova ทำให้ Supra กลายเป็น "IntraLayer" ตัวแรกของโลกที่ทำให้เกิดการเชื่อมต่อระหว่างหลายสายโซ่ผ่านลอจิกแพลตฟอร์มสัญญาอัจฉริยะ
1. การบูรณาการบริการบล็อคเชนในแนวดิ่งและสมบูรณ์แบบ
Supra มุ่งมั่นที่จะส่งเสริมการเปลี่ยนแปลงของเทคโนโลยีบล็อกเชนผ่านการวิจัยที่ก้าวล้ำและความสามารถด้านวิศวกรรมที่ยอดเยี่ยม เป้าหมายคือการสร้างบล็อกเชนชั้น 1 ที่มีประสิทธิภาพซึ่งรวมบริการที่เกี่ยวข้องกับบล็อกเชนต่างๆ ไว้อย่างครบถ้วน เพื่อมอบผู้ใช้รายบุคคล ลูกค้าสถาบัน และนักพัฒนาในการจัดหาโซลูชันแบบครบวงจรและ ประสบการณ์การใช้งานที่ราบรื่น
ในบทความนี้ เราจะแสดงให้เห็นว่าเทคโนโลยี Supra ตีความคำพูดอันโด่งดังของนักปรัชญาชาวกรีกโบราณอย่าง Aristotle ได้อย่างไร: "ส่วนรวมมีค่ามากกว่าผลรวมของส่วนต่างๆ" Supra นำเสนอชุดฟังก์ชันบล็อกเชนที่ครอบคลุมและยึดถือแนวคิดของการบูรณาการในแนวดิ่งโดยสมบูรณ์ บริการ สนับสนุนการพัฒนาระบบนิเวศที่สมบูรณ์และสถานการณ์การใช้งานที่หลากหลาย
ภาพรวมฟังก์ชันหลัก
บริการเนทิฟที่จัดหาโดย Supra blockchain สำหรับ dApps (แสดงในรูปที่ 1) ครอบคลุมฟังก์ชันหลักต่อไปนี้:
บล็อกเชนชั้นที่ 1
รองรับสินทรัพย์หลายประเภท รวมถึงโทเค็นดั้งเดิม โทเค็นแบบตั้งโปรแกรมได้และแบบไม่มีฟังก์ชันได้ และโทเค็นแบบข้ามสายโซ่มาตรฐาน
สภาพแวดล้อมการดำเนินการตามสัญญาอัจฉริยะ
นำเสนอแพลตฟอร์มสัญญาอัจฉริยะของทัวริงที่หลากหลายบนห่วงโซ่ เหมาะสำหรับแอปพลิเคชันบล็อกเชนสาธารณะต่างๆ เช่น โปรโตคอล DeFi เกมบล็อกเชน ลอตเตอรี การติดตามห่วงโซ่อุปทาน ฯลฯ
บริการข้อมูลนอกเครือข่าย
ให้บริการข้อมูลตามความต้องการ (ดึง) และสตรีมมิ่ง (พุช) รวมถึงออราเคิลราคาสกุลเงินดิจิทัล อัตราแลกเปลี่ยนเงินตราต่างประเทศ ดัชนีหุ้น ข้อมูลสภาพอากาศ ฯลฯ ข้อมูลเหล่านี้จะถูกส่งผ่าน Distributed Oracle Protocol (DORA) ของ Supra ซึ่งไม่เพียงแต่ให้บริการบล็อกเชน Supra เท่านั้น แต่ยังรองรับเครือข่ายบล็อกเชนอื่นๆ อีกด้วย
รูปที่ 1 การบูรณาการในแนวตั้งเต็มรูปแบบ
พุชและดึงบริการหมายเลขสุ่มแบบออนไลน์ <br/>จัดให้มีฟังก์ชันสุ่มที่ตรวจสอบได้แบบกระจาย (dVRF) ในรูปแบบสตรีมมิ่งและตามความต้องการสำหรับผู้ใช้ Web 2.0 และ Web 3.0 สำหรับการสร้างและกระจายบริการหมายเลขสุ่ม
เครือข่ายอัตโนมัติ <br/>ใช้เพื่อกำหนดเวลาการดำเนินการธุรกรรมตามโหนดเวลาที่ระบุ กิจกรรมออนไลน์ หรือกิจกรรมนอกเครือข่ายที่ให้ไว้ผ่าน DORA ตัวอย่างเช่น ลูกค้าอาจส่งคำขอ: "ในวันที่ 1 มิถุนายน 2025 เวลา 12:00 น. EST ให้ขาย DOGE ของฉันหากราคา ETH สูงกว่า $4,000"
ห่วงโซ่เฉพาะแอปพลิเคชัน (AppChain)
คอนเทนเนอร์บน Supra มอบความยืดหยุ่นและความเป็นอิสระของ AppChain โดยมีต้นทุนการใช้งานที่ลดลงอย่างมาก และได้รับประโยชน์จากประสิทธิภาพสูง การรักษาความปลอดภัยที่ใช้ร่วมกัน และสภาพคล่องที่เป็นหนึ่งเดียวของเครือข่าย Supra
2. IntraLayer: การเชื่อมต่อ Supra และบล็อกเชนอื่น ๆ
แม้ว่า Supra จะให้บริการแบบเนทิฟหลายรายการ แต่เราเข้าใจอย่างลึกซึ้งถึงความเป็นจริงและคุณค่าของระบบนิเวศแบบหลายห่วงโซ่ เพื่อปรับปรุงการทำงานร่วมกัน เราได้ออกแบบโทโพโลยีแบบดาว (ดูรูปที่ 2) ในโครงสร้างนี้ L1 blockchain และบริการบูรณาการทำหน้าที่เป็นแกนหลักของเครือข่าย IntraLayer แก้ปัญหาผ่านโซลูชันการทำงานร่วมกันของเรา HyperLoop และ HyperNova เชื่อมต่อ L1 และ L2 blockchain อื่น ๆ .
ในฐานะแพลตฟอร์มสัญญาอัจฉริยะ MultiVM อิสระ Supra ไม่เพียงแต่ให้บริการของตัวเองเท่านั้น แต่ยังมุ่งมั่นที่จะมีบทบาทสำคัญในระบบนิเวศแบบหลายห่วงโซ่อีกด้วย บทบาทนี้สะท้อนให้เห็นในการแลกเปลี่ยนมูลค่าระหว่างหรือ “ภายในเครือข่าย” ช่วยให้เกิดการสื่อสารที่ปลอดภัยและมีประสิทธิภาพผ่านสัญญาอัจฉริยะแบบดั้งเดิม ฟังก์ชันอัตโนมัติ และบริการของ Oracle
ไฮเปอร์ลูป
HyperLoop เป็นโซลูชันการรักษาความปลอดภัยที่ได้รับการวิเคราะห์และตรวจสอบอย่างเข้มงวดโดยทฤษฎีเกมโดยใช้โปรโตคอลข้ามสายโซ่หลายลายเซ็นแบบดั้งเดิม ถือเป็นนวัตกรรมการออกแบบครั้งแรกในอุตสาหกรรมที่รับประกันความน่าเชื่อถือของธุรกรรมข้ามสายโซ่
ไฮเปอร์โนวา
ในฐานะโซลูชันการทำงานร่วมกันที่ไม่น่าเชื่อถือ HyperNova มอบความปลอดภัยสูงสำหรับการสื่อสารข้ามสายโซ่ โดยวางรากฐานที่มั่นคงสำหรับการแลกเปลี่ยนข้อมูลและมูลค่าในระบบนิเวศแบบหลายสายโซ่
Supra ประสบความสำเร็จในการเชื่อมต่อระหว่างเครือข่ายอย่างกว้างขวางผ่าน HyperLoop และ HyperNova มอบเครื่องมืออันทรงพลังแก่ผู้ใช้และนักพัฒนา และส่งเสริมการบูรณาการเชิงลึกและการพัฒนาระบบนิเวศแบบหลายเครือข่าย
รูปที่ 2 IntraLayer ของ Supra
ความปลอดภัยของเชนที่เชื่อมต่อไม่ได้ขึ้นอยู่กับสมมติฐานด้านความปลอดภัยของ cross-chain หรือโหนดรีเลย์แบบดั้งเดิม ที่นี่เราจะสรุปสถานการณ์เฉพาะที่ HyperLoop และ HyperNova เหมาะสมที่สุด
ไฮเปอร์ลูป
เราพบว่าโซลูชันข้ามสายโซ่ของ HyperLoop เหมาะอย่างยิ่งสำหรับการเชื่อมต่อ Optimistic Rollup กับ Supra เนื่องจากจะขจัดระยะเวลาท้าทายในการพิสูจน์การฉ้อโกงที่จำเป็นเพื่อให้บรรลุผลขั้นสุดท้ายไฮเปอร์โนวา
เหมาะสำหรับการเชื่อมต่อบล็อคเชน Proof-of-Stake (PoS) L1 ใดๆ กับ Supra เนื่องจากจะรักษาความปลอดภัย L1-to-L1 ด้วยการคำนวณฉันทามติของห่วงโซ่การโต้ตอบของ Supra ใหม่ เพื่อรักษาความปลอดภัยของห่วงโซ่ที่เชื่อมต่อ บล็อกเชน L1 ของ Supra ได้รับการออกแบบมาโดยเฉพาะเพื่ออำนวยความสะดวกในการสื่อสารข้ามสายโซ่ที่ปลอดภัยและมีประสิทธิภาพ
แผนของเราประกอบด้วยการใช้ HyperNova เพื่อเชื่อมโยง Bitcoin ไปยัง Supra ในขณะที่เปิดใช้งานการเชื่อมต่อแบบย้อนกลับผ่าน HyperLoop นอกจากนี้ เรากำลังสำรวจวิธีการใช้ Atomic Swap ในสภาพแวดล้อมนี้ เพื่อปรับปรุงการทำงานร่วมกันข้ามสายโซ่ให้ดียิ่งขึ้น
นี่คือคุณสมบัติหลักบางส่วนที่ขับเคลื่อนโดยกลุ่มเทคโนโลยี Supra IntraLayer:
DeFi อินทราเลเยอร์
Supra เป็น "แพลตฟอร์มที่อยู่ด้านบนของแพลตฟอร์ม" โดยสรุปโปรโตคอล DeFi กระแสหลักที่หลากหลาย (เช่น AMM) นักพัฒนา dApp สามารถเข้าถึงสินทรัพย์และข้อมูลจากบล็อคเชนต่างๆ ได้อย่างง่ายดาย ทำให้กระบวนการพัฒนาข้ามเชนง่ายขึ้นบริการระบบอัตโนมัติแบบข้ามสายโซ่
เราอนุญาตให้ผู้ใช้ตั้งค่างานอัตโนมัติตามเหตุการณ์และข้อมูลจากบล็อกเชนหลายแห่ง ซึ่งจะช่วยปรับปรุงประสบการณ์ผู้ใช้และประสิทธิภาพการดำเนินงานได้อย่างมาก
เราเชื่อมั่นว่าการบูรณาการบริการเนทิฟหลายบริการเข้ากับบล็อกเชน L1 ที่มีประสิทธิภาพสูงในแนวตั้งโดยสมบูรณ์นั้นสอดคล้องกับวิสัยทัศน์ของเราในการสร้าง IntraLayer แบบ cross-chain แห่งแรกของโลก เนื่องจากความต้องการบริการของเรายังคงเติบโตบนบล็อกเชนอื่นๆ ยูทิลิตี้ของเครือข่าย Supra รวมถึงโทเค็นและสินทรัพย์ออนไลน์ของเรา จะสร้างความผันผวนในมูลค่าตามธรรมชาติ ซึ่งจะกระตุ้นให้ผู้ใช้และลูกค้าปรับใช้โครงสร้างพื้นฐานของเรามากขึ้น
ในขณะเดียวกัน เนื่องจากสถาปัตยกรรม IntraLayer ถูกนำมาใช้กันอย่างแพร่หลายในระบบนิเวศที่แตกต่างกัน นักพัฒนาจำนวนมากขึ้นเรื่อยๆ จะถูกดึงดูดโดยบริการดั้งเดิมและประสิทธิภาพที่ยอดเยี่ยมของเรา จากนั้นจึงเลือกที่จะพัฒนาและสร้างแอปพลิเคชันโดยตรงบนบล็อกเชน Supra สิ่งนี้จะไม่เพียงแต่ปรับปรุงเลเยอร์ DeFi ของเรา รวมถึงโปรโตคอลที่พัฒนาภายในและโปรโตคอลของบุคคลที่สามเท่านั้น แต่ยังจะผลักดันให้เกิดการยอมรับและการดึงดูดเครือข่ายโดยรวมอีกด้วย
เราเชื่อว่าด้วยประสิทธิภาพที่ยอดเยี่ยมและบริการที่หลากหลายแบบครบวงจร Supra จะนำคลื่นลูกใหม่ของความนิยมของเทคโนโลยี Web 3.0 มาสู่ชุมชนนักพัฒนา และช่วยในการพัฒนาระบบนิเวศทั้งหมดอย่างรวดเร็ว
3. แกนหลักของ Supra - โมเดลโหนด "เผ่าและเผ่า"
ปรัชญาพื้นฐานของ Supra คือการบูรณาการในแนวตั้งโดยสมบูรณ์ โดยให้บริการที่เกี่ยวข้องกับบล็อกเชนเกือบทั้งหมดบนแพลตฟอร์มเดียว โซลูชันนี้ทำให้มั่นใจได้ว่าผู้ใช้และนักพัฒนาจะได้รับประสบการณ์ที่เป็นหนึ่งเดียวและราบรื่น
บูรณาการในแนวตั้งเต็มรูปแบบเทียบกับโมดูลาร์เลเยอร์ 2
Supra ใช้สถาปัตยกรรมบูรณาการในแนวตั้ง ซึ่งแตกต่างจากโซลูชัน L2 แบบโมดูลาร์แบบดั้งเดิม:
ใน L2 ฟังก์ชันหลัก (เช่น ฉันทามติ การดำเนินการ และความพร้อมใช้งานของข้อมูล) จะกระจายอยู่ในเครือข่ายอิสระ แม้ว่าการออกแบบนี้เรียกว่า "ข้อได้เปรียบแบบโมดูลาร์" แต่ก็นำมาซึ่งปัญหามากมาย:
เวลาแฝงที่เพิ่มขึ้น: การสื่อสารข้ามเครือข่ายทำให้เกิดความล่าช้า
ความมั่นคงทางเศรษฐกิจมีการกระจายอำนาจ: เครือข่ายต่างๆ มีโทเค็นของตัวเองและไม่สามารถแบ่งปันความปลอดภัยได้
ความซับซ้อนสูง: สถาปัตยกรรมโดยรวมนั้นยากต่อการบำรุงรักษาและประสานงาน
ในทางตรงกันข้าม การออกแบบที่บูรณาการในแนวตั้งโดยสมบูรณ์ของ Supra ได้รวมส่วนประกอบทั้งหมดไว้ในบล็อกเชนเดียว:
แบ่งปันความมั่นคงทางเศรษฐกิจและเศรษฐกิจโทเค็นแบบครบวงจร
ลดความล่าช้าในการสื่อสารและปรับปรุงประสิทธิภาพของระบบอย่างมาก
กลไกสิ่งจูงใจแบบครบวงจรช่วยเพิ่มความปลอดภัยของเครือข่าย
ลดต้นทุนการดำเนินงานโดยรวม
ความก้าวหน้าด้านความทนทานต่อข้อบกพร่องของไบเซนไทน์
การวิจัยระบบแบบกระจายแสดงให้เห็นว่าในเครือข่ายแบบอะซิงโครนัสหรือแบบซิงโครนัสบางส่วน โปรโตคอล Byzantine Fault Tolerance (BFT) แบบดั้งเดิมสามารถทนต่อโหนดที่เป็นอันตรายได้เพียงหนึ่งในสามเท่านั้น แต่ความก้าวหน้าทางนวัตกรรมของ Supra ช่วยเพิ่มความทนทานดังกล่าวถึงครึ่งหนึ่ง ทำให้เกิดความปลอดภัยและประสิทธิภาพอย่างที่ไม่เคยมีมาก่อน
บริการคัดแยกและห่วงโซ่ความสมบูรณ์
แกนหลักของบล็อกเชน Supra L1 คือบริการสั่งซื้อ โปรโตคอลที่เป็นเอกฉันท์มีหน้าที่รับผิดชอบในการสั่งซื้อธุรกรรม และการเผยแพร่ข้อมูลธุรกรรมจะถูกแยกออกจากบริการสั่งซื้อ ดังนั้น:
บล็อกจะมีเฉพาะข้อมูลเมตาของชุดธุรกรรม (เช่น การสรุปและหลักฐานความพร้อมของข้อมูล) ไม่ใช่ข้อมูลธุรกรรมเฉพาะ
สิ่งนี้ทำให้บล็อคของ Supra blockchain มีขนาดเล็กมาก ซึ่งช่วยปรับปรุงประสิทธิภาพการดำเนินงานได้อย่างมาก
เนื่องจากบริการสั่งซื้อเป็นรากฐานหลักสำหรับบริการอื่นๆ ทั้งหมด เราจึงเรียก Supra Blockchain ว่า "Integrity Chain"
เหตุใดการทนต่อโหนด Byzantine มากขึ้นจึงเป็นเรื่องสำคัญ
ข้อดีโดยตรงของการทนต่อโหนด Byzantine ได้มากขึ้นคือ:
คณะกรรมการขนาดเล็ก: ตัวอย่างเช่น หากต้องการทนต่อโหนดที่เป็นอันตราย 50 โหนด วิธีการแบบดั้งเดิมต้องใช้สมาชิก 151 คน ในขณะที่ Supra ต้องการสมาชิกเพียง 101 คนเท่านั้น
ลดต้นทุน: การลดจำนวนโหนดที่เป็นเอกฉันท์หมายความว่าจำเป็นต้องชดเชยโหนดน้อยลง ส่งผลให้ค่าธรรมเนียมผู้ใช้ลดลง
ความเร็วในการดำเนินการที่ได้รับการปรับปรุง: ด้วยโหนดที่สอดคล้องกันน้อยลง กระบวนการจึงเร็วขึ้นในขณะที่ยังคงรักษาความปลอดภัยที่แข็งแกร่งไว้
รูปที่ 3 ชนเผ่า ตระกูล และครอบครัว
เผ่า ตระกูล และครอบครัว
แกนหลักนี้อำนวยความสะดวกในการบูรณาการแนวตั้งของบริการต่างๆ บนบล็อกเชน Supra อย่างมีประสิทธิภาพและสมบูรณ์ Supra เสนอกรอบการทำงานเครือข่ายใหม่ที่รองรับการดำเนินการของอัลกอริธึมที่แตกต่างกันในระดับชนเผ่า เผ่า หรือครอบครัว
ดังแสดงในรูปที่ 3:
Tribe เป็นคณะกรรมการของโหนดที่ทนต่อหนึ่งในสามของโหนด Byzantine;
Clan เป็นคณะกรรมการโหนดที่ยอมรับได้มากที่สุดครึ่งหนึ่งของโหนด Byzantine;
Family คือคณะกรรมการของโหนดที่ต้องการโหนดที่ถูกต้องอย่างน้อยหนึ่งโหนด
เพื่อให้บรรลุประสิทธิภาพสูงสุดและความปลอดภัยที่แข็งแกร่ง เครือข่ายของเราได้รับการออกแบบโครงสร้างดังนี้: โหนดที่ใช้งานอยู่จะถูกจัดเป็นเผ่าที่รันโปรโตคอลฉันทามติ ขับเคลื่อนบริการสั่งซื้อ และทนทานต่อหนึ่งในสามของโหนด Byzantine
ประเด็นสำคัญในการออกแบบของเราคือชนเผ่า Supra ทั้งหมดไม่จำเป็นต้องมีส่วนร่วมในการทำธุรกรรมหรือรักษาสถานะ Supra ไว้โดยสมบูรณ์ แต่จะมีกลุ่มย่อยเล็กๆ ที่เรียกว่า “กลุ่ม” ทำหน้าที่จัดการสถานะ ดำเนินการธุรกรรม คำนวณสถานะหลังบล็อก และลงนามในข้อผูกพันของรัฐ ดังนั้นการเผยแพร่ข้อมูลธุรกรรมในตอนแรกจะเกิดขึ้นในระดับกองทัพเท่านั้น จากนั้นจึงเผยแพร่ต่อไป
สถาปัตยกรรมนี้เหมาะอย่างยิ่งสำหรับการแยกส่วนสถานะที่มีประสิทธิภาพ โดยที่กลุ่มต่างๆ จัดการส่วนแบ่งสถานะที่แตกต่างกัน ซึ่งอาจใช้เครื่องเสมือนแยกกัน การออกแบบนี้ช่วยเพิ่มความสามารถในการปรับขนาด ทำให้เราสามารถปรับปริมาณงานได้โดยการเพิ่มกลุ่ม (หรือชิ้นส่วน) มากขึ้น ดังนั้น โปรโตคอลทั้งหมดนอกเหนือจากฉันทามติ (เช่น การเผยแพร่ข้อมูล การดำเนินการแบบชาร์ด บริการ Oracle และบริการตัวเลขสุ่มแบบกระจาย) จะรันในคณะกรรมการขนาดเล็ก (กลุ่ม) ที่ต้องใช้โหนดที่ถูกต้องส่วนใหญ่เท่านั้น
เราจัดระเบียบแคลนที่ได้รับคำสั่งและแคลนบริการหลายรายการเข้าด้วยกันโดยการสุ่มเลือกโหนดเป็นแคลน เพื่อให้แคลนเหล่านี้สร้างพาร์ติชันของแคลนอย่างแท้จริง ฉันทามติหรือการสั่งซื้อทั่วโลกดำเนินการกับชนเผ่า ในขณะที่บริการการคำนวณที่ตรวจสอบได้ต่างๆ ดำเนินการบนกลุ่ม การเลือกโหนดแบบสุ่มนี้ช่วยให้เราสามารถดำเนินการในระดับกองทัพและแนะนำองค์ประกอบความน่าจะเป็นเข้าสู่ระบบ ตัวอย่างเช่น สมมติว่าเผ่าประกอบด้วยโหนด 625 โหนด โดยมีโหนด Byzantine สูงสุด 208 โหนด หากชนเผ่าถูกแบ่งออกเป็น 5 เผ่า โดยแต่ละเผ่าจะมี 125 โหนด ความน่าจะเป็นที่มากกว่าครึ่งหนึ่ง (เช่น 62 โหนด) ในกลุ่มใดเผ่าหนึ่งจะเป็นโหนดไบแซนไทน์จะอยู่ที่ประมาณ 35 × 10 ⁻⁶ กล่าวอีกนัยหนึ่ง เมื่อชนเผ่ามีโหนดไบแซนไทน์ 33% ความน่าจะเป็นที่ "เผ่าที่ไม่ดี" จะอยู่เพียง 35 ในล้านเท่านั้น ในทางปฏิบัติ ความน่าจะเป็นเหล่านี้ต่ำมาก เราจะวิเคราะห์ความน่าจะเป็นเหล่านี้เพิ่มเติมเมื่อพูดถึงช่วงเวลาและช่วงเวลา และแสดงให้เห็นว่าในทางปฏิบัติแทบไม่มีนัยสำคัญเลย
4. ขั้นตอนการทำธุรกรรม
ขั้นตอนการทำธุรกรรมบนห่วงโซ่ Supra มีดังต่อไปนี้ และขั้นตอนเฉพาะจะอธิบายโดยละเอียดในบทต่อๆ ไป:
รูปที่ 4 แสดงกระบวนการทำธุรกรรมตั้งแต่ต้นทางถึงปลายทางใน Supra blockchain
ผู้ใช้ส่งธุรกรรมผ่านกระเป๋าเงิน Starkey ของ Supra [3] หรือ dApp กระเป๋าเงินเชื่อมต่อกับโหนด RPC ของเกตเวย์ซึ่งมีการส่งธุรกรรม ttt ไป
โหนด RPC ของเกตเวย์จะส่งธุรกรรม ttt ไปยังบัคเก็ตหลักของผู้เสนอแบทช์เฉพาะตามการตรวจสอบพื้นฐานและการจัดหมวดหมู่ และส่งธุรกรรมไปยังบัคเก็ตรองของผู้เสนอแบทช์อื่น ๆ
ผู้เสนอชุดงานจะแพ็คธุรกรรมจากที่เก็บข้อมูลหลัก และเพิ่มธุรกรรมที่หมดเวลาจากที่เก็บข้อมูลรองไปยังชุดงาน ดูส่วนที่ 5 สำหรับรายละเอียด
แบทช์ถูกเผยแพร่ไปยังโหนดกลุ่มการดำเนินการที่เกี่ยวข้องผ่านโปรโตคอล xRBC และต้องสร้าง Data Availability Quorum Certificate (DAQC) ก่อนจึงจะสามารถรวมแบทช์ไว้ในบล็อกได้ ใบรับรองเหล่านี้ได้รับการเผยแพร่ทั่วทั้งเผ่า และแบทช์จะเผยแพร่ไปยังโหนด RPC ของเกตเวย์
โหนด Tribe รันโปรโตคอลฉันทามติ Moonshot ของ Supra ผู้เสนอบล็อกสร้างบล็อกโดยการรวม DAQC เหล่านี้และข้อมูลเมตาของแบทช์ที่เกี่ยวข้อง
โปรโตคอลฉันทามติจะสั่งบล็อกและสั่งธุรกรรมทางอ้อมระหว่างแบตช์ เมื่อบล็อกได้รับการสรุป โหนดเหล่านั้นจะปรากฏแก่โหนดเผ่าทั้งหมดที่ใช้โปรโตคอลฉันทามติ เช่นเดียวกับโหนดแคลนทั้งหมด บล็อกที่สรุปผลแล้วยังถูกเผยแพร่ไปยังโหนด RPC ของเกตเวย์อีกด้วย
โหนดกลุ่มดำเนินการชุดธุรกรรมที่เกี่ยวข้องจากบล็อกสุดท้ายและอัปเดตสถานะบล็อกเชนที่ส่วนท้ายของบล็อกเชนปัจจุบัน ต่อจากนั้น พวกเขาคำนวณ poststate ดำเนินการ Merkleization และคำนวณราก Merkle ใหม่ โปรดทราบว่าแคลนที่แตกต่างกันจะดำเนินการแบตช์ที่แตกต่างกันไปพร้อมๆ กัน โหนดกลุ่มลงนามราก Merkle นี้และเผยแพร่ไปยังกลุ่มทั้งหมดรวมถึงโหนด RPC ของเกตเวย์
โหนด RPC ของเกตเวย์ดำเนินการบล็อก คำนวณ post-state และรูท Merkle ตรวจสอบว่าสอดคล้องกับรูท Merkle ที่ลงนามแล้วที่ได้รับ และแจ้งเตือนกระเป๋าเงินเมื่อธุรกรรมเสร็จสมบูรณ์
ขั้นตอนการยืนยันขั้นสุดท้าย
ในขั้นตอนการทำงานของเรา ธุรกรรมจะต้องผ่านขั้นตอนสุดท้ายที่แตกต่างกันสามขั้นตอนต่อไปนี้ โดยแต่ละขั้นตอนให้การรับประกันที่แข็งแกร่งยิ่งขึ้นเกี่ยวกับสถานะของธุรกรรมบนบล็อกเชน:
ขั้นตอนการยืนยันล่วงหน้า
เมื่อแบตช์ bbb ที่มีธุรกรรม ttt ได้รับใบรับรอง Data Availability Quorum Certificate (DAQC) มีการรับประกันว่าธุรกรรม ttt จะถูกรวมไว้ในบล็อกเชน ในขั้นตอนนี้ แม้ว่าจะมีการรับประกันการรวมธุรกรรมแล้ว แต่สถานที่ตั้งเฉพาะและผลการดำเนินการยังไม่ได้รับการพิจารณาเรียงลำดับขั้นสุดท้าย
เมื่อโปรโตคอลฉันทามติเสร็จสิ้นการยืนยันขั้นสุดท้ายของบล็อกที่มีแบตช์ bbb ตำแหน่งของธุรกรรม ttt ในบล็อกเชนจะคงที่และไม่เปลี่ยนแปลง ดังนั้น จึงกำหนดลำดับการดำเนินการที่สัมพันธ์กับธุรกรรมอื่น ๆการดำเนินการขั้นสุดท้าย
นี่คือจุดสิ้นสุดของขั้นตอนสุดท้าย โหนดกลุ่มดำเนินการแบทช์ bbb อัปเดตสถานะบล็อกเชนด้วยผลการดำเนินการของธุรกรรม ttt สร้างเวอร์ชัน Merkleized ของสถานะใหม่ ลงนามรูท Merkle ที่สร้างขึ้น และออกอากาศเพื่อสร้างข้อผูกพันของรัฐ เมื่อขั้นตอนนี้เสร็จสิ้น ผลการดำเนินการของธุรกรรมถือเป็นที่สิ้นสุดและไม่สามารถย้อนกลับได้
Supra L1 รองรับเวลาขั้นสุดท้ายที่รวดเร็ว เวลาในการสังเกตสำหรับขั้นตอนสุดท้ายที่แตกต่างกันเหล่านี้ในการทดลองของเรามีการรายงานไว้ในส่วนที่ 7
บทต่อไปนี้จะกล่าวถึงรายละเอียดขั้นตอนสำคัญในกระบวนการทำธุรกรรมข้างต้น
รูปที่ 5 รูปแบบ Bucketing ที่ไม่มีพูลหน่วยความจำ
5. โซลูชันการเก็บข้อมูลโดยไม่มีพูลหน่วยความจำ
ก่อนอื่นเราจะหารือเกี่ยวกับโปรโตคอล mempool ที่มีอยู่ของ Ethereum และ Solana จากนั้นแสดงให้เห็นว่า Supra ปรับปรุงได้อย่างไร
โซลูชันพูลหน่วยความจำ Ethereum
กระบวนการโปรโตคอลพูลหน่วยความจำ Ethereum แบบดั้งเดิมมีดังนี้:
ลูกค้า (กระเป๋าเงิน) ส่งธุรกรรมไปยังโหนด RPC ซึ่งออกอากาศธุรกรรมผ่านโปรโตคอล Gossip เพื่อให้เข้าถึงผู้ตรวจสอบฉันทามติทั้งหมด
เมื่อผู้ตรวจสอบกลายเป็นผู้เสนอบล็อก ก็จะพยายามจัดแพคเกจธุรกรรมที่ได้รับ
ผู้เสนอบล็อกอาจพยายามตรวจสอบธุรกรรมโดยไม่รวมธุรกรรมเหล่านั้นไว้ในบล็อก แต่เนื่องจากผู้ตรวจสอบฉันทามติทั้งหมดถือธุรกรรมเหล่านี้ ผู้ตรวจสอบรอบถัดไปที่กลายเป็นผู้เสนอบล็อกจะรวมธุรกรรมที่พลาดหรือถูกเซ็นเซอร์ด้วย ดังนั้นโปรโตคอลนี้จึงทนทานต่อการเซ็นเซอร์
ในสถาปัตยกรรมบล็อกเชนทั่วไป ไคลเอนต์ (กระเป๋าเงิน Web3) จะส่งธุรกรรมไปยังโหนด RPC สาธารณะ จากนั้นโหนด RPC จะเผยแพร่ธุรกรรมไปยังเครือข่ายโหนด RPC ทั้งหมดและเครือข่ายตัวตรวจสอบฉันทามติผ่านโปรโตคอลการนินทาแบบจุดต่อจุด โหนดเหล่านี้รักษาโครงสร้างข้อมูลที่เรียกว่า "mempool" เพื่อจัดเก็บธุรกรรมที่ส่งโดยไคลเอนต์ชั่วคราว
จากนั้น ตัวสร้างบล็อกจะดึงธุรกรรมจาก mempool บรรจุลงในบล็อก และประมวลผลผ่านโปรโตคอลที่เป็นเอกฉันท์ เมื่อบล็อกถึงขั้นสุดท้าย ธุรกรรมที่รวมไว้ทั้งหมดจะถือเป็นที่สิ้นสุดเช่นกัน
เนื่องจากธุรกรรมที่ยังไม่ได้ดำเนินการที่ค้างอยู่ใน Bitcoin และเมมพูลของ Ethereum มีรายการค้างอยู่จำนวนมาก โดยเฉลี่ยแล้ว ธุรกรรมจะอยู่ในเมมพูลเป็นระยะเวลานานขึ้นก่อนที่จะถูกเลือกโดยผู้สร้างบล็อก นอกจากนี้ โปรโตคอลการนินทาแบบจุดต่อจุดจะเพิ่มความล่าช้าในการเผยแพร่ธุรกรรมอีกด้วย
Solana ไม่มีโซลูชันพูลหน่วยความจำ
เพื่อลดเวลาแฝงของพูลหน่วยความจำ Solana จะใช้โปรโตคอลที่ไม่มีพูลหน่วยความจำ โดยมีกระบวนการต่อไปนี้:
บล็อกจะถูกสร้างขึ้นตามกำหนดเวลาที่กำหนดล่วงหน้าโดยผู้เสนอบล็อก
ไคลเอนต์ (เช่น กระเป๋าเงิน) ส่งธุรกรรมไปยังโหนด RPC โหนด RPC จะแนบข้อมูลเสริม เช่น ข้อมูลการเข้าถึงแบบอ่านและเขียนไปยังธุรกรรม และส่งไปยังผู้เสนอบางรายที่กำลังจะเสนอบล็อก หากผู้เสนอพลาดธุรกรรม ผู้เสนอรายอื่นจะรวมธุรกรรมนั้นไว้ในบล็อกถัดไป
สิ่งสำคัญคือต้องทราบว่าเครือข่าย Solana ต้องการการยืนยันบล็อก 32 บล็อกเพื่อให้บรรลุผลขั้นสุดท้ายโดยสมบูรณ์ แม้ว่า Solana ได้รับการออกแบบมาเพื่อเพิ่มประสิทธิภาพเวลาแฝงตั้งแต่ต้นทางถึงปลายทาง แต่การทำธุรกรรมซ้ำซ้อนยังคงเกิดขึ้นเป็นครั้งคราวและอาจทำให้เครือข่ายขัดข้อง เมื่อเปรียบเทียบกับโปรโตคอล mempool ของ Ethereum แล้ว Solana ใช้การสื่อสารโดยตรงไปยังผู้เสนอบล็อกที่ต้องการ ซึ่งเป็นแนวทางที่ช่วยลดความล่าช้าในการเผยแพร่ธุรกรรมได้อย่างมีประสิทธิภาพ
โซลูชันโปรโตคอลแบบไร้พูลหน่วยความจำ Supra
เช่นเดียวกับ Solana Supra ใช้โปรโตคอล mempoolless แต่เราแทนที่โปรโตคอลการนินทาทั่วทั้งเครือข่ายแบบเดิมด้วยการสื่อสารแบบกำหนดเป้าหมาย อย่างไรก็ตาม แนวทางของ Supra แตกต่างกันในสองวิธีหลัก:
1. สิ้นสุดทันที
ซึ่งแตกต่างจากระบบตามช่วงเวลาของ Solana Supra ใช้โปรโตคอลฉันทามติสไตล์ Byzantine Fault Tolerance (BFT) PBFT แบบคลาสสิกที่เรียกว่า Moonshot (ดูรายละเอียดด้านล่าง) ในโปรโตคอล Moonshot การสิ้นสุดทันทีสามารถทำได้เมื่อบล็อกได้รับใบรับรองการส่ง (QC) โดยไม่ต้องรอการยืนยันบล็อก 32 รายการเช่น Solana ซึ่งจะช่วยลดระยะเวลาการยืนยันธุรกรรมครั้งสุดท้ายได้อย่างมาก และปรับปรุงประสิทธิภาพของระบบ
2. การจัดเก็บข้อมูลเมตาแบบแบตช์
ในการออกแบบฉันทามติของ Supra บล็อกนี้ไม่มีข้อมูลธุรกรรมโดยตรง แต่จะจัดเก็บ DAQC และข้อมูลเมตาของชุดธุรกรรม (ดูรายละเอียดในส่วนที่ 6) ในโปรโตคอล mempoolless ของเรา ธุรกรรมจากกระเป๋าสตางค์ของลูกค้าจะถูกใส่ลงในบัคเก็ตที่จัดการโดยผู้เสนอแบทช์ที่กำหนด ดังแสดงในรูปที่ 5
คุณสมบัติของโซลูชันการฝากข้อมูลของเรามีดังนี้:
1) กลไกการขจัดข้อมูลซ้ำซ้อน
ธุรกรรมแต่ละรายการจะได้รับการมอบหมายให้ผู้เสนอแบทช์หลักที่ไม่ซ้ำกัน ซึ่งมีหน้าที่รับผิดชอบในการรวมธุรกรรมลงในแบทช์ โมเดลความรับผิดชอบเดียวนี้จะป้องกันไม่ให้ธุรกรรมที่ซ้ำกันถูกบรรจุลงในบล็อกเชนโดยธรรมชาติ
2) การต่อต้านความซ้ำซ้อนและการเซ็นเซอร์
เพื่อให้แน่ใจว่าจะไม่พลาดธุรกรรม เราได้แนะนำผู้เสนอย่อยเป็นกลุ่มสำรอง หากผู้เสนอชุดงานหลักไม่สามารถรวมธุรกรรมได้ทันเวลา ผู้เสนอชุดงานรองจะรวมธุรกรรมในชุดงานหลังจากการหมดเวลา
แม้ว่าผู้เสนอรองหลายรายที่ประมวลผลธุรกรรมพร้อมกันอาจส่งผลให้เกิดบรรจุภัณฑ์ที่ซ้ำกัน แต่ระบบ Supra จะรักษาความสม่ำเสมอตลอดการทำธุรกรรมครั้งแรก
ธุรกรรมที่ทำซ้ำจะถูกยกเลิกโดยอัตโนมัติในระหว่างขั้นตอนการดำเนินการ เนื่องจากหมายเลขลำดับธุรกรรมไม่ถูกต้อง โดยไม่ส่งผลกระทบต่อสถานะออนไลน์
3) บันทึกความรับผิดชอบที่ไม่สามารถเปลี่ยนแปลงได้
หากผู้เสนอรองรวมธุรกรรมไว้ในบล็อกได้สำเร็จ ก็จะสร้างบันทึกที่ไม่เปลี่ยนรูปเพื่อพิสูจน์ว่าผู้เสนอหลักล้มเหลวในการปฏิบัติหน้าที่ บันทึกนี้สามารถใช้สำหรับการวิเคราะห์เครือข่ายในภายหลังเพื่อลงโทษผู้เสนอแบบกลุ่มที่เซ็นเซอร์ธุรกรรมหรือทำให้เกิดความล่าช้าโดยไม่จำเป็น เพื่อให้มั่นใจในความเป็นธรรมและความน่าเชื่อถือของระบบ
กระบวนการเฉพาะของโซลูชันการบัคเก็ตที่ไม่มีพูลหน่วยความจำมีดังนี้:
ผู้เสนอชุดงานแต่ละรายจะรักษาที่เก็บข้อมูลไว้ 2 ชุด ได้แก่ ที่เก็บข้อมูลหลักและที่เก็บข้อมูลรอง
สำหรับแต่ละธุรกรรม ttt ระบบจะกำหนดให้กับตระกูลผู้เสนอแบบแบตช์เฉพาะตามตัวระบุ (แฮช) ที่ไม่ซ้ำใครและคาดเดาไม่ได้ ในตระกูลนี้ โหนดหนึ่งถูกกำหนดให้เป็นผู้เสนอแบทช์หลักสำหรับธุรกรรม ttt และโหนดที่เหลือคือผู้เสนอแบทช์รอง
เมื่อโหนด RPC ได้รับธุรกรรม ttt จากกระเป๋าสตางค์หรือส่วนหน้า dApp โหนดจะส่งต่อไปยังกลุ่มผู้เสนอแบบแบตช์ที่เกี่ยวข้องตามตัวระบุของธุรกรรม ผู้เสนอแบทช์หลักจะจัดเก็บธุรกรรม ttt ไว้ในบัคเก็ตหลัก ในขณะที่ผู้เสนอแบทช์รองจะจัดเก็บธุรกรรม ttt ไว้ในบัคเก็ตรองตามลำดับ
เมื่อสร้างชุดงานใหม่ ผู้เสนอชุดงานจะต้องรวมธุรกรรมทั้งหมดไว้ในที่เก็บข้อมูลหลัก เพื่อป้องกันพฤติกรรม Byzantine (เช่น การเซ็นเซอร์ธุรกรรมเฉพาะโดยการแยกธุรกรรมเหล่านั้นออกจากบัคเก็ตหลัก) ผู้เสนอชุดรองจะทำหน้าที่เป็นกลไกการสำรองข้อมูล
เมื่อชุดงานได้รับการสรุปและตรวจสอบโดยผู้เสนอชุดงาน ผู้เสนอจะลบธุรกรรมที่รวมอยู่ในชุดงานออกจากที่เก็บข้อมูลหลักและรอง
นอกจากนี้ แต่ละธุรกรรม ttt มีการหมดเวลาที่กำหนดได้ หากไม่ได้รวม ttt ไว้ในแบตช์ที่สรุปผลก่อนหมดเวลา ผู้เสนอแบตช์ย่อยในตระกูลจะต้องรวม ttt จากบัคเก็ตย่อยเมื่อสร้างแบตช์ถัดไป กลไกนี้ทำให้แน่ใจได้ว่าธุรกรรมจะไม่พลาดและเพิ่มความต้านทานการเซ็นเซอร์ของระบบ
รูปที่ 6 การเปรียบเทียบแนวคิดกับโซลูชันที่มีอยู่
การออกแบบสองชั้นนี้สร้างความสมดุลที่ชาญฉลาดระหว่างการขจัดข้อมูลซ้ำซ้อนที่มีประสิทธิภาพและการต้านทานการเซ็นเซอร์ที่แข็งแกร่ง นอกจากนี้ เมื่อผู้เสนอชุดรองรวมธุรกรรมไว้ในชุดงานได้สำเร็จ บันทึกที่ไม่เปลี่ยนรูปจะถูกสร้างขึ้นเพื่อพิสูจน์ว่าผู้เสนอหลักล้มเหลวในการปฏิบัติหน้าที่ บันทึกนี้สามารถใช้สำหรับการวิเคราะห์ในภายหลัง และเพื่อกำหนดบทลงโทษสำหรับผู้เสนอแบบกลุ่มที่เซ็นเซอร์ธุรกรรมหรือทำให้เกิดความล่าช้าโดยไม่จำเป็น
6. สถาปัตยกรรมที่ไม่มีพูลหน่วยความจำ: บรรลุการแยกส่วนการเผยแพร่ข้อมูลธุรกรรมและการเรียงลำดับธุรกรรมอย่างมีประสิทธิภาพ
ต่อไปเราจะแนะนำวิธีที่ Supra บรรลุการแยกส่วนการเผยแพร่ข้อมูลธุรกรรมและการสั่งซื้อธุรกรรมผ่านสถาปัตยกรรมชนเผ่าอย่างมีประสิทธิภาพได้อย่างไร
ในช่วงไม่กี่ปีที่ผ่านมา โปรโตคอลบางอย่าง (เช่น Narwhal/Tusk [11] และ Bullshark [20]) ได้ตระหนักถึงความสำคัญของการส่งข้อมูลธุรกรรม และนำกระบวนทัศน์การออกแบบใหม่มาใช้เพื่อแยกการส่งข้อมูลจากการเรียงลำดับธุรกรรม การออกแบบนี้ใช้การส่งและการเรียงลำดับข้อมูลตามลำดับผ่านโปรโตคอลย่อยสองตัวที่ทำงานแบบขนาน:
ในกรณีที่ไม่มีข้อกำหนดในการสั่งซื้อ การส่งข้อมูลจะลดลงเป็นการออกอากาศที่เชื่อถือได้ (RBC) ซึ่งเป็นการดำเนินการพื้นฐานที่ได้รับการศึกษาอย่างกว้างขวางในระบบแบบกระจาย
โดยเฉพาะอย่างยิ่ง โหนดจะเสนอและเผยแพร่บล็อกข้อมูลใหม่อย่างต่อเนื่องผ่านโปรโตคอลย่อย RBC จากนั้น บล็อกข้อมูลเหล่านี้จะถูกกำหนดและส่งออกผ่านโปรโตคอลย่อยการเรียงลำดับ
การออกแบบนี้เพิ่มประสิทธิภาพการใช้ทรัพยากรแบนด์วิธได้อย่างมีประสิทธิภาพ และปรับปรุงปริมาณงานของระบบอย่างมีนัยสำคัญเมื่อเทียบกับวิธีการแบบเดิม Supra ยังปฏิบัติตามหลักการนี้และแยกการส่งข้อมูลและการสั่งซื้อธุรกรรม อย่างไรก็ตาม เราได้สังเกตเห็นว่าแม้ในโปรโตคอลฉันทามติที่ล้ำสมัยในปัจจุบัน จุดเน้นของการเพิ่มประสิทธิภาพยังคงอยู่ที่โปรโตคอลย่อยการสั่งซื้อ ซึ่งจริงๆ แล้วตรงกันข้ามกับคอขวดที่แท้จริงของระบบ
ตัวอย่างเช่น ข้อได้เปรียบหลักของ Tusk [11] และ Bullshark [20] คือสิ่งที่เรียกว่าการเรียงลำดับข้อความเป็นศูนย์ ซึ่งช่วยลดค่าใช้จ่ายในการสื่อสารในขั้นตอนการเรียงลำดับโดยสิ้นเชิง แต่ดังที่เราได้ชี้ให้เห็นก่อนหน้านี้ แหล่งที่มาหลักของต้นทุนการสื่อสารไม่ใช่การเรียงลำดับ แต่เป็นการส่งข้อมูล
รูปที่ 6 เปรียบเทียบแนวทางของเรากับโซลูชันที่มีอยู่ เป้าหมายของเราคือการลดปริมาณการส่งข้อมูลของแต่ละโหนดในระหว่างขั้นตอนการส่งข้อมูล โดยเฉพาะอย่างยิ่งเพื่อลดภาระการส่งข้อมูลสูงสุดของโหนดเดียวใดๆ ในการใช้งานจริง แบนด์วิธของเครือข่ายมักเป็นปัจจัยหลักในการจำกัดปริมาณงานของระบบ ดังนั้น ด้วยการปรับกระบวนการส่งข้อมูลให้เหมาะสม เราจึงสามารถปรับปรุงประสิทธิภาพโดยรวมและประสิทธิภาพของระบบต่อไปได้
โปรโตคอล xRBC ของ Supra
เราลดต้นทุนการสื่อสารในการถ่ายโอนข้อมูลได้อย่างมากด้วยนวัตกรรมการใช้บริการสั่งซื้ออิสระที่ดำเนินการโดยโหนดชุดเดียวกัน
ในแนวทางดั้งเดิม การส่งข้อมูลมักจะดำเนินการผ่านโปรโตคอลที่เชื่อถือได้ออกอากาศ (RBC) RBC ต้องการมากกว่า 2/3 ของโหนดที่แท้จริงในระบบเพื่อป้องกันไม่ให้ผู้ออกอากาศส่งชุดข้อมูลที่แตกต่างกันไปยังโหนดที่แตกต่างกัน (นั่นคือ ปัญหาความคลุมเครือของผู้ส่ง)
อย่างไรก็ตาม เราพบว่าการถ่ายโอนข้อมูลสามารถปรับปรุงให้เป็นการดำเนินการ RBC แบบผ่อนคลายที่เรียกว่า xRBC ได้ โดยใช้ประโยชน์จากบริการสั่งซื้ออิสระ ใน xRBC ต้องใช้โหนดจริงมากกว่า 1/2 เท่านั้นในการส่งข้อมูลให้เสร็จสมบูรณ์ ซึ่งช่วยลดต้นทุนการสื่อสารได้อย่างมาก
ข้อดีของการออกแบบ xRBC
ใน xRBC โหนดที่เข้าร่วมเพียงอย่างเดียวไม่เพียงพอที่จะป้องกันความคลุมเครือของผู้ส่งได้อย่างสมบูรณ์ เพื่อแก้ไขปัญหานี้ บริการสั่งซื้อจะรับรองชุดของผู้ออกอากาศ ทำให้เกิดความเห็นพ้องต้องกันระหว่างโหนดที่ซื่อสัตย์ ดังนั้นจึงขจัดความขัดแย้ง แม้ว่าบริการสั่งซื้อยังคงต้องการการรับประกันส่วนใหญ่ (มากกว่า 2/3 ของโหนดที่ซื่อสัตย์) แต่ xRBC ก็มีข้อได้เปรียบที่เหนือกว่า RBC แบบดั้งเดิมในด้านต่อไปนี้:
ค่าใช้จ่ายในการสื่อสารที่ลดลง: ด้วยการลดการพึ่งพาโหนดที่เที่ยงตรงส่วนใหญ่ ความซับซ้อนในการสื่อสารในการทำงานของโปรโตคอลจึงลดลง
ประสิทธิภาพที่ได้รับการปรับปรุง: xRBC ได้รับการออกแบบมาเพื่อจัดการการถ่ายโอนข้อมูลได้อย่างมีประสิทธิภาพมากขึ้น ขณะเดียวกันก็รักษาความปลอดภัยไว้เทียบเท่ากับ RBC แบบดั้งเดิม
การใช้การเผยแพร่ข้อมูลแบบกระจายของกลุ่ม
เนื่องจากธุรกรรมจะดำเนินการภายในกลุ่มเท่านั้น (สภาย่อยแบบสุ่มของชนเผ่า) ข้อมูลธุรกรรมจึงถูกถ่ายโอนไปยังโหนดที่ดำเนินการกลุ่มนั้นในขั้นต้นเท่านั้น สิ่งนี้จะช่วยลดภาระบนแบนด์วิธเครือข่ายได้อย่างมาก และมีประสิทธิภาพมากกว่าการกระจายข้อมูลทั่วทั้งเผ่า ภายในกลุ่มที่ดำเนินการแต่ละกลุ่ม เราจะกำหนดชุดย่อยของโหนดให้เป็นผู้เสนอแบบกลุ่ม ซึ่งรับผิดชอบในการสร้างชุดธุรกรรมจากที่เก็บข้อมูลที่เกี่ยวข้อง และส่งไปยังโหนดทั้งหมดภายในกลุ่ม
เป็นที่น่าสังเกตว่าผู้เสนอแบทช์จากกลุ่มที่แตกต่างกันสามารถเผยแพร่แบทช์ธุรกรรมได้อย่างอิสระและขนานกัน โดยไม่ต้องซิงโครไนซ์หรือรอขั้นตอนโปรโตคอล กลไกการแพร่กระจายแบบอะซิงโครนัสแบบขนานนี้ช่วยเพิ่มประสิทธิภาพการใช้แบนด์วิธเครือข่ายให้สูงสุดเมื่อส่งข้อมูล
นอกจากนี้ ข้อมูลธุรกรรมอาจถูกเผยแพร่ต่อไปทั่วทั้งเผ่าในขั้นตอนต่อๆ ไป เพื่อให้บรรลุการซิงโครไนซ์สถานะ (เพื่ออำนวยความสะดวกในการกระจายโหนดข้ามยุคต่างๆ ดูส่วนที่ 9 สำหรับรายละเอียด) การออกแบบการเผยแพร่ข้อมูลเป็นระยะนี้ช่วยให้มั่นใจถึงความสอดคล้องและความยืดหยุ่นของระบบในขณะเดียวกันก็รับประกันประสิทธิภาพของเครือข่าย
รูปที่ 7 โปรโตคอล xRBC
กระบวนการเฉพาะ (ดังแสดงในรูปที่ 7)
ผู้เสนอแบทช์มีหน้าที่รับผิดชอบในการสร้างแบทช์ธุรกรรมและส่งไปยังโหนดทั้งหมดภายในกลุ่ม
เมื่อโหนดแคลนได้รับแบทช์ที่ถูกต้อง โหนดจะโหวตเกี่ยวกับความพร้อมของข้อมูลของแบทช์และเผยแพร่ผลการโหวตไปยังโหนดทั้งหมดในแคลน โหนดอื่น ๆ ในแคลน และโหนด RPC เกตเวย์ที่กำหนด
เมื่อผ่านการลงคะแนนเสียงข้างมาก ระบบจะสร้าง Data Availability Certificate (DAQC) เพื่อให้แน่ใจว่าโหนดจริงอย่างน้อยหนึ่งโหนดมีข้อมูลธุรกรรมที่สมบูรณ์
หากโหนดขาดส่วนหนึ่งของข้อมูลแบตช์ ก็สามารถขอข้อมูลจากโหนดกลุ่มส่วนใหญ่แบบธรรมดาได้ และ DAQC รับประกันว่าคำขอนี้จะได้รับการตอบสนอง
สำหรับแบตช์ที่เกินเกณฑ์ขนาด หรือเมื่อโหนดแคลนบางตัวไม่ได้ทำหน้าที่เป็นผู้เสนอแบตช์ เราจะแนะนำการเข้ารหัสการลบเพื่อให้แน่ใจว่ามีการกระจายข้อมูลภายในแคลนอย่างเท่าเทียมกันและเพิ่มประสิทธิภาพการใช้แบนด์วิดท์ให้เหมาะสม
บล็อกเนื้อหาและจุดสิ้นสุด
เฉพาะใบรับรองชุดเท่านั้นที่จะรวมอยู่ในบล็อก เมื่อผู้ตรวจสอบความถูกต้อง (โหนดไทรบ์) ของโปรโตคอลฉันทามติทำหน้าที่เป็นผู้เสนอบล็อก ระบบจะจัดแพคเกจ DAQC ทั้งหมดที่ได้รับลงในบล็อก เมื่อบล็อกถึงขั้นสุดท้ายและได้รับการยืนยันโดยเครื่องมือตรวจสอบความถูกต้อง เครื่องมือตรวจสอบจะลบ DAQC ที่รวมอยู่เหล่านี้ออกจากแคช เนื่องจากได้รับการบันทึกไว้ในบล็อกที่สรุปผลแล้ว และไม่จำเป็นต้องเก็บรักษาไว้อีกต่อไป
เนื่องจากบล็อกประกอบด้วยใบรับรองแบทช์เท่านั้น และไม่ได้จัดเก็บข้อมูลธุรกรรมโดยตรง ดังนั้น Supra blockchain จึงเป็นบล็อกเชนที่มีน้ำหนักเบามาก การออกแบบนี้ช่วยลดขนาดบล็อกได้อย่างมากและปรับปรุงประสิทธิภาพการรับส่งข้อมูล
7. พิธีสารฉันทามติ
โปรโตคอลฉันทามติ Byzantine Fault Tolerance (BFT): แกนหลักของ Blockchain
โปรโตคอลฉันทามติ BFT เป็นองค์ประกอบหลักของบล็อคเชน และมีหน้าที่รับผิดชอบในการจัดเตรียมลำดับมาตรฐานสำหรับบล็อค ดังนั้นจึงมั่นใจได้ว่าธุรกรรมภายในบล็อคนั้นมีคำสั่งมาตรฐานเช่นกัน เราได้ออกแบบโปรโตคอลฉันทามติ BFT ใหม่ที่เรียกว่า Moonshot SMR ซึ่งได้รับการแรงบันดาลใจจากโปรโตคอล Practical Byzantine Fault Tolerance (PBFT) แบบคลาสสิก และได้ดำเนินการปรับประสิทธิภาพให้เหมาะสมบนพื้นฐานนี้
ดังที่ได้กล่าวไว้ก่อนหน้านี้ โปรโตคอลฉันทามติจะถูกดำเนินการภายในเผ่า ในขณะที่การดำเนินการธุรกรรมจะจำกัดเฉพาะกลุ่มเท่านั้น ดังนั้น Moonshot จึงใช้การออกแบบที่ยืดหยุ่นและสามารถปรับได้อย่างยืดหยุ่นตามความต้องการปริมาณธุรกรรมจริง เป็นที่น่าสังเกตว่าบล็อกนี้ไม่มีข้อมูลธุรกรรมโดยตรง มีเพียงใบรับรองแบทช์เท่านั้น ซึ่งทำให้ระบบมีประสิทธิภาพและมีน้ำหนักเบามากขึ้น
ประสิทธิภาพของมูนช็อต
Moonshot บรรลุตัวชี้วัดประสิทธิภาพที่สำคัญดังต่อไปนี้:
ความล่าช้าของข้อเสนอติดต่อกัน (ความล่าช้าขั้นต่ำระหว่างข้อเสนอบล็อกสองรายการ): ความล่าช้าของข้อความ 1 ข้อความ (md)
ความล่าช้าในการส่ง: 3 md.
ความล่าช้าสะสมสำหรับการแพร่กระจายแบบแบตช์และการสร้างใบรับรองความพร้อมใช้งานของข้อมูล: 2 md
เนื่องจากมีการนำเสนอบล็อกในทุก ๆ การกระโดดของเครือข่าย ใบรับรองความพร้อมใช้งานของข้อมูลจึงต้องเข้าคิวเพื่อรอข้อเสนอบล็อกถัดไป โดยมีความล่าช้าในการเข้าคิวโดยเฉลี่ย 0.5 md
ดังนั้น เวลาแฝงตั้งแต่ต้นทางถึงปลายทางโดยรวมของระบบคือ 5.5 md
การตรวจสอบอย่างเป็นทางการ: รับประกันความปลอดภัยของโปรโตคอล
โปรโตคอลแบบกระจายมักจะมีพฤติกรรมที่ซับซ้อนและมีพื้นที่สถานะไม่สิ้นสุด ซึ่งทำให้การพิสูจน์ความถูกต้องเป็นสิ่งที่ท้าทายอย่างยิ่ง การตรวจสอบอย่างเป็นทางการถือเป็นมาตรฐานทองคำในการรับรองความปลอดภัยของโปรโตคอล เนื่องจากสามารถพิสูจน์ทางคณิตศาสตร์ได้ว่าไม่มีข้อผิดพลาดในโปรโตคอล
ด้วยเหตุนี้ เราจึงใช้ตัวตรวจสอบ IvY ของ Microsoft เพื่อตรวจสอบคุณสมบัติความปลอดภัยของโปรโตคอลฉันทามติ Moonshot อย่างเป็นทางการ โดยพิสูจน์ให้เห็นถึงคุณสมบัติที่ไม่มีวันแยกออกอย่างเคร่งครัด และให้การรับประกันทางคณิตศาสตร์สำหรับความถูกต้องและความปลอดภัยของโปรโตคอล
การประเมินการทดลอง
เราทำการประเมินอย่างกว้างขวางบน Google Cloud Platform (GCP) โดยกระจายโหนดอย่างเท่าเทียมกันทั่วทั้งห้าภูมิภาค:
us-east 1-b (เซาท์แคโรไลนา)
us-west 1-a (ออริกอน)
Europe-north 1-a (ฮามินา ฟินแลนด์)
เอเชียตะวันออกเฉียงเหนือ 1-a (โตเกียว)
ออสเตรเลียตะวันออกเฉียงใต้ 1-a (ซิดนีย์)
การตั้งค่าการทดลองมีดังนี้:
ไคลเอนต์และโหนดฉันทามติอยู่ร่วมกัน
แต่ละธุรกรรมประกอบด้วยข้อมูลสุ่ม 512 ไบต์ และขนาดแบตช์ตั้งไว้ที่ 500 KB
การทดสอบแต่ละครั้งใช้เวลา 180 วินาที
การวัดเวลาแฝง: คำนวณเวลาเฉลี่ยตั้งแต่การสร้างธุรกรรมจนถึงการส่งโดยโหนดที่ไม่มีข้อผิดพลาดทั้งหมดเพื่อกำหนดเวลาแฝงตั้งแต่ต้นทางถึงปลายทาง
การวัดปริมาณงาน: ประเมินตามจำนวนธุรกรรมที่สรุปผลต่อวินาที
สถาปัตยกรรมที่เราทดสอบประกอบด้วย 300 โหนดแบ่งออกเป็น 5 แคลน โหนดละ 60 โหนด (ใช้งาน 12 โหนดต่อภูมิภาค GCP) ในการกำหนดค่านี้ ความน่าจะเป็นที่กลุ่ม (60 โหนด) ในเครือข่าย 300 โหนดจะล้มเหลวเนื่องจากเสียงส่วนใหญ่ที่ไม่ซื่อสัตย์ภายในคือ 0.0107
อย่างไรก็ตาม เป้าหมายของเราไม่เพียงแต่แสดงให้เห็นถึงประสิทธิภาพสูงของสถาปัตยกรรมนี้เท่านั้น แต่ยังแสดงให้เห็นว่าสามารถรักษาปริมาณงานที่สูงและความหน่วงต่ำได้แม้ในระบบที่ใหญ่กว่า
การกำหนดค่าฮาร์ดแวร์:
เราใช้เครื่อง e 2-standard-32 โดยแต่ละเครื่องมี 32 vCPU, หน่วยความจำ 128 GB และแบนด์วิดท์ขาออกสูงสุด 16 Gbps
จากการทดลองเหล่านี้ เราได้ตรวจสอบความสามารถอันทรงพลังของสถาปัตยกรรม Supra ในแง่ของประสิทธิภาพและความสามารถในการปรับขนาด
รูปที่ 8 ปริมาณงานและการหน่วงเวลาตั้งแต่ต้นทางถึงปลายทาง
เราสังเกตความสัมพันธ์ระหว่างปริมาณงานของระบบและความล่าช้าตั้งแต่ต้นทางถึงปลายทาง ดังแสดงในรูปที่ 8:
เมื่อทรูพุตสูงถึง 500,000 TPS เวลาแฝงจากต้นทางถึงปลายทางจะยังคงอยู่ต่ำกว่า 1 วินาที
ที่ 300,000 TPS เวลาแฝงจะอยู่ที่ประมาณ 650 มิลลิวินาที ซึ่งใกล้เคียงกับขีดจำกัดทางทฤษฎีของการออกแบบสถาปัตยกรรมของเรา
นอกจากนี้ เรายังวัดเวลาการสร้าง Data Availability Certificate (DAQC) ซึ่งอยู่ที่ประมาณ 160 มิลลิวินาที
โดยสรุป:
ความล่าช้าในการยืนยันล่วงหน้าสำหรับการทำธุรกรรมคือประมาณ 160 มิลลิวินาที
เวลาในการตอบสนองขั้นสุดท้ายในการเรียงลำดับน้อยกว่า 1 วินาที
โปรโตคอลฉันทามติของ DAG
แรงบันดาลใจจากการวิจัยเกี่ยวกับโปรโตคอลฉันทามติ DAG (Directed Acyclic Graph) เราได้ออกแบบโปรโตคอลฉันทามติ DAG ใหม่ที่เรียกว่า Sailfish โปรโตคอลนี้ปรับความล่าช้าในการส่งให้เหมาะสมเป็น 1 การออกอากาศที่เชื่อถือได้ + 1 ข้อความล่าช้า (md) โดยไม่กระทบต่อปริมาณงานของระบบ ซึ่งเหนือกว่าประสิทธิภาพของโปรโตคอลฉันทามติ DAG ที่ล้ำสมัยในปัจจุบัน
นอกจากนี้ เรายังพัฒนา Sailfish เวอร์ชันหนึ่งและรวมเข้ากับสถาปัตยกรรมเผ่า-เผ่าเพื่อปรับปรุงปริมาณงานของระบบให้ดียิ่งขึ้น ขณะนี้เรากำลังทำการทดสอบเชิงทดลองอย่างกว้างขวางเกี่ยวกับการออกแบบนี้ หาก Sailfish มีประสิทธิภาพเหนือกว่าโปรโตคอล Moonshot ที่มีอยู่ในสภาพแวดล้อมเครือข่ายขนาดใหญ่ เราวางแผนที่จะเปลี่ยนโปรโตคอลฉันทามติหลักเป็น Sailfish เพื่อให้บรรลุกระบวนการฉันทามติที่มีประสิทธิภาพมากขึ้น
รูปที่ 9 วิธีการดำเนินการแบบขนานของ Supra
8.การดำเนินการ
สถานะปัจจุบันของบล็อกเชนประกอบด้วยสินทรัพย์ทั้งหมดและข้อมูลการเป็นเจ้าของ รวมถึงข้อมูลล่าสุดสำหรับสัญญาอัจฉริยะทั้งหมด เมื่อดำเนินการธุรกรรมบล็อกที่สรุปผลแล้ว คุณต้องโหลดส่วนสถานะที่เกี่ยวข้อง อัปเดตสถานะตามลำดับธุรกรรมในบล็อก และจัดเก็บสถานะที่แก้ไขอย่างถาวร
ในบล็อกเชนสมัยใหม่ ด้วยการปรับปรุงความสามารถในการประมวลผลธุรกรรมอย่างต่อเนื่อง เวลาดำเนินการกลายเป็นปัจจัยสำคัญที่ไม่สามารถละเลยได้ในความล่าช้าในการยืนยันธุรกรรมขั้นสุดท้ายตั้งแต่ต้นทางถึงปลายทาง แนวโน้มนี้เห็นได้ชัดเจนเป็นพิเศษในเครือข่ายเช่น Solana, Sui, Aptos และ Monad ซึ่งลดเวลาแฝงได้อย่างมีประสิทธิภาพด้วยการดำเนินการแบบขนาน
สถาปัตยกรรมชนเผ่าและเผ่าของเรายังช่วยให้สามารถทำธุรกรรมแบบคู่ขนานได้ แต่ได้รับการปรับให้เหมาะสมในระดับเครือข่าย โดยเฉพาะอย่างยิ่ง การดำเนินการของธุรกรรมจะจำกัดอยู่ภายในกลุ่ม และกลุ่มที่แตกต่างกันจะประมวลผลชุดธุรกรรมของตนเองแบบคู่ขนาน ซึ่งจะช่วยปรับปรุงประสิทธิภาพการดำเนินการของระบบได้อย่างมาก (ดูรูปที่ 9)
8.1 การทำธุรกรรมแบบขนาน
นอกเหนือจากการบรรลุความเท่าเทียมในระดับเครือข่ายแล้ว เรายังเจาะลึกถึงวิธีดำเนินการธุรกรรมแบบขนานอย่างมีประสิทธิภาพโดยใช้โปรเซสเซอร์แบบมัลติคอร์อย่างเต็มที่ภายในโหนดเดียว ปัจจุบัน วิธีการดำเนินการแบบคู่ขนานทั่วไปในวรรณกรรมและอุตสาหกรรมแบ่งออกเป็น 2 ประเภทใหญ่ๆ ได้แก่
เทคนิคการดำเนินการในแง่ดี/เก็งกำไร
เทคนิคที่กำหนดไว้ล่วงหน้าตามการพึ่งพาที่กำหนด
ซอฟต์แวร์หน่วยความจำธุรกรรม (STM)
เทคโนโลยี STM ใช้กันอย่างแพร่หลายในด้านการประมวลผลแบบดั้งเดิมสำหรับการประมวลผลโปรแกรมแบบมัลติคอร์แบบขนาน BlockSTM ของ Aptos นำเทคโนโลยี STM มาใช้ในการทำธุรกรรมบล็อกเชน แนวคิดหลักคือ:
ดำเนินธุรกรรมอย่างเหมาะสมในแบบคู่ขนานบนคอร์ที่มีอยู่ทั้งหมด
จากนั้นตรวจสอบว่ามีข้อขัดแย้งในการพึ่งพาระหว่างธุรกรรมหรือไม่
หากพบข้อขัดแย้ง ธุรกรรมที่ขัดแย้งกันจะถูกดำเนินการอีกครั้งผ่านตัวกำหนดเวลาการทำงานร่วมกัน
นวัตกรรมโซลูชั่นของ Supra
เราขอเสนออัลกอริธึมการดำเนินการแบบขนาน STM ที่เป็นนวัตกรรมใหม่ การออกแบบของเราแตกต่างจาก BlockSTM ของ Aptos ซึ่งสามารถแก้ไขข้อขัดแย้งได้อย่างมีประสิทธิภาพโดยไม่ต้องใช้ตัวกำหนดเวลา แนวทางนี้เทียบได้กับ BlockSTM ในด้านประสิทธิภาพและสถาปัตยกรรม และขณะนี้เรากำลังดำเนินการประเมินเชิงลึกของการออกแบบเพื่อตรวจสอบข้อดีในการใช้งานจริง
การทำให้ขนานกันตามข้อกำหนดการเข้าถึง
บล็อกเชนบางตัวใช้การขนานโดยการระบุรูปแบบการเข้าถึงสำหรับธุรกรรม:
Sealevel ของ Solana กำหนดให้มีการทำธุรกรรมเพื่อประกาศบัญชีที่ต้องอ่านและเขียนอย่างชัดเจน
Sui กำหนดให้ธุรกรรมระบุอ็อบเจ็กต์ที่จะอ่านและเขียน (ผ่านตัวระบุอ็อบเจ็กต์) และเพื่อประกาศว่าอ็อบเจ็กต์เหล่านี้เป็นเอกสิทธิ์หรือใช้ร่วมกัน
แนวทางของ Polygon นั้นแตกต่างออกไป ผู้เสนอบล็อกใช้เทคโนโลยี BlockSTM เพื่อดำเนินการบล็อก คำนวณการพึ่งพาระหว่างธุรกรรมล่วงหน้า และรวมข้อมูลการพึ่งพาเหล่านี้ไว้ในบล็อก ทำให้ผู้ตรวจสอบความถูกต้องรายอื่นสามารถดำเนินการธุรกรรมอิสระพร้อมกันได้
อย่างไรก็ตาม สิ่งสำคัญคือต้องทราบว่าการประกาศโหมดการเข้าถึงในธุรกรรมอย่างชัดเจนหรือรวมถึงข้อมูลการพึ่งพาในบล็อกจะทำให้ขนาดบล็อกเพิ่มขึ้นอย่างมาก สิ่งนี้อาจทำให้แบนด์วิธอิ่มตัวเร็วขึ้น ซึ่งเป็นการจำกัดปริมาณงานสูงสุดที่ระบบสามารถทำได้
ด้วยวิธีการเหล่านี้ เรากำลังพัฒนาอัลกอริธึมการดำเนินการแบบขนานที่กำหนดซึ่งจะวิเคราะห์สัญญาอัจฉริยะแบบคงที่ รับข้อกำหนดการเข้าถึงโดยอัตโนมัติเมื่อมีการปรับใช้สัญญา และจัดเก็บข้อกำหนดเหล่านี้ในสถานะบล็อกเชนโดยไม่ต้องใช้โหนด RPC หรือกระเป๋าเงิน . ข้อมูลจำเพาะเหล่านี้ช่วยให้เราเพิ่มประสิทธิภาพลำดับเชิงเส้นของธุรกรรมในบล็อกสรุปผลให้เป็นคำสั่งซื้อบางส่วน (ผ่อนคลาย) ซึ่งช่วยให้สามารถดำเนินการธุรกรรมอิสระแบบคู่ขนานได้ วิธีการนี้ไม่เพียงแต่ลดการใช้แบนด์วิธเท่านั้น แต่ยังปรับปรุงปริมาณงานและประสิทธิภาพของระบบโดยรวมอีกด้วย
วิธีการผสม
เราเชื่อว่าแนวทางแบบไฮบริดที่ปรับปรุงอัลกอริธึม STM โดยใช้ประโยชน์จากข้อกำหนดการเข้าถึงที่ได้รับแบบคงที่เป็นรูปแบบที่ดีที่สุดของเทคนิคการดำเนินการที่ได้รับการปรับปรุง (ดูรูปที่ 9) ขณะนี้เรากำลังดำเนินการประเมินการออกแบบนี้อย่างครอบคลุม
8.2 ความเป็นธรรมของคำสั่งบังคับคดี
เพื่อให้เกิดความเป็นธรรมในการสั่งซื้อธุรกรรม เราได้ออกแบบกระบวนการสองขั้นตอน:
การสั่งซื้อแบบสุ่มครั้งแรก: โปรโตคอลฉันทามติจะสร้างลำดับเริ่มต้นของธุรกรรมแบบสุ่ม
การสั่งซื้อขั้นสุดท้าย: ผ่านโปรโตคอลหมายเลขสุ่มบนเชนที่สร้างขึ้นโดยลายเซ็นเกณฑ์ BLS แบบบล็อก การสั่งซื้อธุรกรรมขั้นสุดท้ายจะได้รับมาและลำดับการดำเนินการจริงของธุรกรรมจะถูกกำหนด
การสุ่มเพิ่มเติมอีกชั้นนี้ช่วยลดการโจมตีค่าสูงสุดที่แยกได้ (MEV) ได้อย่างมีประสิทธิภาพ เนื่องจากผู้เสนอแบบกลุ่มหรือผู้เสนอบล็อกไม่สามารถคาดเดาหรือจัดการลำดับการดำเนินการธุรกรรมแบบสุ่มขั้นสุดท้ายได้
เพื่อจัดการกับปัญหาสแปม เราได้แนะนำตลาดค่าธรรมเนียมท้องถิ่น ในสภาวะที่มีข้อโต้แย้ง ต้นทุนการทำธุรกรรมจะเพิ่มขึ้นแบบทวีคูณ ซึ่งจะช่วยปรับปรุงความสามารถในการป้องกันการรบกวนของระบบ ขณะเดียวกันก็รับประกันประสิทธิภาพและความยุติธรรมในการสั่งซื้อธุรกรรม
8.3 มัลติ-VM
Ethereum ได้เปิดตัว EVM ซึ่งเป็นสภาพแวดล้อมการเขียนโปรแกรมออนไลน์แบบทัวริงที่สมบูรณ์แบบ ซึ่งได้ปลดปล่อยความคิดสร้างสรรค์ของการพัฒนา dApp อย่างมาก โดยเฉพาะอย่างยิ่งการให้การสนับสนุนที่แข็งแกร่งสำหรับแอปพลิเคชัน DeFi EVM ยืมประสบการณ์จากภาษาโปรแกรม Web 2.0 และให้กำเนิด Solidity อย่างไรก็ตาม ด้วยการพัฒนาเทคโนโลยีบล็อกเชน ชุมชนจึงค่อย ๆ ตระหนักว่าภาษาการเขียนโปรแกรมที่ออกแบบมาโดยเฉพาะสำหรับการถ่ายโอนสินทรัพย์และการจัดการสินทรัพย์ออนไลน์เป็นสิ่งจำเป็น ดังนั้น ทีมงาน Diem ของ Meta จึงได้พัฒนาภาษา Move ซึ่งต่อมาได้ก่อให้เกิดรูปแบบต่างๆ เช่น Aptos Move และ Sui Move
Supra ตระหนักอย่างลึกซึ้งถึงความสำคัญของภาษาการเขียนโปรแกรมธุรกรรมออนไลน์ที่ปรับแต่งได้ จึงได้เลือกภาษา Move เป็นตัวเลือกแรกสำหรับแพลตฟอร์มสัญญาอัจฉริยะของเรา และจะเปิดตัวบล็อกเชน L1 ของเราโดยได้รับการสนับสนุนจาก Move
ในขณะเดียวกัน เรายังมองเห็นศักยภาพที่ยอดเยี่ยมในระบบนิเวศแบบ multi-VM นักพัฒนาภายใต้เครื่องเสมือนที่แตกต่างกันสามารถเสริมซึ่งกันและกันและร่วมกันส่งเสริมนวัตกรรมและการพัฒนาของอุตสาหกรรมบล็อกเชน ดังนั้นเราจึงออกแบบสถาปัตยกรรม multi-VM ที่มีประสิทธิภาพ
ตามลักษณะการแบ่งส่วนตามธรรมชาติของสถาปัตยกรรมเผ่า-เผ่า แต่ละเผ่าจะโฮสต์ส่วนแบ่งสถานะ และเผ่าที่แตกต่างกันสามารถโฮสต์เครื่องเสมือนที่แตกต่างกันได้
หลังจากบูรณาการแพลตฟอร์มสัญญาอัจฉริยะ Move แล้ว Supra จะขยายไปยัง Ethereum Virtual Machine (EVM) เพิ่มเติมเพื่อให้เข้ากันได้กับระบบนิเวศ Ethereum ขนาดใหญ่ ต่อไป เราจะรวม Solana Virtual Machine (SVM) เพื่อรองรับนักพัฒนาที่ใช้ภาษาการเขียนโปรแกรมที่ใช้กันอย่างแพร่หลาย เช่น Rust, C และ C++ เพื่อสร้างสัญญาอัจฉริยะ
ในที่สุด Supra จะสนับสนุน CosmWasm ซึ่งช่วยให้สามารถเชื่อมต่อกับระบบนิเวศ Cosmos ที่ใช้งานได้อย่างราบรื่น
การสื่อสารผ่านเครื่องเสมือน
ในสภาพแวดล้อมแบบ multi-VM ผู้ใช้อาจมีหลายบัญชีบนเครื่องเสมือนที่แตกต่างกัน และต้องการถ่ายโอนสินทรัพย์ผ่านเครื่องเสมือน นอกจากนี้ โทเค็นดั้งเดิมของ Supra $SUPRA จะต้องได้รับการจัดการอย่างเท่าเทียมกันในเครื่องเสมือนทั้งหมด เพื่อแก้ไขปัญหานี้ เราขอเสนอขั้นตอนการทำงานสามขั้นตอนที่เรียบง่ายและมีประสิทธิภาพ:
ส่งธุรกรรมการโอนย้ายเครื่องข้ามเสมือน ผู้ใช้เริ่มต้นธุรกรรมการโอนย้ายทรัพย์สินเครื่องข้ามเสมือน ธุรกรรมนี้ประกอบด้วยสองส่วน:
ธุรกรรมเดบิต tdt_dtd ของเครื่องเสมือนต้นทาง
ธุรกรรมขาเข้า tct_ctc ของเครื่องเสมือนเป้าหมาย
ธุรกรรม ttt จะถูกดำเนินการครั้งแรกบนเครื่องเสมือนต้นทาง การหักเงินจะเสร็จสมบูรณ์ และเหตุการณ์ที่เกี่ยวข้องจะถูกทริกเกอร์
การตรวจสอบและการส่งเหตุการณ์: สุ่มเลือกตระกูลจากกลุ่มของเครื่องเสมือนต้นทาง (ตระกูลประกอบด้วยโหนดที่ซื่อสัตย์อย่างน้อยหนึ่งโหนด) โหนดเหล่านี้จะตรวจสอบเหตุการณ์การหักเงินและรับผิดชอบในการส่งธุรกรรมบัญชี tct_ctc
ดำเนินการเครื่องเสมือนเป้าหมายเพื่อหักบัญชีเครื่องเสมือนเป้าหมาย ตระกูลของเครื่องเสมือนเป้าหมายได้รับและดำเนินการ tct_ctc เพื่อทำการหักบัญชีสินทรัพย์ ณ จุดนี้ กระบวนการถ่ายโอนเครื่องเสมือนจะเสร็จสมบูรณ์
9. ยุคและวัฏจักร
ในสถาปัตยกรรมของ Supra การเพิ่มโหนดใหม่ให้กับเผ่าหรือการลบโหนดที่มีอยู่จะได้รับอนุญาตเฉพาะในขอบเขตของยุคเท่านั้น ระยะเวลาของยุคสามารถกำหนดค่าได้ และโดยปกติจะกำหนดเป็นจำนวนบล็อกหรือเรียลไทม์ เราวางแผนที่จะกำหนดความยาวของยุคให้อยู่ที่ประมาณหนึ่งสัปดาห์ ในแต่ละยุค โหนดทั้งหมดในเผ่าจะดำเนินการสั่งซื้อบริการโดยใช้โปรโตคอลที่เป็นเอกฉันท์
ดังแสดงในรูปที่ 10 ยุคหนึ่งจะถูกแบ่งออกเป็นหลายรอบ (รอบ) โดยระยะเวลาโดยทั่วไปของแต่ละรอบจะอยู่ที่ประมาณหนึ่งวัน ในแต่ละรอบ โหนดในเผ่าจะได้รับการสุ่มให้กับแคลนต่างๆ ผ่านทาง VRF ของ Supra (ฟังก์ชันสุ่มที่ตรวจสอบได้) ตัวอย่างเช่น:
ในช่วงที่ 2 ของยุค 1 (e 1 c 2) โหนดอาจมีบทบาทเป็นผู้ตรวจสอบ DORA
ในช่วงที่ 3 ของยุค 1 (e 1 c 3) โหนดเดียวกันอาจรับผิดชอบในการดำเนินการธุรกรรม EVM
กลไกของการกำหนดบทบาทโหนดใหม่แบบสุ่มทุกๆ รอบนี้จะช่วยปรับปรุงความปลอดภัยของระบบได้อย่างมาก และสามารถป้องกันการโจมตีจากผู้ไม่ประสงค์ดีที่พยายามกำหนดเป้าหมายบทบาทหรือฟังก์ชันเฉพาะได้อย่างมีประสิทธิภาพ
รูปที่ 10 ยุคและสัปดาห์
ผู้โจมตีที่โจมตีบริการเฉพาะ (เช่น Service SSS) อาจพยายามขัดขวางบริการนั้นโดยการปิดการใช้งานโหนดบางส่วนของกลุ่มที่ให้บริการ SSS
เพื่อตอบโต้ภัยคุกคามนี้ โปรโตคอลการสร้างคีย์แบบกระจาย (DKG) จะถูกรันทุกรอบสำหรับการจัดโครงสร้างกลุ่มใหม่ เราสามารถบรรลุการรวมตัวกันใหม่บ่อยครั้งนี้ได้ด้วยนวัตกรรมของเราในด้าน DKG - การพัฒนาโปรโตคอล DKG ที่อิงตามกลุ่มคลาสที่มีประสิทธิภาพสูง
ความน่าจะเป็นที่แคลนที่ไม่ดีจะปรากฏขึ้น
ตามที่กล่าวไว้ในส่วนที่ 3 เราวิเคราะห์ผลกระทบด้านความปลอดภัยของเผ่าที่มี 625 โหนดและแบ่งออกเป็น 5 เผ่า (แต่ละ 125 โหนด):
คำจำกัดความของกลุ่มที่ไม่ดี: โหนดไบแซนไทน์ครอบครองเสียงข้างมากของกลุ่ม
ความน่าจะเป็นของการสร้างกลุ่มที่ไม่ดี: ความน่าจะเป็นของการสร้างกลุ่มที่ไม่ดีแบบสุ่มคือประมาณ 35 ในล้าน
สมมติว่าแต่ละช่วงเวลาคือหนึ่งวันและกลุ่มจะแจกจ่ายโหนดใหม่ผ่านการปรับโครงสร้างใหม่ทุกวัน ซึ่งหมายความว่าแม้ในกรณีที่รุนแรงที่สุด (33% ของโหนดในเผ่าถูกควบคุมโดยนักแสดงไบแซนไทน์) ความน่าจะเป็นที่กลุ่มที่ไม่ดีจะปรากฏนั้นต่ำมาก โดยคาดว่าจะเกิดขึ้นเพียงครั้งเดียวทุกๆ 78 ปี
ความน่าจะเป็นที่ต่ำมากนี้แทบไม่มีนัยสำคัญใดๆ และแสดงให้เห็นอย่างเต็มที่ถึงความน่าเชื่อถือของกลไกการสร้างกลุ่มของเราในการมอบความปลอดภัยที่แข็งแกร่ง
10.คอนเทนเนอร์
Supra Container เป็นฟีเจอร์สำคัญที่ออกแบบมาสำหรับชุมชนนักพัฒนาและได้รับแรงบันดาลใจจากแนวคิด Appchain ที่ได้รับความนิยมในปัจจุบัน
เราตระหนักดีถึงข้อดีของห่วงโซ่แอปพลิเคชันโดยเฉพาะอย่างยิ่งคุณค่าที่เป็นเอกลักษณ์ในการมอบความสามารถอธิปไตยให้กับนักพัฒนา dApp และชุมชนของพวกเขา นอกจากนี้ ห่วงโซ่แอปพลิเคชันยังสามารถรองรับโมเดลธุรกิจที่อิงแอปพลิเคชันได้อีกด้วย ปัจจุบัน เลเยอร์ 2, ไซด์เชน, พาราเชน Polkadot, เชนโซนคอสมอส (โซน) และซับเน็ต Avalanche (ซับเน็ต) เป็นโซลูชันชั้นนำในด้านห่วงโซ่แอปพลิเคชัน
อย่างไรก็ตาม เรายังตระหนักด้วยว่าโซลูชันเหล่านี้ไม่เหมาะในบริบทของบล็อกเชนที่มีปริมาณงานสูง เช่น Supra L1 Application chains มักจะต้องมีฟังก์ชันหลักๆ ดังต่อไปนี้:
การใช้งานสัญญาอัจฉริยะแบบจำกัด
โทเค็นแก๊สแบบกำหนดเอง
ราคาก๊าซที่กำหนดเอง
เมื่อเชนแอปพลิเคชันเหล่านี้โฮสต์บนเชนรอง (เช่น พาราเชน เชนภูมิภาค ซับเน็ต ฯลฯ) ราคาก๊าซจะไม่เหมือนกับราคาของเชนหลักที่เกี่ยวข้อง (เช่น Polkadot Relay Chain, Cosmos Hub หรือ Avalanche C -Chain) ราคาน้ำมันทำให้เกิดการแข่งขันและจะไม่ผันผวนตามราคาโซ่หลัก ตลาดค่าธรรมเนียมที่แปลเป็นภาษาท้องถิ่นนี้ช่วยให้ผู้ใช้ได้รับประสบการณ์ค่าธรรมเนียมการทำธุรกรรมที่คาดการณ์ได้มากขึ้น ซึ่งเหมาะสำหรับการใช้งานจริง
เรามุ่งหวังที่จะรวมข้อดีของห่วงโซ่แอปพลิเคชันเหล่านี้เข้ากับความสามารถของบล็อกเชน L1 ประสิทธิภาพสูงผ่านคอนเทนเนอร์ Supra เพื่อสร้างสภาพแวดล้อมทางนิเวศที่ยืดหยุ่นและมีเสถียรภาพมากขึ้นสำหรับนักพัฒนาและผู้ใช้
รูปที่ 11 คอนเทนเนอร์
Supra Container เป็นแนวคิดใหม่ล่าสุดในด้านบล็อกเชน เรากำหนดให้เป็นชุดหรือชุดของสัญญาอัจฉริยะที่ให้บริการ dApps ที่เกี่ยวข้องเพียงกลุ่มเดียวหรือหลายกลุ่ม เราได้ปรับเฟรมเวิร์กรันไทม์ของ Supra ให้เหมาะสมผ่านคอนเทนเนอร์ Supra เพื่อมอบประสบการณ์ที่เหมือนกับ Appchain แก่นักพัฒนา dApp พร้อมด้วยฟีเจอร์เด่นดังต่อไปนี้:
โทเค็นแก๊สแบบกำหนดเอง
ราคาก๊าซที่กำหนดเอง
การใช้งานสัญญาอัจฉริยะแบบจำกัด
ทั้งหมดนี้สามารถทำได้ด้วยต้นทุนที่ต่ำมาก โดยขจัดกระบวนการที่ยุ่งยากในการเปิดตัวเครือข่ายรองใหม่โดยสิ้นเชิง (เช่น เครือข่ายเครื่องมือตรวจสอบความถูกต้องที่ต้องมีแรงจูงใจในการปักหลัก)
แก้ไขปัญหาการกระจายตัวของสภาพคล่อง
ที่สำคัญกว่านั้น เราได้เอาชนะปัญหาสำคัญที่มักเผชิญโดยสายโซ่แอปพลิเคชัน - การกระจายตัวของสภาพคล่อง - โดยการสนับสนุนความสามารถในการประกอบแบบอะตอมมิกของการเรียกเมธอดข้ามคอนเทนเนอร์ การออกแบบนี้ช่วยให้มั่นใจได้ถึงปฏิสัมพันธ์ที่มีประสิทธิภาพระหว่างคอนเทนเนอร์ในขณะที่ยังคงรักษาการรวมศูนย์สภาพคล่องไว้
อำนวยความสะดวกในการดำเนินการแบบขนาน
ในโมเดล Ethereum EVM แต่ละสัญญาอัจฉริยะมีพื้นที่จัดเก็บข้อมูลที่เป็นอิสระ หลังจากแนะนำคอนเทนเนอร์ Supra ลงในโมเดล EVM แล้ว สถานะบล็อกเชนสามารถแบ่งออกเป็นหลายพาร์ติชันได้:
ธุรกรรมภายในคอนเทนเนอร์จะเข้าถึงเฉพาะสถานะของคอนเทนเนอร์เป้าหมายเท่านั้น โดยไม่ส่งผลกระทบต่อสถานะของคอนเทนเนอร์อื่น
การแยกสถานะนี้จะช่วยเพิ่มประสิทธิภาพเวลาดำเนินการของธุรกรรมภายในคอนเทนเนอร์และลดข้อขัดแย้งระหว่างคอนเทนเนอร์ต่างๆ
จากคุณสมบัตินี้ เราได้สร้างคิวการแบ่งปันงานที่เรียบง่ายและมีประสิทธิภาพเพื่อเพิ่มประสิทธิภาพการดำเนินการแบบคู่ขนาน ด้วยการออกแบบนี้ คอนเทนเนอร์ Supra ปรับปรุงประสิทธิภาพการดำเนินการของบล็อกเชนได้อย่างมาก ลดความซับซ้อนของประสบการณ์ของนักพัฒนา และส่งเสริมการปรับปรุงประสิทธิภาพของระบบนิเวศทั้งหมด
11. บทสรุป
วิสัยทัศน์อันทะเยอทะยานของ Supra ในฐานะ IntraLayer ที่บูรณาการในแนวตั้งโดยสมบูรณ์กำลังเป็นรูปเป็นร่างขึ้นหลังจากการวิจัยอย่างเข้มงวดมานานหลายปี เราได้เผยแพร่ผลการวิจัยจำนวนมากในการประชุมทางวิชาการชั้นนำหลายแห่ง เช่น IEEE Security & Privacy, Network and Distributed Security Symposium (NDSS), ACM Conference on Computer and Communications Security (CCS) เป็นต้น นอกจากนี้ เราได้เผยแพร่เอกสารไวท์เปเปอร์เกี่ยวกับส่วนประกอบหลักของเรา ซึ่งรวมถึง:
พิธีสารฉันทามติ Moonshot และ Sailfish
โปรโตคอล Oracle แบบกระจาย (DORA)
ฟังก์ชันสุ่มตรวจสอบแบบกระจาย (DVRF)
การสร้างคีย์แบบกระจายคลัสเตอร์ที่มีประสิทธิภาพ (DKG)
ตู้สุปรา
ไฮเปอร์ลูป
ไฮเปอร์โนวา
เป็นครั้งแรกที่ Supra นำเสนอวิสัยทัศน์ของเราอย่างเต็มที่สำหรับโครงสร้างพื้นฐานบล็อกเชนที่บูรณาการในแนวตั้งอย่างเต็มรูปแบบ ระบบนี้รวมโปรโตคอลนวัตกรรมมากมายที่พัฒนาขึ้นในช่วงหลายปีที่ผ่านมาเพื่อสร้างบล็อคเชนแบบครบวงจรที่มีประสิทธิภาพสูงมาก
