เหตุใด EOA จึงล้าสมัย: Smart Account ทำอะไรได้จริง

ณ เดือนเมษายน 2026 ข้อมูลจาก BundleBear แสดงว่ามี UserOperations ของ ERC-4337 มากกว่า 1.07 billion รายการ และมี smart account 56.7 ล้านบัญชีที่เคยทำธุรกรรมอย่างน้อยหนึ่งครั้งบน Ethereum และเครือข่าย L2 หลัก ๆ นี่ไม่ใช่เรื่องเฉพาะกลุ่มอีกต่อไป บัญชี Externally Owned Account ที่ใช้คีย์เดียวและรองรับเฉพาะ secp256k1 ซึ่ง Ethereum เปิดตัวพร้อมกันในปี 2015 กำลังถูกหลีกเลี่ยงในวงกว้าง และตัวเลขบนเชนกำลังสะท้อนข้อเท็จจริงระดับโปรโตคอลที่ค่อย ๆ เป็นที่รับรู้กันว่า ตอนนี้บัญชีเองก็เขียนโปรแกรมกำหนดการทำงานได้แล้ว

นี่คือบทความตอนที่ 1 ในซีรีส์ 5 ตอนเกี่ยวกับ smart account โดยมีเป้าหมายที่จำกัดแต่เป็นพื้นฐานสำคัญ คืออธิบายว่า EOA คืออะไร smart account คืออะไร และเหตุใด “smart account เทียบกับ EOA” จึงไม่ใช่แค่ความชอบด้าน UX อีกต่อไป แต่เป็นการเลือกโครงสร้างที่กำหนดวิธีบังคับใช้การเก็บรักษาด้วยตนเองของคุณ

EOA คืออะไรในระดับโปรโตคอล

Yellow Paper ของ Ethereum กำหนดบัญชีไว้ 2 ประเภท ได้แก่ Externally Owned Account และ Contract Account ความแตกต่างเพียงอย่างเดียวระหว่างทั้งสองในระดับสถานะคือฟิลด์ codeHash สำหรับ EOA ค่า codeHash คือแฮชของสตริงว่าง ส่วน Contract Account จะชี้ไปยัง EVM bytecode ที่เรียกใช้ได้ นี่คือความแตกต่างทั้งหมดในชั้นโปรโตคอล

ดังนั้น EOA จึงไม่ใช่ “กระเป๋าเงิน” ในความหมายที่แท้จริง แต่เป็นที่อยู่ซึ่งได้มาจาก 20 ไบต์สุดท้ายของ keccak256(public key) โดยคู่คีย์กำหนดตายตัวให้ใช้เส้นโค้ง secp256k1 MetaMask, Ledger และ Zelcore เป็นอินเทอร์เฟซผู้ใช้ที่เก็บคีย์ไว้ ไม่ใช่ตัวบัญชี หากคุณยังไม่เคยเห็นกลไกเบื้องหลัง บทความพื้นฐานของเราเรื่องคีย์สาธารณะและคีย์ส่วนตัว รวมถึงวิธีสร้างที่อยู่ อธิบายไว้ตั้งแต่ต้นจนจบ

ก่อนที่ ERC-4337 จะเปิดใช้งานในปี 2023 ทุกธุรกรรมบน Ethereum ต้องเริ่มต้นจาก EOA และโปรโตคอลบังคับใช้กฎการตรวจสอบเพียงข้อเดียว คือ ต้องมีลายเซ็น secp256k1 ที่ถูกต้องบนแฮชของธุรกรรม ถือยอดคงเหลือ เซ็นลายเซ็น ECDSA หนึ่งรายการต่อธุรกรรม และจ่ายค่าก๊าซเป็น ETH จากบัญชีเดียวกัน นี่คือขีดความสามารถทั้งหมดของ EOA ไม่มีสิ่งอื่นที่ทำได้

ข้อจำกัดเชิงโครงสร้างที่ส่งผลต่อผู้ใช้

สิ่งเหล่านี้ไม่ใช่แค่จุดติดขัดเล็ก ๆ ใน UX แต่เป็นเหตุผลเชิงโครงสร้างที่อยู่เบื้องหลังความสูญเสียจากการเก็บรักษาด้วยตนเองส่วนใหญ่ที่เรายังคงพบในปี 2026

