เราได้เรียนรู้ว่าระบบแบบกระจายโดยทั่วไปบรรลุความสอดคล้องกันผ่านหลักการของ State Replicator [1] แนวคิดหลักคือแบบจำลองทั้งหมดในระบบรันเครื่องสถานะเดียวกัน ตราบใดที่แบบจำลองทั้งหมดเริ่มต้นด้วยสถานะเริ่มต้นเดียวกันและดำเนินการชุดของการดำเนินการในลำดับเดียวกันตามสถานะเริ่มต้นเดียวกัน จากนั้นสถานะทั้งหมดจะมาบรรจบกันในที่สุด นั่นคือ ระบบทั้งหมดแสดงความสอดคล้องกันภายนอก การกำหนดกลุ่มของการดำเนินการนี้ให้อยู่ในลำดับเดียวกันนั้นจำเป็นต้องให้ระบบบรรลุฉันทามติ นอกจากนี้ โหนดที่ซื่อสัตย์ทั้งหมดจะต้องได้รับฉันทามติในคำสั่งดำเนินการ นี่คือปัญหา Byzantine Generals [2] ที่มีชื่อเสียง

เราได้เรียนรู้ว่าระบบแบบกระจายโดยทั่วไปบรรลุความสอดคล้องกันผ่านหลักการของ State Replicator [1] แนวคิดหลักคือแบบจำลองทั้งหมดในระบบรันเครื่องสถานะเดียวกัน ตราบใดที่แบบจำลองทั้งหมดเริ่มต้นด้วยสถานะเริ่มต้นเดียวกันและดำเนินการชุดของการดำเนินการในลำดับเดียวกันตามสถานะเริ่มต้นเดียวกัน จากนั้นสถานะทั้งหมดจะมาบรรจบกันในที่สุด นั่นคือ ระบบทั้งหมดแสดงความสอดคล้องกันภายนอก การกำหนดกลุ่มของการดำเนินการนี้ให้อยู่ในลำดับเดียวกันนั้นจำเป็นต้องให้ระบบบรรลุฉันทามติ นอกจากนี้ โหนดที่ซื่อสัตย์ทั้งหมดจะต้องได้รับฉันทามติในคำสั่งดำเนินการ นี่คือปัญหา Byzantine Generals [2] ที่มีชื่อเสียง

การรับประกันความปลอดภัยตามทฤษฎีของอัลกอริทึมที่สอดคล้องกันของไบแซนไทน์ นั่นคือ n>3f, n คือจำนวนโหนดทั้งหมด และ f คือจำนวนโหนดที่เป็นอันตราย อัลกอริทึมที่สอดคล้องกันของไบแซนไทน์จำเป็นต้องรับประกันคุณสมบัติสองประการ:

• ความปลอดภัย: โหนดที่ซื่อสัตย์ทั้งหมดเชื่อว่าสถานะของระบบอยู่ในช่วงเวลาหนึ่ง

• กิจกรรม: โหนดที่ซื่อสัตย์ทั้งหมดสามารถกำหนด s เป็นสถานะของระบบได้ในที่สุด

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

ในอดีต ในการวิจัยระบบแบบกระจาย ฉันทามติของไบแซนไทน์มักมาพร้อมกับความซับซ้อนในการสื่อสารที่สูง ซึ่งทำให้เกิดการใช้งานเครือข่ายจำนวนมาก และขนาดของระบบก็ไม่ง่ายที่จะขยาย ตัวอย่างเช่น ในอัลกอริทึม PBFT แบบคลาสสิก จะต้องผ่านสามขั้นตอนเพื่อให้ได้ฉันทามติ ในขั้นตอน PRE-PREPARE โหนดหลักจะส่งข้อความคำขอไปยังโหนดอื่นๆ หลังจากที่โหนดอื่นๆ ตรวจสอบข้อความแล้ว พวกเขาจะส่งการเตรียมการ ข้อความไปยังโหนดอื่น ขั้นตอนนี้สร้าง n ^2 ข้อความ โหนดส่งข้อความยืนยันไปยังโหนดอื่นหลังจากได้รับข้อความเตรียมโควรัมเป็นอย่างน้อย เพื่อให้แน่ใจว่าสอดคล้องกันในมุมมองต่างๆ เมื่อโหนดได้รับข้อความยืนยันอย่างน้อยครบองค์ประชุม ในที่สุด โหนดก็ส่งคำขอ อย่างไรก็ตาม เมื่อโหนดผิดปกติของเครือข่ายหมดเวลาและทริกเกอร์การสลับมุมมอง จำเป็นต้องใช้ความซับซ้อนในการสื่อสารที่ o(n^3)

