Federated Blockchains, Right Future?

Abstract

Blockchain Technology assures a greater transparency, speed, efficiency and security in working of systems, organizations and people. Blockchain technology has established a digital currency ecosystem that runs in a trustless environment across the globe. In the global supply chain network, companies gain integrated global view of consignment with digital transactions and movements for all participants in real time using blockchain.

Blockchain network can solve issues like poverty, inequality, corruption, terrorism and global warming. To deploy blockchain at a global scale, certain features of traditional blockchain must be reworked.

Traditional blockchains are established as public and private blockchains. Private blockchains are established in the form of a permissioned system and owned by a single authority. Such authority has the right to allow / reject entities to participate in blockchain networks. As a counterpart, a public blockchain has an open network with permissible nature and all information is available in a public domain. Any party can view, read, and write data on the blockchain. No participant has control over the data in a public blockchain. In such an environment, issues of privacy are limiting the use of public blockchain and; private blockchain is struggling with the problem of single ownership.

To overcome these aspects, federated blockchain is invented, where blockchain can be maintained under ownership of multiple organizations and can exchange information and work simultaneously without compromising on the benefits of the system. Federated blockchain examples will remove the sole organization influence in the network. This means that multiple entities will be using the network and re-establish a decentralized type system.

Federated Blockchain can assure banks to co-work with zero forgeries & no double spending in the form of inter-banking transaction system without compromising on the privacy, by maintaining a collective ownership of the overall risk. Insurance claims would be streamlined much faster if hospitals, insurance companies and investigation agencies are interconnected in federated blockchain while maintaining privacy of nominees. Cost & time can be substantially improved in collaborative operations between groups of enterprises. Concept of direct democracy can be realized with a federated blockchain where government units like health, transport, and legal are interconnected to serve citizens better and give power in the hands of citizens, for people centric decision making.

In this paper, a new framework is introduced for defining federated blockchain to connect multiple entities.

Introduction

Federated blockchain is a secure hub for information exchange within multiple organizations. Federated blockchain is also known as permissioned blockchain in consortium. It is a distributed system unlike public blockchain which is decentralized. It's quite similar to the private blockchain with a major difference in ownership. Federated blockchain will remove the sole organization influence in the network, multiple organizations collectively share ownership using the network for their benefit. Efforts are made to solve traditional blockchain issues of privacy and single ownership by replacing them with a collective ownership beneath the boundary of consortium. In federated blockchain, control is given only to a few selected members across different organizations.

Following diagram shows the structure of the federated block chain. (4 entities/organization are shown below)

Diagram-Federated Block-chain

N – Blockchain Nodes

S – Selected blockchain nodes (part of governance group) Voting happens only between S nodes for validation of block.

Federated block chain is governed by a “federated governance group”. All the permissions for read / write within the blockchain network are controlled by the governance group. Governance group is responsible for building consensus and providing access permissions to the new nodes in the blockchain. Every entity dedicates some of the nodes to be a part of the governance group. Nodes which are a part of the governance group are called Selected BC nodes (denoted as S).

All the transactional decisions happen in collaboration with all the organizations in federated blockchain irrespective of their size. Every organization maintains equal rights in the federated blockchain, by maintaining equal participation in the governance group.

Federated block-chain network maintains the following basic components and mechanisms to adhere to the blockchain functioning.

Consensus - A well-defined procedure for the block chain networks by which all the nodes of the network reach a common agreement. No blocks will be generated without establishing consensus in the federated governance group.

Transaction – A blockchain transaction is a unit of information which is stored in the blocks within a federated block-chain network. Every member of block-chain can create blocks in a chain to depict a new set of information.

Smart contract – A set of routines stored in federated block-chain networks. Smart contracts are executed after meeting predefined conditions. Smart contract conditions are verified automatically after creation of any new block.

Event distribution – Every member of federated block-chain network distributes events related to block chain transactions across all other nodes. Such events include creation of new blocks, triggers of smart contract and a lot more.

Federated Blockchain / Traditional Blockchain

Federated governance group differentiates the federated blockchain from the traditional block chain in its ownership, consensus mechanism, speed and regulations.

