Design considerations for blockchain solutions

In this section, we'll look at the core building blocks for blockchain solutions and then examine some additional capabilities that should be considered.

Four core building blocks

Blockchain solution proposals typically include the following four building blocks:

• A shared ledger: The shared ledger appends only the distributed transaction record. Bitcoin blockchain was designed with the intent to democratize visibility; however, with blockchain, consumer data regulations also need to be considered. Using a properly configured SQL or NoSQL distributed database can achieve immutability or append only.
• Cryptography: Cryptography in a blockchain ensures authentication and verifiable transactions. Blockchain design includes this imperative because of the computational hardness assumption and a focus on making encryption harder for an adversary to break. This is an interesting challenge with Bitcoin blockchain because of the economic incentive and its system design. When you're working in a less democratic or permissioned business ledger network, considerations around cryptography change.
• Trust systems or consensus: "Trust systems" refers to using the power of the network to verify transactions.

  Trust systems are central to blockchain systems; they are at the heart of blockchain applications. We think trust system is the preferred term over "consensus system" because not all validation is done through consensus. This foundational element of trust dictates the overall design and investment in a blockchain infrastructure. With every new entrant in the blockchain space, the trust system is modified, forming variations that are specialized for specific blockchain use cases.

  Trust, trade, and ownership are staples of blockchain technology. For intercompany transactions, the trust system governs transactions for trade between participating companies.

  There's still much work needed to define the best trust system for specific use cases, like P2P and sharing economy models with B2B models.

• Business rules or smart contracts: Smart contracts are the business terms that are embedded in a blockchain transaction database and executed with transactions. This is the rules component of a blockchain solution. It is needed to define the flow of value and state of each transaction.

The following use diagram gives us a good idea of these concepts:

Figure 1.2: Blockchain building blocks

The four building blocks are generally accepted and well understood. They have existed for decades prior to blockchain. Shared ledgers are an evolutionary change, similar to the move to computer-based spreadsheets, but the underlying business rules stay the same.

Additional capabilities to consider

What else should be included in blockchain proposals, especially those within enterprises? The following is a non-exhaustive list of other capabilities to consider:

• Auditing and logging: Including auditing and logging in a blockchain solution can help address regulations for the purposes of non-repudiation, technology root cause analysis, fraud analysis, and other enterprise needs.
• Enterprise integration: It's also worth considering how the solution will be integrated into the enterprise:
  • Integration with the incumbent systems of record (SoR): The goal here is to ensure that the blockchain solution supports your existing systems, such as CRM, business intelligence, reporting and analytics, and so forth.
  • Integration as a transaction processing system: If you want to preserve the SoR as an interim approach to adopting blockchain, integrating it as a transaction processing system makes sense.
  • Design with the intent to include blockchain: If you intend to share some or part of your data with other enterprises to achieve your business goals, consider designing with your existing system's architecture in mind, as that will accelerate enterprise adoption of blockchain solutions with appropriate data governance. This is because the current data and application architecture will be able to adapt to blockchain-driven transaction processing.
• Monitoring: Monitoring is an important capability for addressing regulations and ensuring high availability, capacity planning, pattern recognition, and fault identification.
• Reporting and regulatory requirements: Being prepared to address regulatory issues is also very important, even for interim adoption of a blockchain as a transaction processing system. It's recommended that you make connectors to your existing SoR to offload reporting and regulatory requirements until blockchain is enterprise aware, or the enterprise software is blockchain aware.
• Enterprise authentication, authorization, and accounting requirements: In a permissioned enterprise world (unlike permissionless Bitcoin blockchain), all blockchain network participants should be identified and tracked. Their roles need to be defined if they are to play a part in the ecosystem.

Let's move on to look at the fundamentals of the secure transaction processing protocol.