นับถอยหลังสู่ปี 2029: จุดเริ่มต้นการเดินทางต้านควอนตัมของ Ethereum ที่ Hegotá

ผู้เขียนต้นฉบับ: KarenZ, Foresight News

คอมพิวเตอร์ควอนตัมยังมาไม่ถึงประตูของบล็อกเชน แต่มูลนิธิ Ethereum ได้วงกลมวันที่หนึ่งไว้บนปฏิทินแล้ว: ธันวาคม 2029

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

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

EF กำหนดเส้นตายปี 2029 ไว้ล่วงหน้าสำหรับ 'Q-day'

'Q-day' มักใช้เรียกช่วงเวลาสมมุติที่คอมพิวเตอร์ควอนตัมซึ่งมีความสามารถโจมตีได้จริงปรากฏขึ้น และระบบเข้ารหัสด้วยคีย์สาธารณะในปัจจุบันต้องเผชิญกับภัยคุกคามอย่างเป็นรูปธรรม

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

ทีมโปรโตคอลของมูลนิธิ Ethereum ใช้สมมติฐานทางวิศวกรรมแบบอนุรักษ์นิยม: เครือข่ายชั้นหนึ่งของ Ethereum ควรเตรียมพร้อมล่วงหน้าสำหรับกรณีที่ Q-day อาจมาถึงเร็วที่สุดในปี 2030

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

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

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

Hegotá ไม่ใช่ 'การอัปเกรดต้านควอนตัม' แต่เป็นบททดสอบแรกของแผนทั้งหมด

ตามแผนงานพื้นฐานที่ทีมโปรโตคอลของมูลนิธิ Ethereum ประกาศในปัจจุบัน การอัปเกรดเครือข่าย Glamsterdam มีแผนจะเปิดตัวบนเมนเน็ตในเดือนธันวาคม 2026 ส่วนความสามารถต้านทานควอนตัมอย่างสมบูรณ์ถูกจัดไว้ในฮาร์ดฟอร์กครั้งที่ห้าหลังจาก Glamsterdam คือ L* โดยมีเป้าหมายในเดือนธันวาคม 2029 จาก Glamsterdam ถึง L* มีเวลาเพียงสามปี หากต้องทำ Hegotá, I*, J*, K* และ L* ตามลำดับ จะมีเวลาเฉลี่ยเพียงประมาณ 7.2 เดือนระหว่างการอัปเกรดแต่ละครั้ง

นี่เป็นตารางเวลาที่ค่อนข้างทะเยอทะยาน ปัจจุบันมูลนิธิ Ethereum ยังไม่ได้ประกาศวันเปิดตัวบนเมนเน็ตที่แน่นอนสำหรับ Hegotá, I*, J* และ K* สิ่งที่แน่นอนคือ ทีมไคลเอนต์คาดว่าจะเริ่มนำ Hegotá ไปใช้ได้เร็วที่สุดในช่วงปลายไตรมาสที่สี่ของปี 2026 และงานวิจัย ข้อกำหนด และการทดสอบของเวอร์ชันถัดๆ ไปหลายเวอร์ชันต้องดำเนินการคู่ขนานกันไป

ตามแผนงานปัจจุบัน การจัดวางหลักของแต่ละเฟสมีดังนี้:

