Hyperledger Fabric：面向许可区块链的分布式操作系统

需积分: 12 165 浏览量更新于2024-07-15 收藏 680KB PDF 举报

Hyperledger Fabric 是一个专为许可区块链设计的分布式操作系统，由 IBM 等公司共同开发，它是一个模块化且可扩展的开源系统。该系统的创新之处在于其不追求通用解决方案，而是为特定的使用场景和信任模型量身定制，因此能够适应多样化的业务需求。作为分布式账本技术的重要代表，Fabric 已经在超过400个原型项目和概念验证中得到了应用，以及在多个行业和实际场景中部署了生产级系统。其核心优势在于其灵活性和可定制性： 1. 模块化共识协议：Fabric 支持多种共识机制，如 Solo、Kafka 和 PBFT（ Practical Byzantine Fault Tolerance）等，这使得开发者可以根据系统的安全需求和性能要求选择最适合的共识算法。这种灵活性使得 Fabric 能够处理不同的网络拓扑和参与者的特性。 2. 应用支持：它运行的是分布式应用程序，这意味着开发者可以构建复杂的应用程序并利用区块链的不可篡改特性来增强数据完整性。通过 Fabric 的沙箱（Sandboxed Containers），开发者可以在隔离的环境中编写和测试智能合约，提高了代码的安全性和可靠性。 3. 权限管理：作为许可型区块链，Fabric 注重控制节点的准入，并对交易进行权限管理，确保只有授权用户或组织能够访问和参与链上活动。这对于需要合规性和隐私保护的企业级应用至关重要。 4. 隐私保护与隐私计算：为了满足某些行业的隐私需求，Fabric 提供了隐私计算功能，允许在保持数据加密的同时执行复杂的分析操作，保护敏感信息。 5. 易用性和可扩展性：Fabric 提供了一整套工具和服务，包括 Fabric SDKs、智能合约语言（如 Go 或 Chaincode）、开发者框架和命令行工具，使得开发者能够快速上手和部署区块链应用。同时，它具有良好的横向扩展能力，能够支持大规模的并发交易处理。 Hyperledger Fabric 不仅是一个底层的区块链基础设施，更是一个高度灵活的平台，它将区块链技术与传统软件开发方法结合起来，使得企业能够在确保安全性的同时，更好地利用区块链的优势，推动其在各行业的广泛应用和发展。随着技术的不断演进，Fabric 将继续引领许可区块链技术的创新方向。

Overall, this hybrid replication design, which mixes pas-

sive and active replication in the Byzantine model, and the

execute-order-validate paradigm, represent the main inno-

vation in Fabric architecture. They resolve the issues men-

tioned before and make Fabric a scalable system for permis-

sioned blockchains supporting ﬂexible trust assumptions.

To implement this architecture, Fabric contains modular

building blocks for each of the following components:

Ordering service: An ordering service atomically broad-

casts state updates to peers and establishes consensus on

the order of transactions. It has been implemented with

Apache Kafka/ZooKeeper (http://kafka.apache.

org/) and with BFT-SMaRt [3].

Identity and membership: A membership service provider

is responsible for associating peers with cryptographic

identities. It maintains the permissioned nature of Fabric.

Scalable dissemination: An optional peer-to-peer gossip

service disseminates the blocks output by ordering ser-

vice to all peers.

Smart-contract execution: Smart contracts in Fabric run

within a container environment for isolation. They can

be written in standard programming languages but do not

have direct access to the ledger state.

Ledger maintenance: Each peer locally maintains the ledger

in the form of the append-only blockchain and as a snap-

shot of the most recent state in a key-value store (KVS).

The KVS can be implemented by standard libraries, such

as LevelDB or Apache CouchDB.

The remainder of this paper describes the architecture

of Fabric and our experience with it. Section 2 summa-

rizes the state of the art and explains the rationale behind

various design decisions. Section 3 introduces the architec-

ture and the execute-order-validate approach of Fabric in de-

tail, illustrating the transaction execution ﬂow. In Section 4,

the key components of Fabric are deﬁned, in particular, the

