区块链跨链桥安全实战：从常见攻击面分析到合约审计与防护方案落地

跨链桥是 Web3 里最“值钱也最危险”的组件之一。原因很直接：桥合约往往托管高价值资产，还要同时和多条链、签名节点、消息验证逻辑打交道，任何一个点出问题，损失都可能是系统级的。

这篇文章我会尽量按“带你做一遍”的方式来讲，不只说攻击面，还会落到一个可运行的简化示例：做一个 基于多签验证的简化跨链桥，然后从代码里指出典型漏洞，再给出审计思路和防护方案。你看完至少能做到三件事：

看懂跨链桥的基本工作流；
能对桥合约做第一轮安全检查；
知道哪些防护是“必须做”，哪些只是“锦上添花”。

背景与问题

为什么跨链桥这么容易出事？

跨链桥本质上是在两条链之间同步“资产状态”或“消息状态”。常见做法包括：

锁定-铸造（Lock-Mint）：在源链锁住资产，在目标链铸造映射资产；
销毁-解锁（Burn-Unlock）：目标链销毁映射资产，源链释放原生资产；
消息桥（Message Passing）：跨链传递任意消息，再由目标链合约执行逻辑。

风险恰恰就出在这里：跨链桥不是单一合约，而是一个系统。

它通常包含：

源链托管合约
目标链铸造/释放合约
验证节点或多签委员会
消息编码与签名系统
链下中继服务
运维与权限管理模块

任何一个环节被击穿，都可能导致“凭空铸币”“重复提现”或者“非法解锁”。

常见安全事故的共性

我把大部分跨链桥事故归纳成四类：

验证机制被绕过
- 签名伪造
- 验证者门限设计错误
- 签名消息未绑定链 ID / 合约地址 / nonce
合约业务逻辑有缺陷
- 重放攻击
- 重入攻击
- 余额记账错误
- 未校验资产精度、代币返回值
权限与运维失控
- owner 权限过大
- 升级代理可被恶意实现替换
- 私钥泄露
链下组件可信假设过强
- 中继器可单点作恶
- 节点同步不一致
- 观察者网络被控制

跨链桥安全，核心不是“把合约写对”这么简单，而是要把信任边界画清楚。

前置知识

建议你至少熟悉这些概念：

Solidity 基础
ECDSA 签名恢复
多签门限机制
ERC20 标准的常见坑
重放攻击与重入攻击
基本审计方法：权限、状态机、外部调用、输入校验

环境准备

下面的示例我用 Solidity + Hardhat 来写，尽量简化依赖，方便你本地跑起来。

目录初始化

mkdir bridge-security-demo
cd bridge-security-demo
npm init -y
npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox
npx hardhat

选择一个基础 JavaScript 项目即可。

安装 OpenZeppelin

npm install @openzeppelin/contracts

核心原理

我们先不急着写代码，先把桥的最小可信闭环讲清楚。

一个简化跨链桥的工作流

假设从 ChainA 转资产到 ChainB：

用户在 ChainA 调用 lock()，把资产存入桥合约；
链下观察者看到这笔锁仓事件；
多个验证者对“这笔跨链消息”签名；
用户或中继器把签名提交到 ChainB；
ChainB 桥合约验证签名数量达到门限；
桥合约在 ChainB 执行 mint() 或 release()；
该消息被标记为已处理，防止重复执行。

这个过程里最关键的是：目标链到底凭什么相信这笔消息是真的？

答案一般有三类：

外部验证者签名：实现简单，但信任集中；
轻客户端验证：更去中心化，但实现复杂、成本高；
乐观验证 / 挑战机制：在效率与安全之间折中。

本文重点讲第一类，因为它最常见，也最容易写出问题。

跨链消息最小安全字段

一条用于解锁/铸造的跨链消息，至少应该绑定这些信息：

sourceChainId
targetChainId
sourceBridge
targetBridge
token
receiver
amount
nonce

如果缺任何一个，都可能埋下重放攻击的坑。

比如你只签了 (receiver, amount)，那攻击者就可能把同一份签名拿去别的桥合约、别的链，甚至重复提交。

架构图：跨链桥的最小可信流