• Hegotá: อยู่ที่จุดเริ่มต้นของเส้นทางนี้ จุดยืนอย่างเป็นทางการชัดเจนมาก: Hegotá ไม่ใช่การอัปเกรดต้านควอนตัม แต่จะกำหนดว่าการอัปเกรดต้านควอนตัมในลำดับถัดไปจะเดินหน้าตามกำหนดได้หรือไม่
• I*: ปรับใช้รีจิสทรีคีย์สาธารณะต้านควอนตัม เพื่อสร้างพื้นฐานโปรโตคอลสำหรับการลงทะเบียนบัญชีและการใช้คีย์สาธารณะต้านควอนตัม ขณะเดียวกัน การแยกฉันทามติออกจากกันเป็นทิศทางหลักที่นำอยู่ในปัจจุบันของเวอร์ชันนี้ และงานออกแบบและย้ายโครงสร้างสถานะขนาดใหญ่ก็คาดว่าจะเริ่มจาก I*
• J*: สร้างชั้นหนึ่ง 'ต้านควอนตัมขั้นต่ำที่ใช้งานได้' หรือ MV-PQ องค์ประกอบสำคัญประกอบด้วยกลไก heartbeat ต้านควอนตัมในชั้นฉันทามติ การสุ่มตัวอย่าง leanDA หลังควอนตัมในชั้นข้อมูล และธุรกรรม leanSPHINCS หลังควอนตัมในชั้นการประมวลผล
• K*: ตามการจัดลำดับพื้นฐานปัจจุบัน แนะนำการพิสูจน์การประมวลผลแบบบังคับ ในตอนนั้น ทิศทางการพัฒนาของผู้ตรวจสอบคือการตรวจสอบการพิสูจน์การประมวลผลแบบกระชับ แทนที่จะให้ผู้ตรวจสอบทุกคนประมวลผลบล็อกเต็มซ้ำอีกครั้ง
• L*: ตามการจัดลำดับพื้นฐานปัจจุบัน เพิ่มข้อความพิสูจน์ต้านควอนตัมที่จำเป็นสำหรับฉันทามติต้านควอนตัมอย่างสมบูรณ์ ซึ่งก็คือ post-quantum attestations และบรรลุเป้าหมายต้านควอนตัมอย่างสมบูรณ์ในชั้นการประมวลผล ชั้นฉันทามติ และชั้นข้อมูล ภายในเดือนธันวาคม 2029

อย่างไรก็ตาม ลำดับงานของ K* และ L* ยังไม่ถูกกำหนดเป็นที่สิ้นสุด ทีมโปรโตคอลกำลังประเมินทางเลือกในการสลับ: เลื่อนข้อความพิสูจน์ต้านควอนตัมจาก L* ขึ้นมาเป็น K* เพื่อให้ความสามารถต้านควอนตัมอย่างสมบูรณ์เกิดขึ้นเร็วขึ้น พร้อมกับเลื่อนการพิสูจน์การประมวลผลแบบบังคับจาก K* ไปเป็น L* หากใช้แนวทางนี้ หน้าที่เฉพาะและจังหวะการอัปเกรดของ K* และ L* จะเปลี่ยนไปตามนั้น ดังนั้น คำกล่าวที่แม่นยำที่สุดในตอนนี้คือ: ธันวาคม 2026 เป็นเป้าหมายเมนเน็ตปัจจุบันของ Glamsterdam และธันวาคม 2029 เป็นเป้าหมายของ L* และความสามารถต้านควอนตัมอย่างสมบูรณ์ในแผนงานพื้นฐาน ลำดับภายในของ K* และ L* ยังอาจปรับเปลี่ยนได้

นักวิจัย นักพัฒนาไคลเอนต์ ผู้ตรวจสอบความปลอดภัย และทีมทดสอบ ต้องทำ Hegotá ให้เสร็จ และต้องเตรียมข้อกำหนดและต้นแบบสำหรับ I*, J*, K* และ L* ไว้ล่วงหน้าด้วย หาก Hegotá รวมฟีเจอร์ที่ส่งผลกระทบต่อกันมากเกินไป มันอาจไม่เพียงทำให้การเปิดตัวของตัวเองล่าช้า แต่ยังแย่งทีมที่จำเป็นสำหรับงานต้านควอนตัมในลำดับถัดไปอีกด้วย

