EIP-8141: เหตุใดการใช้งานการแยกบัญชีแบบเนทีฟจึงไม่ใช่คุณลักษณะหลักในการอัปเกรด Hegota ของ Ethereum

เขียนโดย: imToken

เมื่อสัปดาห์ที่แล้ว ในการประชุมนักพัฒนาแกนหลักของ Ethereum ได้มีการหารืออย่างเป็นทางการเกี่ยวกับการรวม EIP-8141 เข้าไปในอัปเกรด Hegota ผลลัพธ์กลับไม่คาดคิด โดยข้อเสนอที่ Vitalik ให้การสนับสนุนโดยตรง กลับไม่ถูกจัดให้เป็น “ฟีเจอร์หลัก” ของ Hegota แต่ได้รับสถานะ “พิจารณาเพิ่มเติม” (CFI)

ในสัปดาห์นี้ ทีม Google Quantum AI ได้เผยแพร่เอกสารขาวฉบับใหม่ โดยระบุว่าภายใต้สมมติฐานฮาร์ดแวร์ที่กำหนด จำนวนควอนตัมบิตทางกายภาพที่จำเป็นในการถอดรหัส ECDLP-256 ลดลงถึง 20 เท่าเมื่อเทียบกับก่อนหน้านี้ แม้จะไม่ได้หมายความว่าการโจมตีด้วยควอนตัมจะเกิดขึ้นในเร็วๆ นี้ แต่ก็เป็นการเตือนอย่างชัดเจนว่า หากระบบบัญชีในอนาคตไม่สามารถเปลี่ยนตรรกะการตรวจสอบได้อย่างยืดหยุ่น การอภิปรายต่างๆ เกี่ยวกับประสบการณ์กระเป๋าเงินในวันนี้ สุดท้ายอาจเปลี่ยนเป็นปัญหาด้านความปลอดภัย

แม้ในแง่ของความเป็นจริงในการขับเคลื่อนโปรโตคอล EIP-8141 ยังคงมีน้ำหนักมากเกินไปในขณะนี้ โดยเฉพาะอย่างยิ่งในด้านการนำไปใช้งานในไคลเอนต์ ความปลอดภัยของ transaction pool และความซับซ้อนในการตรวจสอบ ยังไม่ได้รับความเห็นพ้องต้องกันที่มั่นคงเพียงพอ

แต่ในจุดเวลาปัจจุบันนี้ ดูเหมือนว่า EIP-8141 จะมีประเด็นที่ควรพิจารณาและทบทวนอย่างจริงจังมากขึ้นเรื่อยๆ

EIP-8141 ได้รับการขับเคลื่อนโดย Vitalik Buterin และผู้มีส่วนร่วมหลักอื่นๆ เช่น timbeiko โดยมีชื่ออย่างเป็นทางการว่า Frame Transactions

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

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

หากพิจารณาเพียงผิวเผิน EIP-8141 ได้หารือถึงชุดความสามารถที่ดูเฉพาะเจาะจงมาก: การชำระค่า Gas ด้วยสกุลเงินที่มีมูลค่าคงที่ การรวมการดำเนินการหลายขั้นตอนเป็นธุรกรรมเดียว การสนับสนุนวิธีการลงนามที่ยืดหยุ่นมากขึ้น และแม้แต่การจัดเตริงพื้นที่สำหรับการลงนามต้านทานควอนตัมในอนาคต สามารถกล่าวได้ว่า การปรับปรุงหลายอย่างเกี่ยวกับประสบการณ์กระเป๋าเงินตั้งแต่ ERC-4337 ถึง EIP-7702 ในช่วงหลายปีที่ผ่านมา ล้วนมีเป้าหมายพื้นฐานคือการทำให้บัญชีไม่ใช่แค่กุญแจส่วนตัวเพียงอย่างเดียว แต่เป็นจุดเข้าใช้งานที่สามารถกำหนดกฎเองได้

ปัญหาคือ การปรับปรุงเหล่านี้ทำให้กระเป๋าเงินดูเหมือนบัญชีอัจฉริยะมากขึ้น แต่ยังไม่ได้แตะต้องโมเดลบัญชีเริ่มต้นของ Ethereum ที่ลึกที่สุด

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

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

หากคุณเคยใช้ imToken หรือกระเป๋าเงิน Web3 อื่นๆ คุณน่าจะเคยเจอปัญหาเหล่านี้ เช่น คุณมี USDC จำนวนมากในกระเป๋าเงิน แต่ไม่มี ETH จึงไม่สามารถส่งธุรกรรมได้ (เพราะค่า Gas ต้องจ่ายด้วย ETH); ถ้าสูญหายรหัสฟื้นฟู คุณจะสูญเสียเงินอย่างถาวรและไม่สามารถกู้คืนได้; การดำเนินการหนึ่งครั้ง เช่น “การอนุญาต + การแลกเปลี่ยน” ต้องลงนามและยืนยันสองครั้ง เป็นต้น

คำถามเหล่านี้ไม่ได้เกิดจากผลิตภัณฑ์กระเป๋าสตางค์ที่ “ไม่ดีพอ” แต่เป็นผลลัพธ์ของการออกแบบโมเดลบัญชีของ Ethereum โดยตรง

ในมุมมองนี้ การพัฒนาในสองปีที่ผ่านมาชัดเจนมากขึ้น: ERC-4337 ได้เริ่มดำเนินการเรื่องการนามธรรมของบัญชีบนชั้นแอปพลิเคชันโดยไม่ต้องแก้ไขโปรโตคอล; ส่วน EIP-7702 ยังพิสูจน์เพิ่มเติมว่า EOA ไม่ได้ไม่สามารถขยายได้เลย อย่างน้อยก็สามารถรับความสามารถบางส่วนที่ใกล้เคียงกับบัญชีอัจฉริยะได้ชั่วคราว

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

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

