分析EOS有哪些安全隐患？

EOSForce.io作为对EOS代码进行过深入研究并且做过大量部署测试的团队，曾经多次提醒过主网安全问题，并且针对发现的问题进行了修复和更改。近期，随着研究深入，我们发现了更多的安全隐患，而一些候选节点也开始关注到主网的安全问题。

我们接下来披露直到现在也还依然困扰我们的9个核心安全隐患，由于Block.one宣称不对任何一条主网的安全负责，我们自己做了一些初步解决方案。这里试图也帮助大家理解：

EOSForce.io对EOSIO的更改为什么是必须的。如果有更好的解决方案，也希望大家来跟我们沟通，一起为EOS的安全做出贡献。 EOSForce.io承诺不竞选超级节点，在EOS主网公测结束验证安全之前不会贸然启动主网。也不建议用户在此之前随便导入私钥去激活主网资产。

为了解决 EOS 目前的困扰， EOSForce.io做了最新的预防，以期望最小功能安全启动EOS主网，然后等各个限制模块形式化验证以及大规模测试验证通过后慢慢放开相应的功能。

困扰1：

EOS基于资源抵押模式， 这很创新，但现在还没有做到原来期望的程度。 目前已经在运行的公有链都是以收手续费的模式。

收手续费有两个好处：

1、 防止链级别DDOS， 众所周知， 以太坊的POW测试网为什么经常受攻击， 因为币没有价值， 没有防止链级别攻击的门槛。 之前以太坊每个code gas价格的合理设置也是为此。 大家都知道，防止DDOS的最好办法，是迫使攻击成本远大于利润获得成本。 

2、手续费可以作为激励的来源，保持整条链的生态稳定向前发展。

" EOS基于抵押模型 "这一思维很创新，零手续费， 当时大家（包括BM）期望通过资源抵押的方式来防止DDOS， 后面又期望成立EOSRAM等相关的资源代币来产生激励。这样就解决了收交易手续费的问题。 

然而交易手续费问题只是在System合约和底层间有点联系 ，并没有得到预期的希望。 

对于开发者， 大家只要随便搭个测试网， 你们可以不用任何成本可以发送交易， 这样就能验证我说的这一问题。 这个问题是链级别致命的问题， 远超过360“史诗级”的传统内存泄露问题。因为只要任何一个人开一台电脑，批量持续向EOS主网发送交易。 EOS网络就会失败。

EOSForce.io 预防1 ：

针对这一点， EOSForce.io在EOS的基础上增加了对每个action设置价格收费。 只是现在在EOS没有把资源模块做好的时候加了个交易手续费的过滤器。 等后面BM大神把这块功能做好了， EOSForce就可以把交易手续费这一层过滤器关掉，进行真正可以通过资源来防止DDOS攻击，还可以激励整条链的生态。

困扰2：

EOS代码中有超级权限这一说， 超级权限不需要私钥就可以通过身份验证。 并且以字符eosio.开头的账户都是准超级权限账户（现在就有eosio）

这点与区块链哲学的基本功能私钥保护下个人资产神圣不可侵犯相违背。

EOSForce.io 预防2 ：

针对这点， EOSForce.io 限制整个系统只有一个特权额账户就是eosio, 并且使该账户的公钥数据段为全0， 加了检验后的该地址为

EOS1111111111111111111111111111111114T1Anm。 没有任何人拥有或者知道该私钥。

困扰3：

交易的设计结构过于复杂

大家可以看我们所摘下来完整的EOS数据块。 EOS的一个交易可以由action数组和多个contextfreeaction数组组成。 而action 中又可以加入inline action, contextfreeaction 不需要签名， action 中可以套大量的inline action。

EOS是以action 为单位顺序执行。交易又可以是延时交易。等等这些设计，都很创新，感谢BM。但这么复杂的功能过于庞大，可攻击组合的点很多。交易套延时交易，交易里有action, action 又可以套inline_action。这复杂的功能需要长时间，多种case组合,长有力的测试验证。

EOSForce.io 预防3：

我们也正在组织大量的团队进行这一块的测试和验证。 但为了持币人的安全性。 我们限制交易里面的action为单action， 不需要签名的contextfreeaction我们先限制掉。 等形式化证明结果，以及大规模各种实列测试验证成功通过后，再把这层过滤器给放开。

困扰4：

EOS的查询 get table 等查询接口不能分批指定关键字查询。

在这里不得不赞叹一下BM这个技术天才， 他用到了多plugin可插拔式模块编程， 多个模块都是单列模式，可以互相访问。

除此之外他还用到了消息总线微服务编程模式。 各个模块只要对相应的消息感兴趣， 只要注册相应的消息总线， 就能接受相应的消息。 但在这些模块中有很多查询接口只能批量查询。

