บทนำ

ในปี 2024 เกิดเหตุการณ์ที่สำคัญมากมายเกี่ยวกับ Ethereum เริ่มต้นของปี Ethereum ได้นำเสนอ blobs ผ่านการอัพเกรด Dencun ซึ่งได้ลดต้นทุนการทำธุรกรรมอย่างมากสำหรับ rollups ที่มีอยู่ ซึ่งเป็นการเปลี่ยนแปลงที่สำคัญที่มีพื้นฐานสำหรับการขยายตัวของระบบนิเวศ rollup อย่างรวดเร็ว

(การลดค่าธรรมเนียมใน OP Chains หลังจากการอัพเกรด Dencun | แหล่งที่มา:Optimism X)

อย่างไรก็ตาม ในขณะที่ dapps ภายในระบบนี้ย้ายไปใช้ระบบ rollups ที่มีความสามารถในการขยายขนาดสูงและเครือข่าย Layer 1 (L1) ทางเลือก กิจกรรมของผู้ใช้บน Ethereum เองก็เริ่มลดลง นอกจากนี้ เมื่อ rollups หยุดส่งค่าธรรมเนียมสูงให้ Ethereum ก็เริ่มเกิดความกังวลภายในชุมชน

นอกจากนี้ ปี 2024 เป็นปีที่ L1 ที่เน้นความสามารถในการขยายขึ้น เช่น Solana และ Sui ได้แสดงความแข็งแกร่งอย่างมีนัยสำคัญ ปริมาณ TPS (ธุรกรรมต่อวินาที) ที่มากมายที่เกิดจากเครือข่ายเหล่านี้ ทำให้กิจกรรมบน rollups ดูเล็กน้อยเป็นไปได้

ในบริบทนี้ เกิดข้อวิจารณ์ขึ้น เช่น 'แผนการเลื่อน Ethereum ที่เน้นการเลื่อนรวมไม่เหมาะสม' หรือ 'การพัฒนา Ethereum ช้าเกินไปที่จะประสบความสำเร็จ' แล้ว Ethereum จริงๆ อยู่บนเส้นทางที่ถูกต้องหรือไม่? Ethereum จะเป็นอย่างไรในปี 2025 หรือแม้แต่ 2030?

ซีรีส์นี้ลึกลงไปในส่วนต่าง ๆ ของแผนกำหนดเส้นทางของ Ethereum ภายใต้หัวข้อหลักสองเรื่อง ซึ่งวิเคราะห์อนาคตของ Ethereum ขึ้นอยู่กับรายละเอียดทางเทคนิค หัวข้อแรกคือ Beam Chain

ข้อเสนอ Beam Chain คืออะไรและทำไมมันสำคัญ?

หากใครเลือกเป็นหัวข้อที่ได้รับความสนใจมากที่สุดภายในชุมชน Ethereum ปีนี้ น่าจะเป็นประกาศของนักวิจัย Ethereum อย่าง Justin Drake เกี่ยวกับ Beam Chain ที่ Devcon ประกาศนี้ได้รับความสนใจอย่างมากและตามมาด้วยเสียงดังมาก มาเริ่มวิเคราะห์ว่าข้อเสนอนี้หมายความว่าอย่างไร

ความคิดหลักของข้อเสนอ Beam Chain คือการออกแบบชั้นความเห็นของ Ethereum ใหม่โดยสมบูรณ์แบบ จัสติน ดรเก้นนำเสนอเหตุผลทั้งสามต่อทำไมชั้นความเห็นปัจจุบันที่ชื่อ Beacon Chain ต้องถูกออกแบบใหม่:

• ความเข้าใจที่ดีขึ้นเกี่ยวกับ MEV ผ่านประสบการณ์ในอดีต
• การก้าวหน้าอย่างรวดเร็วในเทคโนโลยี SNARK (เช่นการพัฒนา zkVM ก้าวหน้าอย่างน่าแปลกใจ รวดเร็วกว่า 10 เท่า)
• กําจัด "หนี้ทางเทคนิค" ที่มีอยู่ใน Beacon Chain

ปัจจุบัน Ethereum มีองค์ประกอบ consensus layer ที่รวมถึงสิ่งต่อไปนี้:

ในนั้น บรรทัดที่ถูกทำเครื่องหมายด้วยตัวหนา แทนความเปลี่ยนแปลงพื้นฐานที่เกินกว่าการปรับเปลี่ยนทั่วไปใน Beacon Chain เช่นเช่นการ snarkification ของโซนของชั้นความเห็นร่วมกันไปยังเทคโนโลยี ZK ซึ่งต้องการการเปลี่ยนแปลงพื้นฐานตั้งแต่ฟังก์ชันแฮชไปจนถึงวิธีการของการสร้าง merkleizing/serializing state

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

Beam Chain ของ Gate มีแนวคิดที่จะปรับเปลี่ยนดังกล่าวผ่านการ hard fork เดียว สรุปได้ว่า:

1. การดำเนินการตามแผนการทำงานสำหรับชั้นสมดุลของ Ethereum ต้องการการออกแบบที่สมบูรณ์แบบของชั้นสมดุล
2. เพื่อให้บรรลุวัตถุประสงค์นี้ การเปลี่ยนแปลงสำคัญบนแผนที่จะถูกรวมเข้าด้วยกันในการ fork แบบยากที่ชื่อ Beam Chain
3. มันรวมทั้งสี่องค์ประกอบ: ช่วงเวลาบล็อกที่เร็วขึ้น, การทำให้เสร็จสิ้นไวขึ้น, การตกแต่งเชิงสุนทรีย์ของโซ่และความต้านทานทางควอนตัม