ordering service, membership service, peer-to-peer gossip,

ledger database, and smart-contract API. Results and in-

sights gained in a performance evaluation of Fabric with a

Bitcoin-inspired cryptocurrency, deployed in a cluster en-

vironment on commodity public cloud VMs, are given in

Section 5. They show that Fabric achieves, in popular de-

ployment conﬁgurations, throughput of more than 3500 tps,

achieving ﬁnality [36] with latency of a few hundred ms. Fi-

nally, Section 6 discusses related work.

2. Background

2.1 Order-Execute Architecture for Blockchains

All previous blockchain systems, permissioned or not, fol-

low the order-execute architecture. This means that the

blockchain network orders transactions ﬁrst, using a con-

Update stateOrder Execute

●

Deterministic (!)

execution

●

Persist state on

all peers

●

Consensus or

atomic broadcast

Figure 1. Order-execute architecture in replicated services.

sensus protocol, and then executes them in the same order

on all peers sequentially.

For instance, a PoW-based permissionless blockchain

such as Ethereum combines consensus and execution of

transactions as follows: (1) every peer (i.e., a node that par-

ticipates in consensus) assembles a block containing valid

transactions (to establish validity, this peer already pre-

executes those transactions); (2) the peer tries to solve a PoW

puzzle [28]; (3) if the peer is lucky and solves the puzzle, it

disseminates the block to the network via a gossip protocol;

and (4) every peer receiving the block validates the solution

to the puzzle and all transactions in the block. Effectively,

every peer thereby repeats the execution of the lucky peer

from its ﬁrst step. Moreover, all peers execute the transac-

tions sequentially (within one block and across blocks). The

order-execute architecture is illustrated by Fig. 1.

Existing permissioned blockchains such as Tendermint,

Chain, or Quorum typically use BFT consensus [9], pro-

vided by PBFT [11] or other protocols for atomic broad-

cast. Nevertheless, they all follow the same order-execute

approach and implement classical active SMR [13, 31].

2.2 Limitations of Order-Execute

The order-execute architecture is conceptually simple and

therefore also widely used. However, it has several draw-

backs when used in a general-purpose permissioned block-

chain. We discuss the three most signiﬁcant ones next.

Sequential execution. Executing the transactions sequen-

tially on all peers limits the effective throughput that can be

achieved by the blockchain. In particular, since the through-

put is inversely proportional to the execution latency, this

may become a performance bottleneck for all but the sim-

plest smart contracts. Moreover, recall that in contrast to tra-

ditional SMR, the blockchain forms a universal computing

engine and its payload applications might be deployed by an

adversary. A denial-of-service (DoS) attack, which severely

reduces the performance of such a blockchain, could simply

introduce smart contracts that take a very long time to exe-

cute. For example, a smart contract that executes an inﬁnite

loop has a fatal effect, but cannot be detected automatically

because the halting problem is unsolvable.

To cope with this issue, public programmable block-

chains with a cryptocurrency account for the execution cost.

Ethereum, for example, introduces the concept of gas con-

In many blockchains with a hard-coded primary application, such as

Bitcoin, this transaction execution is called “transaction validation.” Here

we call this step transaction execution to harmonize the terminology.

3 2018/2/1

剩余14页未读，继续阅读

github_33716821

粉丝: 1
资源: 5

Hyperledger Fabric：面向许可区块链的分布式操作系统

"Google大数据论文：Google File System的设计与实现

安全程序下载与工作存储器要求：S7 Distributed Safety 编程指南

"Ceph分布式文件系统研究及性能测试

Hyperledger Fabric A Distributed Operating System for.pdf

Bigtable：A Distributed Storage System for Structured Data

Bigtable: A Distributed Storage System for Structured Data

CFS: A Distributed File System for Large Scale Container Platforms

Bigtable: A Distributed Storage System for Structured Data中文翻译

sidetree-fabric：使用支持Hyperledger Fabric分类帐的Sidetree的实现

fabric-sdk-py:Hyperledger Fabric Python SDK

最新资源