T27 · Account Abstraction

一个现实问题

你做了一个链上应用，功能很轻，第一次使用只要点三下。

新用户的实际流程是这样的：

1. 装一个钱包扩展
2. 抄下 12 个英文单词，抄完还要按顺序选一遍
3. 去某个地方买一点原生代币，否则连第一笔操作都发不出去
4. 点「开始」，弹出签名框，确认
5. 点下一步，又弹一次
6. 再下一步，再弹一次

你去看漏斗：一百个人点进来，装完钱包的三十个，抄完助记词的十五个，账户里有 Gas 的五个，完成第一次操作的两个。

产品本身没有任何问题。流失全部发生在「成为一个链上账户」这件事上。

更难受的是另一半。三个月后，那两个完成操作的用户里，有一个发消息问你：换手机之后钱包没了，助记词当时抄在一张便签上，找不到了，能不能帮忙找回。

你只能回答不能。

把这两件事放在一起看，会发现它们是同一件事的两面：在 EOA 的世界里，私钥就是账户的全部。 有它就有全部权限，没它就什么都没有。

没有「只能玩这个游戏」的权限，没有「单笔不超过十块钱」的权限，没有「丢了可以按流程恢复」的路径。

所以问题是：这个「全有或全无」，能不能拆开？

思想实验

把两种账户放在一起对比。

第一种：一个只有一把钥匙的保险柜。

钥匙在谁手里，柜子就归谁。钥匙不区分用途——它不能只打开柜子的左半边。钥匙也不能挂失——柜子不认人，只认钥匙。丢了就是永远打不开，被偷了就是东西没了。

在这个世界里，「谁能动这些钱」是一个物理事实。

第二种：一家公司的对公账户。

这里没有「一把钥匙」，只有一本章程：

- 出纳可以付 5000 元以下
- 财务总监可以付 5 万元以下
- 超过 50 万，需要两个人签字
- 每月的房租和水电是定期付款，不用每次审批
- 如果董事长的印章丢了，按流程公示、等待异议期、重新刻一个

注意这本章程做到了保险柜做不到的四件事：按金额分级、按用途授权、多人共同决定、以及钥匙丢了有救。

而它能做到这些，只因为一个差别：

在保险柜里，「谁能动钱」是物理事实；在公司账户里，「谁能动钱」是一段可以被阅读、被修改、被审计的规则。

账户抽象要做的，就是把这段规则搬到链上，写成代码。账户不再是一个公钥算出来的地址，而是一份合约，合约里有一个函数专门回答一句话：「这笔操作，我认不认。」

到这里故事很美好。但推演不能停在这里，因为规则一旦变成代码，一个新问题就出现了：

改这段规则的权力，归谁？

保险柜的世界里只有一种死法：钥匙丢了。规则的世界里多了一种：规则被改了。

你没有消灭风险，你把它从一个物理问题变成了一个治理问题。这一章后半段的全部内容，都在处理这个新问题。

你来决定

回到那个漏斗。你要改善它，只能先做一件事。

观察结果

四条路的对照：

第三列和第四列放在一起看，第一条结论就出来了：

账户抽象没有消灭密钥，它把「一把密钥的全部权限」拆成了「多把密钥的不同权限」，外加一条密钥丢失之后的恢复路径。

这是一次实打实的改进——它让「权限」这个词第一次在账户层面有了意义。

但也正因为如此，第二条结论必须同时说出来：

权限一旦可以被拆分，权限边界就成了新的攻击面。

EOA 的攻击面只有一个：私钥。智能账户的攻击面至少有五个：账户合约本身的代码、会话密钥的范围定义、代付方的赞助规则、恢复机制、以及谁能改上面这四样东西。

这不是在说账户抽象不好，而是在说它把问题换了个位置。换过去的那个位置有一个巨大的好处：它是可以被审计、被测试、被写成断言的。 助记词丢了没有测试可以写，会话密钥的范围写错了有。

你会发现这套东西和 T32 的结构一模一样：结构化的提案、确定性的校验、可配置的策略、可追溯的日志。账户抽象就是把那套策略引擎搬进了合约里。

建立模型

一条核心分割线：验证与执行分离

智能账户的全部设计，都从这一条分割线展开：

