ผู้เขียนต้นฉบับ: parithosh

ที่มา: notes.ethereum.org

สรุป

สรุป

สรุป

สรุป

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

บล็อกแบบนี้blockHash(บล็อกแฮช) ถูกแทนที่ด้วยของมันparentHash(แฮชบล็อกพาเรนต์)engine_executePayloadมีหน่วยการสร้างและหน่วยการสร้างทั้งหมดblockHashต้องใช้พารามิเตอร์ทั้งหมด ไคลเอ็นต์ EL (execution layer) ควรสร้างบล็อกตามพารามิเตอร์เหล่านี้และblockHashรับรองความถูกต้อง บล็อกนี้ไม่ผ่านการตรวจสอบของ Geth อย่างถูกต้อง แต่ผ่านการทดสอบของ Nethermind และ Besu บล็อกได้รับการตรวจสอบอย่างไม่ถูกต้องใน Nethermind เนื่องจากปัญหาการแคช ในขณะที่ Besu ไม่มีการตรวจสอบดังกล่าวเลย ด้วยเหตุนี้ บล็อกจึงถูกเสนอโดยโหนด Lighthouse-Besu และทำให้บล็อกเชนแยกออกเป็นสองส่วน โดยมีตัวตรวจสอบความถูกต้องที่เชื่อมต่อกับ Nethermind หรือ Besu ที่ระดับการดำเนินการที่ทางแยกหนึ่ง และตัวตรวจสอบความถูกต้องที่เชื่อมต่อกับ Geth ที่ทางแยกหนึ่ง ที่อีกทางหนึ่ง .

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

ปัญหาของ Geth คือเมื่อเรียกใช้งานเพย์โหลดผิด มันจะส่งคืนข้อผิดพลาด JSON-RPC แทนINVALID(ใช้งานไม่ได้) และปัญหาของ Teku (แก้ไขแล้ว แต่ไม่ได้ปรับใช้ ณ จุดนี้) คือข้อบกพร่องเหล่านั้นสามารถผ่านได้ในโหมดการซิงค์ในแง่ดี ดังนั้นโหนด Teku-Geth จะยังคงเข้าสู่โหมดการซิงค์ในแง่ดีเมื่อพบการโหลดที่ไม่ถูกต้อง เนื่องจากตัวบล็อกนั้นถูกต้อง โหนด Geth ที่เชื่อมต่อจึงดึงข้อมูลจากเครือข่ายแทนที่จะเป็น engineAPI ดังนั้นโหนด Teku-Geth จึงอยู่บนทางแยกที่ไม่ถูกต้อง เนื่องจากโหนด Teku ยังคงเป็นเวอร์ชันเก่าที่มีข้อบกพร่องมากมาย โหนด Teku-Geth จึงยังคงอยู่ในโหมดการซิงค์ในแง่ดีและปฏิเสธที่จะเสนอบล็อกในช่วงที่บล็อกเชนหยุดการสรุป ขณะนี้เราอยู่ในสถานการณ์ที่ไคลเอนต์เลเยอร์ฉันทามติ (ประภาคาร, ไพรส์ม, นิมบัส และโลเดสตาร์) - Geth (ประมาณ 46%) และไคลเอนต์เลเยอร์ฉันทามติ - Nethermind/Besu (ประมาณ 19%) อยู่บนทางแยกที่แตกต่างกัน ตัวตรวจสอบที่เหลือทำงาน Teku-Geth (ประมาณ 35%) อยู่ในโหมดซิงค์ในแง่ดี

หลังจากค้นหาและใช้งานการแก้ไขสำหรับโหนด Nethermind และ Besu แล้ว เราก็สามารถนำการแก้ไขเหล่านั้นกลับมาใช้เชนที่ถูกต้องได้ การอัปเดตโหนด Teku-Geth ทำให้เกิดปัญหาอื่นที่เกี่ยวข้องกับการเข้าถึงหน่วยความจำที่ไม่ถูกต้อง ซึ่งเกิดจากปัญหาใน Geth ที่เกี่ยวข้องกับการตรวจสอบความถูกต้องของลำดับการบล็อก ช่องโหว่เฉพาะนี้ยังถูกกระตุ้นโดย Fuzzer ของ Marius ซึ่งสร้างparentRootถูกต้องและblock_number=1ปิดกั้น. ก่อนที่ Geth จะดำเนินการบล็อก จะต้องดูบล็อกหลักเพื่อดูว่าจำเป็นต้องซิงโครไนซ์หรือไม่ วิธีหนึ่งในการทำเช่นนี้คือการตรวจสอบในแคชparentHashและparentHashและblockNumber. เนื่องจาก Teku ดำเนินการโหลดทั้งหมดในส้อมทั้งหมดพร้อมกัน แคชจึงไม่มีอีกต่อไปparentHash. ดังนั้น Geth จึงพยายามส่งผ่าน parentHash และblockNumberค้นหาบล็อกหลัก อย่างไรก็ตาม ฐานข้อมูลไม่มีแฮชของ blockNumber นี้ (บล็อกนี้สร้างโดย fuzzer) Geth จะอนุมานว่าเนื่องจากไม่มี parent block จึงจำเป็นต้องเปิดการซิงค์ อย่างไรก็ตาม การซิงโครไนซ์ที่ถูกทริกเกอร์ด้วยวิธีนี้จะพยายามซิงโครไนซ์เชนที่สั้นกว่าเชนที่มีสิทธิ์ ซึ่งละเมิดเงื่อนไขบางประการใน Geth ซึ่งทำให้เกิดข้อผิดพลาดของกระบวนการ Geth โหนดปิด และโหนด Teku-Geth มักจะอยู่ในสถานะที่ไม่แข็งแรง