flowchart LR
    U[用户] --> A[ChainA 锁仓合约]
    A --> E[Lock 事件]
    E --> R[中继器/观察者]
    R --> V[验证者集合签名]
    V --> B[ChainB 桥合约 verify]
    B --> M[Mint/Release]

时序图：一次安全的跨链执行

sequenceDiagram
    participant User as 用户
    participant SA as 源链桥合约
    participant Relayer as 中继器
    participant Signers as 验证者集合
    participant TB as 目标链桥合约

    User->>SA: lock(token, amount, receiver)
    SA-->>Relayer: 触发 Locked 事件
    Relayer->>Signers: 广播跨链消息
    Signers-->>Relayer: 返回签名
    Relayer->>TB: execute(message, signatures)
    TB->>TB: 校验链ID/桥地址/nonce/门限签名
    TB->>TB: 标记消息已执行
    TB-->>User: mint/release 资产

实战代码（可运行）

下面我们实现一个 简化版目标链桥合约。它的核心能力是：

接收一条跨链消息；
验证该消息由足够多的验证者签名；
防止消息被重复执行；
向用户转出 ERC20 资产。

提醒：这是教学示例，不适合直接上生产。

1）测试代币合约

contracts/TestToken.sol

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

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract TestToken is ERC20 {
    constructor() ERC20("Test Token", "TT") {
        _mint(msg.sender, 1_000_000 ether);
    }

    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }
}

2）桥合约

contracts/SimpleBridge.sol

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

import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SimpleBridge is Ownable, ReentrancyGuard {
    using SafeERC20 for IERC20;
    using ECDSA for bytes32;

    struct Message {
        uint256 sourceChainId;
        uint256 targetChainId;
        address sourceBridge;
        address targetBridge;
        address token;
        address receiver;
        uint256 amount;
        uint256 nonce;
    }

    mapping(address => bool) public validators;
    mapping(bytes32 => bool) public executed;
    uint256 public threshold;

    event ValidatorUpdated(address validator, bool active);
    event ThresholdUpdated(uint256 threshold);
    event Executed(bytes32 indexed messageId, address token, address receiver, uint256 amount);

    constructor(address[] memory _validators, uint256 _threshold) Ownable(msg.sender) {
        require(_validators.length > 0, "empty validators");
        require(_threshold > 0 && _threshold <= _validators.length, "bad threshold");

        for (uint256 i = 0; i < _validators.length; i++) {
            require(_validators[i] != address(0), "zero validator");
            validators[_validators[i]] = true;
            emit ValidatorUpdated(_validators[i], true);
        }

        threshold = _threshold;
        emit ThresholdUpdated(_threshold);
    }

    function setValidator(address validator, bool active) external onlyOwner {
        require(validator != address(0), "zero validator");
        validators[validator] = active;
        emit ValidatorUpdated(validator, active);
    }

    function setThreshold(uint256 _threshold) external onlyOwner {
        require(_threshold > 0, "threshold 0");
        threshold = _threshold;
        emit ThresholdUpdated(_threshold);
    }

    function getMessageHash(Message calldata m) public pure returns (bytes32) {
        return keccak256(
            abi.encode(
                m.sourceChainId,
                m.targetChainId,
                m.sourceBridge,
                m.targetBridge,
                m.token,
                m.receiver,
                m.amount,
                m.nonce
            )
        );
    }

    function execute(
        Message calldata m,
        bytes[] calldata signatures
    ) external nonReentrant {
        require(m.targetBridge == address(this), "wrong target bridge");
        require(m.targetChainId == block.chainid, "wrong target chain");
        require(signatures.length >= threshold, "not enough sigs");

        bytes32 messageHash = getMessageHash(m);
        bytes32 ethSignedMessageHash = messageHash.toEthSignedMessageHash();

        require(!executed[messageHash], "already executed");

        uint256 validCount = 0;
        address lastSigner = address(0);

        for (uint256 i = 0; i < signatures.length; i++) {
            address signer = ethSignedMessageHash.recover(signatures[i]);
            require(validators[signer], "invalid signer");
            require(signer > lastSigner, "duplicate or unordered signer");
            lastSigner = signer;
            validCount++;
        }

        require(validCount >= threshold, "threshold not met");

        executed[messageHash] = true;

        IERC20(m.token).safeTransfer(m.receiver, m.amount);

        emit Executed(messageHash, m.token, m.receiver, m.amount);
    }
}

