Ethereum จะประสบกับการเปลี่ยนแปลงครั้งใหญ่นี้ภายใน 3 วัน

ต้นฉบับโดย Sahil Sojitra

รวบรวมโดย Odaily Planet Daily Golem ( @web3_golem )

ฮาร์ดฟอร์ก Fusaka ซึ่งมีกำหนดเปิดใช้งานในวันที่ 3 ธันวาคม 2025 ถือเป็นการอัปเกรดเครือข่ายครั้งใหญ่สำหรับ Ethereum หลังจาก Pectra ซึ่งถือเป็นอีกก้าวสำคัญสำหรับยักษ์ใหญ่ด้านคริปโตในการขยายขนาด

EIP ที่อัปเกรดของ Pectra มุ่งเน้นไปที่การปรับปรุงประสิทธิภาพ ความปลอดภัย และเครื่องมือสำหรับนักพัฒนา ในทางกลับกัน EIP ที่อัปเกรดของ Fusaka เน้นที่การปรับขนาด การอัปเดตโอปโค้ด และความปลอดภัยในการดำเนินการ

PeerDAS (EIP-7594) ปรับปรุงความพร้อมใช้งานของข้อมูลโดยอนุญาตให้โหนดตรวจสอบ blob ได้โดยไม่ต้องดาวน์โหลดข้อมูลทั้งหมด การอัปเกรดหลายรายการยังช่วยเพิ่มความปลอดภัยในการดำเนินการ รวมถึงการจำกัด ModExp (EIP-7823), การจำกัดปริมาณธุรกรรม gas (EIP-7825) และการอัปเดตค่า modExp gas (EIP-7883) การอัปเกรด Fusaka นี้ยังปรับปรุงการสร้างบล็อกผ่านกลไกการ lookahead ของผู้เสนอแบบกำหนดล่วงหน้า (EIP-7917) และรักษาค่าธรรมเนียม blob ให้คงที่โดยการกำหนด "ราคาสำรอง" ที่เชื่อมโยงกับค่าดำเนินการ (EIP-7918)

การปรับปรุงอื่นๆ ได้แก่ การจำกัดขนาดบล็อกของรูปแบบ RLP (EIP-7934) การเพิ่มโอปโค้ด CLZ ใหม่เพื่อเพิ่มความเร็วในการดำเนินการบิต (EIP-7939) และการแนะนำการคอมไพล์ล่วงหน้า secp256r1 (EIP-7951) เพื่อความเข้ากันได้ที่ดีขึ้นกับการเข้ารหัสสมัยใหม่และคีย์ความปลอดภัยของฮาร์ดแวร์

Fusaka เป็นชื่อที่รวมกันระหว่าง Fulu (เลเยอร์การดำเนินการ) และ Osaka (เลเยอร์ฉันทามติ) ถือเป็นอีกก้าวหนึ่งของ Ethereum สู่อนาคตที่ปรับขนาดได้สูงและมีข้อมูลมากมาย ซึ่ง Layer 2 Rollups สามารถทำงานได้ด้วยต้นทุนที่ต่ำลงและความเร็วที่เร็วขึ้น

บทความนี้จะให้การวิเคราะห์เชิงลึกเกี่ยวกับข้อเสนอ EIP หลักทั้งเก้าของฮาร์ดฟอร์ก Fusaka

EIP-7594: PeerDAS — การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลโหนด

Ethereum ต้องการข้อเสนอนี้เนื่องจากเครือข่ายต้องการให้ผู้ใช้โดยเฉพาะผู้ใช้ Rollup สามารถใช้ข้อมูลได้อย่างสะดวกมากขึ้น

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

การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล (DAS) จะช่วยแก้ปัญหานี้โดยอนุญาตให้โหนดตรวจสอบข้อมูลสุ่มจำนวนเล็กน้อยเท่านั้น

อย่างไรก็ตาม Ethereum ยังต้องการวิธี DAS ที่เข้ากันได้กับเครือข่าย Gossip ที่มีอยู่ และไม่สร้างภาระการคำนวณที่หนักหน่วงให้กับผู้ผลิตบล็อก PeerDAS ถูกสร้างขึ้นเพื่อตอบสนองความต้องการเหล่านี้ และเพิ่มปริมาณงานของบล็อกอย่างปลอดภัย พร้อมกับรักษาความต้องการโหนดให้อยู่ในระดับต่ำ

PeerDAS เป็นระบบเครือข่ายที่อนุญาตให้โหนดดาวน์โหลดเฉพาะข้อมูลส่วนเล็กๆ เพื่อตรวจสอบว่าข้อมูลทั้งหมดได้รับการเผยแพร่แล้วหรือไม่ แทนที่จะดาวน์โหลดข้อมูลทั้งหมด โหนดจะใช้การแชร์เครือข่ายแบบ Gossip เป็นประจำเพื่อค้นหาว่าโหนดใดเก็บข้อมูลเฉพาะส่วนที่ต้องการและร้องขอเฉพาะตัวอย่างขนาดเล็กที่จำเป็น แนวคิดหลักคือการดาวน์โหลดเฉพาะข้อมูลส่วนเล็กๆ แบบสุ่ม โหนดยังคงสามารถมั่นใจได้ว่าข้อมูลส่วนนั้นมีอยู่จริง ตัวอย่างเช่น โหนดอาจดาวน์โหลดข้อมูลเพียงประมาณ 1/8 แทนที่จะเป็นข้อมูลส่วนขนาด 256 KB ทั้งหมด แต่เนื่องจากโหนดจำนวนมากจะสุ่มตัวอย่างข้อมูลส่วนต่างๆ ทำให้สามารถตรวจพบข้อมูลที่หายไปได้อย่างรวดเร็ว

เพื่อทำการสุ่มตัวอย่าง PeerDAS ใช้วิธีการเข้ารหัสแบบลบพื้นฐานเพื่อขยายแต่ละเซกเมนต์ข้อมูลใน EIP-4844 การเข้ารหัสแบบลบเป็นเทคนิคที่เพิ่มข้อมูลซ้ำซ้อนเพื่อให้สามารถกู้คืนข้อมูลต้นฉบับได้ แม้ว่าเซกเมนต์ข้อมูลบางส่วนจะสูญหายไป คล้ายกับจิ๊กซอว์ที่สามารถต่อเข้าด้วยกันได้ แม้ว่าบางชิ้นส่วนจะสูญหายไปก็ตาม

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

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

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

