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

แต่ความเป็นจริงของเครือข่ายแบบกระจายไม่เหมาะ: โหนดออฟไลน์โหนดโกหกและบางคนถึงกับก่อวินาศกรรมโดยเจตนา ในกรณีนี้ระบบ "พูดด้วยเสียงเดียว" และรักษาความสม่ําเสมอได้อย่างไร?

นี่คือปัญหาที่โปรโตคอลความเห็นร่วมมีจุดมุ่งหมายที่จะแก้ไข มันเป็นพื้นที่ของกฎเกณฑ์ที่จะนำทางกลุ่มของโหนดที่เป็นอิสระและบางส่วนที่ไม่น่าเชื่อถือได้อย่างไรเพื่อให้ได้ตัดสินใจที่เป็นเอกลักษณ์เกี่ยวกับลำดับและเนื้อหาของแต่ละธุรกรรม

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

• บล็อกที่ขัดแย้งกันสองบล็อกไม่สามารถยืนยันได้พร้อมกัน
• เครือข่ายต้องดำเนินไปข้างหน้าต่อไปและไม่สามารถติดหรือหยุดได้

MonadBFT เป็นการ突破ทางเทคโนโลยีล่าสุดในทิศทางนี้

บทวิจารณ์สั้นๆเกี่ยวกับวิวัฒนาการของโปรโตคอลความเห็น

ในสนามของกลไกความเห็นร่วม มันได้รับการศึกษาจริงในเกณฑ์เป็นเป็นเส้นตารอยสมัย ชุดแรกที่เก่าแก่ของโปรโตคอล เช่น PBFT (Practical Byzantine Fault Tolerance) สามารถจัดการกับสถานการณ์ที่เป็นจริงได้แล้ว: แม้แต่บางโหนดในเครือข่ายจะทิ้งเชน ทำผิด เพ้อเจ้อ ถ้าแม้ว่าพวกเขาจะไม่เกินในอัตราส่วนหนึ่งในจำนวนรวม ระบบก็ยังสามารถเดินหน้าไปได้

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

กระบวนการลงคะแนนทั้งหมดมักผ่านหลายขั้นตอน เช่น การเตรียมพร้อมล่วงหน้า, เตรียมพร้อม, ยืนยัน, และตอบกลับ ในทุกขั้นตอนนั้น ผู้ตรวจสอบทั้งหมดจำเป็นต้องสื่อสารกับกัน กล่าวคือ, ทุกคนต้องบอกให้ทุกคนรู้ และปริมาณข้อความจะเพิ่มขึ้นอย่างรวดเร็วในรูปแบบ 'เครือข่าย'

ความซับซ้อนของโครงสร้างการสื่อสารนี้คือ n² - กล่าวคือ หากมีผู้ตรวจสอบ 100 คนในเครือข่าย แต่ละรอบของการตกลงอาจต้องการการส่งข้อมูลเกือบ 10,000 ข้อความ

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

แหล่งข้อมูล:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

โครงสร้างการสื่อสารรอง 'ทุกคนพูดกับทุกคน' นั้นจริง ๆ มีประสิทธิภาพต่ำมาก ตัวอย่างเช่นในเครือข่ายที่มีผู้ตรวจสอบ 100 คน ทุกรอบของข้อตกลงอาจต้องประมวลผลข้อความหลายหมื่นข้อ

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

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

นี่จะเพิ่มประสิทธิภาพในเรื่องของความซับซ้อนของข้อความจาก n² เดิมเป็น n ซึ่งทำให้ลดภาระของระบบได้อย่างมาก

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

หนึ่งในคุณสมบัติสำคัญของ HotStuff คือการสื่อสารแบบเชิงเส้น ในกลไกของมัน ผู้ตรวจสอบแต่ละคนจำเป็นต้องส่งโหวตของตนไปยังผู้นำปัจจุบันเท่านั้น ซึ่งจากนั้นผู้นำจะแพ็คเกจโหวตเหล่านี้เพื่อสร้างใบรับรองควอรัม (QC)

