Hyperledger Fabric. Components. Hyperledger Fabric is known as a permissioned blockchain where users need prior approval and be authenticated before using the network, opposed to permissionless blockchains [13]. Also, the platform is an open-source modular blockchain framework that allows for pluggable modular components ranging from consensus algorithms to cryptographic libraries. The program Docker is used to run each component in its own container environment. The most important components forming the foundation are: • Channel: Partition of the Hyperledger Fabric network where only joined Peers can interact. Data shared through the channel is ensured to be isolated and confidential. • Ledger: Series of blocks on which transaction details are recorded. Each channel has one ledger where all joined Peers keep a copy of the ledger. • Client: Application using the Hyperledger Fabric SDK that acts on behalf of the user by invoking a transaction to the Hyperledger Fabric network.
Hyperledger Fabric. The previous descriptions in Section 2.4 highlighted an issue with most Blockchain designs, which is that its monolithic architecture leads to the sequence of protocol steps being formed organically, without carefully thinking through the consequences of the order of that sequence, and even leading to some wasted work. Hyperledger Fabric [20] was one of the first systems to think through this order, by propos- ing an execute-order-validate architecture, while also tackling the issues of sequential and deterministic executions. The design of Xxxxxx defines three possible roles for the Blockchain nodes: clients, who submit transaction proposals for execution and broadcast the accepted transactions for ordering; peers, who execute transaction proposals and validate transactions; and ordering nodes, who establish the total order for transactions. An application that runs on the Fabric Blockchain has two parts: the chaincode, which is a smart contract that implements the application logic and is triggered by other transactions; and the endorse- ment policy attached to the chaincode, defining which peers will receive the transaction and stating the criteria for the transaction to be valid, e.g., X peers must have the same result in the end. The processing of transactions works as follows. First, during execution, the client sends a proposal to the peers defined in the endorsement policy (also called endorsers). This transaction contains the ID of the client, the transaction payload (the operation, parameters, and ID of the chaincode), a nonce, and a transaction ID. This proposal is simulated (i.e., the chaincode operation is executed) in the endorsers’ local Blockchains and they store the set of values that were read and written. These sets are then sent to the client, cryptographically signed, forming a message called ”endorsement”. Once the client collects enough endorsements that satisfy the policy, they create the transaction and send it to the ordering nodes. Second, the ordering phase will define a total order on the received transactions by batching them into a block and atomically broadcasting the newly-formed block, establishing consensus using a de- terministic consensus protocol such as Raft [51]. The block is then sent to a new group of peers (the committer peers) for the validation phase. Third, in the validation phase, the peers verify if the endorsement set satisfies the endorsement policy; then, they verify each transaction sequentially, ensuri...
