如何解释“我篡改了区块链”的问题

作者：FISCO BCO首席架构师

来源：FISCO bcos开源社区

颂歌

从isual China下载CSDN

区块链数据的“全局一致性”和“不易篡改”这两个特点已经广为人知，这是区块链创造“信任”的基石。为了达到这两个效果，区块链的共识、同步、验证等技术细节都可以写得很好，本文将从“我篡改了区块链数据”开始。

“我篡改了区块链数据”

FISCO bcos开源联盟链社区现在非常活跃，每天都会有很多讨论。我们还将有兴趣研究和挑战区块链如何“难以篡改”我们注意到，特别是在FISCO bcos支持MySQL数据库作为数据存储引擎后，一段时间后，一些学生在小组中问道：“我手动修改了连接到我节点的数据库中的某个状态数据。这是在篡改区块链数据吗？”

例如，直觉上，链上有一个智能合约来管理特定资产的余额。在数据库契约表中，协商一致后，Alice的余额为100。此时，有人打开MySQL客户机，找到与契约对应的表，并将Alice的余额更新为10000。

这时，他说：“你看，我打了合同查询接口，发现爱丽丝的余额是1万。这是错误的。而且，链仍然没有块，这根本不是防篡改的。

初步分析与解答

为什么最近这样的问题增加了？我们分析和推测，主要原因是MySQL数据库用户有一个良好的基础和成熟的系统，为用户提供友好的命令行或图形交互工具，FISCO BCOS提供了一种表格式的合同开发模式。表格结构设计清晰直观。对于用户来说，一方面更容易理解和管理，另一方面，更新甚至删除都很简单。

下图只是示例数据，它使用ktable合同方法创建了一个名为t_K_U的新方法，系统自动将“U”添加到节点前缀的合同表中，可见，此表结构和数据一目了然。

以前，只有leeldb或rocksdb用作存储引擎。这两个文件数据库交互工具相对较少。他们在用户面前的存在感很弱，操作也相对模糊。它们主要通过API编程访问。这些数据是用肉眼很难分辨的散列键来处理的。修改数据库的案例较少（但并非不可能）。

因此，热点问题出现的前提是用户可以更容易地修改底层数据，而不是以前不存在的问题。

此时，我们将建议用户尝试为Alice的余额启动一个事务，例如给Alice充值或允许Alice转账。在这种情况下，修改了数据的节点将无法参与协商一致。因为在这个节点上计算的Alice余额与其他节点的余额不同，其他节点仍然计算100的余额，而不是10000。显然，结果并不一致。

回顾pbft容错模：定义“F”为容错节点的数目，网络中的一致性节点总数应等于或大于3F+1。换句话说，如果链中有四个一致性节点，则容错f=1；当一致性节点总数为7时，f=2；依此类推。

如果未修改的节点数满足pbft要求的2F+1个数，则链仍然可以被阻塞。但是，一旦一个事务涉及脏数据，修改后的节点将不再能够达成共识并与链同步，这相当于被放弃。这种节点可以称为“拜占庭节点”，即作恶或犯错的节点。具有节点访问控制能力的联盟链甚至可以隔离拜占庭节点。

另一种可能是，数据库中的数据已被手动修改，但数据的一个副本刚刚缓存在节点内存中，而节点内存尚未修改。因此，通过节点对这些数据的查询和处理仍然是正常的，即使是数据库中被修改的数据也会得到正确的结果。但是，这是一个概率事件，它取决于缓存的大小，并且此时的数据包包含数据项。

*注意：对于使用POW或其他一致性机制的链，容错模不同，但容错范围内的少数节点被篡改，不会影响链的一致性。

“整个联盟链能被篡改吗”

有学生可能会继续挖矿问题的底部：“那我再修改几个节点的数据是不是被篡改了？”一般来说，提出这个问题的学生是他自己部署的一个开发和测试环境。所有节点都在他手中，所以你可以随意更改它。

在现实的联盟链环境中，节点由不同的组织控制。要进行修改，必须先入侵他人网络，获得服务器和数据库的权限，启动修改，然后完全退出。事实上，在注重安全保护的商业环境中，这是一件非常困难和几乎不可能做到的事情。

从机制粒度的角度来看，单个机制所掌握的节点数应该小于容错一致性算法的数目。例如，如果链中有7个共识节点，那么单个组织所拥有的共识节点数量不应超过2个。这样就可以避免强行修改组织中的节点数据，或者一个组织中的所有节点意外出错或脱落（如机房光纤被切断），导致链路无法阻塞。

真的没有办法防止“本地篡改”吗？

考虑到区块链数据的本地验证机制，如块间的哈希关系、状态的Merkle树结构、共识节点的签名等，似乎有一定的概率可以在本地检测到异常数据。

但是，如果篡改者更熟悉区块链数据的结构和本地验证逻辑，也可以根据数据验证关系，从状态值开始，对所有的关键数据如Merkle树、块哈希等进行修改。

