The original address: www.xuanzhangjiong.top/2019/09/21/…

Hyperledger Fabric: A distributed operating system – blockchain based on access control

Abstract

Hyperledger Fabric is a modular, scalable, open source blockchain system for deployment and operation permissions. Fabric is currently used in over 400 prototype and proof-of-concept distributed ledger technology scenarios, such as many production systems, across different industries and usage scenarios.

Based on the premise of a one-size fits-All solution, Fabric is the first truly scalable blockchain system for distributed applications. It supports modular consensus protocols that allow systems to be customized to specific use cases and trust models. Fabric is also the first blockchain system to develop smart contracts in a general-purpose programming language to run distributed applications independent of native cryptocurrencies. This is in stark contrast to existing blockchain platforms that require specific programming languages or rely on cryptocurrencies to develop smart contracts. In addition, it implements the licensing model using an easy-to-understand member service combined with industry standard identity management. To support this flexibility, Fabric takes a novel approach to designing blockchain systems with permission controls and improvements to cope with uncertainty, resource exhaustion, and performance attacks.

This article describes Fabric, its architecture, the rationale behind various design decisions, the security model and guarantees, its most prominent implementation aspects, and the distributed application programming model. We further evaluate Fabric by implementing and testing bitcoin-based digital currencies. We have shown that Fabric achieves throughput in excess of 3500TPS per second in some popular deployment configurations, with sub-second latency.

1. Introduction

Blockchain can be defined as an immutable ledger for recording transactions maintained between distrustful nodes in a distributed network. Each node holds a copy of the ledger. Nodes execute consensus protocols to validate transactions, package them into blocks, and build hash chains over blocks. This process is formed by ordering transactions, a step necessary for consistency. The emergence of Bitcoin in blockchain technology Bitcoin.org/ is widely regarded as a promising technology for running trusted exchanges in the digital world. In a public or unauthorized blockchain, anyone can participate without a specific identity. Public blockchains typically involve native cryptocurrencies, and use a consensus of “proof of work” (POW) and economic incentives. Blockchains with access mechanisms, on the other hand, operate with a known set of identified participants. Blockchains with access mechanisms provide a way to exchange money, goods or information between groups of people who share common goals but do not trust each other, for example. Depending on the identity of the nodes, blockchains with access mechanisms can be consented using traditional Byzantine (BFT) protocols. Blockchains can perform arbitrary programmable transaction logic in the form of smart contracts, such as Ethereum ethereum.org/. Scripts in Bitcoin are a precursor to this concept. Smart contracts act as trusted distributed applications and derive security from blockchain and basic consensus. This is very similar to replicating state machines (SMR) using state and the well-known approach of building resilient applications [31]. However, blockchains move away from traditional replication state machines for important reasons :(1) running not just one, but multiple applications at the same time; (2) Applications can be deployed dynamically by anyone; (3) The application code may be untrusted or even malicious. These differences led to the need for a new design.

Many existing blockchains with smart contracts follow state replicators [31] and implement what is known as active replication [13] : a consensus protocol or atomic broadcast that first sorts transactions and propagates them to peer nodes; Second, each node executes transactions sequentially. We call this pattern a sort-execution architecture; It requires all nodes to execute each transaction and all transactions to be determined. In the existing block Chain system, from public Chain, such as the etheric fang (consensus) based on POW, league Chain, such as Tendermint tendermint.com/, Chain chain.com/ and Quorum www.jpmorgan.com/global/Quor… Are based on the sort execution architecture. The sort-execution architecture design is not immediately apparent to all systems because it may be obscured by additional transaction validation steps. The limitation of sort-execution is that all nodes need to execute transactions, and all transactions must be deterministic.

Pre-licensed blockchains are subject to many restrictions, often from relatives they don’t have access to or using a sort-and-execute architecture. In particular:

• Consensus is hard-coded within the platform, contradicting the established understanding that there is no “one size fits all” (BFT) consensus protocol;
• The trust model of transaction verification is determined by consensus protocol and cannot meet the requirements of smart contract.
• Smart contracts must be developed in fixed, non-standard, or domain-specific languages, which impedes their widespread adoption and can lead to bugs;
• All nodes need to execute all transactions in sequence, requiring complex measures to prevent denial-of-service attacks against the platform by untrusted contracts (such as “gas” calculated at runtime in Ethereum);
• The fact that a transaction must be certain is very difficult to program to ensure;
• Each smart contract runs on all nodes, which runs against confidentiality and prevents the propagation of contract code and state to other nodes.

In this article, we describe Hyperledger Fabric, or Fabric for short, an open source blockchain platform that overcomes these limitations github.com/hyperledger… . Fabric is one of the Hyperledger www.hyperledger.org projects supported by Linux Foundation linuxFoundation.org. Fabric is used for over 400 prototypes, proof-of-concept, distributed ledger systems in production environments, across different industries and use cases. These use cases include, but are not limited to, areas such as dispute resolution, trade logistics, net foreign exchange, food safety, contract management, diamond origin, reward points management, trading and settlement of illiquid securities, identity management, and settlement through digital currencies.

Fabric introduces a new blockchain architecture that is resilient, flexible, extensible, and confidential. Fabric is a modular, extensible, general-purpose blockchain with access rights that enables the execution of distributed applications written in standard programming languages. This makes Fabric the first distributed system for a blockchain with access rights.

Fabric’s architecture follows a new execution-sort-verify paradigm for executing untrusted code in untrusted distributed environments. It takes the trading atmosphere in 3 steps, running on different entities of the system:

1. Execute a transaction and validate its correctness, thereby endorsing it (as opposed to “validate the transaction” in other blockchain systems);
2. Sorting by consensus protocol, regardless of transaction semantics;
3. Transaction validation against application-specific trust assumptions prevents race conditions caused by concurrency.

This design is completely different from the sort-execute approach, where Fabric executes the transaction before the order is agreed upon. This combines two well-known methods of replication, passive and active, as follows.

First, Fabric uses passive or master/slave replication [6,13], which is often used in distributed databases, but is middleware-based asymmetric update processing [24,25] and has been migrated to the Byzantine error of untrusted environments. In Fabric, each transaction is executed by only a small number of nodes, allowing parallel execution to address potential uncertainties, referring to the “validation of execution” BFT replication [21]. A flexible endorsement strategy can specify which and how many nodes are required to guarantee the correct execution of the smart contract.

Second, Fabric includes active replication, in which the effect of a transaction on the ledger state is updated only after all transactions have been sorted by consensus, executed independently on each node during the deterministic verification phase. This allows Fabric to validate the trust assumptions of a particular application based on the endorsement policy of the transaction. Furthermore, the ordering of status updates entrusted to a consensus module (i.e., atomic broadcast) is stateless and logically separate from the nodes that perform the transactions and maintain the ledger. Because consensus is modular, its implementation can be customized based on the trust assumptions of a particular deployment. While it is not easy to implement consensus using peer nodes, the separation of the two roles adds flexibility and allows one to rely on well-established toolkits for CFT (fault tolerance) or BFT (Byzantine fault tolerance) sorting.

Overall, this hybrid replication design mixes passive and active replication from the Byzantine model, as well as the execution sequential validation paradigm, and represents a major innovation in the Fabric architecture. They address the aforementioned issues and make Fabric a scalable blockchain system with access rights that supports the assumption of flexible trust. To implement this architecture, Fabric includes a modular build of each of the following components:

