钱包为什么也能是一段程序？

00 · Why abstraction?

先看传统 EOA 把什么写死了

它非常简单可靠，但“简单”也意味着账户不能自己选择验证规则。

在经典 EOA 模型里，协议知道怎样恢复发送者、核对账户 nonce、检查余额并收取 ETH。对用户而言，这几乎等价于：一把长期私钥决定全部权限，每个动作是一笔独立交易，Gas 必须沿固定费用路径支付。

Diagram · fixed vs programmable

同样叫“账户”，验证层可以完全不同

FIG 01

CLASSIC EOA

协议固定验证

AUTHsecp256k1 交易签名
NONCE账户级顺序计数器
PAY发送者预留 ETH Gas
ACTION一笔交易携带一个顶层目标与 calldata

SMART ACCOUNT

代码自定义验证

AUTH单签、多签、passkey、会话钥匙或组合策略
NONCE可分通道管理操作顺序与重放保护
PAY账户预存、Paymaster 赞助或代币结算
ACTION可把多次调用组合成一个账户动作

右侧能力来自具体账户实现与配套基础设施，并非所有“智能账户”自动拥有全部功能。

ERC-4337 把账户抽象定义为：让每个账户提供自己的验证逻辑，而底层协议只保留尽可能少的固定约束。它不改共识层交易格式，而是在更高层引入 UserOperation、Bundler 与 EntryPoint。^[1]

“抽象”的对象，是协议对账户授权方式的固定假设。

先分开账户与钱包

账户是链上状态与控制规则；钱包是帮你查看、签署、发送请求的界面。合约钱包通常由链上智能账户 + 设备上的钱包应用 + Bundler / Paymaster 等服务共同完成体验。 App 关掉不等于链上账户消失，服务可替换也不代表任何实现都天然抗审查。

01 · Programmable authorization

账户不再只问“签名对不对”

它可以问：谁签的、在什么时间、要调用谁、花多少、是否超过策略边界。

一段签名只是证据。真正决定证据是否足够的，是智能账户的验证代码与当前 storage。同一份操作，换一套账户规则，答案可以不同。

01 / MULTISIG

多人共同批准

大额操作要求 2 / 3，日常小额只需一位；签名者和阈值由账户状态记录。

02 / SESSION KEY

临时最小权限

授权一把短期钥匙只能操作某个游戏、某种代币或每日上限，不暴露根密钥。

03 / RECOVERY

可编程恢复

守护人、延迟与旧设备撤销可以共同构成恢复流程；恢复不是协议免费赠送的功能。

04 / POLICY

把意图写成边界

目标白名单、金额上限、有效时段、签名方案与暂停规则都可参与验证。

Interactive · policy gate

同一把会话钥匙，三次请求为什么结果不同？

FIG 02

target == Game
amount ≤ 10 USDC
now < expiry
sessionSig == valid

目标、金额、时间与签名全部满足。

目标: 0xGame · 允许
金额: 8 USDC · 允许
有效期: 剩余 2 小时
结果: VALID · 可以执行

target == Game
amount ≤ 10 USDC
now < expiry
sessionSig == valid

签名是真的，但签名者没有这么大的权限。

目标: 0xGame · 允许
金额: 80 USDC · 超限
有效期: 剩余 2 小时
结果: REJECT · 权限不足

target == Game
amount ≤ 10 USDC
now < expiry
sessionSig == valid

金额很小也不够；授权没有覆盖这个目标。

目标: 0xUnknownDEX · 不允许
金额: 2 USDC · 允许
有效期: 剩余 2 小时
结果: REJECT · 目标越界

账户抽象的安全价值不只是“换一种签名”，而是让授权证据与具体动作边界绑定。

可编程也意味着可编错

多签、恢复、模块和升级入口扩大了能力，也扩大了攻击面。一把私钥的风险容易理解；一套复杂账户必须同时审计验证逻辑、初始化、模块安装、升级权限和钱包显示。

02 · UserOperation is not a transaction

用户先签“意图对象”，不是直接签底层交易

UserOperation 像交易，但它属于 ERC-4337 的高层协议。

UserOperation 描述“请让我的智能账户做这件事，并说明怎样验证与付费”。它进入专用操作池；之后 Bundler 把多个 UserOperation 装进一笔普通以太坊交易，调用 EntryPoint 的 handleOps。因此它本身没有独立的底层交易 sender 或交易 nonce。^[1]

