以太坊早期的账户模型将用户行为与密钥控制紧密耦合,限制了钱包的灵活性与可扩展性。账户抽象(Account Abstraction, AA)试图打破这一耦合,让合约账户像外部账户一样发起交易、管理资产、实现自定义逻辑
📚 作者:Henry 🧱 系列:《以太坊工作原理全解析》 · 第 11 篇 👨💻 受众:Web3 开发者 / 区块链学习者 👉 系列持续更新中,建议收藏专栏或关注作者
本章将深入解析 AA 背后的动机、核心 EIP(特别是 EIP-4337)、核心组件(EntryPoint、UserOperation 等)与运行流程,并展示其对未来 Web3 用户体验、支付模型与安全性的深远影响。
账户抽象:让合约账户也能像外部账户(EOA)一样自主发起交易,并定义自定义验证逻辑。
传统以太坊账户模型:
类型 | 特点 | 限制 |
---|---|---|
EOA(外部账户) | 私钥控制,直接发交易 | 不能自定义签名方式;易丢失私钥 |
CA(合约账户) | 只能被动接收调用 | 无法主动发交易;签名依赖外部账户 |
账户抽象的目标是融合两者优点:
✅ 安全性 + ✅ 灵活性 + ✅ 主动性
账户抽象通过合约账户发起交易与验证器模块,使这些能力成为可能。
路线 | 状态 | 特点 |
---|---|---|
EIP-86 | 早期尝试 | 提议修改协议层,未采纳 |
EIP-2938 | 协议层 AA | 新交易类型 + opcode 扩展,复杂度高 |
✅ EIP-4337 | 应用层 AA | 无需更改协议,已主网上线(2023) |
用户
→ 钱包(Smart Account)
→ 生成 UserOperation
→ Bundler
→ EntryPoint 合约
→ 钱包验证执行
→ 目标合约
元素 | 中文说明 |
---|---|
👤 User / 钱包前端 | 发起交易请求,通常由合约钱包生成 UserOperation 并签名 |
🧾 **UserOper... |
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!