validate(op)  →  这笔操作我认不认？（只看规则，不做事）
execute(op)   →  做事（只在 validate 通过之后）

EOA 里这两件事是同一件事：签名对了就执行，没有中间状态。智能账户把它们拆开，于是「认不认」变成了一段你可以自己写的代码。

一笔操作的完整流转

用户不再直接发交易，而是发一份操作意图，由别人打包上链。

这条链上有三个角色是 EOA 世界里不存在的：

第一行和上一章的分层是同一个道理：打包者属于传输层，它只影响消息送不送得到，不影响消息真不真。 说「我们有很多打包者所以很安全」是一句错位的话。

账户合约的核心

把最关键的部分写出来，剩下的都是外围：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract SmartAccount {
    address public owner;                 // 主密钥
    uint256 public nonce;                 // 防重放
    address public immutable entryPoint;  // 唯一允许调用的入口

    struct SessionKey {
        uint48  validUntil;    // 到期时间
        uint128 spendLimit;    // 累计额度上限（最小单位）
        uint128 spent;         // 已用额度
        bool    enabled;
    }

    // 会话密钥 → 授权范围
    mapping(address => SessionKey) public sessions;
    // 会话密钥 → 目标合约 → 函数选择器 → 允许与否
    mapping(address => mapping(address => mapping(bytes4 => bool))) public allowed;

    constructor(address ep, address o) {
        entryPoint = ep;
        owner = o;
    }

    modifier onlyEntryPoint() {
        require(msg.sender == entryPoint, "not entry point");
        _;
    }

    /// 验证阶段：只判断认不认，不做任何外部调用
    function validate(
        bytes32 opHash,
        bytes calldata signature,
        address target,
        bytes4  selector,
        uint256 value
    ) external onlyEntryPoint returns (bool) {
        address signer = recover(opHash, signature);

        // 主密钥：无限制
        if (signer == owner) return true;

        // 会话密钥：逐项检查范围
        SessionKey storage s = sessions[signer];
        if (!s.enabled) return false;
        if (block.timestamp > s.validUntil) return false;
        if (!allowed[signer][target][selector]) return false;
        if (value + s.spent > s.spendLimit) return false;

        // 累计额度必须在验证阶段就扣掉，否则同一把密钥可以在一个区块内被用很多次
        s.spent = uint128(s.spent + value);
        return true;
    }

    /// 执行阶段：入口合约确认验证通过之后才会调到这里
    function execute(address target, uint256 value, bytes calldata data)
        external
        onlyEntryPoint
    {
        (bool ok, bytes memory ret) = target.call{value: value}(data);
        if (!ok) {
            assembly { revert(add(ret, 32), mload(ret)) }
        }
    }

    function recover(bytes32, bytes calldata) internal pure returns (address) {
        return address(0); // 用你的框架里的签名恢复实现替换
    }
}

这段代码里有四个决定，每一个都对应一类真实事故。

第一，onlyEntryPoint。 账户合约必须限定调用来源，否则任何人都能直接调 execute 把钱转走。这是 T7 那条「对外入口必须假设任何人都会调它」的直接应用。

第二，累计额度在验证阶段就扣。 如果放到执行之后再扣，同一把会话密钥可以在同一个区块里被用很多次，每次检查时 spent 都还是旧值。这就是下一章重入的雏形：状态更新晚于使用，就会被重复利用。

第三，验证阶段不做外部调用。 这一条看起来是洁癖，实际上是打包者的生命线：打包者在链下先模拟一遍验证，通过了才打包上链；如果验证依赖外部状态，链下模拟通过、链上执行失败，打包者白付 Gas。成百上千次之后它就不再服务你的账户了。所以验证阶段的可用操作是被严格限制的。

第四，执行失败时把原始错误原样抛出。 T14 讲错误映射时留了一个尾巴：一笔交易里打包了多个动作，回执只有一个 status。这里是它的解法——账户合约必须把内层的 revert 数据原样冒泡出来，否则前端只能显示「交易失败」，永远说不清是哪一步失败的。

会话密钥：范围就是全部

会话密钥不是「一把弱一点的密钥」，而是一把带范围的密钥。范围写得对不对，决定了它是一个功能还是一个漏洞。

一份可用的范围定义至少包含六项：