Consensus is used in federated blockchains to achieve an agreement for adding new information and distribute such information across all the nodes. In the traditional blockchain “proof of work” or “proof of stake” are used as consensus building algorithms. In proof of stake, higher importance is given to certain nodes based on their stake in overall blockchain. In the “proof of work” all nodes have been given the puzzle to resolve for qualifying to validate the transaction. Whichever nodes solves the puzzle qualifies for the validation. Equality of entities in the federated block chain is guaranteed by the ‘proof of vote’ consensus algorithm. In principle, every node in the network will need to vote, to validate a block. In the federated blockchain, all the members of "Federated Governance Group'' must vote to validate a block. The number of votes required will be pre-determined depending on type of transactions.

Federated Blockchain Framework

Federated Blockchain framework is a set of rules and plugins, which allow groups of entities to set-up the federated blockchain efficiently. Federated blockchain framework is successfully demonstrated for implementation of the following use cases.

• Federated Blockchain for Nation - All citizen-services are modelled on a federated block chain consortium. Governance can be monitored with federated blockchain where different departments like health, transport, legal are connected on the federated block chain.
• Federated Blockchain for Aviation regulatory - All aviation entities are modelled on a federated block chain consortium. Validity/certification/life of important assets including aircraft, pilot, engineer and aircraft components can be monitored on federated blockchain where different entities like Airline, MRO, leasing agencies and Govt. aviation authority are interconnected.
• Federated Blockchain for Essential supply for the citizens - All government units, farmers, ration shops and centralized kitchens, medical shops, hospitals, food processing units, traders and community kitchens are a part of this chain, and are interconnected in federated blockchain to establish a real time collaboration and information sharing between all these institutions.

Following diagram shows the federated blockchain framework.

Framework defines Restrictions and Plugin-FGN as main components of the system. Every entity in blockchain is obligated to adhere with rules set by Restriction. Restrictions are a set of components /configurations and rules to govern functioning of federated blockchain. FGN-Node plugin connects new entities into the federated block chain. Data API, Content DB, BC members are not only a part of the framework but integral component of the overall BC consortium. BC-member entities are actual nodes of an existing organization which connects the framework with Plugin-FGN. Every BC member contains mechanisms like Consensus, Transaction, Event distribution and Smart contracts, which are the minimum components of any blockchain. Such BC members can be the nodes of existing public or private blockchains. Following section describes the framework.

1 - BC Platform Repository

BC Platform repository is a repository of all the participating entities in the consortium. It defines standard rules for each entity to become a member of the federated block chain. All these entry rules identify the business domain of an entity and contain asset classes. Asset class is a kind of information whose life cycle is maintained by the respected entity. BC platform repository contains federated governance group definition.

BC platform repository defines an outline of the Participate() routine for participation of any new entity in the BC platform.

Participate (Entity ex, AssetClass [ ] assets, Node[] memberNodes)                                

{

// Gather all the membership rules for the BC consortium.
 
// verify membership rules for Entity ex.
 
// verify membership rules for the asset classes requested.
 
// If all membership rules are qualified then
 
// add all the member-nodes in BC restriction group.
     
// Update the Asset classes of the BC platform with new Assets.
  
 }        

2 - Platform consensus definitions

Framework defines consensus mechanism for every transaction using 'proof of vote' algorithm so that equality of the entities is guaranteed in the federated blockchain. In principle, every node in the network will need to vote, to validate a block. As a part of the mechanism, a specific number of voter-node requirements are explicitly determined for each transaction type. The number of voting required will be predetermined. Within platform consensus definitions, the exception for a number of voters can be created in case of certain transactions. This means that for 10 selected nodes it might take 7 nodes to validate a block for T1-transaction. Similarly, for T2-transaction, it may require 5 nodes vote to validate a block.

Platform consensus defines multiple routines like PerformTransaction and DefineBCTransaction routines for transaction validation. PerformTransaction routine is outlined for performing a transaction in BC platform.

PerformTransaction (Entity ex, Transaction tx)                              

{
// read transaction definition for tx
           
// identify MinVotesRequired for the transaction tx
           
// activate voting between selected nodes of the restriction group.
           
// If voting count is more than MinVotesRequired then approve the transaction.
           
// If transaction is approved then update the block in BC with a new hash of the transaction.
 
// verify activation conditions of smart-contracts in block.
 
// If any activation condition triggers then
           
// execute Smart contract from all the replicated blocks.
}        

