This project is written in JavaScript and Shell, uses Node.js, Express.js, and the Hyperledger Fabric SDK for Node.js, and serves as the backend for an application that generates transaction conflict graphs (also called precedence graphs or serializability graphs) from transactions of the Hyperledger Fabric blockchain.
If the Hyperledger Fabric blockchain is running on a remote cluster, this project should be installed there.
You may want to use ssh -i ~/.ssh/id_rsa -L 3007:localhost:3007 <remote username>@<remote IP address> to connect to the remote machine via SSH and run the app there.
To see a visualization of the generated graphs, this app should be run together with the corresponding frontend.
The app provides an endpoint (http://localhost:3007/graphGeneration?startblock=&endblock=), which receives startblock and endblock query parameters, and executes the following steps successively:
- Extraction of transactions data within the specified block range from the Hyperledger Fabric blockchain
- Transaction conflict graph generation (edges, nodes, and specific attributes (such as types of failure))
- Serializability check
All the code related to the extraction of the transaction data from the Hyperledger Fabric blockchain can be found in the blockchain_data folder.
The logExtractionLab.sh script, which executes getBlockchainLogsLab.js on a Fabric network node, is called to retrieve the data from a HyperledgerLab network.
The default method uses getBlockchainLogsNoClient.js for transaction data extraction.
If the transaction data should be retrieved using a client defined in the common connection profile, getBlockchainLogsClient.js is called.
In any case, the collected parsed transactions are written to the file system for further processing.
To create the transaction conflict graph, a combined read/write-set, which contains the operations of a transaction and their accessed keys, is created for each transaction. To determine the edges of the graph, the following two checks are done:
-
If the entry in the set is a write operation, the algorithm searches for prior read transactions on the keys.
-
If the entry is a failed read operation, the reason for the failure, which is a prior write transaction on the same key, is detected.
Additionally, attributes of the transaction conflict graph, such as the number of dependencies, inter- and intra-block conflicts, or the type of failures, are gathered.
All cycles of the graph are detected using Johnson's algorithm. If there are no cycles, the set of transactions is serializable. Otherwise, the transactions involved in the most cycles are iteratively removed (and added to the array of transactions that would need to be aborted to ensure serializability) until there are no cycles left. This task may require significant memory resources, therefore 8GB of RAM is required.
If you do not have a Fabric network running already, you might want to use the benchmarking framework Hyperledger Caliper and the Hyperledger Fabric test network. A tutorial on how to setup the Fabric test network and Hyperledger Caliper is provided here. The network has to contain certificate authorities to be able to register and enroll new users.
Modify the config.yaml file
The config.yaml file should be edited by the user before using the application. The variables need to be adapted based on the Hyperledger Fabric network under test.
If the application is used to generate graphs from a network deployed using HyperledgerLab, the variable HyperledgerLab should be set to true. Make sure the connection profile matches the HyperledgerLab network.
Otherwise, the path to the common connection profile of the network, which may be a .json or .yaml file, needs to be specified (ccp_path variable). Depending on whether a client and its crypto store are defined in the common connection profile (client_and_cryptoStore variable), different methods to retrieve the transaction data are used. By default, a connection is established without using a predefined client, hence the channel and certificateAuthority variables need to be provided.
If you start the backend for the first time, run the following command (may take several minutes):
To run the application, execute the following command in the project directory:
Runs the app in the development mode.
Open http://localhost:3007 to access the backend endpoints it via the browser.
Keep in mind that the frontend should be run simultaneously. If it is, http://localhost:3006 can be visited to view the user interface and interact with the application.
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
The app is ready to be deployed!