【公链产品设计01】如何解决EOS DAPP遭受回滚攻击

公链也是一款产品，产品经理和你聊聊公链产品如何设计。

一则老新闻，2018年12月19日上午，BetDice、EOSMax相继发布公告称，遭受“回滚攻击”，其中BetDice损失20万EOS，EOSMax损失5万EOS。

随后，EOS区块链的开发团队甩锅给DAPP开发者，大意就是漏洞是因为DAPP开发者开发水平烂导致，漏洞与EOSIO无关，并告诫广大开发者读、写节点要分离。

但产品经理不以为然，殊不知好的产品不需要思考，要把用户当傻子，一切用户的问题都是产品的问题，以下省略一万字。。。

先说说EOS上这次攻击是怎么发生的。

这两款DAPP都属于博彩游戏，类似下注猜大猜小，用户发送一笔交易，结果要不是赢要不是输。从公链内部看，流程是：

1）DAPP会对接一个API节点，DAPP构造一笔下注交易后，会先在这个API节点上预执行，校验这笔交易有效后，这个全节点一边修改自己数据库，一边将这笔交易广播给网络内的其他节点，包括出块节点。注意此时DAPP对接的全节点只是单方面修改了自己的数据库，交易结果并没有上链；

2）出块节点收到这笔交易后就会发起共识，共识通过后再将结果广播给全网节点，包括DAPP对接的API节点，此时全网节点都会修改数据库，交易结果真正上链；

3）DAPP对接的API节点收到出块节点的结果，比对自己的数据库，如果不一致，就要回滚数据。

黑客就抓住了API节点和出块节点同步时间差的漏洞，黑客发起一笔交易，并实时查询API节点的预执行结果。如果结果是黑客赢了，那黑客就不做任何操作，最终上链的结果也一定是黑客赢；但如果结果是黑客输了，那黑客就同时发送一笔转账交易直达当前正出块的节点上，让账号余额不足以完成先前的那笔输交易，那么先前的那笔交易就会被废弃，那么黑客就不会输了。

为了解决这个问题，EOS开发团队提的方案是“读写节点分离”，也就是DAPP需要对接两个API节点。一个节点只有写的权限，黑客下注的交易在该节点上预执行，但黑客没办法查询到该节点的预执行结果是输还是赢。另一个节点只有读的权限，黑客的交易不会在该节点上预执行。

这个方案其实是一个填坑方案，对于没踩过坑的开发者来说，可能还是会翻车。另外，这个方案要求开发者需要对接两个API节点，成本无疑是增加的。

一个好的公链，DAPP开发者的用户体验非常重要，最好做到不挖坑。那么从公链底层，怎么设计才能避免这个问题呢？

比特币、ETH 1.0采用的POW共识机制，天生不会发生这样的问题。因为POW机制下，出块节点是随机、不确定的，黑客没办法用一笔转账交易精准的发到出块节点上，提前拦截输交易。而EOS采用的是PBFT共识算法，出块节点是可预测的。

我现在所在的公链项目，采用的也是PBFT算法，通过将共识网络和路由网络分离来避免“回滚攻击”。客户端读、写数据只能通过最外层的路由网络与链交互，DAPP只需要对接一个路由节点即可。首先路由节点收到DAPP交易后不会做任何预执行，所以黑客无法在路由节点上提前查询到预执行的结果是输还是赢；再则路由节点会将交易随机丢给共识网络中的一些节点，所以黑客也无法定位到共识节点查询预执行结果。