• มีจุดล้มเหลวเพียงจุดเดียว คีย์ส่วนตัวหนึ่งคีย์ควบคุมทุกอย่าง หากทำหาย บัญชีก็สูญหาย หากคีย์รั่ว เงินก็สูญหายอย่างถาวร โปรโตคอลไม่มีวิธีกู้คืนในตัว ซึ่งเป็นเหตุผลที่วลีกู้คืนเพียงชุดเดียวเป็นจุดล้มเหลวหลักของการเก็บรักษาด้วยตนเอง
• ใช้เส้นโค้งได้เพียงแบบเดียว กำหนด secp256k1 ไว้ตายตัว คุณจึงใช้ passkey (P-256), คีย์ Ed25519, BLS หรือรูปแบบที่ทนต่อควอนตัมไม่ได้
• ไม่มี multisig ในตัว “multisig” ทุกแบบบน Ethereum ตั้งแต่ Gnosis Multisig รุ่นแรกไปจนถึง Safe ล้วนเป็นสัญญาที่ EOA เรียกใช้ ตัว EOA เองไม่สามารถกำหนดให้ต้องมีลายเซ็นสองรายการได้
• ทำธุรกรรมเป็นชุดไม่ได้ EOA ทำได้หนึ่งอย่างต่อธุรกรรม การอนุมัติโทเคนแล้วแลกเปลี่ยนโทเคนนั้นต้องใช้ธุรกรรมที่เซ็นแล้วสองรายการ การยืนยันสองครั้ง และการจ่ายค่าก๊าซสองครั้ง
• กำหนดนโยบายการใช้จ่ายไม่ได้ โปรโตคอลไม่มีแนวคิดอย่าง “คีย์นี้ใช้จ่ายได้ไม่เกิน $500 ต่อวัน” หรือ “คีย์นี้เรียกใช้ได้เฉพาะ Uniswap”
• บัญชีที่ทำรายการต้องจ่ายค่าก๊าซเป็น ETH เอง ไม่มีระบบสนับสนุนค่าก๊าซหรือจ่ายด้วย USDC ในตัว

นี่คือกรอบที่ผู้ใช้ Ethereum ทุกคนถูกจำกัดให้อยู่ภายในมาตลอดทศวรรษ

smart account คืออะไร

ในความหมายตรงตามโปรโตคอล smart account คือ Contract Account ซึ่งเป็นที่อยู่ที่ฟิลด์ codeHash ชี้ไปยัง bytecode โดย bytecode จะกำหนดกฎไว้ในโค้ดว่าบัญชีจะยอมรับการดำเนินการแบบใด

EOA มีกฎตรวจสอบแบบเดียวที่กำหนดตายตัว คือการตรวจสอบ secp256k1 ส่วนกฎตรวจสอบของ smart account จะเป็นไปตามที่สัญญากำหนด อาจเป็น multisig แบบ 2 ใน 3, ลายเซ็น passkey ที่ตรวจสอบบนเส้นโค้ง secp256r1, คีย์ที่รับรองด้วยฮาร์ดแวร์, การล็อกตามเวลา, ขีดจำกัดรายวัน, ปลายทางการเรียกใช้ที่อนุญาตไว้ หรือการผสมผสานสิ่งเหล่านี้ บัญชี smart contract ตรวจสอบลายเซ็นผ่านมาตรฐาน EIP-1271 แทนการตรวจสอบ secp256k1 แบบตายตัวในระดับโปรโตคอล จึงทำให้ใช้รูปแบบลายเซ็นทางเลือกได้

เนื่องจากกฎเหล่านี้อยู่ในรูปโค้ด จึงอัปเกรด ประกอบเข้าด้วยกัน และเพิกถอนได้ smart account มีอยู่บน Ethereum มาตั้งแต่ปี 2018 (Safe เป็นตัวอย่างมาตรฐาน) สิ่งที่ยังขาดคือวิธีทำให้บัญชีเหล่านี้เป็นค่าเริ่มต้น และส่งธุรกรรมได้โดยไม่ต้องให้ EOA จ่ายค่าก๊าซก่อน ERC-4337 และ EIP-7702 เข้ามาปิดช่องว่างนี้

