Hyperledger Fabric : Technical Overview [Part I]

I am a 🇵🇹 PhD researcher @ Técnico Lisboa, where I teach User Centered Design. I am a mentor at the Hyperledger Fabric Based Access Control project, supported and funded by Hyperledger and the Linux Foundation 🔥. Thanks very much for reading. You Rock 💪.

If you like blockchain and open source, be sure to support my work on 🚀 🙏

Fabric allows for different kinds of participants in the network, which facilitates the execute-order-validate paradigm for distributed execution of chaincode.

The authors defend that execute-order-validate has advantages in relation to the usual order-execute paradigm seen in blockchains like Bitcoin and Ethereum.

Endorsement peers (endorsers) execute (endorse) the smart contracts (chaincode) and return blockchain clients the validation output of submitted transactions, which contain the endorsement peers’ signatures. This process allows parallel execution and addresses non-deterministic code.

Chaincode is the central element in a Fabric network, as it dictates the rules to be followed by member participants. It is run in Docker containers, and is, thereby, isolated from the shared ledger. There are two types of chaincode: application chaincode, that executes the application logic and communicates with the peers using gRPC messages and system chaincode, ran on the configuration channel and used to store the configurations of the ecosystem, such as the definition of MSPs, the network address of OSNs, configuration about the consensus, ordering service parameters, and rules on how the channel configuration can be altered. Source: Chaincode can be deployed dynamically, and it usually is running concurrently on the network. It runs directly on the peers’ processes. The configuration channel stores the definition of MSPs, the network address of OSNs, configuration about the consensus, ordering service parameters, and rules on how the channel configuration is tweakable.

Chaincode executes transaction proposals against world state data, as the world state provides direct access to the latest value of these keys. Given this, there is no need to traverse the entire transaction log and calculate its values.

Ultimately, chaincode’s goal is to modify the shared ledger. Each peer contains a ledger component, formed by the block store, which stores blocks containing transactions and the peer transaction manager (PTM). There is a different ledger for each channel, as channels enforce chaincode and data isolation.

Channels allow participants to establish a communication path between the subset of participants that have permissions to visualize a subset of transactions.

For instance, in the same network, there can be a subset of peers that have access to only a certain kind of transactions. In addition to channels, Fabric supports private data, which allows a defined subset of organizations on a channel to isolate their data from others. In specific, organizations with permissions can endorse, commit, or query private data, which is logically separated from channel ledger data. In case of a dispute, private data can be shared. For further privacy, hashes of private data go through the orderer, instead of the data itself. It is disseminated peer-to-peer rather than via blocks. When transaction data must be kept confidential from ordering service nodes, it is a solution to use private data collections, rather than channels.Source:

Fabric introduces a hybrid replication model, combining active and passive replication (primarybackup-replication, ported to the untrusted environment).

Concerning active replication or state machine replication, the ledger state only reflects the transactions after these are validated and
the consensus is reached, concerning their ordering. Passive replication happens as endorsers send the result of the transaction processing to commit nodes.

Fabric comprises three main elements around data: world state, a versioned key-value store which corresponds to the distributed ledger; the transaction log, stores the history of all transactions (PTM); and a NoSQL database, such as CouchDB, stores the world state. It is possible to restrict users’ access to view and edit specific fields and only authorising the read-only permissions. CouchDB supports complex data queries, comparatively to LevelDB, against the whole blockchain data, making it a suitable solution when it comes to data analysis and auditing. LevelDB is the other built-in option for storing the world state.

It is a simple, fast key-value storage library that provides an ordered mapping from string keys to string values.

Although Fabric does not have a built-in cryptocurrency, it is possible to create an underlying token with chaincode, which can represent assets or rights to perform specific actions.

Such assets can be exchanged between network participants, through transactions.

Participants can hold one or more peer nodes on the network. Fabric defines on its model several kinds of peer nodes:

1. Committing peer. Each peer maintains the current snapshot of the current state of the ledger, as a store of key-value. Such peers cannot invoke chaincode functions.
2. Endorser peer. Endorser peers have chaincode installed. When they receive a transaction proposal, they simulate the transaction execution on isolated containers. Based on that simulation, such peers prepare a transaction proposal that is then sent to the orderer peer. The existence of endorser peers avoids sequential execution of transactions by all peers.
3. Orderer peer. Orderers receive endorsed transactions and assemble them into blocks. After grouping transactions, orderers assure consensus, by propagating such blocks to committing peers, where they are validated and then committed to the shared ledger. Orderer
   peers record valid and invalid transactions, while other peers only contain valid transactions.

Types of peers. Source:

Additionally, Fabric defines anchor peers and leader peers.

Anchor peers serve as an intermediary between peers from its organisation and peers from an external one.

Leader peers take the responsibility of distributing the transactions from the orderer to committing peers.

Architecture of a Fabric's solution.

To achieve consensus, and given that there is an assumption of partial trust in a Hyperledger Fabric network, Fabric uses a permissioned voting-based scheme, which achieves low-latency.

The endorsement policy defines the voting-based scheme to be used by peers and, consequently, the weight of each peer regarding the validity of a transaction.

The transaction flow, which follows the execute-order-validate paradigm, is as it follows:

1. Transaction proposal. A blockchain client, which represents an organisation, creates a transaction proposal, and sends it to endorsement peers, as defined in the endorsement policy. The proposal contains information regarding the identity of the proposer, the transaction payload, a nonce, and a transaction identifier.
2. Execute (endorsement): the endorsement consists in the simulation of the transaction. The endorsers produce a write-set, containing the keys and their modified values, and a read-set. The endorsement peers also check the correctness of transaction execution. The endorsement is sent as the proposal response and contains the write-set, read-set, the transaction ID, endorser’s ID, and the endorser’s signature. When the client collects enough endorsements (which need to have the same execution result), it creates the transaction and sends it to the ordering service. The endorsement phase eliminates any eventual non-determinism.
3. Order : after the endorsement, there is the ordering phase, performed by orderers. The ordering service checks if the blockchain client that submitted the transaction proposal has appropriate permissions (broadcast and receiving permissions), on a given channel. Ordering produces blocks containing endorsed transactions, in an ordered sequence, per channel. The ordering allows the network to achieve consensus. The orderer broadcasts transaction’s outputs to all the peers.
4. Validate. Firstly, each peer validates the received transactions by checking if a transaction follows the correspondent endorsement policy. After that, a read-write conflict check is run against all transactions in the block, sequentially. For each transaction, it compares the versions of the keys in the read-set with those currently on the ledger. It checks if the values are the same. In case they do not match, the peers discard the transaction. Finally, the ledger is updated, in which the ledger appends the created block to its head. The ledger appends the results of the validity checks, including the invalid transactions.

Execute-order-validate summary. Source:

In a next article, the membership service provider, the ordering service and the peer gossip will be analysed and discussed.

Thanks very much for reading. You Rock 💪.

If you like blockchain and open source, be sure to support my work on 🚀 🙏

References:

• Elli Androulaki, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, and Et al. Hyperledger Fabric: A Distributed Operating System for Permissioned
  Blockchains. Proceedings of the Thirteenth EuroSys Conference, 2018
• Hyperledger Foundation. Hyperledger Fabric Documentation, 2018. URL //hyperledger-fabric.readthedocs.io/en/release-1.4. Accessed on 2018-11-12
• Marko Vukolic. Rethinking Permissioned Blockchains. In Proceedings of the ACM Workshop on Blockchain, Cryptocurrencies and Contracts, pages 3–7, 2017