BC platform repository defines an outline of the DefinBCTransaction routine for defining a new transaction within BC platform.

DefineBCTransaction (Entity ex, TransactionDefinition tx)

{
// TransactionDefinition contains consensus mechanism
for validating the transaction.
                                               
// validate the transaction definition tx
 
// add the transaction-definition into the BCTransactionDefinition.
 
}        

3 - Heterogeneous Transactions

Framework defines rules for heterogeneous transactions. In traditional blockchain transactions are the unit of information which are stored in the blocks. Heterogeneous transactions boundary spans across multiple block-chain transactions across entities. Heterogeneous transactions will have ACID properties like atomicity, consistency, isolation, and durability.

4 - Heterogenous Smart Contracts

Framework defines rules for the heterogeneous smart contract definitions across the entities. The smart contract is a program, on top of a block chain containing a set of rules. Entities agree on these rules to interact with each other. When the predefined conditions are met, then agreement is automatically enforced on all these entities using these programs. Heterogeneous programs are placed for agreement negotiations across entities.

5 - Content definitions

Entities manage different information assets within their legacy systems. All such data should be explicitly defined, to enable access across federated blockchain. Framework defines content-definitions for all the information assets which must be exchanged across the entities. Content definitions will also define the access mechanism (if contents are not stored on the blockchain, like flat files, documents)

ReceiveContent (Entity ex, Hash hashCode, ContentType ctype, Content* content)

{

// Retrieve ContentDefinition for ctype
 
// Build ContentSource from the ContentDefinition for Entity ex
 
// Retrieve content for the hashCode from ContentSource  

}        

FGN-node plugin

FGN-Node plugin connects new entities into the blockchain consortium. As shown in the framework diagram, FGN-node plugin executes on the selected nodes of the federated governance group for a seamless connectivity within federated-block-chain. FGN-Node-plugin contains the following components.

• Identity Verifier

Identity-Verifier uniquely identifies the asset from the blocks. As a principle, every asset across a federated block chain will have a similar instance across all the nodes. For example, spare-part, certificate, person as unique identities.

• Smart contract event generator

Smart contract event generator generates the event outside the block-chain for external action. Such actions are necessary to execute the heterogeneous smart contract when a group of conditions are met in federated block chain. Entities in blockchain don't store existing content on the block. Standard data APIs are defined to access the content from the Content-DB. Access to Content-DB is required for all the entities, whenever heterogeneous smart contracts are triggered.

• Consensus reader

Consensus reader reads the outcome of the consensus algorithm in the plugin. It validates if the platform consensus rules are followed as per the platform consensus definitions.

Using federated blockchain framework, federated blockchain for nation and Indian aviation are described in subsequent sections.

Blockchain Platform Repository

BC Platform repository is a repository of all the participating entities in the consortium. Each entity nominates certain nodes to be a part of the Federated Governance group. Snodes for each entity are defined in the table as per above diagram. Every entity maintains ownership of certain assets. As seen in the above section, entities manage the lifecycle of such assets on federated blockchain. For example, the Vehicle registration department maintains ownership of vehicle asset information. All these information assets are shown below.

Platform Consensus definitions

Following table describes all the consensus mechanisms for all identified transactions. To validate user-transaction, an algorithm is defined to build consensus across all the selected members. In most of the transactions, voting pattern X / Y is defined. Voting pattern implies that X number of nodes should agree about correctness (validity) of transaction among all Y number of nodes.

Content definitions

Following table defines all the content available across the complete federated blockchain. All this data will be stored on the blockchain. Document column indicates that some of the data for the given record will be stored on an external device and URL will be available in the blockchain.

Heterogeneous Transactions

Each entity can define the heterogeneous transactions, which involves records across multiple entities. Each heterogeneous transaction has a reference to the individual transactions within entities. Multiple transaction records are created for any completion of heterogeneous transactions.

Insurance claim non-settlement

This transaction will initiate a record for “hospital admission”. Such transactions include links to other blockchain transactions including diagnosis reports, CDR records, vehicle police fine records, lab reports and insurance claim reports. When insurance is rejected, then a new transaction is initiated.