ต่อไป เรามาสำรวจวิธีการดำเนินงานของแต่ละส่วน และผลกระทบทางเทคนิคที่เกี่ยวข้อง

รายละเอียดทางเทคนิคของการออกแบบ Beam Chain

ช่องเร็วและความสมบูรณ์อย่างรวดเร็ว

ขณะนี้ Ethereum มีเวลาสล็อต 12 วินาที และใช้เวลา 2-3 ยุค (ประมาณ 15 นาที) เพื่อให้บล็อกที่เชื่อมต่อกับสล็อตมีความสมบูรณ์ การปรับปรุงเวลาเหล่านี้จะมีผลต่อผู้ใช้ Ethereum แอปพลิเคชันและ rollups ที่กำลังพัฒนาบน Ethereum ในทางบวก

ความสมบูรณ์ที่สั้นลง (Orbit SSF)

หัวข้อนี้ที่รู้จักกันในวงการวิจัย Ethereum ว่า SSF (Single Slot Finality) เป้าหมายคือลดเวลาในการถึงความสมบูรณ์ของบล็อก Ethereum จากประมาณ 15 นาทีเป็นเวลาในอีก 12 วินาที ทำให้ผู้ใช้ได้รับการยืนยันไวขึ้น ในการเข้าใจความสมบูรณ์แบบสล็อตเดียว เราต้องเข้าใจขั้นตอนการตรวจสอบข้อมูลปัจจุบันของ Ethereum ที่เรียก Gasper

หลักการออกแบบสำคัญของ Gasper คือการให้แน่ใจว่าบล็อกที่เสนอขึ้นในสล็อตจะได้รับระดับความปลอดภัยทางเศรษฐกิจในระยะเวลาที่กำหนดใด ๆ พร้อมลดภาระการสื่อสารบนผู้ตรวจสอบแต่ละคน โดย Ethereum แบ่งชุดผู้ตรวจสอบทั้งหมดเป็นคณะกรรมการที่แจกจ่ายไปยัง 32 สล็อต แต่ละสล็อตสามารถมีคณะกรรมการได้สูงสุด 64 คณะกรรมการ และเป้าหมายคือการประกอบคณะกรรมการแต่ละคณะที่มีผู้ตรวจสอบ 128 คน (แม้จำนวนนี้สามารถเพิ่มขึ้นได้หากจำนวนผู้ตรวจสอบที่ใช้งานเกินจำนวนนี้)

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

(การรวมลายเซ็น BLS ระหว่างผู้ตรวจสอบของ Ethereum | ที่มา: eth2book)

สรุปว่า Ethereum's Gasper บรรลุความคล่องตัวและความปลอดภัยทางเศรษฐกิจผ่านกลไกต่อไปนี้:

• Validators แบ่งเป็นสล็อตในคณะกรรมการตลอดระยะเวลา 6.4 นาที เพื่อลดความจำเป็นในการสื่อสารโดยตรงระหว่างผู้ตรวจสอบทั้งหมด
• กระบวนการลายมือชื่อรวมทำให้สามารถตรวจสอบโหวตของผู้ตรวจสอบบล็อกด้วยข้อมูลปริมาณเล็ก

อย่างไรก็ตาม มีปัญหาเกิดขึ้นเนื่องจาก Gasper ทำงานบนพื้นฐานของ epoch และ "ความเชื่อมต่อ" ระหว่าง epochs ต้องได้รับการยืนยันก่อนที่ช่องจะมาถึงความสมบูรณ์ที่สุด ใน Gasper จะต้องผ่านอย่างน้อยสอง epochs (64 ช่อง) ก่อนที่จะได้รับความสมบูรณ์เทียบเท่าความปลอดภัยทางเศรษฐกิจของ Ethereum ทั้งหมด

นี่เป็นผลลัพธ์ของการแสดงภาพเชิงภาพดังต่อไปนี้:

(ความสมบูรณ์ทางเศรษฐศาสตร์ที่ Gasper | แหล่งที่มา:Orbit SSF)

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

• เมื่อถอนเงินจาก CEX (ศูนย์กลางการซื้อขาย) ไปยัง Ethereum หรือกลับกัน ระยะเวลาการยืนยันอาจใช้เวลาประมาณ 10 นาทีซึ่งถือว่าเป็นเวลาที่ค่อนข้างนาน
• Ethereum rollups และ dApps อาจเผชิญกับความเสี่ยงที่บล็อก L1 ที่พวกเขาพึ่งพาอาจไม่ได้รับการเสร็จสิ้น และอาจกลายเป็นบล็อกที่ไม่ถูกต้อง หากไม่มีมาตรการป้องกันที่เหมาะสม นี่อาจสร้างปัญหา

ตัวอย่างเช่นในเดือนมีนาคม พ.ศ. 2567 โพลีกอน zkEVM ประสบปัญหาหยุดชั่วคราวเป็นเวลากว่า 2 วันเนื่องจากการจัดการ Ethereum reorg ไม่ถูกต้อง

การลดเวลาในการเสร็จสิ้นไม่ได้เป็นเรื่องที่เป็นไปไม่ได้ ตามที่ได้แสดงให้เห็นโดยอัลกอริทึมของความเห็นเหมือน Tendermint ที่ใช้ในโปรโตคอลหลายรายการแล้ว อย่างไรก็ตาม ความท้าทายของการนำกลไกของ Tendermint มาใช้คือการสื่อสาร P2P ที่ถูกใช้งานบ่อยครั้งระหว่างโหนดซึ่งเป็นการจำกัดความสามารถในการขยายขนาด