ดังนั้น ทีมโปรโตคอลของมูลนิธิ Ethereum จึงแบ่งข้อเสนอที่เป็นตัวเลือกของ Hegotá ออกเป็นระดับ S (2 รายการ), A (15 รายการ), B (8 รายการ), C (7 รายการ), DFI (28 รายการ) และ TBD (2 รายการ) รวมทั้งหมด 62 รายการ ระดับ S หมายถึงต้องส่งมอบ ระดับ A หมายถึงลำดับความสำคัญสูงและคาดว่าจะส่งมอบ ระดับ B ยังต้องผ่านเงื่อนไขด้านข้อกำหนด ต้นแบบ หรือการยืนยันผู้รับผิดชอบ ระดับ C อยู่ต่ำกว่าเกณฑ์การรวมในตอนนี้ DFI หมายถึงไม่แนะนำให้รวมในการอัปเกรดนี้ และ TBD หมายถึงรอการตัดสินใจ

สองรายการระดับ S ของ Hegotá: FOCIL และ Frames

ในการจัดระดับ Hegotá ที่ทีมโปรโตคอลประกาศ มีเพียงสอง EIP ที่เข้าสู่ระดับ S: EIP-7805 FOCIL ในชั้นฉันทามติ และ EIP-8141 Frame Transactions ในชั้นการประมวลผล

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

FOCIL (EIP-7805) ย่อมาจาก 'Fork-choice enforced Inclusion Lists' เป้าหมายคือปรับปรุงการรับประกันการรวมธุรกรรมของ Ethereum

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

ตามการออกแบบของ FOCIL แต่ละ Slot จะมีการเลือกกลุ่มผู้ตรวจสอบขึ้นมาเป็น 'คณะกรรมการรายการรวม' (IL committee) สมาชิกคณะกรรมการจะสร้างและกระจายรายการรวมตามธุรกรรมที่รอดำเนินการที่ตนเห็น ผู้สร้างบล็อกของ Slot ถัดไปจะรวบรวมรายการเหล่านี้ และรวมธุรกรรมที่เข้าเงื่อนไขการประมวลผลเข้าไปในบล็อกที่สร้าง ผู้ตรวจสอบที่ทำหน้าที่รับรองบล็อกใหม่จะเก็บรายการรวมที่ตนได้รับทันเวลาไว้ และตรวจสอบว่าบล็อกตรงตามข้อกำหนดที่เกี่ยวข้องหรือไม่

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

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

พูดง่ายๆ คือ FOCIL ไม่ได้ให้ผู้ตรวจสอบมาแย่งงานผู้สร้างบล็อก แต่เพิ่มกฎชั้นฉันทามติให้ผู้สร้าง: คุณยังสามารถจัดเรียงธุรกรรมส่วนใหญ่ในบล็อกได้ แต่ไม่สามารถละเลยธุรกรรมที่เข้าเงื่อนไขซึ่งคณะกรรมการระบุไว้อย่างต่อเนื่องโดยไม่มีเหตุผลอันสมควร

Frame Transactions (EIP-8141) จัดการกับปัญหาในระดับบัญชี มีแผนจะทำให้การตรวจสอบธุรกรรม การประมวลผลธุรกรรม และการจ่าย Gas เป็นโปรแกรมได้มากขึ้นในระดับโปรโตคอล เพื่อวางรากฐานสำหรับ Account Abstraction แบบเนทีฟ Vitalik เป็นหนึ่งในผู้ร่วมเขียน EIP-8141

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

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

Frames ยังต้องมีข้อเสนอระดับ A สองรายการเป็นองค์ประกอบหลักที่มาคู่กัน EIP-8250 Keyed Nonces อนุญาตให้ผู้ส่งรายเดียวกันใช้ช่อง nonce ที่เป็นอิสระต่อกัน ทำให้ธุรกรรมต่างๆ ไม่ต้องติดขัดกันเพราะต้องแชร์ลำดับที่เข้มงวดร่วมกัน ส่วน EIP-8272 ช่วยให้ธุรกรรมใช้สถานะบนเชนล่าสุดที่ผู้ตรวจสอบตรวจสอบได้ ทำให้ธุรกรรมความเป็นส่วนตัวที่เกี่ยวข้องได้รับการรับประกันการรวมจาก FOCIL ด้วย