การทำความเข้าใจการทำงานของแต่ละด่านใน PBFT เป็นพื้นฐานของ HotStuff และเป้าหมายของแต่ละด่านใน PBFT คือเพื่อความปลอดภัยและความมีชีวิตชีวา

สมมติว่าระบบได้รับคำสั่ง S'=S+1 ในช่วงเวลาหนึ่ง โหนดมาสเตอร์จะส่งคำสั่งนี้ S'=S+1 ไปยังโหนดที่ไม่ใช่มาสเตอร์ (นี่คือข้อความเตรียมการล่วงหน้า) เนื่องจากเป็น ปัญหาไบแซนไทน์โหนดที่ซื่อสัตย์ไม่แน่ใจในตัวเองว่าข้อความที่ได้รับนั้นสอดคล้องกับโหนดที่ซื่อสัตย์อื่น ๆ หรือไม่ (โหนดหลักส่งข้อความที่ไม่สอดคล้องกัน) และโหนดจำเป็นต้องสื่อสารกันอีกครั้งเพื่อให้แน่ใจว่าข้อความที่ได้รับด้วยตัวเองและ โหนดที่ซื่อสัตย์อื่นๆ สอดคล้องกัน (พิจารณาว่าโหนดหลักไม่ได้ส่งข้อความที่ไม่สอดคล้องกัน) แต่ละโหนดจะส่งข้อความเตรียมไปยังโหนดอื่นๆ ทั้งหมด และถ้าคุณได้รับข้อความเตรียมครบองค์ประชุมและผ่านการตรวจสอบ (ตรวจสอบว่าคำแนะนำชี้ไปที่เตรียม ตรงกับตัวเอง) ก็บรรลุฉันทามติรอบแรกแล้ว (เป็นขั้น PREPARE) ณ จุดนี้ ดูเหมือนว่าข้อความที่ได้รับจากโหนดซื่อสัตย์จะสอดคล้องกัน แต่เงื่อนไขโดยนัยที่นี่คือโหนดที่ได้รับฉันทามติจะเห็นจากมุมมองของตนเองเท่านั้น: ฉันได้รับและตรวจสอบข้อความที่สอดคล้องกันขององค์ประชุมแล้ว อย่างไรก็ตาม โหนดอื่น ๆ อาจไม่จำเป็นต้องได้รับข้อความเตรียมองค์ประชุมเพื่อบรรลุฉันทามติ หากการส่งถูกทำในเวลานี้และเกิดความล้มเหลวของเครือข่าย โหนดที่ส่งจะรู้ว่าได้รับฉันทามติแล้ว ตราบเท่าที่เครือข่ายกู้คืน คำสั่งนี้ จะได้รับการยอมรับจากทั้งระบบอย่างแน่นอน ส่ง. อย่างไรก็ตาม โหนดอื่นๆ อาจไม่ได้รับการยินยอมเนื่องจากความล้มเหลวของเครือข่าย และไม่สามารถแน่ใจได้ว่าจะสามารถส่งได้หรือไม่หลังจากรอ เพื่อรักษาระบบให้คงอยู่ การสลับมุมมองจะดำเนินการ และในเวลานี้ โหนดหลักใหม่จำเป็นต้องพิจารณาว่าจะดำเนินการคำสั่งใหม่บนพื้นฐานของ S' หรือ S หากไม่พบว่ามีโหนดบางโหนดส่งคำสั่ง และอีกคำสั่ง S''=S+2 ถูกตกลงและส่ง ระบบจะมีค่าตัวแปร S ไม่สอดคล้องกัน ดังนั้นจึงมีปัญหาด้านความปลอดภัยที่จะส่งในเวลานี้

