Chain: Simplified Byzantine Fault Tolerance (SBFT)

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 which 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 signors. 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 gets resolved.

By using 1 generator (master replicator) in a trusted, private environment this effectively allows for kind of scale and speed needed for transactions and for the signors to validate transactions. These signors 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 is 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 1 generator instead of multiple, synchronization does not occur. Synchronization is a process that establishes consistency of data between 2 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 1 generator and 1 signor are needed. However, typically it allows 100 participants to interact, only needs 5 signors, 1 generator and 1 issuer (some regulatory body). The Fault Tolerance in this setup allows for 3 out of 4 or 4 out of 5 signors.

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, permissionless blockchains like 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 does not 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).

Stages

The Asset Issuer (presumably a node on the platform) creates what can be an unlimited number of cryptographically unique Asset ID's. (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 created for many different types of users. These accounts can be thought of as digitally secure wallets. In addition to storing assets, the Account Manager enables the transferability of assets in to 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 Contract Section). 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 ID's 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 & Security

The Chain Open Standard is a private network in which confidentiality of information is one of 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, and 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 counter-parties (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 get 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 centers. If one of the keys gets compromised then use other key to generate backup keys and transfer over 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.

Smart Contracts

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 generate a smart contract on transaction by transaction basis include (See Captions Below for Use Cases):

Uses cases being explored that have smart contract features for transactions are:

Asset Issuance - Digitize 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
Collateralized Loan - Lend assets, guaranteed by locked collateral
Auction - Set a minimum price and sell your assets to the highest bidder

Architecture Concept

Chain Core is the software implementation of the Chain Open Standard. It is designed to run in enterprise IT environments.

Conclusion: 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 without losing other key features of a blockchain network. Decentralization and transparency are lost as a result of this. For the types of clients they have this is a non issue and is necessary to ensure privacy and confidentiality of transactions at scale. Having 1 generator effectively act as a master replicator for the private network of known signors and participants also allows transactions to scale into the tens of thousands per second. This being the case synchronization 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 decentralization can.

Scale also gets 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 market. However use cases centered around decentralization (privacy), scalability (speed of transactions), and consistency (Stability of network) will dictate what consensus model gets 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.

Sources:

http://chain.com/core/

https://chain.com/os/