Interactive · UserOperation anatomy

点一个字段组，看它回答什么

FIG 03

IDENTITY · SENDER

哪个智能账户要行动？

sender 是将被验证并执行的智能账户地址；它可以已经部署，也可以由 factory 在本次操作中创建。

规范在链上使用打包后的 PackedUserOperation；图中按概念分组，帮助理解，不代替具体版本的编码定义。

普通 EOA 交易与 ERC-4337 UserOperation 对照
比较	普通 EOA 交易	ERC-4337 UserOperation
谁直接提交到底层	EOA 自己签名并广播交易	Bundler 提交包含多个操作的 handleOps 交易
谁验证用户授权	以太坊协议固定交易签名规则	智能账户的 validateUserOp 代码
nonce 在哪里	发送 EOA 的协议账户 nonce	EntryPoint 管理的 UserOperation nonce；Bundler 交易另有自己的协议 nonce
签名格式	交易格式定义的 ECDSA 字段	signature 是交给账户解释的 bytes
Gas 来源	发送账户预留 ETH	账户在 EntryPoint 的 deposit，或 Paymaster deposit

两个 nonce，别混成一个

ERC-4337 的 UserOperation nonce 由 EntryPoint 按 key + sequence 管理，可为普通动作与管理动作开不同顺序通道。 Bundler 最终发出的底层交易仍有 Bundler EOA 自己的协议 nonce。前者防 UserOperation 重放，后者排序底层交易。^[1]

03 · The ERC-4337 journey

一份意图，怎样变成区块里的状态变化？

先在链外被模拟与打包，再在链上分成验证循环与执行循环。

ERC-4337 的核心不是某个新钱包按钮，而是一条端到端路径。每个角色只做自己那一段；把它们混成“钱包替我发交易”，就会看不清信任与失败边界。

Interactive · operation journey

逐步走过 UserOperation 的七站

FIG 04

01

钱包把用户动作编码成 UserOperation

例如“从我的智能账户调用 DEX，批准 100 USDC 后兑换”。callData 可以让账户执行一次或多次调用。

Bundler 在接收、组包和提交前多次模拟验证，目的是避免把不付费或会在验证阶段失效的操作带进链上 bundle。

六个角色，各自负责什么？

USER / WALLET表达与授权构造操作、展示风险、取得账户认可的签名或证明。

SMART ACCOUNT定义有效授权validateUserOp 检查签名、时间与账户策略；EntryPoint 验证 nonce 序列，execute 发出真实调用。

BUNDLER模拟与打包维护操作池、筛掉无效操作，并用一笔底层交易调用 handleOps。

ENTRYPOINT共同入口创建账户、验证账户与 Paymaster、执行 callData、核算并支付费用。

FACTORY按需创建账户对尚未部署的 sender 使用确定性创建逻辑。

PAYMASTER选择是否赞助验证赞助条件，并用预存于 EntryPoint 的原生币承担费用。

三个不是

Bundler 不是以太坊验证者的同义词；它把 bundle 送往区块包含路径。 EntryPoint 不是替用户保管资产的中心账户；它协调验证、执行与计费。 Paymaster 不是让计算免费；它只是改变最终由谁用原生币支付。

04 · Validation and signatures

“有效签名”不再只有一种解释

validateUserOp、ERC-1271 与交易签名解决的是三个不同接口层的问题。

UserOperation 的 signature 是不透明 bytes。账户可以把它解释为一枚 ECDSA 签名、多枚签名、passkey 证明或聚合证明。ERC-4337 不替账户规定格式，只要求账户通过 validateUserOp 给出验证结果，并确保调用者是受信任的 EntryPoint。^[1]

三种签名验证所在层级
接口	谁调用	验证什么	能否直接产生底层交易 sender
协议交易签名	执行客户端在接收交易时	固定交易格式与 EOA 授权	能，恢复并确定 EOA sender
validateUserOp	EntryPoint	某个 UserOperation 是否被账户授权、在时段内有效并能付费	不能；它验证高层操作
ERC-1271	DApp 或其他合约	某个 hash + signature 是否能代表合约账户	不能；成功返回约定 magic value

