BlockChain
Essentially, a blockchain is built of code segments (blocks) arranged in sequence (or on a ‘chain’) – hence the name – and stored on a shared database. Each block is unique, encrypted and can only be created once. The blocks represent transactions made within the network and displayed on a shared ledger. Blockchain was originally created to deliver a decentralised currency, Bitcoin, that would require no third-party trust to process a transaction. However, in the context of SCS and Cleardapp™, it is important to decouple Blockchain from Bitcoin. Blockchain is simply a trust enabling technology which is used by both Cleardapp™, Bitcoin and many other services. Cleardapp™ builds an immutable chain of encrypted document and transaction hashes and stores them on a Corda R3 permissioned blockchain.
‘Smart Contract’
A ‘Smart contract’ is a computer protocol that executes the terms of a contract. It is not a legal contract, but a protocol designed to satisfy common contractual conditions (such as payment terms) and reduce the need for trusted intermediaries. In other words, it is a computer protocol capable of taking data input, processing it through a specified rule set and automatically taking any actions required of it as a result (such as payment) without the need for a third party to govern the process. (International Bar Association, 2019). An alternative tech name for a smart contract is ‘distributed application’, usually shortened to ‘dapp’.
Referential Integrity
All parties must be fully agreed that the relevant, legally enforceable paper agreements (the Contract/Master Services Agreement, the relevant PO etc) are honoured with each Cleardapp™ transaction. This legal prose requirement is handled by Cleardapp™ Referential Integrity. The built-in blockchain ‘notary’ technology guarantees the uniqueness of the transaction that is processed via a smart contract. But how is the legal integrity of the smart contract to be guaranteed when validation lies entirely in the Corda/notary environment? In the Cleardapp™ world, all parties to the transaction must be assured that the legal prose input parameters to the smart contracts are applied to the correct smart contract code which is, in turn, tied back to the correct PO and original master agreement. That is, the contracting parties must be fully agreed that the relevant, enforceable legal prose contained in the paper agreements is honoured and that end-to-end trust is asserted within Cleardapp™ for every Cleardapp™ transaction. This is effected by generating document hashes from the relevant agreement(s) and PO/SO which are stored on chain as a ‘master reference key’. When a new transaction is generated in Cleardapp on the IDS node, the copies of the signed Agreement(s) and PO/SO documents held by SCS are rehashed along with the smart contract input parameters in just the same way that the composite reference key was created . This creates the TRK or Transaction Reference Key. The TRK is compared with the original CRK and, if the two keys are identical, the referential integrity is validated, the transaction executes. The TRK is stored on-chain.
Private ‘permissioned’ blockchains v public ‘permissionless’ blockchains
As noted above, a blockchain is built of code segments (blocks) arranged in sequence (or on a ‘chain’) – hence the name – and stored on a shared database. Each block is unique, encrypted and can only be created once. The blocks represent transactions made within the network and displayed on a public ledger. Blockchain was originally created to deliver a decentralised currency, Bitcoin, that would have no central regulatory authority and require no third-party trust (eg, a bank) to process a transaction. This is a permissionless or public blockchain. For a transaction to be validated and committed to the blockchain in the Bitcoin ‘permissionless’ world, it must be approved by an energy intensive ‘proof of work’ process by multiple parties (called ‘miners’) who achieve validity consensus by solving a complex algorithm. This is necessary because the parties to the transaction are anonymous and therefore ‘trust’ has to be managed algorithmically. By contrast, the architecture underlying Cleardapp™ is a ‘permissioned’ blockchain.
SCS Cleardapp™ – a private, permissioned blockchain solution
Private blockchains differ from public blockchains in that they are permissioned and targeted at the enterprise rather than the individual. They embody the following features which describe the difference between public vs private blockchain: Controlled membership and access: Businesses allow only trusted nodes to join their enterprise blockchains.
- Controlled membership and access: Businesses allow only trusted nodes to join their enterprise blockchains.
- Performance at scale: It is not uncommon for large businesses to process 100,000’s of transactions per second (TPS).
- Resilience: They must have built-in redundancy, automated monitoring, and require minimal human intervention.
- Security and confidentiality: Enterprise blockchains need to encrypt data to ensure maximum security.
- Integration: Businesses have their systems of record (SOR) applications, which their enterprise blockchain will need to communicate with.
BlockChain
Essentially, a blockchain is built of code segments (blocks) arranged in sequence (or on a ‘chain’) – hence the name – and stored on a shared database. Each block is unique, encrypted and can only be created once. The blocks represent transactions made within the network and displayed on a shared ledger. Blockchain was originally created to deliver a decentralised currency, Bitcoin, that would require no third-party trust to process a transaction. However, in the context of SCS and Cleardapp™, it is important to decouple Blockchain from Bitcoin. Blockchain is simply a trust enabling technology which is used by both Cleardapp™, Bitcoin and many other services. Cleardapp™ builds an immutable chain of encrypted document and transaction hashes and stores them on a Corda R3 permissioned blockchain.
‘Smart Contract’
A ‘Smart contract’ is a computer protocol that executes the terms of a contract. It is not a legal contract, but a protocol designed to satisfy common contractual conditions (such as payment terms) and reduce the need for trusted intermediaries. In other words, it is a computer protocol capable of taking data input, processing it through a specified rule set and automatically taking any actions required of it as a result (such as payment) without the need for a third party to govern the process. (International Bar Association, 2019). An alternative tech name for a smart contract is ‘distributed application’, usually shortened to ‘dapp’.
Referential Integrity
All parties must be fully agreed that the relevant, legally enforceable paper agreements (the Contract/Master Services Agreement, the relevant PO etc) are honoured with each Cleardapp™ transaction. This legal prose requirement is handled by Cleardapp™ Referential Integrity. The built-in blockchain ‘notary’ technology guarantees the uniqueness of the transaction that is processed via a smart contract. But how is the legal integrity of the smart contract to be guaranteed when validation lies entirely in the Corda/notary environment? In the Cleardapp™ world, all parties to the transaction must be assured that the legal prose input parameters to the smart contracts are applied to the correct smart contract code which is, in turn, tied back to the correct PO and original master agreement. That is, the contracting parties must be fully agreed that the relevant, enforceable legal prose contained in the paper agreements is honoured and that end-to-end trust is asserted within Cleardapp™ for every Cleardapp™ transaction. This is effected by generating document hashes from the relevant agreement(s) and PO/SO which are stored on chain as a ‘master reference key’. When a new transaction is generated in Cleardapp on the IDS node, the copies of the signed Agreement(s) and PO/SO documents held by SCS are rehashed along with the smart contract input parameters in just the same way that the composite reference key was created . This creates the TRK or Transaction Reference Key. The TRK is compared with the original CRK and, if the two keys are identical, the referential integrity is validated, the transaction executes. The TRK is stored on-chain.
Private ‘permissioned’ blockchains v public ‘permissionless’ blockchains
As noted above, a blockchain is built of code segments (blocks) arranged in sequence (or on a ‘chain’) – hence the name – and stored on a shared database. Each block is unique, encrypted and can only be created once. The blocks represent transactions made within the network and displayed on a public ledger. Blockchain was originally created to deliver a decentralised currency, Bitcoin, that would have no central regulatory authority and require no third-party trust (eg, a bank) to process a transaction. This is a permissionless or public blockchain. For a transaction to be validated and committed to the blockchain in the Bitcoin ‘permissionless’ world, it must be approved by an energy intensive ‘proof of work’ process by multiple parties (called ‘miners’) who achieve validity consensus by solving a complex algorithm. This is necessary because the parties to the transaction are anonymous and therefore ‘trust’ has to be managed algorithmically. By contrast, the architecture underlying Cleardapp™ is a ‘permissioned’ blockchain.
SCS Cleardapp™ – a private, permissioned blockchain solution
Private blockchains differ from public blockchains in that they are permissioned and targeted at the enterprise rather than the individual. They embody the following features which describe the difference between public vs private blockchain: Controlled membership and access: Businesses allow only trusted nodes to join their enterprise blockchains.
- Controlled membership and access: Businesses allow only trusted nodes to join their enterprise blockchains.
- Performance at scale: It is not uncommon for large businesses to process 100,000’s of transactions per second (TPS).
- Resilience: They must have built-in redundancy, automated monitoring, and require minimal human intervention.
- Security and confidentiality: Enterprise blockchains need to encrypt data to ensure maximum security.
- Integration: Businesses have their systems of record (SOR) applications, which their enterprise blockchain will need to communicate with.