บทความเพื่อทำความเข้าใจเรื่องราวทั้งหมดของเหตุการณ์ "ขัดข้อง" ของ Medalla testnet
ที่มา |What’s New in Eth2
ผู้แต่ง | เบน เอ็ดจิงตัน
ที่มา |ผู้แต่ง | เบน เอ็ดจิงตัน
หมายเหตุผู้แปล: ผู้ใช้ที่เรียกใช้ไคลเอ็นต์ Prysm ควรอัปเกรดเป็น
ปัญหานี้เป็นการอัปเดตนอกแผน wnie2 และจะตรวจสอบและวิเคราะห์ตอนที่เกิดขึ้นในเครือข่ายการทดสอบ Eth2 Medalla ในช่วงสุดสัปดาห์ที่ผ่านมาช่วงก่อนหน้านี้。
เราเปิดตัว Medalla เมื่อเกือบสองสัปดาห์ก่อนในวันที่ 4 สิงหาคม ในฐานะเครือข่ายทดสอบสาธารณะขนาดใหญ่แบบหลายไคลเอนต์ที่ใช้ข้อมูลจำเพาะ Eth2 mainnet สำหรับข้อมูลเบื้องต้นเกี่ยวกับเครือข่ายทดสอบ Medalla โปรดดูที่
ช่วงก่อนหน้านี้
อย่างไรก็ตาม ในเย็นวันศุกร์ ฉันเฝ้าดูอัตราการมีส่วนร่วมของผู้ตรวจสอบความถูกต้องลดลงจากหน้าผาในแดชบอร์ด ภายในไม่กี่นาที ตัวตรวจสอบความถูกต้องที่ใช้งานอยู่ลดลงจาก 22,000 เป็นประมาณ 5,000 ตัว และประมาณ 80% ของตัวตรวจสอบความถูกต้องในเครือข่ายหายไป
ดังนั้น บทความนี้จะทบทวนเหตุการณ์ รวมถึงผลที่ตามมาและขั้นตอนต่อไป
ชื่อระดับแรก
เกิดอะไรขึ้นเราค้นพบว่าโปรแกรมตรวจสอบความถูกต้องทุกตัวที่เรียกใช้ไคลเอนต์ Prysm ในเครือข่ายนั้นหายไปในทันที เนื่องจาก Prysm เป็นไคลเอนต์ที่ใช้มากที่สุด ผลลัพธ์ที่ตามมาจึงสามารถจินตนาการได้ทีม Prysmatic เปิด
รายงานเอกสารRoughtimeซึ่งรายละเอียดเหตุการณ์และการตอบสนองของทีมจะได้รับการอัปเดตอย่างต่อเนื่อง ต่อไปนี้เป็นไฮไลต์บางส่วนในบันทึกย่อของฉัน
สาเหตุของเหตุการณ์คือปัญหาเกี่ยวกับการซิงค์นาฬิกา ไคลเอนต์ Prysm ได้รับการกำหนดค่าโดยใช้ Cloudflare's
เพื่อนับเวลา เหตุผลนี้ (ในความคิดของฉัน) ไม่ชัดเจนนัก แต่เป็นที่ชัดเจนว่า Roughtime เลื่อนเวลาไปข้างหน้าสี่ชั่วโมง และกินเวลานานกว่าหนึ่งชั่วโมง ผู้ตรวจสอบไคลเอนต์ Prysm พบว่าเวลาของพวกเขาเร็วขึ้นสี่ชั่วโมงและยังคงสร้างบล็อกและพิสูจน์สำหรับบล็อกเชนที่ยังไม่มีอยู่
ด้วยตัวของมันเอง ไม่เพียงพอที่จะเกิดหายนะ แม้ว่าจะมีบล็อกจำนวนมากที่สูญเสียไปและเผชิญกับข้อพิสูจน์จำนวนมากจากอนาคต ลูกค้าที่เหลือจะยังคงสามารถสร้างบนเชนเดิมได้ เมื่อนาฬิกาของโหนด Prysm ปรับกลับทีละน้อย พวกเขาก็เริ่มกลับเข้ามาในเครือข่าย และการมีส่วนร่วมของผู้ตรวจสอบความถูกต้องก็เริ่มดีขึ้น ดูเหมือนว่าเครือข่ายจะกลับมาเป็นปกติ
แต่ไม่กี่ชั่วโมงต่อมา สถานการณ์กลับแย่ลงอย่างรวดเร็ว
สี่ชั่วโมงหลังจากเวลาเริ่มต้น สองสิ่งก็เกิดขึ้น ประการแรก การพิสูจน์ที่สร้างขึ้นโดยไคลเอนต์ Prysm ทั้งหมดในอนาคตจะเริ่มมีผลสมบูรณ์ ประการที่สอง โหนด Prysm ที่เข้าร่วมเครือข่ายอีกครั้งเริ่มหายไปอีกครั้งเนื่องจากกลไกการป้องกันสแลชถูกเรียกใช้เพื่อป้องกันไม่ให้สร้างการพิสูจน์ที่ขัดแย้งกัน
ทั้งสองสิ่งนี้เกิดขึ้นพร้อมกัน ทำให้เครือข่ายวุ่นวาย ลูกค้าที่เหลือยังคงดิ้นรนในการประมวลผลข้อมูลที่ได้รับ และสายบีคอนก็กลายเป็นป่าที่แตกกิ่งก้านสาขา (Raul จากทีม Prysmatic บอกฉันว่าข้อบกพร่องในการแก้ไขครั้งแรกของ Prysm ทำให้ทุกอย่างแย่ลง)
ข้อมูลในเครือข่ายยังอยู่ภายใต้การควบคุมเป็นระยะเวลาหนึ่ง แต่ในอีก 24 ชั่วโมงข้างหน้า หน่วยความจำและ CPU ที่จำเป็นต่อการนำทางส้อมที่ซับซ้อนและยุ่งเหยิงมากขึ้นเรื่อยๆ กลับล้นหลาม ฉันเห็นไคลเอนต์ Lighthouse ใช้หน่วยความจำ 30GB (ประมาณ 100 เท่าของปกติ) และสำหรับไคลเอนต์ Teku แม้จะมีฮีปหน่วยความจำ Java ขนาด 12GB และโปรเซสเซอร์สูงสุด ฉันก็ยังประสบปัญหา Eth2Statsโปรดทราบว่าทั้งหมดนี้เกิดขึ้นในวันหยุดสุดสัปดาห์ ขอบคุณทีมลูกค้าทุกคนที่ต่อสู้ในแนวหน้า เพื่อให้โหนดสามารถรับมือกับเครือข่ายที่วุ่นวายได้ พวกเขาจำเป็นต้องเพิ่มประสิทธิภาพหน่วยความจำและประสิทธิภาพอย่างต่อเนื่อง
จนถึงขณะนี้เครือข่ายกำลังฟื้นตัวอย่างค่อยเป็นค่อยไป รายงานของผู้ใช้มีการผสมผสานกัน แต่ Prysm และ Lighthouse เวอร์ชันใหม่กว่าสามารถค้นหาส่วนหัวของห่วงโซ่ที่ถูกต้องและสร้างห่วงโซ่สัญญาณต่อไปได้
บางโหนดกำลังแสดงส่วนหัวของโซ่หรือโหนด Lighthouse, Prysm และ Teku ที่อยู่ใกล้เคียง เราจะปรับปรุง Teku ต่อไปเพื่อลดทรัพยากรที่ต้องใช้ในการซิงค์
ไม่เกิดความล้มเหลวฉันทามติ
สิ่งหนึ่งที่ต้องชัดเจนคือไม่มีความล้มเหลวที่เป็นเอกฉันท์ระหว่างไคลเอนต์ กล่าวคือ เมื่อเครือข่ายถูกกู้คืน ไคลเอ็นต์ทั้งหมดสามารถบรรลุฉันทามติเกี่ยวกับสถานะของส่วนหัวของห่วงโซ่ ซึ่งหมายความว่าโดยพื้นฐานแล้ว ห่วงโซ่บีคอนจะไม่ล้มเหลว และจะไม่ล้มเหลว ต้องใช้ hard fork ใดๆ
ประสบการณ์บทเรียน
เราจะใช้เวลามากขึ้นในการไตร่ตรองและสรุปตอนนี้ทั้งหมด ต่อไปนี้เป็นความคิดเห็นส่วนตัวของฉันความสำคัญของการซิงโครไนซ์เวลา。
การพึ่งพาบริการเวลาของบุคคลที่สามสูงเป็นจุดที่ร้ายแรงสำหรับเครือข่าย ก่อนหน้านี้ Alex Vlasov จากทีมวิจัย ConsenSys TX/RX ได้เขียนบทความโดยละเอียดที่อธิบายการซิงโครไนซ์เวลาและความสำคัญในเครือข่าย Ethereum 2.0 งานของเขากำลังก้าวหน้าอย่างรวดเร็ว บางทีนี่อาจเป็นโอกาสสำหรับทุกคนที่จะให้ความสนใจในด้านนี้ นี่คือของเขา
บทความที่เกี่ยวข้องและโพสต์ ethresear.ch
ความสำคัญของความหลากหลายของลูกค้า
ตามหลักการแล้ว เราจะมีไคลเอนต์อิสระตั้งแต่สี่ตัวขึ้นไป โดยแต่ละโหนดไคลเอ็นต์คิดเป็นไม่เกิน 30% ของเครือข่าย ด้วยวิธีนี้ แม้ว่าลูกค้ารายหนึ่งจะมีปัญหา ก็ไม่มีผลกระทบเพียงพอที่จะได้รับความสนใจจากเรา
แม้ว่าเราจะไม่สามารถบรรลุอุดมคตินี้ได้ แต่การลดการใช้งานที่รุนแรงโดยไคลเอ็นต์แต่ละรายจะทำให้เครือข่ายมีความแข็งแกร่งมากขึ้น สมมติว่าคราวนี้ Validator เพียง 50% ออฟไลน์แทนที่จะเป็น 80% เครือข่ายจะกู้คืนได้ง่ายขึ้น เนื่องจากเมื่อมีปัญหากับไคลเอ็นต์ จะส่งผลกระทบต่อการสร้างบล็อกของเครือข่าย การบรรจุหลักฐาน ประสิทธิภาพการแพร่ภาพ การสื่อสารแบบจุดต่อจุด และการซิงโครไนซ์ และปัจจัยเหล่านี้จะส่งผลต่อส่วนที่เหลือด้วย ผู้ตรวจสอบความถูกต้อง
ประสิทธิภาพของแผนสำรองstaker บางรายสามารถเปลี่ยนคีย์การลงนามไปยังโหนดสำรองฮอตไคลเอ็นต์อื่นได้ สิ่งนี้สร้างเครือข่ายความปลอดภัยที่ยอดเยี่ยมอย่างแน่นอน แม้ว่าจะต้องระวังเพื่อหลีกเลี่ยงการเฉือน: ผู้ตรวจสอบความถูกต้องรายใหม่อาจไม่รู้อะไรเลยเกี่ยวกับประวัติการลงคะแนนของผู้ตรวจสอบความถูกต้องที่มีอยู่ และอาจลงคะแนนตรงกันข้ามในอนาคตเมื่อเราทำสำเร็จแล้ว
API ใหม่
ควรเปิดใช้ความสามารถในการสลับไคลเอนต์ตัวตรวจสอบความถูกต้องระหว่างโหนดบีคอนต่างๆ ไม่ใช่แค่คีย์ ตัวอย่างเช่น เครื่องมือตรวจสอบความถูกต้องของ Prysm สามารถแยกออกจากโหนดบีคอน Prysm และเชื่อมต่อกับโหนดบีคอน Teku อีกครั้งได้อย่างง่ายดาย สิ่งนี้สามารถแก้ปัญหาการเฉือนที่กล่าวถึงข้างต้นได้
ความรู้สึกรับผิดชอบของผู้มีส่วนได้ส่วนเสีย
การเข้าร่วม Eth2 ไม่ใช่เรื่อง "ครั้งเดียวจบ" ในขณะนี้ ผู้วางเดิมพันจำเป็นต้องรักษาระดับความสนใจไว้บ้าง เดินไปมาระหว่างฟอรัม ให้ข้อเสนอแนะแก่ผู้พัฒนา และสามารถอัปเดตไคลเอนต์ได้ในเวลาอันสั้น ฉันสนับสนุนผู้ที่ใช้ตัวตรวจสอบความถูกต้องส่วนบุคคลของตนเองเป็นอย่างมาก แต่เฉพาะในกรณีที่พวกเขาตระหนักถึงความรับผิดชอบของตนเท่านั้น
ความเร่งรีบทำให้เสียทำไมสิ่งต่างๆ มักผิดพลาดในเย็นวันศุกร์แม้ในเวลานี้ การตอบสนองจากทีม Prysmatic ก็ยังน่าทึ่ง สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ทีมงาน
รายงานเหตุการณ์
. สิ่งที่ฉันพูดด้านล่างไม่ได้หมายถึงการมองโลกในแง่ลบต่อทีม Prysmatic ซึ่งทำผลงานได้ดีจริงๆ แต่เพื่อมอบประสบการณ์ให้กับทีม Teku เมื่อเผชิญกับสถานการณ์ที่คล้ายคลึงกัน
เมื่อผู้ใช้จำนวนมากกำลังสูญเสียทรัพย์สิน (แม้ว่าจะเป็นเพียงเหรียญทดสอบก็ตาม) และเครือข่ายอยู่ภายใต้แรงกดดันสูง เป็นเรื่องปกติที่จะต้องการตอบสนองอย่างรวดเร็ว แต่บางครั้งความเร่งรีบอาจก่อให้เกิดผลเสียได้
มีสองสิ่งที่หลีกเลี่ยงได้ในเหตุการณ์นี้ ประการแรก มีข้อบกพร่องในการแก้ไขเบื้องต้น Alpha.21 ที่ทำให้ผู้ใช้ต้องย้อนกลับหลังจาก 17 ชั่วโมง
จากข้อมูลของ Raul จากทีม Prysmatic ข้อบกพร่องนี้มีส่วนรับผิดชอบต่อความโกลาหลของเครือข่ายที่ตามมา ประการที่สอง ทีมงานได้ลบฐานข้อมูลของบันทึกแบบ slash-proof ของผู้ตรวจสอบความถูกต้อง 1024 คนโดยไม่ตั้งใจในขณะที่จัดการกับสถานการณ์ ส่งผลให้ผู้ตรวจสอบความถูกต้องส่วนใหญ่ถูกเฉือน
สถานการณ์ที่คล้ายกันสามารถเกิดขึ้นได้กับลูกค้ารายใดก็ได้ ดังนั้นแม้ภายใต้ความกดดันสูง พวกเราทุกคน ไม่ว่าจะเป็นนักพัฒนาซอฟต์แวร์หรือผู้ใช้ จะต้องจัดการกับมันอย่างใจเย็นและไม่ไล่ตามความเร็วอย่างสุ่มสี่สุ่มห้า ดังนั้น เมื่อเราพยายามกู้คืนเครือข่าย เราจึงทำตามวิธีที่ช้าและระมัดระวัง
เปิดเผยปัญหาเพื่อหลีกเลี่ยงปัญหาในอนาคต
ในท้ายที่สุด ตอนนี้จำเป็นจริง ๆ testnet จะมีประโยชน์อะไรหากไม่มีการทดสอบ เห็นได้ชัดว่ามันไม่สมจริงที่จะทำงานอย่างราบรื่นตลอดเวลาครั้งนี้เป็นการทดสอบครั้งยิ่งใหญ่! นี่อาจเป็นอาการช็อกที่เลวร้ายที่สุดที่เครือข่ายอาจประสบ และเราคงไม่สามารถออกแบบการทดสอบดังกล่าวได้หากเราต้องออกแบบเอง การเปิดเผย testnet ให้ได้รับผลกระทบในระดับนี้คือสิ่งที่เราต้องการเพื่อทำให้ไคลเอ็นต์แข็งแกร่งขึ้นอาทิตย์ที่แล้ว
บล็อกในบทความ
อ้างคำพูดของฉัน:
ในอีเมล Ben Eddington วิศวกรของ PegaSys เขียนว่า Medalla "เป็นเครือข่ายทดสอบแรกที่มีขนาดและการกำหนดค่าของ mainnet"พูดตรงๆ,。
อะไรต่อไป?
คุณกำลังรออะไรอยู่?
อะไรต่อไป?
เว็บไซต์: ethereum.cn
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ Ethereum โปรดใส่ใจกับ:
บัญชีสาธารณะ: เว็บไซต์จีน ETH
เว็บไซต์: ethereum.cn
ข้อจำกัดความรับผิดชอบ: งานแปลของ ECN มีเป้าหมายเพื่อส่งมอบข้อมูลคุณภาพสูงและทรัพยากรการเรียนรู้สำหรับชุมชน Ethereum ของจีน ลิขสิทธิ์ของบทความเป็นของผู้เขียนต้นฉบับ การพิมพ์ซ้ำต้องระบุแหล่งที่มาของข้อความต้นฉบับและ ethereum.cn สำหรับระยะยาว พิมพ์ซ้ำกรุณาติดต่อethereumcn@gmail.comอนุญาต.