ใน Tendermint หากจำนวนของโหนดเป็น N ความซับซ้อนของข้อความของมันคือ O(N^3) ซึ่งหมายความว่าเมื่อจำนวนของโหนดเพิ่มขึ้น ความถี่ของการสื่อสารระหว่างพวกเขาเติบโตอย่างเรขาคณิต จำกัดความสามารถในการขยายขนาด ดังนั้นโปรโตคอลเช่น Ethereum ที่มีผู้ตรวจสอบมาก ไม่สามารถนำ Tendermint มาใช้โดยตรง

ต้องมีการทำงานเพิ่มเติมเพื่อแก้ไขปัญหาเหล่านี้เพื่อนำการตกลงแบบ Tendermint-style มาใช้กับ Ethereum

ภาพรวมของข้อเสนอ Orbit SSF

Orbit SSF มีเป้าหมายที่จะปรับเปลี่ยนกลไกคณะกรรมการของ Gasper เพื่อลดเวลาสำหรับการสิ้นสุดของสล็อตในขณะที่ยังคงรักษาความปลอดภัยทางเศรษฐกิจสูง

ข้อเสนอคือลดขนาดของเอพ็อคจาก 32 สล็อตเป็นสล็อตเดียว (~12 วินาที) อย่างไรก็ตาม, ดังที่กล่าวไว้ก่อนหน้านี้ นี้จะเพิ่มการใช้ทรัพยากรสำหรับการสื่อสารของผู้ตรวจสอบ ซึ่งจะมีผลกระทบทางลบต่อความกระจายของ Ethereum

เพื่อที่จะแก้ไขปัญหานี้ Orbit SSF ขอ предлагаетความคิดต่อไปนี้:

เพิ่มจำนวนเงินสุทธิสูงสุดสำหรับแต่ละ Ethereum validator สามารถทำให้มีระดับความปลอดภัยทางเศรษฐกิจเทียบเท่ากับจำนวน validator ที่น้อยลง

แทนที่การมีคณะกรรมการหลายคณะต่อสล็อต ออบิต SSF แนะนำให้นำเข้าคณะกรรมการเดียว "คณะกรรมการสุดยอด" ผู้ตรวจสอบที่มีจำนวนเงินที่มากกว่ามักจะถูกนำเข้าคณะกรรมการในอัตราสัมพันธ์ ซึ่งรักษาระดับความปลอดภัยทางเศรษฐกิจเดียวกันแม้ว่าจะมีคณะกรรมการน้อยลง

การอัพเกรด Ethereum ถัดไป ชื่อ Pectra รวมถึง EIP-7251 ที่เสนอเพิ่มยอดเงินสุทธิสูงสุดที่สามารถนำมาแสกน (MaxEB) สำหรับผู้ตรวจสอบจาก 32 ETH เป็น 2048 ETH ข้อเสนอนี้น่าสนใจสำหรับผู้ให้บริการโครงสร้างโหนด Ethereum และเป็นเงื่อนไขสำคัญสำหรับ Orbit SSF ด้วย

อย่างไรก็ตามหากผู้ตรวจสอบที่มีจำนวนเงินสุดยอดที่มีส่วนร่วมในคณะกรรมการเกือบทั้งหมดนั้นเล็กน้อย ตัวตรวจสอบเดี่ยวที่เล็กน้อยอาจพบว่ารางวัลลดลง ซึ่งอาจทำให้กระจายอำนาจของ Ethereum เกิดความเสียหาย ในการป้องกันเช่นนี้ Orbit SSF ปรับรางวัลเพื่อให้ APR เพิ่มขึ้นเป็นเส้นตรงกับจำนวนเงินที่มีส่วนร่วมในการลงทุน ในขณะที่ยังรักษาให้ผู้ตรวจสอบที่ใหญ่กว่ามีส่วนร่วมในคณะกรรมการบ่อยขึ้น

(รางวัลและความน่าจะเป็นที่จะเข้าร่วมในคณะกรรมการในโอบิต SSF | ที่มา:Orbit SSF)

นอกจากนี้ Orbit SSF ย้ายไปใช้ระบบ "committee-based finality" เพิ่มเติมใน Gasper คณะกรรมการสามารถมีส่วนร่วมในการตัดสินใจในระบบหลังจากผ่าน epoch สองหรือมากกว่า แต่ Orbit SSF อนุญาตให้คณะกรรมการที่ได้รับการกำหนด slot แต่ละช่องมีส่วนร่วมในการตัดสินใจในระบบในเวลาจริง เป้าหมายคือทำให้คณะกรรมการเป็นผู้มีส่วนร่วมที่มีการตัดสินใจอย่างเต็มที่และบรรลุประสิทธิภาพในการขยายมากขึ้นอย่างรวดเร็ว

(Finality in Orbit SSF using Cap-and-slow-rotate | Source:Orbit SSF)

ความสำคัญอยู่ที่การสร้างคณะกรรมการ แนวคิดของ Orbit SSF คือการใช้กลไก "หมุนช้า" โดยที่ผู้ที่มีสิทธิ์มากจะถูกกำหนดไว้ในคณะกรรมการและผู้ถือสิทธิ์น้อยกว่าจะถูกหมุนเข้าและออก นี่จะช่วยให้ค่า F ซึ่งแทนระดับความปลอดภัยทางเศรษฐศาสตร์ สามารถตั้งค่าได้อย่างสูง พร้อมทั้งลดการสื่อสารระหว่างผู้รับรองความถูกต้องให้ต่ำที่สุด และยังรักษาระยะเวลาในการถึงขั้นตอนสุดท้ายไว้อย่างต่ำที่สุด