Sorting service: a sorting service automatically broadcasts status updates to Peer nodes to establish consensus on transactions. Implemented by Apache Kafka/ZooKeeper (kafka.apache.org/) and BFT-Smart [3].

Identity and Membership services: Member service providers are responsible for associating nodes with encrypted identities. It preserves the permission-based nature of Fabric.

Scalable propagation: An optional point-to-point Gossip service is used to broadcast the blocks generated by the sort service to all nodes.

Smart contract execution: In Fabric, smart contracts run in an isolated container environment. They can be developed by standard programming languages, but do not have direct access to ledger state.

Maintain ledger: Each node maintains a locally appending blockchain ledger and maintains a snapshot of the latest state in the key-value store (KVS). KVS can be implemented using standard libraries, such as LevelDB or Apache CouchDB.

The rest of this article describes the architecture of Fabric and our experience with it. Section 2 summarizes current developments and explains the rationale behind various design decisions. Section 3 details the Fabric architecture and the execution-sort-checksum approach, illustrating the transaction execution process. In section 4, the key components of Fabric are defined, in particular, sorting services, member services, peer-to-peer message broadcasting, ledgers. smart contract apis. Results and insights from the performance evaluation of a Fabric reference bitcoin cryptocurrency based on a public cloud VIRTUAL machine environment are given in section 5. They show that Fabric achieves throughput in excess of 3500Tps in a popular deployment configuration, achieving results with latency times of several hundred milliseconds [36]. Finally, related work is discussed in Chapter 6.

Background 2.

2.1 Sequencing – execution architecture of blockchain

In previous blockchain systems, the sorted execution architecture was followed, with or without permissions. This means that the blockchain network first sorts transactions, uses consensus protocols to sort them, and then executes them on all nodes in the same order.

Sort execution schema in replication service

For example, poW-based permissive blockchains such as Ethereum combine consensus and execution as follows:

1. Each node (that is, one node participates in the consensus) assumes that a block contains legitimate transactions (to verify that the node has pre-executed those transactions);
2. This node attempts to solve the PoW puzzle [28];
3. If the node is lucky enough to solve the puzzle, it will publish the block to the entire network through the Gossip protocol.
4. Each node receives a block and verifies the correct solution to the puzzle and all transactions in the block. In effect, each node therefore repeats what the lucky node does, starting with the first step. In addition, all nodes execute transactions sequentially (block by block). The sort-execution architecture is shown in Figure 1.

Existing blockchains with permission control, such as Tendermint, Chain, and Quorum, usually use the BFT consensus algorithm [9], provided by PBFT[11], or provided by other atomic broadcast protocols. However, they all follow a sort execution architecture that implements the classic replication state machine [13,31].

2.2 Restrictions on sorting execution

The sorted execution architecture is conceptually simple and therefore widely used. However, it has several disadvantages when used for alliance chains. Let’s move on to the three most important questions.

Sequential execution. Executing transactions on all nodes limits the throughput of the blockchain. In particular, throughput is inversely proportional to transaction latency, which can be a performance bottleneck for all but simple smart contracts. Moreover, in contrast to traditional state replicators, the blockchain platform forms a general-purpose computing platform on which payload applications may be deployed by an adversary. Denial-of-service attacks severely degrade blockchain performance and can simply introduce a smart contract that takes a long time to execute. For example, executing an infinite loop of smart contracts will have fatal effects, but cannot be detected automatically because the downtime problem is irresolvable.

In many blockchains, such as Bitcoin, where the application is hardcoded, the execution of the transaction is called “Transaction Validation.”

To solve this problem, the public chain uses accounts with cryptocurrencies to calculate execution costs. Ethereum, for example, introduces the concept of GAS at the time of transaction execution, where the price of gas is converted into the cost of cryptocurrency, which is paid by the submitter of the transaction. Ethereum took a long time to implement this concept, assigning a overhead to each step of the underlying computation and introducing its own VM monitor to control execution. While this seems like a viable solution for public chains, it’s not enough for federated chains because there’s no local cryptocurrency to support it.

The distributed systems literature presents a number of approaches to improve performance over sequential execution. For example, by performing unrelated operations [30]. Unfortunately, such techniques are still being successfully applied in the blockchain context of smart contracts. For example, one challenge is the need to determine all dependencies in a smart contract, which is particularly challenging. Moreover, these techniques are ineffective against smart contracts against DoS attacks by unsuspecting developers.

Indeterminate code. Another problem with this concurrent ordering execution architecture is the problem of uncertain transactions. Performing operations in a state replicator after consensus requires certainty, duplication of ledgers, and consistency of all node states, but this approach violates the original design of the blockchain. This is usually addressed by domain-specific languages (e.g., Ethereum), which are sufficient for presentation for applications, but limited to deterministic execution. However, this language is difficult to implement and requires additional knowledge for developers. The adoption of general-purpose programming languages for smart contracts (e.g., Go, Java, C/C++) has instead become more attractive, accelerating the adoption of blockchain solutions.

Unfortunately, the common development language introduces many problems of deterministic execution. Even if the application developer does not explicitly operate nondeterministically, details that are hidden can be destructive (such as map iterators in the Go language). To make matters worse, blockchain burdens potentially untrustworthy programmers for creating deterministic applications. Only one nondeterministic contract with malicious intent is enough to bring the blockchain to a halt. Modular solutions for filtering divergence have also been studied [8], but are costly in practice.

Confidentiality of execution. Many of Xu’s systems run smart contracts on all nodes, according to blueprints in the public chain. However, many of the desired cases in the alliance chain require confidentiality, such as smart contract logic, transaction data, and classifiable ledgers. Although data encryption, zero-knowledge proof [2] and verifiable computation [26] can help achieve confidentiality, they usually incur considerable overhead and are not feasible in practice.

Fortunately, it’s enough to propagate the same state to everyone, rather than running the same code everywhere. Therefore, the execution of smart contracts can be limited to subsets that are trusted for this task, thus proving the reliability of the results. This design shifts active replication to passive replication [6] and ADAPTS to the trust model of blockchain.

2.3 Further limitations of the existing architecture

Fixed trust model. Most alliance chains rely on asynchronous Byzantine fault-tolerant algorithms to establish consensus [36]. Such protocols usually rely on a safe assumption that n> 3F nodes can tolerate up to F nodes to do evil, the so-called Byzantine error [4]. Application logic is often performed on the same nodes under the same security assumptions (even though BFT execution can actually be restricted to fewer nodes). However, such quantitative trust assumptions, regardless of the role of nodes in the system, may not match the trust required by smart contracts. In a flexible system, trust should be at the application level rather than fixed at the protocol level. A generic blockchain should couple these two assumptions and allow a flexible application trust model.