QC นี้เป็นหลักฐานของลายมือที่เป็นรูปแบบกลุ่ม ที่พิสูจน์ว่าทั้งระบบเครือข่าย: 'โหนดส่วนใหญ่เห็นด้วยกับข้อเสนอนี้'

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

ภาพเปรียบเทียบโครงสร้างการสื่อสารแฟนเอาท์ของ HotStuff กับโหมดการเชื่อมต่อทั้งหมดของ PBFT แหล่งที่มา:

https://www.mdpi.com/1424-8220/24/16/5417

นอกจากการสื่อสารแบบเชิงเส้น HotStuff ยังสามารถอัพเกรดไปเป็นเวอร์ชันที่มีการทำท่อส่งข้อมูล ที่ใช้เพื่อเพิ่มประสิทธิภาพ

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

ในท่อ HotStuff กลไกยิ่งยืดหยุ่นมากขึ้น: ผู้นําใหม่ถูกเลือกในแต่ละรอบ และผู้นําแต่ละคนมีหน้าที่สองอย่าง:

• บรรจุรอบคะแนนล่าสุดเข้าในใบรับรองคอรัม (QC) ที่ด้านหนึ่งและส่งออกไปยังเครือข่ายทั้งหมด;
• ในฝั่งหนึ่ง ขอนำเสนอบล็อกใหม่พร้อมที่จะเริ่มรอบต่อไป

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

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

สรุปมาบ้าง โปรโตคอลเช่น HotStuff ได้ทำการปรับปรุงอย่างมีนัยสำคัญเมื่อเทียบกับ BFT แบบดั้งเดิมในสองมิติ:

• ตัวแทนการสื่อสารเบาลงมากขึ้น โดยมีทุกตัวตรวจสอบเพียงต้องสื่อสารกับผู้นำเท่านั้น;
• ที่สอง ประสิทธิภาพในการประมวลผลสูงขึ้น และกระบวนการยืนยันบล็อกหลายรายการสามารถทำงานได้พร้อมกัน

นี้ทำให้ HotStuff เป็นเทมเพลตการออกแบบสำหรับกลไกความเห็นร่วมบล็อกเชน PoS สมัยใหม่หลายรูปแบบ แต่ทุกสิ่งมีข้อดีและข้อเสียของตนเอง - ในขณะที่โครงสร้างท่อสายพลังงานมีประสิทธิภาพ แต่ก็เป็นที่ทำให้เกิดความเสี่ยงโครงสร้างที่ไม่ค่อยจะค้นพบได้

ต่อไปเราจะลงลึกในประเด็นสำคัญนี้: การแบ่งแยกของด้านหาง

ปัญหาการ Forking ที่ปลายทาง

แม้ว่า HotStuff โดยเฉพาะเวอร์ชันไปป์ไลน์จะแก้ปัญหาความสามารถในการปรับขนาดของโปรโตคอลฉันทามติ แต่ก็แนะนําความท้าทายใหม่ ๆ สิ่งสําคัญที่สุดและถูกมองข้ามได้ง่ายคือปัญหาที่เรียกว่า "Tail Forking"

หากสามารถเข้าใจได้ง่ายๆว่า: บล็อกเชนมีประสบการณ์การสร้างบล็อกโดยบังเกิดโดยบังเกิดขึ้นที่ 'ปลายทาง' ของโซ่

โดยเฉพาะอย่างยิ่งมีบล็อกที่ถูกต้องได้รับการเผยแพร่ไปยังผู้ตรวจสอบส่วนใหญ่และได้รับคะแนนโหวตเพียงพอ ในทางทฤษฎีควรได้รับการยืนยันและเขียนลงในห่วงโซ่หลักทันที อย่างไรก็ตามในท้ายที่สุดมันจะถูก "ข้าม" กําพร้าและแทนที่ด้วยบล็อกใหม่ที่ความสูงเท่ากัน