ตัวอย่างเช่น การตั้งค่า n = 3 และ F ที่ใหญ่มากจะทำให้ Ethereum สามารถบรรลุความสมบูรณ์ในระยะเวลาประมาณสามสล็อต ซึ่งจะทำให้เกิดวิสัยทัศน์ของ Justin Drake เกี่ยวกับ FFG 3 สล็อต

อย่างไรก็ตาม การเพิ่ม F ให้เป็นระดับของชุดผู้ตรวจสอบทั้งหมดของ Ethereum ไม่ง่าย สามารถลดค่าใช้จ่ายในการดำเนินการโจมตี 51% บน Ethereum ได้ ดังนั้น ความท้าทายหลักสำหรับ Orbit SSF ในอนาคตคือการกำหนดวิธีเพิ่ม F ให้มั่นคงความปลอดภัยของ Ethereum โดยไม่เสียเปรียบมากนักในการกระจายอำนาจ

ช่วงเวลาสล็อตที่สั้นลง (สล็อต 4 วินาที) แม้ว่า SSF (หรือการสิ้นสุดช่อง 3 สล็อต) จะถูกบรรลุ ผู้ใช้ Ethereum ยังคงต้องรอการยืนยันธุรกรรมขั้นต่ำ 12 วินาที ซึ่งเป็นข้อเสียสำหรับผู้ใช้สองอย่างหลัก

1. ความหน่วงเหนี่ยวยาวเมื่อเปรียบเทียบกับ L1 อื่น ๆ เช่น Solana และ Sui
2. ความเสี่ยงที่สูงขึ้นต่อ MEV (MEV ลดลงเมื่อเวลาบล็อกสั้นลง ทำให้ผู้ใช้ Ethereum มีโอกาสต่อ MEV มากขึ้น)

นอกจากนี้เวลาบล็อก 12 วินาทียิ่งแย่มากสำหรับ rollups โดยเฉพาะ rollups ที่อ้างอิง ตัวอย่างเช่น Taiko ประยุกต์ใช้ rollup ที่อ้างอิงโดยโพสต์บล็อก L2 ทุกบล็อกใน L1 ด้วยผลลัพธ์ที่เวลาบล็อกของ Taiko สามารถเพิ่มขึ้นไปถึง 12 วินาทีขั้นต่ำและบางครั้งอาจเกิน 24 วินาที

มีวิธีการสองวิธีที่ได้รับการเสนอเพื่อแก้ไขปัญหานี้:

a. ลดเวลาบล็อกของ Ethereum เป็น 4 หรือ 8 วินาที

b. ใช้ preconfirmations

ลดเวลาบล็อกของ Ethereum

การลดเวลาบล็อกของ Ethereum เป็นหัวข้อที่ถูกพูดถึงอย่างหนัก. มันได้ถูกกำหนดเป็น EIP-7782 ที่เสนอให้ลดเวลาสล็อตจาก 12 วินาทีเป็น 8 วินาที เพื่อเพิ่มความสามารถในการขยายขนาดของ Ethereum ถึง 33%. อย่างไรก็ตามการใช้เวลาสล็อต 8 วินาทีอาจไม่เหมาะสมสำหรับประสบการณ์ผู้ใช้หรือระบบ rollup ที่พึ่งพากัน. การบรรลุเวลาสล็อตที่สั้นลงดูเป็นไปได้อย่างมีความปรารถนามากกว่า

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

สถิติเวลา传播บล็อคของ mainnet ของ Ethereum ให้ความเข้าใจในความเป็นไปได้ของเวลาบล็อค 4 วินาที กราฟด้านล่างแสดงการกระจายของเวลา传播บล็อค

(CDF ของเวลาการมาถึงของข้อความ | แหล่งที่มา:ความช้าในการแพร่กระจายข้อความ Gossipsub)

ประมาณ 98% ของบล็อกถูกแพร่กระจายในเวลา 4 วินาที ในขณะที่ประมาณ 2% ใช้เวลานานกว่านั้น จากข้อมูลนี้ จะเห็นได้ว่าเวลาบล็อก 4 วินาทีนั้นอาจเป็นไปได้ อย่างไรก็ตาม เวลาบล็อกไม่ได้คำนึงถึงการสื่อสารเท่านั้น แต่ยังรวมถึงการดำเนินการและการลงคะแนน ดังนั้น เฉพาะประมาณ 2 วินาทีเท่านั้นในเวลาบล็อก 4 วินาทีที่สามารถใช้สำหรับการสื่อสารได้ ภายใต้เงื่อนไขเหล่านี้ การบล็อกในเวลา 4 วินาทีจึงเป็นการท้าทาย

เพื่อแก้ไขปัญหานี้ ขนาดของข้อมูลที่ถูกส่งต้องลดลง ประสิทธิภาพขององค์ประกอบ P2P ในไคลเอ็นต์ต้องถูกสูงสุดหรือการสื่อสารทางกายภาพต้องเป็นไปอย่างมีประสิทธิภาพมากขึ้น

ใช้การยืนยันล่วงหน้า

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

ข้อดีของการยืนยันล่วงหน้าคือผู้ตรวจสอบ L1 สามารถใช้งานได้โดยไม่ต้องมีการปรับเปลี่ยนส้อมหรือไคลเอนต์ ตัวอย่างเช่น Commit-Boost เป็นซอฟต์แวร์ที่ช่วยให้ผู้ตรวจสอบ Ethereum สามารถสร้างและเผยแพร่การยืนยันล่วงหน้าได้อย่างปลอดภัย