ERC-1271 的 isValidSignature 是只读验证接口，成功值为 0x1626ba7e。它让 DEX 订单、登录消息与许可等应用理解“合约也可以认可一份签名”，但没有给合约创造私钥，也没有让合约成为底层交易发送者。^[2]

为什么 Bundler 不能只相信账户说“我会付钱”？

普通交易的静态检查相对简单；智能账户验证会执行代码、读取状态，并可能依赖 Factory 或 Paymaster。攻击者若能免费提交大量“看似会付款、最后却失败”的操作，就能堵塞操作池或让 Bundler 亏损。因此规范要求模拟、限制验证阶段的状态访问与资源，并对共享 Factory / Paymaster 使用质押与信誉约束。

签名必须绑定作用域

ERC-4337 的 userOpHash 会承诺除 signature 外的整份打包操作：包括 sender、nonce、创建数据、callData、Gas / 费用字段与 Paymaster 数据，并用 chainId 和 EntryPoint 地址限定作用域。账户的 validateUserOp 必须验证这份 hash；具体账户还可以在签名方案中加入有效时间、实现版本等额外约束。“签了一个 hash”没有意义，除非你知道那个 hash 承诺了什么。

05 · Counterfactual account

账户可以先有地址，第一次使用时再部署

Factory + CREATE2 把部署成本推迟到首个 UserOperation。

如果合约钱包必须先由另一只钱包付一笔部署交易，入门体验就回到了原点。 ERC-4337 允许 sender 尚未部署：钱包根据 Factory、创建参数与 CREATE2 逻辑计算地址，这个地址可以先接收资产；首次操作进入 EntryPoint 时，Factory 才真正部署账户。^[1]^[3]

Interactive · counterfactual deployment

地址没变，链上状态发生了什么？

FIG 05

本地确定性计算0xSmart…A11C可展示、可收 ETH / token 记账

STATE · NOT DEPLOYED

地址可知，code 尚不存在

这不是“隐藏合约”；它只是一个按 Factory 与创建参数可预测的未来地址。

UserOperation 携带factory + factoryDataEntryPoint 触发 senderCreator / Factory

STATE · CREATE

创建与首个动作进入同一流程

Factory 必须在预期 sender 地址部署账户；否则验证失败。

同一地址0xSmart…A11Cruntime code + storage 已存在

STATE · ACTIVE

后续操作不再携带创建数据

账户直接验证并执行；之前记在该地址名下的资产关系无需搬家。

“反事实”不是说账户虚假存在，而是说部署前就能推导部署后的地址与控制条件。

还没部署的账户怎样签登录消息？

ERC-1271 需要调用账户代码；未部署时没有代码可调用。ERC-6492 为这类“部署前签名”定义包装，把 Factory 与创建数据连同签名一起交给验证者，使其可以准备或模拟部署后再按 ERC-1271 验证。^[4]

安全边界 · 初始化

地址可预测不等于初始化天然安全。Factory 必须确保创建参数与预期 owner / 模块绑定，智能账户初始化只能发生一次，且不应让抢跑者先写入自己的控制者。

06 · Gas abstraction

“免 Gas”不是没有成本，而是付款路径被抽象

最终仍有人用链的原生币支付 Bundler；Paymaster 决定是否替用户承担。

EntryPoint 在验证前确保最大可能费用有来源。没有 Paymaster 时，智能账户可用自己的 EntryPoint deposit；有 Paymaster 时，EntryPoint 调用其验证函数，确认它愿意为这份操作买单，并从 Paymaster 的原生币 deposit 扣除实际成本。^[1]

Interactive · who pays?

用户看到“0 ETH”，账本背后是谁付款？

FIG 06

SMART ACCOUNT DEPOSIT预存 0.02 ETH 到 EntryPoint

用户界面账户支付

EntryPoint 扣款账户 deposit 的 ETH

Bundler 收到实际 Gas 费用

额外信任无需 Paymaster

APP PAYMASTER应用为符合条件的首次操作赞助

用户界面0 ETH

EntryPoint 扣款Paymaster deposit 的 ETH

Bundler 收到实际 Gas 费用

额外信任赞助策略与服务可用性

TOKEN PAYMASTER预扣 USDC，链上仍用 ETH 结算 Gas

用户界面以 USDC 计价

EntryPoint 扣款Paymaster deposit 的 ETH

