ETH2.0 กำลังจะมา คุณไม่รู้แคสเปอร์หรือยัง? (สอง)
มีอยู่มีอยู่ใน เราแนะนำ Casper FFG ในเอกสารต้นฉบับของ Vitalik ซึ่งใช้ PoS เพื่อยืนยันบล็อกที่สร้างโดย PoW เพื่อปรับปรุงความปลอดภัยของระบบ แต่นี่เป็นเพียงโซลูชันชั่วคราวเท่านั้น และ PoS บริสุทธิ์จะถูกใช้ใน Ethereum 2.0 โปรโตคอล Casper บทความนี้จะแนะนำโปรโตคอล Casper ที่จะใช้ใน Ethereum 2.0
ชื่อเรื่องรอง
อันดับแรก เรามาดูกันว่าสถาปัตยกรรมของ Ethereum 2.0 เป็นอย่างไร ดังแสดงในรูปที่ 1 จะมีเชนหลักที่เรียกว่า Beacon chain ใน Ethereum 2.0 ซึ่งสร้างผ่าน PoS Casper ภายใต้ห่วงโซ่สัญญาณมีชิ้นส่วน 1,024 ชิ้น และชิ้นส่วนแต่ละชิ้นสามารถประมวลผลข้อมูลได้อย่างอิสระ
คำอธิบายภาพ
รูปที่ 1 สถาปัตยกรรมของ Ethereum 2.0
ดังที่เห็นได้จากรูปที่ 1 Ethereum 2.0 และ Ethereum 1.0 จะเป็น 2 chains หลังจากรับรู้ 2.0 shard แล้ว 1.0 จะยังคงทำงานเป็น shard ของ Ethereum 2.0 ในบทความที่แล้ว เราแนะนำว่า คุณสามารถเป็น Validator เพื่อเข้าร่วมฉันทามติ PoS ได้โดยการจำนอง Stake เพื่อให้ Ethereum เปลี่ยนไปเป็น 2.0 อย่างราบรื่น วิธีการเป็น Validator ใน Ethereum 2.0 โดยการจำนอง Stake ใน Ethereum 1.0 คือ Casper An ปัญหาสำคัญที่ต้องได้รับการแก้ไข
ในการเป็น Validator ผู้ใช้จะต้องส่งธุรกรรมไปยังสัญญาพิเศษใน Ethereum 1.0 ก่อนเพื่อจำนอง ETH จำนวนหนึ่ง (ปัจจุบันมูลค่าขั้นต่ำคือ 32ETH) จากนั้นผู้ใช้จะได้รับหลักฐานการทำธุรกรรม เมื่อแสดงหลักฐานนี้กับ Ethereum 2.0 ผู้ใช้จะกลายเป็น Validator หลังจากผ่านการตรวจสอบ ดังแสดงในรูปที่ 2:คำอธิบายภาพ
รูปที่ 2 การจำนอง ETH ใน Ethereum 1.0 เพื่อเป็นกระบวนการ Validator ใน Ethereum 2.0เพื่อตรวจสอบความถูกต้องของการทำธุรกรรมจำนองของผู้ใช้ Ethereum 2.0 จำเป็นต้องบันทึกข้อมูลการบล็อกใน Ethereum 1.0 ปัจจุบันและแฮชรูทของ Merkle ซึ่งประกอบด้วยธุรกรรมปัจจุบันทั้งหมดในสัญญาจำนองการพิสูจน์ต้น Merkle ที่สมบูรณ์สามารถตรวจสอบความถูกต้องของธุรกรรมสกุลเงินได้ ผู้ใช้ที่ได้รับการยืนยันกลายเป็นผู้ตรวจสอบความถูกต้องใน Ethereum 2.0
ชื่อเรื่องรอง
กระบวนการสร้างบล็อกของ Capser ใน Ethereum 2.0
ในบทความที่แล้ว เราแนะนำ Casper ในการสร้างบล็อกผ่าน PoW และใช้ PoS เพื่อจบบล็อก ดังนั้นปัญหาที่ต้องแก้ไขสำหรับ PoS Casper ล้วนๆ คือวิธีสร้างบล็อก ก่อนที่จะแนะนำกระบวนการโปรโตคอลอย่างเป็นทางการ ให้เราอธิบายคำจำกัดความสองสามข้อ:
คอลเลกชัน Validators: V = V1 ... Vn โดยถือว่า Validator แต่ละตัวมีส่วนได้ส่วนเสียเท่ากัน
slot: หน่วยเวลาพื้นฐาน ปัจจุบันตั้งค่าเป็น 6s;
ยุค: 64 ช่องในรูปแบบยุค;
คำอธิบายภาพ
รูปที่ 3 กระบวนการฉันทามติของ Casper ใน Ethereum 2.0
1. ในตอนต้นของแต่ละยุค จะมีการสร้างตัวเลขสุ่มโดยเครื่องสร้างตัวเลขสุ่ม และชุด Validator V จะแบ่งออกเป็น 64 ส่วนโดยเฉลี่ยเพื่อให้ได้ S1, S2, ..., S64
2. ในยุคนั้น แต่ละช่อง i เลือก Validator ใน Si เพื่อส่งบล็อกตัวเลือกตามหมายเลขสุ่มที่สร้างขึ้นในขั้นตอนที่ 1 และเขียนตัวตรวจสอบความถูกต้องส่งบล็อกตัวเลือกในช่อง i เป็น offerr_i และบล็อกตัวเลือกที่ส่งเขียน B_i .
3. สำหรับแต่ละช่อง i ผู้ตรวจสอบความถูกต้องที่เหลืออยู่ใน Si ยกเว้น ผู้เสนอ_i ลงคะแนนให้ B_i และการลงคะแนนจะถูกเขียนเป็นการรับรอง5. สำหรับแต่ละสล็อต i หลังจากได้รับบล็อก (B_i) ของสล็อต i หรือรอเป็นเวลา 3 วินาที Validator ที่เหลืออยู่ใน Si ยกเว้น offerr_i จะเผยแพร่ส่วนหัวของห่วงโซ่ปัจจุบันในมุมมองของเขา
LMD GHOST（Lastest Message Driven GHOST）
ชื่อเรื่องรอง
ก่อนที่จะแนะนำอัลกอริธึมการเลือกเชนที่เหมาะสมที่สุดใหม่นี้ ให้เราระลึกถึงอัลกอริธึมการเลือกเชนที่เหมาะสมที่สุดของ Ethereum 1.0 - GHOST แนวคิดหลักของอัลกอริทึม GHOST คือสำหรับ blockchain จะมีการสร้าง fork จำนวนมากเนื่องจากการหน่วงเวลาและการมีอยู่ของโหนดที่เป็นอันตราย เมื่อพบ fork ความยากสูงสุดของทรีย่อยจะถูกเลือกเป็นเชนที่เหมาะสมที่สุด ดังแสดงในรูปที่ 4 :
คำอธิบายภาพ
รูปที่ 4 โปรโตคอล GHOST
ไม่มีปัญหากับโปรโตคอล GHOST ในโปรโตคอล PoW แต่โปรโตคอล PoS ได้รับผลกระทบจากการโจมตีแบบ Lang Range โดยธรรมชาติ กล่าวคือ ผู้โจมตีสามารถใช้เงินจำนวนเล็กน้อยเพื่อซื้อบัญชีที่ครั้งหนึ่งเคยมีเงินเดิมพันจำนวนมาก แต่ปัจจุบันยังว่างเปล่า ย้อนอดีต และดำเนินธุรกรรมในตำแหน่งที่ผ่านมา Fork สร้างบล็อกที่ผิดกฎหมายจำนวนมาก และโปรโตคอล GHOST จะไม่สามารถรับประกันความปลอดภัยของระบบได้ ดังแสดงในรูปที่ 5:คำอธิบายภาพ
รูปที่ 5: ช่วง Lang
ผู้โจมตีสร้างบล็อกสีเหลืองในตำแหน่งที่ผ่านมา ความยากทั้งหมดของทรีย่อย B คือ 10 และบล็อกสีม่วงจะกลายเป็นจุดบนเชนที่เหมาะสมที่สุด แม้ว่าโทเค็นจะต้องถูกจดจำนองก่อนลงคะแนน แต่หลังจากแลกโทเค็นของตนเองแล้ว ผู้โจมตีสามารถกระทำการโดยประมาทในยุคตรวจสอบโดยไม่ต้องกังวลเกี่ยวกับการยึดโทเค็น
ดังนั้นเพื่อแก้ปัญหานี้ Ethereum 2.0 จึงออกแบบอัลกอริทึมใหม่ - LMD GHOST (GHOST ข้อความล่าสุดที่ขับเคลื่อนด้วย) แนวคิดหลักของ LMD GHOST คือ สำหรับห่วงโซ่ที่มีทางแยก เมื่อพบจุดทางแยกในกระบวนการค้นหาส่วนหัวของห่วงโซ่ ให้เลือกแผนผังย่อยที่รองรับตัวตรวจสอบความถูกต้องเพิ่มเติมในยุคปัจจุบัน กระบวนการหลักของข้อตกลงคือ:
สำหรับห่วงโซ่ที่มีส้อม:
2、M=[M1,…,1. H เท่ากับบล็อกการสร้าง
Mn] เป็นข่าวล่าสุดจาก Validator;
3. เลือกโหนดลูกที่ได้รับการสนับสนุนมากที่สุดใน M และตั้งค่าเป็น H
4. ทำซ้ำขั้นตอน (2-3) จนกว่าจะไม่มีโหนดย่อย
จนถึงตอนนี้ เราได้แนะนำวิธีการที่ Casper ใน Ethereum 2.0 สร้างบล็อก และส่วนต่อไปคือวิธีทำให้บล็อกตัวเลือกสุดท้ายเสร็จสมบูรณ์
ชื่อเรื่องรอง
การยืนยันการบล็อก
ในบทความที่แล้ว เราได้อธิบายจุดตรวจที่สมเหตุสมผลและจุดสิ้นสุดแล้ว และโหนดก่อนจุดตรวจที่สรุปผลจะได้รับการยืนยันในที่สุด กล่าวโดยสรุป Casper ใน Ethereum 2.0 ถือว่าแต่ละยุคเป็นจุดตรวจสอบและการรับรองจะลงคะแนนเสียงในจุดตรวจสอบเพื่อกำหนดสถานะที่สมเหตุสมผลและสิ้นสุดของจุดตรวจสอบ ตรรกะหลัก ๆ ของการพิจารณาที่สมเหตุสมผลและสิ้นสุดนั้นคล้ายกับที่อธิบายไว้ข้างต้น ต่อไป เรามาอธิบายว่าบล็อกเข้าสู่สถานะที่เป็นธรรมและสิ้นสุดได้อย่างไร
วิธีปรับบล็อกตอนนี้แคสเปอร์แบ่งยุคออกเป็น 64 ช่อง ช่องสุดท้ายเรียกว่า epoch_boundary_slot และแฮชของมันถูกเขียนเป็น epoch_boundary_hash เพื่อแทนยุค และยุคนั้นถือเป็นจุดตรวจสอบ ให้ห่วงโซ่รักษาแผนที่ เราเรียกว่า justified_hashes รูปแบบการจัดเก็บคือ
. เพิ่มสองฟิลด์ epoch_boundary_hash (แฮชของบล็อกที่มีสล็อตเล็กที่สุดในยุคก่อนหน้า) และ latest_justified_hash (แฮชของบล็อกล่าสุดในยุค เท่ากับสล็อตใน justified_hashes เฉพาะแฮชล่าสุด การรับรองนี้ถูกกฎหมายห่วงโซ่จะติดตามแฮชที่สมเหตุสมผลล่าสุด ดังนั้นการเลือก epoch_boundary_hash เดียวกันจะเป็นการโหวตสำหรับ latest_justified_hash เดียวกัน ทีนี้มาดูกันว่าสภาวะเปลี่ยนผ่านระหว่างขอบเขตยุคอย่างไร สมมติว่าเป็นห่วงโซ่ epoch_boundary_block B1, B2, B3, B4 ของ 4 ยุคสุดท้าย โดยที่ B4 เป็น epoch_boundary_block ล่าสุดของยุคนั้น และช่องจะถูกเขียนเป็น B1_slot, B2_slot, B3_slot, B4_slot, B3_slot = B4_slot - 64, เป็นต้น หากมากกว่า 2/3 ของ Validators เลือก B4 เป็น epoch_boundary_block ให้ใส่
เพิ่ม justified_hashes
เงื่อนไขสำหรับ epoch_boundary_block ที่จะถูกพิสูจน์คือมากกว่า 2/3 ของ Validators ชี้ไปที่บล็อกในการรับรอง epoch_boundary_hash เมื่อมีการรวมบล็อกใน justified_hashes บล็อกนั้นจะได้รับการพิสูจน์ และสถานะที่พิสูจน์ว่าบล็อกนั้นมีอยู่แล้ว ความชอบธรรมถูกบันทึกไว้ในสายโซ่ที่เหนือกว่า
วิธีจบบล็อก
หลังจากยืนยันสถานะที่ถูกต้องแล้ว ขั้นตอนต่อไปคือการกำหนดวิธีทำให้บล็อกเข้าสู่สถานะสุดท้าย
หาก B4 และ B3 อยู่ใน justified_hashes การยืนยันที่โหวตให้ B4 เป็น epoch_boundary_block จะเลือก B3 เป็น latest_justified_hash และสรุป B3
ถ้า B4, B3 และ B2 อยู่ใน justified_hashes ให้โหวตให้ B4 เป็นการรับรองของ epoch_boundary_block เลือก B2 เป็น latest_justified_hash และจบ B2
ถ้า B3, B2 และ B1 อยู่ใน justified_hashes ให้โหวตให้ B3 เป็นการยืนยัน epoch_boundary_block เลือก B1 เป็น latest_justified_hash และจบ B1คุณสามารถถือว่า epoch_boundary_block เป็น h(t) และ latest_justified_hash เป็น h(s) ซึ่งทำให้เข้าใจขั้นตอนการยืนยันของบล็อกได้ง่ายขึ้น
ชื่อเรื่องรอง
สิ่งเล็กน้อยอื่น ๆ
สำหรับการทำงานที่สมบูรณ์ของ Casper ยังมีสิ่งเล็ก ๆ น้อย ๆ ที่ต้องแก้ไข เนื่องจากพื้นที่ค่อนข้างสั้นเรามารวมเข้าด้วยกัน
เงื่อนไขการลงโทษ
เพื่อป้องกันการสังเกตจากการโจมตี Stake ผู้ใช้จำนองโทเค็นเพื่อเป็น Validator สำหรับ PoS เมื่อ Validator ทำงานอย่างผิดกฎหมาย Token ที่จำนองไว้จะถูกยึดเพื่อป้องกันไม่ให้ผู้ไม่ประสงค์ดีทำสิ่งชั่วร้าย เงื่อนไขการลงโทษของ Validator คือ:
1. Validator คนเดียวกันไม่สามารถออกคำรับรองที่แตกต่างกันสองฉบับในยุคเดียวกันได้ 2. Validator เดียวกันไม่สามารถออกใบรับรองสองรายการได้ epoch_boundary_blocks คือ t1 และ t2 ตามลำดับ latest_justified_hash คือ s1 และ s2 และ s1
เงื่อนไขการลงโทษนี้เหมือนกับเงื่อนไขการลงโทษในข้อที่แล้ว
เงื่อนไขการเปลี่ยนตัวตรวจสอบความถูกต้อง
ราชวงศ์ (B) ระบุจำนวนยุคสุดท้ายตั้งแต่บล็อก B ถึงบล็อกกำเนิด 1/64 Validator สามารถเปลี่ยนระหว่างสองราชวงศ์ได้
เงื่อนไขการเลือกส้อม
เริ่มต้นจากบล็อกที่สรุปล่าสุด ดำเนินการ LMD GHOST