Hard-coded consensus. Fabric is the first blockchain system to introduce pluggable consensus. Prior to Fabric, almost all blockchain systems used hard-coded consensus protocols. Decades of research on consensus agreements, however, suggest that there is no such “one-size-fits-all” solution. For example, the PERFORMANCE of the BFT protocol varies greatly under potentially hostile environments [33]. On LAN clusters with symmetric and isomorphic links [18], protocols with “chain” communication modes show demonstrably optimal throughput, but poor performance over wide-area heterogeneous networks. In addition, external conditions such as load, network parameters, and actual failures or attacks may vary over time in a given deployment. For these reasons, the BFT consensus should be inherently reconfigurable and ideally adapted to changing environments [1]. Another important aspect is matching the trust assumptions of the protocol to a given blockchain deployment scenario. In fact, one might want to use a protocol based on an optional trust model (such as XFT[27]) instead of BFT consensus, or use a CFT protocol (such as Paxos/Raft[29] and ZooKeeper[20]), or even use a perfix-less protocol.

2.4 Sort the execution of blockchain experience

Prior to learning about Fabric that performs a sort verification architecture, the Fabric team had experience building blockchains with access rights using PBFT[11] consensus algorithms using the sort execution model. The limitations of this approach immediately became clear from feedback from many proof-of-concept applications. For example, users often observe state inconsistencies between nodes and report bugs in the consensus protocol; In all cases, close examination reveals non-deterministic trading as the culprit. Other complaints and restrictions, such as “only 5 transactions per second” reported by some users, but their transactions took an average of 200 milliseconds to complete. We have learned that the key attributes of a blockchain system, namely consistency, security, and performance, must be independent of the knowledge and willingness of the user, especially if the blockchain operates without trust.

3. The architecture

In this section, we introduce the three-phase execution-sort-verify architecture and explain the transaction flow. The formation of Fabric is covered in Chapter 4.

3.1 an overview of the Fabric

Fabric is a distributed blockchain system with access rights that can execute distributed applications written in general-purpose programming languages (e.g., Go, Java, Node.js). It securely tracks execution history on an app-only ledger structure and has no built-in cryptocurrency.

Fabric introduces the execution-sort-fancy blockchain architecture and does not adopt a standard sort execution design, for reasons described in Chapter 2. In short, a distributed application of Fabric consists of two parts:

• A smart contract, called a chain code, is the program code that implements the application logic and runs in the execution phase. Chain codes are at the heart of distributed applications in fabric and can be developed by untrusted developers. There is a special class of chain codes that exist in the system to manage the blockchain system and maintain parameters, called system chain codes. (see 4.6)
• Endorsement policy, which is executed during validation. Endorsement policies cannot be selected and modified by distrusted app developers; They are part of the system. An endorsement policy is a static library in the Fabric that can be specified by chain codes as parameters. Only designated administrators can run system administration functions and modify endorsement policies.

A typical endorsement strategy makes the chain code specify the endorser of the transaction, which is specified by a series of peer nodes that need to endorse. It uses A simple set of logical expressions, such as “three of five” or “A and B or B and C”. Custom endorsement policies can implement arbitrary logic (for example, with our Bitcoin cryptocurrency, see Section 5.1).

The client sends the transaction to the peer specified in the endorsement policy. Each transaction is executed by a particular node and the result is recorded, also known as endorsement. After execution, transactions enter a sorting phase, where a pluggable consensus protocol is used to produce uniformly sorted transactions that are packaged into blocks. These blocks are broadcast to all nodes using the Gossip protocol. Unlike standard active replication [31], which completely sorts transaction inputs, Fabric sort combines the transaction output of the state with the results calculated during the transaction execution phase. Each node verifies the state change and execution consistency of endorsement transaction in the verification stage. All nodes validate transactions in the same order and the validation is deterministic. In this sense, Fabric introduced a new hybrid replication paradigm in the Byzantine model, combining passive replication (pre-consistent calculation of state updates) and active replication (post-consistent verification of results and state changes performed).

The execution-sort-checksum architecture of Fabric (RW-set stands for read and write sets, described in 3.2)

The sequential validation method is shown in Figure 2.

A Fabric blockchain system consists of a series of nodes that form a network. Just as Fabric is permission controlled, all nodes participating in the network carry identity through a modular member service provider (MSP) (Section 4.1). Nodes play three roles in a Fabric network:

Client: Submits a trade proposal for execution, helps orchestrate the execution phase, and finally, broadcasts the transaction to the sorting service.

Peers: Execute a trade proposal while verifying a trade. Peer also maintains a blockchain ledger, an appending data structure used to record transactions, forming a hash chain, as well as stateful, a concise representation of the ledger’s state. Not all nodes execute all transaction proposals, only some are called endorser nodes (or simply endorsers), which are specified by the chain code policy to be associated with which transaction. However, all nodes hold complete ledgers.

Sort service node

Called simply Orderer, it is a common ordering service component. In short, the sorting service establishes the order of all transactions in the Fabric, and at execution time each transaction contains status updates and computed dependencies, and is signed by the endorsement node. Orderers do not know the application status and do not participate in the execution or validation of transactions. This design renders the consensus of modularity in the Fabric and simplifies the switching of consensus protocols.

High-level transaction flow in the Fabric

Because it is possible to play different roles on the same physical node, Fabric can be operated like a traditional peer-to-peer blockchain system, maintaining state, invoking, verifying, and ordering transactions on each node. The transaction flow of different nodes is described in Figure 3.

In contrast to the unknown blockchain that only supports single chains, Fabric networks have so far supported multi-chain mechanisms that allow multiple chains to be connected to sorting services. Each blockchain is called a channel and has different nodes as members. However, the channel-based consensus does not coordinate all transactions. Each channel is independent of other channels. All deployments assume that all orderers are trusted and also implement channel-based permission control at the peer level. In the following, let’s briefly mention channels, focusing on one channel.

The next three sections explain the flow of transactions in the Fabric, clarifying the steps for execution, sorting, and validation. A Fabric network is shown in Figure 4.

A Fabric network with an alliance MSP and chain codes running (in different shades and colors) are selectively installed on nodes according to policy.

Endorsement nodes simulate proposals and perform actions through specific chain codes installed in the blockchain. The chain code runs in the Docker container and is independent of the endorsement process.

At this time, a proposal is simulated based on the local state of endorsement node without synchronization with other nodes. Even endorsement nodes do not persist simulated results into ledger state. The state of the blockchain is maintained by the Peer Transaction Manager (PTM) in key-value pairs with versions, and a successful update monotonically increases the value of the version (see 4.4). A state created by one chain cannot be accessed directly by another chain. Chain codes should not maintain state in program code. The only ones that can be maintained should be the GetState, PutState, and DelState operations. With appropriate permissions, one chain code can call another chain code in the same channel to obtain state.

As a result of the simulation, each endorser generates a Writeset that contains status updates generated by the simulation execution (for example, modifying a key with a new value), as well as a readset that represents the version of the dependency on which the proposal simulation is based (for example, the version of all read keys). After the simulation, the endorsement node signs a message called endorsement, which contains a read set, a write set, (as well as metadata such as transaction ID, endorser ID, and endorser signature), and sends a proposal response back to the client. A client collects until the chain code endorsement policy is met, the transaction is called (see 3.4). In particular, this requires all endorsers to definitively produce the same execution results (for example, the same read and write sets). The client then proceeds to create the transaction and send it to the sorting service.

