ภาพรวม
ภาพรวม
ชื่อระดับแรก
เหตุการณ์และภูมิหลัง
โดยปกติ สถานะเครือข่ายที่สอดคล้องกันของ Ethereum PoS จะเสร็จสิ้น (สรุปแล้ว) ใน 2 ยุค แต่เมื่อสัปดาห์ที่แล้วมีความล่าช้าถึง 2 ยุคที่สรุปได้
อันดับแรกมันเกิดขึ้นในวันที่ 11 พฤษภาคม และการสิ้นสุดของยุคนั้นล่าช้าไป 3 ยุค ประมาณ 20 นาที
ครั้งที่สองมันเกิดขึ้นในวันที่ 12 พฤษภาคม และการสิ้นสุดของยุคนั้นล่าช้าไป 8 ยุค ประมาณ 51 นาที
ในระหว่างงาน เครือข่าย Ethereum ยังคงสร้างบล็อกและประมวลผลธุรกรรมต่อไป อย่างไรก็ตาม เนื่องจากอัตราการลงคะแนนไม่เพียงพอของ Validator (โหนดการตรวจสอบ) ทำให้ไม่สามารถสรุป Epoch ได้ (นั่นคือ Epoch ได้รับการรับประกันความปลอดภัยระดับฉันทามติของเครือข่าย Ethereum PoS) ความล้มเหลวของ Epoch ในการสรุปหมายความว่าในกรณีของผู้ตรวจสอบความถูกต้องส่วนใหญ่ทำความชั่วร้ายและการฟอร์ก epcoh อาจถูกย้อนกลับ ส่งผลให้ธุรกรรมถูกย้อนกลับ
ในความเป็นจริง ในระหว่างเหตุการณ์ ไม่มีการ Fork ในเครือข่าย Ethereum และ Validator ไม่ได้ลงคะแนนอย่างมุ่งร้าย เป็นเพราะ Validator จำนวนมากออฟไลน์อยู่เท่านั้น อัตราการลงคะแนนจึงไม่เพียงพอ ซึ่งทำให้ไม่สามารถสรุป Epoch ได้ในระหว่างนั้น เหตุการณ์.
หลังจากการสังเกต สถานการณ์ผิดปกติของ CPU โอเวอร์โหลดใน Offline Validator ถือเป็นสาเหตุโดยตรงของ Offline Validator
ในเหตุการณ์ที่สอง การสรุป Epoch นั้นล่าช้าไป 8 ยุค เนื่องจากความล่าช้าของการสรุปนั้นมากกว่าMIN_EpochS_TO_INACTIVITY_PENALTY(= 4) จึงทำให้เกิดอัลกอริธึมฉันทามติของ EthereumInactivity leakกลไกการประมวลผล
ลงโทษผู้ตรวจสอบออฟไลน์โดยการตัดเงินที่จำนำไว้ประมาณ 28 ETH ถูกยึด。
การยกเลิกรางวัลการยืนยัน ส่งผลให้ยังไม่ได้ออกประมาณ 50 ETH。
กลไกนี้ช่วยให้แน่ใจว่าเครื่องมือตรวจสอบออนไลน์สามารถถือครอง ⅔ ของเงินจำนำทั้งหมดของ Ethereum ได้ในที่สุด เพื่อให้สามารถสรุปสถานะเครือข่ายได้ในที่สุด
บริการโหนดของ imToken ตรวจพบเหตุการณ์นี้เช่นกัน ด้วยการตรวจสอบสถานะการลงคะแนนของ Validator ของ Ethereum Consensus Layer แบบเรียลไทม์ มันสามารถแจ้งเตือนล่วงหน้าถึงความผิดปกติของเครือข่ายฉันทามติ Ethereum ก่อนที่ Epoch จะไม่สิ้นสุดตามปกติ รูปด้านล่างคือสถานะของโหนดเมื่อเหตุการณ์แรกเกิดขึ้น
ภายใต้กลไก PoW ความสำเร็จของธุรกรรมคือการระบุว่าธุรกรรมจะไม่ถูกย้อนกลับหลังจากบล็อกติดต่อกันจำนวนหนึ่ง และ PoS จะขึ้นอยู่กับความสูงของบล็อกที่ส่งคืนโดย Safe Head เป็นตัวกำหนดความสำเร็จของ ธุรกรรม. ในข้อกำหนดปัจจุบัน Justified Checkpoint ใช้เป็นสถานะของ Safe Head ดังนั้นเมื่อพิจารณาจากสถานะของ Epoch ก่อนหน้า อาจมีความล่าช้า 6.4 นาที ซึ่งเป็นประสบการณ์ที่เลวร้ายสำหรับผู้ใช้
บริการ Safe Head ที่พัฒนาโดย imToken จะคำนวณบล็อคที่ปลอดภัยสำหรับการยืนยันธุรกรรมตามข้อมูลชั้นฉันทามติของ Ethereum แบบเรียลไทม์ และลดระยะเวลาในการยืนยันธุรกรรมบนสถานที่ตั้งเพื่อรับประกันความปลอดภัยของการทำธุรกรรมของผู้ใช้ ภายใต้สถานการณ์ปกติ ความสูงของบล็อกที่ส่งคืนโดยอัลกอริธึม Safe Head ของ imToken (สีเหลืองในรูปด้านบน) จะใกล้เคียงกับความสูงของบล็อกล่าสุด (สีเขียว) ซึ่งจะช่วยปรับปรุงประสบการณ์ของผู้ใช้
ข้อมูลเพิ่มเติมเกี่ยวกับกลไก Safe Head:
วิเคราะห์สาเหตุ
สาเหตุโดยตรงของเหตุการณ์ข้างต้นคือการโหลดของโหนดไคลเอ็นต์ชั้นฉันทามติของ Ethereum บางโหนดสูงเกินไป ซึ่งทำให้ Validator ออฟไลน์ ดังนั้นการลงคะแนนฉันทามติจึงไม่สามารถทำได้ตามปกติ หลังจากวิเคราะห์แล้ว สาเหตุของภาระที่สูงของโหนดเหล่านี้คือ:
เมื่อได้รับการรับรองที่ชี้ไปที่บล็อกเก่า โหนดจำเป็นต้องคำนวณสถานะของบีคอนเชนใหม่เพื่อตรวจสอบการรับรองเหล่านี้ และกระบวนการนี้ใช้ทรัพยากร CPU และหน่วยความจำจำนวนมาก
เมื่อได้รับพยานจำนวนมากที่ชี้ไปที่บล็อกเก่าพร้อมกัน ทรัพยากร CPU และหน่วยความจำของโหนดจะหมดลง ซึ่งทำให้ตัวตรวจสอบเหล่านี้ทำงานแบบออฟไลน์
เดิมที ปัญหาประเภทนี้สามารถแก้ไขได้โดยการแคชตามพยานที่ชี้ไปที่บล็อก อย่างไรก็ตาม เนื่องจากขนาดของ Validator ที่เพิ่มขึ้นและการเกิดขึ้นของการรับรองดังกล่าวจำนวนมาก แคชที่ไคลเอ็นต์ที่มีปัญหาใช้งานจึงใช้งานไม่ได้ ลง และโหนดต้องใช้ทรัพยากรจำนวนมากเพื่อรีสตาร์ท Computes the beacon chain state
ไคลเอนต์เลเยอร์ฉันทามติ Teku และ Prysm ได้ออกเวอร์ชันแพตช์เพื่อแก้ปัญหานี้ โดยเฉพาะอย่างยิ่ง การนำไคลเอ็นต์ไปใช้เวอร์ชันแพตช์จะกรองพยานเก่าเหล่านี้ออก นั่นคือ ละเว้นพยานเมื่อตรงตามเงื่อนไขต่อไปนี้:
พยานชี้ไปที่ช่องเก่า
พยานชี้ไปที่ด่านที่โหนดไม่เคยเห็น
อย่างไรก็ตาม เรายังคงต้องติดตามการสรุป Ethereum mainnet ต่อไปเพื่อยืนยันประสิทธิภาพของแพตช์
ชื่อระดับแรก
Prysm：v 4.0.3-hotfix
Teku：v2 3.5.0
ข้อดีของการออกแบบ Ethereum
ในเหตุการณ์นี้ Ethereum รับประกันความพร้อมใช้งานและยังคงสร้างบล็อกและดำเนินการธุรกรรมต่อไป และกุญแจสำคัญในการชะลอการสิ้นสุดของ Epoch นั้นอยู่ที่สองประเด็น:
1. ความหลากหลายของลูกค้า Ethereum
ชื่อเรื่องรอง
ความหลากหลายของลูกค้า Ethereum
ในเหตุการณ์นี้ แม้ว่าจะมีปัญหาในการใช้งานไคลเอ็นต์เลเยอร์ฉันทามติ Teku และ Prysm แต่ก็ไม่ได้ส่งผลกระทบต่อการทำงานปกติของไคลเอ็นต์เลเยอร์ฉันทามติอื่นๆ เช่นเดียวกับลูกค้า Lighthouse ในครั้งนี้และไม่ได้รับผลกระทบเนื่องจากไคลเอ็นต์ที่แตกต่างกันมีการออกแบบการใช้งานที่แตกต่างกัน Validator จึงยังคงทำงานได้ตามปกติ
ชื่อเรื่องรอง
การออกแบบอัลกอริทึมที่สอดคล้องกันของ Ethereum Gasper เพื่อการใช้งาน
การตรวจสอบความพร้อมใช้งานของ Ethereum เป็นหนึ่งในจุดเริ่มต้นการออกแบบของอัลกอริทึมที่สอดคล้องกันของ Ethereum Gasper ซึ่งจะแยกการผลิตและการสิ้นสุดของบล็อก Ethereum ดังนั้น แม้ว่าการบล็อกขั้นสุดท้ายจะถูกบล็อก การผลิตบล็อกจะไม่ถูกยุติ เมื่อพิจารณาว่าในกรณีส่วนใหญ่ การสิ้นสุดการบล็อกจะกลับมาดำเนินการต่อในที่สุด (การบล็อกที่สร้างขึ้นจะยังคงได้รับการสิ้นสุด) ผลกระทบต่อผู้ใช้จะน้อยมาก เมื่อเปรียบเทียบกับอัลกอริธึมฉันทามติ BFT อื่นๆ: หากการสรุปบล็อกล้มเหลว โหนดฉันทามติจะหยุดสร้างบล็อกถัดไป เป็นผลให้บล็อกเชนทั้งหมดไม่สามารถใช้งานได้ในช่วงเวลาดังกล่าว ซึ่งเรียกกันทั่วไปว่า บล็อกเชนแฮงค์
ชื่อระดับแรก
ชื่อเรื่องรอง
ความท้าทายหลายไคลเอนต์ Ethereum
คำอธิบายภาพ
แหล่งที่มา:https://clientdiversity.org/#distribution
จะเห็นได้ว่าความหลากหลายของลูกค้า Ethereum ยังคงต้องได้รับการส่งเสริมและเผยแพร่ อาจเป็นไปได้ว่าหากการใช้งานไคลเอ็นต์มีความหลากหลายมากพอที่ Prysm และ Teku คิดน้อยกว่า ⅓ เหตุการณ์นี้ก็จะไม่เกิดขึ้นด้วยซ้ำ (⅔ ไคลเอ็นต์ทำงานได้อย่างถูกต้องเพียงพอที่จะจบยุค) นอกจากนี้ ลูกค้าของชั้นการดำเนินการปัจจุบันกระจุกตัวอยู่ใน Geth ซึ่งคิดเป็นสัดส่วนสูงถึง 61% นี่เป็นความเสี่ยงที่อาจเกิดขึ้น: หาก Geth ทำงานไม่ถูกต้อง Ethereum จะได้รับผลกระทบอย่างมาก
นอกเหนือจากความต้องการความพยายามเพิ่มเติมในความหลากหลายของไคลเอนต์ Ethereum แล้ว การเปลี่ยนไคลเอนต์ Ethereum ยังเป็นจุดอ่อนที่เปิดเผยจากเหตุการณ์นี้: เมื่อการใช้งานไคลเอ็นต์บางอย่างล้มเหลว Validator จะเปลี่ยนไปใช้งานไคลเอนต์ปกติได้อย่างไร กระบวนการนี้เกี่ยวข้องกับ:
โอนย้ายคีย์การตรวจสอบความถูกต้องของไคลเอ็นต์ที่มีปัญหาไปยังไคลเอ็นต์ปกติอย่างปลอดภัย
เนื่องจากฉันทามติของ Ethereum มีกฎ Slash จึงจำเป็นต้องตรวจสอบให้แน่ใจว่าพฤติกรรมของไคลเอ็นต์เก่าและไคลเอนต์ใหม่นั้นสอดคล้องกันโดยไม่ถูกเฉือน ตัวอย่างเช่น:
ลูกค้าเก่าและใหม่โหวตจุดตรวจทั้งสองด้านของส้อมจึงถูกเฉือน
ชื่อเรื่องรอง
การตรวจสอบฉันทามติของ Ethereum
บริการต่างๆ เช่น Safe Head จำเป็นต้องตรวจสอบสถานะแบบเรียลไทม์ของเครือข่าย Ethereum PoS อย่างต่อเนื่อง เพื่อตรวจจับและเตือนเหตุการณ์ดังกล่าวล่วงหน้า แทนที่จะรอจนกว่าจะสิ้นสุดยุคตามที่คาดไว้เพื่อเรียนรู้ว่าสถานะเครือข่ายผิดปกติ งานวิจัยล่าสุดที่เกี่ยวข้องสามารถพบได้ในชื่อเรื่องรอง。
วิทยาศาสตร์ยอดนิยมของ Ethereum Consensus Algorithm
ชื่อเรื่องรอง
ผลกระทบสำหรับแอปพลิเคชัน Ethereum
แม้ว่าเครือข่าย Ethereum จะแข็งแกร่งเพียงพอ แต่ความไม่เสถียรในบางครั้งจะส่งผลกระทบต่อแอปพลิเคชัน ในเวลาเดียวกัน แอปพลิเคชันควรจัดการกับสถานการณ์ที่ไม่เสถียรเหล่านี้ได้อย่างถูกต้อง
Layer 1 ->เวลาฝากเลเยอร์ 2 จะนานขึ้น เมื่อเลเยอร์ 2 ยังอยู่ในขั้นเริ่มต้น สิ่งที่จำเป็นเบื้องต้นที่สำคัญคือต้องแน่ใจว่าธุรกรรมการฝาก L1 จะไม่ถูกย้อนกลับ ดังนั้น เมื่อการสิ้นสุดยุคของเครือข่าย Ethereum ล่าช้า เวลาฝากของ L1->L2 ก็จะนานขึ้นตามลำดับ
ในทำนองเดียวกัน การแลกเปลี่ยนยังต้องป้องกันไม่ให้ธุรกรรมการเติมเงินบนเครือข่ายถูกย้อนกลับ ดังนั้นเวลาการเติมเงินจะนานขึ้นตามลำดับ
ใบเสนอราคาในห่วงโซ่ Oracle มีความเสี่ยงที่จะถูกย้อนกลับ ดังนั้นบริการที่มีมูลค่าสูงซึ่งต้องใช้ใบเสนอราคานี้ควรถูกระงับอย่างเหมาะสม
สรุป
สรุป
ลิงค์อ้างอิง