Commit-Boost เช่น MEV-Boost เป็นเครื่องมือเสริมทางเลือกสำหรับผู้ตรวจสอบ ที่ช่วยให้พวกเขาสามารถสร้างและแพร่กระจาย "การสัญญา" อย่างปลอดภัย ขึ้นอยู่กับกรณีการใช้งาน การสัญญาเหล่านี้สามารถมีรูปแบบต่าง ๆ

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

อย่างไรก็ตาม, ประสิทธิภาพของ Commit-Boost ขึ้นอยู่กับการนำมาใช้ของผู้ตรวจสอบรายใหม่ ถ้ามีเพียงไม่กี่ผู้ตรวจสอบที่ใช้มัน ผลกระทบต่อ UX จะน้อยลง อย่างไรก็ตาม, Commit-Boost ได้รับการสนับสนุนอย่างแข็งขันจากชุมชน Ethereum และมีศักยภาพที่จะเป็น middleware ที่แพร่หลายเช่น MEV-Boost มันได้รับการอุปรากรจากผู้ดำเนินการตรวจสอบที่มีชื่อเสียงเช่น Rocket Pool, Renzo, SSV, Luganodes, Nethermind, Puffer, A41, และ Figment นอกจากนี้ยังได้รับทุนอุดหนุนจาก EF, Lido, และ Eigenlayer และมีการสนับสนุนแข็งขันจากตัวสร้างบล็อก Titan

อย่างไรก็ตาม, ตามที่กล่าวถึงไว้ก่อนหน้านี้, preconfirmation มีโอกาสสูงกว่าที่จะถูกใช้เป็น off-chain sidecar เช่น MEV-Boost มากกว่าที่จะถูกผสานเข้ากับโปรโตคอลโดยตรง

บทบาทของ Beam Chain ในการสร้างช่องว่างที่เร็วขึ้น

ตามที่ได้พูดถึงในการนำเสนอของ Justin Drake วัตถุประสงค์ของ Beam Chain คือการลดเวลาบล็อก ดังนั้น การวิจัยและการนำมาใช้จะเน้นไปที่การลดเวลาช่องว่างให้เหลือ 4 วินาทีโดยไม่เสียส่วนลดลงของการกระจายอำนาจ อาจจะแก้ไขโดยการทำให้ Ethereum เป็น snarkification เต็มรูปแบบซึ่งจะอธิบายในส่วนท้ายของบทความนี้

Chain snarkification และความต้านทานทางควอนตัม

จัสตินระบุในการนําเสนอของเขาว่าเป้าหมายของ Beam Chain คือการสอดแนมลูกค้าฉันทามติโดยใช้เทคโนโลยี ZK สิ่งนี้หมายความว่าอย่างไรจะประสบความสําเร็จได้อย่างไรและเหตุใดจึงจําเป็น

Chain snarkification

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

Beam Chain มีจุดมุ่งหมายเพื่อแทนที่กระบวนการดําเนินการใหม่นี้ด้วย "การตรวจสอบ" โดยใช้เทคโนโลยี ZK มันจะลดข้อกําหนดฮาร์ดแวร์สําหรับผู้ตรวจสอบความถูกต้องลงอย่างมากและช่วยให้ทุกคนสามารถเรียกใช้โหนด Ethereum ได้จากทุกที่ เพื่อให้บรรลุเป้าหมายนี้ Beam Chain และ Ethereum จะใช้ ZK SNARKs

ZK ในโปรโตคอล Ethereum

ZK SNARKs มีคุณสมบัติสองอย่างต่อไปนี้:

1. พวกเขาอนุญาตให้ทำการตรวจสอบว่าคำนวณบางอย่างได้รับการดำเนินการโดยไม่ต้องทำการคำนวณใหม่
2. ขนาดพิสูจน์เล็กกว่าข้อมูลต้นฉบับ

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

ด้วยผลที่เกิดขึ้น ความต้องการของฮาร์ดแวร์สำหรับ Ethereum validators สามารถลดลงได้อย่างมาก ตัวอย่างเช่น Vitalik ได้แสดงออกในบทความของ The Verge ว่าเป้าหมายคือเพื่อให้ Validators สามารถทำงานได้แม้แต่ใน environment ที่จำกัดทรัพยากร เช่น smartwatches

จะทำอะไรบ้าง

ขั้นตอนแรกคือการทำให้ฟังก์ชันการเปลี่ยนสถานะเป็น snarkify ฟังก์ชันการเปลี่ยนสถานะทั่วไปมักจะมีรูปแบบดังต่อไปนี้:

f(S,B)=S’

ที่นี่:

• S: สถานะก่อนสถานะของบล็อกเชน
• B: บล็อกที่กำหนด
• S’: สถานะหลังการดำเนินการบล็อกของบล็อกเชน
• ฟังก์ชันการเปลี่ยนสถานะของรัฐ

บล็อกเชนทั้งหมด จะขึ้นอยู่กับฟังก์ชันการเปลี่ยนสถานะที่กำหนดเอง และ Ethereum ก็ไม่แตกต่าง Ethereum มีฟังก์ชันการเปลี่ยนสถานะที่แตกต่างกันสำหรับชั้นความเห็นและการดำเนินการ การ Snarkifying ทั้งสองนี้จะทำให้สามารถตรวจสอบระบบ Ethereum ทั้งหมดได้โดยใช้ ZK ซึ่งจะทำให้ผู้ตรวจสอบที่มีน้ำหนักเบาสามารถทำได้

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

