การตรวจสอบอุบัติเหตุ Ethereum 2.0 Mainnet
ที่มา | Prysmatic Labs
ชื่อเรื่องรอง
https://beaconcha.in/epoch/32302
สรุปอุบัติเหตุ
ตั้งแต่ยุค 32302 ห่วงโซ่บีคอนได้สูญเสียข้อเสนอบล็อกจำนวนมาก เนื่องจาก Prysm เป็นไคลเอนต์ Eth2 ที่ใช้มากที่สุด ปัญหาจึงน่าจะอยู่ที่ Prysm มากที่สุด หลังจากเวลาผ่านไป เราได้สร้างข้อผิดพลาดขึ้นใหม่ภายในเครื่อง นี่เป็นปัญหาที่ทราบกันดีเกี่ยวกับการลงคะแนนข้อมูล eth1 และการฝากเงินของผู้ตรวจสอบความถูกต้อง แม้ว่าจะเคยรายงานปัญหานี้ให้เราทราบแล้ว แต่เราไม่สามารถทำซ้ำข้อบกพร่องนี้ได้และถือว่าเป็นเหตุการณ์ที่เกิดขึ้นอย่างโดดเดี่ยว และปัญหานี้ไม่เคยมีการแพร่กระจายอย่างกว้างขวางใน testnet หรือ mainnet ใดๆ นี่เป็นครั้งแรกที่ปัญหานี้ส่งผลให้ข้อเสนอการบล็อกล้มเหลว
ในช่วง 18 ยุคนี้ โหนดบีคอน Prysm เกือบทั้งหมดไม่สามารถสร้างบล็อกใหม่ได้ ยุค 32320 เริ่มทำงานตามปกติอีกครั้ง ในเวลาที่เหตุการณ์นี้เชื่อกันว่าจบลงแล้ว อย่างไรก็ตาม ประมาณ 24 ชั่วโมงต่อมา อุบัติเหตุก็เกิดขึ้นอีกครั้งในลักษณะเดียวกัน
อิทธิพล
การทบทวนให้รายละเอียดเส้นเวลาของเหตุการณ์ วิเคราะห์สาเหตุที่แท้จริงและกำหนดประเด็นที่ผู้เดิมพัน Eth2 และผู้เข้าร่วมจำเป็นต้องทราบ
อิทธิพล
ข้อมูลเบื้องต้นบางอย่างบ่งชี้ว่าโปรแกรมตรวจสอบความถูกต้องที่ได้รับผลกระทบแต่ละตัวสูญเสียเงินเฉลี่ย 122,950 gwei ($0.3 ณ เวลาที่เขียน) ในเหตุการณ์แรก ภายใน 24 ชั่วโมงของเหตุการณ์นั้น เหตุการณ์ที่เหมือนกันครั้งที่สองเกิดขึ้น ซึ่งทำให้ Validator ที่ได้รับผลกระทบแต่ละตัวมีค่าใช้จ่ายประมาณ 0.22 ดอลลาร์
ข้อเท็จจริงสำคัญบางประการ:
➤ ไม่มีตัวตรวจสอบความถูกต้องถูกตัดออก
➤ ไม่มีผลต่อการสรุปห่วงโซ่บีคอน
➤ อัตราการมีส่วนร่วมยังคงสูงมาก (84.8% ที่จุดต่ำสุด) (หมายเหตุบรรณาธิการ ข้อมูลนี้สอดคล้องกับฉบับล่าสุดที่เขียนโดย Ben Eddingtonอัพเดทความคืบหน้า Eth2มีความคลาดเคลื่อน )
➤ ผู้ตรวจสอบส่วนใหญ่จะสูญเสียการพิสูจน์ 2 ถึง 3 รายการ ไม่ว่าลูกค้าจะเป็นประเภทใดก็ตาม
➤ ครั้งนี้ดูเหมือนจะไม่ใช่การโจมตีที่มุ่งร้ายหรือจงใจ
ชื่อเรื่องรอง
คำถามที่พบบ่อย
ทางลัดสู่การเป็น Validator
อุบัติเหตุครั้งนี้จะทำให้ความเชื่อมั่นของทุกคนที่มีต่อ Eth2 ลดลงหรือไม่?
จะไม่. เหตุการณ์ไม่ได้ทำให้เกิดความล้มเหลวเป็นเอกฉันท์ และขนาดของเหตุการณ์ก็เล็กมากเมื่อเทียบกับขนาดของ Eth2 mainnet (ในเหตุการณ์แรก ผู้ตรวจสอบความถูกต้องที่ได้รับผลกระทบแต่ละคนสูญเสียค่าเฉลี่ยประมาณ $0.3) ตั้งแต่กำเนิด Eth2 นั้นแข็งแกร่งมากด้วยการมีส่วนร่วมของผู้ตรวจสอบความถูกต้องที่สูงมากและการสรุปทุกยุคทุกสมัย จากมุมมองของเรา ความสามารถของเครือข่ายในการกลับสู่สถานะการทำงานอย่างสมบูรณ์หลังจากแก้ไขข้อผิดพลาดได้ทำให้ความเชื่อมั่นของชุมชนแข็งแกร่งขึ้นในความยืดหยุ่นของ Ethereum
เหตุการณ์นี้จะบั่นทอนความเชื่อมั่นของทุกคนในทีม Prysmatic Labs หรือไม่?
การตอบสนองและการแก้ไขเหตุการณ์นี้แตกต่างอย่างสิ้นเชิงจากความพยายามก่อนหน้านี้ของเราในการจัดการกับความล้มเหลวในเครือข่ายทดสอบ Eth2 ทันทีหลังจากเหตุการณ์นั้น ทีมงานของเราได้ตัดข้อมูลที่ผิดออกไป ประเมินผลกระทบเชิงปริมาณ และวางขั้นตอนที่ชัดเจนสำหรับผู้ตรวจสอบในขณะที่รอการแก้ไข นอกจากนี้ หลังจากที่เราได้พิจารณาวิธีแก้ปัญหาอย่างเต็มที่แล้ว เราจะขอให้ทุกคนอัปเกรดเวอร์ชันไคลเอนต์ เป็นที่น่าสังเกตว่าเนื่องจากไคลเอนต์ Prysm เป็นซอฟต์แวร์ที่มีสัดส่วนผู้ใช้มากที่สุดในเครือข่าย Ethereum 2.0 ข้อบกพร่องใด ๆ ที่ปรากฏอาจทำให้เกิดปัญหาร้ายแรงขึ้น
ชื่อเรื่องรอง
สรุปต้นตอของเหตุการณ์
เชน Eth2 และ Eth1 นั้นเชื่อมต่อกันอย่างหลวมๆ และ Eth2 ต้องการเพียง Eth1 สำหรับการตรวจสอบเงินฝากของผู้ตรวจสอบความถูกต้อง นั่นคือ Eth2 PoS chain สามารถดำเนินการต่อไปได้แม้ว่าตัวตรวจสอบความถูกต้องจะลงคะแนนให้กับข้อมูลขยะ สิ่งเดียวที่สำคัญคือไม่สามารถเพิ่มเงินฝากตัวตรวจสอบความถูกต้องใหม่ได้จนกว่าห่วงโซ่ PoS จะโหวตข้อมูล Eth1 ที่ถูกต้องอีกครั้ง "การลงคะแนน" นี้กระทำระหว่าง "ระยะเวลาการลงคะแนน" ซึ่งปัจจุบันกำหนดไว้ที่ 64 ยุค (ประมาณ 6.8 ชั่วโมง) บน mainnet
วิธีการลงคะแนนเป็นหลักการ "เสียงข้างมาก" แบบง่ายๆ ซึ่งอธิบายไว้ในข้อกำหนดเฉพาะของเครื่องมือตรวจสอบความถูกต้องของ Eth2 น่าเสียดายที่ Prysm สูญเสียการตรวจสอบบางอย่างเมื่อบังคับใช้หลักการนี้ (การลงคะแนนโดยเสียงส่วนใหญ่) ในเหตุการณ์นี้ เนื่องจากบั๊กใน Prysm ผู้เสนอบล็อกสร้างรากต้นไม้เงินฝาก Eth1 ที่ไม่ถูกต้องโดยสิ้นเชิง และโหนด Prysm อื่นๆ ค้นพบข้อเสนอบล็อกก่อน จากนั้นพวกเขาลงคะแนนเสียงอย่างถูกต้องเนื่องจากไคลเอนต์ Prysm ทำตาม "การลงคะแนนเสียงส่วนใหญ่" แบบง่ายๆ โดยไม่มีการตรวจสอบอย่างชัดเจน
จากนั้น โหนด Prysm ทั้งหมด "สโนว์บอล" จะโหวตข้อมูลที่ไม่ถูกต้อง ส่งผลให้ผู้เสนอบล็อกไม่สามารถรวมบล็อกที่มีเงินฝากเข้าในห่วงโซ่ได้ นี่เป็นเพราะเงินฝากเหล่านี้ไม่ได้รับการตรวจสอบเทียบกับรูทของเงินฝาก Eth1 ของโหนด ดังนั้นข้อเสนอบล็อกจะล้มเหลว หลังจากช่วงเวลาลงคะแนน ปัญหาจะได้รับการแก้ไขโดยอัตโนมัติ แต่ถ้าข้อบกพร่องไม่ได้รับการแก้ไข ปัญหาจะเกิดขึ้นอีก
ชื่อเรื่องรอง
ไทม์ไลน์ของเหตุการณ์
หมายเหตุ รายละเอียดทางเทคนิคด้านล่าง! คุณสามารถข้ามไปยังส่วนถัดไปเพื่ออ่านเกี่ยวกับแนวทางแก้ไขและบทเรียนที่ได้รับจากเหตุการณ์ดังกล่าว
ข้อเสนอการบล็อกล้มเหลว
Epoch 32302 เริ่มมีปัญหากับข้อเสนอบล็อกที่หายไป
Nishant แจ้งให้ทีมทราบและเรียกประชุมทั้งหมด จากนั้นเราสร้างเหตุการณ์ซ้ำผ่านโหนดสัญญาณเมนเน็ตบนเครื่องและเริ่มการสอบสวน
Prysm โหวตให้รากต้นไม้ที่แปลกประหลาด eth1 ผิด การสืบสวนเผยให้เห็น
ข้อความ
ยกเว้น
ความสงสัยเริ่มแรกเกี่ยวกับวิธีที่ Prysm จัดการการลงคะแนนข้อมูล eth1 ในเส้นทางรหัสข้อเสนอของเครื่องมือตรวจสอบความถูกต้อง โดยเฉพาะอย่างยิ่ง เราพยายามขจัดปัญหาบางอย่าง:
1. มีปัญหาในการบรรจุเงินฝากลงในบล็อกหรือไม่?
2. ข้อมูลบันทึกการฝากเงินที่ได้มาผสมกับข้อมูล eth1 หรือไม่ ไม่แน่ใจ?
3. มีปัญหากับต้น Merkle เงินฝากของเราหรือไม่?
ในอีกประมาณ 16 ชั่วโมงข้างหน้า เราใช้เวลามากมายในการทำงานร่วมกันเพื่อวินิจฉัยปัญหาเบื้องหลัง เรารวบรวมบรรทัดของโค้ด พยายามจำลองกระบวนการที่ล้มเหลวผ่านการทดสอบหน่วย และลองใช้วิธีการต่างๆ แม้ว่าเราจะมีวิธีแก้ปัญหาที่เป็นไปได้แล้ว แต่เราก็รู้สึกประหม่าที่จะปล่อยการแก้ไขเนื่องจากขาดความมั่นใจ
สาเหตุที่เป็นไปได้
เราได้เรียนรู้บทเรียนจากประสบการณ์ก่อนหน้านี้เกี่ยวกับข้อบกพร่องใน Eth2 testnet ว่ายังไม่เพียงพอที่จะมั่นใจในสาเหตุที่แท้จริง ในสถานการณ์ที่มีเดิมพันสูง เราต้องมั่นใจ 100% ในโซลูชันก่อนที่จะปล่อยให้ผู้ใช้ 28 ชั่วโมงหลังจากเกิดอุบัติเหตุ เรานั่งลงและถามตัวเองว่า "มีอะไรอีกที่เราไม่รู้ เราจะถามคำถามอะไรได้บ้างที่จะทำให้เราเข้าใกล้ต้นตอของความล้มเหลวมากขึ้น" จากนั้นเราได้เรียนรู้สิ่งต่อไปนี้: ประเด็น:
1. การใช้งาน Merkle Tree แบบกระจัดกระจายของเรานั้นไม่ได้มีปัญหาร้ายแรง เนื่องจากใช้การฝาก mainnet และ Prater testnet ซึ่งตรงกับการใช้งาน Eth2 zrnt ของ Lighthouse และ Protolambda
2. เส้นทางรหัสที่เราใช้เพื่อดึงข้อมูล Eth1 จากโหนด Eth1 นั้นไม่บั๊กและไม่ส่งคืนข้อมูลที่ไม่ถูกต้อง
สิ่งที่เราไม่รู้คือ:
1. วิธีสร้างรูททรีเงินฝากที่ไม่ถูกต้อง
2. เหตุใดปัญหานี้จึงเกิดขึ้นซ้ำได้ในบางโหนด แต่ไม่เกิดในโหนดอื่น
3. เหตุใดโหนด Prysm จึงแสดงข้อผิดพลาด "แบบทีละรายการ" เมื่อกำหนดจำนวนเงินฝากในบล็อก
แก้ไขปัญหา
เพื่อตอบคำถามเหล่านี้ เราได้ดูเส้นทางรหัสที่เริ่มต้นโครงสร้างเงินฝากของเรา ปรากฎว่ามีการเพิ่มเลเยอร์แคชตั้งแต่เนิ่นๆ เพื่อหลีกเลี่ยงการดาวน์โหลดบันทึกการฝากเงินของตัวตรวจสอบความถูกต้องทุกครั้งที่ผู้วางเดิมพันเปิดโหนดของตน นอกจากนี้ เราได้เพิ่มคุณสมบัติใหม่ - ความสามารถในการเริ่ม Prysm จากสถานะการกำเนิดที่ฝังอยู่ภายในไคลเอ็นต์ ค่าดีฟอลต์ที่ไม่ถูกต้องในทรีเงินฝากของเราทำให้ข้อมูลเสียหายเมื่อเติมแคช:
ต้นตอของปัญหา
ปรากฎว่าฟังก์ชัน len(รายการ) จะส่งกลับ 1 เสมอหากแผนผังเงินฝากของเราว่างเปล่า ซึ่งหมายความว่าเราตั้งค่าของ lastReceivedMerkleIndex เป็น 0 ทั้งที่จริง ๆ แล้วเราควรตั้งค่าเป็น -1 โค้ดข้างต้นจะทำให้โหนด Prysm บางตัวในเส้นทางโค้ดข้ามการฝังเงินฝาก 0 ลงในแผนผัง โค้ดเบสที่เหลือทั้งหมดชี้ไปที่ส่วนแปลกๆ ของการติดตั้งแผนผังเงินฝากของเราว่าเป็นปัญหา ไม่ใช่เส้นทางโค้ดนี้
ชื่อเรื่องรอง
แก้ไขปัญหา
สรุปสาเหตุที่แท้จริง
➤ Prysm เก็บข้อมูล eth1 ไว้บนดิสก์เพื่อป้องกันไม่ให้ผู้ใช้ต้องส่งคำขอไปยังบันทึกสัญญาเงินฝากของผู้ตรวจสอบความถูกต้องทุกครั้งที่เริ่มกระบวนการใหม่
➤ หากโหนดรีบูตและคงข้อมูล eth1 ไว้บนดิสก์ เราจะเริ่มต้นแคชฝากของเราจากข้อมูลนี้ แต่เนื่องจากวิธีที่ตัวช่วย sparse merkle tree (SMT) ของเรา เส้นทางโค้ดสำหรับการเริ่มต้นแคชนี้แตกต่างจากข้อมูลด้านบน เราจะ ข้ามการฝังการฝากเงินครั้งที่ 0 ลงในแผนผังการฝากเงิน ส่งผลให้รูตของทรีการฝากเงินไม่ถูกต้อง เส้นทางรหัสนี้ได้รับผลกระทบเฉพาะโหนดที่ยังไม่มีฐานข้อมูลตั้งแต่กำเนิด และได้รับการแก้ไขในภายหลัง
➤ ในข้อมูลจำเพาะอย่างเป็นทางการ โหนด Prysm ปฏิบัติตามหลักการของ "เสียงข้างมากอย่างสมบูรณ์" เพื่อใช้อัลกอริทึมการลงคะแนนข้อมูล eth1 แต่ Prysm ไม่ได้ใช้เงื่อนไขที่ถูกต้องบางประการของอัลกอริทึม โหนด Prysm โหวตด้วยการโหวตข้อมูล eth1 ในระดับมากสุดที่อ้างอิงถึงรูทของบล็อกที่มีอยู่ ซึ่งอาจทำให้โหนด Prysm โหวตสำหรับแฮชทรีเงินฝากที่สร้างโดยทรีเงินฝากที่มีปัญหา เนื่องจากเงินฝากเหล่านี้ไม่ได้รับการตรวจสอบ
➤ เนื่องจากโหนดส่วนใหญ่ในเครือข่ายเป็นโหนด Prysm ผลกระทบก้อนหิมะของการลงคะแนนสำหรับต้นขั้วเงินฝากที่ผิดพลาดด้วยกฎเสียงข้างมากจึงกลายเป็นปัญหาร้ายแรงเนื่องจากโหนด Prysm ไม่สามารถสร้างบล็อกบน mainnet ได้ในช่วงระยะเวลาหนึ่งหลังจากนั้น
สารละลาย
สารละลาย
เมื่อเวลา 13:00 น. ตามเวลาปักกิ่งของวันอาทิตย์ที่ 25 เมษายน หลังจากเกิดความไม่แน่นอนมาหลายชั่วโมง เราได้ออกการแก้ไขปัญหานี้แล้ว เรามั่นใจในวิธีแก้ปัญหานี้อย่างแน่นอน และมั่นใจเป็นอย่างยิ่งว่าปัญหานี้จะไม่เกิดขึ้นอีกใน Eth2 หลังจากการอัปเกรดโหนด
เรียนรู้บทเรียน
➤ ความมั่นใจในโซลูชันของเราและการสื่อสารอย่างระมัดระวังกับโลกภายนอกเป็นสิ่งสำคัญอย่างยิ่งในงานนี้
เราได้เรียนรู้บทเรียนสำคัญเกี่ยวกับคุณค่าของการสื่อสารที่ดีเมื่อเราประสบอุบัติเหตุ Eth2 Medalla testnet ทุกความคิดเห็นในที่สาธารณะและการใช้ภาษาที่ชัดเจนสามารถส่งผลกระทบร้ายแรงต่อผลลัพธ์ของเหตุการณ์ ในกรณีของ testnet เราคิดว่าวิธีแก้ปัญหาในทันทีคือการบอกทุกคนผ่านช่องทางสาธารณะให้ "รีสตาร์ทโหนดของคุณ" การตัดสินใจที่เร่งรีบนี้ทำให้โหนดส่วนใหญ่บนเครือข่ายออฟไลน์ จากนั้นจึงแย่งกันหาเพื่อนที่ดีในกลุ่มเพื่อนที่ไม่ดีเพื่อซิงโครไนซ์กับบล็อกเชน นอกจากนี้ เรายังปล่อยฮอตแพตช์อัปเกรดซอฟต์แวร์อย่างรวดเร็วซึ่งเราไม่มั่นใจ 100% ว่าจะแก้ปัญหาได้ สิ่งนี้ทำให้เกิดความสับสนมากขึ้นในระบบและสร้างความสงสัยให้กับผู้ให้บริการโหนดเกี่ยวกับโซลูชัน
ในทางตรงกันข้าม ตลอดกระบวนการทั้งหมดของอุบัติเหตุ mainnet ใหม่ เราให้ความสำคัญกับการสื่อสารอย่างระมัดระวังและแม่นยำเสมอ นอกจากนี้ เราจะไม่เผยแพร่โปรแกรมแก้ไขด่วนจนกว่าเราจะมั่นใจ 100% เกี่ยวกับแหล่งที่มาและวิธีแก้ปัญหา
➤ ความอดทนและความสงบสามารถช่วยแก้ปัญหาได้
ทีมงานของเราใช้เวลาไม่กี่ปีที่ผ่านมาในการสร้าง Eth2 และได้เรียนรู้วิธีสงบสติอารมณ์เมื่อเผชิญกับความทุกข์ยาก เราเชื่อว่าการสงบสติอารมณ์เป็นสิ่งสำคัญ สื่อสารรายงานสถานะบ่อยๆ และทำให้แน่ใจว่าทีมรู้สึกถึงการสนับสนุน และการตอบรับเชิงบวกเป็นสิ่งสำคัญในระหว่างกระบวนการแก้ไขปัญหา เราสามารถใช้เวลาในการรวบรวมหลักฐานให้ได้มากที่สุด และทำงานร่วมกับผู้ใช้ของเราอย่างพิถีพิถัน และเราจะแก้ไขปัญหานี้ได้สำเร็จ ที่สำคัญกว่านั้น เราใช้เวลาในการประเมินผลกระทบของเหตุการณ์ตั้งแต่เริ่มแรกเพื่อลดปัญหาคนวางเดิมพันและการขาดความกังวลเรื่องข้อมูล บทเรียนนี้สำคัญมากสำหรับการทำงานในสถานการณ์ที่มีความเครียดสูงและอดนอน ช้าลง แก้ไขด้วยวิธีการที่เหมาะสม และหลีกเลี่ยงการทำให้ปัญหาแย่ลงในทุกวิถีทาง
➤ เครือข่ายทดสอบ Eth2 ไม่เท่ากับเครือข่ายหลัก
สำหรับไคลเอนต์ Prysm เราได้ทดสอบและรับฟังผู้สมัครก่อนการผลิตของ Prysm อย่างครอบคลุมบนเครือข่ายทดสอบ Eth2 สาธารณะ ทั้ง Prater และ Pyrmont testnet เป็นเครื่องมือที่ยอดเยี่ยมสำหรับผู้ใช้ในการทดสอบการตั้งค่าก่อนเข้าร่วม Eth2 mainnet อย่างไรก็ตาม เครือข่ายทดสอบเหล่านี้ถือว่าสัดส่วนของลูกค้า Eth2 ระดับการผลิตสี่รายนั้นใกล้เคียงกับคะแนนเฉลี่ย นั่นคือไม่มีลูกค้ารายใดมีส่วนแบ่งส่วนใหญ่ที่ชัดเจนระหว่างผู้ตรวจสอบความถูกต้อง น่าเสียดายที่สิ่งนี้อาจไม่คำนึงถึงช่องโหว่ที่เกิดขึ้นเมื่อคนส่วนใหญ่ใช้ไคลเอนต์บางตัวเท่านั้น ในอนาคต Prysmatic Labs จะทดสอบในเครือข่ายทดสอบภายในในสภาพแวดล้อมที่ใกล้กับสภาพแวดล้อมเมนเน็ต หรือสภาพแวดล้อมที่มีโหนดเครือข่าย Prysm 50%
ชื่อเรื่องรอง
สิ่งที่นักเดิมพันควรนึกถึง
เหตุใดจึงต้องใช้ไคลเอนต์ Prysm เพื่อเดิมพัน
https://launchpad.ethereum.org
ผู้คนเลือกที่จะใช้งาน Prysm เพราะตั้งแต่เริ่มต้นทีมงานของเราได้มุ่งเน้นไปที่การทำให้ประสบการณ์การเดิมพัน Ethereum ของพวกเขาง่ายขึ้น ฉันได้พูดคุยกับผู้ใช้ของเราหลายครั้ง และหลายคนเลือกไคลเอ็นต์หนึ่งรายไม่ใช่เพราะการเพิ่มประสิทธิภาพระดับไมโครหรือความแตกต่างของผลตอบแทนที่ค่อนข้างน้อยเมื่อเทียบกับไคลเอนต์อื่นๆ แต่เพราะเราทำให้ประสบการณ์ของพวกเขาง่ายขึ้น - ข้อมูลเอกสารที่ดีได้ให้ความช่วยเหลือที่สำคัญแก่ สมาชิกในชุมชนทั้งหมด สำหรับผู้เริ่มต้น Eth2 นั้นน่ากลัว และการเดิมพันก็เต็มไปด้วยความไม่แน่นอนและความเสี่ยง ภารกิจของทีมของเราคือการแจ้งให้ผู้ใช้ทราบว่าเราอยู่เคียงข้างพวกเขาและได้รับการสนับสนุนไม่ว่าปัญหาของพวกเขาจะเล็กน้อยเพียงใด โดยเฉพาะอย่างยิ่ง เราได้จับตาดูผู้วางเดิมพันทั่วไปที่อาจไม่คุ้นเคยกับบรรทัดคำสั่งหรือระบบปฏิบัติการ UNIX
ในอนาคต คุณจะได้รับสิ่งต่อไปนี้จากทีมของเรา:
➤ ปรับปรุงความถูกต้องของการนำเงื่อนไขข้อกำหนดไปใช้ ทำให้มั่นใจว่าเงื่อนไขที่กำหนดไว้ล่วงหน้าและถูกต้องได้รับการตรวจสอบและท้าทายอย่างเต็มที่ก่อนที่จะเขียนโค้ดใดๆ
➤ เราจะพัฒนาไปอีกขั้นเพื่อปรับปรุงประสบการณ์นี้ ทำให้ Prysm ดีขึ้นกว่าที่เป็นอยู่ในปัจจุบันหลายเท่า ทำให้ผู้วางเดิมพันที่ใช้ไคลเอ็นต์ของเราเข้าร่วมในเครือข่ายได้ง่ายขึ้น รวมถึงการปรับปรุงเว็บอินเตอร์เฟส
➤ Prysm จะเพิ่ม R&D เป็นสองเท่า<>การผสานรวมล่วงหน้าของ eth2 มีคุณสมบัติและการปรับปรุงที่สำคัญ
➤ เราเชื่อว่าการแข่งขันที่ดีจะสร้างแรงจูงใจที่แข็งแกร่งในการผลักดันให้ Proof-of-Stake ของ ETH มีส่วนร่วมมากขึ้น และปลอดภัยมากขึ้น เนื่องจากทีมงานลูกค้าทั้งหมดปรับปรุงซอฟต์แวร์ของตนอย่างต่อเนื่อง
➤ ทีมงานของเรามุ่งมั่นที่จะแก้ปัญหาที่นักเดิมพันอาจประสบด้วยมาตรฐานสูงสุดระดับมืออาชีพ เราเชื่อว่าเราพร้อมที่จะจัดการกับปัญหาใดๆ ที่เข้ามา และรับประกันชุมชนของเราว่าเราจะทำให้ผู้เดิมพันได้รับความสำคัญสูงสุดของเรา
➤ สุดท้ายนี้ เราเชื่อว่ามีฟีเจอร์สำคัญมากมายที่สามารถทำให้ Prysm เป็นซอฟต์แวร์ที่น่าดึงดูดยิ่งขึ้นสำหรับการเข้าร่วมใน Eth2 และเราจะทำซ้ำเพื่อบรรลุเป้าหมายนี้ต่อไป
ชื่อเรื่องรอง
สะท้อนให้เห็นถึงการสนทนาที่หลากหลายของลูกค้า
หัวข้อทั่วไปที่เราได้ยินตั้งแต่การกำเนิดของ Eth2 คือความหลากหลายของลูกค้า Eth2 เป็นระบบกระจายที่มีผู้คนทั่วโลกเข้าร่วมเป็นผู้ตรวจสอบความถูกต้อง ต่างคนต่างใช้ซอฟต์แวร์ที่แตกต่างกันเพื่อเข้าร่วมในฉันทามติของ blockchain หากมีปัญหาร้ายแรงกับซอฟต์แวร์บางตัว หากไคลเอนต์ที่เรียกใช้เครือข่ายมีการกระจายในลักษณะที่สมดุล ผลกระทบจะน้อยลง
Leonardo Bautista-Gomez เปิดตัวการวิเคราะห์ข้อมูลเมื่อต้นเดือนมกราคมและผลการวิจัยพบว่าโหนด Prysm คิดเป็น 65% ของเครือข่าย เหตุการณ์นี้ยังแสดงให้เห็นว่าเครื่องมือตรวจสอบความถูกต้องของ Prysm คิดเป็นส่วนใหญ่ในปัจจุบัน
https://github.com/leobago/BSC-ETH2/tree/master/armiarma
เราขอแนะนำให้คุณดูที่ไคลเอ็นต์แต่ละรายอย่างเป็นกลาง: ซอฟต์แวร์ ชุมชน และความยืดหยุ่น และตัดสินใจว่าซอฟต์แวร์และทีมใดที่อยู่เบื้องหลังเหมาะสมที่สุดสำหรับความต้องการของคุณ หากไคลเอนต์ Eth2 ขาดบางสิ่งที่สำคัญสำหรับคุณ หรือเหตุผลที่คุณไม่เลือกไคลเอ็นต์ของพวกเขา เราขอแนะนำให้คุณยื่นคำขอคุณสมบัติ Prysmatic Labs ยังคงมุ่งเน้นที่การช่วยให้คุณมีส่วนร่วมในเครือข่าย Ethereum และขยายขอบเขตของซอฟต์แวร์บล็อกเชน
อ้างถึง
อ้างถึง
• การสื่อสารเกี่ยวกับเหตุการณ์ https://www.reddit.com/r/ethstaker/comments/mxpz57/regarding_the_recent_beacon_chain_incident/
• รายงานชันสูตร https://docs.google.com/document/d/1nJr6_bd-UnLBxvhT8lcRYdAZr69QdVQ3zJNUr3LgW-0/edit?usp=sharing
• เหตุการณ์ Medalla testnet https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a
https://medium.com/prysmatic-labs/tagged/blockchain)
ลิงค์ต้นฉบับ: https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c