นี่ไม่ใช่ข้อบกพร่อง ไม่ใช่การโจมตี แต่เนื่องจากในโครงสร้างการออกแบบของโปรโตคอลเองมีความเป็นไปได้ของ 'chain tailing' นี่ฟังดูไม่น่าเป็นธรรมใช่ไหม? ดังนั้น การเกิดอะไรขึ้นบ้าง?

เหมือนที่เราได้กล่าวไว้ก่อนหน้านี้ ผู้นำแต่ละคนในสายพาน HotStuff มีหน้าที่สองงาน:

• 提议一个新区块 (例如 Bₙ₊₁)
• เก็บโหวตสำหรับบล็อกของผู้นำก่อนหน้าเพื่อสร้าง QC (เช่น เพื่อยืนยัน Bₙ ในที่สุด)

งานสองงานเหล่านี้เป็นขนส่งขนส่งขนส่งขนส่ง แต่ปัญหาเกิดขึ้นที่นี่

ตัวอย่างเช่น สมมติว่า Alice เป็นผู้นำ และเธอเสนอบล็อก Bₙ ที่สูง n ซึ่งได้รับส่วนใหญ่อย่างมากของโหวตและเป็น "เกือบยืนยัน"

ต่อไปควรเป็นคราวของบ็อบในการเป็นผู้นำ ดำเนินการไปสู่บล็อกถัดไป Bₙ₊₁ ของโซ่ และรวม QC (Qualified Commitment) ของ Bₙ ในข้อเสนอของเขาเพื่อทำการยืนยันสุดท้ายของ Bₙ

แต่ถ้าบ็อบออฟไลน์ในขณะนี้ หรือมีจิตใจไม่ต้องส่ง QC ของ Bₙ แล้วจะเกิดปัญหา

เนื่องจากไม่มีใครแพคเกจบล็อกของ Alice ด้วย QC บันทึกการโหวตของ Bₙ ไม่ได้กระจ散กระจายออกไป บล็อกนี้ที่ควรได้รับการยืนยัน จึงถูก 'ประมวลผลเย็น' และโดยสุดท้ายถูกละเลยโดยเครือข่ายทั้งหมด

นี่คือความสำคัญของตะขอหาง: บล็อกจากผู้นำก่อนหน้าถูกข้ามเนื่องจากความประมาทหรือความชั่วร้ายของผู้นำต่อไป

ทำไมหางที่แบนขนาดนั้น

ปัญหาของหางสี่เจาะจงมุ่งไปที่สองด้านหลัก 1) กลไกสร้างสรรค์ถูกทำลาย, 2) ความเคลื่อนไหวของระบบถูกทำลาย

ก่อนอื่น รางวัลถูกกลืน

หากบล็อกถูกยกเลิกผู้นําที่เสนอจะไม่ได้รับรางวัลใด ๆ ไม่ว่าจะเป็นรางวัลบล็อกหรือค่าธรรมเนียมการทําธุรกรรม ตัวอย่างเช่นหากอลิซเสนอบล็อกที่ถูกต้องและได้รับการสนับสนุนอย่างท่วมท้นในการลงคะแนน แต่เนื่องจากความผิดพลาดของบ๊อบหรือการดําเนินการที่เป็นอันตรายบล็อกไม่สามารถยืนยันได้อลิซจะไม่ได้รับเงินในที่สุด สิ่งนี้จะนําไปสู่โครงสร้างแรงจูงใจที่มีข้อบกพร่อง: โหนดที่เป็นอันตรายเช่น Bob สามารถ 'ตัด' แหล่งรางวัลของพวกเขาโดยการข้ามบล็อกของฝ่ายตรงข้าม พฤติกรรมนี้ไม่ต้องการการโจมตีทางเทคนิคเพียงแต่จงใจ 'ไม่ให้ความร่วมมือ' เพื่อลดผลกําไรของคู่แข่ง หากสิ่งนี้เกิดขึ้นซ้ํา ๆ เมื่อเวลาผ่านไปการมีส่วนร่วมและความเป็นธรรมของระบบทั้งหมดจะลดลงและแม้แต่ทําให้เกิดการสมรู้ร่วมคิดระหว่างโหนด