หากฉันทามติในขั้นอื่นดำเนินการ หลังจากที่บรรลุฉันทามติ PREPARE แต่ละรายการจะส่งข้อความยืนยันอีกครั้ง และแต่ละโหนดจะรอเพื่อยอมรับและตรวจสอบข้อความยืนยันครบองค์ประชุมก่อนที่จะส่ง ก็จะเจอปัญหาเดียวกัน คือ Node ที่ถึง COMMIT Consensus แล้ว เค้ารู้ว่าถ้า Network ปกติ ระบบจะ Submit ไม่ช้าก็เร็ว แต่ Node อื่นๆ ที่ไม่ถึง COMMIT Consensus นั้น ไม่แน่ใจเหมือนกันว่า สามารถยื่นได้ในที่สุด หลังจากเกิดความล้มเหลวของเครือข่าย หากโหนดหลักในมุมมองใหม่ไม่พบโหนดที่ส่ง ก็จะยังคงทำให้เกิดความไม่สอดคล้องกัน ความขัดแย้งในที่นี้คือเราจำเป็นต้องเปลี่ยนมุมมองเพื่อสานต่อฉันทามติสำหรับกิจกรรม เพื่อความปลอดภัย เรายังจำเป็นต้องตรวจสอบให้แน่ใจว่าค่าของ S สอดคล้องกันก่อนที่มุมมองใหม่จะเริ่มฉันทามติ และจะต้องส่งคำแนะนำที่ส่งมาในมุมมองใหม่ ดู. ใน PBFT วิธีการส่งข้อความไปยังโหนดอื่นเพื่อพิสูจน์สถานะของ S ของตัวเองเมื่อมีการเปลี่ยนมุมมอง นั่นคือการส่งข้อความเตรียมการล่วงหน้าของ S ล่าสุดและข้อความเตรียมโควรัมที่สอดคล้องกัน เมื่อเปลี่ยนมุมมอง โหนดหลักใหม่สามารถตัดสินได้ว่า S'=S+1 จำเป็นต้องส่งก่อนฉันทามติหรือไม่

• หากไม่มีโหนดใดบรรลุฉันทามติใน PREPARE สำหรับ S'=S+1 โหนดนั้นจะไม่ส่ง S'=S+1 ต่อไป

• หากมีคู่โหนดที่บรรลุฉันทามติในเฟส PREPARE ของ S'=S+1 เป็นไปไม่ได้ที่จะบรรลุฉันทามติในคำสั่งที่ขัดแย้งกัน S''=S+2 และส่งคำสั่งนั้น

ตามกฎนี้ รับประกันความปลอดภัยและกิจกรรม แต่ความซับซ้อนที่เกิดจากวิธีนี้คือ o(n^3) ดังนั้นจึงยังไม่สามารถใช้อัลกอริทึมในเครือข่ายขนาดใหญ่ได้ อัลกอริธึมฉันทามติ HotStuff [4] เสนอโดย Yin Maofan และคณะ มีลักษณะเฉพาะของการเปลี่ยนแปลงมุมมองเชิงเส้นซึ่งแก้ปัญหาคอขวดของ PBFT แบบคลาสสิกหรือแม้แต่ฉันทามติ BFT การสลับโหนดหลักไม่จำเป็นต้องเพิ่มโปรโตคอลและค่าใช้จ่ายอื่น ๆ และระบบยังสามารถทำงานภายนอกได้อย่างสม่ำเสมอซึ่งช่วยลดความซับซ้อนในการสื่อสารของกระบวนการฉันทามติเป็น o(n)

——แนวคิดพื้นฐานของ HotStuff——

การทำความเข้าใจอัลกอริทึม hotstuff จำเป็นต้องแนะนำแนวคิดหลายอย่างที่เกี่ยวข้องกับกระบวนการฉันทามติ:

1) ลายเซ็นเกณฑ์ [5] (ลายเซ็นเกณฑ์): รูปแบบลายเซ็นเกณฑ์ A (k, n) หมายถึงกลุ่มลายเซ็นที่ประกอบด้วยสมาชิก n สมาชิก สมาชิกทั้งหมดใช้รหัสร่วมกัน และสมาชิกแต่ละคนมีรหัสส่วนตัวของตนเอง ตราบเท่าที่มีการรวบรวมลายเซ็นของสมาชิก k และสร้างลายเซ็นที่สมบูรณ์ ลายเซ็นจะสามารถตรวจสอบได้ด้วยคีย์สาธารณะ

