Blockchain provides a trusted, independent, and cost-efficient mechanism for multi-party transactional records management. There are inherent problems with the public DLT, particularly around the pseudonymity of the parties identities, as well as privacy and confidentiality. We can leverage additional enterprise technologies to mitigate this. I’ll cover this in the solution architecture.
Blockchain stores a cryptographic hash of the data, workflow processes and signatures for each record, rendering them effectively immutable, more valid, more authentic and more reliable. Blockchain is appealing to auditors and litigators as it effectively certifies corrupt free data as proof or record.
Blockchain technology could also be used to verify the workflow steps that a record went through during its creation and management. The technology can create a cryptographic hash of each step effectively creating an immutable proof of process for the record.
Blockchain is an essential technology for records management professionals to understand because it has broad implications for securing and authenticating intellectual property at lower cost and higher efficiency. It’s important to point out that a records repository can store any digital object including audio, video or even software. A cryptographic hash of the record can be stored on the blockchain together with a time stamp, serving effectively as proof of copyright.
Blockchain also provides for an advantage over legacy centralized digital signature technologies. The signatures, fingerprints, time stamps created for authentication purposes, are stored on the distributed ledger providing proof of data integrity and authenticity without the need of a third party.
Scenario
This is a simple workflow that describes how the proposed solution architecture can be leveraged to synchronize the smart contract with the contract records for multiple parties.
Ann uploads a contract record into the records management repository, essentially a document library and generates a URL (hyperlink) for the document.
Ann digitally signs the contract using a blockchain API and generates a unique cryptographic hash for the document.
Ann configures a workflow as the contract proposer and configures Bob as the reviewer.
When Ann clicks SAVE, a smart contract proposal is created on the permissioned distributed ledger. She includes as properties, the cryptographic hash and document URL as unique references.
Bob receives an email notification with a link to review the contract record. Bob is prompted to accept or reject the contract proposal.
Bob accepts the contract proposal and is redirected to sign the contract record.
After signing the contract record, the original smart contract is archived and a new fully executed contract is created on the distributed ledger with the two parties having entered voluntarily into the contract.
The smart contract is now synchronized with the contract record, joined by a reference to the hash and the document URL.
Solution Architecture
The architectural components:
- Smart Contract Workflow Functionality Blockchain Permissioned Distributed Ledger.
- Smart Contract Application Functionality (Software as a Service).
- Enterprise Records Management Portal (SharePoint Online or On Premise).
Smart Contract Workflow Functionality
Ideally this would be smart contract language for modeling rights and obligations for multi-party business processes in any business domain, providing high integrity and privacy guarantees. The smart contracts would encode the rights of the parties as choices that they can exercise, and obligations as agreements that they agree to.
A Permissionless distributed ledger technologies conducts transactions pseudonymously. Identities of parties can be hard to establish. Regulatory compliance dictates that parties to a transaction are identifiable. The smart contract workflow functionality provides for a permissioned ledger, reinforcing the essential properties of a smart contract:
- Proof of Rights and Obligations
- Confidential Execution
- Evidentiary Trail
- Formally Verifiable
The smart contract programming language should be intuitive, and support formal methods for catching design time errors. The language should also be accessible enough for lawyers and contract professionals to at least understand, if not write. The next illustration shows how a design time error is caught and displayed, warning the developer that the smart contract is not valid due to a missing authorization from the second party to the contract.