2
月
在社区成长 2 月
LEVEL 1
1 XP
一、背景：钱包安全不只等于保管助记词
在以太坊及其他 EVM 兼容链上，资产损失并不一定源于私钥泄露。更常见的风险边界是：用户仍然控制私钥，却签署了超出预期的授权、向错误网络上的同名地址转账、与可升级但权限不透明的代理合约交互，或者把普通消息签名误认为无资产影响。
本文给出一套可复核的链上交互检查流程，重点覆盖地址与网络确认、合约字节码识别、代理与管理权限排查、ERC-20 授权分析、交易模拟、事件核验和授权回收。所有命令仅用于公开链上数据查询、本地 Anvil 实验或本人控制的钱包，不涉及对真实目标的攻击。本文也不构成投资建议，结论仅针对能被链上数据和本地测试支持的技术事实。
二、核心原理
1. 私钥签名与交易执行是两个阶段
钱包签名只能证明某个账户同意了一段确定的数据。交易是否成功、最终调用哪个逻辑、会修改哪些状态，则由链 ID、目标地址、calldata、账户 nonce、当前合约状态以及 EVM 执行结果共同决定。因此，看到钱包界面显示“签名”并不代表操作无风险。
2. ERC-20 授权不是转账
approve(spender, amount) 会在代币合约中写入 allowance。获得额度的 spender 之后可以调用 transferFrom，在额度和余额允许的范围内转走代币。无限授权通常使用 uint256 最大值，便利性较高，但会扩大 spender 私钥泄露、合约升级或逻辑缺陷所造成的影响范围。
3. 代理地址与实现合约需要同时检查
常见代理模式把用户交互入口与实际逻辑分离。代理通过 delegatecall 执行实现合约代码，但状态保存在代理地址。只检查代理源码、只检查实现源码，或者忽略管理员能否升级，都不足以形成完整结论。风险判断至少应包含代理类型、当前实现地址、升级管理员、升级延迟、多签门槛以及历史升级事件。
4. 链上数据可验证，但页面标签未必可信
区块浏览器标签、代币名称和前端展示可被仿冒。地址、链 ID、运行时代码、交易输入、日志、余额变化和存储槽才是更稳定的核验对象。即便源码已验证，也只能说明公开源码与特定字节码之间存在可比对关系，不能自动证明业务逻辑安全。
三、前置条件
建议在隔离的测试账户中准备以下工具：
（1）Foundry 工具集，包括 anvil、cast 和 forge；
（2）可信 RPC，敏感项目可同时准备两个独立提供方进行交叉查询；
（3）区块浏览器，但不要把浏览器标签作为唯一证据；
（4）只存放测试资产的新钱包；
（5）待检查的链 ID、目标合约地址、代币地址和预期操作说明。
安装 Foundry 后可执行：
foundryup
anvil
Anvil 默认在 http://127.0.0.1:8545 启动本地链，并提供仅用于本地测试的预置账户。不要向这些公开测试私钥转入真实资产。
四、分步骤实践
步骤一：先固定网络和目标地址
查询当前 RPC 对应的链 ID：
cast chain-id --rpc-url https://你的可信rpc
再读取目标地址的原生币余额与代码：
cast balance 0x目标地址 --rpc-url https://你的可信rpc
cast code 0x目标地址 --rpc-url https://你的可信rpc
若 cast code 返回 0x，通常表示该地址在当前区块没有合约代码，但不能仅凭这一点认定其一直是普通外部账户：地址可能曾经存在代码，或交易可能部署并调用新合约。对于日常转账，至少应确认链 ID、完整地址、资产合约地址和小数位数，不要只核对地址首尾几位。
步骤二：核对代币基本字段，防止同名资产混淆
以标准 ERC-20 为例：
cast call 0x代币地址 "name()(string)" --rpc-url https://你的可信rpc
cast call 0x代币地址 "symbol()(string)" --rpc-url https://你的可信rpc
cast call 0x代币地址 "decimals()(uint8)" --rpc-url https://你的可信rpc
cast call 0x代币地址 "totalSupply()(uint256)" --rpc-url https://你的可信rpc
名称和符号可以重复，真正的资产标识应包含链 ID 与合约地址。decimals 只是显示精度，不代表价格或价值。对非标准代币，上述调用可能回退或返回异常编码，需要结合源码和实际 ABI 判断。
步骤三：检查现有授权额度
查询某个钱包对 spender 的授权：
cast call 0x代币地址 "allowance(address,address)(uint256)" 0x钱包地址 0xSpender地址 --rpc-url https://你的可信rpc
将返回值与实际业务所需额度比较。如果业务只需要使用 100 个单位，却要求最大整数额度，应将其记录为权限过宽，而不是直接断言存在恶意。可验证结论应写成：“该 spender 当前可在余额与 allowance 的共同约束内调用 transferFrom；是否会执行取决于 spender 合约逻辑及其控制权限。”
对不再使用的 spender，可把额度设置为零。标准接口的编码如下：
cast calldata "approve(address,uint256)" 0xSpender地址 0
实际发送前，应在钱包中再次确认交易目标是代币合约，而不是 spender。部分历史代币要求先归零再设置新额度；部分代币可能存在手续费、黑名单或非标准返回值，不能机械套用标准 ERC-20 假设。
步骤四：识别代理与升级权限
EIP-1967 实现地址槽为：
0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
可读取代理存储：
cast storage 0x代理地址 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url https://你的可信rpc
结果通常是左侧补零的 32 字节值，最后 20 字节可能是实现地址。随后对实现地址执行 cast code，并在浏览器中检查源码、编译器版本及部署交易。需要注意：存储槽非零并不能单独证明一定采用标准 EIP-1967；透明代理、UUPS、Beacon、Diamond 和自定义代理的控制面不同，应结合运行时代码、调用路径和事件分析。
重点关注以下问题：谁能升级；管理员是单签还是多签；多签阈值是多少；是否存在时间锁；能否暂停；能否任意增发；能否转移用户资产；初始化函数是否已锁定；管理员变更和升级事件是否连续。若无法核实权限主体，应明确写为“权限归属未完成验证”，而不是猜测安全或恶意。
步骤五：在本地分叉环境模拟交易
不要用主钱包直接试错。可以在得到授权的前提下，用公开状态创建本地分叉：
anvil --fork-url https://你的可信rpc --fork-block-number 已确认的区块号
固定区块号可以提高复现性。随后使用本地 RPC 读取状态：
cast call 0x目标合约 "某个只读函数签名" --rpc-url http://127.0.0.1:8545
发送状态变更交易时，仅使用 Anvil 预置测试账户，或者导入专门用于实验且没有真实资产的私钥。不要在命令历史中写入真实主钱包私钥。测试应记录区块号、链 ID、目标地址、calldata、调用者、返回值、日志和余额差异。
步骤六：先解码，再签名
交易 calldata 的前 4 字节是函数选择器，其余部分通常是 ABI 编码参数。若已知 ABI，可使用：
cast calldata "approve(address,uint256)" 0xSpender地址 1000000
cast 4byte 0x函数选择器
四字节数据库只能提供候选签名，不是证明，因为不同函数签名可能发生选择器碰撞。可靠做法是将候选 ABI 与已验证源码、实际字节码行为和本地模拟结果交叉核对。
对于 EIP-712 签名，应检查 domain 中的 name、version、chainId 和 verifyingContract，并逐项核对 message 字段。Permit、Permit2、订单签名和委托签名可能允许第三方在之后提交链上交易。“无需 Gas 的签名”不等于“没有资产权限变化”。
步骤七：交易后核验结果
广播交易后不要只看前端“成功”提示。应核对交易收据状态、实际调用地址、事件日志、资产余额、NFT 所有权和 allowance。示例：
cast receipt 0x交易哈希 --rpc-url https://你的可信rpc
cast call 0x代币地址 "balanceOf(address)(uint256)" 0x钱包地址 --rpc-url https://你的可信rpc
cast call 0x代币地址 "allowance(address,address)(uint256)" 0x钱包地址 0xSpender地址 --rpc-url https://你的可信rpc
需要区分交易成功与业务成功：某些合约可能捕获内部调用失败并继续执行，最终收据状态仍为成功。此时必须结合日志、调用轨迹和状态差异判断。
五、防御性示例：最小额度原则
假设某协议一次操作最多需要 50 USDC，USDC 在目标链上的 decimals 经核验为 6，则理论所需原始额度为 50 × 10^6。更稳妥的流程是：先确认官方合约地址和 chainId；读取当前 allowance；仅批准本次所需额度；执行操作；再次读取 allowance；若协议不会自动消耗至零，则主动撤销剩余额度。
这里的风险结论有明确边界：有限额度可以降低单个 spender 可转出的上限，但无法防止代币自身的管理员权限、钱包私钥泄露、错误接收地址或恶意签名等其他风险。
六、风险与注意事项
1. RPC 可返回错误或滞后的数据，重要查询应固定区块并使用第二个独立 RPC 复核。
2. 区块浏览器的源码验证不能替代审计；审计报告也只覆盖特定提交、部署地址和时间范围。
3. 合约升级会使旧结论失效。应监控 Upgraded、AdminChanged、OwnershipTransferred、RoleGranted 等事件。
4. 不要把助记词、私钥或完整签名请求粘贴到陌生网站。硬件钱包也无法替用户判断业务语义。
5. 小额试转只能降低单次金额风险，不能证明后续交易安全，也无法识别无限授权的长期风险。
6. 授权回收交易本身也需要确认代币地址、spender 和链 ID，避免在钓鱼页面执行伪造的“撤销”。
7. 跨链资产还需要额外评估桥接合约、验证者集合、消息验证机制、封装资产发行权限和目标链流动性；不能只检查源链交易。
七、常见问题
问：钱包显示“合约已验证”，是否可以直接交互？
答：不可以。已验证通常只表示源码可以与链上字节码进行匹配，还需要检查代理实现、初始化状态、管理员权限、外部依赖和具体调用参数。
问：撤销 allowance 后是否绝对安全？
答：只能消除该代币、该 owner 与该 spender 组合下的后续 transferFrom 额度。已经转出的资产无法因此追回，其他代币授权、NFT operator 授权、Permit2 授权和离线签名也不会自动失效。
问：无限授权一定是漏洞吗？
答：不是。它是一种权限与便利性的权衡，但会放大 spender 被攻破、升级失控或逻辑缺陷的后果。审计时应结合资金规模、spender 权限、升级机制和用户退出路径评估。
问：交易模拟成功，主网执行就一定成功吗？
答：不一定。模拟之后的状态变化、抢跑、滑点、区块时间、预言机更新、nonce 变化和 RPC 差异都可能改变结果。模拟是降低不确定性的证据之一，不是最终保证。
问：如何判断一个地址是不是官方地址？
答：应从多个独立来源交叉核验，包括项目正式文档、经过验证的发布渠道、部署交易和链上治理记录。搜索结果、私信链接、代币名称与浏览器标签均不能单独作为依据。
八、总结
一套可靠的钱包交互流程应当遵循“先固定网络和地址，再理解权限与调用，随后模拟，最后核验状态”的顺序。对 ERC-20 授权采用最小额度和及时回收原则；对代理合约同时审查实现、管理员和升级路径；对签名请求检查结构化数据及实际授权含义；对重要结论保留链 ID、区块号、地址、字节码和查询命令，以便第三方复现。
安全判断应避免“看起来正规”或“以前用过没问题”这类不可验证依据。更严谨的表达是说明已验证的事实、尚未验证的权限，以及结论适用的时间和链上状态边界。
在以太坊及其他 EVM 兼容链上，资产损失并不一定源于私钥泄露。更常见的风险边界是：用户仍然控制私钥，却签署了超出预期的授权、向错误网络上的同名地址转账、与可升级但权限不透明的代理合约交互，或者把普通消息签名误认为无资产影响。
本文给出一套可复核的链上交互检查流程，重点覆盖地址与网络确认、合约字节码识别、代理与管理权限排查、ERC-20 授权分析、交易模拟、事件核验和授权回收。所有命令仅用于公开链上数据查询、本地 Anvil 实验或本人控制的钱包，不涉及对真实目标的攻击。本文也不构成投资建议，结论仅针对能被链上数据和本地测试支持的技术事实。
二、核心原理
1. 私钥签名与交易执行是两个阶段
钱包签名只能证明某个账户同意了一段确定的数据。交易是否成功、最终调用哪个逻辑、会修改哪些状态，则由链 ID、目标地址、calldata、账户 nonce、当前合约状态以及 EVM 执行结果共同决定。因此，看到钱包界面显示“签名”并不代表操作无风险。
2. ERC-20 授权不是转账
approve(spender, amount) 会在代币合约中写入 allowance。获得额度的 spender 之后可以调用 transferFrom，在额度和余额允许的范围内转走代币。无限授权通常使用 uint256 最大值，便利性较高，但会扩大 spender 私钥泄露、合约升级或逻辑缺陷所造成的影响范围。
3. 代理地址与实现合约需要同时检查
常见代理模式把用户交互入口与实际逻辑分离。代理通过 delegatecall 执行实现合约代码，但状态保存在代理地址。只检查代理源码、只检查实现源码，或者忽略管理员能否升级，都不足以形成完整结论。风险判断至少应包含代理类型、当前实现地址、升级管理员、升级延迟、多签门槛以及历史升级事件。
4. 链上数据可验证，但页面标签未必可信
区块浏览器标签、代币名称和前端展示可被仿冒。地址、链 ID、运行时代码、交易输入、日志、余额变化和存储槽才是更稳定的核验对象。即便源码已验证，也只能说明公开源码与特定字节码之间存在可比对关系，不能自动证明业务逻辑安全。
三、前置条件
建议在隔离的测试账户中准备以下工具：
（1）Foundry 工具集，包括 anvil、cast 和 forge；
（2）可信 RPC，敏感项目可同时准备两个独立提供方进行交叉查询；
（3）区块浏览器，但不要把浏览器标签作为唯一证据；
（4）只存放测试资产的新钱包；
（5）待检查的链 ID、目标合约地址、代币地址和预期操作说明。
安装 Foundry 后可执行：
foundryup
anvil
Anvil 默认在 http://127.0.0.1:8545 启动本地链，并提供仅用于本地测试的预置账户。不要向这些公开测试私钥转入真实资产。
四、分步骤实践
步骤一：先固定网络和目标地址
查询当前 RPC 对应的链 ID：
cast chain-id --rpc-url https://你的可信rpc
再读取目标地址的原生币余额与代码：
cast balance 0x目标地址 --rpc-url https://你的可信rpc
cast code 0x目标地址 --rpc-url https://你的可信rpc
若 cast code 返回 0x，通常表示该地址在当前区块没有合约代码，但不能仅凭这一点认定其一直是普通外部账户：地址可能曾经存在代码，或交易可能部署并调用新合约。对于日常转账，至少应确认链 ID、完整地址、资产合约地址和小数位数，不要只核对地址首尾几位。
步骤二：核对代币基本字段，防止同名资产混淆
以标准 ERC-20 为例：
cast call 0x代币地址 "name()(string)" --rpc-url https://你的可信rpc
cast call 0x代币地址 "symbol()(string)" --rpc-url https://你的可信rpc
cast call 0x代币地址 "decimals()(uint8)" --rpc-url https://你的可信rpc
cast call 0x代币地址 "totalSupply()(uint256)" --rpc-url https://你的可信rpc
名称和符号可以重复，真正的资产标识应包含链 ID 与合约地址。decimals 只是显示精度，不代表价格或价值。对非标准代币，上述调用可能回退或返回异常编码，需要结合源码和实际 ABI 判断。
步骤三：检查现有授权额度
查询某个钱包对 spender 的授权：
cast call 0x代币地址 "allowance(address,address)(uint256)" 0x钱包地址 0xSpender地址 --rpc-url https://你的可信rpc
将返回值与实际业务所需额度比较。如果业务只需要使用 100 个单位，却要求最大整数额度，应将其记录为权限过宽，而不是直接断言存在恶意。可验证结论应写成：“该 spender 当前可在余额与 allowance 的共同约束内调用 transferFrom；是否会执行取决于 spender 合约逻辑及其控制权限。”
对不再使用的 spender，可把额度设置为零。标准接口的编码如下：
cast calldata "approve(address,uint256)" 0xSpender地址 0
实际发送前，应在钱包中再次确认交易目标是代币合约，而不是 spender。部分历史代币要求先归零再设置新额度；部分代币可能存在手续费、黑名单或非标准返回值，不能机械套用标准 ERC-20 假设。
步骤四：识别代理与升级权限
EIP-1967 实现地址槽为：
0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
可读取代理存储：
cast storage 0x代理地址 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url https://你的可信rpc
结果通常是左侧补零的 32 字节值，最后 20 字节可能是实现地址。随后对实现地址执行 cast code，并在浏览器中检查源码、编译器版本及部署交易。需要注意：存储槽非零并不能单独证明一定采用标准 EIP-1967；透明代理、UUPS、Beacon、Diamond 和自定义代理的控制面不同，应结合运行时代码、调用路径和事件分析。
重点关注以下问题：谁能升级；管理员是单签还是多签；多签阈值是多少；是否存在时间锁；能否暂停；能否任意增发；能否转移用户资产；初始化函数是否已锁定；管理员变更和升级事件是否连续。若无法核实权限主体，应明确写为“权限归属未完成验证”，而不是猜测安全或恶意。
步骤五：在本地分叉环境模拟交易
不要用主钱包直接试错。可以在得到授权的前提下，用公开状态创建本地分叉：
anvil --fork-url https://你的可信rpc --fork-block-number 已确认的区块号
固定区块号可以提高复现性。随后使用本地 RPC 读取状态：
cast call 0x目标合约 "某个只读函数签名" --rpc-url http://127.0.0.1:8545
发送状态变更交易时，仅使用 Anvil 预置测试账户，或者导入专门用于实验且没有真实资产的私钥。不要在命令历史中写入真实主钱包私钥。测试应记录区块号、链 ID、目标地址、calldata、调用者、返回值、日志和余额差异。
步骤六：先解码，再签名
交易 calldata 的前 4 字节是函数选择器，其余部分通常是 ABI 编码参数。若已知 ABI，可使用：
cast calldata "approve(address,uint256)" 0xSpender地址 1000000
cast 4byte 0x函数选择器
四字节数据库只能提供候选签名，不是证明，因为不同函数签名可能发生选择器碰撞。可靠做法是将候选 ABI 与已验证源码、实际字节码行为和本地模拟结果交叉核对。
对于 EIP-712 签名，应检查 domain 中的 name、version、chainId 和 verifyingContract，并逐项核对 message 字段。Permit、Permit2、订单签名和委托签名可能允许第三方在之后提交链上交易。“无需 Gas 的签名”不等于“没有资产权限变化”。
步骤七：交易后核验结果
广播交易后不要只看前端“成功”提示。应核对交易收据状态、实际调用地址、事件日志、资产余额、NFT 所有权和 allowance。示例：
cast receipt 0x交易哈希 --rpc-url https://你的可信rpc
cast call 0x代币地址 "balanceOf(address)(uint256)" 0x钱包地址 --rpc-url https://你的可信rpc
cast call 0x代币地址 "allowance(address,address)(uint256)" 0x钱包地址 0xSpender地址 --rpc-url https://你的可信rpc
需要区分交易成功与业务成功：某些合约可能捕获内部调用失败并继续执行，最终收据状态仍为成功。此时必须结合日志、调用轨迹和状态差异判断。
五、防御性示例：最小额度原则
假设某协议一次操作最多需要 50 USDC，USDC 在目标链上的 decimals 经核验为 6，则理论所需原始额度为 50 × 10^6。更稳妥的流程是：先确认官方合约地址和 chainId；读取当前 allowance；仅批准本次所需额度；执行操作；再次读取 allowance；若协议不会自动消耗至零，则主动撤销剩余额度。
这里的风险结论有明确边界：有限额度可以降低单个 spender 可转出的上限，但无法防止代币自身的管理员权限、钱包私钥泄露、错误接收地址或恶意签名等其他风险。
六、风险与注意事项
1. RPC 可返回错误或滞后的数据，重要查询应固定区块并使用第二个独立 RPC 复核。
2. 区块浏览器的源码验证不能替代审计；审计报告也只覆盖特定提交、部署地址和时间范围。
3. 合约升级会使旧结论失效。应监控 Upgraded、AdminChanged、OwnershipTransferred、RoleGranted 等事件。
4. 不要把助记词、私钥或完整签名请求粘贴到陌生网站。硬件钱包也无法替用户判断业务语义。
5. 小额试转只能降低单次金额风险，不能证明后续交易安全，也无法识别无限授权的长期风险。
6. 授权回收交易本身也需要确认代币地址、spender 和链 ID，避免在钓鱼页面执行伪造的“撤销”。
7. 跨链资产还需要额外评估桥接合约、验证者集合、消息验证机制、封装资产发行权限和目标链流动性；不能只检查源链交易。
七、常见问题
问：钱包显示“合约已验证”，是否可以直接交互？
答：不可以。已验证通常只表示源码可以与链上字节码进行匹配，还需要检查代理实现、初始化状态、管理员权限、外部依赖和具体调用参数。
问：撤销 allowance 后是否绝对安全？
答：只能消除该代币、该 owner 与该 spender 组合下的后续 transferFrom 额度。已经转出的资产无法因此追回，其他代币授权、NFT operator 授权、Permit2 授权和离线签名也不会自动失效。
问：无限授权一定是漏洞吗？
答：不是。它是一种权限与便利性的权衡，但会放大 spender 被攻破、升级失控或逻辑缺陷的后果。审计时应结合资金规模、spender 权限、升级机制和用户退出路径评估。
问：交易模拟成功，主网执行就一定成功吗？
答：不一定。模拟之后的状态变化、抢跑、滑点、区块时间、预言机更新、nonce 变化和 RPC 差异都可能改变结果。模拟是降低不确定性的证据之一，不是最终保证。
问：如何判断一个地址是不是官方地址？
答：应从多个独立来源交叉核验，包括项目正式文档、经过验证的发布渠道、部署交易和链上治理记录。搜索结果、私信链接、代币名称与浏览器标签均不能单独作为依据。
八、总结
一套可靠的钱包交互流程应当遵循“先固定网络和地址，再理解权限与调用，随后模拟，最后核验状态”的顺序。对 ERC-20 授权采用最小额度和及时回收原则；对代理合约同时审查实现、管理员和升级路径；对签名请求检查结构化数据及实际授权含义；对重要结论保留链 ID、区块号、地址、字节码和查询命令，以便第三方复现。
安全判断应避免“看起来正规”或“以前用过没问题”这类不可验证依据。更严谨的表达是说明已验证的事实、尚未验证的权限，以及结论适用的时间和链上状态边界。