2) ใบรับรอง (Quorum Certificate, QC): หลังจากที่โหนดหลักได้รับข้อความการลงคะแนนคู่โหนดอย่างน้อยโควรัม (พร้อมลายเซ็น) สำหรับข้อเสนอ โหนดหลักจะใช้ลายเซ็นเกณฑ์เพื่อสังเคราะห์ QC QC นี้สามารถเข้าใจได้ว่าเป็นลายเซ็นเกณฑ์ที่สมบูรณ์ ลายเซ็นที่สร้างขึ้นหมายความว่ามีการบรรลุฉันทามติในข้อเสนอ

3) มุมมอง: มุมมองเป็นหน่วยพื้นฐานของฉันทามติ มุมมองสามารถเข้าถึงฉันทามติได้มากที่สุดเพียงครั้งเดียว และจะเพิ่มขึ้นอย่างจำเจ แต่ละมุมมองจะค่อยๆ หมุนเพื่อให้ฉันทามติก้าวหน้า

4) Consensus state tree: แต่ละ Consensus block สามารถถือเป็นโหนดต้นไม้ แต่ละโหนดต้นไม้มีเนื้อหาข้อเสนอที่สอดคล้องกัน (คำแนะนำการใช้งานก่อนหน้า) และ QC ที่สอดคล้องกัน และแต่ละโหนดต้นไม้มีแฮชโหนดต้นไม้หลักเพื่อสร้างต้นไม้ โครงสร้าง และโหนดหลักสร้างโหนดต้นไม้ใหม่ตามสาขาท้องถิ่นที่ยาวที่สุด โหนดที่ปกคลุมด้วยวัตถุฉนวนประสานโหนดต้นไม้ที่ขาดหายไประหว่างกลางกับโหนดต้นไม้ล่าสุดบนสาขาที่ยาวที่สุดของโหนดอื่นๆ

—— กระบวนการฉันทามติของ HotStuff ——

ข้อความ

▲ Basic Hotstuff

Basic HotStuff เป็นกระบวนการพื้นฐานของความเห็นพ้องต้องกัน ในหมู่พวกเขา มุมมองจะถูกเปลี่ยนอย่างต่อเนื่องในลักษณะที่เพิ่มขึ้นอย่างจำเจ แต่ละมุมมองมีโหนดหลักเฉพาะที่รับผิดชอบข้อเสนอ รวบรวม และส่งต่อข้อความ และสร้าง QC กระบวนการทั้งหมดประกอบด้วย 4 ขั้นตอน: ขั้นเตรียม (PREPARE) ขั้นก่อนส่ง (PRE-COMMIT) ขั้นส่ง (COMMIT) ใน ขั้นตอนการตัดสินใจ (DECIDE) โหนดหลักส่ง (ถึงฉันทามติ) สาขาหนึ่ง รวบรวมข้อความลงคะแนนพร้อมลายเซ็นจากโหนดฉันทามติองค์ประชุมในสามขั้นตอนของ PREPARE, PRE-COMMIT และ COMMIT ใช้ลายเซ็นเกณฑ์เพื่อสังเคราะห์ QC แล้วออกอากาศไปยังโหนดอื่น

เมื่อรวมกับลายเซ็นเกณฑ์ HotStuff สามารถแปลงวิธีการก่อนหน้าในการเผยแพร่ข้อความฉันทามติไปยังโหนดหลักสำหรับการประมวลผล การผสาน และการส่งต่อ และความซับซ้อนในการสื่อสารสามารถลดลงเป็น o(n) กล่าวโดยย่อ HotStuff ใช้ลายเซ็นเกณฑ์ + สองรอบของ การสื่อสารเพื่อให้บรรลุผลที่เป็นเอกฉันท์ของการสื่อสาร PBFT รอบหนึ่ง