• อัปเดตข้อมูลช่องและหัวบล็อกหลังจากได้รับบล็อก
• ตรวจสอบลายมือชื่อของผู้ตรวจสอบที่เสนอบล็อก
• ตรวจสอบการทำธุรกรรมภายในบล็อก
• ประมวลผลการถอนเงิน, การลดค่าทำลาย, การสิ้นสุดบล็อก และข้อมูลอื่น ๆ เมื่อเกิดการเปลี่ยนแปลงของยุค

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

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

Beam Chain เป้าหมายที่จะบรรลุประสิทธิภาพที่ ZK proof สามารถสร้างได้ภายใน 3 วินาทีบนเครื่องพีซีมาตรฐาน แต่ถึงแม้ว่าจะบรรลุเป้าหมายนี้แล้ว ผู้ตรวจสอบที่ทำงานบนอุปกรณ์เช่นนาฬิกาอัจฉริยะหรือสมาร์ทโฟนอาจจะไม่มีทรัพยากรเพียงพอในการสร้าง ZK proofs

ที่นี่เครือข่ายสามารถพึ่งพาความเมตตาได้ เพียงหนึ่ง ZK proof สำหรับ state transition ของ consensus layer ต่อบล็อก และไม่จำเป็นต้องสร้างโดยผู้เสนอบล็อก กล่าวอีกนัยหนึ่งในขณะที่มีอย่างน้อยหนึ่งเอนทิตีในเครือข่ายสร้าง ZK proof สำหรับแต่ละบล็อก มันสามารถรับรองว่าบล็อก Beam Chain ถูกสร้างอย่างถูกต้องได้

Future: การทำให้ Ethereum เป็นสตริงเต็ม

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

หากการเปลี่ยนแปลงนี้ถูกนำมาใช้พร้อมกับการทำให้ execution layer เป็น snarkification นักตรวจสอบจะต้องแลกเปลี่ยนข้อมูลจำนวนเล็กมากเท่านั้นเมื่อเทียบกับบล็อกทั้งหมด นี่เป็นเพราะว่า SNARK proofs มีขนาดเล็กกว่าข้อมูลเดิมอย่างมีนัยยิ่ง นักตรวจสอบ Ethereum ที่เป็น snarkified อย่างสมบูรณ์จะแลกเปลี่ยนข้อมูลน้อยลงซึ่งลดความต้องการของเครือข่ายเทียบกับระบบปัจจุบัน

สรุปแล้ว ข้อดีต่อไปนี้คือการเข้ารหัสแบบเต็มของ Ethereum สำหรับ validators

1. ผู้ตรวจสอบเพียงต้องยืนยันพิสูจน์เท่านั้น ไม่ต้องดำเนินการคำนวณซ้ำ เพื่อลดการใช้งานความสามารถในการคำนวณ
2. Validators แลกเปลี่ยนข้อมูลพิสูจน์แทนข้อมูลบล็อกเต็ม เพื่อลดความต้องการแบนด์วิดท์ของเครือข่าย

ด้วยผลลัพธ์นั้น ระบบนิเวศ Ethereum อาจเปลี่ยนแปลงอย่างมาก ตัวอย่างเช่น:

• สิ่งที่เรียกว่า “Ethereum Node Apps” อาจช่วยให้ผู้ตรวจสอบสามารถดำเนินการได้บนอุปกรณ์มือถือ
• ผู้ที่ตรงตามข้อกำหนดการฝากขั้นต่ำสามารถเรียกใช้โหนด Ethereum และลดความยากลำบากในการกลายเป็นผู้ตรวจสอบได้อย่างมีนัยสำคัญ

นี่จะทำให้การเข้าร่วมของผู้ตรวจสอบง่ายและกระจายอำนาจมากขึ้น

ลายเซ็นที่ต้านทานทางควอนตัม

การทำสนิทสภาพการเปลี่ยนแปลงของสถานะอย่างเดียวเพียงพอสำหรับ Beam Chain เป็นชั้นเชิงพันธุกรรมหรือไม่?

ปัญหาที่ Ethereum จะเผชิญหน้าในโลกหลังควอนตัมคือ?

มีอีกพื้นที่หนึ่งที่ Beam Chain ตั้งเป้าที่จะขัดขวาง: การสร้างลายเซ็น ปัจจุบันเลเยอร์ฉันทามติของ Ethereum ใช้ลายเซ็นผู้ตรวจสอบความถูกต้องเป็นข้อมูลการรับรองเพื่อสรุปบล็อกและกําหนดห่วงโซ่ที่ถูกต้องในกรณีของส้อม

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

ลายเซ็น BLS ที่ใช้ใน Beacon Chain ของ Ethereum ยังคงใช้ระบบเส้นโค้งคู่ ความปลอดภัยของกลไกลายเซ็นที่ใช้เส้นโค้งคู่เชื่อมต่อกับปัญหาการลอกลายเซ็นลักษณะที่พิเศษ (DLP) ซึ่งความสามารถด้านการคำนวณของคอมพิวเตอร์ควอนตัมอาจทำให้เส้นโค้งคู่ที่พิเศษถูกครอบครอง ซึ่งทำให้เส้นโค้งคู่ที่พิเศษเป็นที่อ่อนแอต่อคอมพิวเตอร์ควอนตัม

