by Elli Androulaki, Christian Cachin, Angelo De Caro, Alessandro Sorniotti and Marko Vukolic (IBM Research, Zurich)
Blockchains can be defined as immutable decentralised ledgers for recording transactions that - depending on the system - are to various degrees resilient to malicious behaviour. Blockchain peers maintain copies of the ledger that consists of groups of transactions (blocks) linked together into a hash-chain. This effectively establishes total order among blocks and, consequently across transactions. Transactions have in recent years evolved to allow the execution of arbitrary logic, also known as smart contracts. In principle, a smart-contract is an application that operates on top of blockchain, which uses the underlying ordering of transactions (i.e., consensus) to maintain consistency of smart contract execution results across peers, now also referred to as execution replicas.
Blockchain networks, with the prominent example of Ethereum [L1], are typically public and open, i.e., anybody can participate without having a specific identity.
Permissioned blockchains have evolved as an alternative to open blockchains to address the need for running blockchain technology among a set of known and identifiable participants that are required to be explicitly admitted to the blockchain network. The concept behind permissioned blockchains is particularly interesting in business applications of blockchain technology and distributed ledgers, in which the participants require some means of identifying each other while not necessarily fully trusting each other.
In the world of business, permissioned blockchain systems often come across critical requirements (from a practical and regulatory perspective) for transactional security and privacy of business logic that is put on a shared ledger. In addition, commonly enterprise-purposed permissioned ledgers need to meet certain performance and scalability standards and/or comply with different cryptographic standards and practices, ultimately calling for modularity of crypto components.
Fabric [L2] is an open source project under the umbrella of Hyperledger [L3], a consortium hosted by Linux Foundation [L4] aiming to offer an enterprise-level permissioned block-chain platform. Fabric deals with all the aforementioned challenges, while offering support for execution of distributed applications (i.e., smart contracts or chaincodes in Fabric parlance) in general-purpose programming languages.
But, let’s take a closer look to Fabric.
Technically, Fabric is a framework for executing (potentially non-deterministic) distributed applications in an untrusted environment. Fabric introduces execute-order-validate distributed execution paradigm, which effectively splits the traditional execution into pre-consensus (i.e., pre-ordering) execution and post-consensus validation. This separation facilitates a flexible trust model for execution of its smart contracts, also known as chaincodes, that is not impacted by the trust model considered by the underlying consensus mechanism. Beyond its novel replication approach, Fabric is best defined by the following features, which are novel in the blockchain context:
- A pluggable ordering service with multi-channel enablement. That is, Fabric supports state partitions, with each partition implementing total order semantics. Ordering service nodes (called orderers) impose total order on state updates (produced in the execution phase) using distributed consensus. The operation of orderers is logically decoupled from peers who execute chaincode and maintain the distributed ledger state. The consensus modularity goes beyond the possibility of plugging different ordering protocols in the byzantine fault-tolerant model [1], as, depending on the use case, different failure models can be assumed for orderers, such as simple crash fault-tolerant model or, in future, the recently proposed XFT fault model [2].
- A flexible trust model for chaincode execution. A chaincode’s deployers can specify the entities (or combination of entitites) that should be trusted to execute the deployed chaincode on a given channel. Chaincode deployers specify these entities by means of a policy, also referred to as endorsement policy, and can be completely independent from trust assumptions governing the ordering of transactions or the execution of other chaincodes.
- Parallelisation of chaincode execution, as not all chaincodes need to execute on all nodes.
- A modular and easily extensible membership framework. This constitutes the foundation of the permissioned nature of Fabric. Namely, as permissioned blockchains need to manage node (i.e., client, peer, orderer) identities, and access rights, membership services are a critical component of permissioned block-chains. Fabric allows for the definition and use of one or more membership abstractions, called membership service providers, each aiming to reflect an architecturally different membership management service, which is independent and securely recon-figurable. The default type of membership module supported by Fabric is compatible with X.509 certificates which are widely used by existing business membership systems.
- An access control enforcement mechanism to govern channel creation, channel participation, and administration, chaincode deployment, and chaincode execution.
- A highly efficient block dissemination mechanism from the ordering service to peers to ensure the system is able to sustain high volumes of peers, and transactions.
- A novel, two-phase smart-contract (or chaincode) deployment mechanism, to ensure that a maximum of one instance of a certain chaincode runs on each peer even if it is used to serve multiple channels.
Hyperledger Fabric V1 is due to be completed in June 2017, and it will constitute the first highly scalable permissioned blockchain platform combining the features listed above.
Links:
[L1] www.ethereum.org
[L2] www.hyperledger.org
[L3] github.com/hyperledger/fabric
[L4] www.linuxfoundation.org
References:
[1] C. Dwork, N. Lynch, L. Stockmeyer: “Consensus in the presence of partial synchrony”, J. ACM, 35(2): 288–323, April 1988.
[2] S. Liu, et al.: “XFT: practical fault tolerance beyond crashes”, OSDI 2016.
Please contact:
Elli Androulaki
IBM Research - Zurich, Switzerland
