การควบรวมกิจการของ Ethereum: อะไรคือความเสี่ยงในการใช้งานไคลเอนต์หลายเครื่อง?

แปลต้นฉบับ: บล็อกยูนิคอร์น

แปลต้นฉบับ: บล็อกยูนิคอร์น

ขอขอบคุณเป็นพิเศษสำหรับ Vitalik Buterin (V God), Hsiao-Wei Wang, Caspar Schwarz-Schilling สำหรับข้อเสนอแนะและคำวิจารณ์

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

ทำไมเราต้องการลูกค้าหลายราย

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

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

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

มาดูกันว่าจะเกิดอะไรขึ้นเมื่อเรามีลูกค้าหลายราย มีสองสถานการณ์ที่เป็นไปได้:

1.ลูกค้าที่มีช่องโหว่มีสัดส่วนน้อยกว่า 50% ของการเดิมพันลูกค้าจะสร้างบล็อกที่มีธุรกรรมที่ใช้ประโยชน์จากข้อบกพร่อง พิมพ์ ETH เรียกเชนนี้ว่าA。

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

อย่างไรก็ตาม staker ส่วนใหญ่ที่เรียกใช้ไคลเอ็นต์ที่ไม่มีข้อผิดพลาดจะไม่สนใจบล็อกนี้เนื่องจากบล็อกนี้ไม่ถูกต้อง (สำหรับพวกเขา การพิมพ์การดำเนินการ ETH นั้นไม่ถูกต้อง) พวกเขาจะสร้างเชนสำรอง B ที่ไม่มีบล็อกที่ไม่ถูกต้อง

เนื่องจากลูกค้าที่ถูกต้องเป็นส่วนใหญ่ B-chain จะสะสมหลักฐานมากขึ้น ดังนั้น แม้แต่ลูกค้าที่มีปัญหาก็ยังโหวตให้เชน B ผลคือเชน B จะสะสมคะแนนเสียงได้ 100% และเชน A จะตาย ห่วงโซ่จะดำเนินต่อไปราวกับว่าข้อผิดพลาดไม่เคยเกิดขึ้น

2.หุ้นที่เดิมพันส่วนใหญ่ใช้ไคลเอนต์ที่มีบั๊กกี้ในกรณีนี้คือโซ่Aจะได้คะแนนเสียงข้างมาก แต่เนื่องจากBน้อยกว่า 50% ของการพิสูจน์ทั้งหมด ลูกค้าที่ละเมิดจะไม่เห็นห่วงโซ่ทาสAเปลี่ยนเป็นโซ่Bเหตุผล. ดังนั้นเราจะเห็นการแตกของโซ่

กรณีที่ 1 เป็นกรณีที่เหมาะที่สุด เนื่องจากสิ่งนี้มักจะส่งผลให้เกิดบล็อกที่ถูกละเลย และผู้ใช้ส่วนใหญ่จะไม่สังเกตเห็นด้วยซ้ำ นักพัฒนาซอฟต์แวร์สามารถดีบักไคลเอ็นต์ แก้ไขข้อบกพร่อง และคุณก็พร้อมดำเนินการ ในทางตรงกันข้าม กรณีที่ 2 มีอุดมคติน้อยกว่าอย่างชัดเจน แต่ก็ยังดีกว่าไคลเอนต์เพียงรายเดียว - ส่วนใหญ่จะตรวจจับการแยกเชนได้อย่างรวดเร็ว (คุณสามารถทำให้สิ่งนี้เป็นอัตโนมัติได้ด้วยการรันไคลเอนต์หลายตัว) การแลกเปลี่ยนจะระงับการฝากอย่างรวดเร็ว และผู้ใช้ Defi สามารถรอการแยกเพื่อดำเนินการต่อด้วยความระมัดระวัง โดยพื้นฐานแล้ว สิ่งนี้ยังคงให้ไฟเตือนสีแดงกะพริบสำหรับผลลัพธ์ที่เลวร้ายที่สุดเมื่อเทียบกับสถาปัตยกรรมไคลเอ็นต์เดียว

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

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