** Discussion of design choices. ** The simulated execution of transactions by endorsement node is not synchronized with other endorsement nodes, and the two endorsement nodes may execute according to different account states and thus produce different outputs. For a standard endorsement policy, multiple endorsement nodes are required to produce the same result, which means that in multiple operations over the same key argument, a client may not be able to satisfy the endorsement policy. This is a new element compared to primary/secondary replication in replication (through middleware [24]) : it is assumed that none of the node’s execution results are trusted in the blockchain network.

We consciously adopted this design because it simplifies the architecture and is well suited for blockchain applications. As bitcoin demonstrates, distributed applications can normally reduce or eliminate operations that access the same state (for example, in Bitcoin, two operations that modify the same object are not allowed, representing a double-flower attack [28]).

Executing trades before the sorting stage is a very important point in tolerating uncertain chain codes in section 2. An uncertain transaction in the Fabric only jeopardizes its own activity because the client is unable to collect a sufficient number of endorsements, which is more acceptable in practice than sorted execution architectures, which lead to inconsistent node states.

Finally, tolerating uncertain execution can also handle DoS attacks with untrusted chain codes, because the endorsement node can terminate execution according to local execution policies if it suspects a DoS attack. This does not affect the consistency of the system, and such unilateral termination is not possible in the sorted execution architecture.

3.3 Sorting Stage

When the client has collected enough endorsements on the proposal, it assembles a transaction and submits it to the sorting service. The transaction includes the payload of the transaction (for example, parameters related to the chain code operation), the transaction metadata, and a series of endorsements. The sorting service sorts all transactions on each channel. In other words, the ordering source atoms broadcast [7] endorsements, thus reaching a consensus on the transaction, despite the possibility of having the wrong ordering person. In addition, the sorting service packages multiple transactions into a block and outputs a block with a hash chain containing the transaction. Grouping or bulk packaging transactions into blocks can improve throughput of broadcast protocols, a well-known technique in fault-tolerant broadcast environments.

At a high level, the sorting service only supports the following two operations. These operations are implicitly parameterized by the peer node through channel identifiers:

Broadcast: This operation is called by the client to broadcast any transaction TX, which usually contains the transaction payload and the client’s signature for propagation.

Deliver: This method is called by the client to retrieve the block B with a non-negative serial number S. The block contains a list of transactions and a hash chain value h representing the block with serial number is, i.e. Since clients can call it multiple times and always return the same block once it is available, we say that the Peer passes block B with serial number S when B is first received in a call to Deliver.

The sorting service ensures that blocks delivered on a channel are completely ordered. More specifically, sorting ensures the following security attributes for each channel:

Protocol: For any two blocks B with serial numbers S and, transmitted on the correct Peer, such as S =s’, it guarantees B=B’.

Hashchain integrity: If one correct node passes block B with number S and another correct node passes block B’=([tx1,… TXK],h’) with number S +1, it preserves h’= h (B), where h (.) Represents an encrypted hash function.

Do not skip: if the correct node p is for each I =0… ,s-1 sends a block whose id is S >0, node P has sent a block whose id is I.

None created: When the correct node passes block B with the number S, for each tx < B, a client has broadcast tx.

To be active, the sorting service supports at least the following “final” properties:

Validity: If the correct client invokes broadcast (TX), each correct node will eventually transmit a block B containing tx, which contains some serial number.

However, allowing each individual ordering implementation to have its own activity and fairness guarantees for customer requests.

Because there may be a large number of nodes in a blockchain network, but relatively few nodes are expected to implement the sorting service nodes, Fabric can be configured to propagate the delivered blocks from the sorting service to all Peer nodes using the built-in Gossip service (Section 4.3). The implementation of Gossip is extensible and independent of the particular implementation of the sorting service, so it applies to BOTH CFT and BFT ordering services, ensuring the modularity of Fabric.

The sorting service can also perform access control checks to see if clients are allowed to broadcast messages or receive blocks on a given channel. This and other capabilities of the sorting service are further described in Section 4.2.

Discussion of design choices. It is important that the sorting service does not maintain any state of the blockchain and neither validates nor performs transactions. This architecture is an important defining feature of Fabric, which makes Fabric the first blockchain system that can fully distinguish consensus between execution and validation. This makes consensus as modular as possible and enables a consensus protocol ecosystem that implements sorting services.

3.4 Verification Phase

Deliver the block to the Peer node either by connecting directly to the sorting service or via gossip. When a new block arrives, it enters the validation phase, which consists of three consecutive steps:

1. Endorsement policy checks occur in parallel for all transactions within the block. Validation is the task of the so-called Validation System Chain Code (VSCC), a static library that is part of the blockchain configuration and is responsible for verifying the endorsement policy configured for the chain code (see section 4.6). If the checksum is not satisfactory, the transaction is marked as invalid and its impact is ignored.

2. Perform read/write conflict checks on all transactions in the block in sequence. For each transaction, it compares the version of the key in the readset field to the version in the current state of the ledger, stored locally by the node, and ensures that they remain the same. If the versions do not match, the transaction is marked as invalid and its impact is ignored.

3. The ledger update phase runs finally, where blocks are attached to the locally stored ledger and the blockchain state is updated. In particular, when a block is added to the ledger, the validity check results from the first two steps are also retained as bitmasks representing valid transactions within the block. This helps to recreate the state later. In addition, all state updates are applied by writing all key-value pairs in writeset to local state.

The default VSCC in Fabric allows monotonous logical expressions over an endorsement set that represents the configuration of the chain code. The VSCC evaluation proves that the set of nodes expressed by valid signatures satisfies the expression through the recognition of transactions. However, different VSCC policies can be configured statically.

Discussion of design choices. Fabric’s ledger contains all transactions, including those deemed invalid. This is derived from the overall design, because the ordering service, independent of the chain code state, produces the chain of blocks, and because the validation is done by the consensus Peer node. This capability is required in some use cases where invalid transactions need to be tracked during subsequent audits, and is contrasted with other blockchains Figure 5. Fabric Peer node components.

4. The Fabric components

Fabric is written in Go, using the gRPC framework (grpc.io/) for clients, Peer…

4.1 Member Services

The member service provider (MSP) maintains the identity of all nodes in the system (clients, Peer nodes, and collators) and is responsible for issuing node credentials for authentication and authorization. Because Fabric is licensed, all interactions between nodes occur through authenticated messages, usually using digital signatures. Membership services include components for each node where transactions can be verified, the integrity of transactions verified, endorsements signed, endorsements verified, and other blockchain operations verified. Tools for key management and node registration are also part of the MSP.

An MSP is an abstraction that can use different instances. The default MSP implementation in Fabric handles the standard PKI approach based on digital signatures and can accommodate commercial certification authorities (cas). Separate CA and Fabric are also provided, called fabric-CA. In addition, alternative MSP implementations are envisaged, such as relying on anonymous credentials to authorize clients to invoke transactions without linking them to identities [10].

Fabric allows two modes to set up a blockchain network. In FL ine mode, credentials are generated by the CA and distributed out of band to all nodes. Peers and subscribers can only register in FL INE mode. For registered clients, Fabric-CA provides an online mode to issue encrypted credentials to. The MSP configuration must ensure that all nodes, especially all nodes, recognize the same identity and authentication as valid.

MSP allows for identity federation, for example, when multiple organizations are running a blockchain network. Each organization issues status to its members, and each peer recognizes members of all organizations. This can be done with multiple MSP instances, for example, by creating mappings between each organization and the MSP.