Paymaster 结算预扣后按实际成本退款

额外信任报价、预言机与代币授权

Paymaster 验证通过后，即使主执行回滚，它仍可能要支付已经消耗的 Gas；规范提供 postOp 处理成功或回滚后的结算。

deposit 与 stake 不是一回事

Deposit 是 EntryPoint 实际用于付 Gas 的余额； stake 是 Factory / Paymaster 为获得更宽状态访问与抵抗女巫式 DoS 而锁定的经济承诺。 ERC-4337 的 stake 不是共识质押，也没有协议罚没；Bundler 按规范的信誉与延迟规则判断这些共享实体。

翻译“Gasless”

更准确的中文不是“这次计算没有 Gas”，而是： 用户不必在这个账户里预先持有原生币，费用由别的 deposit 先付，再按赞助或代币规则结算。

07 · What programmability enables

批处理、会话钥匙和恢复，都不是魔法按钮

账户抽象提供可编程入口；具体语义仍由账户实现。

BATCH一次授权，多次调用

例如 approve + swap；是否原子取决于账户 executeBatch 怎样处理失败。

SESSION短期、限额、限目标

减少根密钥频繁签名，但必须能撤销并限制有效域。

RECOVERY守护人 + 延迟

提高丢钥恢复能力，也引入社会工程与治理攻击面。

MODULE按需安装能力

验证、执行与 Hook 可模块化；模块供应链就是账户安全边界。

“打包”有两种，不要混淆

账户批处理与 Bundler bundle 的区别
打包	谁做	目的	失败是否彼此原子
账户内调用批处理	智能账户的 execute / executeBatch	一次 UserOperation 完成多次 DApp 调用	由账户代码定义；常见实现可让整批一起回滚
Bundler bundle	Bundler	用一笔 handleOps 交易承载多个用户的 UserOperation	不同 UserOperation 不是同一个用户原子动作；执行失败可独立记录并继续

账户抽象还允许替代签名方案，但链上验证仍有成本与兼容性要求。 “支持 passkey”通常意味着账户代码或验证器能验证相应曲线 / 证明，并且钱包能把用户操作安全地绑定到人类可读意图；它不是把 WebAuthn 凭证直接塞进普通 EOA 交易签名。

恢复不是撤销链上历史

社交恢复可以改变未来的控制规则，不能逆转攻击者已经成功执行的转账。好的恢复流程必须同时考虑延迟、通知、取消、守护人串谋和升级权限。

08 · ERC-4337 and EIP-7702

两条路径不是竞争关系，而是可以叠加

4337 为合约账户搭建操作基础设施；7702 让既有 EOA 地址接上可编程代码。

ERC-4337 不修改以太坊共识协议：新智能账户通常由 Factory 部署，用户通过 UserOperation 使用它。 EIP-7702 是 Pectra 的协议改动：EOA 私钥可授权把持久 delegation indicator 写入自己的 code，调用时加载另一地址的实现，却在 EOA 自己的地址、余额与 storage 上下文执行。^[5]^[6]

ERC-4337、EIP-7702 与组合路径
维度	ERC-4337 合约账户	EIP-7702 委托 EOA	组合使用
地址起点	通常是 Factory 确定性创建的新账户地址	保留原 EOA 地址与资产关系	原 EOA 地址作为 4337 sender
底层变化	无需共识协议新交易类型	类型 4 交易处理授权列表	Bundler 可把 7702 authorization 放入 bundle 交易
根授权	由账户代码定义	原 EOA 私钥始终能替换或清除 delegation	日常走智能规则，根 EOA key 仍是特殊权力
基础设施	UserOperation、Bundler、EntryPoint、可选 Paymaster	可自行发类型 4 交易或依赖 relayer	使用 4337 标准化转发与赞助

在组合路径里，eip7702Auth 与 UserOperation 一起提交，却不是 UserOperation 的内部字段。Bundler 会把授权元组放进外层类型 4 bundle 交易；规范的哈希流程还会把预期 delegate 地址绑定进 userOpHash，避免授权后悄悄换成另一份实现。^[1]

一个重要的安全修正

把 EOA 委托给“2 / 3 多签逻辑”不会自动消灭原私钥的最终权力。 EIP-7702 指南明确提醒：EOA 私钥仍能重新授权别的实现或清除委托。所以它能获得多签式日常策略，却不等于变成没有单钥后门的传统多签合约账户。^[6]