เมื่อเปรียบเทียบกับอัลกอริทึม PBFT ฉันทามติจะเริ่มต้นเมื่อโหนดหลักส่งคำขอไปยังโหนดอื่น ๆ ในการเตรียมการล่วงหน้า โหนดหลักได้ปฏิบัติตามความรับผิดชอบของการฉันทามติรอบนี้แล้ว ก็จะเหมือนกับโหนดอื่น ๆ กระบวนการฉันทามติทั้งหมดประกอบด้วยขั้นตอนการเผยแพร่ข้อเสนอ (ระยะ PRE-PREPARE) และสองขั้นตอนที่เป็นเอกฉันท์ (ระยะ PREPARE, ระยะ COMMIT)

เตรียมเวที:

โหนดหลัก: 1) ตามข้อความ New-View ของโควรัมที่ได้รับ ซึ่งมีการจัดเตรียมQC ที่มีความสูงสูงสุดในแผนผังสถานะของผู้ส่ง โหนดหลักจะคำนวณ QC ความสูงสูงสุดจากการเตรียมQC

2) ตามสาขาที่ชี้ไปที่โหนดของ highQC นี้ ให้บรรจุบล็อกเพื่อสร้างโหนดต้นไม้ใหม่ และโหนดแม่ของมันคือโหนดที่ชี้ไปที่ highQC

3) ส่งข้อเสนอที่สร้างขึ้นไปยังโหนดทาสอื่น ๆ ในข้อความเตรียม และข้อเสนอปัจจุบันมี highQC

โหนดทาส: 1) หลังจากได้รับข้อความเตรียม ตรวจสอบข้อมูลในการเตรียม รวมทั้งความถูกต้องของลายเซ็นใน qc ไม่ว่าจะเป็นข้อเสนอของมุมมองปัจจุบัน

2) ไม่ว่าโหนดในข้อความเตรียมจะขยายจากสาขาของ lockQC (นั่นคือโหนดลูก) หรือจำนวนการดูของ highQC ในข้อความเตรียมนั้นมากกว่าของ lockQC (อันแรกคือเงื่อนไขความปลอดภัย และ หลังเป็นเงื่อนไขที่ใช้งานเพื่อให้แน่ใจว่าการซิงโครไนซ์ทันเวลาเมื่อโหนดล้าหลัง);

3) สร้างข้อความเตรียมการลงคะแนนและส่งไปยังโหนดหลักพร้อมลายเซ็น

ขั้นตอนก่อนกำหนด:

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

โหนดสเลฟ: โหนดอื่นๆ ได้รับข้อความก่อนคอมมิต และหลังจากตรวจสอบแล้ว ส่งข้อความโหวตล่วงหน้าไปยังมาสเตอร์โหนด

⚠️โปรดทราบว่า ณ เวลานี้ การเตรียม QC ใน pre-commit ที่ส่งโดยโหนดหลักจะระบุข้อความข้อเสนอในข้อความเตรียม และโหนดทั้งหมดโหวตเพื่อให้บรรลุฉันทามติได้สำเร็จ ช่วงเวลานี้คล้ายกับฉันทามติที่มาถึงในขั้น PREPARE ใน PBFT.

ขั้นตอนการกระทำ:

โหนดหลัก: คล้ายกับขั้นตอนก่อนการคอมมิต 1) โหนดหลักจะรวบรวมข้อความการลงคะแนนล่วงหน้าแบบโควรัมก่อน จากนั้นจึงรวมการควบคุมคุณภาพล่วงหน้าของขั้นตอนนี้ และส่งไปยังโหนดอื่นในข้อความการคอมมิต 2) ตั้งค่าล็อกคิวซีในเครื่องเป็น pre-commitQC

โหนดสเลฟ: เมื่อได้รับข้อความคอมมิต การตรวจสอบข้อความจะถูกส่งผ่านและ QC ที่ล็อกในเครื่องจะได้รับการอัปเดตเป็น pre-commitQC ในข้อความคอมมิต และมีการเซ็นชื่อและสร้างการโหวตคอมมิตและส่งไปยังโหนดหลัก

