很多人第一次遇到转错地址或误发交易时，会问同一个问题：链上交易能不能撤销？简短的回答是：一笔交易一旦被区块确认并达到足够深度，通常无法像银行转账那样由某个中心机构撤回。但“撤销”这个词在区块链安全讨论中经常出现，它指向的并不是同一个东西。有人说的是双花攻击里的交易回滚，有人说的是智能合约执行失败后的状态恢复，还有人说的是多签或确认数带来的事前防护。把这些混在一起，就容易产生“链上交易可以撤销”的误解。
确认数等待：用时间换取回滚难度
最基础的防护是等待确认。交易广播后进入内存池，矿工或验证者按手续费等因素选择打包。被打包进第一个区块时，交易获得一次确认；此后每多一个区块，就多一层确认。公开资料中常提到，当确认数达到六个及以上时，通常认为这笔交易比较安全、难以篡改。这个说法的实质是：要让已确认交易被回滚，攻击者需要重建一条更长或更被网络接受的链，成本随确认数增加而上升。
但确认数不是“撤销按钮”，而是一种概率性防护。它降低的是交易被替换或回滚的可能性，并不承诺绝对终局。对于小额、低风险场景，有些商家接受零确认交易，即不等待区块确认就交付；这本质上是一种信任或风险承担，而不是技术上的安全保证。零确认交易面临的风险包括手续费竞争导致的交易顺序变化，以及特定条件下矿工不广播区块造成的双花手法。
多签：事前把“一个人说了算”改成“多人批准”
多签（Multi-sig）解决的是另一个问题：单把私钥失控。它的基本规则是，动用一笔资金需要多个私钥生成的签名才有效。即使其中一个私钥丢失或泄露，攻击者也不一定能把资金转走，因为还需要其他签名方批准。资料中将其描述为一种提高安全性的方式，多个可信方必须同时批准更新，否则无效。
这里要区分清楚：多签不是让已发生的交易可撤销，而是让交易在发出前就需要更多批准。它防的是单点故障和单点作恶，不防私钥全体泄露，也不防签名方合谋。多签的适用场景包括共同管理资金、交易所冷钱包分散权限等，但它本身不解决智能合约逻辑漏洞，也不替代对交易内容的核对。
智能合约里的“回滚”：执行失败与攻击利用是两回事
在智能合约语境中，“回滚”有特定含义：将已经发生的状态恢复成未发生时的样子。一笔合约调用如果执行失败，状态变更可能被撤销，这属于合约运行机制的一部分。但安全资料中讨论的“交易回滚攻击”是另一回事：攻击者利用合约设计缺陷，让支付动作发生后整个流程出错回滚，从而在不真正付款的情况下获利。资料提到，这类攻击多发于智能合约游戏中，当下注动作和开奖动作在同一个交易内时，攻击者可以检测合约状态、获知开奖信息，再选择是否让下注交易回滚。对应的开发建议是不要将用户下注与开奖放在同一个交易内。
所以，合约执行失败导致的状态回滚，和攻击者故意利用回滚获利，不能混为一谈。前者是机制，后者是滥用机制。对普通用户来说，这意味着看到“交易失败”不一定代表资金安全无事，关键要看合约逻辑是否把支付和状态更新放在了正确的顺序里。
重入与假充值：防护点在合约和平台校验，不在“撤销交易”
重入攻击的典型模式是：合约先向用户转账，再修改用户余额状态；恶意合约在接收转账时再次调用转账函数，导致余额状态一直未变，却能反复提取资金。资料中提醒开发者，如果合约存储了用户资金状态，应先修改状态，再进行实际转账。这里的防护是代码顺序和状态检查，不是事后撤销某笔交易。
假充值攻击则针对交易所或合约的入账校验。资料举了几个例子：在 EOS 上，如果有人发行一个同样名为 EOS 的代币，而收款方没有校验来源合约是否为 eosio.token，就可能把假币当成真币入账；在以太坊上，如果交易所不校验交易状态，失败的 ERC20 转账也可能被误认为成功充值。对应的防护是严格校验来源合约、tokenid 或交易执行状态。这些机制解决的是“入账判断错误”，而不是“把已经发生的链上交易撤回来”。
双花与 51% 攻击：回滚是攻击结果，不是可用功能
双花攻击指的是一笔钱被花两次。资料中列举了几种手法：通过控制矿工费让给自己转账的交易优先打包，从而使给商家的交易被回滚；通过控制区块广播时间，针对接受零确认的商家；以及占有超过全网一半算力后创造更长链，回滚旧链交易。这些描述里，“回滚”是攻击者造成的结果，而不是网络提供给用户的撤销服务。
这也解释了为什么确认数等待和多签各自解决不同问题：确认数等待提高回滚成本，多签降低单点私钥失控风险，两者都不能让用户主动撤回一笔已经确认的交易。把它们统称为“防撤销机制”会模糊各自的适用边界。
结论：先分清要防的是“交易被回滚”还是“操作出错”
链上交易通常不可撤销，这是理解所有防护机制的前提。确认数等待防的是交易被回滚的概率，多签防的是单把私钥说了算，智能合约里的状态检查和顺序调整防的是逻辑漏洞被利用，平台入账校验防的是假币或失败交易被误认。它们各自解决不同层面的问题，没有一种机制能同时覆盖全部风险，也不存在“开启某个功能就能随意撤销交易”的通用方案。对普通用户而言，真正有用的做法是：转账前核对地址和链，大额操作留出确认时间，理解多签和平台校验的局限，而不是期待事后撤销。