ในระหว่างการแก้ไขข้อบกพร่องของปัญหาข้างต้น ทีม Geth ยังพบสภาวะการแย่งชิงในฐานรหัสที่ผสานซึ่งก่อให้เกิดข้อผิดพลาด นอกจากนี้ เรามีปัญหาอื่น ๆ - Nimbus มีข้อบกพร่องที่เกี่ยวข้องกับการเชื่อมต่อชั้นผู้บริหารใหม่ Lodestar ได้ลดคะแนนของเพื่อนที่ปฏิเสธที่จะสร้างบล็อค

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

FAQ

ถาม: testnet นี้เสียหรือไม่

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

ถาม: ทำไมห่วงโซ่นี้ถึงไม่ได้รับการสรุปเป็นเวลานานนัก

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

ถาม: ตัวตรวจสอบความถูกต้องของห่วงโซ่แบบแยกจะถูกเฉือนหรือไม่

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

ถาม: สิ่งนี้จะส่งผลต่อการเปิดตัว mainnet อย่างไร จะมีความล่าช้าใหม่หรือไม่?

A:เราไม่คิดว่าเรื่องนี้จะส่งผลกระทบต่อแผนการเปิดตัว mainnet ไม่พบปัญหาร้ายแรงในสเปคตัวเอง จุดประสงค์ของ testnet คือการค้นหาข้อบกพร่อง และเราคิดว่า Kintsugi ทำงานได้ดีในการค้นหากรณีขอบในการใช้งานไคลเอนต์ เหตุการณ์นี้เป็นการทดสอบความเครียดที่ดีสำหรับชุดค่าผสมของไคลเอนต์หลายตัว เรามีรายการตรวจสอบสาธารณะที่จะแนะนำเราเมื่อเราพร้อมที่จะรวมเข้ากับ mainnet

ถาม: สิ่งนี้จะส่งผลต่อแผนการทดสอบอย่างไร

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

ความหมายที่สำคัญสำหรับตัวตรวจสอบความถูกต้อง ผู้ให้บริการโครงสร้างพื้นฐาน และผู้พัฒนาเครื่องมือ:

ระยะเวลาที่ยังไม่สิ้นสุดใน testnet ช่วยเสริมข้อสันนิษฐานบางประการเกี่ยวกับข้อกำหนดด้านฮาร์ดแวร์ที่เลวร้ายที่สุด ในช่วงระยะเวลาที่ไม่ใช่การสรุป ผู้ตรวจสอบความถูกต้องควรคาดหวังว่าจะ:

• โหลด CPU เพิ่มขึ้น (บางครั้งสูงถึง 100%) เนื่องจากต้องประเมินกฎการเลือกส้อมหลายข้อ

• การใช้งาน HDD จะเพิ่มขึ้นในช่วงที่ยังไม่สิ้นสุดเนื่องจากจะไม่มีการตัดแต่ง

• จะมีการใช้ RAM เพิ่มขึ้นเล็กน้อย

ซึ่งหมายความว่าเครื่องมือเพิ่มเติมหรือการมอนิเตอร์ที่ทำงานบนเครื่องเดียวกันจะเกิดการแย่งชิงทรัพยากร เครื่องมือของ Kintsugi testnet (block explorer, faucet, RPC) ทำงานบนคลัสเตอร์ Kubernetes ที่มี 3 โหนด คลัสเตอร์นี้ยังเรียกใช้โหนดสัญญาณที่ใช้โดยเครื่องมือต่างๆ เนื่องจากโหนดบีคอนใช้ทรัพยากรมากกว่าที่จัดเตรียมไว้มาก เครื่องมือของเราจึงมักทำงานในลักษณะที่ด้อยประสิทธิภาพเนื่องจากทรัพยากรไม่เพียงพอ เป็นเรื่องที่รอบคอบสำหรับผู้ให้บริการโครงสร้างพื้นฐานในการเรียกใช้ฉันทามติและเลเยอร์การดำเนินการบนเครื่องที่แยกจากกัน หรือมีข้อกำหนดการใช้ทรัพยากรที่เข้มงวด

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

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