ดังนั้น FOCIL และ Frames จึงไม่ใช่ฟีเจอร์สองอย่างที่ไม่เกี่ยวข้องกัน ตัวแรกเปลี่ยนว่าบล็อกต้องรวมธุรกรรมที่เข้าเงื่อนไขใดบ้าง ตัวหลังเปลี่ยนโครงสร้างการตรวจสอบของธุรกรรมเอง การที่ทั้งสองทำงานร่วมกันได้อย่างปลอดภัยหรือไม่ คือหนึ่งในภารกิจทดสอบที่สำคัญที่สุดของ Hegotá

นอกจากระดับ S แล้ว ยังมี EIP ใดอีกที่น่าจับตามอง?

ข้อเสนอระดับ S กำหนดเส้นทางหลักของ Hegotá แต่ข้อเสนอระดับ A หลายรายการก็จะส่งผลต่อความปลอดภัยของบัญชี การย้ายต้านควอนตัม การพิสูจน์การประมวลผล และการคิดราคาทรัพยากรของ Ethereum ในอนาคตเช่นกัน

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

ด้านความปลอดภัยของบัญชี EIP-7906, EIP-8298 และ EIP-8151 ถูกมองว่าเป็นชุดส่วนขยายของ Frames

EIP-7906 แนะนำกลไก Transaction Assertions ให้ธุรกรรมตรวจสอบว่าผลลัพธ์ที่ระบุเกิดขึ้นหรือไม่ก่อนส่งขั้นสุดท้าย กลไกนี้มีจุดประสงค์เพื่อลดความเสียหายจากสัญญาที่ประสงค์ร้ายดูดสินทรัพย์ออกจากกระเป๋าเงิน และจากพฤติกรรม MEV บางส่วน อย่างไรก็ตาม ขอบเขตการอ่านที่เฉพาะเจาะจงของข้อเสนอนี้ยังอยู่ระหว่างการศึกษาและจำกัดให้แคบลง จึงไม่สามารถเขียนการออกแบบปัจจุบันเป็นข้อกำหนดสุดท้ายที่ล็อกไว้แล้วได้

EIP-8298 อนุญาตให้บัญชีนำโค้ดสัญญาที่มีอยู่กลับมาใช้ใหม่ ทำให้บัญชีที่ได้รับการมอบหมายเปลี่ยนเป็นบัญชีสัญญาอัจฉริยะที่มีโค้ดเต็มรูปแบบ ส่วน EIP-8151 จำกัดที่อยู่ที่มีโค้ดบัญชีอยู่แล้วไม่ให้พึ่งพาการรับรองแบบ ecRecover แบบเดิมต่อไป

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

EIP-8025 (การพิสูจน์การประมวลผลแบบเลือกได้) เกี่ยวข้องกับแผนงาน zkEVM ในอนาคต มีแผนจะรวมการเปลี่ยนแปลงที่จำเป็นสำหรับการพิสูจน์การประมวลผลแบบเลือกได้เข้าไว้ในข้อกำหนดการประมวลผลแบบรวม เพื่อลดปัญหาที่โปรเจกต์ zkVM ต่างๆ ต้องดูแลเวอร์ชันที่แยกออกจากกันในระยะยาว

EIP-8279 (ชั้น Byte ของรายการเข้าถึงบล็อก) และ EIP-8131 (ชั้นเนื้อหาธุรกรรมแบบรวม) เป็นชุดข้อเสนอด้านความปลอดภัยในการประมวลผล ทั้งสองรายการกำหนดมาตรฐานการคิดราคาขั้นต่ำสำหรับรายการเข้าถึงบล็อกและเนื้อหาธุรกรรมตามลำดับ โดยมีจุดประสงค์เพื่อจำกัดไม่ให้ผู้โจมตีใช้เนื้อหาที่มีราคาต่ำเกินไปสร้างภาระทรัพยากรที่รุนแรง สิ่งที่ทั้งสองแก้ไขก่อนคือต้นทุนการประมวลผลบล็อกในกรณีเลวร้ายที่สุด ไม่ใช่การประกาศเพิ่มความจุของเครือข่ายโดยตรง การจะใช้ส่วนต่างความปลอดภัยที่เกิดขึ้นเพื่อขยายความจุหรือไม่ ต้องตัดสินใจแยกต่างหากในภายหลัง