PeerDAS ได้เพิ่มฟีเจอร์ที่เรียกว่า "cell KZG proof" ซึ่งแสดงให้เห็นว่าการคอมมิทต์ KZG นั้นตรงกับเซลล์เฉพาะ (หน่วยเล็กๆ) ใน blob จริง ซึ่งทำให้โหนดสามารถดาวน์โหลดเฉพาะเซลล์ที่ต้องการสุ่มตัวอย่างได้ การได้รับ blob ที่สมบูรณ์พร้อมกับการตรวจสอบความสมบูรณ์ของข้อมูลเป็นสิ่งสำคัญอย่างยิ่งต่อการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล

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

ด้วยเหตุนี้ การทำธุรกรรมแบบซุบซิบ (PooledTransactions) จึงใช้ wrapper ที่ปรับเปลี่ยนแล้ว:

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

ใน wrapper ใหม่ `cell_proofs` เป็นเพียงรายการที่มี proof ทั้งหมดสำหรับแต่ละเซลล์ของแต่ละ blob (เช่น `[cell_proof_0, cell_proof_1, ...]`) ฟิลด์อื่นๆ ได้แก่ `tx_payload_body`, `blobs` และ `commitments` เหมือนกับใน EIP-4844 ความแตกต่างคือฟิลด์ "proofs" เดิมเพียงฟิลด์เดียวถูกลบออกและแทนที่ด้วยรายการ `cell_proofs` ใหม่ และมีการเพิ่มฟิลด์ใหม่ชื่อ `wrapper_version` เพื่อระบุรูปแบบ wrapper ที่ใช้อยู่ในปัจจุบัน

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

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

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

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

EIP-7594 เข้ากันได้กับ EIP-4844 อย่างสมบูรณ์ จึงไม่ส่งผลกระทบต่อฟังก์ชันการทำงานใดๆ ที่มีอยู่บน Ethereum การทดสอบและกฎเกณฑ์โดยละเอียดทั้งหมดรวมอยู่ในข้อกำหนดฉันทามติและการบังคับใช้

ความเสี่ยงด้านความปลอดภัยหลักของระบบ DAS ใดๆ คือ "การโจมตีแบบปกปิดข้อมูล" ซึ่งผู้สร้างบล็อกแสร้งทำเป็นว่ามีข้อมูลอยู่จริง แต่แท้จริงแล้วซ่อนข้อมูลบางส่วนไว้ PeerDAS ป้องกันปัญหานี้โดยใช้การสุ่มตัวอย่าง: โหนดจะตรวจสอบข้อมูลส่วนต่างๆ แบบสุ่ม ยิ่งมีการสุ่มตัวอย่างโหนดมากเท่าใด ผู้โจมตีก็ยิ่งโกงได้ยากขึ้นเท่านั้น EIP-7594 ยังมีสูตรคำนวณความน่าจะเป็นที่การโจมตีจะสำเร็จ โดยอ้างอิงจากจำนวนโหนดทั้งหมด (n) จำนวนตัวอย่างทั้งหมด (m) และจำนวนตัวอย่างต่อโหนด (k) บนเครือข่ายหลัก Ethereum ซึ่งมีโหนดประมาณ 10,000 โหนด โอกาสที่การโจมตีจะสำเร็จนั้นต่ำมาก ดังนั้น PeerDAS จึงถือว่าปลอดภัย

EIP-7823: กำหนดขนาดสูงสุด 1024 ไบต์สำหรับ MODEXP

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

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

เพื่อบรรเทาปัญหาเหล่านี้และปรับปรุงเสถียรภาพของ Ethereum, EIP-7823 เพิ่มขีดจำกัดที่เข้มงวดสำหรับปริมาณข้อมูลอินพุต MODEXP ซึ่งทำให้กระบวนการก่อนการคอมไพล์มีความปลอดภัยมากขึ้น ทดสอบได้ง่ายขึ้น และคาดเดาได้มากขึ้น

EIP-7823 แนะนำกฎง่ายๆ: ฟิลด์ความยาวทั้งสามฟิลด์ที่ใช้โดย MODEXP (ฐาน เลขชี้กำลัง และโมดูลัส) ต้องน้อยกว่าหรือเท่ากับ 8192 บิต หรือ 1024 ไบต์ อินพุต MODEXP เป็นไปตามรูปแบบที่กำหนดไว้ใน EIP-198: <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> ดังนั้น EIP นี้จะจำกัดเฉพาะค่าความยาวเท่านั้น หากความยาวใดเกิน 1024 ไบต์ การประมวลผลล่วงหน้าจะหยุดทันที แสดงข้อผิดพลาด และใช้แก๊สทั้งหมด

ตัวอย่างเช่น หากมีผู้พยายามระบุเลขฐานสองขนาด 2000 ไบต์ การเรียกจะล้มเหลวก่อนที่จะเริ่มงานใดๆ ข้อจำกัดเหล่านี้ยังคงเป็นไปตามสถานการณ์การใช้งานจริงทั้งหมด โดยทั่วไปแล้ว การตรวจสอบ RSA จะใช้ความยาวคีย์ 1024 บิต, 2048 บิต หรือ 4096 บิต ซึ่งทั้งหมดอยู่ในขีดจำกัดใหม่ การดำเนินการเส้นโค้งวงรีใช้ขนาดอินพุตที่เล็กกว่า ซึ่งโดยทั่วไปจะน้อยกว่า 384 บิต จึงไม่ได้รับผลกระทบ

ข้อจำกัดใหม่เหล่านี้ยังเอื้อต่อการอัปเกรดในอนาคต หากในอนาคต MODEXP ถูกเขียนใหม่เป็นโค้ด EVM โดยใช้ EVMMAX นักพัฒนาสามารถเพิ่มเส้นทางที่ปรับให้เหมาะสมสำหรับขนาดอินพุตทั่วไป (เช่น 256 บิต, 381 บิต หรือ 2048 บิต) และใช้รูปแบบการสำรองที่ช้าลงสำหรับกรณีที่หายาก การแก้ไขขนาดอินพุตสูงสุดทำให้นักพัฒนาสามารถเพิ่มการจัดการพิเศษสำหรับโมดูลัสทั่วไปได้ ก่อนหน้านี้ไม่สามารถทำได้เนื่องจากขนาดอินพุตไม่จำกัด ส่งผลให้พื้นที่การออกแบบมีขนาดใหญ่เกินไปและจัดการได้ไม่ปลอดภัย

เพื่อยืนยันว่าการเปลี่ยนแปลงนี้จะไม่ส่งผลกระทบต่อธุรกรรมที่ผ่านมา ผู้เขียนได้วิเคราะห์การใช้งาน MODEXP ทั้งหมดตั้งแต่บล็อก 5,472,266 (20 เมษายน 2018) ไปจนถึงบล็อก 21,550,926 (4 มกราคม 2025) ผลการวิจัยแสดงให้เห็นว่าการเรียกใช้ MODEXP ที่ประสบความสำเร็จในอดีตไม่เคยใช้ข้อมูลอินพุตเกิน 513 ไบต์ ซึ่งต่ำกว่าขีดจำกัดใหม่ 1024 ไบต์อย่างมาก การเรียกใช้จริงส่วนใหญ่ใช้ความยาวที่น้อยกว่า เช่น 32 ไบต์ 128 ไบต์ หรือ 256 ไบต์

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

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