เส้นทางที่นำมาสู่ปัจจุบัน: ประวัติโดยย่อของ account abstraction

แนวคิดที่จะรวม EOA กับสัญญาเข้าด้วยกันมีมาตั้งแต่ยุคเริ่มต้นของ Ethereum แล้ว EIP-86 ของ Vitalik ซึ่งร่างขึ้นในปี 2016 เป็นข้อเสนอฉบับแรกที่ลงรายละเอียด เส้นทางจากจุดนั้นมาสู่มาตรฐานที่ใช้งานอยู่ในปัจจุบันผ่านความพยายาม 5 ครั้ง

• EIP-2938 (กันยายน 2020) เสนอ account abstraction ในระดับโปรโตคอล แต่ถูกยกเลิกเพราะต้องเปลี่ยนแปลงระบบมากเกินไป ขณะนั้น Ethereum กำลังอยู่ในช่วงเปลี่ยนผ่านสู่ proof-of-stake อย่างเต็มตัว
• EIP-3074 (ตุลาคม 2020) เพิ่ม opcode AUTH และ AUTHCALL ซึ่งเปิดทางให้ EOA มอบหมายการทำงานแก่สัญญา invoker แต่ถูกถอนออกเนื่องจากข้อกังวลด้านความปลอดภัยและมีข้อเสนอใหม่มาแทน
• ERC-4337 เริ่มใช้งานบน Ethereum mainnet เมื่อ 1 มีนาคม 2023 มาตรฐานนี้ทำงานเฉพาะในชั้นแอปพลิเคชันโดยไม่ต้อง hard fork และส่ง pseudo-transaction ที่เรียกว่า UserOperations ผ่าน mempool แยกต่างหาก, Bundler และสัญญา EntryPoint แบบ singleton
• EIP-7702 เปิดใช้งานพร้อมการอัปเกรด Pectra เมื่อ 7 พฤษภาคม 2025 โดยเพิ่มประเภทธุรกรรม 0x04 ซึ่ง EOA จะเซ็น authorization tuple (chain_id, address, nonce, y_parity, r, s) ที่ชี้บัญชีไปยังโค้ดสัญญาที่ได้รับมอบหมายผ่านตัวบ่งชี้ 0xef0100 || address ทำให้ EOA ทำงานเป็น smart account ได้ชั่วคราวโดยไม่ต้องย้ายเงิน
• ERC-6900 กำหนดมาตรฐานสถาปัตยกรรมปลั๊กอินแบบโมดูลาร์ ซึ่ง smart account ใช้ประกอบโมดูลตรวจสอบ โมดูลดำเนินการ และโมดูล hook เข้าด้วยกัน

ข้อสรุปคือ account abstraction ไม่ใช่การทดลองอีกต่อไป แต่เป็นมาตรฐานแบบหลายชั้นที่ใช้งานจริงแล้ว โดยมีเส้นทาง ERC-4337 ที่ตรงไปตรงมาสำหรับ smart account ใหม่ และเส้นทาง EIP-7702 ที่เปิดให้ EOA เดิมทุกบัญชีเลือกใช้งานได้

ความสามารถ 5 ประการที่ smart account เพิ่มเข้ามา

หาก EOA คือ “หนึ่งคีย์ หนึ่งลายเซ็น หนึ่งธุรกรรม” smart account ก็ครอบคลุมความสามารถทั้งหมดนั้นและเพิ่มเติมเข้าไป

