EOS持有者请进，一起侃侃Whiteblock对EOS的负面研究报告

上周5️⃣，一个EOS的负面新闻开始传播，”EOS只是一个中心化的云服务，EOS不是区块链“，我看到这个新闻时，也被这些描述吸引和震到了，觉得不可思议。于是阅读了该新闻来源的英文研究报告，其实这篇新闻稿是翻译和总结于whiteBlock出的一个EOS测试报告。今天我就新闻中提到的两点来谈谈我的看法。

EOS是一个中心化的计算云服务

这个观点对应于研究报告中对EOS网络架构的分析部分，原文如下，红色部分是一些结论

翻译过来就是EOS网络架分为三层，具体如下:

核心网络层

EOSIO核心网络是区块生产者所在网络，由21个BP Node生产节点组成，这些节点由网络社区投票选出，通过网络连接在一起。

这一层网络的节点CPU强，内存大，带宽高，通常也有备份服务器。

访问网络层

介于消费层和核心层之间，过滤并缓冲数据，保证核心层网络高效运转。

访问网络层的节点有两类： API Node, Seed Node。

1）API Node

处理来自cleos的请求，执行事务和查询状态。同时也会过滤交易，将好的交易广播给BP，减轻BP的负载。API Node使用代理和负载均衡模块来完成这些操作。简单来说，API Node就是为BP Node遮风挡雨，防毒面具。每个生产者节点应至少具有一个关联的API节点

2）Seed Node

Seed Node负责和其他节点通信，并跟踪同步区块数据。Seed Node只负责广播区块，也要求所有种子节点验证交易，也不负责执行交易，不需要保留状态数据，也不具备API能力。一个BP必须关联一个Seed node.

消费网络层

任何使用区块链的用户，包括直接通过cleos、间接使用与区块链接口的某些应用程序。比如我们经常使用cleos -u node_url来发送action，这个操作就是消费网络层的用户通过API Node访问网络。

该研究报告对EOS网络的分析是蛮准确的，但是得到的结论有故意夸大负面因素的嫌疑。首先，EOS并没有限制seed node, api node，任何cleos的用户都可以部署API Node, Seed Node，这样消费网络层就和访问网络层就合并了，也就不存在文中提到的用户使用网络必须请求中心化的访问网络层的问题。当然，由于EOS的高TPS,导致数据量巨大，一般的用户没法部署API和Seed Node, 因此目前事实上大部分cleos的用户确实是通过其他人的API Node来发起并处理交易，存在一定的中心化问题。但是这个是因为EOS高TPS的问题，EOS初期发展的问题，而不是EOS本身设计的问题。如果以太坊TPS高起来也会存在这个问题，且就算是现在，以太坊的大部分用户(消费网络层)也是通过交易所，钱包等中心化节点访问以太坊网络的，是不是也存在一样的中心化问题呢？所以这个问题其实是一种生态问题。

其次，EOS网络核心层是21个超级节点确实有点中心化，而以太坊的网络核心层确实可以是任意节点，但是事实上以太坊网络核心层几乎也就是几个大矿池，所以这个问题是归根到底是DPOS和POW的问题，即投票和算力的中心化对比问题。所以说，等以太坊支持POS后，也请whiteBlock再来出一篇分析报告。

EOS不是区块链，没有使用密码学技术

一开始看到这个“没有使用密码学技术”很是奇怪，第一感觉是这个EOS研究报告的作者太"牛"了吧。后来看了该研究报告的英文原文，才知道这个观点的真实意思。原文中，作者是说EOS没有通过密码技术对状态数据进行验证。其实总结起来就是EOS的状态数据没有上链，没有采用以太坊状态Merkle树的方式保存状态数据并进行验证，然后被翻译过来又被媒体一传播就成了EOS没有使用密码学技术。研究报告中该观点的相关原文如下：

EOS状态数据没有上链没有验证，这个说法是正确的。我在一个月前也写了一篇文章

【EOS的安全隐患】

分析了该隐患，但是我当时是建设性分析，且提出了一些意见，而这篇研究报告多处提到该观点（上图红色部分），并把它当做严重设计错误并极力贬低EOS就有点过了。下面我们就来分析一下这个状态数据不验证不上链是否真的有那么大的缺陷？