EIP-7825: วงเงินการทำธุรกรรม 16.7 ล้านแก๊ส

Ethereum จำเป็นต้องมีข้อเสนอนี้ เนื่องจากในปัจจุบันธุรกรรมเดียวเกือบจะใช้แก๊สทั้งบล็อกได้หมด

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

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

EIP-7825 ได้กำหนดกฎเกณฑ์ที่เข้มงวดขึ้น นั่นคือ ธุรกรรมใดๆ ต้องใช้แก๊สไม่เกิน 16,777,216 (2²⁴) กฎเกณฑ์ นี้จะกลายเป็นขีดจำกัดระดับโปรโตคอล ซึ่งหมายความว่ากฎเกณฑ์นี้ใช้กับทุกขั้นตอน ตั้งแต่ผู้ใช้ส่งธุรกรรม พูลธุรกรรมที่ตรวจสอบธุรกรรม และตัวตรวจสอบที่รวมธุรกรรมลงในบล็อก หากมีใครส่งแก๊สเกินขีดจำกัดนี้ ไคลเอ็นต์จะต้องปฏิเสธธุรกรรมทันทีและส่งข้อผิดพลาดเช่น MAX_GAS_LIMIT_EXCEEDED

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

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

ข้อเสนอนี้ยังกำหนดข้อกำหนดเฉพาะสำหรับวิธีที่ลูกค้าควรตรวจสอบธุรกรรม หากแก๊สของธุรกรรมเกิน 16,777,216 พูลธุรกรรมจะต้องปฏิเสธ ซึ่งหมายความว่าธุรกรรมดังกล่าวจะไม่ถูกจัดคิวไว้ด้วยซ้ำ ในระหว่างการตรวจสอบบล็อก หากบล็อกมีธุรกรรมเกินขีดจำกัด บล็อกนั้นจะต้องถูกปฏิเสธ

ตัวเลข 16,777,216 (2²⁴) ถูกเลือกเนื่องจากแสดงถึงขอบเขตอำนาจ 2 ที่ชัดเจน ทำให้ง่ายต่อการนำไปใช้งาน และยังคงมีขนาดใหญ่พอที่จะรองรับธุรกรรมส่วนใหญ่ในโลกแห่งความเป็นจริง เช่น การใช้งานสัญญาอัจฉริยะ การโต้ตอบ DeFi ที่ซับซ้อน หรือการเรียกใช้สัญญาหลายขั้นตอน ค่านี้มีขนาดประมาณครึ่งหนึ่งของขนาดบล็อกทั่วไป หมายความว่าแม้แต่ธุรกรรมที่ซับซ้อนที่สุดก็สามารถรักษาให้อยู่ในขีดจำกัดนี้ได้อย่างง่ายดาย

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

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

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

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

EIP-7883: อัตราค่าแก๊ส ModExp เพิ่มขึ้น

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

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

เพื่อแก้ไขปัญหานี้ Ethereum จำเป็นต้องปรับสูตรกำหนดราคา ModExp เพื่อให้การใช้แก๊สสะท้อนปริมาณงานที่ลูกค้าดำเนินการจริงได้อย่างแม่นยำ ดังนั้น EIP-7883 จึงได้นำกฎเกณฑ์ใหม่มาใช้ โดยเพิ่มต้นทุนแก๊สขั้นต่ำ เพิ่มต้นทุนแก๊สรวม และทำให้การดำเนินการที่มีปริมาณข้อมูลอินพุตขนาดใหญ่ (โดยเฉพาะการดำเนินการแบบยกกำลัง ฐาน หรือโมดูโลที่เกิน 32 ไบต์) มีราคาแพงขึ้น ทำให้การกำหนดราคาแก๊สสอดคล้องกับความต้องการในการประมวลผลจริง

ข้อเสนอนี้จะเพิ่มต้นทุนในหลายๆ วิธีหลัก ส่งผลให้มีการปรับเปลี่ยนอัลกอริธึมการกำหนดราคาของ ModExp ที่กำหนดไว้เดิมใน EIP-2565

ประการแรก ปริมาณการใช้ก๊าซขั้นต่ำได้เพิ่มขึ้นจาก 200 เป็น 500 และปริมาณการใช้ก๊าซรวมไม่ได้ถูกหารด้วย 3 อีกต่อไป ซึ่งหมายความว่าปริมาณการใช้ก๊าซรวมเพิ่มขึ้นเป็นสามเท่า ตัวอย่างเช่น หากการเรียก ModExp ก่อนหน้านี้ใช้ก๊าซ 1200 หน่วย ขณะนี้จะใช้พลังงานประมาณ 3600 หน่วยภายใต้สูตรใหม่

ประการที่สอง ค่าใช้จ่ายในการคำนวณจะเพิ่มขึ้นเป็นสองเท่าสำหรับเลขชี้กำลังที่ยาวกว่า 32 ไบต์ เนื่องจากตัวคูณจะเพิ่มขึ้นจาก 8 เป็น 16 ตัวอย่างเช่น หากเลขชี้กำลังมีความยาว 40 ไบต์ EIP-2565 จะเพิ่มจำนวนการวนซ้ำเป็น 8 × (40 − 32) = 64 ในขณะที่ EIP-7883 ใช้ 16 × (40 − 32) = 128 ทำให้ค่าใช้จ่ายเพิ่มขึ้นเป็นสองเท่า

ประการที่สาม การกำหนดราคาในปัจจุบันถือว่าขนาดฐาน/โมดูลัสขั้นต่ำอยู่ที่ 32 ไบต์ และต้นทุนการคำนวณจะเพิ่มขึ้นอย่างมากเมื่อค่าเหล่านี้เกิน 32 ไบต์ ตัวอย่างเช่น หากโมดูลัสคือ 64 ไบต์ กฎใหม่จะใช้ความซับซ้อนเป็นสองเท่า (2 × words²) แทนสูตรที่ง่ายกว่าเดิม ซึ่งสะท้อนต้นทุนจริงของการดำเนินการจำนวนมาก การเปลี่ยนแปลงเหล่านี้ร่วมกันทำให้มั่นใจได้ว่าการดำเนินการ ModExp ขนาดเล็กจะจ่ายค่าธรรมเนียมขั้นต่ำที่เหมาะสม และต้นทุนของการดำเนินการขนาดใหญ่ที่ซับซ้อนจะได้รับการปรับให้เหมาะสมตามขนาดของการดำเนินการ