⚠️โปรดทราบว่า ณ เวลานี้ pre-commitQC ที่แนบมากับข้อความยืนยันที่ส่งโดยโหนดหลักนั้นคล้ายกับรอบที่สองของข้อตกลงเฟส COMMIT ใน PBFT ซึ่งฉันทามติของเฟสนี้ใน PBFT บ่งชี้ถึงฉันทามติของเฟสแรกของ คู่โหนดเพื่อบรรลุฉันทามติ นั่นคือเพื่อให้แน่ใจว่าอย่างน้อยโหนดองค์ประชุมได้เสร็จสิ้นขั้นตอน PREPARE และเมื่อการสลับมุมมองเกิดขึ้น โหนดที่เพียงพอสามารถพิสูจน์ได้ว่าบรรลุฉันทามติ PREPARE ในข้อเสนอและเนื้อหาของข้อเสนอต้องการ ที่จะส่งในมุมมองใหม่

ขั้นตอนการตัดสินใจ:

โหนดหลัก: 1) เมื่อมีการรวบรวมข้อความการโหวตคอมมิตองค์ประชุม คอมมิชชันQC จะถูกรวมและส่งไปยังโหนดอื่นในข้อความตัดสินใจ

2) เมื่อโหนดอื่นได้รับข้อความตัดสินใจ ธุรกรรมในข้อเสนอที่ชี้โดย commitQC จะถูกดำเนินการ

3) จากนั้นเพิ่มจำนวนการดู จำนวนการดู เริ่มฉันทามติรอบถัดไป และสร้างข้อความมุมมองใหม่ตามการเตรียมคิวซี

โหนดสเลฟ: หลังจากตรวจสอบข้อความแล้ว ให้ดำเนินการธุรกรรมของโหนดทรีที่ชี้ไปโดย commitQC ในข้อความตัดสินใจ

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

ข้อความ

▲ Chained HotStuff

พบว่ากระบวนการของแต่ละขั้นตอนใน Basic HotStuff นั้นคล้ายคลึงกันมาก ผู้เขียน HotStuff เสนอ Chained HotStuff เพื่อลดความซับซ้อนของประเภทข้อความของ Basic HotStuff และอนุญาตให้แต่ละขั้นตอนของ Basic HotStuff ประมวลผลธุรกรรมในลักษณะไปป์ไลน์

กระบวนการของ Chained HotStuff มีดังนี้:

ดังที่เห็นได้จากรูปภาพ แต่ละขั้นตอนจะสลับมุมมอง ดังนั้นข้อเสนอแต่ละข้อจึงมีมุมมองของตัวเอง โหนดอยู่ในมุมมองที่แตกต่างกันสำหรับข้อเสนอที่แตกต่างกัน การโหวตในขั้นตอน PREPARE จะถูกสังเคราะห์เป็น QC โดยโหนดหลักของมุมมองปัจจุบันและส่งต่อไปยังโหนดหลักของมุมมองถัดไป ดำเนินการต่อไปยังขั้นตอน PRE-COMMIT ของมุมมองก่อนหน้า แต่ละเฟสมีโครงสร้างที่คล้ายคลึงกัน และเฟส PREPARE ของมุมมอง v+1 สามารถถือเป็นระยะ PRE-COMMIT ของมุมมอง v ระยะ PREPARE ของมุมมอง v+2 ถือเป็นระยะ PRE-COMMIT ของมุมมอง v+1 และระยะ COMMIT ของมุมมอง v cmd1 ใน v1 จะดำเนินการขั้นตอน PREPARE, PRE-COMMIT และ COMMIT ในมุมมอง v1, v2 และ v3 ตามลำดับ และกระทำใน v4 cmd2 และอื่น ๆ การสร้างข้อเสนอ cmd ในแต่ละขั้นตอนจะมาพร้อมกับการโหวต QC ในขั้นตอนก่อนหน้า ขั้นตอนการทำงานของ HotStuff เวอร์ชันคล่องตัวมีดังนี้:

โหนดหลัก: 1) รอข้อความ NEW-VIEW และส่งข้อเสนอของตัวเอง

2) รอให้โหนดอื่นลงคะแนน

3) ส่งข้อความ NEW-VIEW ไปยังโหนดหลักถัดไป

โหนดสเลฟ: 1) รอข้อความข้อเสนอจากโหนดหลัก