มืดอีกที พืมงของการโจมตี MEV ขยายตัว:

ส้อมหางยังก่อให้เกิดปัญหาที่ร้ายกาจ แต่ร้ายแรงกว่า: มีพื้นที่มากขึ้นสําหรับ MEV (ค่าที่สกัดได้สูงสุด) ที่จะจัดการโดยมีเจตนาร้าย นี่คือตัวอย่าง: สมมติว่าอลิซมีการค้าเก็งกําไรที่มีค่าในบล็อกของเธอ หากบ็อบต้องการสร้างปัญหาเขาสามารถสมรู้ร่วมคิดกับแครอลผู้นําคนต่อไปและจงใจไม่แพร่กระจายบล็อกของอลิซ จากนั้นแครอลก็สร้างบล็อกใหม่ที่ความสูงเท่ากัน "ขโมย" การค้าเก็งกําไรดั้งเดิมของอลิซ - ทําให้ MEV ได้รับของเขาเอง การปฏิบัติของ "การจัดเรียงหัวโซ่ + การสมรู้ร่วมคิดและการจัดสรร" นี้ยังคงเป็นบล็อกตามกฎบนพื้นผิว แต่จริงๆแล้วมันเป็นการปล้นที่ออกแบบมาอย่างดี ที่แย่ไปกว่านั้นคือมันก่อให้เกิด "การสมรู้ร่วมคิด" ระหว่างผู้นําเปลี่ยนการยืนยันบล็อกเป็นเกมแบ่งปันผลประโยชน์มากกว่าบริการสาธารณะ

สาม, ทำลายการรับรองความสมบูรณ์, ทำให้ผู้ใช้ประสบปัญหาในการใช้งาน:

เมื่อเทียบกับโปรโตคอลที่มีลักษณะคล้าย Nakamoto ข้อได้เปรียบที่สําคัญอย่างหนึ่งของ BFT คือการสรุปที่กําหนด: เมื่อบล็อกถูกกระทําแล้วจะไม่สามารถย้อนกลับได้ อย่างไรก็ตามส้อมหางขัดขวางการรับประกันนี้โดยเฉพาะอย่างยิ่งในบล็อกที่ 'มุ่งมั่นล่วงหน้า แต่ไม่ได้รับการยืนยันอย่างเป็นทางการ' dapps ที่มีปริมาณงานสูงบางรายมักต้องการอ่านข้อมูลทันทีหลังจากการลงคะแนนแบบบล็อกเพื่อลดเวลาแฝง และหากการบล็อกถูกยกเลิกอย่างกะทันหัน อาจทําให้สถานะผู้ใช้ย้อนกลับ เช่น ยอดคงเหลือในบัญชีที่ผิดปกติ การซื้อขายที่มีเลเวอเรจสูงที่เพิ่งเสร็จสิ้นจะหายไปโดยไม่มีเหตุผล หรือการรีเซ็ตสถานะเกมอย่างกะทันหัน

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

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

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

MonadBFT คืออะไร?

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

1) การเปลี่ยนผู้นำ: เลือกผู้นำใหม่สำหรับแต่ละรอบเพื่อขับเคลื่อนโซ่ไปข้างหน้า;
2) Pipelined commits: กระบวนการการยืนยันบล็อกหลายกระบวนการสามารถทับซ้อนกันได้;
3) การสื่อสารแบบเชิงเส้น (การส่งข้อความแบบเชิงเส้น): แต่ละผู้ตรวจสอบเพียงแค่ต้องสื่อสารกับผู้นำเท่านั้น ลดการใช้ทรัพยากรของเครือข่ายมากเป็นอย่างมาก