คอมพิวเตอร์ควอนตัมได้ก้าวหน้าอย่างรวดเร็ว เช่นมีการพัฒนาชิปคอมพิวเตอร์ควอนตัมเช่น Willow ของ Google ที่สามารถทำการคำนวณในเวลา 5 นาทีซึ่งจะใช้เวลา 10^25 ปีของคอมพิวเตอร์ที่มีประสิทธิภาพสูง แม้ว่าสิ่งนี้ยังไม่สามารถเป็นอันตรายต่อความปลอดภัยของเส้นโค้งเอลลิปติก แต่การพัฒนาต่อไปในอัตราเช่นนี้อาจทำให้ระบบบล็อกเชนเสี่ยงภายในไม่กี่ปี

(การเปลี่ยนสู่มาตรฐานการเข้ารหัสโพสต์ควอนตัม | ที่มา: NIST IR 8547)

สถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา (NIST) ได้เริ่มความพยายามในการกําหนดมาตรฐานอัลกอริธึมลายเซ็นที่ทนต่อควอนตัมเพื่อจัดการกับการล่มสลายของระบบที่มีอยู่เนื่องจากคอมพิวเตอร์ควอนตัม

Ethereum ก็ให้ความสำคัญกับปัญหานี้อย่างจริงจังเช่นกัน ใน Beam Chain เป้าหมายคือที่จะบรรลุอัลกอริทึมลายเซ็นป้องกันควอนตัมได้

มีหลายประเภทของลายเซ็นต์ที่สามารถป้องกันการทำลายจากควอนตัมได้ แต่การนำเสนอ Beam Chain ของ Justin ได้กล่าวถึงอัลกอริทึมลายเซ็นต์ที่พื้นฐานบนฟังก์ชันแฮช ในขณะที่เส้นโค้งเอลลิปติกพึ่งพากันทางคณิตศาสตร์ ลายเซ็นต์บนฟังก์ชันแฮชไม่พึ่งพากันทางคณิตศาสตร์เหล่านี้ ทำให้เกิดความยากต่อคอมพิวเตอร์ควอนตัมอย่างมาก ด้วยเหตุนี้ ลายเซ็นต์บนฟังก์ชันแฮชถือเป็นลายเซ็นต์ที่ป้องกันจากควอนตัมและ Beam Chain มีเป้าหมายที่จะนำลายเซ็นต์เช่นนี้มาใช้

ความท้าทายและบทบาทของ ZK

ความท้าทายหลักคือลายเซ็นที่ใช้ฮาชเบสไม่มีคุณสมบัติการรวมกันที่มีอยู่ในลายเซ็น BLS Ethereum พึ่งพาการรวมลายเซ็นต์ระหว่างความเห็นสนับสนุนเพื่อเอธีเซียมให้เกิดประสิทธิภาพ โดยไม่มีการรวมกัน Ethereum จะไม่สามารถรองรับชุดผู้ตรวจสอบที่มากได้อีกต่อไป

ZK สามารถใช้ในการแก้ปัญหานี้ โดยการใช้เทคโนโลยี Proof Aggregation ซึ่งเป็นเทคโนโลยีที่รวม ZK proofs หลายๆ อันเข้าด้วยกันให้เป็นหลักฐานเดียว กลไกทำงานดังนี้:

(แผนภาพการรวมหลักฐาน | ที่มา: Figment Capital)

1. Validators ลงลายมือลงบล็อกโดยใช้อัลกอริทึมที่ต้านทานควอนตัม
2. ลายเซ็นถูกส่งไปยังผู้รวบรวม**หรือคณะกรรมการรวม
3. ตัวรวมสร้างพิสูจน์ ZK ที่ยืนยันความถูกต้องของลายมือ
4. โดยใช้เทคนิคการรวมพิสูจน์ ตัวรวบรวมรวมพิสูจน์ใหม่กับพิสูจน์ที่มีอยู่เป็นลายเซ็นใหม่เมื่อได้รับลายเซ็นใหม่

วิธีการนี้ช่วยให้ Ethereum สามารถบรรลุประสิทธิภาพเดียวกันกับการรวมลายเซ็น BLS ในขณะที่ยังได้รับการต้านทานด้านควอนตัมในระดับการตัดสินใจ

บทบาทของ ZK ใน Beam Chain

สรุปล่าสุด Beam chain กับ ZK จะนำเอาความได้เปรียบต่อไปนี้:

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

zkVM เป็นพื้นฐานสำหรับ ZK ใน Beam Chain

ระบบพิสูจน์ที่อยู่ในพื้นฐานของ ZK ใน Beam Chain จะเป็น zkVM ซึ่งเป็น Risc-V-based zkVM ที่ช่วยให้สามารถพิสูจน์โปรแกรมใดๆ ในภาษาใดก็ได้ มอบความยืดหยุ่นที่มากขึ้น

(Beam state transition to be compiled into Risc-V and proven in zkVMs | Source: ประกาศ Beam Chain โดย Justin Drake)

สิ่งนี้จะสอดคล้องกับระบบนิเวศของ Ethereum ที่ถูกพัฒนาขึ้นในหลายภาษาเพื่อรักษาความหลากหลายและความทนทานของ Ethereum ในอนาคต Beam Chain สามารถเขียนฟังก์ชันการเปลี่ยนสถานะในหลายภาษาของไคลเอ็นต์ต่าง ๆ และคอมไพล์เป็น Risc-V และอนุญาตให้พิสูจน์ใน zkVM ที่ใช้ Risc-V เป็นพื้นฐาน ดังนั้น zkVM เป็นทางเลือกที่เหมาะสมสำหรับ Beam Chain

