EIP-8141 담은 프레임 트랜잭션, 이더리움(ETH) 검증·실행 분리 논의 재점화

วิตาลิก บูเทริน(Vitalik Buterin) ผู้ร่วมก่อตั้งอีเธอเรียม(ETH) หยิบยกแนวคิดออกแบบรูปแบบธุรกรรมอีเธอเรียมขึ้นมาอีกครั้ง โดยเสนอให้แยกขั้นตอน 'การตรวจสอบ' ออกจาก 'การประมวลผล' เพื่อรับมือปัญหาการขยายขนาดเครือข่ายและความเป็นส่วนตัวไปพร้อมกัน

บูเทรินอธิบายผ่านโพสต์บน X เมื่อเร็ว ๆ นี้ว่า ในโมเดลปี 2015 การประมวลผลและสถานะ(state) ของธุรกรรมยังมองเป็นก้อนเดียวกันได้ แต่กลยุทธ์ขยายขนาดปัจจุบันต้องแยกส่วนที่ 'ยืดหยุ่นแบบไดนามิก' ออกจากส่วนที่ 'วิเคราะห์ได้แบบสถิต' เขาระบุว่ากิจกรรมบนเครือข่ายอีเธอเรียมกว่า 90% ไม่จำเป็นต้องพึ่งความยืดหยุ่นแบบไดนามิก ส่วนที่ไม่เกี่ยวกับสถานะโดยตรงจึงประมวลผลครั้งเดียวในขั้นตอนเมมพูล(mempool) แล้วแทนที่ด้วยการพิสูจน์แบบสตาร์ก(STARK) ได้

หัวใจของแนวคิดนี้คือร่างเอกสาร EIP-8141 หรือ 'เฟรมทรานแซกชัน'(Frame Transaction) เอกสารข้อเสนอปรับปรุงอีเธอเรียมระบุว่า EIP-8141 จะแบ่งธุรกรรมออกเป็นหลายเฟรม โดยแต่ละเฟรมแยกขั้นตอนการตรวจสอบ การจ่ายค่าธรรมเนียม และการประมวลผลคำสั่งผู้ใช้ออกจากกัน

EIP-8141 เป็นร่างเอกสารที่จัดทำเมื่อวันที่ 29 มกราคม 2026 โดยบูเทรินมีชื่อเป็นหนึ่งในผู้ร่วมเขียน เอกสารระบุว่าเฟรมทรานแซกชันต้องการนำเป้าหมายดั้งเดิมของการแยกบัญชีออกจากรูปแบบลายเซ็น(account abstraction) มาปรับใช้ในระดับโปรโตคอลโดยตรง

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

ธุรกรรมแบบเดิมมักถูกมองว่าการประมวลผลและการตรวจสอบเป็นก้อนเดียวกัน แต่การออกแบบใหม่จะตัดแบ่งธุรกรรมเป็นหน่วยย่อยเรียกว่าเฟรม แบ่งเป็นเฟรม VERIFY สำหรับตรวจสอบ เฟรม SENDER สำหรับประมวลผล และเฟรมสำหรับขั้นตอนพื้นฐานอื่น ๆ

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

ประเด็นนี้ไม่ได้จำกัดอยู่แค่ข้อเสนอเดียว EIP-8250 หรือ 'คีย์เอ็ดนอนซ์'(Keyed Nonces) เสนอเพิ่มพื้นที่นอนซ์(nonce) อิสระให้เฟรมทรานแซกชัน มาจากปัญหาที่ว่าหากใช้นอนซ์เชิงเส้นเพียงชุดเดียว ธุรกรรมของผู้ใช้หลายคนจากที่อยู่ผู้ส่งเดียวกันอาจขวางกันเอง

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

กระทู้รวมข้อเสนออัปเกรดเครือข่ายชื่อ 'เฮโกตา'(Hegota) บนเว็บไซต์อีเธอเรียม เมจิเชียนส์(Ethereum Magicians) รวมเฟรมทรานแซกชัน คีย์เอ็ดนอนซ์ รีเซนต์รูตส์(Recent Roots) และโฟซิล(FOCIL) ไว้เป็นแกนด้านความปลอดภัย ความเป็นส่วนตัว และประสบการณ์ผู้ใช้ สะท้อนว่าการออกแบบรูปแบบธุรกรรมใหม่ไม่ใช่การทดลองแยกเดี่ยว แต่ถูกนับเป็นส่วนหนึ่งของการหารืออัปเกรดครั้งถัดไป

ฝั่งไคลเอนต์สำหรับประมวลผล(execution client) ก็มีการทดลองบนเทสต์เน็ตต่อเนื่อง ประกาศที่เผยแพร่ในอุตสาหกรรมระบุว่า 'อีธเร็กซ์'(ethrex) กำลังเปิดทดสอบบนเทสต์เน็ตสาธารณะที่รวม EIP กลุ่มเฟรมทรานแซกชัน คีย์เอ็ดนอนซ์ รีเซนต์รูตส์ และโฟซิลไว้ด้วยกัน ถือเป็นสัญญาณว่าการหารือในเอกสารเริ่มขยับลงสู่ขั้นตอนเดฟเน็ตและเทสต์เน็ตแล้ว

ปฏิกิริยาจากชุมชนนักพัฒนาแบ่งเป็นสองฝั่ง ทั้งด้านทิศทางการออกแบบและภาระด้านการพัฒนา ในกระทู้ถกเถียง EIP-8141 มีความเห็นตอบรับอย่าง "This looks great!" แต่ตามมาด้วยคำถามหลายข้อ เช่น จะจัดการอย่างไรหากมีหลายเฟรม VERIFY พร้อมกัน ความเป็นไปได้ของ 'มัลติคอลแบบอะตอมิก'(atomic multicall) และความซับซ้อนของคำสั่งใหม่รวมถึงการตรวจสอบความทนทานระดับโปรโตคอล

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

ประเด็นนี้เชื่อมโยงกับรายงานก่อนหน้านี้ของโทเคนโพสต์ที่ระบุว่าอีเธอเรียมยกระดับความทนทานต่อควอนตัมและความเป็นส่วนตัวขึ้นเป็นวาระหลักในโรดแมประยะยาว ก่อนหน้านี้บูเทรินเคยจัดลำดับความสำคัญของความปลอดภัยจากควอนตัม ความเป็นส่วนตัวระดับสูง สตาร์กแบบเรียกซ้ำ(recursive STARK) และการตรวจสอบเชิงรูปนัย(formal verification) ไว้สูงขึ้นในโรดแมประยะยาวเช่นกัน

อย่างไรก็ตาม ทั้ง EIP-8141 และ EIP-8250 ยังอยู่ในสถานะร่าง(draft) ยังไม่มีการกำหนดตารางเวลานำไปใช้บนเมนเน็ต การเปลี่ยนแปลงที่ยืนยันได้ในขณะนี้จึงยังเป็นเพียงการหารือด้านการออกแบบโปรโตคอลว่าจะแบ่งและตรวจสอบรูปแบบธุรกรรมอย่างไร ไม่ใช่การอัปเกรดที่ได้ข้อสรุปแล้ว