แต่การพึ่งพาอย่างเดียวบนจุดสามข้อนี้ไม่เพียงพอเพื่อความปลอดภัย เพื่อปิดช่องโหว่โครงสร้างของส่วนท้าย MonadBFT ได้เพิ่มกลไกสำคัญสองอย่าง:

1) กลไกการเสนออีกครั้งที่บังคับ (Re-Proposal)
2) ใบรับรองที่ไม่ได้รับการรับรอง (NEC)

กลไกการเสนอใหม่

ในโปรโตคอล BFT เวลาถูกแบ่งเป็นรอบ (เรียกว่ามุมมอง) โดยมีผู้นำในแต่ละรอบรับผิดชอบในการเสนอบล็อกใหม่ หากผู้นำล้มเหลว (ตัวอย่างเช่น โดยไม่เสนอบล็อกตรงเวลาหรือเสนอเสนอที่ไม่ถูกต้อง) ระบบจะสลับไปยังรอบถัดไปและเลือกผู้นำใหม่

MonadBFT ได้เพิ่มกลไกเพื่อให้แน่ใจว่าบล็อกที่เสนออย่างซื่อสัตย์ระหว่างกระบวนการสลับมุมมองจะไม่ 'หลุดออกจากเชือก' เนื่องจากการหมุนผู้นำ

เมื่อผู้นำปัจจุบันล้มเหลว ผู้ตรวจสอบจะส่งข้อความที่ถูกลงนามสำหรับการสลับรอบ (การเปลี่ยนมุมมอง) แสดงว่ารอบปัจจุบันได้หมดเวลาแล้ว

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

รอบผู้นำใหม่จะเก็บข้อความหมดเวลาเหล่านี้จากผู้ตรวจสอบส่วนใหญ่ (2f+1) และผสานเข้าด้วยกันในใบรับรองการหมดเวลา (TC) ใบรับรองการหมดเวลานี้แทนภาพรวมทางสมองที่เป็นเอกลักษณ์ของ 'บล็อกหัวเชือก' ของเครือข่ายทั้งหมดเมื่อรอบก่อนหน้าล้มเหลว ผู้นำใหม่จะเลือกบล็อกที่สูงที่สุด (หรือหมายเลขมุมมองล่าสุด) ที่รู้จักกันเป็น high_tip จากนั้น

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

ทำไม? ตามที่กล่าวไว้ก่อนหน้า: เราไม่ต้องการให้บล็อกที่ใกล้จะได้รับการยืนยันหายไป

ตัวอย่างเช่น สมมติว่า Alice เป็นผู้นำของมุมมอง 5 ได้เสนอบล็อกที่ถูกต้องและได้รับโหวตส่วนมาก ถัดมาเมื่อผู้นำของมุมมอง 6 คือ Bob ออฟไลน์และล้มเหลวในการก้าวหน้าขั้นตอนเชื่อมต่อโซ่ ณ เวลาที่ Carol เป็นผู้นำของมุมมอง 7 ตามกฎของ MonadBFT เธอต้องรวม TC และเสนอบล็อกของ Alice อีกครั้ง ด้วยวิธีนี้ งานที่ซื่อสัตย์ของ Alice จะไม่ได้เสียเปล่า

หาก Carol ไม่มีบล็อกของ Alice เธอสามารถขอจากโหนดอื่น ๆ โหนดสามารถ:

• 提供บล็อก หรือ
• ส่งข้อความ 'No-Endorsement (NE)' ที่ได้รับลายเซ็น ซึ่งบ่งบอกว่าผู้ส่งไม่มีบล็อกนี้ (กลไกของมันจะอธิบายในภายหลัง) (สูงสุด f โหนดบายแทนตีความและไม่ตอบกลับ)

เมื่อ Carol ทำการเสนอแบล็คของ Alice อีกครั้ง เธอจะได้โอกาสเสนอเพิ่มเติมเพื่อให้แน่ใจว่าเธอไม่ได้ 'เกี่ยวข้อง' เนื่องจากความล้มเหวของผู้นำก่อนหน้า

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