更为彻底的是，从genesis块开始，所有块、系统配置（对于pow，可以修改挖矿难度来加速块）、pbft共识制造者列表等，都是按照他的逻辑来改变的，使得这个本地数据链仍然是自洽的，只是无法与其他节点达成共识。

这听起来是一项艰巨的工作，但对于一个有决心和能力的篡改者来说，更改本地数据并不困难。困难的是改变其他机构的数据。

到这一点，就相当于一个人的铁心“骗自己”，而神仙也没办法。一旦修改本地数据的权限被赋予了错误的人，在最坏的情况下，整个链中没有一个字节是正确的。

然而，无论当地的数据有多错误，它只会影响到我们自己，而不会影响到别人。一旦我们与其他节点达成共识，我们就会被发现甚至受到惩罚。整个效果会有点掩盖。

“为什么区块链不能阻止我篡改数据？”

此外，学生会问：“为什么区块链不能立即发现并阻止我篡改数据？也许我不是故意的。坦率地说，这有点过于期待区块链。

区块链系统不是万能的，也不是万能的。区块链不会阻止用户操作自己的服务器、软件、数据库等，就像法律不能也不应该阻止你在家打破杯子一样。

本质上，共识机制可以检测并拒绝被篡改的数据，以确保链中剩余的大部分健康节点继续达成一致。但是，如果节点不在本地参与一致性数据，协商机制就无法达成。

那么，为什么区块链不能主动检测并纠正错误，以确保每个节点上的数据一致性？首先，链上的数据非常复杂。用户直接登录数据库手动修改少量数据。区块链节点不知道哪些数据被修改，无法触发检查。

如果区块链系统定期检查所有数据，并将所有数据与其他节点进行比较，可以想象，网络、磁盘和计算开销将非常高。

关键是这并不能解决问题，因为即使脏数据在从数据篡改到检测的时间窗口内只存在几十毫秒，如果不幸有应用程序查询数据，仍然会得到被篡改的结果。对于要求苛刻的服务，后检测可能不是最佳选择，因为它可能会造成业务损失。那时候，你最多能做的就是报警和纠正。

同时，还可以将BIN的运行速度与其它辅助检测机制相结合，提高数据库的运行速度和响应速度。还有一些方法。如上所述，性能价格比低，问题没有完全解决。只有当数据对数据修改极其敏感，企业接受延迟发现和修改时，才将其视为补救措施。我们将这一部分划分为运营管理工具，并根据场景需求进行实现。

另外还有一种方法可以部分解决查询问题：F+1查询。也就是说，在查询数据时，无论是块数据还是合同状态数据，都可以多查询几个节点，查询节点数大于F。

如果链中有7个节点，f=2，用户会继续发送一个网络请求，查询其他机构的两个节点，一共三个节点，如果得到的数据一致，说明数据必须正确，否则，这三个节点一定有问题。

但要执行F+1查询，前提是其他组织已经打开了查询接口权限，这样就可以连接到查询了。在许多具有严格安全保护的联盟链中，只开放节点间P2P互连的网络端口，不易向其他组织提供数据查询权限。此外，网络上多个查询的异步性、及时性、成功率和性能也会带来更多的变数。

综上所述，对于节点的本地数据，就像土拨鼠或假数据（发出交易参与共识，或进行F+1查询），区块链全局共识和容错机制可以发现，如果没有假头，只蹲在用户硬盘上，用户只能负责。

后记

区块链通过网络游戏和多方验证，实现了整个网络的容错和反腐败，区块链同步到每个节点的本地数据需要用户妥善管理和保存。

从信任的角度出发，向所有用户传递信任。如果他们不敢相信，那就意味着系统和数据管理存在漏洞，更别说修改数据了。在本地系统的整个环节，包括区块链软件、SDK和业务服务，都有可能出错和篡改。在这样的环境下，有什么样的信任？

节点持有者必须非常谨慎。首先，他们不应该手动更改数据。其次，关键是要建立一个全面的系统，包括管理策略和技术保护，如主机访问控制、数据库登录和操作权限控制、操作审计、日志审计等，以避免未经授权的访问、自窃取或外部渗透。

如果出现数据错误，区块链比中心化式系统更好。它可以通过与其他节点的相互验证来检测。在这种情况下，要进行警示、核实、纠正和问责。在有条件和必要的前提下，应该使用F+1查询方法，为查询操作增加一点保险。

此外，建议定期将节点数据备份到安全的脱机设备。这样，无论出现意外或人为的数据问题，数据仍然可以从冷数据中快速恢复，以保证一定的RTO（恢复时间目标）和RPO（恢复点目标）。

然而，区块链的稳健性在于，无论单个角色如何抛掷自己的节点和数据，都不会对全局产生影响，只有修饰符自身受损。无论巢中发生什么，链还是轻的，“全球一致性”和“不可篡改”的定律依然成立，而链仍然是信任的锚，这就是区块链的魅力所在。