其他考虑因素1.共识性、ACID 属性和 CAP共识性模型绝不会消失，原因如下。当 NoSQL 成为标准时，各种 NoSQL 系统通过理解此 CAP 理论来解决它们的问题，而 RDBMS 企业社区仍坚持使用他们的 ACID 属性。区块链能够提供各种原语来突破 CAP 和维护 ACID。以下是一些考虑因素：
CAP- C – 一致性
一致性确保仅有一个已发生事件的事实以及事件发生的顺序。 - A – 可用性
事实上对区块链的所有调用都是异步的，这有助于“调用”应用程序取得进展，同时确保共识性和耐久性（链锁也能保证这一点）。 - P – 网络分区
在执行网络分区后一起返回数据时，共识性还能预防存在冲突的分裂脑情形。
ACID- A – 原子性
链代码编程模型是一种整体式行为，它允许您将活动分组到一起。这些活动要么全部发生，要么都不发生。 - C – 一致性
我认为新的 NoSQL 领域回避了这个问题。它的含义与 CAP 中的“C”相同。 - I – 隔离性
这意味着两个事务是序列化的，这正是区块构造和链锁在做的工作。 - D – 持久性
整个网络中的链锁和复制可确保在一个或多个节点发生故障时您不会丢失数据。正因如此，每个人都想引入一个节点。这也是所有这些节点不应放在同一处的原因。
2.证据 – SSC 被签名和加密安全服务容器 (SSC) 中的软件、操作系统、虚拟机管理程序和 Docker 容器镜像无法修改。证书可以包含在 SSC 中，以便能向远程方证明它自己是真实的。例如，在构建 SSC 时包含 SSL 证书，有助于确保我们在与一个真实实例进行通信，因为 SSL 证书在 SSC 中始终受到保护（加密）。
3.HSM 的使用依据 ，硬件安全模块 (HSM) 是一种物理计算设备，负责保护和管理用于实现强身份验证的数字密钥，并提供密码处理功能。这些模块历来采用插入卡或外部设备的形式，可直接附加到计算机或网络服务器上。
对于像 HSM 这样的高安全性设备，管理时也很难确保足够的安全和可控。事实上，现行标准要求对 HSM 管理（和密钥管理）系统强制执行某些安全方法和安全级别。 |