这份代码里，为什么这样写？

1. `targetBridge == address(this)`

防止同一条签名消息被拿到别的桥合约上执行。

2. `targetChainId == block.chainid`

防止跨链消息被带到错误链上重放。

3. `executed[messageHash]`

防止重复执行，同一个消息只能处理一次。

4. `signer > lastSigner`

这是一个很实用的小技巧：要求签名地址按升序提交，避免同一个签名者重复计数。

我第一次审跨链相关代码时，就见过“统计签名数但不去重”的问题，看起来门限是 3/5，实际上一个签名者提交三次就过了。

3）Hardhat 测试代码

test/SimpleBridge.js

const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("SimpleBridge", function () {
  async function signMessage(bridge, message, signer) {
    const hash = await bridge.getMessageHash(message);
    const sig = await signer.signMessage(ethers.getBytes(hash));
    return sig;
  }

  it("should execute bridge transfer with valid signatures", async function () {
    const [owner, user, v1, v2, v3] = await ethers.getSigners();

    const Token = await ethers.getContractFactory("TestToken");
    const token = await Token.deploy();
    await token.waitForDeployment();

    const Bridge = await ethers.getContractFactory("SimpleBridge");
    const bridge = await Bridge.deploy(
      [v1.address, v2.address, v3.address],
      2
    );
    await bridge.waitForDeployment();

    await token.transfer(await bridge.getAddress(), ethers.parseEther("1000"));

    const message = {
      sourceChainId: 1,
      targetChainId: await ethers.provider.getNetwork().then(n => Number(n.chainId)),
      sourceBridge: owner.address,
      targetBridge: await bridge.getAddress(),
      token: await token.getAddress(),
      receiver: user.address,
      amount: ethers.parseEther("10"),
      nonce: 1
    };

    const sig1 = await signMessage(bridge, message, v1);
    const sig2 = await signMessage(bridge, message, v2);

    const ordered = [v1.address, v2.address].sort();
    const sigs = ordered[0] === v1.address ? [sig1, sig2] : [sig2, sig1];

    await bridge.execute(message, sigs);

    expect(await token.balanceOf(user.address)).to.equal(ethers.parseEther("10"));
  });

  it("should prevent replay", async function () {
    const [owner, user, v1, v2, v3] = await ethers.getSigners();

    const Token = await ethers.getContractFactory("TestToken");
    const token = await Token.deploy();
    await token.waitForDeployment();

    const Bridge = await ethers.getContractFactory("SimpleBridge");
    const bridge = await Bridge.deploy(
      [v1.address, v2.address, v3.address],
      2
    );
    await bridge.waitForDeployment();

    await token.transfer(await bridge.getAddress(), ethers.parseEther("1000"));

    const message = {
      sourceChainId: 1,
      targetChainId: await ethers.provider.getNetwork().then(n => Number(n.chainId)),
      sourceBridge: owner.address,
      targetBridge: await bridge.getAddress(),
      token: await token.getAddress(),
      receiver: user.address,
      amount: ethers.parseEther("10"),
      nonce: 1
    };

    const sig1 = await signMessage(bridge, message, v1);
    const sig2 = await signMessage(bridge, message, v2);

    const ordered = [v1.address, v2.address].sort();
    const sigs = ordered[0] === v1.address ? [sig1, sig2] : [sig2, sig1];

    await bridge.execute(message, sigs);

    await expect(
      bridge.execute(message, sigs)
    ).to.be.revertedWith("already executed");
  });
});

运行测试

npx hardhat test

审计视角：跨链桥最常见攻击面分析

下面进入最关键的部分：站在攻击者视角看桥。

1. 重放攻击

问题表现

同一条跨链消息被多次执行，或者在别的链/别的桥合约上执行。

成因

消息签名字段不完整，比如没绑定：

目标链 ID
目标桥地址
nonce

错误示例

function badHash(address receiver, uint256 amount) public pure returns (bytes32) {
    return keccak256(abi.encode(receiver, amount));
}

这种写法几乎等于邀请别人重放。

正确思路