7702 委托的三类风险

钓鱼：把整个 EOA 委托给恶意代码； 初始化抢跑：攻击者先写入自己的 owner； storage 冲突：更换实现后，旧数据被新代码用不同类型解释。 delegation 是持久指针，不是“一笔交易临时借用后自动消失”。

09 · Failure and security boundaries

验证失败、执行回滚与服务不可用，是三种故障

只有把故障放回正确层，才知道资产、费用和可恢复性分别受什么影响。

VALIDATION FAILURE操作不应进入 bundle

签名、nonce、时间、Factory、Paymaster 或 deposit 不通过。Bundler 模拟后丢弃；若链上验证失败，EntryPoint 跳过该操作并可能让 handleOps 回滚。

EXECUTION REVERT授权有效，业务失败

账户已通过验证，但 DApp 调用回滚。该 UserOperation 的业务状态不提交；已经使用的 Gas 仍由账户或 Paymaster 承担。

SERVICE FAILURE请求尚未上链

某个 Bundler / Paymaster / RPC 离线或拒绝服务。若账户与接口可互操作，可更换服务；硬编码单一 relayer 会形成可用性单点。

看一个智能账户，至少审查八处

01 / ROOT

根授权

哪把钥匙、哪些守护人或哪个治理合约能改变验证规则？

02 / INIT

初始化

账户或 7702 委托第一次设置 owner / 模块时，谁能调用，是否绑定签名？

03 / MODULES

模块与升级

谁能安装验证器、Hook、执行模块或更换实现？storage 是否兼容？

04 / DOMAIN

签名域

操作是否绑定链、EntryPoint、账户、nonce、调用数据与有效期？

05 / GAS

费用上限

Paymaster 预扣什么、怎样退款；Gas 限额与费用字段是否可能被替换？

06 / SERVICES

服务可替换性

账户是否依赖单一 Bundler、Paymaster、RPC、签名聚合器或专有模块？

07 / UI

人类可读意图

钱包展示的是最终调用、批处理与权限，还是只让用户盲签一个 hash？

08 / FALLBACK

恢复与退出

服务停摆、模块损坏或根钥匙丢失后，是否有受限且可观察的恢复路径？

Bundler 没有资产托管权

Bundler 可以审查、延迟或不包含一份 UserOperation，但不能凭空伪造通过智能账户验证的授权。真正的风险分界是：你的账户能否换 Bundler，验证代码是否正确，以及钱包有没有让你看懂自己授权的 callData。

10 · Mental model and check

把账户抽象压缩成六个动作

以后看到“智能账户、Gasless、批量交易”，先沿这条链核对。

01表达意图钱包构造目标、calldata、费用与时效。

02账户授权按单签、多签、passkey 或策略产生证明。

03模拟验证Bundler 检查 nonce、代码、费用与状态依赖。

04打包上链多个 UserOperation 进入一笔 handleOps 交易。

05验证执行EntryPoint 调账户与 Paymaster，再执行 callData。

06结算费用账户或 Paymaster deposit 支付 Bundler。

七个常见误区

误区 1：UserOperation 就是一种新的以太坊交易

它是 ERC-4337 的高层伪交易对象。Bundler 最终提交的 handleOps 才是底层协议交易。

误区 2：Bundler 就是验证者

Bundler 模拟并打包 UserOperation；验证者 / 区块构建者负责底层交易包含路径。角色可能由同一实体兼任，但概念不同。

误区 3：Paymaster 让 Gas 消失

Gas 仍被计量并由原生币结算。Paymaster 只是用自己的 EntryPoint deposit 先付，可能再向用户收代币或由应用补贴。

误区 4：智能账户一定有社交恢复和 passkey

账户抽象允许实现这些能力，不保证每个账户已经安全实现。要检查具体代码、模块与钱包支持。

误区 5：bundle 内所有用户操作必须一起成功或失败

Bundler bundle 是承载层；不同 UserOperation 的主执行可独立成功或回滚。账户自己的 executeBatch 才决定单个操作内的原子性。

误区 6：EIP-7702 把 EOA 永久变成传统合约账户

它写入可替换或清除的委托指针，原 EOA 私钥仍保留授权控制；执行时才加载委托实现。

