10 选 1？页面模板成了第一个绊脚石
真的没有办法防“本地篡改”吗?考虑区块链数据本地验证的机制，比如区块之间的 Hash 关系、状态的 Merkle 树结构、共识节点的签名等，按数据的互验关系顺藤摸瓜进行检测，似乎有一定概率可以本地检测出数据异常。 但进一步想，对某个数据的查询，区块链的本地校验范围是有限的，一般不会超出单个区块或者一棵 Merkle 树，所以如果篡改者比较熟悉区块链数据的结构和本地校验逻辑，也可以顺着数据校验关系，从状态值开始，把 Merkle 树、区块 Hash 等关键数据全部改掉。 甚至更彻底地，从创世块开始，把所有的区块、系统配置（对于 PoW，可以修改挖矿难度以加速出块）、PBFT 的共识者列表等等，都按他的逻辑改一遍，这样这条本地数据链依旧是校验自洽的，只是无法和其他节点共识了。
这种改法，听起来需要不少力气活，但对于一个有决心、有能力的篡改者来说，改改本地数据这个事情其实并不难，难的只是去改别的机构数据而已。
复习下 PBFT 的容错模型：定义
如果未修改过数据的节点数满足 PBFT 要求的 还有一种可能性是，手动修改了数据库里的数据，但节点内存里还刚好缓存了一份副本，并没有被修改，所以通过节点对这个数据的查询、交易还是正常的，甚至会用正确的结果把数据库里被篡改过的数据覆盖掉，不过这是概率性事件，取决于缓存的大小和当时包含的数据项。 *注：对于采用PoW或其他共识机制的链来说，容错模型有所不同，但在容错范围内的少数节点被篡改，也不会影响链的共识。 “能否篡改整个联盟链”有的同学可能会继续刨根问底：“那我多修改几个节点的数据是不是就篡改了？”，一般提出这个问题的同学是面向他自己部署的开发测试环境，所有节点都在他手上，所以可以随便改。
在真实的联盟链环境上，节点分别掌握在不同机构手里，要修改，首先得侵入他人的网络、获得服务器和数据库权限、发起修改再全身而退。事实上，在注重安全防护的商业化环境里，这是非常艰难、几乎不可能做到的事情。 而之前只采用 LevelDB 或 RocksDB 作为存储引擎，这两个文件型数据库交互工具比较少，在用户面前的存在感不强，操作相对晦涩，主要通过 API 编程访问，数据用肉眼难以辨别的 Hash 键寻址，动手修改数据库的情形就少了一些（但也不是不可能）。 所以，热点问题浮出水面，前提是用户可以更方便地修改底层数据了，而不是这个问题之前不存在。
这时我们会建议用户试一下，针对 Alice 的余额，发起一个交易，比如给 Alice 充值，或者让 Alice 转账操作，这时，修改过数据的节点将无法参与共识。因为该节点上算出来的 Alice 的余额和其他节点结果不同，其他节点依旧按 100 的余额进行计算，而不是 10000，显然结果是对不齐的。 区块链数据“全局一致”、“难以篡改”这两个特性已经广为人知，是区块链营造“信任”的基石。为了达到这两个效果，区块链的共识、同步、校验等技术细节足可大书特书，而本文要从“我篡改了区块链数据”讲起。 “我篡改了区块链数据”FISCO BCOS 开源联盟链社区现在相当活跃，每天都会产生大量的讨论，大家也会饶有兴趣地研究和挑战区块链如何做到“难以篡改”。我们注意到，尤其在 FISCO BCOS 支持 MySQL 数据库作为数据存储引擎后，隔一阵子就有同学在群里问：“我手动修改了我节点连接的数据库里某个状态数据，这是不是就是篡改了区块链数据呢？” 直观地举个例，如链上有个智能合约，管理特定资产余额，在数据库合约表里，经过共识的 Alice 的余额本来是 100，这时有人打开 MySQL 客户端，找到那个合约对应的表，把 Alice 的余额更新成 10000。 这时他表示：“你看，我调用合约的查询接口，查出来 Alice 的余额确实是 10000，这就不对了嘛，而且，链还在出块，根本不防篡改嘛！”。 初步分析和解答为何这类问题最近多起来了？我们分析了下，猜想主要是由于 MySQL 数据库用户基础良好，体系比较成熟，给用户提供友好的命令行或图形化交互工具，FISCO BCOS 提供了一种表风格的合约开发模式，表结构设计得清晰直观，对于用户来说，一方面理解和管理起来更容易了，另一方面顺手更新甚至删除一下都是小意思。
下图仅为示例数据，采用 KVTable 合约方式，创建了名为 （编辑：烟台站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