สรุป

หากใช้งาน Beam Chain สําเร็จ Ethereum อาจมีคุณสมบัติดังต่อไปนี้:

1. ผู้ใช้จะได้รับการยืนยันธุรกรรมภายใน 4 วินาที โดยการเสร็จสิ้นอย่างสิ้นเชิงใน 12 วินาที
2. Validators จะยืนยันการเปลี่ยนแปลงของสถานะในชั้นความเห็นชอบโดยใช้ ZK proofs หากชั้นปฏิบัติการเป็น snarkified ด้วย validators จะต้องใช้ข้อมูลอย่างน้อยเพียงครั้งเดียวเท่านั้นเพื่อมีส่วนร่วมในการเป็นความเห็นร่วม
3. ลายเซ็นผู้ตรวจสอบความถูกต้องจะเป็นควอนตัมต้านทาน
4. t ป้องกันไม่ให้คอมพิวเตอร์ควอนตัมประนีประนอมฉันทามติของ Ethereum

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

นี่เป็นส่วนสุดท้ายของการสำรวจว่า Ethereum จะพัฒนาอย่างไรในอีกห้าปีผ่านมุมมองของ Beam Chain ในบทความถัดไปเราจะสำรวจว่า Ethereum จะเป็นยังไงในปี 2025 จากมุมมองสองประการ: ประสบการณ์ผู้ใช้และความต้านทานการเซ็นเซอร์

Appendix: Beam Chain FAQs

(Q): ข้อเสนอของ Justin Drake ได้รับการสนทนาในที่ส่วนตัว เป็นข้อขัดแย้งกับค่าแกนของ Ethereum ที่เป็น "เปิดเผย" หรือไม่?

(A): ไม่มันทําไม่ได้ ข้อเสนอ Beam Chain เพียงแค่แนะนําให้ใช้บางส่วนของแผนงานที่มีอยู่ของ Ethereum ในครั้งเดียว ส่วนจะดําเนินการหรือไม่เป็นสิ่งที่ยังต้องมีการพูดคุยกันในชุมชน หัวข้อทั้งหมดที่กล่าวถึงข้างต้นมี EIPs หรือโพสต์ที่เกี่ยวข้องบน Ethresear.ch อยู่แล้ว สิ่งนี้ไม่มากก็น้อยแสดงให้เห็นว่า Beam Chain ไม่ใช่ข้อเสนอที่เสนอทิศทางใหม่ที่ไม่เปิดเผยก่อนหน้านี้สําหรับ Ethereum นอกจากนี้ การอภิปรายเกี่ยวกับแผนงานของ Ethereum จะจัดขึ้นต่อสาธารณะในช่วง All Core Devs Call ทุกสองสัปดาห์ ซึ่งทุกคนสามารถเข้าร่วมได้ หากมีคนไม่เห็นด้วยกับแผนงานหรือมีแนวคิดใหม่พวกเขาสามารถแสดงความคิดเห็นในระหว่างการโทรเหล่านี้หรือส่งข้อเสนอใหม่ในรูปแบบของ EIPs หรือโพสต์บน Ethresear.ch

สรุปมาว่า ข้อเสนอ Beam Chain ของ Justin ไม่ได้เป็นเรื่องการเปลี่ยนแปลงแผนการเดินทาง แต่เป็นการรวมกลุ่มส่วนต่าง ๆ ของแผนการเดินทางไว้ภายใต้ชื่อเดียวหรือมีม

(คำถาม): 5 ปีไม่นานไปมั้ยที่จะนำ Beam Chain มาใช้งาน?

(A): อาจจะรู้สึกว่าห้าปีเป็นเวลานาน แต่จำเป็นต้องพิจารณาสองปัจจัย:

1. Ethereum สร้างขึ้นบนโครงสร้าง multi-client
2. Ethereum มีจำนวนผู้ตรวจสอบมากที่สุดในบล็อกเชนใดๆ

(ความหลากหลายของลูกค้าสนับสนุน | แหล่งที่มา: ความหลากหลายของไคลเอ็นต์ Ethereum)

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

ตามที่แสดงในภาพ เลเยอร์คอนเซ็นซัสของ Ethereum ในปัจจุบันกำลังดำเนินการด้วยอย่างน้อยสี่ลูกค้า ในการแทนที่ Beacon Chain ด้วย Beam Chain ทีมลูกค้าทั้งสี่ต้องทำงานร่วมกันในการพัฒนา โดยพิจารณาถึงนี้และชุด Validator ขนาดใหญ่ของ Ethereum กระบวนการพัฒนา Beam Chain ต้องให้ลำดับความสำคัญกับความเสถียรและไม่สามารถเร่งความเร็วไปสู่ระยะเวลาหลายเดือนหรือ 1-2 ปี

คำปฏิเสธ:

1. บทความนี้ถูกคัดลอกมาจาก [2077research]. สิทธิ์ในการคัดลอกทั้งหมดเป็นของผู้เขียนต้นฉบับ [ sm-stack]. หากมีคำคัดค้านเรื่องการนำออกนี้ กรุณาติดต่อ เกตเรียนทีมทำงานและพวกเขาจะดำเนินการตรวจสอบได้ทันที
2. คำประกาศความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำใดๆ เกี่ยวกับการลงทุน
3. ทีมงาน Gate Learn ดำเนินการแปลบทความเป็นภาษาอื่น ๆ หากไม่ได้กล่าวถึง, การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่แปลนั้นถือเป็นการละเมิดกฎหมาย