EOS持有者请进来谈谈Whiteblock对EOS的负面影响 - 币安下载官方APP安卓

编辑：币安app官网下载安交易所app下载来源：互联网时间：2022-10-18

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

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

翻译过来就是EOS *** 框架分为三层，如下：

核心 *** 层

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

该层 *** 的节点CPU强、内存大、带宽高，通常有备份服务器。

接入 *** 层

在消费者层和核心层之间，对数据进行过滤和缓冲，保证核心层 *** 的高效运行。

访问 *** 层的节点有两种：API节点、种子节点。

1）API 节点

处理来自 cleos 的请求，执行事务和查询状态。同时会过滤交易，将好的交易广播给BP，减轻BP的负载。API 节点使用 *** 和负载平衡模块来做到这一点。简单来说，API Node 是 BP Node 的盾牌和防毒面具。每个生产者节点应至少有一个关联的 API 节点

2）种子节点

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

EOS持有者请进来谈谈Whiteblock对EOS的负面影响-第1张图片-币安app官方下载最新版

消费者 *** 层

任何使用区块链的用户，包括直接通过 cleos，间接使用一些与区块链交互的应用程序。比如我们经常使用 cleos -u 发送，这个操作就是消费 *** 层的用户通过 API Node 访问 *** 。

研报中对EOS *** 的分析相当准确，但得出的结论却涉嫌故意夸大负面因素。首先，EOS不限制种子节点和api节点。任何 cleos 用户都可以部署 API Node 和 Seed Node，使消费 *** 层和接入 *** 层合并，用户无需使用文中提到的 *** 。请求集中访问 *** 层的问题。当然，由于EOS的TPS高，数据量巨大，普通用户无法部署API和种子节点。因此，目前大多数 cleos 用户实际上是通过其他人的 API 节点发起和处理交易。存在一定的中心化问题。但这是因为EOS的TPS高，EOS的初期发展，不是 EOS 本身的设计。如果以太坊的 TPS 很高，也会存在这个问题，即使是现在，以太坊的大部分用户（消费者 *** 层）都是通过交易所、钱包等中心化节点访问以太坊 *** 的。是否存在相同的情况？中心化呢？所以这个问题实际上是一个生态问题。

其次，EOS *** 的核心层确实有点中心化，有 21 个超级节点，而以太坊 *** 的核心层确实可以是任何节点，但实际上以太坊 *** 的核心层几乎只是几个大矿矿池，所以问题归根结底是DPOS和POW的问题，也就是投票和算力的集中比较。所以，当以太坊支持 POS 时，请再做一份分析报告。

起初看到这种“无密码技术”是很奇怪的。之一印象就是这个EOS研究报告的作者太“牛”了。看完研究报告的英文原文，我才明白了这个观点的真正含义。在原文中，作者是说 EOS 不通过密码技术验证状态数据。其实总结一下，EOS的状态数据是不在链上的eos 区块链新闻，状态数据也不是通过以太坊状态树的方式保存和验证，然后通过媒体翻译传播，从而使EOS不使用密码学。研究报告中的相关文字如下：

这个说法是正确的，EOS状态数据不在链上，未经验证。一个月前我也写了一篇文章分析隐患，但是做了建设性的分析，提出了一些意见，而这份研究报告在很多地方都提到了这个观点（上图红色部分），并把作为一个严重的设计错误并试图贬低 EOS，这有点过头了。接下来，我们来分析一下这个状态数据是否没有经过验证，无法上传到链上。真的有这么大的缺陷吗？

区块链的数据分为两类，一类是交易原始数据（区块包含交易），另一类是状态数据。交易执行会改变状态数据，所以理论上，有了交易数据，状态数据就可以完全恢复。 *** C 中的状态数据是 UTXO( )， *** C 中的状态数据是一堆树，EOS 中的状态数据是一个数据库表。

将交易数据打包在区块中eos 区块链新闻，生成交易树生成根并保存在区块头中，然后将区块头哈希作为链表组成区块链，从而维护整个交易历史数据。只要任一节点获得相同的区块头哈希，就绝对可以肯定这些节点收到了相同的交易数据。在 EOS 中，当一个区块之后产生了 15 个新区块，那么这个区块被 BP 的 2/3（15/21 > 2/3)，也代表了之前的所有区块）的交易数据完整并且准确的记录在2/3BP上，而且都是一样的，自然是不可逆的。但是到了状态数据就不一样了，即使每个节点得到的交易都是一样的，但是，执行这些事务的结果不一定相同，因为执行事务就是执行程序，程序可能有bug，可能导致各个节点的状态数据不一致。同时，单个超级节点也可以独立修改状态数据。区块链不怕数据不一致，而是怕不一致找不到，所以没有办法选择，最终达成确定性共识。例如，在以太坊中，如果生产者***成功，然后执行交易 T1 得到错误状态 S1（伪造或 BUG），区块 B1 包含 T1 和 S1 数据。其他节点收到 B1 块后，执行交易 T1 后得到真实状态 S2，所以其他节点会认为 B1 块是非法的而被丢弃。

在 EOS 中，每个区块中的交易都是独立执行并获得状态数据，但这些状态数据不共享，每个节点无法验证这些节点的状态数据是否一致。EOS 的章程规定，所有决议均需获得 2/3 的节点批准方可生效。例如，一笔交易需要经过后续 15 个区块的确认，即经过 2/3 的超级节点间接批准，才能成为不可逆区块。但是，由于状态数据不上链且未经验证，单个超级节点可以任意修改任何状态数据（如 EOS 代币余额），因此使用节点服务的用户可能会得到错误的数据。一个典型的例子是单个超级节点说我可以单独行动来冻结一个帐户。当然，添加一些改进后，这个问题不是什么大问题。比如每个用户不使用超级节点的API Node，而是自己部署Api Node和Seed节点，自己生成状态数据，由于交易数据必须是2/3的共识，所以每个用户获得的交易数据必须一致，不考虑程序bu *** 生的状态数据也必须一致，因此单个超级节点的任意状态数据修改行为不会影响用户。因此，基于今天的讨论，我个人认为必须提出私下修改状态数据的行为，例如冻结EOS上的账户，并将2/3 BP共识上链，以确保所有节点状态数据有 2/3 节点共识。同时，