Other considerations
There are a few other considerations to keep in mind apart from the previously mentioned aspects. They are briefly explained in the following sections.
Consensus, ACID properties, and CAP
A consensus model will never go to 0 because when NoSQL became the standard, various NoSQL systems solved their problems by understanding the CAP theorem, and the RDBMS enterprise community held steadfast to their ACID properties. Blockchain technology components and operational models aim to serve primarily as a transaction system. The distributed nature of the infrastructure and transaction processing tends to put the CAP theorem in high gear. It suggests that between the three desired properties of a transaction system—consistency, availability, and partition tolerance—at any given point, only one or two can be achieved. In the blockchain context, the CAP theorem implies that in the presence of a network partition, you must choose between consistency and availability. On the other hand, ACID properties—atomicity, consistency, isolation, and durability—constitute a set of properties of database transactions that are intended to guarantee validity even in the event of errors, power failures, and so forth. The technology design needs to consider the CAP and ACID principles when devising a system that can deliver industry and use case requirements.
CAP stands for consistency, availability, network partition tolerance:
- C – Consistency: Consensus guarantees only one truth of what happened and in one 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 tolerance: Consensus again prevents split-brain with conflicts when things get back together after a network partition.
ACID stands for atomicity, consistency, isolation, durability:
- A – Atomicity: The chaincode programming model is an all-or-nothing behavior that allows you to group activities together. It either all happens, or it doesn't.
- C – Consistency: I think the new world of NoSQL fudges this one. This means the same as the "C" in CAP.
- I – Isolation: Isolation indicates that two transactions are serialized, which is exactly what the block construction and chaining do.
- D – Durability: The chaining and replication all over the network ensure 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 co-located.
Attestation – SSCs are signed and encrypted
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 prove themselves to be genuine to a remote 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.
Use of HSMs
According to Wikipedia (https://en.wikipedia.org/wiki/Hardware_security_module), 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 plug-in card or an external device that attaches directly to a computer or network server.
It can be a real challenge to administer a high-security device like an HSM with sufficient security and controls. In fact, today's standards mandate certain methods and levels of security for HSM administrative (and key management) systems.
