Native Account Abstraction + Quantum Resistance: Why Hasn't EIP-8141 Become the Headliner for Ethereum's Hegota Yet?
- Key Point: The EIP-8141 (Frame Transaction) proposal aims to implement native account abstraction from the bottom layer of the Ethereum protocol, endowing accounts with flexible, programmable verification and execution logic to solve core issues such as gas payment, multi-step operations, account security, and future quantum-resistant signatures. Although it has not been listed as the headline feature for the Hegota upgrade, it has entered the formal evaluation stage of "considered for inclusion."
- Key Elements:
- Proposal Goal: Introduce a new "Frame Transaction" type, deconstructing transaction validation, payment, and execution into programmable "frames," aiming to break the binding between accounts and a single ECDSA signature at the protocol level.
- Potential Impact: Could enable paying gas with stablecoins, merging multi-step operations, natively supporting security rules like multi-signature/social recovery, and providing the possibility for future migration to quantum-resistant signature schemes.
- Current Progress: Achieved "considered for inclusion" status in core developer meetings but was not directly included in the Hegota upgrade. The main reasons are high complexity in client implementation, transaction pool security, and insufficient consensus.
- Industry Context: ERC-4337 and EIP-7702 are already advancing account abstraction at the application layer, while Google's quantum computing research shows a significant reduction in the estimated qubits needed to break ECDSA, increasing the urgency of upgrading the signature system.
- Next Steps: The proposal will continue to be refined and evaluated by developer meetings. It may be advanced or deferred in future upgrades. Its core value lies in formally placing the ultimate solution for native account abstraction on the protocol discussion agenda.
สัปดาห์ที่แล้ว การประชุมนักพัฒนาหลักของ Ethereum ได้มีการหารืออย่างเป็นทางการเกี่ยวกับการรวม EIP-8141 ในการอัปเกรด Hegota ผลลัพธ์กลับน่าประหลาดใจ ข้อเสนอนี้ซึ่งได้รับการสนับสนุนโดยตรงจาก Vitalik เอง ไม่ได้ถูกกำหนดให้เป็น "ฟีเจอร์หลัก" ของ Hegota แต่ได้รับสถานะ "อยู่ระหว่างการพิจารณาเพื่อรวม" (CFI) แทน
และในสัปดาห์นี้ ทีม Google Quantum AI ได้เผยแพร่ไวท์เปเปอร์ล่าสุด ระบุว่าภายใต้สมมติฐานฮาร์ดแวร์ที่กำหนด การประมาณจำนวนคิวบิตทางกายภาพที่จำเป็นสำหรับการแคร็ก ECDLP-256 ลดลงอย่างมากถึง 20 เท่าเมื่อเทียบกับก่อนหน้านี้ แม้ว่าจะไม่ได้หมายความว่าการโจมตีด้วยควอนตัมจะเกิดขึ้นในเร็ววัน แต่ก็เตือนเราอย่างแท้จริงว่า หากระบบบัญชีในอนาคตไม่สามารถเปลี่ยนตรรกะการตรวจสอบได้อย่างยืดหยุ่น การอภิปรายมากมายเกี่ยวกับประสบการณ์การใช้กระเป๋าเงินในวันนี้ อาจกลายเป็นปัญหาด้านความปลอดภัยในที่สุด
แม้ว่าจากมุมมองความเป็นจริงของการพัฒนาพรอโตคอล EIP-8141 ยังคงมีน้ำหนักมากเกินไปในปัจจุบัน โดยเฉพาะในด้านการนำไปใช้ในไคลเอนต์ ความปลอดภัยของพูลธุรกรรม และความซับซ้อนของการตรวจสอบ ยังไม่มีความเห็นพ้องต้องกันที่แข็งแกร่งเพียงพอ
แต่ ณ จุดเวลาปัจจุบันนี้ ดูเหมือนว่าจุดที่ EIP-8141 คุ้มค่าต่อการอภิปรายและพิจารณาอย่างจริงจัง จะมีมากขึ้นเรื่อยๆ จริงๆ
1. EIP-8141 ต้องการแก้ไขปัญหาอะไรกันแน่?
EIP-8141 ผลักดันโดย Vitalik Buterin และผู้มีส่วนร่วมหลักอย่าง timbeiko และอื่นๆ มีชื่ออย่างเป็นทางการว่า Frame Transactions (ธุรกรรมเฟรม)
หากจะสรุปให้เข้าใจง่ายขึ้น สิ่งที่มันต้องการทำไม่ใช่การเพิ่มฟีเจอร์กระเป๋าเงินใดๆ เพียงอย่างเดียว แต่พยายามให้บัญชีใดๆ ก็ตามไม่ต้องถูกผูกมัดด้วยเส้นทางลายเซ็น ECDSA เดียวอีกต่อไป แต่สามารถมีตรรกะการตรวจสอบและการดำเนินการที่ยืดหยุ่นมากขึ้นได้ ในระดับพรอโตคอล
นี่หมายความว่า การเซ็นแบบหลายคน การสนับสนุนค่าแก๊ส การหมุนเวียนคีย์ การกู้คืนผ่านโซเชียล และแม้แต่การเชื่อมต่อกับแผนการลายเซ็นต้านทานควอนตัมในอนาคต จะไม่ใช่แค่ความสามารถชั้นนอกที่แขวนไว้กับกระเป๋าเงินอีกต่อไป แต่มีโอกาสที่จะกลายเป็น "สมาชิกดั้งเดิม" ในระบบบัญชีของ Ethereum
หากมองเพียงผิวเผิน EIP-8141 กำลังพูดถึงชุดความสามารถที่ดูเฉพาะเจาะจงมาก: การใช้สเตเบิลคอยน์จ่ายค่าแก๊ส การรวมการดำเนินการหลายขั้นตอนเป็นธุรกรรมเดียว การสนับสนุนวิธีการเซ็นที่ยืดหยุ่นมากขึ้น และแม้แต่การเตรียมพื้นที่สำหรับลายเซ็นต้านทานควอนตัมในอนาคต กล่าวได้ว่า การปรับปรุงมากมายเกี่ยวกับประสบการณ์กระเป๋าเงิน ตั้งแต่ ERC-4337 ถึง EIP-7702 ในหลายปีที่ผ่านมา โดยพื้นฐานแล้วล้วนทำให้บัญชีไม่ใช่แค่คีย์ส่วนตัวอีกต่อไป แต่เป็นทางเข้าที่สามารถกำหนดกฎเองได้
ปัญหาอยู่ที่ว่า การปรับปรุงเหล่านี้ทำให้กระเป๋าเงินดูเหมือน Smart Account มากขึ้นจริงๆ แต่ยังไม่เคยแตะต้องโมเดลบัญชีพื้นฐานสุดของ Ethereum อย่างแท้จริง
เป็นที่ทราบกันดีว่าในระบบปัจจุบัน บัญชี Ethereum แบ่งออกเป็นสองประเภทหลัก ประเภทแรกคือบัญชีภายนอก (Externally Owned Account - EOA) ซึ่งเป็นที่คุ้นเคยที่สุด ควบคุมโดยคีย์ส่วนตัว สามารถเริ่มธุรกรรมได้เอง แต่ขาดความสามารถในการโปรแกรม ประเภทที่สองคือบัญชีสัญญา (Contract Account) ซึ่งก็คือ Smart Contract นั่นเอง สามารถดำเนินตรรกะที่ซับซ้อนได้ แต่ไม่สามารถเริ่มธุรกรรมได้เอง
สิ่งนี้นำไปสู่ความสามารถในการเริ่มธุรกรรม ที่ถูกผูกมัดกับลายเซ็นคีย์ส่วนตัวเดียวมาเป็นเวลานาน ตราบใดที่เงื่อนไขนี้ไม่เปลี่ยนแปลง ความสามารถมากมายที่ผู้ใช้ในวันนี้คิดว่าควรจะมีโดยธรรมชาติ เช่น การเปลี่ยนกฎการเซ็นได้อย่างยืดหยุ่น การให้ผู้อื่นจ่ายค่าแก๊สแทน การกู้คือสิทธิ์ควบคุมบัญชีหลังจากสูญเสียคีย์ส่วนตัว หรือการย้ายไปยังระบบรหัสผ่านใหม่ในอนาคตอย่างราบรื่น ก็ยากที่จะกลายเป็นความสามารถพื้นฐานของบัญชีอย่างแท้จริง
หากคุณเคยใช้ imToken หรือกระเป๋าเงิน Web3 อื่นๆ คุณก็มีโอกาสสูงที่จะเคยประสบกับปัญหาต่างๆ เหล่านี้ เช่น มี USDC อยู่ในกระเป๋าเงินมากมาย แต่ไม่มี ETH ก็ส่งธุรกรรมไม่ได้ (เพราะค่าแก๊สจ่ายได้ด้วย ETH เท่านั้น) สูญเสียวลีช่วยจำก็สูญเสียเงินไปโดยสิ้นเชิง ไม่สามารถกู้คืนได้ การดำเนินการ "อนุมัติ + แลกเปลี่ยน" ต้องเซ็นสองครั้ง ยืนยันสองครั้ง เป็นต้น
ปัญหาเหล่านี้ ไม่ใช่เพราะผลิตภัณฑ์กระเป๋าเงิน "ไม่ดีพอ" แต่เป็นผลจากการออกแบบโมเดลบัญชีของ Ethereum เอง
จากมุมมองนี้ การวิวัฒนาการในช่วงสองปีที่ผ่านมาค่อนข้างชัดเจนแล้ว ERC-4337 ได้ทำให้ Account Abstraction ทำงานในเลเยอร์แอปพลิเคชันไปก่อน โดยไม่ต้องแก้ไขพรอโตคอล EIP-7702 ได้พิสูจน์เพิ่มเติมว่า EOA ไม่ได้ขยายไม่ได้โดยสิ้นเชิง อย่างน้อยก็สามารถได้รับความสามารถบางส่วนที่ใกล้เคียงกับ Smart Account ชั่วคราวได้
กล่าวคือ Ethereum ไม่ได้ไม่อยากทำ Account Abstraction แต่กำลังใช้วิธีที่อ่อนโยนและระมัดระวังมากขึ้น ค่อยๆ เข้าใกล้สิ่งนี้ และการปรากฏตัวของ EIP-8141 หมายความว่าเส้นทางนี้มาถึงจุดใหม่แล้ว มันไม่พอใจกับการเพิ่มความสามารถของ Smart Account อีกชั้นนอกระบบที่มีอยู่แล้ว แต่ พยายามฝัง Account Abstraction เข้าไปในโมเดลธุรกรรมเองโดยตรง ทำให้บัญชีมีตรรกะการตรวจสอบและการดำเนินการที่โปรแกรมได้ตั้งแต่ระดับพรอโตคอล
นี่คือเหตุผลที่ EIP-8141 กลับมาได้รับความสนใจอีกครั้งในวันนี้ ด้านหนึ่ง ประสบการณ์กระเป๋าเงินในเลเยอร์บนใกล้เคียงกับ Native Account Abstraction มากขึ้นเรื่อยๆ ระดับพรอโตคอลจำเป็นต้องตามให้ทันในไม่ช้า อีกด้านหนึ่ง แรงกดดันระยะยาวจากควอนตัมคอมพิวติ้ง กำลังเปลี่ยน "บัญชีสามารถเปลี่ยนวิธีการเซ็นได้อย่างยืดหยุ่นหรือไม่" จากประเด็นทางเทคนิคที่ห่างไกล ให้กลายเป็นปัญหาความเป็นจริงที่ต้องพิจารณาอย่างจริงจังก่อนเวลาอันควร
2. EIP-8141 ทำงานอย่างไร?
ในที่สุด EIP-8141 ได้แนะนำประเภทธุรกรรมใหม่ทั้งหมด นั่นคือ Frame Transaction (ธุรกรรมเฟรม) โดยมีหมายเลขประเภทธุรกรรมเป็น 0x06
หากตรรกะพื้นฐานของธุรกรรม Ethereum แบบดั้งเดิมคือหนึ่งธุรกรรมต่อหนึ่งการเรียก (call) สิ่งที่ EIP-8141 ต้องการทำคือ การแยกธุรกรรมหนึ่งรายการออกเป็นชุดของ "เฟรม" ที่สามารถดำเนินการตามลำดับกฎที่กำหนดได้ จึงแยกการตรวจสอบ การชำระเงิน และการดำเนินการ สามสิ่งซึ่งเดิมผูกมัดกันไว้ ให้จัดการแยกกัน
แต่ละ "เฟรม" มีโหมดการดำเนินการสามแบบ:
- VERIFY (เฟรมตรวจสอบ): รับผิดชอบตรวจสอบความถูกต้องของธุรกรรม จะรันตรรกะการตรวจสอบที่กำหนดเองของบัญชี หากผ่าน จะเรียกใช้ opcode ใหม่ที่ชื่อ APPROVE เพื่ออนุญาตการดำเนินการและกำหนดขีดจำกัดค่าแก๊ส
- SENDER (เฟรมผู้ส่ง): ดำเนินการจริง เช่น โอนเงิน เรียกสัญญา เป็นต้น ที่อยู่ผู้เรียกคือผู้ส่งธุรกรรมเอง
- DEFAULT (เฟรมทางเข้า): ใช้ที่อยู่ทางเข้าของระบบเป็นผู้เรียก สำหรับสถานการณ์เช่นการปรับใช้สัญญา การตรวจสอบ Paymaster เป็นต้น
ความหมายของกลไกนี้ ไม่ใช่ทำให้ธุรกรรมซับซ้อนขึ้นได้ แต่เป็นการแยก "การตรวจสอบ การชำระเงิน การดำเนินการ" สามสิ่งนี้ออกจากการกระทำของบัญชีเป็นครั้งแรก และให้พรอโตคอลจัดตารางงานแบบดั้งเดิม
เพราะในอดีต ใครเป็นผู้ตรวจสอบธุรกรรม ใครเป็นผู้จ่ายค่าแก๊ส ใครเป็นผู้ดำเนินการจริง ส่วนใหญ่ถูกผูกไว้กับการกระทำของบัญชีเดียวกันหมด ภายใต้การออกแบบของ EIP-8141 สิ่งเหล่านี้สามารถถูกแยกออกเป็นเฟรมต่างๆ ได้ โดยให้พรอโตคอลดำเนินการตามลำดับที่ชัดเจน และด้วยเหตุนี้เอง บัญชีจึงไม่ต้องพึ่งพาคีย์ส่วนตัวเดียวเพื่อ "เซ็นทั้งหมด" อีกต่อไป แต่เริ่มมีรูปแบบที่ใกล้เคียงกับหน่วยดำเนินการที่โปรแกรมได้มากขึ้น
ยกตัวอย่างที่เจาะจง สมมติว่าคุณต้องการใช้ USDC จ่ายค่าแก๊สเพื่อทำการ Swap ภายใต้กรอบของ EIP-8141 ในทางทฤษฎีสิ่งนี้สามารถถูกจัดระเบียบเป็นโฟลว์เฟรมที่สมบูรณ์: เริ่มจากบัญชีตรวจสอบลายเซ็นและสิทธิ์ในการดำเนินการ จากนั้นผู้ชำระเงินหรือ Paymaster ตรวจสอบเงื่อนไขที่ตัวเองยินดีรับผิดชอบค่าใช้จ่าย ตามด้วยการชำระค่าใช้จ่ายสำหรับสินทรัพย์ที่เกี่ยวข้อง และสุดท้ายจึงดำเนินการ swap จริง
ด้วยวิธีนี้ การชำระค่าแก๊สและธุรกรรมหลักสามารถถูกรวมเข้าไว้ในโฟลว์อะตอมมิกเดียวกันได้ จะสำเร็จทั้งหมดหรือย้อนกลับทั้งหมด
สำหรับผู้ใช้ การเปลี่ยนแปลงที่เห็นได้ชัดเจนที่สุดคือ การดำเนินการมากมายที่ก่อนหน้านี้ต้องแยกเป็นสองสามขั้นตอน และมีความเสี่ยงล้มเหลวในระหว่างขั้นตอนนั้น ในอนาคตสามารถเป็นเหมือนการดำเนินการที่สมบูรณ์ครั้งเดียวมากขึ้นได้ ดังนั้นความเป็นอะตอมมิกนี้จึงเป็นหนึ่งในกุญแจสำคัญที่ EIP-8141 ต้องการใช้แก้ปัญหาการแตกแยกของประสบการณ์ผู้ใช้
แล้วสิ่งนี้หมายความว่าอย่างไรสำหรับผู้ใช้กระเป๋าเงิน? จากผลลัพธ์ การเปลี่ยนแปลงที่เห็นได้ชัดเจนอย่างน้อยมีสี่ระดับ:
- การชำระค่าแก๊สถูกทำให้เป็นนามธรรม: การมีสเตเบิลคอยน์ในกระเป๋าเงิน ไม่ได้หมายความว่าคุณต้องเตรียม ETH เพิ่มเติมอีกเล็กน้อยเพื่อดำเนินการอีกต่อไป ในอนาคตการให้ DApp, Paymaster หรือผู้สนับสนุนอื่นๆ จ่ายค่าแก๊สแทน จะกลายเป็นเรื่องดั้งเดิมมากขึ้น
- การดำเนินการหลายขั้นตอนถูกรวมเข้าด้วยกัน: กระบวนการที่มักต้องเซ็นหลายครั้งในปัจจุบัน เช่น "อนุมัติ + Swap" หรือ "อนุมัติ + การ Stake" มีโอกาสที่จะถูกบรรจุเป็นการดำเนินการที่สมบูรณ์มากขึ้น
- กฎความปลอดภัยของบัญชีถูกเปิดออก: การเซ็นแบบหลายคน การกู้คืนผ่านโซเชียล ขีดจำกัดรายวัน Time Lock การหมุนเวียนคีย์ สิ่งเหล่านี้ไม่ใช่แค่ฟีเจอร์ขั้นสูงที่ผลิตภัณฑ์กระเป๋าเงินบางตัวจัดให้เพิ่มเติมอีกต่อไป แต่เริ่มมีโอกาสที่จะสร้างขึ้นบนตรรกะบัญชีที่ดั้งเดิมมากขึ้น
- แผนการลายเซ็นไม่จำเป็นต้องถูกผูกมัดด้วยเส้นทางเดียวของ ECDSA อีกต่อไป: สิ่งนี้ทำให้บัญชีมีโอกาสในการย้ายไปยังระบบรหัสผ่านที่แตกต่างกันในอนาคต รวมถึงแผนการลายเซ็นหลังยุคควอนตัม เป็นครั้งแรกที่มีความเป็นไปได้ในความหมายระดับพรอโตคอล
3. ทำไมไม่กลายเป็นฟีเจอร์หลักของ Hegotá?
จุดสำคัญที่มักถูกมองข้าม แต่มีความสำคัญมากสำหรับผู้ใช้กระเป๋าเงินคือ: แม้ว่า EIP-8141 จะถูกนำมาใช้ในที่สุด ระบบบัญชีที่มีอยู่ก็จะไม่ถูกยกเลิกโดยรวม
แม้ว่าคุณกำลังใช้กระเป๋าเงิน Web3 ที่มีอยู่เช่น imToken ก็ไม่จำเป็นต้องย้ายข้อมูล เพราะมันเข้ากันได้กับเวอร์ชันก่อนหน้า ที่อยู่ EOA ที่มีอยู่สามารถใช้งานต่อไปได้ เพียงแค่เลือก "อัปเกรด" ตรรกะการตรวจสอบของบัญชีในเวลาที่เหมาะสม
แต่ในทางกลับกัน เพราะมันเปลี่ยนแปลงลึกพอ มันจึงไม่กลายเป็นฟีเจอร์หลักของ Hegotá ในการอภิปรายรอบล่าสุดโดยตรง อย่างไรก็ตาม ตามกระบวนการ EIP champion ปี 2026 ความหมายของ CFI (Considered for Inclusion) ไม่ใช่การถูกปฏิเสธ แต่เป็นการเข้าสู่ขั้นตอนการพิจารณาอย่างจริงจัง แต่ยังไม่ถึงเวลาตัดสินใจขั้นสุดท้ายสำหรับการเปิดตัว
กล่าวอีกนัยหนึ่ง นักพัฒนาหลักไม่ได้ไม่เห็นด้วยกับทิศทางของ EIP-8141 แต่ในขณะที่ยอมรับคุณค่าของมัน ก็ยังมองว่ามันยัง "หนัก" เกินไปในปัจจุบัน
เพราะ Native Account Abstraction ไม่เหมือนกับ ERC-4337 ที่สามารถถูกผลักดันโดยกระเป๋าเงิน โครงสร้างพื้นฐาน และแอปพลิเคชันบางส่วนก่อนได้ ทันทีที่มันเข้าสู่ระดับพรอโตคอล หมายความว่าไคลเอนต์เลเยอร์ดำเนินการทั้งหมดต้องนำไปใช้ ทดสอบ และประสานงานกันอย่างจริงจัง สิ่งนี้จะเพิ่มเกณฑ์การก้าวหน้าตามธรรมชาติ และทำให้นักพัฒนาหลักมีแนวโน้มที่จะระมัดระวังมากขึ้นเมื่อวางแผน fork
แล้วต่อไปจะเกิดอะไรขึ้น? สามารถแยกออกเป็นสองเส้นทาง:
- เนื่องจาก EIP-8141 อยู่ในสถานะ CFI แสดงว่ามันยังคงถูกประเมินอย่างต่อเนื่อง ผู้เขียนข้อเสนอจะเติมเต็มรายละเอียดสำคัญเกี่ยวกับความปลอดภัยของพูลธุรกรรม กฎการตรวจสอบ และการนำไปใช้ในไคลเอนต์ต่อไป การประชุม ACD ในภายหลังจะทบทวนอีกครั้งว่ามันมีเงื่อนไขที่จะก้าวหน้าต่อไปหรือไม่
- หากความไม่แน่นอนเหล่านี้สามารถถูกลดลงอย่างต่อเนื่อง มันก็มีโอกาสเข้าสู่ขั้นตอนการรวมที่แท้จริงมากขึ้นในการอัปเกรดครั้งต่อๆ ไป หากไม่สามารถ มันก็อาจถูกเลื่อนไปยังรอบการอัปเกรดที่ล่าช้ากว่าได้อย่างสมบูรณ์
พูดตามความเป็นจริง EIP-8141 ไม่ใช่ข้อเสนอ Native Account Abstraction ข้อเดียว และตัวมันเองก็ไม่ใช่แผนการลายเซ็นหลังยุคควอนตัมสำเร็จรูป ไม่สามารถแก้ไขปัญหาควอนตัมคอมพิวติ้งได้โดยตรง แต่ความสำคัญของมันอยู่ที่ว่า มันเป็นครั้งแรกที่ให้ทางออกในความหมายระดับพรอโตคอล สำหรับบัญชีที่จะหลุดพ้นจากเส้นทางเดียวของ ECDSA
จากมุมมองนี้ คุณค่าที่แท้จริงของ EIP-8141 ไม่ได้อยู่ที่ว่ามันเป็นคำตอบที่ถูกต้องเพียงข้อเดียวหรือไม่ แต่อยู่ที่ว่ามันนำคำถามที่ว่า "จุดจบของ Native Account Abstraction ควรมีหน้าตาเป็นอย่างไรกันแน่" มาวางบนโต๊ะอภิปรายพรอโตคอล Ethereum อย่างครบถ้วนเป็นครั้งแรก
มันไม่ใช่แผนเดียว แต่มันเป็นหนึ่งในแผนที่ทะเยอทะยานที่สุดและใกล้เคียงกับขีดจำกัดจินตนาการของ "Native AA ที่สมบูรณ์"
