Beam Sync: วิธีใหม่ในการซิงค์โหนด Ethereum
หมายเหตุบรรณาธิการ: บทความนี้มาจาก:ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)
, ผู้แต่ง: Jason Carver, แปลและพิสูจน์อักษร: Chen Liang & A Jian, พิมพ์ซ้ำโดยได้รับอนุญาตจาก Odaily
ข้อความ
เหตุใดจึงต้องปรับปรุงประสบการณ์การซิงค์โหนด
มันทำให้ฉันประจบประแจงเล็กน้อยเมื่อนึกถึงจำนวนคนที่ยังคงใช้ Infura (ผ่าน Metamask, Gnosis-Safe ฯลฯ ) เพื่อโต้ตอบกับแอปพลิเคชันบนเครือข่าย บริการของ Infura นั้นยอดเยี่ยม แต่ก็เห็นได้ชัดว่าไม่ถูกต้องหากผู้ใช้ส่วนใหญ่ไม่ได้เรียกใช้โหนดของตนเอง แม้แต่นักพัฒนาที่มีความสามารถและมีแรงจูงใจสูงก็ไม่สามารถเลิกพึ่งพา Infura ได้โดยสิ้นเชิง ณ จุดนี้ เรายังดำเนินการส่วนสำคัญของวิสัยทัศน์ "การตรวจสอบตนเอง" ของ Ethereum ให้เสร็จสิ้น
ทีมงานของเราต้องการเป็นส่วนหนึ่งในการพลิกกลับแนวโน้มนี้ ภารกิจของเราคือการเพิ่มจำนวนโหนดบนเครือข่ายให้มากที่สุด โดยเฉพาะโหนดที่ดำเนินการโดยมือสมัครเล่น นักวิจัย และนักพัฒนา เมื่อเราถามว่าทำไมพวกเขาถึงไม่รันโหนดของตัวเอง คำตอบคือ: "ฉันติดตั้งซอฟต์แวร์ไคลเอ็นต์ และพยายามซิงค์บล็อกเชน แต่ดูเหมือนจะไม่ซิงค์เลย ฉันจึงหยุดเพราะฉันมีสิ่งอื่นที่ต้อง ทำ."
ชื่อระดับแรก
วิธีการซิงโครไนซ์ที่มีอยู่
ชื่อเรื่องรอง
Full Sync (วิธีการซิงโครไนซ์แบบเต็ม)
วิธีการซิงโครนัสอย่างสมบูรณ์คือการดำเนินการทุกบล็อกตั้งแต่บล็อกการกำเนิด บล็อกการกำเนิดทำเครื่องหมายสถานะการกำเนิดเริ่มต้น (เนื้อหาของสถานะรวมถึงยอดคงเหลือในบัญชี, รหัสไบต์ของสัญญา, เนื้อหาการจัดเก็บสัญญา ฯลฯ ) สิ่งที่เรียกว่า "execution block" หมายความว่าทุกครั้งที่มีการดาวน์โหลดบล็อก สถานะก่อนหน้าจะถูกอ่านและสถานะใหม่จะถูกสร้างขึ้น (ตามเนื้อหาของบล็อก) และสถานะใหม่จะถูกใช้เพื่อตรวจสอบสถานะรูทใน ส่วนหัวของบล็อก (เพื่อตรวจสอบว่าบล็อกบล็อกไม่ใช่บล็อกที่ถูกต้อง) การซิงค์แบบเต็มนั้นช้ามากบน Ethereum mainnet และเมื่อเครือข่ายมีอายุมากขึ้น การซิงค์กับบล็อกล่าสุดจะใช้เวลานานขึ้นเรื่อย ๆ โดยใช้วิธีซิงค์แบบเต็ม ดังนั้นผู้คนจึงพัฒนาวิธีการ "ซิงค์อย่างรวดเร็ว"
ชื่อเรื่องรอง
Fast Sync (วิธีการซิงโครไนซ์อย่างรวดเร็ว)
ก่อนที่การซิงค์อย่างรวดเร็วจะดำเนินการบล็อกเริ่มต้น สถานะบล็อกที่จำเป็นประกอบด้วย: สัญญาไบต์โค้ด บัญชี และเนื้อหาพื้นที่จัดเก็บตามสัญญา อาจต้องอ่านค่าใด ๆ เหล่านี้เมื่อทำธุรกรรม ดังนั้น วิธีการซิงค์ด่วนจำเป็นต้องได้รับสแน็ปช็อตของสถานะก่อนที่บล็อกจะเริ่มต้นจากเพียร์อื่นๆ สแนปชอตถูกทำเครื่องหมายด้วยค่าแฮชรูทสถานะ ค่าแฮชรูทสถานะที่เรียกว่าคือค่ารูททรี Merkle ของเนื้อหาสถานะทั้งหมด โหนดใช้แฮชรูทสถานะนี้เพื่อตรวจสอบว่าข้อมูลสถานะที่ดาวน์โหลดจากเพียร์อื่นๆ ตรงกับสถานะที่อ้างสิทธิ์โดยคนขุดแร่ในบล็อก
หลังจากที่วิธีซิงค์เร็วดาวน์โหลดสถานะที่จำเป็นทั้งหมดแล้ว หมายความว่าโหนดมีข้อมูลทั้งหมดที่จำเป็นในการดำเนินธุรกรรมอยู่แล้ว จากจุดนี้ไป โหนดสามารถเปลี่ยนเป็นโหมดการซิงโครไนซ์เต็มรูปแบบได้ และบล็อกสามารถดำเนินการได้ทีละบล็อกจากบล็อกเริ่มต้น เช่นเดียวกับโหนดที่เสร็จสิ้นกระบวนการซิงโครไนซ์เต็มรูปแบบก่อนบล็อกเริ่มต้น
ชื่อเรื่องรอง
วิธีการอื่นๆ
วิธีการซิงค์ด่วนอื่นๆ ได้แก่ Warp Sync ตลอดจนวิธีการซิงค์บางวิธีที่ยังไม่ได้รับการพิสูจน์ในปัจจุบัน ในระดับที่เป็นนามธรรมมากขึ้น ทั้งหมดนี้เป็นของวิธีการซิงโครไนซ์ที่รวดเร็วในรูปแบบต่างๆ นอกจากนี้ แม้แต่การทำความเข้าใจหลักการของวิธีการซิงโครไนซ์อื่นๆ เหล่านี้ก็ไม่ได้ช่วยให้เข้าใจกลยุทธ์การซิงโครไนซ์บีม ดังนั้นหลักการซิงโครไนซ์เหล่านี้จึงไม่ใช่จุดเน้นของบทความของเรา และฉันจะพูดถึงเรื่องนี้ในภายหลัง
ชื่อระดับแรก
วิธีการซิงค์ด่วนเร็วแค่ไหน?
วิธีการซิงโครไนซ์อย่างรวดเร็วเผชิญกับความท้าทายบางอย่างในสภาพแวดล้อมการทำงานเครือข่ายหลักในปัจจุบัน เนื่องจากการซิงโครไนซ์จำเป็นต้องดาวน์โหลดข้อมูลจำนวนมาก แม้กระทั่งข้อมูลมากกว่า 100GB ดังนั้นจึงอาจเป็นไปได้ในขั้นตอนที่สอง "รับสถานะทั้งหมด" ที่แสดงด้านบน รูปจะติดอยู่เป็นเวลานาน
หากคุณไม่สามารถดาวน์โหลดข้อมูลสถานะทั้งหมดใน 30 นาที (การแจ้งเตือนสปอยเลอร์: คุณไม่สามารถเสร็จสิ้นได้จริงๆ) คุณต้องทำเดือย (เดือย) นั่นคือเปลี่ยนเป็นบล็อกการบูตใหม่และเริ่มการซิงโครไนซ์ใหม่ แม้ว่าจะไม่ใช่จาก 0 แต่ก็เพิ่มเวลาในการดาวน์โหลดและตรวจสอบบล็อกด้วย
ชื่อระดับแรก
ภาพรวม
วิธีการซิงค์ลำแสง
ชื่อเรื่องรอง
วิธีการซิงโครไนซ์แบบบีมเป็นผลมาจากการปรับปรุงวิธีการซิงโครไนซ์แบบเร็วโดยตรง ข้อแตกต่างระหว่างวิธีการซิงโครไนซ์สองแบบคือ วิธีการซิงโครไนซ์แบบบีมจะดำเนินการบล็อกเริ่มต้นโดยตรงที่จุดเริ่มต้น และขอเฉพาะข้อมูลสถานะที่ขาดหายไปในฐานข้อมูลในเครื่อง และทำให้สถานะอินพุตและสถานะเอาต์พุตบันทึกในเครื่อง หลังจากดำเนินการบล็อก บล็อกจะซิงค์กับบล็อกถัดไปและทำกระบวนการซ้ำ โดยขอข้อมูลที่ขาดหายไปตามต้องการ
เมื่อเวลาผ่านไป ข้อมูลที่หายไปจะน้อยลงเรื่อยๆ โปรดทราบว่าหากไม่มีการเข้าถึงสถานะใดสถานะหนึ่ง ไคลเอนต์จะไม่ร้องขอ (และจะไม่ได้รับข้อมูลสถานะส่วนนี้) ดังนั้นเราจึงเรียกใช้กระบวนการอื่นในเบื้องหลังเพื่อเติมเต็มช่องว่างเหล่านี้ ด้วยกระบวนการทดแทนนี้ ในที่สุด Beam Sync จะดึงข้อมูลสถานะทั้งหมดและบันทึกลงในเครื่อง จากนั้นโหนดสามารถเปลี่ยนเป็นสถานะที่ซิงค์อย่างสมบูรณ์ได้
เราอ้างถึงชุดข้อมูลที่จำเป็นในการดำเนินการแต่ละบล็อกว่า "พยานการบล็อก" ด้วยโครงสร้างของ Merkle tree เราสามารถพิสูจน์ได้ว่าข้อมูลของพยานนั้นนำมาจากสถานะนี้จริง ๆ โดยไม่ต้องดาวน์โหลดสถานะทั้งหมด (หมายเหตุของผู้แปล: นี่คือสิ่งที่เรียกว่า "หลักฐานของ Merkle")
ชื่อเรื่องรอง
เพื่อความง่าย เราใช้ "ขนาดข้อมูลพยานบล็อก" เพื่ออ้างถึงจำนวนองค์ประกอบข้อมูลที่จำเป็นในการดำเนินการบล็อก องค์ประกอบข้อมูลดังกล่าวอาจเป็นโหนดบนแผนผังสถานะของบัญชีหลัก หรือโหนดบนแผนผังการจัดเก็บสัญญา หรือรหัสไบต์ที่สมบูรณ์ของสัญญา (หมายเหตุผู้แปล: "แผนผังสถานะ" ในที่นี้ "แผนผังการจัดเก็บ" เป็นโครงสร้างแบบต้นไม้ Merkle ทั้งหมด ข้อมูล).
การวิเคราะห์ขนาดข้อมูลพยานบล็อกเป็นกุญแจสำคัญในการทำความเข้าใจประสิทธิภาพของวิธีการซิงโครไนซ์บีม วิธีการซิงค์ด่วนต้องดาวน์โหลดข้อมูลสถานะทั้งหมดก่อนที่จะดำเนินการบล็อกแรก (เช่น บล็อกเริ่มต้น) ในขณะที่การซิงค์บีมจำเป็นต้องดาวน์โหลดข้อมูลพยานของหนึ่งบล็อกเท่านั้น หากข้อมูลพยานบล็อกที่ดาวน์โหลดมีสถานะที่สมบูรณ์หนึ่งในสาม หนึ่ง จากนั้น Beam Sync จะทำงานอย่างมีประสิทธิภาพเป็นสามเท่าของ Fast Sync
เห็นได้ชัดว่า ขั้นตอนต่อไปคือการดูว่าข้อมูลพยาน mainnet มีขนาดใหญ่เพียงใด อาจยังเร็วเกินไปที่จะสรุปผลโดยตรง แต่ผลการทดสอบเบื้องต้นแนะนำว่า 3,000 โหนดต้นไม้สถานะเป็นค่าประมาณที่สมเหตุสมผล (ระดับความเชื่อมั่น 90%) ข้อมูลสถานะทั้งหมดของเครือข่ายหลักมีโหนดต้นไม้มากกว่า 300 ล้านโหนด
ชื่อเรื่องรอง
การปรับปรุงความเร็วสำหรับ Beam sync
มากำหนดเกณฑ์ใหม่: เวลา "เริ่มดำเนินการ" นี่คือเวลาที่ใช้ในการเริ่มต้นโหนดด้วยฐานข้อมูลที่ว่างเปล่าเพื่อเสร็จสิ้นการนำเข้าบล็อกล่าสุดทั้งหมด
หากบีมต้องการดาวน์โหลดโหนดแผนผังสถานะ 3,000 โหนดเท่านั้น และการซิงโครไนซ์แบบเร็วจำเป็นต้องดาวน์โหลดโหนดต้นไม้ 300 ล้านโหนด เราสามารถกำหนดขีดจำกัดความเร็วของวิธีการซิงโครไนซ์ลำแสงได้: เมื่อซิงโครไนซ์ mainnet อาจอยู่ในเวลา "เริ่มดำเนินการ" รับเพิ่มสูงถึง 100,000x!
อย่างไรก็ตาม วิธีการใช้ Beam Sync มักจะไม่ได้รับการปรับปรุง 100,000 เท่าอย่างแท้จริง เหตุผลรวมถึงแต่ไม่จำกัดเพียง:
ข้อมูลพยานบล็อกถูกกำหนดตามความต้องการ ซึ่งหมายความว่าเราไม่สามารถคาดการณ์ล่วงหน้าได้ว่าข้อมูลสถานะใดที่จำเป็น (หลังจากได้รับข้อมูลหนึ่งเท่านั้น เราจึงสามารถระบุได้ว่าข้อมูลที่จำเป็นถัดไปคืออะไร) ดังนั้นเมื่อเราขอข้อมูลจากเพียร์โหนด เราสามารถขอข้อมูลสถานะได้ครั้งละหนึ่งข้อมูลเท่านั้น ในทางตรงกันข้าม Fast Sync สามารถขอโหนดต้นไม้ได้สูงสุด 384 โหนดในแต่ละครั้ง ซึ่งทำให้ Beam Sync ไวต่อเวลาแฝงของเครือข่ายเพียร์มากขึ้น
การค้นหาโหนดซิงค์คุณภาพสูงและเวลาแฝงต่ำต้องใช้เวลา ตามจริงแล้ว โหนดเพียร์ประเภทใดที่จะเจอนั้นเป็นเหตุการณ์สุ่มอย่างแท้จริง
วิธีการซิงก์บีมจะดาวน์โหลดสถานะการบล็อกต่อไปหลังจากบล็อกเริ่มต้น ซึ่งแตกต่างจากวิธีซิงค์เร็ว ซึ่งจะทำให้เวลานำเข้าบล็อกช้าลงด้วย หากคุณมีสัญชาตญาณเกี่ยวกับเรื่องนี้ คุณอาจสังเกตเห็นว่าหากเวลาเฉลี่ยในการรวบรวมพยานการบล็อกนานกว่าเวลาเฉลี่ยในการสร้างบล็อก แสดงว่าปัญหานั้นรุนแรงขึ้น
ชื่อเรื่องรอง
ลำแสงซิงค์ล่าช้า
ความล่าช้าในการรวบรวมข้อมูลพยานบล็อกอาจค่อยๆ เพิ่มขึ้น จากนั้นคุณจะพบว่าโหนดการซิงค์บีมของคุณล่าช้าไป 5 นาที กล่าวคือ บล็อกล่าสุดที่คุณมีในเครื่องนั้นเป็นบล็อกที่สร้างขึ้นโดยทั้งเครือข่ายเมื่อ 5 นาทีที่แล้ว ซึ่งหมายความว่าเมื่อ RPC เรียกยอดคงเหลือในบัญชีโหนดปัจจุบันของคุณ โหนดของคุณจะตอบกลับยอดคงเหลือเมื่อห้านาทีที่แล้ว
Beam Sync Pivot
ในการทดสอบโดยสรุป เป็นเรื่องปกติที่เวลาล่าช้าจะแตกต่างกันไปอย่างมาก ตั้งแต่ 1 นาทีถึง 20 นาที โชคดีที่เรามีเคล็ดลับบางอย่างสำหรับการกู้คืนจากการบล็อกซิงค์ที่ล้าหลัง และอันที่จริง โดยทั่วไปแล้ว ยิ่งคุณตามหลังคุณมากเท่าไหร่ คุณก็จะฟื้นตัวได้ดีขึ้นเท่านั้น ซึ่งนำไปสู่ความผันผวนอย่างมากในเวลาล่าช้า: ตามมาด้วยการติดตามอย่างรวดเร็ว และ วนซ้ำ
เหตุผลหนึ่งที่เราสามารถไล่ตามได้เร็วกว่าหากบล็อกอยู่ข้างหลัง คือเราสามารถสร้างข้อมูลพยานสำหรับบล็อกหลายบล็อกล่วงหน้าและพร้อมกันได้ ท้ายที่สุด คุณสามารถใช้ประโยชน์จากบล็อกในอนาคตเหล่านี้ได้ก็ต่อเมื่อคุณตามไม่ทันเท่านั้น แน่นอนว่าหากเวลาที่ใช้ในการรวบรวมข้อมูลบล็อกที่ต้องการนั้นเกินเวลาการสร้างบล็อกเสมอ ไม่ต้องสงสัยเลยว่าคุณจะล้าหลังการเติบโตของบล็อกเชนมากขึ้นเรื่อยๆ เราหวังว่าสิ่งนี้จะไม่เกิดขึ้น แต่เราต้องการ วางแผนสำหรับสิ่งนี้
ชื่อเรื่องรอง
กลไกการหมุนในบีมซิงค์นั้นเหมือนกับในซิงค์เร็ว โหนดของคุณเลือกชุดของบล็อกที่จะข้าม และเลือกส่วนหัวของบล็อกใหม่ใกล้กับด้านบนสุดของเชน จากนั้นบีมซิงค์จะเริ่มต้นอีกครั้ง และโหนดนั้นไม่ตรง ซิงค์ตั้งแต่ต้น แต่ก็ยังมีข้อมูลทั้งหมดจากการซิงค์ครั้งก่อน
เอาล่ะ มาดูกันว่าสถานการณ์จริงจะเป็นอย่างไร
ชื่อระดับแรก
บีมซิงค์บนไคลเอ็นต์ Trinity
ชื่อเรื่องรอง
ประกาศต้นแบบ
ไคลเอ็นต์ Trinity เวอร์ชันอัลฟาใหม่ได้รับการประกาศเมื่อสัปดาห์ที่แล้ว และเวอร์ชันนี้มีต้นแบบของวิธีการซิงโครไนซ์ของ Beam ที่ทำงานบนฮาร์ดแวร์ระดับไฮเอนด์
หมายเหตุ: การเพิ่ม Gas Limit ของบล็อกจาก 8M เป็น 10M ดูเหมือนจะเพิ่มเวลาหน่วงโดยเฉลี่ย และการอัปเกรดอิสตันบูลอาจลดเวลาหน่วงเนื่องจากจะเพิ่มปริมาณการใช้ก๊าซที่จำเป็นในการเขียนข้อมูลสถานะบนบล็อกเชน
ปัจจุบัน Trinity ยังเป็นเวอร์ชันอัลฟ่าและเวอร์ชันล่าสุดยังมีปัญหามากมาย เช่น การซิงโครไนซ์อาจหยุดกะทันหันหลังจากผ่านไปหนึ่งหรือสองวัน การติดตั้งไคลเอนต์ Trinity จำเป็นต้องทำงานเพิ่มเติม และเอาต์พุตบรรทัดคำสั่งก็ยุ่งเหยิง ดังนั้น Trinity ในขณะนี้จึงพร้อมสำหรับนักพัฒนาและนักวิจัยที่อยากรู้อยากเห็นและไม่รังเกียจที่จะเล่นกับมัน
โดยทั่วไปแล้วปัญหาที่ไม่ได้รับการแก้ไขจะถูกเปิดเผยในการพัฒนารายวัน ดังนั้นปัญหาเหล่านี้จึงเป็น "จุดบกพร่องในบันทึกเบื้องหลัง" ณ จุดนี้ พูดได้อย่างปลอดภัยว่าไม่มีใครกังวลว่า Beam Sync จะเป็นความฝันที่ไม่มีวันเป็นจริง ความมั่นใจในการซิงโครไนซ์บีมนี้เป็นเรื่องใหม่ แต่เราก็คิดเช่นกันว่าอาจมีปัญหาที่ไม่ทราบอย่างกะทันหันให้แก้ไขในอนาคตเหมือนเมื่อเดือนที่แล้ว!
งานที่เหลือ
นอกจากการดีบักพื้นฐานและการนำไปใช้งานแล้ว เรายังมีงานอื่นๆ ที่ต้องทำอีกมากมาย Trinity ยังไม่ได้ใช้กลไกการทดแทนสำหรับสถานะ (เช่น การดาวน์โหลดเหตุการณ์ ธุรกรรม และข้อมูลเก่าก่อนบล็อกเริ่มต้น) ขณะนี้วิธีเดียวที่จะเปิดใช้งานกลไกการสลับคือการรีสตาร์ท Trinity และยังไม่ทราบการกำหนดค่าฮาร์ดแวร์ขั้นต่ำที่จำเป็นสำหรับวิธีการซิงโครไนซ์ลำแสง (เรายินดีให้ทุกคนช่วยเรารวบรวมข้อมูลที่เกี่ยวข้อง)
ปัญหาทั้งหมดข้างต้นอยู่ภายใต้การวิจัยและพัฒนาที่ใช้งานอยู่ และนี่เป็นเพียงหนึ่งในหลาย ๆ ผลงานเกี่ยวกับ Trinity ขอบคุณมูลนิธิ Ethereum สำหรับการสนับสนุนและสนับสนุนความพยายามเหล่านี้
ชื่อระดับแรก
มีอะไรใหม่เกี่ยวกับ Beam Sync?
วิธีการซิงโครไนซ์ลำแสงเช่นเดียวกับทฤษฎีอื่น ๆ นั้นขึ้นอยู่กับงานวิจัยก่อนหน้านี้ เราไม่ได้คิดค้นวิธีการเร่งความเร็วการซิงโครไนซ์โดยการดาวน์โหลดสถานะล่าสุดและข้ามการดำเนินการของบล็อกเก่า (วิธีการซิงโครไนซ์อย่างรวดเร็ว) เราไม่ได้คิดค้นวิธีการดำเนินการบล็อกโดยอาศัยข้อมูลพยานแทนสถานะสมบูรณ์เพื่อเร่งการดำเนินการให้เร็วขึ้น สำหรับรายละเอียด โปรดดูที่ ไคลเอนต์ไร้สัญชาติ
