There are a few other considerations to keep in mind apart from the previously mentioned aspects. They are briefly explained in the following sections.

A consensus model will never go to 0 because when NoSQL became the standard, various NoSQL systems solved their problems by understanding this CAP theorem, and the RDBMS enterprise community held steadfast to their ACID properties. Blockchain might well provide the primitives to break CAP and maintain ACID. Here are some thoughts.

Cap stands for:

• C—Consistency: Consensus guarantees only one truth of what happened and in what order
• A—Availability: The fact that all calls to the blockchain are asynchronous allows the invoking application to make progress while ensuring consensus and durability (chaining also guarantees this)
• P—Network partition: Consensus, again, prevents split-brain with conflicts when things get back together after a network partition

ACID stands for:

• A—Atomicity: The chaincode programming model is an all-or-nothing behavior, which allows you to group activities together. Either everything happens, or it doesn't.
• C—Consistency: We believe the new world of NoSQL fudges this one. I believe this means the same as the C in CAP.
• I—Isolation: Isolation indicates that two transactions are serialized, which is exactly what block construction and chaining does.
• D—Durability: The chaining and replication all over the network ensures that if one or more nodes go down, data won't be lost. This is why everyone wants to bring a node and why those nodes should not be not co-located.

In secure service containers (SSCs), the software, operating system, hypervisors, and Docker container images cannot be modified. Certificates may be included in the SSC so that they can probe themselves into being genuine to a remote a party. For example, including an SSL certificate when building SSCs helps ensure that you're speaking with a genuine instance, since the SSL certificate always stays protected (encrypted) within the SSC.

According to Wikipedia, a hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plugin card or an external device that attaches directly to a computer or network server.

Administering a high-security device such as an HSM can be a real challenge in relation to sufficient security and controls. In fact, today's standards mandate certain methods and levels of security for HSM administrative (and key management) systems.