EIP-3298 มีแผนจะยกเลิกกลไกการคืน Gas อย่างถาวร เพื่อลดกรณีพิเศษในการวัด การนำไปใช้ และการทดสอบ ส่วน EIP-5920 (PAY Opcode) อนุญาตให้สัญญาโอน ETH โดยไม่ต้องรันโค้ดของสัญญาปลายทาง แยก 'การโอนมูลค่า' และ 'การเรียกสัญญา' ออกจากกันอย่างชัดเจน

ในขณะเดียวกัน ข้อเสนอบางรายการที่ได้รับความสนใจยังคงอยู่ในระดับ B

ตัวอย่างเช่น EIP-8198 (Quick Slots) ต้องการลดเวลา Slot แต่ทีมโปรโตคอลกำหนดให้ต้องทำข้อกำหนดที่ครอบคลุมการเปลี่ยนแปลงโปรโตคอลหลัก ต้นแบบที่สมบูรณ์ การประเมินผลกระทบต่อระบบปลายน้ำ และพิสูจน์ว่าจะไม่รบกวนการออกแบบการแยกฉันทามติในลำดับถัดไป เหตุผลคือเวลา Slot ไม่เพียงส่งผลต่อความเร็วในการออกบล็อก แต่ยังส่งผลต่อการกระจายข้อมูลในเครือข่าย การตัดสินฉันทามติ และสมมติฐานด้านเวลาของแอปพลิเคชัน

นอกจากนี้ EIP-8368 และ EIP-8372 ถูกจัดเป็น 'TBD' (รอการตัดสินใจ) ข้อเสนอทั้งสองเกี่ยวข้องกับขีดจำกัด Gas และการคิดราคาทรัพยากรสถานะ ทีมโปรโตคอลตัดสินใจรอข้อมูลเมนเน็ตหลังจาก Glamsterdam เปิดตัวในเดือนธันวาคม 2026 ก่อน แล้วค่อยตัดสินว่าจำเป็นต้องปรับเทียบใหม่หรือไม่

จำนวน EIP ที่ Hegotá รวมในท้ายที่สุด ไม่ใช่มาตรวัดเดียวว่าการอัปเกรดนี้ประสบความสำเร็จหรือไม่

สิ่งที่สำคัญกว่าคือ มันจะสามารถส่งมอบ FOCIL, Frames และองค์ประกอบหลักที่เกี่ยวข้องได้โดยไม่ลดทอนความปลอดภัยและคุณภาพการทดสอบหรือไม่ พร้อมกับเหลือทรัพยากรการวิจัยและพัฒนาเพียงพอสำหรับรีจิสทรีคีย์สาธารณะและการแยกฉันทามติของ I*, ความสามารถต้านทานควอนตัมขั้นต่ำที่ใช้งานได้ของ J* และการพิสูจน์การประมวลผลและฉันทามติต้านควอนตัมอย่างสมบูรณ์ของ K* และ L*

ตามเป้าหมายปัจจุบัน Glamsterdam จะเริ่มต้นวงจรการอัปเกรดที่แน่นขนัดนี้ในเดือนธันวาคม 2026 และ L* ในแผนงานพื้นฐานจะถึงเส้นชัยในเดือนธันวาคม 2029 การอัปเกรดแต่ละครั้งระหว่างทางไม่สามารถทำแค่ฟีเจอร์ของตัวเองให้เสร็จเท่านั้น แต่ต้องรับประกันว่าเฟสถัดไปจะเดินหน้าต่อได้

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

เอกสารอ้างอิง:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446