การสร้างแรงจูงใจในความหลากหลายของลูกค้า: บทลงโทษการต่อต้านความสัมพันธ์

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

ขออภัย เราไม่สามารถทำให้รางวัลขึ้นอยู่กับไคลเอ็นต์ที่ตัวตรวจสอบกำลังทำงานอยู่ได้โดยตรง ไม่มีวิธีการที่เป็นกลางในการวัดสิ่งนี้ที่ไม่สามารถหลอกได้

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

ใน ether คุณสามารถถูกแฮ็กได้จากสองพฤติกรรม:

1. ลงชื่อเข้าใช้สองช่วงตึกที่มีความสูงเท่ากัน

2. สร้างคู่ของหลักฐานที่ตัดได้ (การลงคะแนนแบบเซอร์ราวด์หรือการลงคะแนนสองครั้ง)

เมื่อคุณถูกเฉือน คุณมักจะไม่สูญเสียเงินทั้งหมด ในขณะที่เขียน (Altair Fork) ค่าปรับเริ่มต้นค่อนข้างน้อย: คุณจะเสียเพียง 0.5ETH หรือ 1.5% ของ Ether ที่คุณเดิมพัน (ซึ่งในที่สุดจะเพิ่มเป็น 1ETH หรือ 3%)

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

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

การลงโทษต่อต้านความสัมพันธ์อื่น: การรั่วไหลของการใช้งานกำลังสอง

อีกวิธีหนึ่งที่ทำให้ Validator ล้มเหลวคือออฟไลน์ อีกครั้งนี้มีโทษ แต่กลไกต่างกันมาก เราไม่เรียกว่าการเฆี่ยนตี และมักจะเป็นเรื่องเล็กน้อย: ภายใต้การทำงานปกติ ผู้ตรวจสอบความถูกต้องที่ออฟไลน์จะถูกลงโทษแบบเดียวกับที่พวกเขาจะได้รับหากตรวจสอบความถูกต้องครบถ้วน ในขณะที่เขียนนี้ นั่นคืออัตราการเติบโตต่อปีที่ 4.8% หากตัวตรวจสอบความถูกต้องของคุณออฟไลน์เป็นเวลาหลายชั่วโมงหรือหลายวัน เช่น เนื่องจากอินเทอร์เน็ตขัดข้องชั่วคราว ก็คงไม่คุ้มที่จะเสียเหงื่อ
สิ่งต่าง ๆ เปลี่ยนไปอย่างมากเมื่อตัวตรวจสอบความถูกต้องมากกว่า 1 ใน 3 ออฟไลน์ จากนั้นห่วงโซ่บีคอนก็ล้มเหลวในการสรุป ซึ่งเป็นการคุกคามคุณสมบัติพื้นฐานของระเบียบการฉันทามติ ซึ่งก็คือความมีชีวิตชีวา
เพื่อคืนความอ่อนเยาว์ในสถานการณ์เช่นนี้ สิ่งที่เรียกว่า "การรั่วไหลที่ไม่มีการใช้งานรอง" เข้ามามีบทบาท หากตัวตรวจสอบยังคงออฟไลน์ต่อไปในขณะที่เชนไม่สมบูรณ์ ค่าปรับทั้งหมดจะเพิ่มขึ้นเป็นสองเท่าเมื่อเวลาผ่านไป เริ่มแรกจะต่ำมาก หลังจากนั้นประมาณ 4.5 วัน ผู้ตรวจสอบแบบออฟไลน์จะสูญเสีย 1% ของเงินเดิมพัน อย่างไรก็ตาม มันเพิ่มขึ้นเป็น 5% หลังจาก ~10 วัน และ 20% หลังจาก ~21 วัน (นี่คือมูลค่าของ Altair ซึ่งจะเพิ่มเป็นสองเท่าในอนาคต)

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

