ห้าคำถามเกี่ยวกับ Ethereum: ปัญหาความหลากหลายของลูกค้ามาจากไหน?

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)หมายเหตุบรรณาธิการ: บทความนี้มาจาก

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

การประชุมผู้พัฒนาหลักครั้งที่ 90 ล่าสุดนั้นทุ่มเทให้กับปัญหาเดียวเกือบตลอดเวลา ฉันขอแนะนำให้ทุกคนฟังเซสชั่นนี้ด้วยตัวเอง

ในเซสชันนี้ Alexey ได้กล่าวถึงปัญหาที่นักพัฒนาไคลเอ็นต์โอเวอร์โหลด แม้ว่าฉันคิดว่าการสนทนานี้เป็นการเริ่มต้นที่สำคัญ แต่เราก็กระตือรือร้นที่จะหาทางออกเพื่อทำความเข้าใจปัญหาอย่างถ่องแท้ เป็นสิ่งสำคัญที่เราใช้เวลาสักครู่เพื่อวิเคราะห์ปัญหา ในการวิเคราะห์ความหมายแฝงของคำถาม "Five Whys" เป็นหนึ่งในวิธีที่ง่ายและมีประสิทธิภาพที่สุด

เพื่อไม่ให้เป็นการเสียเวลา เรามาดูกันว่าคำถามแรกคืออะไร

• Geth: 75%

• Parity & OpenEthereum: 20%

• Nethermind: 1%

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

คำถามแรก: เหตุใดทีมพัฒนาของ Geth จึงกดดันมาก ถึงขั้นโอเวอร์โหลด

ด้วย etherscan เราสามารถดูสถิติของความจุที่ติดตั้งของไคลเอ็นต์แต่ละรายได้ดังนี้:

ส่วนที่เหลืออีก 4% ประกอบด้วยลูกค้าบางรายที่มีส่วนแบ่งตลาดน้อยกว่า 1% ดังนั้นจึงถูกละเว้น

ที่สำคัญ พลังการประมวลผลมากกว่า 51% มุ่งไปที่ไคลเอนต์ Geth สมมติว่าใน Berlin hard fork ที่กำลังจะมาถึง Geth มีข้อผิดพลาดในการดำเนินการหนึ่งใน EIPs (Ethereum Improvement Proposals) แม้ว่าจะไม่มีข้อบกพร่องในการใช้งานอื่น ๆ ของไคลเอนต์นี้ ตราบใดที่บล็อกพบข้อบกพร่องนี้ มันจะทำให้เครือข่าย Ethereum แยก ตามเหตุผลแล้ว การบล็อกนี้ไม่ถูกต้อง และไคลเอ็นต์อื่นๆ จะถือว่าบล็อกนี้เป็นการบล็อกที่ไม่ถูกต้อง อย่างไรก็ตาม มากกว่า 51% ของโหนดการขุดกำลังเรียกใช้ไคลเอนต์ Geth ดังนั้นเครือข่ายทั้งหมดจะถูกนำไปยังห่วงโซ่แยกที่ไม่ถูกต้อง

ดังนั้น คำตอบสำหรับคำถามแรกคือ:

เนื่องจากลูกค้าของเครือข่าย Ethereum ไม่มีความหลากหลายเพียงพอ

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

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

คำถามที่สอง: เหตุใดเครือข่าย Ethereum จึงขาดความหลากหลายของไคลเอนต์

เมื่อ Ethereum mainnet เปิดใช้งาน เรามีลูกค้าหลายราย สองคนหลักคือ Geth และ CPPEthereum จากนั้น Parity ก็มาถึงและ CPPEthereum ก็ถูกกำจัด

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

เหตุใดเราจึงต้องการลูกค้าหลายราย

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

ฉันคิดว่าควรเน้นที่ความซับซ้อนแทน

หมายเหตุ: Mythical Man-Month หรือ Mythical Man-Month ชี้ให้เห็นว่าผู้คนจำนวนมากและช่วงเวลาสั้นๆ ไม่สามารถทำให้ความคืบหน้าของการพัฒนาซอฟต์แวร์สั้นลงได้ การเบียดเสียดกันไม่ได้ช่วยในการผลิตซอฟต์แวร์ แต่สร้างปัญหาและสร้างซอฟต์แวร์ที่แย่กว่า การเพิ่มกำลังคนให้กับโครงการที่ล่าช้ากว่ากำหนดการมีแต่จะทำให้ล่าช้ากว่ากำหนด

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

