This post aims to look at some of the key features of the Chain Open Standard, a permissioned blockchain, specifically its consensus mechanism.
Blockchain startup Chain recently released an open source, permissioned blockchain built in collaboration with 10 global financial firms and telcos. This platform is made for financial applications that require high scalability ( > thousands of transactions per second), robust security and near absolute privacy. Blockchains must be built for the regulatory requirements of these institutions as well. These are attributes the financial services sector requires. If speed is the key characteristic of this platform, network stability becomes very important in any solution designed. Chain was built with this design assumption in mind.
Partners in the project include Capital One, Citi, Fidelity, First Data, Fiserv, Mitsubishi UFJ, Nasdaq, Orange, State Street and Visa, all of whom have contributed to the technology. This platform is being called the Chain Open Standard. Chain Core is the software implementation of the Chain Open Standard and is designed to run for enterprise IT environments.
Note: Chain Core is the name Chain has given to nodes on its platform.
Consensus mechanism: simplified Byzantine fault tolerance (SBFT)
In SBFT, one designated block generator collects and validates proposed transactions, periodically batching them together into a new-block proposal. Consensus is provided by a generator that applies rules (validates) agreed to by the nodes (chain cores) to the block and designated block signers. Other (multiple) designated block signers ratify the proposed block with their signatures. All network members know the identities of the block signers (permissioned blockchain) and accept blocks only if signed by a sufficient number of signers. A block signer validates all transactions in each block and adds a signature. Only blocks with sufficient signatures are accepted into the chain. This attempts to prevent the double-spending problem by attempting to ensure competing transactions get resolved.
By using one generator (master replicator) in a trusted, private environment, this effectively allows for the kind of scale and speed needed for transactions, and for the signers to validate transactions. These signers are configurable, meaning they can be added/removed from the system at any time. The same goes for the nodes (chain cores) in the network. They can be added/deleted, since it’s a private network, and this adds an extra layer of security particularly when dealing with what could be a malicious actor.
As a result of using one generator instead of multiple generators, synchronisation doesn’t occur. Synchronisation is a process that establishes consistency of data between two or more entities. This feature allows for scalability and speed to not be affected for the enterprise-grade solution. Since the blockchain is private and the entities are known, multiple generators could be seen as a redundancy. Not all nodes need to be online for this platform to function at a minimum one generator and one signer are needed. However, typically, it allows 100 participants to interact, only needs five signers, one generator and one issuer (some regulatory body). The fault tolerance in this setup allows for three out of four, or four out of five signers.
The privacy section will go into the details of how the Chain Open Standard tackles the problem of confidentiality of information for the platform participants. Open, permission-less blockchains such as bitcoin are transparency machines in that all participants can view information on the network. Chain has built a solution for those who need privacy as a main feature. Without the need for complete transparency and all nodes (chain cores) receiving transactional information, scalability doesn’t get sacrificed, but transparency does. All systems have trade-offs. In this system, the nodes (chain cores) would only get block proofs by node platform.
The node (core) itself, could store all the blockchain data or only a snapshot (balance sheet), and a limited history of activity from the account manager (described below).
- The Asset Issuer (presumably a node on the platform) creates what can be an unlimited number of cryptographically unique Asset IDs. (Creation Phase.)
- Units of these assets are issued on a blockchain. (Submission Phase.)
- An Asset ID is associated with an Asset Definition. (Asset Definitions can be self-enforcing rules to meet specific conditions depending on the use case. These can have an unlimited amount of reference data.) (Validation Phase.)
- Once issued, units of an asset ID can be stored in and transferred between accounts, programmatically transacted via smart contracts, or retired from circulation. (Signing Phase and Pulling into Nodes Phase.)
- After the Signing Phase, the transaction goes live.
One of the interesting features of this system is the account manager, which serves many key roles. It stores assets in secure accounts. This is where transaction data gets stored. These accounts can contain any combination of assets and create for many different types of user. These accounts can be thought of as digitally secure wallets. In addition to storing assets, the account manager enables the transferability of assets into and out of accounts via blockchain transactions (within the same core or between different cores in the network). The account manager builds the smart contracts for all different types of transactions (see ‘Smart contracts’ below). Each transaction is a smart contract.
Ownership of the assets flows through the system by using a push model. The addresses are provided by other parties, and the unique Asset IDs and accounts that get created are used to designate ownership of the assets. The smart contract (transaction) defines what actions a designated party can take.
Privacy and security
The Chain Open Standard is a private network in which confidentiality of information is one of the top priorities. This platform has been designed to support selective disclosure of sensitive information. This is done using three techniques:
- one-time-use addresses
- zero-knowledge proofs
- encrypted metadata.
A one-time address is created each time an account holder wishes to receives assets. These differing addresses prevent other observers of the blockchain from associating transactions with each other or with a particular party.
To cryptographically conceal the contents (assets and amounts) of a transaction, ‘zero-knowledge proofs’ are used, while still allowing the entire network to validate the integrity of the contents. Zero-knowledge proofs (ZKPs) do this by one party proving to another party that a given statement is true without conveying any information (in this case, about the transaction), apart from the fact that the statement is indeed true. Only the counterparties (and those granted access) can view the details of the transaction.
Also, transaction metadata can be encrypted with traditional PKI to conceal details from all but the relevant parties. The platform uses keys to prove verifiable authenticity (signatures) of the messages delivered between the nodes (chain cores).
The keys are generated by creating an unlimited number of cryptographically unique Asset IDs. These keys are rotated every 2-3 weeks. Rotating keys is a process for decrypting data with an old key and applying the data to a new key by re-keying. These keys should probably be kept in different places or data centres. If one of the keys becomes compromised, use other key to generate backup keys and transfer all assets to new key. Key management and rotation is essential to managing secure digital assets. These keys also allow and restrict access to certain activities.
Chain Core also integrates with industry-standard hardware security module (HSM) technology. All block and transaction signing takes place within hardened HSM firmware. Multi-signature accounts using independent HSMs can further increase blockchain security. HSM firmware that secures all transactions and blocks multi-signature accounts to eliminate single points of failure.
The Chain Open Standard platform has designed a framework in which all transactions are smart contracts that allow for outside events or data to trigger the execution of certain clauses in the contract. It also allows each transaction to contain metadata, such as information required for ‘know your customer’ (KYC) and anti-money laundering (AML) regulations. The smart contracts have a built-in identity feature.
Some of the use cases Chain is looking at for financial transactions and generating a smart contract on a transaction by transaction basis include (see captions below for use cases):
Use cases being explored that have smart contract features for transactions are:
- Asset issuance – Digitise existing assets for transacting on a blockchain network.
- Simple payment – Transfer assets from one account to another.
- Bilateral trade – Swap one asset for another with no counterparty risk.
- Order book – Name your sale price and let a buyer find you.
- Collateralised loan – Lend assets, guaranteed by locked collateral.
- Auction – Set a minimum price and sell your assets to the highest bidder.
Chain Core is the software implementation of the Chain Open Standard. It’s designed to run in enterprise IT environments.
Trade-offs for scalability and speed
Key characteristics of the Chain Open Standard include scalability, speed and privacy. With this in mind, as with any blockchain, trade-offs occurred for high transaction speeds. Chain created a private blockchain open only to members of the platform. Data privacy is a major problem. Private blockchains aim to solve this without losing other key features of a blockchain network. Decentralisation and transparency are lost as a result of this. For the types of clients it has, this is a non-issue and is necessary to ensure privacy and confidentiality of transactions at scale. Having one generator effectively act as a master replicator for the private network of known signers and participants also allows transactions to scale into the tens of thousands per second. This being the case, synchronisation becomes a waste of effort and hurts scalability, so has been discarded as well. If limitless scalability is a design principle network stability (consistency of the data) and speed cannot be sacrificed. Transparency and decentralisation can.
Scale is also achieved in the Chain Open Standard through sharding and replication of the storage layer. Sharding allows for the partitioning of large databases into smaller ones, which make them faster and much easier to manage. (Ethereum aspires to this as well.) The one thing in the near-term that may hurt this enormous scalability could be using zero-knowledge proofs, which are not known to scale at this point in time.
Networks can be fitted and repurposed for any size of market. However, use cases centred around decentralisation (privacy), scalability (speed of transactions) and consistency (stability of network) will dictate what consensus model is used. Illiquid markets will not need the same type of solution as highly liquid ones. The same can be said of use cases where absolute privacy is necessary. Within each network, different levels of participation by different institutions are also important for deciding what type of blockchain you will build.
– This article is reproduced with kind permission. Some minor changes have been made to reflect BankNXT style considerations. Read more here. Main image: MoonRock, Shutterstock.com