ข้อเสนอนี้กำหนดฟังก์ชันการคำนวณแก๊สใหม่ และอัปเดตกฎสำหรับความซับซ้อนและจำนวนการวนซ้ำ ความซับซ้อนของการคูณใช้ค่าเริ่มต้นที่ 16 สำหรับความยาวฐาน/โมดูลัสที่ 32 ไบต์หรือน้อยกว่า ในขณะที่สำหรับอินพุตขนาดใหญ่กว่า จะเปลี่ยนไปเป็นสูตรที่ซับซ้อนกว่าคือ 2 × words² โดยที่ "words" หมายถึงจำนวนบล็อกขนาด 8 ไบต์ จำนวนการวนซ้ำยังได้รับการปรับปรุงเพื่อให้เลขยกกำลัง 32 ไบต์หรือน้อยกว่าใช้ความยาวบิตเพื่อกำหนดความซับซ้อน ในขณะที่เลขยกกำลังที่มากกว่า 32 ไบต์จะเสียค่า Gas Penalty ที่มากขึ้น

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

การขึ้นราคาเหล่านี้มีสาเหตุมาจากการทดสอบประสิทธิภาพ ซึ่งแสดงให้เห็นว่าราคาที่ ModExp รวบรวมไว้ล่วงหน้านั้นถูกประเมินค่าต่ำเกินไปอย่างมากในหลายกรณี สูตรที่ปรับปรุงใหม่นี้ทำให้ต้นทุนค่าก๊าซเพิ่มขึ้น 150% สำหรับการดำเนินงานขนาดเล็ก ประมาณ 200% สำหรับการดำเนินงานทั่วไป และหลายเท่า บางครั้งอาจเกิน 80 เท่า สำหรับการดำเนินงานขนาดใหญ่หรือการดำเนินงานที่ไม่สมดุล ทั้งนี้ขึ้นอยู่กับขนาดของเลขชี้กำลัง ฐาน หรือโมดูลัส

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

ผลการทดสอบแสดงให้เห็นว่าต้นทุนแก๊สที่เพิ่มขึ้นมีนัยสำคัญ ปัจจุบันการเรียกใช้ ModExp ในอดีตประมาณ 99.69% ต้องใช้แก๊ส 500 (เดิม 200) หรือสามเท่าของราคาเดิม อย่างไรก็ตาม ต้นทุนแก๊สที่เพิ่มขึ้นนั้นยิ่งสูงขึ้นสำหรับกรณีทดสอบที่มีภาระงานสูงบางกรณี ยกตัวอย่างเช่น ในการทดสอบแบบ "คำนวณแบบเอ็กซ์โพเนนเชียลเข้มข้น" ปริมาณการใช้แก๊สเพิ่มขึ้นจาก 215 เป็น 16,624 ซึ่งเพิ่มขึ้นประมาณ 76 เท่า เนื่องจากการกำหนดราคาสำหรับเลขชี้กำลังที่สูงมากในปัจจุบันมีความสมเหตุสมผลมากขึ้น

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

EIP-7917: การคาดการณ์ผู้เสนอรายต่อไปอย่างแม่นยำ

Ethereum ต้องการข้อเสนอนี้เนื่องจากไม่สามารถคาดการณ์ตารางเวลาของผู้เสนอสำหรับยุคถัดไปของเครือข่ายได้อย่างสมบูรณ์ แม้ว่าจะทราบค่า seed ของ RANDAO สำหรับยุคที่ N+1 ในยุคที่ N แต่รายชื่อผู้เสนอที่แท้จริงอาจยังคงเปลี่ยนแปลงได้เนื่องจากการอัปเดตยอดคงเหลือที่มีผลบังคับใช้ (EB) ภายในยุคที่ N

การเปลี่ยนแปลง EB เหล่านี้อาจเกิดจากการตัดทอน การลงโทษ รางวัลที่เกิน 1 ETH การรวมบัญชีผู้ตรวจสอบ หรือการฝากเงินใหม่ โดยเฉพาะอย่างยิ่งหลังจากที่ EIP-7251 เพิ่มยอดคงเหลือสูงสุดที่ใช้งานได้จริงเป็นมากกว่า 32 ETH ความไม่แน่นอนนี้ก่อให้เกิดปัญหาสำหรับระบบที่ต้องอาศัยการทราบผู้เสนอรายต่อไปล่วงหน้า (เช่น โปรโตคอลที่ได้รับการยืนยันล่วงหน้า) ซึ่งจำเป็นต้องมีกรอบเวลาที่มั่นคงและคาดการณ์ได้เพื่อให้ทำงานได้อย่างราบรื่น ผู้ตรวจสอบอาจพยายาม "ปั๊ม" หรือควบคุมยอดคงเหลือที่ใช้งานได้จริงเพื่อโน้มน้าวผู้เสนอรายต่อไปในยุคถัดไป

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

เพื่อให้บรรลุเป้าหมายนี้ EIP-7917 ได้นำเสนอกลไกการมองล่วงหน้าแบบกำหนดล่วงหน้าสำหรับข้อเสนอ (proposer lookahead) ซึ่งจะคำนวณและจัดเก็บกำหนดการข้อเสนอสำหรับ MIN_SEED_LOOKAHEAD + 1 epoch ถัดไป ณ จุดเริ่มต้นของแต่ละ epoch กล่าว โดยง่ายคือ สถานะบีคอนจะมีรายการชื่อ `prosoperer_lookahead` ซึ่งจะครอบคลุมข้อเสนอสองรอบเต็มเสมอ (รวม 64 ช่อง)

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

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

สมมติว่ามี 8 ช่องต่อยุค แทนที่จะเป็น 32 ช่อง (เพื่อความง่าย) หากไม่มี EIP นี้ ในช่วงยุคที่ 5 แม้ว่าคุณจะทราบค่า seed ของยุคที่ 6 แต่ผู้เสนอราคาจริงสำหรับช่องที่ 2 ในยุคที่ 6 ก็ยังคงสามารถเปลี่ยนแปลงได้ หากผู้ตรวจสอบถูกลงโทษหรือได้รับรางวัลมากพอที่จะเปลี่ยนแปลงยอดคงเหลือที่มีผลในช่วงยุคที่ 5 ด้วย EIP-7917 Ethereum จะคำนวณผู้เสนอราคาทั้งหมดสำหรับยุคที่ 5, 6 และ 7 ล่วงหน้า ณ จุดเริ่มต้นของยุคที่ 5 และจัดเก็บตามลำดับใน `prosopers_lookahead` ดังนั้น แม้ว่ายอดคงเหลือจะเปลี่ยนแปลงในภายหลังในยุคที่ 5 รายชื่อผู้เสนอราคาสำหรับยุคที่ 6 จะยังคงเดิมและสามารถคาดการณ์ได้