ตอนนี้เราเข้าใกล้ต้นตอของปัญหามากขึ้น

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

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

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

• คำถามที่ 4: เหตุใดโปรโตคอลการเชื่อมต่อเครือข่ายจึงเพิ่มความยากในการติดตั้งไคลเอนต์

ฉันเชื่อว่าคำตอบสำหรับคำถามนี้สามารถแบ่งออกเป็นสองส่วนโดยทั่วไป

การจัดการของรัฐ

ข้อกำหนดการเชื่อมต่อเครือข่ายโดยรวม

• เท่าที่เกี่ยวข้องกับการจัดการสถานะ ไคลเอนต์ Ethereum จะต้องสามารถซิงโครไนซ์สถานะทั้งหมดบนเครือข่ายและเก็บรักษาสำเนาในเครื่องของสถานะนั้น ทำยากทั้งคู่ สถานะการซิงโครไนซ์ต้องการคำขอนับล้านสำหรับไคลเอนต์และเซิร์ฟเวอร์ที่อ่านและประมวลผลคำขอสถานะ และสามารถทำให้ I/O ของดิสก์อิ่มตัวได้ สถานะที่ซิงโครไนซ์ใหม่จำเป็นต้องได้รับการบำรุงรักษาและตัดออกเพื่อให้ฐานข้อมูลสามารถดำเนินการบล็อกใหม่ได้เร็วพอ จากมุมมองทางวิศวกรรม นี่เป็นความท้าทายอย่างยิ่ง!

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

จัดการคำขอ GetNodeData เพื่อเข้าถึงสถานะที่สร้างโดยบล็อกล่าสุด

จัดการคำขอเพื่อเข้าถึงประวัติของข้อมูลบนเครือข่าย รวมถึงส่วนหัวของบล็อก เนื้อความของบล็อก และใบเสร็จรับเงิน

คำถามที่ 5: ทำไม...

สารละลาย

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

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

สารละลาย

ฉันติดตามคำถามนี้มาตลอดปีที่ผ่านมา ทำให้ฉันประหลาดใจว่าต้นตอของปัญหามากมายบน Ethereum สามารถสืบย้อนไปถึงเลเยอร์เครือข่ายได้

บางทีตัวอย่างที่ชัดเจนที่สุดคือ I/O ของดิสก์เคยเป็นคอขวดสำหรับไคลเอ็นต์มาก่อน คอขวดนี้มีอยู่เนื่องจากไคลเอนต์มักจะใช้ฐานข้อมูลของรัฐโดยใช้การแสดงโครงสร้างแบบต้นไม้ (Trie) แบบไร้เดียงสา วิธีสร้างฐานข้อมูลสถานะถูกกำหนดโดยองค์ประกอบเครือข่าย GetNodeData

ในการแก้ไขปัญหานี้ เราจำเป็นต้องยกเครื่องส่วนต่าง ๆ ของเลเยอร์ฉันทามติของ Ethereum เช่นเดียวกับเลเยอร์เครือข่าย ปัจจุบันได้เริ่มงานซ่อมบำรุง มีการทำงานมากมายภายใต้ชื่อ "Stateless Ethereum" ที่ Alexey และฉันทำงานร่วมกันเป็นเวลา 8 เดือน อย่างน้อยงานบางอย่างที่เราทำก็ช่วยลดภาระของทีม Geth เนื่องจากพวกเขาใช้โปรโตคอลการซิงโครไนซ์ SNAP ที่พวกเขาพัฒนาขึ้นในช่วงหลายปีที่ผ่านมา ยังมีงานอีกส่วนหนึ่งที่ต้องดำเนินการโดยคนเก่งที่เข้าใจปัญหาอย่างลึกซึ้งและคิดหาทางออกที่เป็นไปได้

ในปัจจุบัน โปรโตคอล DevP2P ETH ขนาดใหญ่ดังกล่าวยังไม่ได้รับการแยกส่วนอย่างสมบูรณ์ เรามีความเข้าใจพื้นฐานเกี่ยวกับวิธีการแยกเครือข่ายนี้ออกเป็นสามเครือข่ายส่วนตัวที่แยกจากกัน แต่ยังไม่มีใครทำโดยตรง