การใช้งานไคลเอนต์ส่วนใหญ่นั้นแย่แค่ไหน?

เพื่อให้เข้าใจถึงอันตราย ลองมาดูประเภทความล้มเหลวสามประเภท:

1. Mass slashing event: โปรแกรมตรวจสอบไคลเอ็นต์ส่วนใหญ่ลงนามในหลักฐาน slashable เนื่องจากข้อผิดพลาด

2. เหตุการณ์ออฟไลน์จำนวนมาก: เนื่องจากข้อผิดพลาด ตัวตรวจสอบไคลเอนต์ส่วนใหญ่ทั้งหมดจึงออฟไลน์

3. เหตุการณ์การบล็อกไม่ถูกต้อง: เนื่องจากข้อผิดพลาด โปรแกรมตรวจสอบไคลเอนต์ส่วนใหญ่พิสูจน์ได้ว่ามีการบล็อกที่ไม่ถูกต้อง

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

สถานการณ์ที่ 1: ลายเซ็นคู่

นี่อาจเป็นสถานการณ์ที่ผู้ดำเนินการตรวจสอบความถูกต้องกลัวมากที่สุด: จุดบกพร่องที่ทำให้ไคลเอนต์ตรวจสอบความถูกต้องลงนามในหลักฐานที่สามารถลบได้ ตัวอย่างคือผู้พิสูจน์สองคนลงคะแนนให้เป้าหมายยุคเดียวกัน แต่มีเพย์โหลดต่างกัน เนื่องจากนี่เป็นข้อผิดพลาดของลูกค้า ข้อกังวลจึงไม่ใช่แค่ staker รายเดียว แต่เป็น staker ทั้งหมดที่เรียกใช้ไคลเอนต์นี้โดยเฉพาะ เมื่อพบความกำกวมเหล่านี้ ก็จะกลายเป็นการนองเลือด: เซียนพนันที่เกี่ยวข้องทั้งหมดจะเสียเงิน 100% ของเงินเดิมพัน นี่เป็นเพราะเรากำลังพิจารณาลูกค้าหลายราย: หากลูกค้าที่มีปัญหาเดิมพันเพียง 10% ของเงินเดิมพันของพวกเขา ดังนั้น "เพียง" 20% ของเงินเดิมพันจะถูกเฉือน (ใน Altair; 30% และตั้งค่าพารามิเตอร์การลงโทษขั้นสุดท้าย)

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

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

สถานการณ์ที่ 2: กิจกรรมออฟไลน์ขนาดใหญ่

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

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

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

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

สถานการณ์ที่ 3: บล็อกข้อมูลไม่ถูกต้อง

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

1. ไคลเอนต์ที่ทำงานทั้งหมดจะละเว้นการบล็อกที่ไม่ถูกต้องและสร้างบนส่วนหัวที่ถูกต้องล่าสุดแทนซึ่งสร้างเชน B แยกต่างหาก ลูกค้าที่ทำงานทั้งหมดจะโหวตและสร้างเครือข่าย B

2. ลูกค้าที่ผิดพลาดคิดว่าทั้งสาย A และ B ถูกต้อง ดังนั้นจะโหวตเลือกสายใดในสองสายที่คิดว่าหนักที่สุดในขณะนี้

เราต้องแยกแยะสามกรณี:

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