ใบรับรองที่ไม่สามารถลงนาม (NEC)

ดำเนินการต่อจากตัวอย่างก่อนหน้า: หลังจากที่ตาของบ็อบหมดเวลาลงทุน แครอลร้องขอให้ผู้ตรวจสอบอื่น ๆ 提供 high_tip block (นั่นคือ block ของอลิส) ในจุดนี้ อย่างน้อย 2f+1 ผู้ตรวจสอบจะตอบ:

• ให้บริการบล็อกของ Alice
• ส่งข้อความ NE ที่ลงนามแสดงว่าคุณยังไม่ได้รับบล็อกของ Alice

ตราบใดที่ Carol ได้รับบล็อกจาก Alice เธอต้องเสนอใหม่ตามกฎระเบียบ Carol สามารถข้ามบล็อกและเสนอใหม่เมื่ออย่างน้อย f+1 ผู้ตรวจสอบได้ลงลายรับ NE ข้อความ

ทำไม f+1? ในระบบ BFT ที่ประกอบด้วย validators 3f+1 คน มีอาจจะมีผู้ที่มีเจตนาที่เพียง f คนเท่านั้น หากบล็อกของ Alice ได้รับโหวตเพียงส่วนใหญ่ แสดงว่าอย่างน้อย 2f+1 โหนดที่ซื่อสัตย์ได้รับบล็อกนี้

ดังนั้นหาก Carol อ้างว่า “ฉันไม่สามารถรับบล็อกของ Alice ได้” เธอจะต้องแสดงไซน์เนเจอร์ของผู้ตรวจสอบ f+1 ให้เห็นว่าไม่มีใครได้รับมันนั้น ซึ่งเป็นการรับรองที่ไม่มีการสนับสนุน (NEC)

NEC เป็นข้อมูลประจำตัวของผู้นำ: เป็นหลักฐานที่สามารถตรวจสอบได้ว่าบล็อกก่อนหน้ายังไม่พร้อมที่จะยืนยัน ไม่ได้ถูกข้ามอย่างชัดเจน แต่ถูก 'ละทิ้ง' ด้วยเหตุผล

Re-proposal + Unendorsed certificate = แก้ไขสายหาง

MonadBFT นำเสนอชุดกฎการประมวลผลหัวโซ่ที่เข้มงวดและชัดเจนโดยการนำเสนอกลไกการเสนออีกครั้งและใบรับรองไม่มีการยืนยัน (NEC)

โปรดยืนยันอย่างสมบูรณ์ว่า 'ใกล้จะได้รับการยืนยัน' บล็อก;

โปรดระบุหลักฐานเพียงพอเพื่อพิสูจน์ว่าบล็อกยังไม่พร้อมที่จะยืนยัน,

มิฉะนั้นจะไม่อนุญาตให้ข้ามหรือแทนบล็อกก่อนหน้านี้

กลไกนี้ ทำให้บล็อกที่ได้รับจำนวนโหวตส่วนใหญ่ที่ถูกต้องจะไม่ถูกทอดทิ้งเนื่องจากข้อผิดพลาดของผู้นำหรือการหลีกเลี่ยงโดยตั้งใจ

ความเสี่ยงทางโครงสร้างของหางสามงที่แก้ไขอย่างเป็นระบบและโปรโตคอลสามารถจำกัดพฤติกรรมการข้ามที่ไม่เหมาะสมได้อย่างชัดเจน

หากผู้นำพยายามข้ามบล็อกก่อนหน้าโดยไม่มีหลักฐาน NEC โปรโตคอลจะรู้จักและปฏิเสธพฤติกรรมทันที พฤติกรรมกระโดดโดยไม่มีหลักฐานทางร้ายจะถูกพิจารณาว่าผิดกฎหมายและจะไม่ได้รับการสนับสนุนจากความเห็นร่วมของเครือข่าย

จากมุมมองแรงจูงใจทางเศรษฐกิจ การออกแบบนี้จะให้ความคุ้มครองที่ชัดเจนสำหรับผู้ตรวจสอบ

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

