以太坊中，每个区块交易执行后，会更新状态数据并生成一个merkle root(可以看成是状态数据摘要)，同时这个state merkle root也会保存在BlockHeader里，也就说以太坊的状态数据是上链的。所以后面节点在replay block交易时可以很容易验证出本地的状态数据是否和全网的状态数据一致。
但是EOS不一样，EOS只有transaction和action merkle，并没有state(状态)merkle。EOS的状态数据(数据库表里的数据)保存在数据库中，执行区块交易并更新状态后，并没有将这个状态数据保存在链上。因而网络中的节点在replay 交易后，并不知道本地的状态数据是否和BP及其他节点的状态数据一致。
总结为一句话就是EOS状态数据不上链。
-
状态不一致为何出现
正常来说，对于相同的输入(交易数据), 所有节点(包括21个超节点)通过执行这些交易应该会输出相同的状态数据。但是有代码，就有可能有BUG，当出现BUG时就有可能“同步节点”生成了和“生产节点”不一样的的输出，由于缺失状态数据检验，同步节点并不知道出现了这种不一致性错误，因而这个BUG就没法及时发现，进而可能隐藏很久，最后可能会导致很严重的问题。
比如A发起一个交易，A给RAM购买登记合约转账1000EOS购买RAM，生产节点在执行这次转账交易并没有真正转账，但是如果EOS系统存在BUG或者同步节点eosflare.io本身的BUG，eosflare.io的同步节点在同步交易数据并执行该交易时却真正转账了。然后，B通过查询eosflare.io的转账记录，确认成功了，然后就给A买了相应量的RAM。然而事实上，数据以超级节点为准，由于这个不一致性，B白白损失了替A购买RAM的资产。如果在以太坊等有状态默克树的系统中，eosflare.io在执行完后通过检测本地状态数据merkle root即可发现，本地数据和超级节点的状态数据不一致，就会显示A转账给B的交易异常，并会上报EOS社区及时修复这个BUG。
-
状态不一致怎么解决
到了这里，你可能会说，这种不一致性应该直接归类到代码的BUG啊，代码就应该保证所有机器执行相同交易得到相同结果，不能算到缺失merkle验证机制上。这种说法也对，但是在一般的分布式系统中，运行环境是可控(基本都是发行方部署的)，即代码的测试环境相对可模拟，因而测试基本能cover大部分case，但是区块链中，任何设备都可以成同步节点参与这个过程，靠EOS开发人在发布前测试各种环境是不现实的，且缺失状态merkle机制后，整个系统缺乏错误发现机制，会很难发现这类错误，相当于保护了BUG。正常情况下，此类BUG发生的几率是极低的，但是一旦发生，这些BUG可能长时间隐藏和被利用，更何况目前EOS发展初期，这种BUG可能性也许并没有那么极低。那么，如何主动发现不一致性呢？首先超级节点们可以周期性的检测各自状态数据是否一致，也许EOS BP们早就已经这样做了。然后，EOS社区可以开发一个状态比较工具并每隔一段时间公布一下当前网络的状态数据(相当于checkpoint)，同步节点们就可以使用这个工具来比对本地状态数据和公开发布的正确状态数据，进而尽早发现不一致性问题。当然这些都只是一种临时方案，最终还是需要其他的正规的自动化的检测机制。
-
痛苦的EOS数据同步
以上只是状态验证机制缺失的一个副作用，其实还有另外一个负面影响就是不容易实现快速同步。
随着EOS的不断运行，数据量是越来越大了，数据同步经常挂掉是常有的事，这个问题的一个核心原因是EOS缺少类似以太坊fast sync机制。fast sync模式下，本地节点是不需要replay交易的，而是直接从其他任意节点下载状态数据(数据库数据)，同步节点的负载大大降低。而EOS因为缺失状态数据检测机制，同步节点没法相信其他节点的状态数据，因此需要亲力亲为执行每个交易来获取状态数据，因而负载是很大的。这不，最近EOS已经提出了可信节点的概念，就是说社区会列出一些可信任的节点名单，这样同步节点不需要执行交易而是直接从可信节点下载状态数据即可，大大提高同步速度。但是这会导致海量同步节点同时连接这些可信节点，进而会导致这些节点压力山大，同时区块链行业，这种中心化的理念还是越少越好，一个本可以用代码来保证(merkle验证)的机制非得用人治来解决。
当然，我相信EOS社区最后肯定会也正在尝试解决这两个问题，只是希望能够快一点。
作者个人技术能力有限，如有错误请指点
尝试长按二维码关注公众号吧（^_^)
公众号:区块链斜杠青年
欢迎大家加我微信:itleaks