第三行要单独说。很多实现只限制了「能调哪个合约」，没限制「能调哪个函数」。于是一把只该用来玩游戏的密钥，可以对游戏合约调用一次授权类的函数，把额度授给一个攻击者控制的地址，然后在链下慢慢取走。

T32 里那个「通过授权而不是转账」的案例，在这里原封不动地重演一次。它的教训也一样：

策略必须覆盖所有会改变资金控制权的动作，而不只是转账。

代付：谁付 Gas，谁就要有自己的策略

代付方是一个替别人付钱的合约。这句话本身就说明了它的风险：任何没有边界的赞助，都是一个可以被持续提取的池子。

三种常见模式：

代付方自己的策略至少要有：每个账户的次数与金额上限、全局的日预算、允许被调用的目标合约白名单、以及一个能立刻关掉的开关。

第二行那个「代币本身有转账钩子」是 T9 埋下的线：非标准代币的 transfer 可能把执行权交给别人。代付方在收款时如果不注意这一点，会在自己的核心路径上引入一次外部调用。下一章会把这件事的后果完整演示一遍。

恢复：这一节是这一章最危险的部分

社交恢复的标准流程：

1. 账户主人预先指定 N 个守护人，设定阈值 M
2. 主密钥丢失时，M 个守护人签名，发起一次「把主密钥换成新地址」的提议
3. 进入时间锁，等待 T 天
4. T 天之内，当前主密钥可以一键取消这次提议
5. T 天之后没有被取消，恢复生效

第 3 步和第 4 步是整个机制的安全性来源，没有它们，M 个守护人等于 M 把可以直接夺取账户的钥匙。

但即便有它们，这套机制仍然有大量被滥用的空间。把它们列全很重要，因为设计恢复流程时最容易犯的错，就是只想到「用户丢了密钥」这一种情况：

第四行值得反复强调。时间锁的全部前提是用户在窗口内能看到通知并且有能力取消。这个前提在最需要恢复机制的那些场景里恰恰不成立——一个人之所以丢了密钥，往往就是因为发生了让他没法正常上网的事。

所以设计恢复流程时，有三条比「选几个守护人」重要得多：

1. 恢复提议必须产生一个链上事件，并且要有链下通知的通道。 用户看不见的提议，等于没有时间锁。
2. 当前主密钥的取消权必须是无条件、无延迟的。 取消这个动作本身不能再有任何门槛。
3. 守护人的独立性要被验证，而不是被假设。 至少记录每个守护人是怎么被确认的、什么时候确认的。

还有一条属于产品而不属于代码：时间锁的长度是一次权衡，不是一个技术参数。 短了防不住合谋，长了让真正需要恢复的人等太久。不同金额的账户应该给不同的长度，这和 T17 那张按业务风险分档的确认深度表是同一个思路。

它叫什么

动手

验收 1：主密钥能执行任意操作
验收 2：会话密钥只能执行范围内的操作，范围外必须 revert
验收 3：用户账户里一分钱原生代币都没有，操作仍然成功
验收 4：会话密钥无法通过授权类调用绕过额度限制

- 链上那笔交易的 from 是谁？（不是用户）
- Gas 是从哪个账户扣的？
- 你的 validate 被调用了几次？

- 够数的守护人发起恢复，主密钥在窗口内取消：恢复必须失效
- 够数的守护人发起恢复，窗口内无人取消：恢复必须生效
- 恢复提议必须发出一个链上事件，事件里带发起人、新主密钥、生效时间

AI Lab

第一步：
为一个智能账户设计社交恢复流程。
给出完整的状态机：有哪些状态、什么事件触发状态转移、
每个状态下谁能做什么。用合约函数的粒度描述，不要用抽象说法。

第二步：
列出这套流程的全部信任假设，每一条写成
「如果 ___ 作恶或失效，账户会被 ___」。
主语要具体到角色和数量。

第三步：
现在扮演攻击者。你的目标是夺取一个使用了这套流程的账户。
给出至少 6 条攻击路径，每一条包含：
- 你需要什么前提条件
- 具体的操作步骤
- 这套流程的哪一个环节没有挡住你
- 账户主人有没有机会发现
不要只考虑技术手段，社会工程和时机选择也算。

真实案例

改一个变量

带走的问题

本章自测