上周5号，一条关于EOS的负面消息开始流传，"EOS只是一个集中式的云服务，EOS不是区块链"。看到这个新闻，我也被这些描述所吸引和震撼，觉得不可思议。。所以我看新闻来源的英文研究报告。事实上，这份新闻稿是一份翻译和总结的EOS测试报告。接下来我就新闻中提到的两点谈谈我的看法。
这个观点对应的是研究报告中对EOS网络架构的分析。原文如下红色部分是一些结论。
翻译过来，EOS网络框架分为三层，如下：
核心网络层
EOSio核心网络是区块生产者所在的网络。。它由21个BP节点生产节点组成。这些节点由网络社区投票选出，并通过网络连接在一起。
这一层网络的节点CPU强，内存大，带宽高，通常有备份服务器。
访问网络层
数据在消费者层和核心层之间进行过滤和缓冲，以确保核心层网络的高效运行。
访问网络层的节点有两种：API节点和种子节点。
1)API节点
处理来自cleos的请求，执行事务和查询状态。同时会过滤交易，把好的交易广播给BP，减轻BP的负荷。API节点使用代理和负载平衡模块来完成这项工作。简单地说API节点是BP节点的挡箭牌和防毒面具。每个生产者节点应该至少有一个关联的API节点
2)种子节点
种子节点负责与其他节点通信，并跟踪同步的块数据。。种子节点只负责广播块，所有种子节点也需要验证事务，但不负责执行事务，不需要保存状态数据，不具备API能力。BP必须与种子节点相关联。
消费者网络层
任何使用区块链的用户，包括直接使用cleos的用户，都会间接使用一些与区块链交互的应用程序。比如我们经常用cleos-u来发送。这个操作就是消费者网络层的用户通过API节点访问网络。
研究报告中对EOS网络的分析相当准确，但结论有故意夸大负面因素之嫌。首先，EOS不限制种子节点和api节点。任何cleos用户都可以部署API节点和种子节点。，使消费者网络层和接入网络层合并，用户不需要使用本文提到的网络。请求集中访问网络层的问题。当然，由于EOS的高TPS和庞大的数据量，普通用户无法部署API和种子节点。因此目前，大多数cleos用户实际上通过其他人发起和处理交易'；的API节点。存在一定的集权问题。但这是因为EOS的TPS高，EOS最初的开发并不是EOS本身的设计。如果以太坊的TPS很高，即使是现在，以太坊的大部分用户(消费者网络层)都是通过交易所、钱包等集中节点接入以太坊网络的。有没有同样的情况？集权呢？所以这个问题其实是一个生态问题。第二，EOS网络的核心层确实有点集中，有21个超级节点，而以太坊网络的核心层可以是任意节点，但实际上以太坊网络的核心层几乎只有几个大型矿池，所以问题归结到DPOS和POW。，也就是投票和计算能力的集中比较。所以，以太坊支持POS的时候，请再做一份分析报告。
很奇怪看到这个"无密码技术"一开始。第一印象就是这份EOS研究报告的作者太"厉害"。看了研究报告的英文原文，才明白这个观点的真正含义。在原文中，作者的意思是EOS不通过密码技术验证状态数据。事实上，总而言之，eos状态数据是EOS区块链新闻，是不上链的。状态数据不通过以太坊状态树保存和验证，再通过媒体翻译传播，这样EOS就不使用密码学。研究报告中的相关文字如下：
此说法正确，EOS状态数据不上链，未验证。。一个月前，我也写过一篇文章分析隐患，但我做了建设性的分析，提出了一些看法。这份研究报告多处提到了这一点(上图红色部分)并将其视为严重的设计失误，试图贬低EOS，有点过分。然后让'；让我们分析一下这个状态数据是否还没有被验证，不能上传到这个链上。真的有这么大的缺陷吗？
区块链数据可以分为两类，一类是交易原始数据(区块包含交易)，一类是状态数据。事务执行将改变状态数据。所以理论上，有了事务数据，状态数据是完全可以恢复的。BTC的州数据是UTXO()，BTC的州数据是一束树，EOS的州数据是一个数据库表。
将交易数据封装在eos区块链新闻中的block中，生成交易树生成根并存储在blockheader中，然后将blockheaderhash作为链表形成区块链，从而维护整个交易历史数据。只要任何节点获得相同的块头散列。绝对可以肯定的是，这些节点已经接收到相同的事务数据。在EOS中，当一个块之后生成15个新块时，那么这个块就是BP的2/3(15/21
2/3)。，也代表了之前的所有区块)都完整准确的记录在2/3BP上，而且都是一样的，自然不可逆。但是涉及到状态数据，就不一样了。即使每个节点获得的事务相同，执行这些事务的结果也不一定相同。因为执行一个事务就是执行一个程序，程序可能会有bug，导致各个节点的状态数据不一致。同时，单个超级节点也可以独立修改状态数据。区块链不怕数据不一致，就怕不一致能'；t被发现，所以没有办法选择并最终达成确定的共识。。例如，在以太坊中，如果生产者挖掘成功，然后执行事务T1以获得错误状态S1(伪造或BUG)，块B1包含T1和S1数据。在接收到B1块之后，其他节点执行事务T1并获得真实状态S2。所以其他节点会认为B1块不合法，将其丢弃。
在EOS中，每个块中的事务都是独立执行的，并获得状态数据，但是这些状态数据并不共享，每个节点无法验证这些节点的状态数据是否一致。。EOS's公司章程规定，所有决议都需要2/3节点通过才能生效。比如一个交易，需要经过后面15个区块的确认，也就是间接得到三分之二超级节点的批准，才能成为不可逆区块。但是由于状态数据不在线且未经验证，单个超级节点可以任意修改任何状态数据(如EOS令牌余额)，因此使用节点服务的用户可能会得到错误的数据。典型的例子就是单个超级节点说我可以单独行动冻结账户。。当然，经过一些改进，这个问题并不是什么大问题。比如每个用户不使用超级节点的Api节点，而是自己部署API节点和种子节点并生成状态数据，因为事务数据必须2/3一致。所以每个用户获得的事务数据必须一致，不管程序bug产生的状态数据也必须一致，所以单个超级节点的任意状态数据修改行为不会影响用户。所以基于下面的讨论，我个人认为有必要提出私自修改状态数据的行为。比如冻结EOS上的账号，上传2/3BP共识，保证所有节点状态数据都有2/3节点共识。同时
BTC、ETH、EOS的事务和状态数据结构如下：
一般来说这个调研报告很好，提出的问题也是存在的。更专业，更值得EOS生态推广人去思考和改进。其实我在这里提到了一些改进
1)增加快速同步功能让更多人成为种子节点和API节点
。2)添加状态数据的机制不仅可以加快同步，还可以增强状态数据的一致性
3)BPs定期检查状态数据，及时发现同一事务产生不同状态数据的情况。
