Beacon Chain Validators: ความเสี่ยงด้านความซ้ำซ้อนและความล้มเหลว

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้เขียน: Aditya Asgaonkar แปล: A Jian พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต

ชื่อระดับแรก

Validator และ Validator Clients

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

Validator จำเป็นต้องใช้ซอฟต์แวร์ที่เรียกว่า Validator Client (VC) เพื่อทำหน้าที่ของตน1. ทีมไคลเอนต์บีคอนเชนทั้งหมดใช้ VC เป็นหนึ่งในแพ็คเกจซอฟต์แวร์ไคลเอ็นต์ของตน

• จำเป็นต้องพูด Validators ต้องการให้ลูกค้าของพวกเขาออนไลน์ตลอด 24/7 เพื่อให้พวกเขาได้รับประโยชน์สูงสุดและหลีกเลี่ยงการลงโทษทั้งหมด วิธีทั่วไปในการบรรลุความพร้อมใช้งานสูงคือการตั้งค่ากลไกสำรองและเฟลโอเวอร์ บทความนี้จะอธิบายถึงอันตรายของความซ้ำซ้อนต่อตัวตรวจสอบความถูกต้อง และเสนอทางเลือกที่สมเหตุสมผลสำหรับ VCs ในบีคอนเชน
• ประเภทของการสูญเสีย / การลงโทษ
• Validators เผชิญกับการสูญเสียสามประเภท ตามลำดับความรุนแรงจากน้อยไปหามาก:

ความผิดหวังของรางวัล: เมื่อตัวตรวจสอบล้มเหลวในการดำเนินการเมื่อได้รับมอบหมายงาน TA จะไม่สามารถรับรางวัลที่เกี่ยวข้องกับงานได้ ส่วนของผู้ตรวจสอบความถูกต้อง (เงินต้น) จะไม่ลดลง แต่สูญเสียโอกาสที่จะได้รับรางวัลบทลงโทษการทำงานช้า: หากผู้ตรวจสอบไม่ส่งข้อความพยาน และสายสัญญาณไม่สามารถปิดบล็อค 2 ได้ในเวลานั้น ส่วนของผู้ตรวจสอบจะลดลงเล็กน้อย (แน่นอนว่าจะไม่ได้รางวัลที่เกี่ยวข้อง)การลงโทษอย่างเจ็บแสบ: หากผู้ตรวจสอบส่งข้อความพยานที่ละเมิดกฎของ Casper FFG ผู้ตรวจสอบจะถูกฟันทันที - ส่วนของผู้ตรวจสอบความถูกต้องจะลดลงตามอัตราส่วน 3 และผู้ตรวจสอบความถูกต้องจะถูกไล่ออกและไม่สามารถใช้ได้อีก เข้าร่วมใน ฉันทามติ (และตัดออกจากรางวัลในอนาคตด้วย) ยิ่งไปกว่านั้น เนื่องจาก beacon chain ไม่สามารถโอนและดึง ETH ที่จำนำไว้ได้ เงินที่เหลือทั้งหมดของผู้ตรวจสอบจะถูกล็อคไว้ที่ beacon chain และไม่สามารถใช้งานได้ (จนกว่า beacon chain จะเปิดใช้ฟังก์ชันที่เกี่ยวข้อง)

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

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

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

มาดูตัวอย่างที่ใช้งานได้จริง:

คำอธิบายภาพ

- VC ซ้ำซ้อนนำไปสู่การเชือด! -โปรโตคอลเฟลโอเวอร์ของ VC

หมายเหตุ: เมื่อฉันพูดว่า "เฟลโอเวอร์" ฉันหมายถึงการรีสตาร์ทอินสแตนซ์ VC ใหม่ด้วยตนเองหรือโดยอัตโนมัติหลังจากที่ VC หยุดทำงาน อย่างไรก็ตาม ฉันไม่แนะนำให้ใช้กลไกเฟลโอเวอร์อัตโนมัติ เพราะหากใช้งานไม่ดี อาจทำให้คุณมี VC สองตัว ห้อยต่องแต่ง!

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

• - กลไกป้องกันการเฉือน -
• กลไกป้องกันการสแลช: ซอฟต์แวร์ VC ทั้งหมดที่พัฒนาโดยทีมไคลเอ็นต์บีคอนเชนมีกลไกป้องกันการสแลชเป็นอุปกรณ์ป้องกันข้อผิดพลาดอัตโนมัติสำหรับเหตุการณ์ที่ไม่คาดคิด ตามกฎการทับศัพท์ ข้อความรับรองคู่เดียวเท่านั้นที่จะทำให้เกิดการทับ จำเป็นต้องตรวจสอบข้อความคู่นี้เท่านั้นจึงจะตัดสินผลลัพธ์ได้ จากนั้น VC สามารถจัดเก็บข้อความและบล็อกทั้งหมดที่ลงนามด้วยตัวเองในฐานข้อมูล Slash Protection ในเครื่อง เมื่อลงนามข้อความ/บล็อกการรับรองใหม่ VC จำเป็นต้องตรวจสอบว่าข้อความใหม่ขัดแย้งกับข้อความเก่าในฐานข้อมูลหรือไม่ (ไม่ว่าจะเป็นคู่ข้อความแบบเฉือน) และเซ็นชื่อเฉพาะข้อความใหม่ที่ไม่ขัดแย้งกัน
• ดังนั้น VC จึงต้องการกลไกสามอย่างเพื่อให้แน่ใจว่าการทำงานถูกต้องและปลอดภัย:

Beacon Chain Node (BN) ที่ซิงโครไนซ์อย่างสมบูรณ์เพื่อรับข้อมูลเกี่ยวกับ Beacon Chainผู้ตรวจสอบลงนามคีย์ส่วนตัวเพื่อลงนามในข้อความจริงการฟันอย่างทันท่วงทีจะปกป้องฐานข้อมูลแบบป้องกันข้อผิดพลาด

โปรโตคอลเฟลโอเวอร์ที่ดีต้องคำนึงถึงความล้มเหลวของกลไกอย่างใดอย่างหนึ่ง สองอันแรกรับประกันได้ง่าย - สามารถรักษา BN ที่ซ้ำซ้อนสำหรับการเชื่อมต่อ VC ใหม่ได้ และยังสามารถคัดลอกคีย์การเซ็นชื่อจากโฟลเดอร์สำรองเป็นไฟล์แบบอ่านอย่างเดียว

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

โซลูชันล้มเหลวที่แนะนำของฉัน

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

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

ข้อผิดพลาด BN - จากนั้นย้ายไปยัง BN ที่ซ้ำซ้อน

ไฟล์คีย์ตัวตรวจสอบความถูกต้องหายไป - คัดลอกมาจากไฟล์คีย์สำรองของ Cold Storageการสูญเสียฐานข้อมูลที่มีการป้องกันแบบสแลช - สร้างฐานข้อมูลใหม่หรือกู้คืนจากการสำรองข้อมูลแบบสดhttps://youtu.be/awBX1SrXOhk。ตัวตรวจสอบการแบ่งคีย์(เช่น: วิธีที่ถูกต้องในการนำเครื่องมือตรวจสอบความถูกต้องแบบยืดหยุ่นไปใช้)โครงสร้างพื้นฐานที่ยืดหยุ่นได้อย่างเหมาะสมต้องใช้เทคนิคการแยกคีย์ ซึ่งเป็นอีกบทความหนึ่ง สามารถดูข้อมูลเพิ่มเติมได้ในวิดีโอพูดคุยนี้: