产业气象站|| 区块链，如何解释“我篡改了区块链”这个问题导读：区块链数据“全局一致”、“难以

文章图片
导读：区块链数据“全局一致”、“难以篡改”这两个特性已经广为人知，是区块链营造“信任”的基石。
区块链数据“全局一致”、“难以篡改”这两个特性已经广为人知，是区块链营造“信任”的基石。为了达到这两个效果，区块链的共识、同步、校验等技术细节足可大书特书，而本文要从“我篡改了区块链数据”讲起。
“我篡改了区块链数据”
FISCOBCOS开源联盟链社区现在相当活跃，每天都会产生大量的讨论，大家也会饶有兴趣地研究和挑战区块链如何做到“难以篡改” 。我们注意到，尤其在FISCOBCOS支持MySQL数据库作为数据存储引擎后，隔一阵子就有同学在群里问：“我手动修改了我节点连接的数据库里某个状态数据，这是不是就是篡改了区块链数据呢？”
直观地举个例，如链上有个智能合约，管理特定资产余额，在数据库合约表里，经过共识的Alice的余额本来是100 ，这时有人打开MySQL客户端，找到那个合约对应的表，把Alice的余额更新成10000 。
这时他表示：“你看，我调用合约的查询接口，查出来Alice的余额确实是10000 ，这就不对了嘛，而且，链还在出块，根本不防篡改嘛！” 。
初步分析和解答
为何这类问题最近多起来了？我们分析了下，猜想主要是由于MySQL数据库用户基础良好，体系比较成熟，给用户提供友好的命令行或图形化交互工具， FISCOBCOS提供了一种表风格的合约开发模式，表结构设计得清晰直观，对于用户来说，一方面理解和管理起来更容易了，另一方面顺手更新甚至删除一下都是小意思。
下图仅为示例数据，采用KVTable合约方式，创建了名为t_kv_node的合约表，系统自动加了u_前缀，可见，这个表结构和数据一目了然。

文章图片
而之前只采用LevelDB或RocksDB作为存储引擎，这两个文件型数据库交互工具比较少，在用户面前的存在感不强，操作相对晦涩，主要通过API编程访问，数据用肉眼难以辨别的Hash键寻址，动手修改数据库的情形就少了一些（但也不是不可能）。
【产业气象站|| 区块链，如何解释“我篡改了区块链”这个问题】所以，热点问题浮出水面，前提是用户可以更方便地修改底层数据了，而不是这个问题之前不存在。
这时我们会建议用户试一下，针对Alice的余额，发起一个交易，比如给Alice充值，或者让Alice转账操作，这时，修改过数据的节点将无法参与共识。因为该节点上算出来的Alice的余额和其他节点结果不同，其他节点依旧按100的余额进行计算，而不是10000 ，显然结果是对不齐的。

文章图片
复习下PBFT的容错模型：定义f为可容错节点数，网络中共识节点总数应等于或多于3f+1 。即链上有4个共识节点时，可容错的f=1；共识节点总数为7个时， f=2 ，以此类推。
如果未修改过数据的节点数满足PBFT要求的2f+1的数量，链依旧可以出块。但被修改过的节点，一旦有交易涉及脏数据，就像踩到了雷一样，从此再无法与链共识、同步，相当于被抛弃了。这种节点可以称为“拜占庭节点” ，即作恶或出错的节点，具备节点准入控制能力的联盟链甚至会将拜占庭节点隔离出去。
还有一种可能性是，手动修改了数据库里的数据，但节点内存里还刚好缓存了一份副本，并没有被修改，所以通过节点对这个数据的查询、交易还是正常的，甚至会用正确的结果把数据库里被篡改过的数据覆盖掉，不过这是概率性事件，取决于缓存的大小和当时包含的数据项。