สำคัญที่สุด MonadBFT ไม่เสียสมรรถนะของโปรโตคอลเพื่อเพิ่มความปลอดภัย

การออกแบบบางอย่างที่เกี่ยวข้องกับทราบที่อยู่ในหาง (เช่น โปรโตคอล BeeGees) ในอดีตมีความสามารถในการป้องกันบางอย่าง แต่มักพึงพอใจในความซับซ้อนของการสื่อสารสูง (n²) หรือเปิดให้กระบวนการสื่อสารหนักในแต่ละรอบ ซึ่งเพิ่มภาระของระบบอย่างมีนัยสำคัญในการใช้งานจริง

กลยุทธ์การออกแบบของ MonadBFT มีความซับซ้อนมากกว่า

การสื่อสารเพิ่มเติม (เช่น ข้อความตอบกลับที่หมดเวลา การเสนอบล็อกใหม่) เกิดขึ้นเฉพาะเมื่อมีการเกิดข้อผิดพลาดในมุมมองหรือเกิดความผิดปกติ ในเส้นทางปกติที่มีผู้นำที่ซื่อสัตย์ส่วนใหญ่ทำการผลิตบล็อกอย่างต่อเนื่อง โปรโตคอลยังคงรักษาสถานะการทำงานอย่างเรียบเรียงและมีประสิทธิภาพ

ความสมดุลทางดีนามะระหว่างประสิทธิภาพและความปลอดภัยเป็นหนึ่งในข้อได้เปรียบใน MonadBFT สำหรับโปรโตคอลที่เป็นบรรพบุรุษ

สรุป

บทความนี้จะทบทวนกลไกพื้นฐานของการตกลง PBFT เดิมๆ จัดเรียงเส้นทางการพัฒนาของโปรโตคอล HotStuff และเน้นที่ว่า MonadBFT แก้ปัญหาหางหมดที่แตกต่างของไทล์ HotStuff ในโครงสร้างเลเยอร์ของโปรโตคอล

การเสาหลังอาจทำให้แรงบันดาลใจทางเศรษฐศาสตร์ของผู้เสนอบล็อกเสี่ยงต่อกิจกรรมของเครือข่าย โมนัด BFT รับประกันว่าบล็อกใดที่ถูกเสนอโดยผู้นำซื่อสัตย์และได้รับการอนุมัติจากการโหวตส่วนใหญ่ทางกฎหมายจะไม่ถูกทอดทิ้งหรือข้ามโดยการนำเสนออีกครั้งและใบรับรองที่ไม่ได้รับการสนับสนุน (NEC)

ในบทความถัดไป เราจะดำเนินการสำรวจคุณลักษณะแกนของ MonadBFT อีก 2 คุณลักษณะ

1）ความสมบูรณ์ที่เป็นเพียงเพียงการคาดการณ์
2）การตอบสนองอย่างเชื่อมั่น

การวิเคราะห์เพิ่มเติมของกลไกเหล่านี้และความสำคัญทางปฏิบัติสำหรับผู้ตรวจสอบและนักพัฒนา

คำแถลง:

1. บทความนี้พิมพ์ซ้ําจาก [michael_lwy] ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [michael_lwy]，if you have any objections to the reprint, please contact ทีม Gate Learn) ทีมจะดำเนินการโดยเร็วที่สุดตามกระบวนการที่เกี่ยวข้อง
2. ข้อความกล่าวถึงในบทความนี้เป็นความคิดเห็นของผู้เขียนเท่านั้น และไม่มีเจตนาที่จะให้คำแนะนำทางการลงทุนใดๆ
3. เวอร์ชันภาษาอื่นของบทความถูกแปลโดยทีม Gate Learn โดยไม่ระบุGate.ioอย่าคัดลอก แจกจ่าย หรือลอกเลียบบทความที่ถูกแปลโดยไม่ได้รับอนุญาต