消息必须具备上下文绑定：

谁发来的
发往哪条链
发往哪个桥
第几笔消息

2. 签名计数绕过

问题表现

看起来需要 3 个验证者，但实际上 1 个验证者重复提交签名也能过。

成因

没有检查签名者唯一性。

排查点

如果你在代码里看到类似逻辑，就要警惕：

for (...) {
    if (validators[signer]) {
        count++;
    }
}

这段逻辑没有去重，极危险。

防护

对签名者地址排序并去重
或使用 mapping(address => bool) 临时记录已计数签名者

3. 权限中心化过重

很多桥项目的问题不是“黑客太强”，而是“管理员太万能”。

比如：

owner 可以直接替换验证者集合；
owner 可以把 threshold 改成 1；
owner 可以直接提走桥里资产；
owner 可以升级到恶意实现。

审计建议

把以下权限逐项列出来：

谁能改验证者
谁能改门限
谁能暂停
谁能升级
谁能提取资金

如果这些能力都在单个 EOA 上，那系统风险非常高。

更稳妥的做法

管理权限放进多签钱包
敏感操作加 timelock
高危参数变更设置延迟生效
资金提取和参数治理分离

4. ERC20 兼容性问题

桥合约最爱碰到“奇怪的代币”。

常见坑

transfer 不返回 bool
手续费代币，实际到账金额少于转账金额
Rebase 代币余额会变
黑名单代币会拒绝转账
精度不是 18 位

防护建议

一律使用 SafeERC20
不假设 amount == 实际到账
对特殊代币建立白名单或单独适配
桥协议层不要轻易支持所有 ERC20

我实际踩过一个坑：桥逻辑按“用户存了 100 就记 100”，结果代币是 fee-on-transfer，到桥里实际只进了 98，后面目标链照样放 100，金库很快就被搬空。

5. 重入攻击

虽然跨链桥多数问题集中在验证逻辑，但资产释放时仍然可能被重入。

典型风险点

先转账，后标记已执行
向不可信合约地址回调
同时支持 ERC777 或自定义 token hook

错误顺序

IERC20(token).transfer(receiver, amount);
executed[messageHash] = true;

正确顺序

先检查
再更新状态
最后外部调用

也就是标准的 Checks-Effects-Interactions。

6. 升级代理存储冲突

如果桥用的是可升级代理，问题会再多一层。

风险

新实现改坏 storage layout
初始化函数可被重复调用
升级权限被盗
代理指向恶意实现

排查建议

看是否用了 initializer
看是否禁用了实现合约初始化
看 upgrade 权限是不是多签
看 storage slot 是否规范

状态机视角：消息处理流程

stateDiagram-v2
    [*] --> Created
    Created --> Signed: 验证者签名
    Signed --> Submitted: 提交到目标链
    Submitted --> Executed: 验签通过并转账
    Submitted --> Rejected: 验签失败/参数错误
    Executed --> [*]
    Rejected --> [*]

合约审计清单：我建议你按这个顺序看

这一段非常实用，适合你以后拿任意桥项目做初筛。

一、信任模型

先问三个问题：

谁决定一条跨链消息为真？
这个“谁”能否串通？
如果它作恶，链上有没有纠错机制？

如果答案是“5 个验证者签名，3 个就能通过，而且没有挑战期”，那你已经知道核心风险在验证者层了。

二、消息唯一性

检查是否绑定：

chainId
bridge address
nonce
token
receiver
amount

三、验签实现

检查：

是否使用正确的消息哈希
是否防签名重复计数
是否区分 eth_sign 与 EIP-712
是否存在 malleability 风险
是否严格校验门限

四、状态更新顺序

检查：

是否先标记 executed 再转账
是否有可重入入口
是否可重复处理失败消息

五、权限与升级

检查：

owner 是否过大
是否使用多签治理
是否有 pause
pause 是否会冻结用户赎回
升级是否有延迟与审计流程

六、资产兼容性

检查：

是否支持 fee-on-transfer
是否支持黑名单 token
是否处理 decimals 差异
是否有资产白名单

常见坑与排查

下面给一组“现象 -> 定位 -> 解决”的排查方式，比较接近真实开发现场。