EIP-7917 แก้ไขข้อบกพร่องที่มีมายาวนานในการออกแบบ Beacon Chain โดยรับประกันว่าเมื่อ RANDAO ของยุคก่อนหน้าพร้อมใช้งานแล้ว การเลือกตัวตรวจสอบสำหรับยุคถัดไปจะไม่สามารถเปลี่ยนแปลงได้ นอกจากนี้ยังช่วยป้องกัน "การสับเปลี่ยนยอดคงเหลืออย่างมีประสิทธิภาพ" ซึ่งตัวตรวจสอบจะพยายามปรับยอดคงเหลือหลังจากเห็น RANDAO เพื่อควบคุมรายชื่อผู้เสนอสำหรับยุคถัดไป กลไกการมองไปข้างหน้าแบบกำหนดได้นี้ช่วยขจัดช่องโหว่การโจมตีทั้งหมด ทำให้การวิเคราะห์ความปลอดภัยง่ายขึ้นอย่างมาก นอกจากนี้ยังช่วยให้ไคลเอนต์ consensus ทราบล่วงหน้าว่าใครจะเป็นผู้เสนอบล็อกที่กำลังจะมาถึง ซึ่งอำนวยความสะดวกในการใช้งานและช่วยให้เลเยอร์แอปพลิเคชันสามารถตรวจสอบกำหนดการของผู้เสนอได้อย่างง่ายดายผ่าน Merkle proofs ของ beacon root

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

EIP-7918: ค่าธรรมเนียมฐาน Blob ถูกจำกัดโดยต้นทุนการดำเนินการ

Ethereum จำเป็นต้องมีข้อเสนอนี้เนื่องจากระบบค่าธรรมเนียม Blob ในปัจจุบัน (ได้มาจาก EIP-4844) ล้มเหลวเมื่อแก๊สกลายมาเป็นต้นทุนหลักในการหมุนเวียน

ปัจจุบัน แก๊สที่ใช้ในการดำเนินการ (ซึ่งเป็นต้นทุนของการรวมธุรกรรม Blob ไว้ในบล็อก) ที่ Rollups ส่วนใหญ่จ่ายนั้นสูงกว่าค่าธรรมเนียม Blob จริงมาก ซึ่งทำให้เกิดปัญหาคือ แม้ว่า Ethereum จะลดค่าธรรมเนียม Blob พื้นฐานลงอย่างต่อเนื่อง แต่ต้นทุนรวมของ Rollup ก็ไม่ได้เปลี่ยนแปลงไป เนื่องจากต้นทุนสูงสุดยังคงเป็นแก๊สที่ใช้ในการดำเนินการ ดังนั้น ค่าธรรมเนียม Blob พื้นฐานจะลดลงอย่างต่อเนื่องจนกว่าจะถึงขั้นต่ำสุด (1 wei) ซึ่ง ณ จุดนี้ โปรโตคอลจะไม่สามารถใช้ค่าธรรมเนียม Blob เพื่อควบคุมความต้องการได้อีกต่อไป จากนั้น เมื่อการใช้งาน Blob เพิ่มขึ้นอย่างกะทันหัน ค่าธรรมเนียม Blob จะต้องใช้เวลานานหลายบล็อกจึงจะฟื้นตัวกลับสู่ระดับปกติ ซึ่งทำให้ราคาไม่แน่นอนและคาดเดาได้ยากสำหรับผู้ใช้

ตัวอย่างเช่น สมมติว่า Rollup ต้องการเผยแพร่ข้อมูลของตน: จำเป็นต้องจ่ายแก๊สสำหรับการดำเนินการประมาณ 25,000,000 gwei (แก๊สประมาณ 1,000,000 ต้องใช้ 25 gwei) ในขณะที่ค่าธรรมเนียม Blob อยู่ที่ประมาณ 200 gwei เท่านั้น ซึ่งหมายความว่าต้นทุนรวมอยู่ที่ประมาณ 25,000,200 gwei โดยต้นทุนเกือบทั้งหมดมาจากแก๊สสำหรับการดำเนินการ ไม่ใช่ค่าธรรมเนียม Blob หาก Ethereum ยังคงลดค่าธรรมเนียม Blob ลง เช่น จาก 200 gwei เป็น 50 gwei จากนั้นเป็น 10 gwei และสุดท้ายเป็น 1 gwei ต้นทุนรวมแทบจะไม่เปลี่ยนแปลง โดยคงอยู่ที่ 25,000,000 gwei

EIP-7918 แก้ไขปัญหานี้โดยแนะนำ "ราคาสำรอง" ขั้นต่ำตามต้นทุนพื้นฐานการดำเนินการ จึงป้องกันไม่ให้ราคา Blob ต่ำเกินไป และทำให้ราคา Blob ของ Rollup มีเสถียรภาพและคาดเดาได้มากขึ้น

แนวคิดหลักของ EIP-7918 นั้นเรียบง่าย นั่นคือ ราคาของ blob ไม่ควรต่ำกว่าต้นทุนแก๊สที่ใช้ในการดำเนินการจำนวนหนึ่ง (เรียกว่า BLOB_BASE_COST) ค่าของ calc_excess_blob_gas() จะถูกตั้งไว้ที่ 2¹³ และกลไกนี้จะถูกนำไปใช้โดยการปรับเปลี่ยนเล็กน้อยในฟังก์ชัน calc_excess_blob_gas()

โดยทั่วไป ฟังก์ชันนี้จะเพิ่มหรือลดค่า Blob base fee โดยพิจารณาจากค่า blob gas ที่บล็อกใช้ว่าสูงกว่าหรือต่ำกว่าค่าเป้าหมาย ภายใต้ข้อเสนอนี้ หาก blob มีค่า "ต่ำเกินไป" เมื่อเทียบกับค่า execution gas ฟังก์ชันจะหยุดหักค่า blob gas เป้าหมาย ซึ่งจะทำให้ blob gas ส่วนเกินเพิ่มขึ้นอย่างรวดเร็วขึ้น และป้องกันไม่ให้ค่า blob base fee ลดลงอีก ดังนั้น ค่า blob base fee จึงมีค่าต่ำสุด เท่ากับ BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB

