Blockchain frameworks 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 semantics.
- Cryptography: Cryptography in a blockchain ensures authentication and verifiable transactions. Blockchain design includes this imperative because of the focus on assuming computational hardness and 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 refer to using the power of the network to verify transactions. Trust systems are central to blockchain systems in my view; they are at the heart of blockchain applications, and we believe trust system is the preferred term over consensus system since 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 inter-company transactions, the trust system governs transactions for trade between participating companies. Much work still needs to be done to define the best trust system for specific use cases, such as P2P and sharing economy models with B2B models.
The following use diagram gives a good idea of these concepts:
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 have stayed the same.
What else should be included in enterprise blockchain proposals? Here is a non-exhaustive list of other capabilities to consider:
- Auditing and logging: Including auditing and logging in a blockchain solution can help with addressing 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 system of record as an interim approach to adopting blockchain, integrating it as a transaction processing system makes sense
- Design with the intent to include blockchain: The path of least disruption to your existing systems will accelerate enterprise adoption of blockchain
- 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 blockchains), 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.