2. ลูกค้าที่มีช่องโหว่ถือหุ้นเกินครึ่งแต่น้อยกว่าสองในสามของสัดส่วนการถือหุ้นในตัวอย่างนี้ เราจะเห็นการสร้างเชนสองรายการ - A โดยไคลเอ็นต์ที่มีจุดบกพร่อง และ B โดยไคลเอ็นต์อื่นๆ ทั้งหมด ห่วงโซ่ทั้งสองไม่มีเสียงข้างมากสองในสาม ดังนั้นจึงไม่สามารถสรุปผลได้ เมื่อสิ่งนี้เกิดขึ้น นักพัฒนาจะต้องพยายามทำความเข้าใจว่าเหตุใดจึงมีสองเชน เมื่อพวกเขาพบว่ามีบล็อกที่ไม่ถูกต้องในเชน A พวกเขาสามารถดำเนินการแก้ไขไคลเอนต์บั๊กกี้ได้ เมื่อแก้ไขแล้ว ระบบจะจดจำเชน A ว่าไม่ถูกต้อง ดังนั้นมันจะเริ่มสร้างบนเชน B ซึ่งจะทำให้สามารถสรุปได้ สิ่งนี้ก่อกวนผู้ใช้อย่างมาก แม้ว่าความสับสนว่าห่วงโซ่ใดถูกต้องจะเกิดขึ้นในระยะเวลาสั้นๆ แต่ไม่ถึงหนึ่งชั่วโมง แต่ห่วงโซ่อาจไม่ได้รับการสรุปเป็นเวลาหลายชั่วโมงหรือแม้แต่วันเดียว แต่สำหรับผู้ผลิต แม้แต่ผู้ที่ดำเนินการกับลูกค้าที่มีปัญหา บทลงโทษยังคงค่อนข้างเบา หากพวกเขาไม่ได้เข้าร่วมในเชน B ในขณะที่สร้างเชน A ที่ไม่ถูกต้อง พวกเขาจะถูกลงโทษด้วย "การรั่วไหลที่ไม่ใช้งาน" อย่างไรก็ตาม เนื่องจากอาจใช้เวลาน้อยกว่าหนึ่งวัน เรากำลังพูดถึงค่าปรับน้อยกว่า 1% ของเงินเดิมพัน

3. ลูกค้าดังกล่าวถือหุ้นมากกว่าสองในสามของสัดส่วนการถือหุ้นในกรณีนี้ ไคลเอนต์รถบั๊กกี้ไม่เพียงแค่สร้างเชน A เท่านั้น แต่จริงๆ แล้วจะมีเดิมพันเพียงพอในการ "ทำให้เสร็จ" โปรดทราบว่าจะเป็นลูกค้ารายเดียวที่จะถือว่าเชน A เสร็จสมบูรณ์ เงื่อนไขประการหนึ่งสำหรับการสรุปคือเชนนั้นถูกต้อง และสำหรับไคลเอ็นต์ที่ดำเนินการอย่างถูกต้องอื่นๆ ทั้งหมด เชน A จะไม่ถูกต้อง อย่างไรก็ตาม เนื่องจากวิธีการทำงานของโปรโตคอล Casper FFG เมื่อผู้ตรวจสอบความถูกต้องสรุปเชน A พวกเขาจะไม่สามารถเข้าร่วมในเชนอื่นที่ขัดแย้งกับ A โดยไม่ถูกแฮ็ก เว้นแต่เชนนั้นจะได้รับการสรุป (สำหรับรายละเอียดใดๆ สำหรับผู้ที่สนใจ โปรดดูภาคผนวก 2). ดังนั้น เมื่อห่วงโซ่ A ได้รับการสรุปผลแล้ว ผู้ตรวจสอบที่ใช้ไคลเอ็นต์ที่มีบั๊กกี้จะตกอยู่ในสถานการณ์เลวร้าย: พวกเขาได้ตกลงกับเชน A แต่เชน A นั้นไม่ถูกต้อง พวกเขาไม่สามารถร่วมให้ข้อมูลกับ B ได้เนื่องจากยังไม่ได้ข้อสรุป แม้แต่การแก้ไขข้อบกพร่องของซอฟต์แวร์ตรวจสอบความถูกต้องก็ไม่สามารถช่วยได้ - พวกเขาได้ส่งบัตรลงคะแนนที่ไม่เหมาะสมไปแล้ว สิ่งที่จะเกิดขึ้นตอนนี้เป็นเรื่องที่เจ็บปวดมาก: สาย B ที่ยังไม่ได้รับการสรุปจะเข้าสู่การรั่วไหลที่ไม่มีการใช้งานครั้งที่สอง ในช่วงเวลาสองสามสัปดาห์ ผู้ตรวจสอบความถูกต้องที่กระทำผิดจะรั่วไหลของเงินเดิมพันของตนจนกว่าจะสูญเสียเงินเดิมพันไปมากพอที่ B จะสรุปได้อีกครั้ง สมมติว่าพวกเขาเริ่มต้นด้วยเงินเดิมพัน 70% – จากนั้นพวกเขาจะสูญเสียเงินเดิมพัน 79% เนื่องจากนั่นคือจำนวนเงินที่พวกเขาจะต้องเสียเพื่อให้น้อยกว่าหนึ่งในสามของเงินเดิมพันทั้งหมด ณ จุดนี้ เชน B จะถูกสรุปอีกครั้ง และผู้เดิมพันทุกคนสามารถเปลี่ยนไปใช้ได้ ห่วงโซ่จะกลับมาแข็งแรงอีกครั้ง แต่การหยุดทำงานจะกินเวลานานหลายสัปดาห์ โดย ETH นับล้านถูกทำลายในกระบวนการนี้

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

