1
月
在社区成长 1 月
LEVEL 1
1 XP
一、背景：为什么“看起来正常”的交易也可能有风险
加密货币转账通常不可逆，用户一旦签署并广播交易，资产是否能够追回往往不再取决于客服或平台，而取决于目标地址是否仍可控、私钥是否安全以及链上规则是否允许撤销。现实中的风险并不只有私钥泄露，还包括地址投毒、恶意授权、网络或代币识别错误、假冒空投、钓鱼签名和跨链桥误操作等。
本文以以太坊兼容链为主要示例，目标不是预测价格，也不是推荐任何资产，而是建立一个可复用的交易核验流程：在签名之前确认“给谁、给什么、给多少、通过什么合约执行”；在广播之后确认“交易是否真的上链、状态是否成功、资产是否发生异常变化”。比特币等 UTXO 模型链在交易结构上不同，但“核对网络、核对地址、保留证据、最小权限操作”的原则同样适用。
二、原理：一笔链上操作究竟包含什么
1. 原生资产转账。以太坊中的 ETH 转账通常由发送地址、接收地址、value、nonce、gas 参数和签名组成。普通转账的 data 字段一般为空，但“data 为空”并不代表一定安全，因为接收地址可能是合约地址，或者用户所在钱包界面隐藏了其他上下文。
2. ERC-20 代币转账。用户看到的“转账代币”通常是对代币合约调用 transfer 或 transferFrom。钱包显示的代币名称和图标来自客户端或数据服务，不应当作为唯一依据。真正需要核对的是合约地址、链 ID、精度 decimals、余额变化以及事件日志中的 from、to、value。
3. 授权操作。approve 或 permit 不是直接转账，而是授予某个地址或合约未来动用代币的权限。若额度是最大值，且授权对象为恶意合约，攻击者可能在之后再次调用 transferFrom。对于不熟悉的 DApp，授权风险往往比一次性转账更隐蔽。
4. 交易状态。钱包显示“已发送”只表示客户端尝试广播，并不等于链上成功。应检查交易哈希对应的 receipt：status 为 1 通常表示执行成功，status 为 0 表示执行失败；即便状态成功，也要进一步查看实际资产变化和事件日志，因为合约可能执行了与用户理解不同的动作。
三、前置条件与安全边界
实践前准备一个专门的测试钱包，只放入可承受损失的少量测试网资产；不要把主钱包助记词、私钥或 keystore 文件输入网页、聊天工具和脚本。准备一个可信的区块浏览器，并确认其域名、网络名称和链 ID。对于脚本查询，使用自己控制的节点，或使用明确可信的 RPC 服务；不要把带有签名能力的私钥放进 RPC URL、浏览器插件或不明代码。
建议记录以下信息：网络名称与 chain ID、资产合约地址、目标地址、交易哈希、操作时间、DApp 域名和钱包弹窗中的原始字段。涉及大额资产时，最好采用硬件钱包、多签钱包或白名单机制，并先用小额测试交易验证流程。
四、分步骤实践：签名前后的完整核验流程
步骤一：确认网络和资产身份
先核对钱包当前网络是否与收款方要求一致。相同的地址格式并不意味着资产可以在不同网络间直接使用。以太坊主网、各种 EVM 兼容链可能使用相同的十六进制地址格式，但余额、交易历史和合约地址分别属于不同链。代币合约地址也必须从项目官方文档、已验证的合约页面或可信交易所公告中交叉确认，不能只看代币名称、Logo 或搜索结果第一项。
步骤二：核对地址的完整字符串
不要只比较地址前后几位。复制地址后，应在钱包和可信来源之间逐字符核对；对高价值转账，可以在离线环境中使用二维码或硬件钱包的地址显示功能。特别注意地址投毒：攻击者可能向历史交易方发送金额极小的交易，制造一个与常用地址前后字符相似的地址，诱导用户从交易记录中复制错误目标。地址应来自已保存的通讯录、官方页面或人工再次确认，而不是直接从陌生交易记录复制。
步骤三：识别“转账”还是“授权”
签名弹窗出现 approve、setApprovalForAll、permit、increaseAllowance 等字样时，应暂停操作。ERC-20 的 approve 表示允许 spender 使用某种代币，NFT 常见的 setApprovalForAll 则可能允许对方管理某个集合中的全部 NFT。除非明确理解业务用途，否则不要签署无限额度授权。可以优先选择精确额度，并在使用完成后撤销不再需要的授权。注意，撤销授权本身也是一笔链上交易，需要支付网络手续费。
步骤四：检查合约和调用参数
在高级钱包或区块浏览器的“输入数据”中，核对函数名称、目标合约地址和金额。代币金额要结合 decimals 理解，例如 decimals 为 6 的代币，链上整数 1000000 通常代表 1 个代币；不能把界面显示值直接当作原始整数。若 DApp 要求签署 typed data，应查看 domain、chainId、verifyingContract、spender、额度和截止时间。对于 permit 类签名，尤其要确认签名是否可能被重复使用以及 nonce、deadline 是否合理。
步骤五：先用小额和独立测试确认
对新地址、新网络或新 DApp，先发送最小可接受金额，等待链上确认，并让收款方确认收到。若是合约交互，先在测试网或本地分叉环境中复现流程。不要为了“抢先机”跳过核验，也不要相信网页显示的倒计时、空投资格或所谓客服要求的紧急操作。
步骤六：广播后验证 receipt 和余额变化
拿到交易哈希后，在对应网络的区块浏览器中检查 from、to、value、token transfers、状态、区块确认数和手续费。也可以使用只读 RPC 查询交易和收据。下面是使用 curl 的示例，RPC_URL 应替换为自己确认过的只读节点地址，TX_HASH 替换为真实交易哈希：
curl -s "$RPC_URL" -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["TX_HASH"],"id":1}'
curl -s "$RPC_URL" -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["TX_HASH"],"id":2}'
返回结果中，transaction 的 to 是交易目标，input 是调用数据，receipt 的 status 用于判断执行结果，logs 则可帮助核对 ERC-20 Transfer 事件。查询时必须使用与交易相同的网络，否则可能得到“交易不存在”或完全无关的数据。对于余额核验，不要只看钱包首页缓存，必要时分别查询原生资产余额和代币合约 balanceOf。
五、一个安全的本地实验方案
可以在本地 Anvil、Hardhat Network 或其他经过确认的开发节点上部署一个简单 ERC-20 合约，创建两个测试账户，分别进行精确额度 approve、无限额度 approve、transferFrom 和撤销授权实验。实验步骤是：第一，记录账户 A 和 B 的余额；第二，A 只授权 B 使用 10 个测试代币；第三，用 B 调用 transferFrom，验证最多只能转出 10 个；第四，A 将授权额度设为 0；第五，再次尝试 transferFrom，确认调用失败或无法转移资产。所有私钥仅使用本地自动生成的测试账户，禁止把这套代码和私钥用于主网。
防御性检查脚本也应只读。例如使用 ethers.js 查询授权额度时，可以调用 token.allowance(owner, spender)，并将结果与预期额度比较。对于生产钱包，应把“无限额度”“不熟悉的 spender”“无截止时间的签名”“目标合约未验证”列为需要人工复核的信号。不要通过脚本批量扫描、爆破或干扰第三方地址；安全测试仅限本地实验、测试网或获得明确授权的环境。
六、风险与注意事项
1. 助记词和私钥永远不能以任何理由提供给客服、项目方、群管理员或所谓审计人员。真正的链上交易不需要把私钥交给他人代签。
2. 硬件钱包能降低私钥被远程窃取的风险，但无法阻止用户在屏幕上确认错误地址或恶意合约。应在硬件设备自身屏幕核对关键字段。
3. “撤销授权”不能追回已经转走的资产，也不能消除已经泄露的私钥。若私钥疑似泄露，应立即将剩余资产转移到全新钱包，并检查旧地址的授权、自动化脚本和设备安全。
4. 跨链桥、交易聚合器和路由合约通常涉及多次调用，界面显示的最终数量可能与中间步骤不同。应确认源链、目标链、接收地址、滑点、截止时间和失败处理规则。
5. 区块浏览器的“已验证合约”标识是有帮助的，但不等于项目安全；开源代码也不等于不存在经济设计、权限管理或升级代理风险。
6. 任何要求先转币才能领取、解冻、验证或提现的页面都应高度警惕。空投、抽奖和“追回资产”服务经常利用受害者的焦虑继续诱导签名。
七、常见问题
问：交易失败了，资产会不会被转走？
答：正常情况下，失败交易的状态为 0，合约状态变更会回滚，但已经消耗的 gas 通常无法退回。仍应检查 receipt 和日志，不要只依据钱包通知判断。
问：地址相同，为什么在另一条链上看不到余额？
答：EVM 链可能使用相同地址格式，但每条链是独立账本。需要确认资产是否实际跨链、目标链是否支持该代币，以及钱包是否添加了正确的网络和合约地址。
问：把授权额度设置为零是否足够？
答：对指定代币和指定 spender 来说，成功执行后通常可以阻止其继续使用该授权，但仍要检查是否存在其他 spender、NFT 的全量授权、签名权限或私钥泄露。若私钥泄露，撤销授权不是根治方案。
问：只读连接会不会盗走资产？
答：只读 RPC 查询本身不包含签名，通常不能直接转移资产；但不可信网站仍可能通过钓鱼页面诱导你签名。因此只读查询和交易签名必须分开，签名前仍要核对域名、参数和硬件钱包显示内容。
八、总结
可靠的链上安全不是记住某个网站或某个钱包品牌，而是形成固定流程：确认网络和合约身份，逐字符核对地址，区分转账与授权，审查额度和签名参数，先在本地或测试网验证，广播后用交易哈希核对 receipt、日志和实际余额。遇到高压催促、无限授权、陌生合约、异常空投和“先付款再解冻”等情形，应停止操作并保留证据。把每一次签名都视为一份不可轻易撤销的授权文件，才能在不依赖投资承诺的前提下，降低加密货币使用中的实际操作风险。
加密货币转账通常不可逆，用户一旦签署并广播交易，资产是否能够追回往往不再取决于客服或平台，而取决于目标地址是否仍可控、私钥是否安全以及链上规则是否允许撤销。现实中的风险并不只有私钥泄露，还包括地址投毒、恶意授权、网络或代币识别错误、假冒空投、钓鱼签名和跨链桥误操作等。
本文以以太坊兼容链为主要示例，目标不是预测价格，也不是推荐任何资产，而是建立一个可复用的交易核验流程：在签名之前确认“给谁、给什么、给多少、通过什么合约执行”；在广播之后确认“交易是否真的上链、状态是否成功、资产是否发生异常变化”。比特币等 UTXO 模型链在交易结构上不同，但“核对网络、核对地址、保留证据、最小权限操作”的原则同样适用。
二、原理：一笔链上操作究竟包含什么
1. 原生资产转账。以太坊中的 ETH 转账通常由发送地址、接收地址、value、nonce、gas 参数和签名组成。普通转账的 data 字段一般为空，但“data 为空”并不代表一定安全，因为接收地址可能是合约地址，或者用户所在钱包界面隐藏了其他上下文。
2. ERC-20 代币转账。用户看到的“转账代币”通常是对代币合约调用 transfer 或 transferFrom。钱包显示的代币名称和图标来自客户端或数据服务，不应当作为唯一依据。真正需要核对的是合约地址、链 ID、精度 decimals、余额变化以及事件日志中的 from、to、value。
3. 授权操作。approve 或 permit 不是直接转账，而是授予某个地址或合约未来动用代币的权限。若额度是最大值，且授权对象为恶意合约，攻击者可能在之后再次调用 transferFrom。对于不熟悉的 DApp，授权风险往往比一次性转账更隐蔽。
4. 交易状态。钱包显示“已发送”只表示客户端尝试广播，并不等于链上成功。应检查交易哈希对应的 receipt：status 为 1 通常表示执行成功，status 为 0 表示执行失败；即便状态成功，也要进一步查看实际资产变化和事件日志，因为合约可能执行了与用户理解不同的动作。
三、前置条件与安全边界
实践前准备一个专门的测试钱包，只放入可承受损失的少量测试网资产；不要把主钱包助记词、私钥或 keystore 文件输入网页、聊天工具和脚本。准备一个可信的区块浏览器，并确认其域名、网络名称和链 ID。对于脚本查询，使用自己控制的节点，或使用明确可信的 RPC 服务；不要把带有签名能力的私钥放进 RPC URL、浏览器插件或不明代码。
建议记录以下信息：网络名称与 chain ID、资产合约地址、目标地址、交易哈希、操作时间、DApp 域名和钱包弹窗中的原始字段。涉及大额资产时，最好采用硬件钱包、多签钱包或白名单机制，并先用小额测试交易验证流程。
四、分步骤实践：签名前后的完整核验流程
步骤一：确认网络和资产身份
先核对钱包当前网络是否与收款方要求一致。相同的地址格式并不意味着资产可以在不同网络间直接使用。以太坊主网、各种 EVM 兼容链可能使用相同的十六进制地址格式，但余额、交易历史和合约地址分别属于不同链。代币合约地址也必须从项目官方文档、已验证的合约页面或可信交易所公告中交叉确认，不能只看代币名称、Logo 或搜索结果第一项。
步骤二：核对地址的完整字符串
不要只比较地址前后几位。复制地址后，应在钱包和可信来源之间逐字符核对；对高价值转账，可以在离线环境中使用二维码或硬件钱包的地址显示功能。特别注意地址投毒：攻击者可能向历史交易方发送金额极小的交易，制造一个与常用地址前后字符相似的地址，诱导用户从交易记录中复制错误目标。地址应来自已保存的通讯录、官方页面或人工再次确认，而不是直接从陌生交易记录复制。
步骤三：识别“转账”还是“授权”
签名弹窗出现 approve、setApprovalForAll、permit、increaseAllowance 等字样时，应暂停操作。ERC-20 的 approve 表示允许 spender 使用某种代币，NFT 常见的 setApprovalForAll 则可能允许对方管理某个集合中的全部 NFT。除非明确理解业务用途，否则不要签署无限额度授权。可以优先选择精确额度，并在使用完成后撤销不再需要的授权。注意，撤销授权本身也是一笔链上交易，需要支付网络手续费。
步骤四：检查合约和调用参数
在高级钱包或区块浏览器的“输入数据”中，核对函数名称、目标合约地址和金额。代币金额要结合 decimals 理解，例如 decimals 为 6 的代币，链上整数 1000000 通常代表 1 个代币；不能把界面显示值直接当作原始整数。若 DApp 要求签署 typed data，应查看 domain、chainId、verifyingContract、spender、额度和截止时间。对于 permit 类签名，尤其要确认签名是否可能被重复使用以及 nonce、deadline 是否合理。
步骤五：先用小额和独立测试确认
对新地址、新网络或新 DApp，先发送最小可接受金额，等待链上确认，并让收款方确认收到。若是合约交互，先在测试网或本地分叉环境中复现流程。不要为了“抢先机”跳过核验，也不要相信网页显示的倒计时、空投资格或所谓客服要求的紧急操作。
步骤六：广播后验证 receipt 和余额变化
拿到交易哈希后，在对应网络的区块浏览器中检查 from、to、value、token transfers、状态、区块确认数和手续费。也可以使用只读 RPC 查询交易和收据。下面是使用 curl 的示例，RPC_URL 应替换为自己确认过的只读节点地址，TX_HASH 替换为真实交易哈希：
curl -s "$RPC_URL" -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["TX_HASH"],"id":1}'
curl -s "$RPC_URL" -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["TX_HASH"],"id":2}'
返回结果中，transaction 的 to 是交易目标，input 是调用数据，receipt 的 status 用于判断执行结果，logs 则可帮助核对 ERC-20 Transfer 事件。查询时必须使用与交易相同的网络，否则可能得到“交易不存在”或完全无关的数据。对于余额核验，不要只看钱包首页缓存，必要时分别查询原生资产余额和代币合约 balanceOf。
五、一个安全的本地实验方案
可以在本地 Anvil、Hardhat Network 或其他经过确认的开发节点上部署一个简单 ERC-20 合约，创建两个测试账户，分别进行精确额度 approve、无限额度 approve、transferFrom 和撤销授权实验。实验步骤是：第一，记录账户 A 和 B 的余额；第二，A 只授权 B 使用 10 个测试代币；第三，用 B 调用 transferFrom，验证最多只能转出 10 个；第四，A 将授权额度设为 0；第五，再次尝试 transferFrom，确认调用失败或无法转移资产。所有私钥仅使用本地自动生成的测试账户，禁止把这套代码和私钥用于主网。
防御性检查脚本也应只读。例如使用 ethers.js 查询授权额度时，可以调用 token.allowance(owner, spender)，并将结果与预期额度比较。对于生产钱包，应把“无限额度”“不熟悉的 spender”“无截止时间的签名”“目标合约未验证”列为需要人工复核的信号。不要通过脚本批量扫描、爆破或干扰第三方地址；安全测试仅限本地实验、测试网或获得明确授权的环境。
六、风险与注意事项
1. 助记词和私钥永远不能以任何理由提供给客服、项目方、群管理员或所谓审计人员。真正的链上交易不需要把私钥交给他人代签。
2. 硬件钱包能降低私钥被远程窃取的风险，但无法阻止用户在屏幕上确认错误地址或恶意合约。应在硬件设备自身屏幕核对关键字段。
3. “撤销授权”不能追回已经转走的资产，也不能消除已经泄露的私钥。若私钥疑似泄露，应立即将剩余资产转移到全新钱包，并检查旧地址的授权、自动化脚本和设备安全。
4. 跨链桥、交易聚合器和路由合约通常涉及多次调用，界面显示的最终数量可能与中间步骤不同。应确认源链、目标链、接收地址、滑点、截止时间和失败处理规则。
5. 区块浏览器的“已验证合约”标识是有帮助的，但不等于项目安全；开源代码也不等于不存在经济设计、权限管理或升级代理风险。
6. 任何要求先转币才能领取、解冻、验证或提现的页面都应高度警惕。空投、抽奖和“追回资产”服务经常利用受害者的焦虑继续诱导签名。
七、常见问题
问：交易失败了，资产会不会被转走？
答：正常情况下，失败交易的状态为 0，合约状态变更会回滚，但已经消耗的 gas 通常无法退回。仍应检查 receipt 和日志，不要只依据钱包通知判断。
问：地址相同，为什么在另一条链上看不到余额？
答：EVM 链可能使用相同地址格式，但每条链是独立账本。需要确认资产是否实际跨链、目标链是否支持该代币，以及钱包是否添加了正确的网络和合约地址。
问：把授权额度设置为零是否足够？
答：对指定代币和指定 spender 来说，成功执行后通常可以阻止其继续使用该授权，但仍要检查是否存在其他 spender、NFT 的全量授权、签名权限或私钥泄露。若私钥泄露，撤销授权不是根治方案。
问：只读连接会不会盗走资产？
答：只读 RPC 查询本身不包含签名，通常不能直接转移资产；但不可信网站仍可能通过钓鱼页面诱导你签名。因此只读查询和交易签名必须分开，签名前仍要核对域名、参数和硬件钱包显示内容。
八、总结
可靠的链上安全不是记住某个网站或某个钱包品牌，而是形成固定流程：确认网络和合约身份，逐字符核对地址，区分转账与授权，审查额度和签名参数，先在本地或测试网验证，广播后用交易哈希核对 receipt、日志和实际余额。遇到高压催促、无限授权、陌生合约、异常空投和“先付款再解冻”等情形，应停止操作并保留证据。把每一次签名都视为一份不可轻易撤销的授权文件，才能在不依赖投资承诺的前提下，降低加密货币使用中的实际操作风险。