2) ตรวจสอบ QC ในข้อเสนอ อัปเดต highQC ในพื้นที่ ล็อค QC และส่งคะแนนเสียง

3) ส่งข้อความ NEW-VIEW ไปยังโหนดหลักถัดไป

▲ Event-driven HotStuff

ตั้งแต่ HotStuff แบบเชื่อมโยงไปจนถึง HotStuff ที่ขับเคลื่อนด้วยเหตุการณ์ เอกสารต้นฉบับจะแยกความปลอดภัย (ความปลอดภัย) และความมีชีวิตชีวา (ความมีชีวิตชีวา) ของโปรโตคอลทั้งหมด และความมีชีวิตชีวาจะกลายเป็นโมดูลเครื่องกระตุ้นหัวใจที่แยกจากกัน โมดูลเครื่องกระตุ้นหัวใจรับประกันความพร้อมใช้งานหลังจาก Global Stability Time (GST) ให้สองฟังก์ชั่น:

• เลือกและตรวจสอบโหนดหลักสำหรับแต่ละมุมมอง

• ช่วย masternodes สร้างข้อเสนอ

กล่าวอีกนัยหนึ่ง ด้วยต้นทุนการเปลี่ยนมุมมองที่ต่ำ กลไกการหมุนของโหนดใดๆ ที่เหมาะสมและกลยุทธ์การสร้างข้อเสนอใดๆ สามารถนำมาใช้ในเครื่องกระตุ้นหัวใจได้

หลักการของ Hotstuff ที่ขับเคลื่อนด้วยเหตุการณ์และเวอร์ชันอื่นๆ ยังคงเป็นฉันทามติสามขั้นตอนหลัก ข้อแตกต่างคือความสะดวกในการใช้งานทางวิศวกรรมเท่านั้น สำหรับรายละเอียด โปรดดูรหัสเทียมของบทความ [4]

ชื่อเรื่องรอง

การเพิ่มประสิทธิภาพกลไกกิจกรรม

กลไกที่ใช้งานอยู่เป็นกุญแจสำคัญในการพัฒนาฉันทามติอย่างต่อเนื่อง ในบทความ HotStuff ต้นฉบับ กลไกความมีชีวิตชีวาใช้ไทม์เอาต์ที่สอดคล้องกันทั่วโลกเพื่อกำหนดไทม์เอาต์ของมุมมอง ใน NoxBFT เราได้ออกแบบกลไกที่ยืดหยุ่นมากขึ้นเพื่อรับมือกับความไม่เสถียรของสภาพแวดล้อมเครือข่าย

ชื่อเรื่องรอง

พูลบัฟเฟอร์ธุรกรรม

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

กลไกการกู้คืนอย่างรวดเร็ว

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

1) โหนดล้าหลังมาก และดึงบล็อกจากโหนดอื่นโดยตรงเพื่อกู้คืนไปยังจุดตรวจสอบล่าสุด

2) ความคืบหน้าเป็นเอกฉันท์หลังจากจุดตรวจสอบล้าหลัง และ CommitQC ล่าสุดถูกดึงมาจากโหนดอื่นๆ เพื่อเรียกคืนความคืบหน้าที่เป็นเอกฉันท์อย่างรวดเร็ว

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

ลายเซ็นรวม

สรุป

สรุป

เกี่ยวกับผู้เขียน

เกี่ยวกับผู้เขียน

เฉิงไท่หนิง

อ้างอิง

อ้างอิง

[1] Schneider F B . The state machine approach: A tutorial[J]. Springer New York, 1990.

[2] Lamport L ,  Shostak R ,  Pease M . The Byzantine Generals Problem[J]. ACM Transactions on Programming Languages and Systems, 1982, 4(3).

[3] Castro M, Liskov B. Practical Byzantine fault tolerance[C]. OSDI.1999, 99(1999): 173-186.

[4] Yin M ,  Malkhi D ,  Reiter M K , et al. HotStuff: BFT Consensus in the Lens of Blockchain[J].  2018.

[5] Shoup V . Practical Threshold Signatures[C]// International Conference on Theory & Application of Cryptographic Techniques. Springer-Verlag, 2000.