เพื่อทำความเข้าใจว่าเหตุใดจึงจำเป็น ลองมาดูความต้องการสำหรับ blob กัน Rollups มุ่งเน้นไปที่ต้นทุนรวมที่จ่ายไป ได้แก่ ต้นทุนการดำเนินการบวกกับต้นทุน blob หากต้นทุนก๊าซการดำเนินการสูงมาก เช่น 20 gwei แม้ว่าต้นทุน blob จะลดลงจาก 2 gwei เหลือ 0.2 gwei ต้นทุนรวมก็ยังคงแทบไม่เปลี่ยนแปลง ซึ่งหมายความว่าการลดต้นทุนพื้นฐานของ blob แทบจะไม่มีผลกระทบต่อความต้องการเลย ในทางเศรษฐศาสตร์ สิ่งนี้เรียกว่า "ความไม่ยืดหยุ่นของต้นทุน" ซึ่งทำให้เกิดสถานการณ์ที่เส้นอุปสงค์เกือบจะตั้งฉาก นั่นคือ การลดราคาไม่ได้ทำให้ความต้องการเพิ่มขึ้น

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

อีกเหตุผลหนึ่งที่ต้องเพิ่มราคาจองนี้คือ โหนดจำเป็นต้องทำงานเพิ่มเติมอย่างมากเพื่อตรวจสอบการพิสูจน์ KZG ของข้อมูลแบบบล็อบ การพิสูจน์เหล่านี้รับประกันว่าข้อมูลในบล็อบตรงตามที่คาดหวัง ภายใต้ EIP-4844 โหนดจำเป็นต้องตรวจสอบการพิสูจน์เพียงหนึ่งรายการสำหรับแต่ละบล็อบ ซึ่งมีค่าใช้จ่ายที่ไม่แพง อย่างไรก็ตาม ใน EIP-7918 โหนดจำเป็นต้องตรวจสอบการพิสูจน์จำนวนมากขึ้นมาก ทั้งนี้เนื่องจากใน EIP-7594 (PeerDAS) บล็อบจะถูกแบ่งออกเป็นส่วนเล็กๆ จำนวนมากที่เรียกว่าเซลล์ ซึ่งแต่ละเซลล์มีหลักฐานของตัวเอง ซึ่งจะเพิ่มภาระงานในการตรวจสอบอย่างมาก

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

เมื่อพื้นที่ Blob และพื้นที่บล็อกการดำเนินการขยายตัว ความสัมพันธ์ด้านราคาจะยังคงสมดุล มีเพียงบางกรณีที่ Ethereum เพิ่มความจุ Blob อย่างมีนัยสำคัญโดยไม่เพิ่มความจุแก๊สการดำเนินการ ราคาสำรองอาจสูงเกินไป ในสถานการณ์เช่นนี้ ค่าธรรมเนียม Blob อาจเกินความต้องการที่แท้จริงในที่สุด อย่างไรก็ตาม Ethereum ไม่มีแผนที่จะขยายตัวในลักษณะนี้ คาดว่าพื้นที่ Blob และพื้นที่บล็อกการดำเนินการจะเติบโตไปพร้อมๆ กัน ดังนั้น ค่าที่เลือก (BLOB_BASE_COST = 2¹³) จึงถือว่าปลอดภัยและสมดุล

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

ผู้เขียนยังได้ทำการวิเคราะห์เชิงประจักษ์เกี่ยวกับกิจกรรมธุรกรรมบล็อกจริงตั้งแต่เดือนพฤศจิกายน 2567 ถึงเดือนมีนาคม 2568 โดยใช้กฎราคาสำรอง ในช่วงที่มีค่าธรรมเนียมการดำเนินการสูง (เฉลี่ยประมาณ 16 gwei) เกณฑ์ราคาสำรองจะเพิ่มค่าธรรมเนียมบล็อกพื้นฐานอย่างมีนัยสำคัญเมื่อเทียบกับกลไกเดิม ในช่วงที่มีค่าธรรมเนียมการดำเนินการต่ำ (เฉลี่ยประมาณ 1.3 gwei) ค่าธรรมเนียมบล็อกจะเกือบคงที่ เว้นแต่ค่าธรรมเนียมบล็อกพื้นฐานที่คำนวณได้จะต่ำกว่าราคาสำรอง จากการเปรียบเทียบบล็อกหลายพันบล็อก ผู้เขียนแสดงให้เห็นว่ากลไกใหม่นี้สร้างราคาที่มีเสถียรภาพมากขึ้น ในขณะที่ยังคงตอบสนองต่อความต้องการได้อย่างเป็นธรรมชาติ ฮิสโทแกรมค่าธรรมเนียมบล็อกเป็นเวลาสี่เดือนแสดงให้เห็นว่าราคาสำรองป้องกันไม่ให้ค่าธรรมเนียมบล็อกลดลงเหลือ 1 gwei ซึ่งจะช่วยลดความผันผวนอย่างรุนแรง

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

EIP-7934: RLP บังคับใช้ข้อจำกัดขนาดบล็อก

ก่อน EIP-7934 Ethereum ไม่มีขีดจำกัดขนาดบล็อกการประมวลผลที่เข้ารหัสด้วย RLP ที่เข้มงวด ในทางทฤษฎี หากบล็อกมีธุรกรรมจำนวนมากหรือข้อมูลที่ซับซ้อนมาก ขนาดของบล็อกอาจมีขนาดใหญ่มากได้ ซึ่งก่อให้เกิดปัญหาหลักสองประการ ได้แก่ ความไม่เสถียรของเครือข่าย และความเสี่ยงจากการโจมตีแบบปฏิเสธการให้บริการ (DoS)

หากบล็อกมีขนาดใหญ่เกินไป โหนดต่างๆ จะใช้เวลาในการดาวน์โหลดและตรวจสอบนานขึ้น ส่งผลให้การแพร่กระจายบล็อกช้าลงและเพิ่มโอกาสในการเกิดการ Fork ชั่วคราวของบล็อกเชน ยิ่งไปกว่านั้น ผู้โจมตีอาจจงใจสร้างบล็อกขนาดใหญ่มากเพื่อโอเวอร์โหลดโหนด ทำให้เกิดความล่าช้าหรือทำให้โหนดออฟไลน์ ซึ่งเป็นการโจมตีแบบปฏิเสธการให้บริการแบบคลาสสิก นอกจากนี้ โปรโตคอล Gossip ในชั้น Consensus Layer (CL) ของ Ethereum ยังปฏิเสธที่จะเผยแพร่บล็อกใดๆ ที่มีขนาดใหญ่กว่า 10MB ซึ่งหมายความว่าบล็อกการดำเนินการที่มีขนาดใหญ่เกินไปอาจล้มเหลวในการเผยแพร่ผ่านเครือข่าย ทำให้เกิดการแตกกระจายภายในเครือข่ายหรือความขัดแย้งระหว่างโหนดต่างๆ ด้วยความเสี่ยงเหล่านี้ Ethereum จำเป็นต้องมีกฎเกณฑ์ระดับโปรโตคอลที่ชัดเจนเพื่อป้องกันบล็อกขนาดใหญ่เกินไปและรักษาเสถียรภาพและความปลอดภัยของเครือข่าย

