อธิบายรายละเอียดว่า Ethereum 2.0 รวมเข้ากับ 1.0 อย่างไร
หมายเหตุบรรณาธิการ: บทความนี้มาจากข้อมูล Babbitt (รหัส: bitcoin8btc)หมายเหตุบรรณาธิการ: บทความนี้มาจาก
ข้อมูล Babbitt (รหัส: bitcoin8btc)
หมายเหตุ: ผู้เขียนต้นฉบับคือ Danny Ryan (djrtwo) ผู้ประสานงานของ Ethereum 2.0 ในบทความนี้ เขาได้แนะนำรายละเอียดว่า Ethereum 1.0 จะรวมเข้ากับ Ethereum 2.0 ได้อย่างไร ตามคำแนะนำของเขาในไคลเอนต์ชุดค่าผสม eth1+eth2 eth2 ไคลเอนต์สามารถจัดการกับความซับซ้อนของ PoS และ shard ฉันทามติ และไคลเอนต์ eth1 ที่แนบมาสามารถกลายเป็นกลไก eth1 ซึ่งสามารถจัดการกับความซับซ้อนของสิ่งต่าง ๆ เช่น สถานะ ธุรกรรม เครื่องเสมือน ฯลฯ
คำอธิบายภาพ
(ภาพจาก: tuchong.com)<-> eth2 ชื่อเรื่องรองความสัมพันธ์ระหว่างลูกค้า Ethereum 1.0 และ Ethereum 2.0
เนื่องจาก Vitalik เสนอ eth1 ในช่วงต้นเดือนธันวาคม 2019
ตั้งแต่นั้นมา มีการอภิปรายอย่างแข็งขันในหมู่นักวิจัยเพื่อพิจารณารูปแบบที่เป็นไปได้ของการควบรวมกิจการนี้จากมุมมองของซอฟต์แวร์ และความคาดหวังสำหรับการสร้างต้นแบบก็เพิ่มมากขึ้นเท่านั้น วิสัยทัศน์ของเราคือการสร้างไฮบริดที่งานฉันทามติหลักได้รับการจัดการโดยไคลเอ็นต์ Ethereum 2.0 (ต่อไปนี้จะเรียกว่าไคลเอ็นต์ eth2) ในขณะที่สถานะ/บล็อกได้รับการจัดการโดยเอ็นจิ้น Ethereum 1.0 (ต่อไปนี้จะเรียกว่าเอ็นจิ้น eth1) และ พวกเขาร่วมกันสร้างไคลเอ็นต์ที่รวมกัน eth1+eth2
บทความนี้มีเป้าหมายเพื่อแยกความรับผิดชอบระหว่างไคลเอ็นต์ eth2 และเอ็นจิน eth1 ที่แนบมาให้ชัดเจนยิ่งขึ้น เพื่อให้มีพื้นฐานที่ดีขึ้นสำหรับการสนทนา การเขียนข้อมูลจำเพาะ และการสร้างต้นแบบ โปรดทราบว่าบทความนี้ไม่ได้ระบุเฉพาะเจาะจงของโปรโตคอล (เช่น วิธีการที่แม่นยำซึ่งไคลเอ็นต์ eth1 เรียกกลไก eth2) และตัวอย่างใดๆ ที่รวมอยู่ในบทความนี้มีวัตถุประสงค์เพื่อช่วยในคำอธิบายและการสนทนาที่ตามมาเท่านั้น
เพื่อทำความเข้าใจเนื้อหาของบทความนี้ สิ่งที่ต้องมีก่อนคือคุณต้องคุ้นเคยกับแนวคิดของ Ethereum 2.0 และ Stateless Ethereum
ชื่อเรื่องรอง
การแบ่งงานที่ชัดเจน
โดยสรุป สิ่งที่เราคิดว่าเป็นไคลเอนต์ eth2 ในปัจจุบันจะจัดการกับ PoS หลักเช่นเดียวกับฉันทามติของชิ้นส่วน โดยพื้นฐานแล้ว โปรโตคอล eth2 และไคลเอนต์ eth2 ได้รับการออกแบบมาเป็นอย่างดีในการสร้างและเข้าถึงฉันทามติเกี่ยวกับ "สิ่ง" มากมาย ซึ่งเป็นห่วงโซ่ชิ้นส่วนจำนวนมากที่เต็มไปด้วยข้อมูลและสถานะ (ขั้นสุดท้าย) เมื่อเปรียบเทียบกับชั้นฉันทามติ PoW ในปัจจุบันของ eth1 แล้ว "ชั้นฉันทามติ" ของ eth2 นั้นก้าวหน้าและซับซ้อนกว่ามาก
วันนี้ ไคลเอนต์ eth1 มีชั้นฉันทามติที่ค่อนข้างเรียบง่ายและบาง มีเพียงเชนเดียว และ PoW จัดการกับความซับซ้อนส่วนใหญ่ในฮาร์ดแวร์นอกโปรโตคอล ความซับซ้อนและการเพิ่มประสิทธิภาพส่วนใหญ่ของไคลเอนต์ eth1 อยู่ที่ชั้นผู้ใช้ (รวมถึงการจัดเก็บ/การจัดการสถานะ การซิงโครไนซ์สถานะ การดำเนินการเครื่องเสมือน การประมวลผลธุรกรรม การรวมธุรกรรม ฯลฯ)
การแยกข้อกังวลนี้ทำให้เกิดการจับคู่ที่ดีเมื่อรวม eth1 เข้ากับ eth2 เป็นชาร์ด ไคลเอ็นต์ eth2 สามารถจัดการกับความซับซ้อนของ PoS และฉันทามติของชาร์ด และไคลเอนต์ eth1 ในเครือสามารถกลายเป็นเอ็นจิ้น eth1 ซึ่งสามารถจัดการสถานะการจัดการที่ซับซ้อนได้ ธุรกรรม เครื่องเสมือน และสิ่งที่ใกล้ชิดกับ userland
ชื่อเรื่องรอง
การเปลี่ยนแปลงน้อยที่สุดเพื่อให้ได้การสื่อสารในท้องถิ่น
วิธีรวมซอฟต์แวร์ไคลเอนต์ eth1 และ eth2 มีหลายวิธีที่ทำได้ (เช่น การควบรวมกิจการอย่างสมบูรณ์ การนำเข้า eth1 เป็นไลบรารี ผ่านโปรโตคอลการสื่อสารระหว่างทั้งสอง เป็นต้น) แต่ในบทความนี้ เราจะมุ่งเน้นไปที่หนึ่งใน แนวทางการบุกรุกน้อยที่สุดและเป็นโมดูล - โปรโตคอลการสื่อสารแบบเนทีฟระหว่างไคลเอนต์ eth2 และเอ็นจิ้น eth1 ที่ง่ายขึ้น
เนื่องจากความหลากหลายของการใช้งานไคลเอ็นต์ eth1 และ eth2 วิธีนี้ช่วยป้องกันซอฟต์แวร์ไคลเอนต์จากการถูกล็อคด้านใดด้านหนึ่ง ทำให้ทีมลูกค้ายังคงเป็นอิสระและมุ่งเน้นไปที่ความพยายามในการวิจัยและพัฒนาของตนเอง ทำให้โครงการซอฟต์แวร์ส่วนใหญ่มีความเสถียรสำหรับการสร้างต้นแบบอย่างรวดเร็ว
แล้วมันจะเป็นอย่างไร?
โดยคร่าวๆ ไคลเอนต์ที่รวม eth1+eth2 จะมีลักษณะดังนี้:
ในหมู่พวกเขา เครื่องยนต์ eth2 และเครื่องยนต์ eth1 ทำงานร่วมกัน และสื่อสารในพื้นที่ผ่าน RPC ที่ขับเคลื่อนโดยไคลเอนต์ eth2
ทั้งคู่จะดูแลอินเทอร์เฟซ p2p ของตัวเอง เชื่อมต่อกับเพียร์และจัดการโปรโตคอลเครือข่ายที่เกี่ยวข้องกับแต่ละโดเมนเฉพาะ
ลูกค้า Ethereum 2.0
Beacon Chain และ Beacon State (อ็อบเจกต์ฉันทามติหลักที่สร้างส่วนที่เหลือของระบบ)
เศษโซ่ (1, โซ่เศษ eth1, 2, เศษโซ่ข้อมูลอย่างเดียวจำนวนมาก);
การทำงานของ Mempool [ไม่แสดง] (การรับรอง การฝากเงิน การออก ฯลฯ)
อินเทอร์เฟซ P2P (1, ข้อมูลเลเยอร์ฉันทามติ, 2, รวมถึงซุบซิบบล็อกเศษ eth1);
RPC ไปยังเอ็นจิ้น eth1 (การโทรทั้งหมดขับเคลื่อนโดยไคลเอ็นต์ eth2)
เครื่องยนต์ Ethereum 1.0
เครื่องเสมือน EVM (การดำเนินการและการตรวจสอบ eth1 shard block);
อินเทอร์เฟซ P2P (1. การซุบซิบธุรกรรมบน Ethereum วันนี้ 2. การซิงโครไนซ์สถานะ 3. ไม่มีการซุบซิบบล็อกเศษ eth1);
ฉันทามติ
RPC จากลูกค้า eth2 (การโทรทั้งหมดขับเคลื่อนโดยไคลเอนต์ eth2);
ชื่อเรื่องรอง
ฉันทามติ
โดยเฉพาะอย่างยิ่ง กลไก eth1 ที่แนบมาต้องมีสิทธิ์เข้าถึงไคลเอนต์ eth2 เนื่องจากไม่สามารถรักษาฉันทามติของตนเองได้ ใน PoW ของ Ethereum วันนี้ ไคลเอ็นต์ eth1 จะตรวจสอบหลักฐานการทำงาน สร้างโครงสร้างแบบต้นไม้ และเรียกใช้กฎการเลือกทางแยกเพื่อค้นหาจุดสูงสุดของห่วงโซ่ ใน eth2 กลไกเหล่านี้ค่อนข้างแตกต่างกัน ซึ่งต้องอาศัยความเข้าใจอย่างลึกซึ้งเกี่ยวกับฉันทามติหลักของ eth2 ไคลเอนต์ eth2 ให้ข้อมูลล่าสุดเกี่ยวกับหัวโซ่เศษ eth1 เพื่อให้กลไก eth1 สามารถรักษามุมมองที่แม่นยำของสถานะของ eth1
เนื่องจากกลไก eth1 อาศัยไคลเอนต์ eth2 อย่างสมบูรณ์เพื่อส่งเสริมฉันทามติ เราจึงเสนอว่าการสื่อสารระหว่างไคลเอ็นต์ eth2 และกลไก eth1 เป็นวิธีการทั้งหมดบนกลไก eth1 ที่เรียกโดยไคลเอนต์ eth2 (เช่น addBlock, getBlockProposal เป็นต้น) สิ่งนี้จะบังคับใช้ความสัมพันธ์ของผู้นำ/ผู้ตามเพื่อลดความซับซ้อนของการให้เหตุผลของระบบและจำกัดตรรกะทางธุรกิจที่กลไก eth1 ต้องการ
จากลูกค้า eth2 และมุมมองที่เป็นเอกฉันท์หลัก เชนชาร์ด eth1 ได้รับการจัดการเกือบเหมือนกันกับเชนชาร์ดอื่นๆ ทั้งหมด (การเลือกทางแยก ครอสลิงก์ โครงสร้างบล็อก ลายเซ็น ฯลฯ) ความแตกต่างหลักคือเนื้อหาของชาร์ดบล็อกสามารถดำเนินการกับกลไก eth1 ได้ ดังนั้นรูปแบบของข้อมูลของชาร์ดบล็อก eth1 จะต้องสัมพันธ์กับ eth1 และต้องทำการตรวจสอบเพิ่มเติมเพื่อให้ดำเนินการได้สำเร็จ
ชื่อเรื่องรอง
สถานะ
eth2 มีสถานะที่เกี่ยวข้องกับฉันทามติหลัก ซึ่งเรียกว่า "สถานะสัญญาณ" ข้อมูลสถานะบีคอนมีขนาดเล็ก (ประมาณ 10-40MB เท่านั้น ขึ้นอยู่กับขนาดของชุดเครื่องมือตรวจสอบความถูกต้อง) และมีข้อมูลทั้งหมดที่จำเป็นในการทำความเข้าใจฉันทามติหลักและวิธีจัดการกับห่วงโซ่เศษ ในความเป็นจริง ในการจัดการส่วนที่เกี่ยวข้องกับฉันทามติของเชนชาร์ด ไคลเอนต์ต้องมีสิทธิ์เข้าถึงสถานะบีคอน (เช่น ครอสลิงค์ล่าสุดที่รันการเลือก shard chain fork ชุดการตรวจสอบปัจจุบัน หรือการสับเปลี่ยนที่ได้รับมอบหมายแบบสุ่ม)
สถานะของ eth2 จะไม่โต้ตอบกับสถานะของเลเยอร์ผู้ใช้เสมอไป และการโต้ตอบที่สำคัญที่สุดคือความพร้อมใช้งานของข้อมูลเชนย่อย รูทข้อมูลเลเยอร์ผู้ใช้จริงจะอยู่ในข้อมูลเชนชาร์ด และสำหรับเชนชาร์ด eth1 มันคือรูทสถานะผู้ใช้ Ethereum ปัจจุบัน
กรณีต่างๆ ของสถานะ eth1 ที่เกี่ยวข้องกับไคลเอนต์ eth2 มีการกล่าวถึงด้านล่าง:
3. สำหรับไคลเอนต์ eth2 ที่มีเอ็นจิ้น eth1 แบบมีสถานะเพื่อเรียกใช้ตัวตรวจสอบความถูกต้องที่สามารถสร้างบล็อกย่อย eth1 ได้ จะต้องใช้เอ็นจิ้น eth1 เพิ่มเติมและสถานะ eth1 ที่สมบูรณ์เพื่อเรียกใช้โปรโตคอล eth2 (นักพัฒนากำลังสำรวจวิธีการสร้างบล็อกไร้สถานะ แต่เราทำเช่นนั้น ไม่พูดให้เข้าใจง่ายๆ) บล็อกที่ถูกต้องใหม่สามารถสร้างขึ้นได้ตามความต้องการโดยใช้สถานะโลคัลและพูลหน่วยความจำธุรกรรม (TX mempool) (เพิ่มเติมเกี่ยวกับเรื่องนี้ด้านล่าง)
เครือข่าย
นอกจากตัวตรวจสอบความถูกต้องแล้ว โหนดผู้ใช้/แอปพลิเคชันจำนวนมากยังอาจทำงานด้วยกลไก eth1 ที่มีสถานะสมบูรณ์ เช่น ตัวสำรวจบล็อก โหนดเก็บถาวร ผู้ให้บริการสถานะ เป็นต้น
เครือข่าย
ENR
เพื่อความง่าย ในตอนแรก eth2 และ eth1 จะรักษาสแต็กเครือข่ายและโปรโตคอลแยกต่างหาก เพื่อตอบสนองต่อความรับผิดชอบที่เปลี่ยนไป (เช่น eth1 shard block gossip) ผู้พัฒนาได้เลิกใช้โปรโตคอล eth1 ที่มีอยู่บางส่วน (เช่น eth1 shard block gossip) และแทนที่ด้วยโปรโตคอล eth2 หลังจากขั้นตอนการสร้างต้นแบบเริ่มต้นหรือในขั้นต่อไป อาจจำเป็นต้องโอนย้ายโปรโตคอล eth1 ไปยัง libp2p เพื่อรวมเครือข่ายสแต็ก แต่ไม่บังคับ
ไคลเอนต์ eth2 และเอนจิ้น eth1 สามารถเข้าถึง discv5 DHT เดียวกันได้ แต่ค้นหาเพื่อนที่มีความสามารถเหมาะสมอย่างอิสระและรักษาการเชื่อมต่ออย่างอิสระ
ชื่อเรื่องรอง
ฟังก์ชัน eth1 (สถานะ ธุรกรรม ฯลฯ) แสดงโดยคีย์ eth (หรือ eth1 ใหม่) ที่มีอยู่ใน ENR
ฟังก์ชัน eth2 (ฉันทามติหลัก) แสดงโดยคีย์ eth2 ใน ENR
การมีอยู่ของแต่ละโปรโตคอลหมายความว่าโหนดสามารถและเต็มใจที่จะระบุประเภทของโปรโตคอลเครือข่ายพื้นฐาน
ชื่อเรื่องรอง
โปรโตคอลสาย
1. โปรโตคอล eth2 1. คำขอ / ตอบกลับ eth2 (1. สถานะ, 2. การซิงโครไนซ์บล็อก Beacon, 3. การซิงโครไนซ์ Shard block) 2. การซุบซิบฉันทามติหลัก (1. บล็อก Beacon, 2. การพิสูจน์, 3. บล็อก, รวมถึงการแบ่งส่วนย่อย eth1 , 4, การทำงานของตัวตรวจสอบอื่น ๆ ); 2, โปรโตคอล eth1 1, ชุดย่อยของโปรโตคอลสาย eth1 (1, การซุบซิบของธุรกรรม, 2, วิธีการซิงโครไนซ์ เช่น getnodedata หรือวิธีการใหม่, 3, รับใบเสร็จรับเงิน )
3. เหตุใดไคลเอนต์ eth2 จึงประมวลผล eth1 บล็อกการนินทา eth2 ถูกใช้เป็นพิเศษเพื่อจัดการการผลิต การนินทา และการตรวจสอบการบล็อกเศษ เป้าหมายของเราคือให้ชิ้นส่วน eth1 เป็นมาตรฐานและสอดคล้องกับชิ้นส่วนที่เหลือมากที่สุดเท่าที่จะเป็นไปได้ เกี่ยวกับฉันทามติหลัก ความแตกต่างที่สำคัญของบล็อก eth1 เมื่อเทียบกับชิ้นส่วนอื่น ๆ คือความสามารถในการดำเนินการ/ตรวจสอบเนื้อหาบล็อกกับเครื่องมือ eth1
เมื่อตัวตรวจสอบกำลังฟอร์กบล็อกชิ้นส่วน eth1 ไปยังบีคอนเชน ไคลเอนต์ eth2 จะเรียกกลไก eth1 อีกครั้งเพื่อดำเนินการและตรวจสอบความถูกต้องของบล็อก
เมื่อโหนดรวมสถานะ eth1+eth2 ได้รับ eth1 shard block ใหม่ ไคลเอนต์ eth2 จะเรียกกลไก eth1 อีกครั้งเพื่อตรวจสอบความถูกต้องของบล็อกและอัพเดตที่จัดเก็บสถานะในเครื่อง
ชื่อเรื่องรอง
ซุบซิบการทำธุรกรรมและ mempool พูลหน่วยเก็บข้อมูล
บล็อกชาร์ด eth1 ถูกป้อนไปยังเอนจิ้น eth1 จากไคลเอ็นต์ eth2 ที่แนบมา ธุรกรรมที่รวมอยู่ในบล็อกเหล่านี้ควรถูกกำจัดออกจากพูลหน่วยเก็บข้อมูลในลักษณะที่คล้ายกับบล็อก PoW ของ Ethereum mainnet ในปัจจุบัน
บล็อกการผลิต
บล็อกชาร์ด eth1 ถูกสร้างขึ้นจากเนื้อหาของพูลหน่วยเก็บข้อมูล mempool ตามไคลเอนต์ eth2 ที่แนบมา เมธอด RPC นี้และฟังก์ชันพื้นฐานคล้ายกับ getWork แต่จะส่งคืนเนื้อหาบล็อกทั้งหมด ไม่ใช่แค่แฮช
ชื่อเรื่องรอง
บล็อกการผลิต
สำหรับบล็อกบีคอนและบล็อกชาร์ดที่ไม่ใช่ eth1 ไคลเอนต์ eth2 มีทุกสิ่งที่จำเป็นในการสร้างบล็อกที่ถูกต้อง
สำหรับบล็อกย่อย eth1 ลูกค้า eth2 สามารถเข้าถึงสถานะ eth1 ธุรกรรม และโครงสร้าง eth1 พื้นฐานอื่นๆ ได้ทันที/ทุกเวลาเพื่อสร้างบล็อกที่ถูกต้อง ในทางกลับกัน เมื่อตัวตรวจสอบที่กำหนดสร้างบล็อก eth1 ไคลเอ็นต์ eth2 จะขอข้อมูลบล็อก eth1 ที่เป็นไปได้ (TX, รูทสถานะ ฯลฯ) จากกลไก eth1 จากนั้น ไคลเอ็นต์ eth2 จะแพ็คข้อมูลบล็อก eth1 นี้ลงใน shard block ที่สมบูรณ์ (เพิ่มช่อง, positer_index, positer_signature ฯลฯ) และเผยแพร่บล็อกไปยังเครือข่าย
กลไก eth1 สามารถสร้างข้อมูลบล็อก eth1 ที่ถูกต้อง/เป็นไปได้ เนื่องจากจัดการพูลหน่วยเก็บข้อมูลการทำธุรกรรม eth1 ในลักษณะเดียวกับที่ ethereum mainnet ใช้ในปัจจุบัน และยังคงรักษาสถานะหลักล่าสุดของ eth1 ผ่านการอัปเดตจากข้อมูลไคลเอนต์ eth2
ชื่อเรื่องรอง
ขั้นตอนต่อไปคืออะไร?
หากการออกแบบทั่วไปนี้ได้รับการยอมรับ ขั้นตอนต่อไปได้แก่:
ตรวจสอบให้แน่ใจว่าสมมติฐานเกี่ยวกับไคลเอนต์ eth2 ที่ขับเคลื่อนกลไก eth1 นั้นสอดคล้องกับซอฟต์แวร์ eth1 ที่มีอยู่ และไม่กำหนดภาระที่ไม่ได้ตั้งใจให้กับซอฟต์แวร์ eth1 ที่มีอยู่
กำหนดโปรโตคอลการสื่อสารที่ใช้ในการขับเคลื่อนกลไก eth1 ให้ชัดเจนยิ่งขึ้น เช่น new_head(block), validate_block_transition(block), get_proposal(parent_root) เป็นต้น;
กำหนดองค์ประกอบเครือข่าย เช่น ชุดย่อยของโปรโตคอล eth1 ที่จำเป็น และวิธีการใช้ ENR โดยเฉพาะ
