Hyperledger Project Technologies

The Hyperledger Project is a collaborative effort hosted by The Linux Foundation that aims to develop and support open-source enterprise DLTs [36]. Currently it hosts over 10 projects which include frameworks and tools for the design, development, deployment, and testing of DLNs and distributed applications. The next sub-sections described the Hyperledger Project framework and tools utilized for this experimental network.

3.6.1.1 Hyperledger Fabric

HLF (v1.2) was chosen primarily because its modularity allows developers and ar- chitects to tailor its different layers, such as methods for validation, consensus, and the distributed-ledger data structure, to meet an organization’s needs [35]. Furthermore, HLF allows the creation of a consortium-based network of peers where organizations can manage their own users’ permissions.

Key terminology related to HLF is defined below:

• Consensus: HLF supports pluggable consensus and it can support different types per channel. Consensus in HLF takes place among the Ordering Service Nodes (OSNs), commonly referred to as orderers, and is performed by selecting a leader among them with a fully synchronized ledger to order the transactions, place them in a block, and deliver them to other peer nodes for validation and committal. The framework deployed in this research uses Apache Kafka and Apache Zookeeper for consensus since it is the only consensus module consid- ered ready for production environments. The Zookeeper-Kafka consensus at its core enforces the ordering of transactions in a block. Blocks are created when a predetermined number of transactions are received or when a timer since re- ceiving the first transaction for a block has expired (block timeout). Once one

of these two actions happen (whichever one happens first), a block is delivered to the peer nodes [37].

• Channel: A channel in HLF is a private blockchain where only the specific channel participants have access to and can interact with it [38]. Participation is managed via authentication and Access Control Rules (ACRs).

• Chaincode: Also known as smart-contracts, chaincode is the code/service in- voked by an application interacting with the HLF network that manages access and modifications to the ledger. It is installed on peer nodes to work on one or more available channels [38].

• Endorsement: In HLF, endorsement refers to peer nodes simulating the exe- cution of a chaincode transaction and communicating the response back to the originator, along with their signature to provide proof of valid execution result [38]. Endorsement policies define a transaction endorsement requirement in the form of Boolean expressions over participating organizations [37].

• Membership Services Provider (MSP): The MSP provides cryptographic (PKI-based) credentials to the HLF participants for authentication and trans- action processing [38].

• Peer Node: A network node that executes the chaincode and maintains a copy of the ledger. Peers can be identified as endorsers in order to participate in the endorsement of a transaction and can also be identified as anchors which allow them to be discovered by and communicate with all other peers.

• Orderer Node: OSNs or Orderers are nodes that participate in the consensus phase. They receive transactions from other peers, create blocks and broadcast them to all other endorsing and committing peers [37, 38].

• Access Control Rules: ACRs can be deployed to control which participants have access to which assets and the conditions under which that access is granted or denied. This allows certain entities to perform actions on assets they own, or update the state of an asset given a set of rules. Although a feature available through Hyperledger Composer, the modeled network does not employ the use of ACRs, all vehicles and RSUs are assumed to have the add/update rights to the events they are involved in.

HLF networks follow the execute-order-validate-commit model for transactions shown in Figure 9. Transactions are received in the execute phase where they are passed through chaincode, if needed, while at the same time the receiving peer sends a request for endorsement. Requests for endorsement are sent only if such requirement has been set when instantiating chaincode. In order for the transaction to be valid, the endorsement execution at a different peer node must yield the same output as the same execution at the originating node. Once the transaction has received all endorsements, it is sent to an orderer for consensus, entering the ordering phase. At this stage the transactions are ordered by their timestamps and await inclusion in a block. A block is created whenever the first of the following two conditions is met: the block is filled with the maximum number of transactions allowed or a block timer expires, i.e., block timeout. Once the block is cut, it is broadcast to other nodes for validation. During the validation phase, peer nodes ensure that the received transaction has valid endorsement signatures and meets the pre-defined endorsement policy requirement through a process known as validation system chaincode (VSCC). Another type of validation that takes place during this stage is multi-version concurrency control (MVCC) [39] validation, which checks if the state of the object being modified by a transaction in a block has not changed since the transaction was executed and tags it valid or invalid. Once validation has completed, the transaction is committed to the

ledger and the state database is updated to reflect the creation or modification of the data asset in question. Finally, any events specified in the blocked and committed transactions are then emitted.

Figure 9. Hyperledger Fabric Transaction Workflow

3.6.1.2 Hyperledger Composer

Hyperledger Composer (HLC) (v0.20.3) is a toolset and framework aimed at facili- tating the development and execution of blockchain networks and services [40]. It was utilized to model and deploy the ITS chaincode and network services of this setup. It includes a “Composer-Playground” tool to view and interact with world-state data and perform upgrades to the services. Composer has the capability to stand up a REST server that interfaces with the HLF network to provide a web API.

3.6.1.3 Hyperledger Explorer

The Hyperledger Explorer (v3.5) project provides a web application to interact and query underlying data from the blockchain that is not available through the HLC generated services [41]. Block information such as hashes, timestamps, and transactions are made available via its services layer which can be used for computing performance data such as network throughput in Transactions Per Second (TPS).