误区 7：服务商离线就等于资产丢失

如果账户与标准接口可互操作，用户可以换 Bundler / Paymaster；如果实现硬编码唯一服务，则会形成可用性单点。

现在检查你的理解

1. ERC-4337 中，哪一个才是进入区块的底层协议交易？

UserOperation 是高层对象；Bundler 把多个操作封装进一笔底层 handleOps 交易。

2. 智能账户的 signature 字段最准确的理解是什么？

ERC-4337 不规定账户签名格式；账户代码决定怎样验证这段 bytes。

3. 用户界面显示“0 ETH Gas”时，哪项一定仍然成立？

Gas 没消失；只是付款者与用户的结算媒介发生变化。

4. “反事实账户”在部署前具有什么？

地址可以先算出并接收资产记账；代码在首次操作中由 Factory 部署。

5. EIP-7702 EOA 委托给多签逻辑后，哪项仍要特别记住？

7702 让 EOA 获得委托代码能力，但根私钥仍控制后续授权变化。

6. Bundler 为什么要在接收和打包前反复模拟验证？

智能验证依赖 EVM 状态；模拟与限制规则让操作池和 Bundler 能抵抗廉价 DoS。

11 · Glossary and primary sources

把术语钉在正确层级上

账户抽象的难点，不是词多，而是每个词属于不同的链上或链外层。

账户抽象 ACCOUNT ABSTRACTION

把账户授权、执行或费用逻辑从固定协议假设中抽离，交给可编程账户与配套基础设施。

智能账户 SMART ACCOUNT

用合约代码定义授权和执行规则的用户账户；可能是独立合约账户，也可能是 7702 委托 EOA。

UserOperation USEROP

ERC-4337 的高层操作对象，描述 sender、动作、nonce、费用、可选创建与赞助数据，以及账户解释的签名。

Bundler BUNDLER

接收、模拟、筛选并打包 UserOperation，最终提交 handleOps 底层交易的参与者。

EntryPoint ENTRYPOINT

ERC-4337 的共同入口合约，协调账户创建、验证、Paymaster、执行与费用结算。

Paymaster PAYMASTER

按自定义条件同意为 UserOperation 支付 Gas 的辅助合约；费用来自它在 EntryPoint 的原生币 deposit。

Factory ACCOUNT FACTORY

按确定性参数创建智能账户的合约，使账户地址可以在部署前计算。

反事实部署 COUNTERFACTUAL

先确定未来合约地址并使用它，等首次操作时再由 Factory 实际部署代码。

ERC-1271 CONTRACT SIGNATURE

让合约用 isValidSignature 表示某份签名在其规则下有效的只读验证接口。

EIP-7702 委托 EOA DELEGATION

EOA 授权在自身 code 写入指向实现的 delegation indicator，调用时在 EOA 上下文执行实现代码。

官方一手资料

ERC-4337 · Account Abstraction Using Alt MempoolUserOperation、Bundler、EntryPoint、nonce、Factory、Paymaster、模拟、bundle 与 7702 组合的正式规范。
ERC-1271 · Standard Signature Validation Method for Contracts合约账户如何用 isValidSignature 验证代表自己的签名。
EIP-1014 · Skinny CREATE2反事实账户所依赖的确定性合约地址公式与碰撞边界。
ERC-6492 · Signature Validation for Predeploy Contracts尚未部署的合约账户如何包装并验证签名。
EIP-7702 · Set Code for EOAs类型 4 交易、authorization list、delegation indicator 与执行语义。
ethereum.org · Pectra EIP-7702 guidelines7702 钱包集成、初始化、storage、钓鱼、relayer 与 4337 兼容的官方指南。
ethereum.org · Account abstraction账户抽象目标、恢复、Gas 赞助，以及 4337 与 7702 路线概览。
ethereum.org · Prague-Electra (Pectra)Pectra 于 2025-05-07 在主网激活及 EOA 可编程能力概览。
ethereum.org · Ethereum accountsEOA、合约账户、钱包与账户状态的基础定义。
ethereum.org · Transactions底层以太坊交易与 EIP-7702 类型 4 交易的官方说明。

资料核对：2026-07-25 · 技术事实以 Ethereum 规范、ERC / EIP 与 ethereum.org 一手资料为基线。