• กำหนดวิธีตรวจสอบได้ ใช้รูปแบบลายเซ็นแบบใดก็ได้ (passkey, P-256, ฮาร์ดแวร์ HSM) กำหนดจำนวนผู้อนุมัติแบบใดก็ได้ (2 ใน 3, 3 ใน 5) และตั้งเงื่อนไขได้ตามต้องการ (ความสูงของบล็อก ราคาออราเคิล) บัญชีเป็นผู้กำหนดว่าอะไรถือว่า “ได้รับอนุญาต”
• รวมหลายรายการเป็นธุรกรรมเดียวที่ทำสำเร็จพร้อมกัน อนุมัติ แลกเปลี่ยน และฝากได้ในการดำเนินการเดียวที่เซ็นไว้ ทุกขั้นตอนจะสำเร็จทั้งหมดหรือไม่สำเร็จเลย วิธีนี้ช่วยขจัดหนี้จากการอนุมัติและรูปแบบ multisig ใน Zelcore ซึ่งเป็นวิธีแก้ปัญหาที่ผู้ใช้ต้องจัดการเอง
• จัดการค่าก๊าซผ่าน paymaster สัญญาของบุคคลที่สามจ่ายค่าก๊าซแทนผู้ใช้ หรือผู้ใช้จ่ายเป็น USDC, USDT หรือโทเคน ERC-20 ใด ๆ ที่ paymaster ยอมรับ หากต้องการทำความเข้าใจเพิ่มเติมว่าค่าก๊าซ การอนุมัติ และกลไก DeFi เชื่อมโยงกันอย่างไร ควรอ่านบทความพื้นฐานเกี่ยวกับ DeFi ก่อน
• คีย์สำหรับเซสชัน เป็นคีย์ลงนามที่กำหนดขอบเขต ระยะเวลา และแอปที่ใช้ได้โดยเฉพาะ เช่น “คีย์นี้ใช้จ่าย USDC บน Uniswap ได้ไม่เกิน 100 USDC ใน 24 ชั่วโมงข้างหน้า” หากคีย์เซสชันถูกเจาะ ความเสียหายจะถูกจำกัดด้วยนโยบาย ไม่ใช่ขนาดของบัญชี
• กู้คืนบัญชีได้ กู้คืนผ่านบุคคลอื่น ผ่านฮาร์ดแวร์ หรือผ่านการล็อกตามเวลาได้ บัญชีกู้คืนได้โดยไม่ต้องใช้คีย์ลงนามเดิม จึงยุติการพึ่งวลีกู้คืนในฐานะสิ่งที่หากสูญหายแล้วจะทำให้ทุกอย่างสูญสิ้นได้ในที่สุด

เหตุใดเรื่องนี้จึงเป็นหัวใจสำคัญของการเก็บรักษาด้วยตนเองในตอนนี้

การยอมรับใช้งานไม่ใช่ประเด็นที่ยังถกเถียงกันอีกต่อไป ในสัปดาห์แรกหลัง Pectra มีการอนุมัติผ่าน EIP-7702 มากกว่า 11,000 รายการ และหลังจากนั้นไม่นานจำนวนวอลเล็ตก็เพิ่มเกิน 25,000 ใบ โดยมี OKX และ MetaMask เป็นผู้นำ ตัวเลขสะสมของ BundleBear (UserOps 1.07B รายการ, smart account 56.7M บัญชี) แสดงให้เห็นภาพที่เหลือ

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

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

เนื้อหาถัดไปในซีรีส์นี้

ส่วนนี้เป็นการวางกรอบ ส่วนที่เหลือของซีรีส์จะลงรายละเอียดการใช้งานจริง

• ส่วนที่ 2 อธิบายองค์ประกอบของ ERC-4337 ได้แก่ UserOperations, Bundlers, EntryPoint, Paymasters และจุดที่แต่ละส่วนอาจทำงานผิดพลาด
• ส่วนที่ 3 เจาะลึกการมอบสิทธิ์ผ่าน EIP-7702 ทั้ง authorization tuple ตัวบ่งชี้ 0xef0100 และข้อควรคำนึงด้านความปลอดภัยเมื่อตั้งค่าให้ EOA ของคุณชี้ไปยังโค้ดของผู้อื่น
• ส่วนที่ 4 เปรียบเทียบการใช้งาน smart account หลัก ๆ (Coinbase Smart Wallet, Safe, Argent, Ambire) และค่าเริ่มต้นของแต่ละแบบ
• ส่วนที่ 5 เป็นบทสรุปด้านการใช้งานจริง ครอบคลุมวิธีกำหนดค่าการกู้คืน คีย์เซสชัน และนโยบายการใช้จ่ายในบัญชีจริง โดยไม่ละทิ้งการเก็บรักษาด้วยตนเอง

ประโยคเดียวที่ควรจำเมื่อต่อไปยังส่วนที่ 2 คือ EOA เป็นคีย์ที่มีที่อยู่ ส่วน smart account เป็นสัญญาที่กำหนดว่าคีย์ของบัญชีนั้นทำอะไรได้บ้าง