坑 1：签名明明是对的，合约却报 `invalid signer`

常见原因

链下签的是 abi.encodePacked，链上验的是 abi.encode
链下签的是原始哈希，链上恢复时用了 toEthSignedMessageHash
签名提交顺序不符合合约要求
验证者地址不是合约里登记的地址

排查方法

先在链下和链上分别打印 hash：

const hash = await bridge.getMessageHash(message);
console.log("hash:", hash);

然后确认链下用的是：

await signer.signMessage(ethers.getBytes(hash));

如果你改成了 EIP-712，那链上恢复逻辑也必须同步改掉，不能一边 eth_sign 一边按 typed data 验。

坑 2：测试环境通过，主网上转账失败

常见原因

代币是手续费代币
代币做了黑名单限制
代币 decimals 与预期不一致
桥里余额不足

排查方法

重点检查桥合约转账前后的余额变化：

uint256 beforeBal = IERC20(m.token).balanceOf(address(this));
IERC20(m.token).safeTransfer(m.receiver, m.amount);
uint256 afterBal = IERC20(m.token).balanceOf(address(this));

如果是 fee-on-transfer 模型，就不能简单假设桥的会计逻辑和 nominal amount 一致。

坑 3：门限参数设置错误导致“假安全”

现象

合约部署时是 5 个验证者、门限 3，看起来没问题；但后续 owner 删除了两个验证者，threshold 还是 3，系统直接不可用；或者反过来，threshold 被改成 1，系统近乎裸奔。

排查方法

检查参数变更是否有约束：

function setThreshold(uint256 _threshold) external onlyOwner {
    require(_threshold > 0, "threshold 0");
    threshold = _threshold;
}

上面这段其实还不够安全，因为它没校验“当前活跃验证者数量”。

建议改进

维护活跃验证者计数
要求 threshold <= activeValidatorCount
参数修改走多签 + timelock

安全/性能最佳实践

这一节尽量只讲“能落地”的。

1. 从 `eth_sign` 升级到 EIP-712

示例里为了易跑用了 signMessage。但生产环境更推荐 EIP-712 Typed Data，原因是：

可读性更好
域隔离更强
能减少签错消息的概率

尤其跨链消息这种高价值场景，强烈建议做结构化签名。

2. 验证逻辑与资金托管逻辑分层

不要把所有能力都堆在一个大合约里。更稳妥的结构是：

Verifier：专门验消息和签名
Vault：专门托管与释放资金
Governance：专门管理参数和权限

这样做的好处很现实：

审计更聚焦
升级影响范围更小
权限分离更清晰

3. 对高风险操作启用暂停，但别把用户出口也堵死

pause 很重要，但设计不好就会变成“双输”：

能暂停攻击，同时也暂停了正常赎回
用户资产被困在桥里

更好的思路是区分：

暂停新入金
保留受控出金或紧急赎回通道

边界条件要写清楚：一旦验证层出问题，哪些通道还可用，谁能触发，多久生效。

4. 加监控，而不是只靠审计

桥不是“审一次就完了”的系统。建议至少监控：

单笔大额出金
同 nonce 重复提交
threshold / validator 变更
短时连续出金
升级事件
owner 权限操作

很多事故不是没有预警，而是没有把链上异常变成可执行告警。

5. 对验证者做运维级安全加固

这是很多智能合约开发者容易忽略的点：桥的安全上限往往不是 Solidity，而是私钥管理。

建议：

验证者私钥放 HSM 或 MPC
不要用单机热钱包
签名节点隔离部署
不同地理区域和云厂商分散
设置签名频率与额度风控

如果验证者私钥被批量拿下，链上代码再漂亮也救不回来。

6. 引入速率限制和额度上限

对桥来说，这是非常实用的“止血器”：

单笔最大出金
单日总出金上限
新资产初始额度较低
大额消息需要更高门限

这类机制不能根治漏洞，但能显著降低爆炸半径。

逐步验证清单

如果你正在开发或审计一个桥，我建议照这个 checklist 走一遍：

合约层

消息哈希包含 chainId、bridge、nonce、token、amount、receiver
消息执行有唯一标识，且不可重放
签名者去重
threshold 与活跃验证者数量一致
外部调用前已更新状态
使用 SafeERC20
高危函数受多签控制
升级逻辑有初始化保护