การวิเคราะห์ความเสี่ยง

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

เมื่อคำนึงถึงสิ่งนี้ Scenario 3 จึงมีความสำคัญสูงสุด เมื่อลูกค้าอยู่ในสองในสามของคนส่วนใหญ่ ผลกระทบจะค่อนข้างหายนะ ซึ่งเป็นสถานการณ์ที่ค่อนข้างเป็นไปได้เช่นกัน เพื่อเน้นย้ำว่าช่องโหว่ดังกล่าวสามารถทำได้ง่ายเพียงใด ข้อบกพร่องดังกล่าวเพิ่งเกิดขึ้นบน Kiln Testnet (โปรดดู Kiln Testnet Blocking Proposal Failed) ในกรณีนี้ Prysm ตรวจพบว่าอิฐมีข้อบกพร่องหลังจากนำเสนอและไม่ได้พิสูจน์ หาก Prysm คิดว่าการบล็อกนั้นถูกต้อง และสิ่งนี้เกิดขึ้นบน Mainnet แสดงว่าเราอยู่ในสถานการณ์หายนะที่อธิบายไว้ในกรณีที่ 3 ของสถานการณ์ที่ 3 เนื่องจากปัจจุบัน Prysm ครองเสียงข้างมาก 2/3 บน Mainnet ดังนั้น หากคุณกำลังใช้งาน Prysm อยู่ มีความเสี่ยงอย่างมากที่คุณอาจสูญเสียเงินทุนทั้งหมด และคุณควรพิจารณาเปลี่ยนลูกค้า

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

หากตอนนี้ฉันใช้งานไคลเอ็นต์หลายเครื่องและกังวลเกี่ยวกับการเปลี่ยน ฉันมีตัวเลือกใดบ้าง

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

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

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

แล้วลูกค้าที่ถูกลงโทษล่ะ?

สิ่งที่ฉันเขียนไว้ข้างต้นใช้กับไคลเอนต์ที่สอดคล้องกัน - Prysm, LightTower, Nimbus, Loestar และ Teku และในขณะที่เขียน Prysm อาจมีส่วนใหญ่สองในสามในเครือข่าย
สิ่งเหล่านี้นำไปใช้ในลักษณะเดียวกันกับการดำเนินการไคลเอนต์ Go-Etherum มีแนวโน้มที่จะเป็นไคลเอนต์ที่ดำเนินการส่วนใหญ่หลังจากการผสานรวม และหากสร้างบล็อกที่ไม่ถูกต้อง ก็อาจสิ้นสุด ซึ่งนำไปสู่ความล้มเหลวอย่างร้ายแรงที่อธิบายไว้ในสถานการณ์ที่ 3
ชื่อเรื่องรอง

ภาคผนวก

ภาคผนวก 1: เหตุใดบล็อกที่ไม่ถูกต้องจึงไม่ถูกเฉือน

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