4.2 Sorting Services

The sorting service manages multiple channels. At each channel, it provides the following services:

1. For resume transaction order, broadcast and delivery services.
2. Channels can be reconfigured when members update transactions through broadcast configurations.
3. Optionally, in configurations where the sorting service acts as a trusted entity, you can restrict the broadcast of transactions to specific client and Peer nodes.

The sorting service is started on the system channel using genesis block. This block defines the attributes of the sort service.

Current production implementations include subscription service nodes (OSNs) that implement the operations described here and communicate over system channels. The actual atomic broadcast functionality is provided by an instance of Apache Kafka (http://kafka.apache.org), which provides scalable publish-subscribe messaging and strong consistency of node crashes based on ZooKeeper. Kafka can run on a physical node separate from the OSN. The OSN acts as a proxy between the Peer and Kafka.

The OSN directly injects newly received transactions into atomic broadcasts (for example, to Kafka Broker). Node bulk transactions, on the other hand, are received from blocks broadcast by atoms. A block is cut as long as one of the following three conditions is met :(1) the block contains the specified maximum number of transactions; (2) The block has reached its maximum size (in bytes); Or (3) the amount of time that has elapsed since the first transaction for the new block was received, as described below.

The batch process is deterministic and therefore produces the same block at all nodes. Given the flow of transactions received from atomic broadcasts, it is easy to see that the first two conditions are trivial certainties. To ensure deterministic block generation in the third case, the node starts a timer when the first transaction in the block is read from the atomic broadcast. If the block has not been cut by the time the timer expires, the node broadcasts a special cut time transaction on the channel indicating the serial number of the block it wants to cut. On the other hand, each node cuts off the new block as soon as it receives the first switch-time transaction for a given block number. Because this transaction is passed atomically to all connected nodes, they all contain the same list of transactions in the block. (To deploy this scheme in the presence of F Byzantine failed OSNs, the block is only cut when f+1 time switching transactions are received.) The sorter saves the most recently delivered series of blocks directly to its file system, so they can answer the Peer node by delivering a retrieval block.

The sorting service using Kafka is one of three currently available. A centralized sorting service called Solo runs on a node for development. A bFT-smart proof of concept sort [3] has also been provided [34]; It ensures atomic broadcast service but has not yet been reconfigured and access control. This illustrates the modularity of consensus in the Fabric.

4.3 Peer Gossip

One advantage of separating sort and validation execution is that they can be extended independently. However, since most conformance algorithms (in both CFT and BFT models) are bandwidth-constrained, the throughput of the sorting service is limited by the network capacity of its nodes. Consensus cannot be expanded by adding more nodes [14,36], but throughput is reduced. However, since sorting and validation are separate, we are interested in effectively broadcasting the execution results to all Peer nodes for validation after the sorting segment. This is the goal of the Gossip component, which utilizes popular multicast for this purpose [15]. These blocks are signed by the sorting service. This means that Peer nodes can independently assemble the blockchain and verify its integrity when they receive all the blocks.

Compared to overlay networks, propagation through gossip is powerful and resistant to node failures. Making random selection allows gossip to reduce the overhead of maintaining connections between Peer nodes and also reduces the attack surface. Gossip works well in permitted environments and can withstand Sybil attacks and message forgery.

The communication layer for gossip is based on gRPC and utilizes TLS with mutual authentication, which enables each party to bind TLS credentials to the identity of the remote Peer. The gossip component maintains the latest member view of the online Peer in the system. All peers independently build local views from regularly propagated membership data. In addition, nodes can reconnect to the view after a crash or network outage.

The main purpose of gossip is to reliably distribute messages, i.e. blocks from the sort phase, between nodes using a push-pull protocol. It uses two phases for information dissemination: during push, each node selects a random set of active neighbors from the membership view and forwards them to them; During the pull, each node periodically probes a randomly selected set of nodes and relooks for missing messages. It has been shown [15,22] that concatenating the two methods is critical to make optimal use of the available bandwidth and to ensure that all nodes receive all messages with high probability.

To reduce the load of sending blocks from the sorting nodes to the network, the protocol also selects a leader node that extracts blocks from the sorting service on their behalf and initiates gossip distribution. This mechanism is resilient to leadership failure.

Another task of Bagua is to transfer state to newly connected nodes and nodes that have been disconnected for a long time. They need to receive all the blocks in the chain. This feature relies on the fact that the largest chunk of the serial number stored by each node is propagated along with membership data.

4.4 ledger

Each Peer’s ledger component maintains ledger and blockchain state on persistent storage and enables the emulation, validation, and ledger update phases. Broadly speaking, it consists of block storage and node transaction Manager (PTM).

Ledger block storage. The ledger block stores persistent transaction blocks and is implemented as a set of add-only files. Because blocks are immutable and arrive in a finite order, attaching structures alone provides maximum performance. In addition, block storage maintains indexes for random access to blocks or transactions within blocks.

Node Transaction Manager (PTM). PTM maintains the latest state in the versioned key-value store. It is a tuple of the key store form (key, val, ver) for each unique item stored by any chain code, containing its most recently stored value val and its latest version ver. Versions consist of the block serial number and the serial number of transactions (stored entries) within the block. This makes the version unique and monotonous.

PTM uses local key-value stores for versioning key-value stores, implemented by the LevelDB key-value database implemented in Go (https:// github.com/syndtr/goleveldb) or Apache CouchDB (HTTP: / / couchdb.apache.org/).

During simulation, PTM provides a stable snapshot of the latest state of transactions. As described in Section 3.2, PTM records a tuple (key, ver) for each item accessed by GetState in readset and a tuple (key, val) for each item updated by a transaction with PutState in writeset. In addition, PTM supports range queries, for which an encrypted hash (a set of tuples (key, ver)) of the query result is computed and the query string itself and the hash value are added to the readset.

For transaction validation (Section 3.4, p. 394), PTM validates all transactions in a block sequentially. This checks to see if the transaction conflicts with any previous transaction (within the block or earlier). For any key in the READset, if the version recorded in the readset is different from the version that exists in the latest state (assuming all previous valid transactions have been committed), the PTM marks the transaction as invalid. For range queries, PTM re-executes the query and compares the hashes to those that exist in readSET to ensure that no phantom reads occur. This read-write conflict semantics leads to serialization of single copies [23].

The ledger component tolerates Peer crashes during ledger updates, as shown below. After receiving the new block, PTM has performed validation in the block and marked the transaction as valid or invalid using the bitmask mentioned in Section 3.4. The ledger now writes the block to the ledger block store, copies it to disk, and then updates the block store index. PTM then applies state changes to the writeset of all valid transactions to the local version store. Finally, it calculates and holds a value savepoint representing the block number with the most successful application. The value savepoint is used to recover the index and latest state from persistent blocks when recovering from a crash.

4.5 Chaincode perform

Chaincode executes in a loosely coupled environment with the rest of the Peer node and supports plug-ins for adding new languages to the programming Chaincode. Currently, chain code supports three languages: Go, Java, and Node.

Each user-level or application-chain code runs in a separate process in the Docker container environment, which isolates the chain code from each other and from the node code. This also simplifies the management of the chain code lifecycle (that is, start, stop, or abort the chain code). The chain code and its peers communicate using gRPC messages. Through this loose coupling, the Peer node does not know the actual language that implements the chain code.

In contrast to application chain code, system chain code runs directly in the peer process. System chain code can implement specific functions required by Fabric and can be used in situations where isolation between user chain codes is overly restrictive. For more details on system chain code, see the next section.

4.6 Configuring and System Chain Codes

The basic behavior of Fabric is composed of channel configurations and special chain codes (called system chain codes).

Channel configuration. Recall that a channel forms a logical blockchain. The configuration of the channel is stored in metadata in a special configuration block. Each configuration block contains the complete channel configuration and does not contain any other transactions. Each blockchain starts with a configuration block called the Genesis block, which is used to direct the channel. Channel configuration includes:

• Participate in the MSP definition of nodes. • Network address of the OSN. • Consensus implementation and shared configuration of ordering services, such as batch sizes and timeouts. • Rules governing access to sort service operations (broadcast and delivery). • You can modify the rules that govern each part of the channel configuration.

Channel configuration can be updated using a channel configuration update transaction. This transaction contains a representation of the changes made to the configuration, along with a set of signatures. The ordering service node verifies the use of signature authorization to modify by validating the update with the current configuration. The sorter then generates a new configuration block with the new configuration and configuration update transaction embedded. The node receiving this block verifies that the configuration update is authorized based on the current configuration; If it works, they update the current configuration.

System chain code. The Approved System Chain Code (ESCC) and Validated System Chain Code (VSCC) are referenced when the application chain code is deployed. The two chain codes are selected symmetrically so that the output of the ESCC (approved) can be validated as part of the input to the VSCC.

ESCC takes the proposal and the proposal simulation results as input. If the result is satisfactory, ESCC generates a response containing the result and approval. For the default ESCC, this recognition is simply a signature of the peer’s locally signed identity.

VSCC takes the transaction as input and outputs whether the transaction is valid. For the default VSCC, accreditation is collected and evaluated according to the accreditation policy specified for the chain code.

Other system chain code implements other supporting functions, such as configuration and chain code lifecycle.

5. Evaluate

Although Fabric has not been tuned and optimized for performance, we will report some preliminary performance data in this section. Fabric is a complex distributed system; Its performance depends on a number of parameters, including the choice of distributed applications and transaction sizes, sorting services and consensus implementations and their parameters, network parameters and topology of the nodes in the network, the hardware on which the nodes run, the number of nodes and channels, further configuration parameters and network dynamics. As a result, in-depth performance evaluation of Fabric has been deferred for future work.

In the absence of a blockchain standard benchmark, we used the most prominent blockchain application to evaluate Fabric, a simple authoritatively minted cryptocurrency that uses bitcoin’s data model, which we call Fabric Coin (hereinafter referred to as Fabcoin). This allows us to place Fabric’s performance in the context of other licensed blockchains, typically from Bitcoin or Ethereum. For example, it is also an application used in other licensed blockchain benchmarks [19,32].

In the following article, we first describe Fabcoin (Section 5.1, p. 51), which also demonstrates how to customize the validation phase and approval policies. In Section 5.2, we present benchmarks and discuss our results.

5.1 the Fabric”

UTXO cryptocurrency. The data model introduced by Bitcoin [28] has been referred to as “unused transaction output” or UTXO, and is used by many other cryptocurrencies and distributed applications. UTXO represents each step in the evolution of a data object as a separate atomic state in the ledger. This state is created by a transaction and destroyed (or “consumed”) by another unique transaction that occurs later. Each given transaction destroys many input states and creates one or more output states. The “coins” in Bitcoin were originally created through coin-base transactions that rewarded “miners” of blocks. This shows up in the ledger as the status of the coins that designate the miner as the owner. Any coin can be spent in the sense that the coin is allocated to the new owner through a transaction that atomically destroys the current coin state specifying the previous owner and creates another coin state representing the new owner.

We capture the UTXO model in the key-value store of Fabric, as shown below. Each UTXO state corresponds to a unique KVS entry created once (coin state “not spent”) and destroyed once (coin state “spent”). Equivalently, each state can be treated as a KVS entry created with logical version 0; When it is destroyed again, it receives version 1. No concurrent updates should be made to these entries (for example, trying to update the coin’s state in a different way equals double the cost of the coin).

Values in the UTXO model are transmitted through transactions that reference several input states that belong to the entity issuing the transaction. An entity has a state because the entity’s public key is contained in the state itself. Each transaction creates one or more output states in the KVS representing the new owner, removes the input states in the KVS, and ensures that the sum of the values in the input states equals the sum of the values in the output states. There is also a policy that determines how value is created (for example, coin cluster transactions in Bitcoin or specific mint operations in other systems) or destroyed (that is, as a cost of execution).

Fabcoin implementation. Each state in Fabcoin is a tuple of form (key, val = txID.j,(amount, owner, label)) that represents the coin state created as the JTH output of a transaction with identifier TXID, and assigns the unit of amount labeled label to the entity that owns the public key. A label is a string used to identify a given type of coin (for example, “USD”, “EUR”, “FBC”). A transaction identifier is a short value that uniquely identifies each Fabric transaction. Fabcoin implementation consists of three parts :(1) customer wallet, (2) Fabcoin chain code, and (3) custom VSCC for Fabcoin implementation of its endorsement policy.

Fabcoin chain code. Peer runs Fabcoin’s chain code, simulates transactions and creates read and write sets. In short, in the case of SPEND transaction, for each input coin state in ∈ input, the chain code first performs GetState (in); This goes into readset with the current version in Fabric’s versioning KVS (sec.4.4). The chain code then performs DelState (in) for each input state, which also adds to writeset and effectively marks the coin state as “cost.” Finally, for j=1… Output, | |, chain code execution PutState txid. J, (out) the first j output = (amount, owner, tag). In addition, the node optionally runs the transaction validation code, as described below in the VSCC step of Fabcoin; This is not necessary because the custom VSCC actually validates the transaction, but it allows the (correct) node to filter out potentially ill-formed transactions. In our implementation, the chain code runs Fabcoin VSCC without encryption to verify the signature.

Custom VSCC. Finally, each peer verifies the Fabcoin transaction using a custom VSCC. This validation begins with the cryptographic signature in the SIG under the corresponding public methodology. In each experiment, in the first phase, we invoke a transaction involving only the Fabcoin MINT operation to generate coins, and then run the second phase of the experiment, we invoke the Fabcoin SPEND operation (effectively run single input, single output SPEND transaction) on the previously minted coins. When reporting throughput measurements, we used more and more Fabric CLI clients running on a single VM (modified to make concurrent requests) until end-to-end throughput was saturated and stated before saturation. Throughput data is reported as average throughput keys and the following semantic validation is performed. For MINT transactions, it checks that the output state is created under a matching transaction identifier (TXID) and that all outputs are positive. With respect to SPEND transactions, VSCC also verifies that (1) for all input coin states, the entry in the readset has been created and is also a Client wallet. By default, each Fabric client maintains a Fabcoin wallet added to writeset and marked as removed, and (2) a Fabcoin wallet that locally stores the set of encryption keys for all amounts entered in coin states equal to the sum of coins allowed to be spent by the client. To create the amount of SPEND that outputs all the coin states, and (3) transfer the inputs and outputs of one or more coins, the client wallet matches the coin labels. Here, VSCC obtains the amount of Fabcoin request =(input, output, sigs) created for input coins by retrieving their current values from the ledger.

2 Allocate data using the commit ID 9E770062 in the main branch of the Fabric.

Contains :(1) enter the coin status list at… | = | in the input, specify the customer wants to spend COINS state (in…) , note that Fabcoin VSCC does not check transacwell for (2) outputting list of coin states, outputting the amount, owner, and double outgoings to the tions as this passes through Fabric tags),… |. The client wallet is signed with a private key that is a standard validation run after a custom VSCC. In the case that corresponds to the input coin state, if two transactions attempt to allocate the same unFabcoin request and nonce (which is part of the coin state each Fabric spends to the new owner), the concatenation of both will pass through the VSCC transaction and add the signature in a set of SIGs. The SPEND logic is then captured in a read/write transaction when the sum in the uncertainty check performed by PTM is added up. According to Secput, the coin state is at least the sum of the amounts in outputs 3.4 and 4.4, and PTM verifies that the outputs and outputs of the current version are positive. Matches the MINT number stored in the ledger with the readset number; Therefore, after the first transaction changes the identifier of the state of the particular coin (i.e., a reference to the public key), the second ordered transaction will be called central bank (CB), and the output containing nized is invalid. Any number of coin states. To be considered valid, the 5.2 experimental signature of MINT transactions in SIGS must be an encryption setting. Unless explicitly stated otherwise, in our external signature experiment under CB’s public key :(1) the node is running on the Fabric version v1.1-preview2 of the Fab version request, as well as the previously mentioned meter for performance evaluation via local lognonce. Fabcoin can be configured to use multiple CB’s or GING, (2) nodes hosted in a single IBM Cloud (SoftLayer) specifying a threshold number of signatures from a set of CB’s. Data center as dedicated VIRTUAL machine interconnecting with 1Gbps network Finally, client wallet consists of converting Fabcoin requests to work, (3) all nodes are 2.0 GHz 16-vCPU virtual machines running transactions and sending them to their chosen peer. Ubuntu has 8GB of RAM and SSDS as local disks, (4) single channel subscription service runs typical Kafka subscriber setup, including 3 ZooKeeper nodes, 4 Kafka agents and 3 Fabric Orderers, all on different VMS, (5) there are 5 peers in total, All of these are Fabcoin endorsements, (6) signed using the default 256-bit ECDSA scheme. To measure and grade latency in transaction flows across multiple nodes, node clocks were synchronized with the NTP service throughout the experiment. All communication between Fabric nodes is configured to use TLS.

We can observe that the throughput does not significantly exceed the 2MB block size, but the latency gets worse (as expected). Therefore, we use 2MB as the block size for the following experiment, with the goal of maximizing the throughput measured, assuming that an end-to-end delay of around 500ms is acceptable.

Deal size. During this experiment, we also looked at the size of MINT and SPEND transactions. In particular, the 2MB block contains 473 MINT or 670 SPEND transactions, which means that the average transaction size of SPEND is 3.06kB and MINT’s average transaction size is 4.33kB. Typically, transactions in the Fabric are large because they carry certificate information. In addition, Fabcoin’s MINT transactions are greater than SPEND transactions because they come with CB certificates. This is how Fabric and Fabcoin will improve in the future.

Peer CPU impact. Fabric peers run many CPU-intensive encryption operations. To estimate the CPU’s impact on throughput, we ran a series of experiments with 4 peers running on 4, 8, 16, and 32 vCPU VMS, along with coarse-grained delay grading of block validation to better identify bottlenecks. Our experiments focused on the verification phase, because Kafka subscriptions were never a bottleneck in our experiments. Finally, in this experiment, we measured the average SPEND throughput of 3560 transactions per second (TPS) on a 32-vCPU peer. In general, MINT throughput is slightly less than SPEND, but the difference is still within 10%.

The delay took place in stages. Coarse-grained delay analysis of reported peak throughput was further performed in our last experiment. The results are shown in Table 1. The sorting phase includes broadcast delivery delays and internal delays in the peer before validation begins. The table reports the average latency, standard deviation, and tail latency for MINT and SPEND (99% and 99.9%).

We can observe that sorting dominates the overall delay. We observed an average latency of less than 550 ms and a tail latency of subseconds. In particular, the highest end-to-end delay in our experiment came from the first block during load establishment. The delay under low load can be adjusted and reduced by using the orderer’s time cut parameter (see section 3.3), which we basically do not use in the experiment because we set it to a large value.

SSD and RAM disks. To evaluate the overhead of stable storage using local SSDS, we repeated the previous experiment with RAM disks (TMPFS) installed as stable storage on all node VMS. The benefits are limited, as TMPFS can only help with the ledger phase of peer verification. We measured a sustained peak throughput of 3870 SPEND TPS on 32 vcpus, approximately 9% higher than SSD.

Table 1. MINT and SPEND delay statistics, in milliseconds (ms), on a 32-vCPU peer with a 2MB block, divided into five phases. Validation (6) includes stages 3,4, and 5; The end-to-end delay consists of stages 1-5.

6. Related work

Fabric’s architecture is similar to the middleware replication database pioneered by Kemme and Alonso [24]. However, all existing work on this only addresses crash failures, not the setup of distributed trust corresponding to BFT systems. For example, a replicated database [25, sec.6.3] with asymmetric update processing relies on a single node to perform each transaction, which is not applicable to blockchain. The execution sequence verification architecture of Fabric can be interpreted as a generalization of this work on the Byzantine model, as well as the practical application of distributed ledgers. From the perspective of BFT database replication, Byzantium [17] and HRDB [35] are two other precursors to Fabric. Byzantium allows transactions to run in parallel and use active replication, but entirely using the BFT middleware commands BEGIN and COMMIT/ROLLBACK. In optimistic mode, each operation is coordinated by a master copy; If the master device is suspected to be Byzantine, all copies perform transactions for the master device and trigger expensive protocols to change the master device. HRDB relies on the right master in a more powerful way. In contrast to Fabric, both systems use active replication, cannot handle flexible trust models, and rely on deterministic operations of replicas. However, their database API is richer than Fabric’s KVS model.

In Eve [21], related architecture of SMR is also explored in THE BFT model. Its peers execute transactions simultaneously and then use a consensus protocol to verify that they have all reached the same output state. If the state diverges, they roll back and perform operations in sequence. Eve contains independently executed elements that also exist in the Fabric but provide no additional functionality.

A large number of distributed ledger platforms in the licensing model have recently emerged, which makes it impossible to compare with all distributed ledgers (some prominent are Tendermint [5], Quorum [19], Chain Core [12], Multichain < HTTPS: / / www.multichain.com/ >, Hyperledger Sawtoothsawtooth.hyperledger.org, the Volt proposal [32], etc., please refer to the overview of the recent references in dec [9]. All platforms follow the order-execution architecture, as described in Section 2. As a representative example, use Quorum Platform [19], an enterprise-centric version of Ethereum. Based on the consensus of Raft [29], it uses gossip to propagate transactions to all peers, and the Raft leader (called a Minter) assembles valid transactions into a block and distributes this using Raft. All peers execute transactions in the order determined by the leader. Therefore, it is subject to the limitations mentioned in section 1-2.

reference

[1] P.-L. Aublin, R. Guerraoui, N. Knezevi, C, V. Qu ´ ema, And M. Vukolic. The Next 700 BFT Protocols. ´ ACM Trans-comput. Syst., 32(4):12:1 — 12:45, Jan. 2015.

[2] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza. Zerocash: Decentralized anonymous payments on bitcoin. IEEE Symposium on Security & Privacy, Pages 459 — 474, 2014.

[3] A. N. Bessani, J. Sousa, and E. A. P. Alchieri. State machine replication for the masses with BFT-SMART. In International Conference on Whosesystems and Networks (DSN), Pages 355 — 362, 2014.

[4] G. Bracha and S. Toueg. Asynchronous consensus and broadcast protocols. J. ACM, 32(4):824–840, 1985.

[5] E. Buchman. Tendermint: Byzantine fault tolerance in the age of blockchains. M.Sc. Thesis, University of Guelph, Canada, June 2016. [6] N. Budhiraja, K. Marzullo, F. B. Schneider, and S. Toueg. The primary-backup approach. In S. Mullender, Editor, Distributed Systems (2nd Ed.), pages 199 — 216. ACM Press/AddisonWesley, 1993.

[7] C. Cachin, R. Guerraoui, and L. E. T. Rodrigues. Introduction to Reliable and Secure Distributed Programming (2. ed.). Springer, 2011.

[8] C. Cachin, S. Schubert, and M. Vukolic. Non-determinism ´ in byzantine fault-tolerant replication. In 20th International Conference on Principles of Distributed Systems (OPODIS), 2016.

[9] C. Cachin and M. Vukolic. Blockchain consensus protocols ´ in the wild. In A. W. Richa, editor, 31st Intl. Symposium on Distributed Computing (DISC 2017), pages 1:1–1:16, 2017.

[10] J. Camenisch and E. V. Herreweghen. Design and implementation of the idemix anonymous credential system. In ACM Conference on Computer and Communications Security (CCS), Pages 21 — 30, 2002.

[11] M. Castro and B. Liskov. Practical Byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst., 20 (4) : 398-461, Nov., 2002.

[12] Chain. Chain protocol whitepaper. Chain.com/ docs / 1.2 / protocol/cca shut/whitepaper, 2017.

[13] B. Charron-Bost, F. Pedone, and A. Schiper, editors. Replication: Theory and Practice, volume 5959 of Lecture Notes in Computer Science. Springer, 2010.

[14] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena, E. Shi, E. G. Sirer, et al. On scaling decentralized blockchains. In International Conference on Financial Cryptography and Data Security (FC), Pages 106 — 125. Springer, 2016.

[15] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart, and D. Terry. Epidemic algorithms for replicated database maintenance. In ACM Symposium on Principles of Distributed Computing (PODC, Pages 1-12. ACM, 1987.

[16] T. T. A. Dinh, R. Liu, M. Zhang, G. Chen, B. C. Ooi, and J. Wang. Untangling blockchain: A data processing view of blockchain systems. e-print, arXiv:1708.05665 [cs.DB], 2017.

[17] R. Garcia, R. Rodrigues, And N. M. Preguic a. Efficient middleware for Byzantine Fault Tolerant database replication. In the European Conference on Computer Systems (EuroSys), Pages 107 — 122, 2011.

[18] R. Guerraoui, R. R. Levy, B. Pochon, And V. quema. Through- ´ put optimal total order broadcast for cluster environments. ACM trans.comput.syst., 28 (2) : 5:1 – observe, 2010.

[19] J. P. Morgan. Quorum whitepaper. github.com/ jpmorganchase/quorum-docs, 2016.

[20] F. P. Junqueira, B. C. Reed, and M. Serafini. Zab: Highperformance broadcast for primary-backup systems. In International Conference on Dependable Systems & Networks (DSN), pages 245–256, 2011.

[21] M. Kapritsos, Y. Wang, V. Quema, A. Clement, L. Alvisi, ´ and M. Dahlin. All about Eve: Execute-verify replication for multi-core servers. In Symposium on Operating Systems Design and Implementation (OSDI), pages 237–250, 2012.

[22] R. Karp, C. Schindelhauer, S. Shenker, and B. Vocking. Randomized rumor spreading. In Symposium on Foundations of Computer Science (FOCS), pages 565–574. IEEE, 2000.

[23] B. Kemme. One-copy-serializability. In Encyclopedia of Database Systems, pages 1947–1948. Springer, 2009.

[24] B. Kemme and G. Alonso. A new approach to developing and implementing eager database replication protocols. ACM Transactions on Database Systems, 25(3):333 — 379, 2000.

[25] B. Kemme, R. Jimenez-Peris, And M. Pati ´ no-mart ınez. Database Replication. Synthesis Lectures on Data Management. Morgan & Claypool Publishers, 2010.

[26] A. E. Kosba, A. Miller, E. Shi, Z. Wen, and C. Papamanthou. Hawk: The blockchain model of cryptography and privacypreserving smart contracts. In 37th IEEE Symposium on Security & Privacy, 2016.

[27] S. Liu, P. Viotti, C. Cachin, V. Quema, and M. Vukoli ´ C.xft: Practical fault tolerance beyond crashes. In Symposium on Operating Systems Design and Implementation (OSDI), Pages 485-500, 2016.

[28] S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. www.bitcoin.org/bitcoin.pdf, 2009.

[29] D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. In USENIX Annual Technical Conference (ATC), Pages 305 — 320, 2014.

[30] F. Pedone and A. Schiper. Handling message semantics with Generic Broadcast protocols. Distributed Computing, 15 (2) : 97-107, 2002.

[31] F. B. Schneider. Implementing fault-tolerant services using the state machine approach: ACM Comput. Surv., 22(4):299 — 319, 1990.

[32] S. Setty, S. Basu, L. Zhou, M. L. Roberts, and R. Venkatesan. Enabling secure and resource-efficient blockchain networks with VOLT. Technical Report MSR-TR-2017-38, Microsoft Research, 2017.

[33] A. Singh, T. Das, P. Maniatis, P. Druschel, and T. Roscoe. BFT protocols under fire. In Symposium on Networked Systems Design & Implementation (NSDI), pages 189–204, 2008.

[34] J. Sousa, A. Bessani, And M. Vukolic. A Byzantine Fault – ´ Tolerant ordering Service for the Hyperledger Fabric Blockchain Platform. Technical The Report arXiv: 1709.06921, CoRR, 2017.

[35] B. Vandiver, H. Balakrishnan, B. Liskov, and S. Madden. Tolerating Byzantine faults in transaction processing systems using commit barrier scheduling. In ACM Symposium on Operating Systems Principles (SOSP), Pages 59 — 72, 2007.

[36] M. Vukolic. The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication. In International Workshop on Open Problems In Network Security (iNetSec), Pages 112-125, 2015.

[37] J. Yin, J. Martin, A. Venkataramani, L. Alvisi, and M. Dahlin. Separating agreement from execution for Byzantine fault tolerant services. In ACM Symposium on Operating Systems Principles (SOSP), Pages 253 — 267, 2003.

Translated from: arxiv.org/pdf/1801.10… Copyright belongs to the author, please contact the author for commercial use