作者 | 红石
责编 | 乔治
出品 | 区块链大本营（blockchain_camp）
#今天是一篇技术文。
3月15日，mercatox 遭受（hard_fail）攻击，黑客获利数千 EOS，约合数万人民币。
3月11日，EOS DApp nkpaymentcap 被攻击，黑客成功获利 5 万 EOS，约合人民币100多万元。经分析发现，攻击者采用假转账通知攻击获取大量合约代币，又将代币通过 DApp 合约兑换成真 EOS 进行套现。
3月10日，EOS 竞猜类游戏 Vegas Town 被连续（hard_fail）攻击，黑客获利数千枚 EOS 。
3月9日，EOS 竞猜类游戏 Gamble EOS 遭受假转账攻击，黑客成功获利数千 EOS……
仅仅三月份，利用交易验证漏洞进行的攻击就已经有这么多起，损失达上千万人民币。
那么，什么是交易验证漏洞？为何 EOS 让你频频“丢钱”？BM告诉你，是你的代码“太笨”。
先说说交易验证，你不了解交易验证，但黑客了解。
因为在支付领域，这很重要。在区块链领域，无论做 DApp，还是接入数字货币支付，交易验证都是重要部分。
交易验证，说起来也简单：就是如何确认一笔金额已经到账。
说起来也不简单，因为会有无数黑客试图让并未成功的交易通过验证，从而空手套白狼。
比如最近针对 EOS 交易的 hard_fail 状态攻击，就是这样一种黑客攻击。
hard_fail 状态攻击
在 EOS 区块链上，每笔交易（transaction）都有一个状态（status）参数，只有当这个参数为 executed（已执行），才说明交易成功。但是因为一般来说，失败的交易都不会提交到链上，所以，一些不谨慎的交易所、DApp 甚至没有验证这个参数。
这才有了最近的 hard_fail 状态攻击。其实这个攻击手法的背后原理远比它的名字简单，就是黑客发起了注定失败的、但是又能上链的交易，专门攻击那些只要交易上链就视作交易成功的平台。
不试不知道，一试吓一跳，真的有很多平台没验证这个参数……
那么，EOS 交易验证到底需要验证些啥？
EOS 交易验证涉及的参数
EOS 交易验证，需验证：
1、交易 excuted，验证 transaction status 参数为 executed，验证这个参数可以有效避免 hard_fail 状态攻击；
说简单点，这一步是验证交易是否正常执行。
2、不可逆，即交易所在区块号低于当前最新不可逆块号，需要获得 transaction 所在区块的区块号，以及主网最新不可逆块的区块号（不可逆区块高度），判断：
block_num < last_irreversible_block_num；
说简单点，这一步是验证交易是否已经同步。
区块链是分布式账本，交易提交上去后，需要大多数节点记录了这笔交易，才能认为交易已上链并不可篡改。不然的话，比如如果只有一个节点有这笔交易，则只要这个节点的交易信息一改，这笔交易就变了。
3、合约账户和货币符号；
合约账户就是货币的智能合约账户。EOS 区块链转账都是基于智能合约的，比如 EOS 币的智能合约账户就是 eosio.token，每一次进行 EOS 币转账，都会调用这个合约。
假币攻击就是因为交易所没验证合约账户。
4、交易（action）类型为 transfer；
EOS 区块链上的交互都是以 transaction 进行，无一例外。所以，不是每一笔 transaction 都包含转账。EOS 一笔 transaction 可以有多个 action，只有类型为 transfer（转账）的 action，才是转账，才是需要做交易验证的。
5、From 和 to，即转入转出的账户需要再次确认。
交易（Transaction）同时满足这些条件，才能判断为交易成功，并执行下一步程序。而且，如果是通过公共 API 或 API 服务商提供的数据进行交易验证，需要使用不同服务提供商的 API 至少进行二次确认，以防止 API 信息出错导致问题。
那么问题又来了，如何通过公共 API 进行交易验证呢？
通过 EOSPark API 获取交易、进行交易验证
让我们以 EOSPark 的 API 服务做个基本示例。
EOSPark 本身是一个主流 EOS 区块浏览器，但他们也面向开发者提供 API、代码一致性校验、合约安全（SEC）、合约语义化等服务。
1、EOSPark API 官网： https://eospark.com/openapi 2、EOSPark API 官方文档： https://developer.eospark.com/api-doc/zh/https/
EOSPark API 服务思维导图：
EOSPark API 有四种查询 EOS 交易的方式。
根据账户查询：
HTTPS API get_account_related_trx_info Websocket API subscribe_account
根据 txID 查询：
HTTPS API get_transaction_detail_info HTTPS API get_transaction_action_info
以 HTTPS API get_account_related_trx_info 为例，这个接口能查询对应账户的进出交易，无论是收到的转账还是发起的转账，都可以一起查到：
get_account_related_trx_info 的基本查询语句如下：
https://api.eospark.com/api?module=account&action=get_account_related_trx_info&apikey= {这里放你的 API KEY}&account={这里放 EOS 账户名}&page=1&size=10
语句填好参数后可以直接在普通浏览器中打开查询信息，不过当然，我们更习惯用 IDE：
Node.js 代码示例：
返回 JSON 示例：
可以看到在 get_account_related_trx_info 返回的信息中，本来就包括交易所在区块号（block_num）和不可逆区块高度（last_irreversible_block_num）。
同时 status、code（合约账户）、symbol、From（这里是 sender）和 to（这里是 receiver）这些参数也一应俱全。（交易类型因为这个接口本身就是返回转账交易，所以这里可以不作验证。）
也就是说，使用这个接口，查询一次就可以直接验证获取到的交易。
那么问题又来了，也就是说，有些时候查询的信息不能直接进行交易验证？
很不幸，是滴。
获取不可逆区块高度和交易状态的补充方法
有些接口返回的交易信息不包含交易验证所需所有参数，需要再另外获取。最常见的就是不可逆区块高度的缺失，还有一些直接查询 actions 的接口有交易状态参数缺失。
不过处理起来都很简单。
同样以 EOSPark API 服务为例：
获取不可逆区块高度，使用 RPC 接口 get_info 就好，这是一个获取 EOS 主网基本信息的接口：
Node.js 代码示例：
返回 JSON 示例：
获取状态参数，可以使用 HTTPS 接口 get_transaction_detail_info，这是一个根据 txID 查询交易（transaction）详情的接口:
查询语句：
https://api.eospark.com/api?module=transaction&action=get_transaction_detail_info&apikey= {这里放你的API KEY}&trx_id={这里放查询的交易ID}
返回 JSON 示例：
至此，我们就简单说完了 EOS 区块链交易验证的一个基本思路。当然，具体情况具体分析，具体开发时验证的方式不一定按这样来。不过条条大路通罗马，思路是一样的，验证的参数也基本都是这些。