ในความเป็นจริง มีเหตุผลสองประการที่เราไม่ได้ - หนึ่งคือตอนนี้เราทำไม่ได้ แต่ถึงแม้เราจะทำได้ เราก็คงไม่:

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

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

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

ภาคผนวก 2: เหตุใดไคลเอนต์ที่มีข้อบกพร่องจึงไม่สามารถเปลี่ยนไปใช้เชน B หลังจากจบเชน A แล้ว

ส่วนนี้มีไว้สำหรับผู้ที่ต้องการทำความเข้าใจในรายละเอียดเพิ่มเติมว่าเหตุใดไคลเอนต์รถบั๊กกี้จึงไม่สามารถเปลี่ยนกลับได้และต้องประสบกับการรั่วไหลที่ไม่มีการใช้งาน เราต้องดูว่าการสรุปผล Casper FFG ทำงานอย่างไร

แต่ละด่านประกอบด้วยจุดตรวจต้นทางและจุดตรวจปลายทาง จุดตรวจเป็นด่านแรกของยุค หากมีการเชื่อมโยงจากยุคหนึ่งไปยังอีกยุคหนึ่งด้วยคะแนนรวมมากกว่า 2/3 ของคะแนนเสียงทั้งหมด (กล่าวคือ การพิสูจน์มากมายที่จุดตรวจสอบแรก "แหล่งที่มา" และจุดตรวจสอบที่สองคือ "เป้าหมาย") เราจะเรียก พวกเขาเป็น "ลิงค์เสียงข้างมาก"

ยุคสามารถเป็น "เหมาะสม" หรือ "แน่นอน" ซึ่งกำหนดดังนี้:

1. ยุค 0 อยู่ในแนวเดียวกัน

2. ยุคนั้นถูกต้องตามกฎหมายหากมีความเชื่อมโยงที่เหนือกว่ากับยุคที่สมเหตุสมผล

3. ถ้า (1) ยุค X ตรงกัน และ (2) ยุคถัดไปก็ตรงกันด้วย และแหล่งที่มาของลิงก์ส่วนใหญ่คือยุค X ดังนั้น ยุค X จะสิ้นสุด

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

1. V และ W สามารถแฮกได้หากมีเป้าหมายในยุคเดียวกัน (เช่น ความสูงเท่ากัน) แต่จะไม่โหวตให้จุดตรวจสอบเดียวกัน (การโหวตซ้ำ)

2. หมายความว่า (1) แหล่งที่มาของ V อยู่ก่อนหน้าแหล่งที่มาของ W และ (2) เป้าหมายของ V อยู่ภายหลังกว่าเป้าหมายของ W (การลงคะแนนแบบเซอร์ราวด์)

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

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

กล่องโค้งมนในภาพนี้แสดงถึงยุคสมัย ไม่ใช่บล็อก ลูกศรสีเขียวคือลิงก์หลักสุดท้ายที่สร้างโดยตัวตรวจสอบความถูกต้องทั้งหมด ลูกศรสีแดงคือลิงก์หลักที่สนับสนุนโดยไคลเอนต์ที่มีบั๊กกี้เท่านั้น ไคลเอ็นต์ที่ใช้งานได้จะละเว้นยุคที่มีบล็อกไม่ถูกต้อง (สีแดง) ลูกศรสีแดงอันแรกจะระบุยุคที่ไม่ถูกต้อง และลูกศรที่สองจะระบุยุคที่ไม่ถูกต้อง
ตอนนี้สมมติว่าจุดบกพร่องได้รับการแก้ไขแล้ว และผู้ตรวจสอบความถูกต้องซึ่งระบุยุคที่ไม่ถูกต้องในที่สุดต้องการเข้าร่วมห่วงโซ่ B ที่ถูกต้องอีกครั้ง เพื่อให้สามารถยุติห่วงโซ่ได้ ขั้นตอนแรกคือการปรับยุค X:

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

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