区块链的数据分为两类，一类是交易原始数据(区块包含了交易)，一类是状态数据。交易执行更改状态数据，所以理论上，有了交易数据，是可以完全还原出状态数据的。BTC中状态数据是UTXO(Unspent Transaction Output), Ethereum里状态数据是一堆merkle树，EOS里的状态数据是数据库table。

交易数据打包在区块里，并生成一个交易merkle树产生一个merkle root并保存在区块头里，然后以区块头hash为链表形成区块链，这样就维护了整个交易历史数据。任何节点只要获取到相同的区块头hash，那么可以完全肯定这些节点收到了相同的交易数据。在EOS里就是，当一个区块后面生产了新的15个块，那么这个区块就得到2/3(15/21 > 2/3)的BP认可，也代表这个块之前的所有交易数据都完全准确无误的记录在2/3BP上了，且都是一模一样的，自然是不可逆的了。但是到了状态数据，就不一样了，即使每个节点获取到的交易都是一样的，但是执行这些交易的结果却不一定是一样的，因为执行交易就是执行一个程序，是程序就有可能有bug，这样就可能导致各个节点的状态数据不一致。同时，单个超级节点也可以独自修改状态数据。区块链不怕数据不一致，而是怕发现不了不一致，也就没法选择并最后达成确定性共识。比如在以太坊下，如果生产者挖矿成功，然后执行一个交易T1，得到错误状态S1(伪造也好，BUG也好)，并出块包含T1和S1数据的区块B1。其他节点在收到B1区块后，执行交易T1后却得到了真实状态S2, 那么其他节点会认为B1区块是非法的并丢弃，这里最后的共识就是丢掉B1，这就是研究报告中提到的以太坊会验证状态数据。而在EOS里，每个区块里的交易被独立执行并得出状态数据，但这些状态数据并不分享，各个节点就没法验证这些节点的状态数据是否一致。EOS的宪法规定所有决议都应该是2/3的节点认可才生效。比如交易，就需要得到后续15个区块的确认，也就是间接得到了2/3超级节点的认可，才成为不可逆区块。但是因为状态数据不上链不检验，单个超级节点自己是可以任性的修改任何状态数据(比如EOS代币余额)的，这样使用该节点服务的用户就可能拿到错误数据。这个典型的例子就是某单个超级节点说我可以独自行动冻结某个账号。当然这个问题在加上一些改进后就不是特别大的问题，比如如果每个用户不使用超级节点的API Node，而是自己也部署Api Node和Seed node, 自己生成状态数据，由于交易数据肯定是得到2/3共识的，因而每个用户拿到的交易数据肯定也是确定的一致的，然后在不考虑程序BUG的情况下生成的状态数据也肯定是一致的，这样单个超级节点的任性状态数据修改行为并不会影响用户。因此基于今天的探讨，我个人觉得EOS上冻结账号等私自修改状态数据的行为都要通过提议，2/3 BP共识上链，以保证所有节点状态数据都得到2/3节点共识。同时，相同交易不同节点产生不同状态数据的概率极低，且可以通过其他相对简单的措施降低影响。

BTC, ETH, EOS的交易及状态数据架构如下：

总结

总的来说，whiteBlock出的这篇研究报告是很不错的，提出的问题也是存在的，比较专业，值得EOS生态推动者去思考改善。其实，我在【可能的EOS安全隐患】里就提到过一些改善点

1）增加Fast Sync功能，让更多的个人能成为Seed node和API node

2）增加状态数据的checkpoint机制，既可以加速同步，也可以增强状态数据的一致性

3）BP们定时check状态数据, 及时发现相同交易产生不同状态数据的case

附录

报告原文地址：

https://cdn0.tnwcdn.com/wpcontent/blogs.dir/1/files/2018/11/EOS_Report.pdf

该研究报告对EOS的设计及架构及生态分析的比较到位，推荐EOS进阶朋友仔细阅读。

个人能力有限，本文的分析可能有不足或者错误的地方，欢迎大家告知

------------------------------------------------

如果你喜欢我的文章，请末尾点击喜欢