EIP-7934 แก้ไขปัญหานี้โดยนำการเข้ารหัส RLP ระดับโปรโตคอลมาใช้เพื่อบังคับใช้ขีดจำกัดขนาดบล็อก ขนาดบล็อกสูงสุดที่อนุญาต (MAX_BLOCK_SIZE) ถูกกำหนดไว้ที่ 10 MiB (10,485,760 ไบต์) แต่ Ethereum เพิ่ม 2 MiB (2,097,152 ไบต์) ให้กับขีดจำกัดนี้ เนื่องจากบล็อกบีคอนก็ใช้พื้นที่บางส่วน (SAFETY_MARGIN) เช่นกัน

ซึ่งหมายความว่าขนาดบล็อกที่เข้ารหัส RLP สูงสุดที่อนุญาตคือ MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN หากบล็อกที่เข้ารหัสเกินขีดจำกัดนี้ จะถือว่าบล็อกนั้นไม่ถูกต้อง และโหนดต้องปฏิเสธบล็อกนั้น ตามกฎนี้ ผู้ผลิตบล็อกต้องตรวจสอบขนาดที่เข้ารหัสของแต่ละบล็อกที่พวกเขาสร้าง และผู้ตรวจสอบต้องยืนยันขีดจำกัดนี้ในระหว่างการตรวจสอบบล็อก ขีดจำกัดขนาดนี้ไม่ขึ้นอยู่กับขีดจำกัดแก๊ส หมายความว่าแม้ว่าบล็อกจะ "ต่ำกว่าขีดจำกัดแก๊ส" บล็อกนั้นจะยังคงถูกปฏิเสธหากขนาดที่เข้ารหัสมีขนาดใหญ่เกินไป วิธีนี้ช่วยให้มั่นใจได้ว่าทั้งการใช้งานแก๊สและขีดจำกัดขนาดไบต์จริงเป็นไปตามขีดจำกัด

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

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

ด้านความปลอดภัย EIP-7934 ช่วยเพิ่มความสามารถของ Ethereum ในการต้านทานการโจมตีแบบ DoS ที่มุ่งเป้าไปที่ขนาดบล็อกเฉพาะได้อย่างมีนัยสำคัญ โดยมั่นใจได้ว่าไม่มีผู้มีส่วนร่วมรายใดสามารถสร้างบล็อกที่อาจทำลายเครือข่ายได้ สรุปได้ว่า EIP-7934 ได้เพิ่มขอบเขตความปลอดภัยที่สำคัญ ปรับปรุงเสถียรภาพ กำหนดมาตรฐานการทำงานของ Execution Logic (EL) และ CL และป้องกันการโจมตีต่างๆ ที่เกี่ยวข้องกับการสร้างและการแพร่กระจายบล็อกขนาดใหญ่เกินไป

EIP-7939: คำนวณรหัสโอปโค้ดเลขศูนย์นำหน้า (CLZ)

ก่อน EIP นี้ Ethereum ไม่มีโอปโค้ดในตัวสำหรับคำนวณจำนวนเลขศูนย์นำหน้าในตัวเลข 256 บิต นักพัฒนาต้องติดตั้งฟังก์ชัน CLZ ด้วยตนเองโดยใช้ Solidity ซึ่งต้องใช้การดำเนินการและการเปรียบเทียบบิตจำนวนมาก

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

EIP-7939 แก้ไขปัญหานี้โดยแนะนำโอปโค้ดใหม่ชื่อ CLZ (0x1e) โอปโค้ดนี้จะอ่านค่า 256 บิตจากสแต็กและส่งกลับจำนวนเลขศูนย์นำหน้า หากตัวเลขอินพุตเป็นศูนย์ โอปโค้ดจะส่งกลับ 256 เนื่องจากเลขศูนย์ขนาด 256 บิตจะมีเลขศูนย์นำหน้า 256 ตัว

สิ่งนี้สอดคล้องกับวิธีการทำงานของ CLZ ในสถาปัตยกรรม CPU มากมาย เช่น ARM และ x86 ซึ่งรองรับการทำงานของ CLZ อยู่แล้ว การเพิ่ม CLZ สามารถลดค่าใช้จ่ายของอัลกอริทึมต่างๆ ได้อย่างมาก เช่น การดำเนินการต่างๆ เช่น lnWad, powWad, LambertW, ฟังก์ชันทางคณิตศาสตร์ต่างๆ, การเปรียบเทียบสตริงไบต์, การสแกนบิตแมป, การเรียกใช้การบีบอัด/คลายการบีบอัดข้อมูล และโครงร่างลายเซ็นหลังควอนตัม ล้วนได้รับประโยชน์จากการตรวจจับแบบ zero-lookahead ที่รวดเร็วยิ่งขึ้น

ต้นทุนก๊าซของ CLZ ถูกกำหนดไว้ที่ 5 ใกล้เคียงกับ ADD และสูงกว่าราคา MUL เดิมเล็กน้อย เพื่อหลีกเลี่ยงความเสี่ยงจากการโจมตีแบบปฏิเสธการให้บริการ (DoS) อันเนื่องมาจากการกำหนดราคาที่ต่ำกว่าความเป็นจริง เกณฑ์มาตรฐานแสดงให้เห็นว่าต้นทุนการประมวลผลของ CLZ ใกล้เคียงกับของ ADD และในสภาพแวดล้อมการพิสูจน์ SP1 rv32im ต้นทุนการพิสูจน์ของ CLZ ต่ำกว่าของ ADD จริง ๆ ซึ่งช่วยลดต้นทุนของการพิสูจน์แบบ Zero-Knowledge

EIP-7939 เข้ากันได้ย้อนหลังอย่างสมบูรณ์เนื่องจากมีการแนะนำโอปโค้ดใหม่และไม่ปรับเปลี่ยนพฤติกรรมที่มีอยู่ใดๆ

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

EIP-7951: รองรับลายเซ็นสำหรับฮาร์ดแวร์สมัยใหม่

ก่อน EIP นี้ Ethereum ขาดวิธีการดั้งเดิมที่ปลอดภัยในการตรวจสอบลายเซ็นดิจิทัลที่สร้างขึ้นโดยใช้เส้นโค้ง secp256r1 (P-256)