当数据小时，还可以接受。但当真到了百万tps后， 这样的查询，就基本没有机器能满足了。 虽然--key在EOS就是有的字段，但在EOS代码中一直像transfer接口中的memo参数一样， 只有其名，确没有他的实现。

EOSForce.io 预防4：

加入--key 按关键字定点小额查询。

困扰5：

EOS的水龙头模块已经有很长一段时间，该模块是不通的了。

水龙头模块，是一个让用户可以通过第三方注册用户名的插件。

EOSForce.io 预防5：

增加水龙头插件。

困扰6：

chainbase 数据库的不稳定性。

大家可以调用chainbase 的接口，对相同的数据进行两次存储， 程序就会core dump。 EOS合约中的multiIndex table表也是用的chainbase, 当你对一个table的同一行数据的不通列同时进行修改时， 他只会更新最后一次的操作。

EOSForce.io 预防6：

认真的review相关这块的代码， 对所有有出现问题的地方进行了review。

困扰7：

EOS 的wasm-jit 是直接fork Andrew Scheidecker近两年的代码,以及fork了官方的webassembly。这里面有多少bug，需要大规模测试。

EOSForce.io 预防7 ：

EOSForce.io在创始块内置系统合约，使系统合约从创始块起，就是内置合约。 EOSForce.io限制了setcode, setabi接口

困扰8：

EOS没有世界状态， 只能通过块级别验证检验发生分叉。

比如：A，B节点的交易序列表都是一样的，也就是块都是一样的。 但对各个账户执行了不同的数据库落盘，链是不知道的。

攻击可能性： 虽然BM在apply_context.cpp中做了只能合约table 拥有者才能修改table。但不排除不能通过外面构造相应的key value 直接对不同合约账户的table做相关 的状态落盘攻击。

这时，链上的块大家都是一致的，但各个节点里面的状态存储就会相应的不同，甚至可以跨账户覆盖相应的table。对不同合约账户的状态进行更改。

EOSForce.io 预防8：

先限制自由提交代码的功能，等所有的这些经过了形式化证明后， 再放开。

困扰9：

mongodb, sql插件的不稳定性。

EOS的数据库的落盘插件模块，mongodb 之前是好的，中间他们就想废弃了，换sql模块。但这种朝令昔改，对于生态的开发用户是致命的。

EOSForce.io 预防9 ：

EOSForce.io正在大规模招募区块链开发者， 对filter模块， 数据库模块会有更好，更持续的更新。

区块链开发不比传统软件开发，如果一个模块的漏洞导致大规模的丢币事件，就算性能真达到百万tps也没有任何意义，安全稳定怎么强调都不为过。在保证安全稳定的基础上，再去扩展性能，扩展特色。 

我们相信BM，也尊重BM给我们带来充满希望的EOSIO。 然而程序没有BUG是不可能的。区块链和中心化系统有本质区别，中心化系统的代码更新和数据修改权限完全由中心化机构负责，可以随意上线、发现BUG、修复BUG、回滚数据、冲账、高速迭代等操作。

但区块链没法做到貌似没BUG、或者没有特别明显的BUG就上线，链上数据全是最高价值的用户资产相关的，即使99%没问题了，也还是一定有问题，只要有任何一个可被攻击的点或维度，区块链网络就一定会失败，不要抱任何侥幸心理。

EOSIO代码一年来经过了持续迭代，尤其是4月和5月，对以前更复杂的设计进行了裁减，一路修改到6月1号发布1.0版本，并没有多少团队对EOSIO进行过完整的测试。而传统安全攻防级别的运维测试并不能算真正的测试。真正需要测试的是链上投票流程、资源相关、自定义合约等，这种测试用例真要写起来也要写几个月，大家都知道，以太坊的测试数据和测试脚本是代码本身的好几倍。

今天，EOS的市值一度到达1000亿人民币，细枝末节多如牛毛，远超过比特币和以太坊上线时的规模。如果链本身的安全不能得到基本保证的话，用户的资产会大量缩水或者归零。

而Block.one官方一直强调不会对主网的安全负责。 EOSForce.io对EOSIO本身存在的重大风险做了大量的测试和修复，也不敢说目前一定是安全的。接下来，我们诚挚邀请各位EOS社区的用户，节点候选人，第三方安全团队一起来验证一条安全的EOS主网。在确认无重大安全隐患后再行上线。 欢迎登陆EOSForce.io参与EOS主网公测。

向Oracle chain，EOS Shenzhen 等投票No go的团队致敬，在安全问题上，没有任何妥协的余地。