协议层

运维层

验证者私钥管理是否合规
是否有轮换机制
是否有应急预案
是否定期做演练

一个更真实的防护落地方案

如果你不是做 demo，而是真要上生产，我建议最低配也要做到下面这套：

最低可接受方案

链上
- EIP-712 验签
- nonce 防重放
- 多签门限校验
- pause + rate limit
- 资产白名单
- 多签治理 owner
链下
- 验证者分散部署
- 签名节点权限隔离
- 告警系统
- 手工审核大额跨链
流程
- 上线前审计
- 重大升级复审
- 漏洞赏金
- 应急冻结预案

如果资产规模较大，再往上加

轻客户端验证或更强证明机制
MPC / TEE / HSM
形式化验证关键模块
分层风控和熔断机制

总结

跨链桥安全的难点，不在某一个“神奇漏洞”，而在它把多种风险叠在了一起：签名验证、状态同步、资产托管、权限治理、链下运维，每层都可能出问题。

如果你要抓重点，我建议记住这 5 条：

消息必须绑定上下文：链 ID、桥地址、nonce 一个都不能少；
验签必须防重复计数：门限系统最怕“伪多签”；
状态先更新再转账：防重入、防重复执行；
权限不能只靠单个 owner：多签、延迟、生效窗口都要有；
桥的安全是系统工程：合约审计只是底线，不是终点。

最后给一个很务实的建议：如果你的桥还处在早期，不要一开始就追求“支持所有资产、所有链、所有场景”。先把资产范围缩小、额度控住、验证路径收敛，再逐步扩展。桥最怕的不是功能少，而是在信任边界还没搞清楚时托管了太多钱。

如果你照着本文的示例和清单去看项目代码，已经能完成一轮相当靠谱的跨链桥安全初筛了。

《区块链跨链桥安全实战：从常见攻击面分析到合约审计与防护方案落地》

区块链跨链桥安全实战：从常见攻击面分析到合约审计与防护方案落地

背景与问题

为什么跨链桥这么容易出事？

常见安全事故的共性

前置知识

环境准备

目录初始化

安装 OpenZeppelin

核心原理

一个简化跨链桥的工作流

跨链消息最小安全字段

架构图：跨链桥的最小可信流

时序图：一次安全的跨链执行

实战代码（可运行）

1）测试代币合约

2）桥合约

这份代码里，为什么这样写？

1. targetBridge == address(this)

2. targetChainId == block.chainid

3. executed[messageHash]

4. signer > lastSigner

3）Hardhat 测试代码

运行测试

审计视角：跨链桥最常见攻击面分析

1. 重放攻击

问题表现

成因

错误示例

正确思路

2. 签名计数绕过

问题表现

成因

排查点

防护

3. 权限中心化过重

审计建议

更稳妥的做法

4. ERC20 兼容性问题

常见坑

防护建议

5. 重入攻击

典型风险点

错误顺序

正确顺序

6. 升级代理存储冲突

风险

排查建议

状态机视角：消息处理流程

合约审计清单：我建议你按这个顺序看

一、信任模型

二、消息唯一性

三、验签实现

四、状态更新顺序

五、权限与升级

六、资产兼容性

常见坑与排查

坑 1：签名明明是对的，合约却报 invalid signer

常见原因

排查方法

坑 2：测试环境通过，主网上转账失败

常见原因

排查方法

坑 3：门限参数设置错误导致“假安全”

现象

排查方法

建议改进

安全/性能最佳实践

1. 从 eth_sign 升级到 EIP-712

2. 验证逻辑与资金托管逻辑分层

3. 对高风险操作启用暂停，但别把用户出口也堵死

4. 加监控，而不是只靠审计

5. 对验证者做运维级安全加固

6. 引入速率限制和额度上限

逐步验证清单

合约层

协议层

运维层

一个更真实的防护落地方案

最低可接受方案

1. `targetBridge == address(this)`

2. `targetChainId == block.chainid`

3. `executed[messageHash]`

4. `signer > lastSigner`

坑 1：签名明明是对的，合约却报 `invalid signer`

1. 从 `eth_sign` 升级到 EIP-712