เส้นโค้งนี้เป็นมาตรฐานที่ใช้โดยอุปกรณ์สมัยใหม่ เช่น Apple Secure Enclave, Android Keystore, HSM, TEE และคีย์ความปลอดภัย FIDO2/WebAuthn หากปราศจากการสนับสนุนนี้ แอปพลิเคชันและวอลเล็ตจะไม่สามารถดำเนินการลายเซ็นโดยใช้การรักษาความปลอดภัยฮาร์ดแวร์ระดับอุปกรณ์ได้อย่างง่ายดาย ความพยายามก่อนหน้านี้ (RIP-7212) มีช่องโหว่ด้านความปลอดภัยที่ร้ายแรงสองจุด ซึ่งเกี่ยวข้องกับการจัดการจุดอนันต์และการเปรียบเทียบลายเซ็นที่ไม่ถูกต้อง ปัญหาเหล่านี้อาจนำไปสู่ข้อผิดพลาดในการตรวจสอบและแม้แต่ความล้มเหลว ของข้อตกลง EIP-7951 ได้แก้ไขปัญหาด้านความปลอดภัยเหล่านี้และแนะนำโปรโตคอลที่คอมไพล์ล่วงหน้าแบบเนทีฟที่ปลอดภัย ซึ่งในที่สุด Ethereum ก็สามารถรองรับลายเซ็นจากฮาร์ดแวร์สมัยใหม่ได้อย่างปลอดภัยและมีประสิทธิภาพ

EIP-7951 เพิ่มสัญญาที่คอมไพล์ไว้ล่วงหน้าใหม่ชื่อ P256VERIFY ที่แอดเดรส 0x100 ซึ่งดำเนินการตรวจสอบลายเซ็น ECDSA โดยใช้เส้นโค้ง secp256r1 ซึ่งทำให้การตรวจสอบลายเซ็นรวดเร็วและประหยัดค่าใช้จ่ายเมื่อเทียบกับการนำอัลกอริทึมนี้ไปใช้โดยตรงใน Solidity

EIP-7951 ยังกำหนดกฎการตรวจสอบอินพุตที่เข้มงวด หากมีกรณีที่ไม่ถูกต้อง การคอมไพล์ล่วงหน้าจะส่งคืนข้อผิดพลาดโดยไม่ย้อนกลับ ซึ่งใช้แก๊สเท่ากับการเรียกที่สำเร็จ อัลกอริทึมการตรวจสอบนี้ปฏิบัติตาม ECDSA มาตรฐาน: คำนวณ s⁻¹ mod n สร้างจุดลายเซ็น R' ขึ้นใหม่ ปฏิเสธหาก R' อยู่ที่อินฟินิตี้ และสุดท้ายตรวจสอบว่าพิกัด x ของ R' ตรงกับ r (mod n) หรือไม่ วิธีนี้แก้ไขข้อผิดพลาดใน RIP-7212 ซึ่งเปรียบเทียบ r' โดยตรง แทนที่จะลดรูปเป็น modulo n ก่อน

ค่าธรรมเนียมแก๊สสำหรับการดำเนินการนี้กำหนดไว้ที่ 6900 แก๊ส ซึ่งสูงกว่าเวอร์ชัน RIP-7212 แต่สอดคล้องกับเกณฑ์มาตรฐานประสิทธิภาพจริงที่ตรวจสอบโดย secp256r1 ที่สำคัญ อินเทอร์เฟซนี้เข้ากันได้อย่างสมบูรณ์กับเครือข่ายเลเยอร์ 2 ที่ได้ใช้งาน RIP-7212 อยู่แล้ว (ที่อยู่เดียวกัน รูปแบบอินพุต/เอาต์พุตเดียวกัน) ดังนั้นสัญญาอัจฉริยะที่มีอยู่จะยังคงทำงานได้ตามปกติโดยไม่มีการเปลี่ยนแปลงใดๆ ความแตกต่างเพียงอย่างเดียวคือพฤติกรรมที่ปรับปรุงใหม่และค่าธรรมเนียมแก๊สที่สูงขึ้น

จากมุมมองด้านความปลอดภัย EIP-7951 ช่วยฟื้นฟูพฤติกรรมที่ถูกต้องของ ECDSA ขจัดปัญหาความยืดหยุ่นในระดับที่คอมไพล์ไว้ล่วงหน้า (โดยปล่อยให้แอปพลิเคชันตรวจสอบเพิ่มเติม) และระบุอย่างชัดเจนว่าการคอมไพล์ล่วงหน้าไม่จำเป็นต้องมีการดำเนินการแบบคงที่ เส้นโค้ง secp256r1 ให้ความปลอดภัย 128 บิต และได้รับความน่าเชื่อถือและการวิเคราะห์อย่างกว้างขวาง ทำให้ปลอดภัยสำหรับการใช้งานบน Ethereum

โดยสรุป EIP-7951 มีเป้าหมายเพื่อนำการตรวจสอบสิทธิ์ที่รองรับฮาร์ดแวร์สมัยใหม่มาสู่ Ethereum อย่างปลอดภัย แก้ไขปัญหาความปลอดภัยในข้อเสนอครั้งก่อน และมอบวิธีการที่เชื่อถือได้และเป็นมาตรฐานในการตรวจสอบลายเซ็น P-256 ทั่วทั้งระบบนิเวศ

สรุป

ตารางด้านล่างสรุปว่าไคลเอ็นต์ Ethereum ใดที่ต้องมีการเปลี่ยนแปลงสำหรับ Fusaka EIP ต่างๆ เครื่องหมายถูกใต้ "Consensus Client" หมายความว่า EIP จำเป็นต้องอัปเดตไคลเอ็นต์ชั้น consensus ขณะที่เครื่องหมายถูกใต้ "Execution Client" หมายความว่าการอัปเกรดจะส่งผลต่อไคลเอ็นต์ชั้น execution EIP บางรายการจำเป็นต้องอัปเดตทั้งชั้น consensus และชั้น execution ในขณะที่บางรายการจำเป็นต้องอัปเดตเพียงชั้นใดชั้นหนึ่งเท่านั้น

โดยสรุปแล้ว นี่คือ EIP สำคัญที่รวมอยู่ในฮาร์ดฟอร์ก Fusaka แม้ว่าการอัปเกรดนี้จะเกี่ยวข้องกับการปรับปรุงหลายอย่างสำหรับไคลเอนต์ consensus และ Execution ตั้งแต่การปรับค่า gas และการอัปเดต opcode ไปจนถึงเวอร์ชันที่คอมไพล์ล่วงหน้าใหม่ แต่หัวใจสำคัญของการอัปเกรดนี้ยังคงเป็น PeerDAS ซึ่งนำการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลแบบเพียร์ทูเพียร์มาใช้ ซึ่งช่วยให้การประมวลผลข้อมูล Blob ทั่วทั้งเครือข่ายมีประสิทธิภาพและกระจายศูนย์มากขึ้น