not only one, but many distributed applications run concur-
rently; (2) applications may be deployed dynamically and by
anyone; and (3) the application code is untrusted, potentially
even malicious. These differences necessitate new designs.
Many existing smart-contract blockchains follow the
blueprint of SMR [31] and implement so-called active repli-
cation [13]: a protocol for consensus or atomic broadcast
first orders the transactions and propagates them to all peers;
and second, each peer executes the transactions sequentially.
We call this the order-execute architecture; it requires all
peers to execute every transaction and all transactions to be
deterministic. The order-execute architecture can be found
in virtually all existing blockchain systems, ranging from
public ones such as Ethereum (with PoW-based consensus)
to permissioned ones (with BFT-type consensus) such as
Tendermint (http://tendermint.com/), Chain (http:
//chain.com/), and Quorum (http://www.jpmorgan.
com/global/Quorum). Although the order-execute design
is not immediately apparent in all systems, because the addi-
tional transaction validation step may blur it, the limitations
of order-execute are inherent in all: every peer executes ev-
ery transaction and transactions must be deterministic.
Prior permissioned blockchains suffer from many limita-
tions, which often stem from their permissionless relatives
or from using the order-execute architecture. In particular:
•
Consensus is hard-coded within the platform, which con-
tradicts the well-established understanding that there is
no “one-size-fits-all” (BFT) consensus protocol [33];
•
The trust model of transaction validation is determined
by the consensus protocol and cannot be adapted to the
requirements of the smart contract;
•
Smart contracts must be written in a fixed, non-standard,
or domain-specific language, which hinders wide-spread
adoption and may lead to programming errors;
•
The sequential execution of all transactions by all peers
limits performance, and complex measures are needed
to prevent denial-of-service attacks against the platform
originating from untrusted contracts (such as accounting
for runtime with “gas” in Ethereum);
•
Transactions must be deterministic, which can be difficult
to ensure programmatically;
•
Every smart contract runs on all peers, which is at odds
with confidentiality, and prohibits the dissemination of
contract code and state to a subset of peers.
In this paper we describe Hyperledger Fabric or simply
Fabric, an open-source (http://github.com/hyperledger/
fabric) blockchain platform that overcomes these limita-
tions. Fabric is one of the projects of Hyperledger (http:
//www.hyperledger.org) under the auspices of the Linux
Foundation (http://www.linuxfoundation.org). Fab-
ric is used in more than 400 prototypes, proofs-of-concept,
and in production distributed-ledger systems, across differ-
ent industries and use cases. These use cases include but are
not limited to areas such as dispute resolution, trade logis-
tics, FX netting, food safety, contract management, diamond
provenance, rewards point management, low liquidity se-
curities trading and settlement, identity management, and
settlement through digital currency.
Fabric introduces a new blockchain architecture aiming
at resiliency, flexibility, scalability, and confidentiality. De-
signed as a modular and extensible general-purpose per-
missioned blockchain, Fabric supports the execution of dis-
tributed applications written in standard programming lan-
guages. This makes Fabric the first distributed operating sys-
tem for permissioned blockchains.
The architecture of Fabric follows a novel execute-order-
validate paradigm for distributed execution of untrusted
code in an untrusted environment. It separates the trans-
action flow into three steps, which may be run on different
entities in the system: (1) executing a transaction and check-
ing its correctness, thereby endorsing it (corresponding to
“transaction validation” in other blockchains); (2) order-
ing through a consensus protocol, irrespective of transaction
semantics; and (3) transaction validation per application-
specific trust assumptions, which also prevents race condi-
tions due to concurrency.
This design departs radically from the order-execute
paradigm in that Fabric typically executes transactions be-
fore reaching final agreement on their order. It combines
the two well-known approaches to replication, passive and
active, as follows.
First, Fabric uses passive or primary-backup replica-
tion [6, 13] as often found in distributed databases, but with
middleware-based asymmetric update processing [24, 25]
and ported to untrusted environments with Byzantine faults.
In Fabric, every transaction is executed (endorsed) only by a
subset of the peers, which allows for parallel execution and
addresses potential non-determinism, drawing on “execute-
verify” BFT replication [21]. A flexible endorsement policy
specifies which peers, or how many of them, need to vouch
for the correct execution of a given smart contract.
Second, Fabric incorporates active replication in the
sense that the transaction’s effects on the ledger state are
only written after reaching consensus on a total order among
them, in the deterministic validation step executed by each
peer individually. This allows Fabric to respect application-
specific trust assumptions according to the transaction en-
dorsement. Moreover, the ordering of state updates is del-
egated to a modular component for consensus (i.e., atomic
broadcast), which is stateless and logically decoupled from
the peers that execute transactions and maintain the ledger.
Since consensus is modular, its implementation can be tai-
lored to the trust assumption of a particular deployment. Al-
though it is readily possible to use the blockchain peers also
for implementing consensus, the separation of the two roles
adds flexibility and allows one to rely on well-established
toolkits for CFT (crash fault-tolerant) or BFT ordering.
2 2018/2/1