ในที่สุดแล้ว EIP-8141 ได้แนะนำประเภทธุรกรรมใหม่—Frame Transaction โดยมีรหัสประเภทธุรกรรมเป็น 0x06

หากตรรกะพื้นฐานของธุรกรรม Ethereum แบบดั้งเดิมคือธุรกรรมหนึ่งครั้งสอดคล้องกับการเรียกใช้งานหนึ่งครั้ง EIP-8141 มุ่งหมายที่จะแยกธุรกรรมหนึ่งครั้งออกเป็นชุดของ “เฟรม” ที่สามารถดำเนินการตามลำดับที่กำหนดไว้ เพื่อแยกกระบวนการตรวจสอบ การชำระเงิน และการดำเนินการ ซึ่งเดิมถูกผูกติดกันไว้

แต่ละ「เฟรม」มีสามโหมดการดำเนินการ:

• VERIFY (การตรวจสอบเฟรม): รับผิดชอบในการตรวจสอบว่าธุรกรรมถูกต้องตามกฎหมาย โดยจะรันตรรกะการตรวจสอบที่ผู้ใช้กำหนดเอง หากผ่านการตรวจสอบ จะเรียกใช้โอเปอเรเตอร์ APPROVE ที่เพิ่งแนะนำเพื่ออนุญาตให้ดำเนินการและระบุขีดจำกัดแก๊ส
• SENDER (ส่งเฟรม): ดำเนินการจริง เช่น การโอนเงิน การเรียกใช้สัญญา ฯลฯ ที่อยู่ของผู้เรียกใช้คือผู้ส่งธุรกรรมเอง
• DEFAULT (เฟรมการเข้าสู่ระบบ): ใช้ที่อยู่การเข้าสู่ระบบของระบบเป็นผู้เรียกใช้งาน สำหรับสถานการณ์ต่างๆ เช่น การปรับใช้สัญญา การตรวจสอบ Paymaster ฯลฯ;

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

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

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

ดังนั้น การจ่าย Gas และธุรกรรมหลักจะถูกรวมเข้าเป็นกระบวนการอะตอมเดียวกัน ทั้งหมดจะสำเร็จ หรือทั้งหมดจะถูกยกเลิก

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

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

• การชำระค่าแก๊สถูกนามธรรม화: การมีสกุลเงินคงที่ในกระเป๋าเงินไม่ได้หมายความว่าคุณต้องเตรียม ETH เพิ่มเติมเพื่อใช้งาน อีกต่อไป ในอนาคต การชำระค่าแก๊สโดย DApp, Paymaster หรือผู้สนับสนุนรายอื่นจะกลายเป็นเรื่องธรรมชาติยิ่งขึ้น
• กระบวนการหลายขั้นตอนถูกรวมเข้าด้วยกัน: กระบวนการที่มักต้องใช้การลงนามหลายครั้ง เช่น “การอนุญาต + Swap” หรือ “การอนุญาต + การฝากหลักประกัน” ตอนนี้มีโอกาสถูกแพ็กเกจเป็นการดำเนินการที่สมบูรณ์ยิ่งขึ้น
• กฎความปลอดภัยของบัญชีถูกเปิดใช้งาน: การลงนามหลายฝ่าย, การกู้คืนทางสังคม, ขีดจำกัดรายวัน, การล็อกเวลา, และการเปลี่ยนกุญแจ ไม่ใช่เพียงฟีเจอร์ขั้นสูงที่ให้มาเพิ่มเติมในผลิตภัณฑ์กระเป๋าสตางค์ใดกระเป๋าสตางค์หนึ่งอีกต่อไป แต่เริ่มมีโอกาสถูกสร้างขึ้นบนตรรกะบัญชีที่เป็นเนื้อเดิมมากขึ้น;
• ระบบลายเซ็นไม่จำเป็นต้องถูกผูกไว้กับ ECDSA เท่านั้น: ทำให้บัญชีมีความเป็นไปได้ในระดับโปรโตคอลครั้งแรกในการย้ายไปใช้ระบบการเข้ารหัสอื่นๆ รวมถึงแผนการลายเซ็นหลังควอนตัม

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

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

แต่ในทางกลับกัน นั่นก็เพราะการเปลี่ยนแปลงนั้นลึกพอ จึงไม่ได้กลายเป็นฟีเจอร์หลักของ Hegotá ในรอบการอภิปรายล่าสุด อย่างไรก็ตาม ตามกระบวนการ EIP champion ปี 2026 ความหมายของ CFI (Considered for Inclusion) ไม่ได้หมายถึงการปฏิเสธ แต่หมายถึงการเข้าสู่ขั้นตอนการพิจารณาอย่างจริงจัง ยังไม่ถึงขั้นตัดสินใจอย่างเป็นทางการเพื่อนำไปใช้งาน

พูดอีกแบบคือ นักพัฒนาหลักไม่ได้ปฏิเสธทิศทางของ EIP-8141 แต่ยอมรับคุณค่าของมันในขณะเดียวกันก็มองว่ามันยังคงหนักเกินไปในขณะนี้

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

แล้วจะเกิดอะไรขึ้นต่อไป? สามารถแยกออกเป็นสองเส้นทางได้:

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

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

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

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

ไม่ว่า EIP-8141 จะสามารถทัน Hegotá หรือไม่ การอภิปรายครั้งนี้เองก็ได้แสดงให้เห็นอย่างน้อยหนึ่งสิ่งแล้ว:

อีเธอเรียมไม่ได้นั่งรอให้ปัญหาลุกลาม แต่กำลังสร้างพื้นฐานสำหรับระบบบัญชีรุ่นถัดไปอย่างค่อยเป็นค่อยไป