เราใช้งาน Validator เกือบ 3,000 ตัวบนเครือข่ายทดสอบ Ethereum 2.0
หมายเหตุบรรณาธิการ: บทความนี้มาจากชุมชน HashQuark (ID: HashQuarkPool)พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต
Prysm เป็นการใช้งาน ETH2.0 ที่ยอดเยี่ยม และปัจจุบันเป็นการใช้งานที่รันมากที่สุดในเครือข่ายทดสอบ Medalla Prysm นำสถาปัตยกรรมของ Beacon Chain Node + Validator Node มาใช้ โดยอันแรกมีหน้าที่ในการซิงโครไนซ์ข้อมูลบล็อก ส่วนอันหลังมีหน้าที่ลงนามในบล็อกและเป็นพยาน เนื่องจากโหนดเครื่องมือตรวจสอบความถูกต้องสามารถโหลดเครื่องมือตรวจสอบความถูกต้องได้หลายรายการพร้อมกัน เพื่อให้มีความเข้าใจเชิงคุณภาพและปริมาณของจำนวนเครื่องมือตรวจสอบความถูกต้องที่สามารถโหลดได้และขั้นตอนการปรับใช้เครื่องมือตรวจสอบความถูกต้องที่เกี่ยวข้อง เราจึงจัดการทดสอบนี้เป็นพิเศษ
ชื่อเรื่องรอง
เราจำลองเครือข่ายการทดสอบ Medalla สร้าง ETH2.0 Beacon Chain ของ HashQuark ดำเนินการทดสอบสองรอบ รวมทั้งหมด 14 กรณีทดสอบ และเรียกใช้ Validator นับแสน การใช้งาน Prsym นั้นยอดเยี่ยมมาก สำหรับผู้ใช้ทั่วไปที่ต้องการเข้าร่วม Ethereum Staking ด้วย ETH จำนวนเล็กน้อย (หลายสิบถึงหลายร้อยตัวตรวจสอบความถูกต้อง) เซิร์ฟเวอร์คลาวด์ 8G แบบ 4 คอร์สามารถรัน Beacon Chain Node และ Validator ได้อย่างราบรื่น อย่างไรก็ตาม ปัญหาทางเทคนิคที่พบในกระบวนการทำงานไม่สามารถแก้ไขได้โดยผู้ใช้ทั่วไปที่ไม่ใช่บุคลากรด้านเทคนิค
สำหรับพูลการขุด PoS ระดับมืออาชีพที่เรียกใช้ตัวตรวจสอบความถูกต้องหลายหมื่นตัว จำเป็นต้องมีการกำหนดค่าที่สูงขึ้นเพื่อให้แน่ใจว่าอัตราการบล็อกสูงมาก อัตราการบล็อกจะลดลงเมื่อจำนวน Validator เพิ่มขึ้น
ต่อไป เราจะทำการทดสอบรอบต่อไปในเครือข่ายการทดสอบสาธารณะ Medalla เพื่อให้ใกล้เคียงกับสภาพแวดล้อมเครือข่ายหลักมากขึ้น ในปัจจุบัน เรามีตัวตรวจสอบเกือบ 3,000 ตัวที่ทำงานตามปกติบน Medalla ซึ่งคิดเป็น 5% ของเครือข่ายทั้งหมด
ชื่อเรื่องรอง
สภาพแวดล้อมการทดสอบ
สำหรับการปรับใช้โฮสต์คลาวด์ที่ใช้ในการทดสอบต่อไปนี้ เราเลือกรุ่น N ที่ใช้งานทั่วไป และแพลตฟอร์ม CPU คือ Intel/Broadwell ระบบใช้ Ubuntu 18.04.2 LTS รุ่น geth คือ 1.9.19-stable และรุ่น Prysm คือ v1.0.0-alpha.24
ระยะแรกของความพยายามเบื้องต้น
ชื่อเรื่องรอง
โปรแกรมทดสอบ
ใช้โหนด ETH1.0 ขั้นพื้นฐานที่สุด 2 โหนด + โหนด Beacon Chain ETH2.0 2 โหนด + สถาปัตยกรรมโหนด Validator 2 โหนดเพื่อสร้างเครือข่ายส่วนตัวเป็นแผนเริ่มต้น การทำงานที่เสถียรของเครือข่ายเป็นเวลาหนึ่งวันคือช่วงสังเกตการณ์
ชื่อเรื่องรอง
ตารางด้านล่างแสดงภาพรวมของการทดสอบของเรา:
ตารางที่ 1
ชื่อเรื่องรอง
ในระหว่างการทดสอบ เราได้รวบรวม CPU, หน่วยความจำ, ดิสก์ IO, แบนด์วิธเครือข่าย IO และตัวบ่งชี้อื่นๆ ของแต่ละเซิร์ฟเวอร์อินสแตนซ์
ชื่อเรื่องรอง
ในการทดสอบที่ 1 หน่วยความจำของ 4G Beacon Chain Node แบบ 2 คอร์เพิ่มขึ้นเป็นระยะ ๆ หลังจากทำงานประมาณ 6 ชั่วโมง การใช้หน่วยความจำถึง 100% ทำให้กระบวนการหยุดลงเนื่องจากข้อผิดพลาดของหน่วยความจำไม่เพียงพอ และการใช้งาน CPU ก็ค่อยๆ เพิ่มขึ้น. ดังที่แสดงด้านล่าง:
รูปที่ 1
คำอธิบายภาพ
รูปที่ 2
หลังจากนั้น เราได้อัปเกรดการกำหนดค่าของ Beacon Chain Node เป็น 4-core 8G
หลังจากนั้น เราปรับใช้โหนด ETH2.0 ในภูมิภาคต่างๆ เพื่อสังเกตว่าการเชื่อมต่อเครือข่ายในภูมิภาคต่างๆ จะมีผลกระทบมากขึ้นในแต่ละตัวบ่งชี้หรือไม่ และผลการทดลองก็ปกติ
ชื่อเรื่องรอง
ตามสถานการณ์การทดสอบเครือข่ายส่วนตัว Beacon Chain Node แนะนำการกำหนดค่า 8G แบบ 4 คอร์ และการกำหนดค่า 4G แบบ 2 คอร์ของโหนด Validator ก็เพียงพอแล้ว แต่จะใช้ CPU 1 คอร์เมื่อนำเข้าไฟล์คีย์ และอัตราการใช้งาน CPU เป็น 100% (ดังแสดงในรูปด้านล่าง) ที่แสดงไว้) เพื่อความปลอดภัย ขอแนะนำให้กำหนดค่า 4C6G
คำอธิบายภาพ
นอกจากนี้ ในขั้นตอนนี้ของการทดสอบ ข้อกำหนดสำหรับประสิทธิภาพของดิสก์ I/O และแบนด์วิธของเครือข่ายภายนอกนั้นต่ำมาก ซึ่งอาจเป็นเพราะเหตุผลของเครือข่ายส่วนตัว ข้อกำหนดด้านประสิทธิภาพที่สอดคล้องกันนั้นจำเป็นต้องได้รับการทดสอบใน ETH2.0 อย่างเป็นทางการ เครือข่ายทดสอบ
การทดสอบเปรียบเทียบระยะที่ 2
ชื่อเรื่องรอง
ขั้นตอนแรกส่วนใหญ่ทดสอบแรงกดดันของผู้ตรวจสอบจำนวนต่างๆ บนทรัพยากรเซิร์ฟเวอร์ นอกจากนี้ การสร้างบล็อกของผู้ตรวจสอบและพยานยังเป็นตัวบ่งชี้ที่สำคัญสำหรับผู้ตรวจสอบ ด้วยเหตุนี้ เราจึงทำการทดสอบเปรียบเทียบ ในเครือข่ายเดียวกัน มีการใช้งานตัวตรวจสอบความถูกต้องจำนวนต่างกันในภูมิภาคต่างๆ สำหรับการทดสอบเปรียบเทียบ
ชื่อเรื่องรอง
ในระหว่างการทดสอบ เราจะรวบรวมตัวบ่งชี้ต่างๆ เช่น CPU, หน่วยความจำ, ดิสก์ IO, แบนด์วิธเครือข่าย IO, จำนวนบล็อกที่ควรสร้าง, จำนวนบล็อกจริงที่ผลิต, จำนวนบล็อกที่ควรตรวจสอบ และจำนวนบล็อกจริงที่เห็นโดย แต่ละเซิร์ฟเวอร์อินสแตนซ์
ชื่อเรื่องรอง
ต่อไปนี้เป็นกรณีทดสอบของเรา:
คำอธิบายภาพ
ตารางที่ 2
เครือข่าย ETH1.0 ประกอบด้วยเซิร์ฟเวอร์คลาวด์ 4G แบบ 2 คอร์ 3 เซิร์ฟเวอร์ สองแห่งในฮ่องกงและอีกแห่งในเซาเปาโล ตั้งเวลาบล็อกไว้ที่ 15 วินาที
เราได้ปรับใช้ Beacon Chain Node และ Validator Node ในฮ่องกง สิงคโปร์ ลอสแองเจลิส แฟรงก์เฟิร์ต เซาเปาโล และลอนดอน Beacon Chain Node และ Validator Nodes ในแต่ละภูมิภาคเชื่อมต่อกันผ่านอินทราเน็ต การกำหนดค่าและจำนวนตัวตรวจสอบที่สอดคล้องกันจะแสดงในรูปด้านบน
อินสแตนซ์ 1 และอินสแตนซ์ 2 ทั้งคู่มีตัวตรวจสอบความถูกต้อง 1k ตัว ความแตกต่างอยู่ที่การกำหนดค่าของโหนดตัวตรวจสอบความถูกต้อง ซึ่งใช้เพื่อเปรียบเทียบผลกระทบของจำนวนตัวตรวจสอบความถูกต้องที่มีการกำหนดค่าต่างกันบนตัวบ่งชี้
Beacon Chain Node ในแต่ละภูมิภาคเชื่อมต่อกับโหนดอื่นๆ
ชื่อเรื่องรอง
การเลือกพารามิเตอร์ Testnet
ก่อนอื่น เราปรับใช้สัญญาการฝากเงินบนเครือข่าย ETH1.0 และหลังจากสร้างคีย์ตัวตรวจสอบความถูกต้องตามจำนวนที่ต้องการแล้ว เราก็ส่งธุรกรรมการฝากเป็นชุด Prysm เริ่มต้นด้วยการแก้ไขพารามิเตอร์ต่อไปนี้:
MinGenesisActiveValidatorCount ถูกตั้งค่าเป็น 8192 ซึ่งเป็นที่พอใจเนื่องจากมีตัวตรวจสอบความถูกต้อง 40k ตัวรวมอยู่ในการทดสอบของเรา
Eth1FollowDistance ถูกตั้งค่าเป็น 20 นั่นคือสัญญาการฝากบนเครือข่าย ETH1.0 จะถูกตรวจสอบโดยเครือข่าย ETH2.0 หลังจากผ่านไป 5 นาที
SecondsPerETH1Block ถูกตั้งค่าเป็น 15 ซึ่งสอดคล้องกับการตั้งค่าเวลาของแต่ละบล็อกในเครือข่าย ETH1.0
เนื่องจากเราได้ส่งธุรกรรมการฝากทั้งหมดล่วงหน้าเพื่อให้ตรงตามจำนวนผู้ตรวจสอบขั้นต่ำที่กำหนดไว้ในเวลาเริ่มต้นที่เร็วที่สุด เครือข่าย ETH2.0 ทั้งหมดจึงเปิดตัวเมื่อ 1599811207(2020-09-11T16:00:07+08:00) .
ชื่อเรื่องรอง
สถิติและผลการทดสอบ
นอกจากนี้ เรายังปรับใช้ Beacon Chain Node เพื่อเชื่อมต่อกับเครือข่ายส่วนตัว ETH2.0 เพื่อสืบค้นข้อมูล เพิ่มพารามิเตอร์ --slots-per-archive-point=1 เพื่อเก็บข้อมูลของแต่ละบล็อกอย่างต่อเนื่องเพื่อเพิ่มความเร็วในการสืบค้น การเพิ่มพารามิเตอร์ --rpc-max-page-size=1000 ช่วยให้เราสามารถสืบค้นข้อมูลได้มากขึ้นในแต่ละครั้ง ซึ่งจะช่วยลดจำนวนคำขอและเร่งความเร็วโดยรวม
เราเลือกช่วงเวลาที่เครือข่ายค่อนข้างเสถียร โดยสุ่มตัวอย่างจาก 75 ยุค (ประมาณ 12-2020-2020 00:00:00 +0800) ถึง 1200 ยุค (2020-09-17 00:00:00 +0800) ถึง ได้รับส่วนนี้ ข้อมูลของการสร้างบล็อกและข้อมูลพยานของผู้ตรวจสอบในกรณีต่างๆ ได้รับการวิเคราะห์ภายในระยะเวลาหนึ่งและได้รับผลลัพธ์ต่อไปนี้:
พยานผู้ตรวจสอบในแต่ละภูมิภาคจะแตกต่างกันเล็กน้อย:
คำอธิบายภาพ
ตารางที่ 3
ที่นี่เรากำหนดอัตราพยานหารด้วยจำนวนพยานที่รวมอยู่ในช่วงเวลาหนึ่งหารด้วยจำนวนพยานที่ได้รับมอบหมาย ไม่ใช่เรื่องยากที่จะเห็นว่า โดยทั่วไป เมื่อจำนวนผู้ตรวจสอบเพิ่มขึ้น อัตราพยานจะลดลง แต่ในตัวอย่างที่ 3 แม้ว่าจำนวนผู้ตรวจสอบจะมีเพียง 2k แต่อัตราการเป็นพยานนั้นต่ำกว่าอัตราพยานที่ 6k หรือแม้แต่ 10k
เราแบ่งสัดส่วนของผู้ตรวจสอบแต่ละคนตามช่วง และได้รับข้อมูลต่อไปนี้:
คำอธิบายภาพ
เนื่องจากจำนวนผู้ตรวจสอบในแต่ละอินสแตนซ์แตกต่างกัน อัตราส่วนการแปลงจะง่ายขึ้น:
คำอธิบายภาพ
ตารางที่ 5
ด้วยเหตุนี้ เราได้ตรวจสอบบันทึกของอินสแตนซ์ 3 และพบว่าการเชื่อมต่อระหว่าง Beacon Chain Node กับโหนดอื่นๆ และ ETH1.0 ไม่เสถียร สันนิษฐานว่าสิ่งนี้ทำให้เกิดอัตราการพบเห็นที่ผิดปกติซึ่งจำเป็นต้องตรวจสอบในภายหลัง
ชื่อเรื่องรอง
ในการทดสอบรอบนี้ เราสังเกตข้อมูลดัชนีประสิทธิภาพในตารางต่อไปนี้:
คำอธิบายภาพ
Beacon Chain Node
ตารางที่ 6
Validator Node
ในอินสแตนซ์ 1-5 การใช้งาน CPU ของ Beacon Chain Node อยู่ระหว่าง 5% ถึง 10% และการใช้งาน CPU ของ Beacon Chain Node ในอินสแตนซ์ 6 อยู่ที่ประมาณ 12% หน่วยความจำเพิ่มขึ้นอย่างต่อเนื่องระหว่าง 12% ถึง 17% และไม่มีความแตกต่างอย่างมีนัยสำคัญในดิสก์ IO และแบนด์วิธ
นอกจากนี้ สำหรับการสร้างไฟล์คีย์การตรวจสอบ เราใช้บรรทัดคำสั่งไพธอนที่แนะนำเครื่องมือประสิทธิภาพของเครื่องมือนี้ในการสร้างคีย์ค่อนข้างต่ำ ใช้เพียง 1 คอร์ในเครื่องมัลติคอร์ และใช้เวลาประมาณ 2.5 ชั่วโมงในการสร้างคู่คีย์ 2,000 คู่ ในทางกลับกัน คู่คีย์นำเข้าของ Validator Node ยังเป็นการดำเนินการแบบคอร์เดียว และเวลาในการนำเข้าคู่คีย์ 2,000 คู่คือประมาณ 40 นาที
ชื่อเรื่องรอง
จากการทดสอบรอบนี้ เราสังเกตเห็นในเครือข่ายส่วนตัวว่าการเพิ่มจำนวนของ Validator จะส่งผลต่ออัตราการผลิตบล็อกของ Validator ทั้งหมดบนโหนด สำหรับ Validator เดียว ในกรณีที่ดีที่สุดและกรณีที่แย่ที่สุด ค่าเฉลี่ยของ Witness น้อยลงประมาณ 10 บล็อกต่อวัน ในแง่ของการสร้างบล็อก เราไม่พบความแตกต่างในการทดสอบของเรา เมื่อเทียบกับ CPU และแบนด์วิธ การใช้หน่วยความจำและดิสก์ IO จะเพิ่มขึ้นอย่างเห็นได้ชัดเมื่อจำนวนตัวตรวจสอบความถูกต้องเพิ่มขึ้น
ชื่อเรื่องรอง
แผนการทดสอบและขั้นตอนที่ตามมาเพื่อเพิ่มประสิทธิภาพ
ในการทดสอบรอบนี้ ประเด็นต่อไปนี้ใช้เวลาในการเตรียมการมากขึ้น:
การสร้างคู่คีย์ตัวรับรองความถูกต้อง
ปรับใช้สัญญาเงินฝาก
คู่คีย์นำเข้า Validator Node
ในแผนติดตามผล มีการวางแผนที่จะเพิ่มประสิทธิภาพขั้นตอนข้างต้นเพื่อปรับปรุงประสิทธิภาพการทดสอบ
นอกจากนี้ ในแผนการทดสอบติดตามผล เมื่อพิจารณาความเสถียรระหว่างเครือข่ายในภูมิภาคต่างๆ และผลกระทบต่อตัวบ่งชี้ตัวตรวจสอบความถูกต้อง การปรับปรุงต่อไปนี้สามารถพิจารณาได้:
เพิ่มอินสแตนซ์ทดสอบหลายรายการในภูมิภาคเดียวกันเพื่อเปรียบเทียบว่าความแตกต่างนั้นเกิดจากภูมิภาคนั้นหรือไม่
ปรับใช้โหนด ETH1.0 หลายโหนดเพื่อให้ Beacon Chain Node เชื่อมต่อกับเครือข่าย ETH1.0 ได้อย่างราบรื่นและลดผลกระทบ
เพิ่มการทดสอบเปรียบเทียบแยกต่างหากในภูมิภาคเดียวกัน เพิ่มจำนวนผู้ตรวจสอบ ตัวแปรควบคุม และเปรียบเทียบผลกระทบของจำนวนผู้ตรวจสอบในแง่ของข้อมูลสถิติ ให้พิจารณาเพิ่มมิติต่างๆ เช่น การพิจารณาระยะทางของวัตถุพยาน เป็นต้น คุณสามารถอ้างอิงบทความนี้เกี่ยวกับบทความ.
ชื่อระดับแรก
สรุปแนวข้อสอบ
เมื่อเพิ่มจำนวนผู้ตรวจสอบเกือบ 4k แล้ว Validator Node จะรายงานว่าขนาดข้อความ 5350532 (5M) ที่ได้รับจาก grpc นั้นเกินค่าสูงสุดที่ 4194304 (4M)
คำอธิบายภาพ
รูปที่ 4
วิธีแก้ไข: ใช้พารามิเตอร์ --grpc-max-msg-size เพื่อเพิ่มขนาดข้อความที่อนุญาตโดย grpc เมื่อเริ่มต้นโหนดเครื่องมือตรวจสอบความถูกต้อง
ในรอบแรกของการทดสอบ เมื่อมี Beacon Chain Node เพียงสองโหนดในเครือข่าย มีแนวโน้มที่จะเกิดปัญหาที่ไม่สามารถซิงโครไนซ์บล็อกระหว่างโหนดทั้งสองได้ และทั้งสองโหนดไม่ถือว่าโหนดอื่นเป็นเพียร์ที่เหมาะสม ดังที่แสดงด้านล่าง:
คำอธิบายภาพ
รูปที่ 5
วิธีแก้ไข: ขณะนี้เราแก้ปัญหาด้วยการล้างการซิงค์ข้อมูลของโหนดอีกครั้ง ในระหว่างการทดสอบ เราพบว่าเมื่อจำนวนโหนด Beacon Chain เพิ่มขึ้น ปัญหานี้จะไม่เกิดขึ้นอีก
จำนวนเงินฝากไม่เพียงพอที่รายงานผิดissueซึ่งได้รับการแก้ไขในเวอร์ชันล่าสุดของรายงานนี้
คำอธิบายภาพ