Heterogeneous Smart contracts (HSC)

Heterogeneous smart contract definitions allow entities to execute multiple programs over different blocks from different entities. Each entity can define the HSC under a federated governance group. HSC will be defined on heterogeneous transactions. HSC will get executed after generation of the heterogeneous transaction.

No heterogeneous smart contract is identified for the national federated blockchain.

Federated Blockchain in Aviation

All aviation entities are modelled on a federated block chain consortium. Across the globe there are aviation authorities like FAA in US, EASA in Europe, DGCA in India who set governance, safety, security and operational rules / measures / processes for the aviation industry in the region. Validity/certification/life of important assets including aircraft, pilot, engineer and aircraft components can be monitored on federated blockchain where different entities like Airline, MRO, leasing agencies and Govt aviation regulatory are interconnected. Each Node has CTES properties like consensus, transactions, event-distribution and smart contracts. Snode (selected nodes can only be part of consortium governance activities). Realization of federated blockchain framework is described in 5 sections, blockchain platform repository, content definitions, consensus mechanism, heterogeneous smart contracts and heterogeneous transactions.

Following diagram shows the realization of our framework into Aviation regulatory-blockchain consortium.

Blockchain Platform Repository

BC Platform repository is a repository of all the participating entities in the consortium. Each entity nominates certain nodes to be a part of the Federated Governance group. Snodes for each entity are defined in the table as per above diagram. Every entity maintains ownership of certain assets. As seen in the above section, entities manage the lifecycle of such assets on federated blockchain. All these information assets are shown below.

Platform Consensus Definitions

Following table describes all the consensus mechanisms for all identified transactions. To validate user-transaction, an algorithm is defined to build consensus across all the selected members. In most of the transactions, voting pattern X / Y is defined. Voting pattern implies that X number of nodes should agree about correctness (validity) of transaction among all Y number of nodes.

Content Definitions

Following table defines all the content available across the complete Federated blockchain. All this data will be stored on the blockchain. Document column indicates that some of the data for the given record will be stored on an external device and URL will be available in the blockchain.

Heterogeneous transactions

Each entity can define the heterogeneous transactions, which involves records across multiple entities. Each heterogeneous transaction has a reference to the individual transactions within entities. Multiple transaction records are created for any completion of heterogeneous transactions.

ARC transaction

ARC is defined as a heterogeneous transaction within the Aviation regulatory blockchain consortium. As per the regulations, ARC must be performed and submitted to Aviation regulator every year for every aircraft. ARC is a heterogeneous transaction and it is linked to multiple quality checklist transactions and work-order transactions.

Heterogeneous Smart Contracts (HSC)

Heterogeneous smart contract definitions allow entities to execute multiple programs over different blocks from different entities. Each entity can define the HSC under a federated governance group. HSC will be defined on heterogeneous transactions.

ARC smart contract

ARC smart contract is defined for the Aviation regulatory BC consortium. ARC HSC is a contract between Airline, MRO, Lessor and Aviation regulatory indicating readiness of aircraft for 365 days. Once an ARC transaction is finished multiple programs are executed across all nodes as per the following:

1. On the lessors’ nodes, all the aircraft part database and relevant documents are extracted and stored in the offline repository for aircraft analysis.
2. On the lessors’ nodes, all the aircraft work orders and relevant documents of the past 1 year are extracted and made available for analysis.
3. On Airline nodes, ARC certificate is generated from the program with all relevant documentations.
4. On Aviation regulatory nodes, all the ARC checklists are extracted and pushed to the right authorities.

Conclusion

Using a new framework, organizations can be connected in a federated blockchain, to establish a belief / trust within each other, without compromising privacy. Blockchain technology is an effective technology and is capable to solve global issues like poverty, inequality, corruption, terrorism and global warming but due to its traditional limitations of technology, large global consortiums are limited. New framework defined in this paper defines 5 component restrictions set as the essential requirement of the consortium. If all these 5 components can be defined across organizations, then federated blockchains can be easily established. As shown in this paper, Nationwide federated blockchain and Aviation regulatory federated blockchain have been successfully realized using a newly introduced framework. Overall new framework simplifies realization of the federated block chain across multiple entities.