Factors to Consider
Alternate Deployment Options
The Sample Solution is designed to deploy and run on a single VM. There are a few important things to consider in respect to the application performance, scalability, and availability.
Performance
Transactions performed on the Sample Solution network are regular HLF transactions that go through a flow of operations performed by the different nodes on the network (client, peer, and orderer). It is important to know that there are computational tasks (e.g., calculating hashcodes) that bring load to the CPU. Adding more CPU power may positively impact the computational tasks and increase the transaction throughput in case of heavy loads.
Scalability
The network can be scaled horizontally by adding additional peers that can process the requests of additional clients (e.g., reading transactional data). Multi-core CPUs can be used to increase the transaction throughput. Detailed sizing of the network is usually an ongoing process as DLT networks are expected to grow/shrink with the time (e.g., as new participants join the network or existing participants leave). For production grade networks, use multiple VMs to bring the network to a proper state to handle increasing transactional volumes. The Sample Solution doesn’t include a scalability concept outside of a single VM.
Availability
The availability of the network depends on the number of nodes and their distribution across different infrastructures (e. g., cloud providers and data centers). Usually, a product-grade HLF network may run on different data centers and cloud providers across the globe in case the participants are international. Regular backups of the peers/orderers and their CouchDB stores (in cases where CouchDB is used), can be performed to restore the peers in case of hardware failures. The Sample Solution doesn’t cover or automate any backup strategy.
Technology Alternatives
HLF is one of several blockchain-based DLT technologies available to build a private and permissioned network. There are also public blockchain networks that focus on tokenization and are entirely public, open, and un-permissioned. However, those public networks are slow to process transactions, provide no real privacy, and lack support of permissioned network models. The latter capabilities are essential for many enterprise-grade applications where privacy and permissioned control of data and transactions is a must.
Public blockchain networks are usually powered by many distributed and decentralized peers. Those peers can be run by anyone and are often commercially hosted in pools (farms) operated worldwide. Some of those networks are dedicated to the sole purpose of recording all transactions that move tokens between accounts/addresses (e.g., the Bitcoin network) on the ledger. Some support more complex transactions powered by smart contracts that allow the developers to record data on the public ledger. Those public networks are suitable for many use cases like asset modeling and trading through non-fungible tokens (NFTs). One of the most used and proven public networks that supports smart contracts is Ethereum.
Most permissioned and private DLT networks are built on several established blockchain technology implementations, like Corda, HLF, Quorum, Hyperledger Sawtooth, etc. They each have their own strengths and weaknesses and have specific use cases. There are also open-source projects supported by communities of individual developers and companies. HLF is one of the most used and popular implementations, as it is open and generic enough to handle and solve problems across industries like supply chain, healthcare, financing, etc.
Security
The provisioned HLF network is accessible through its nodes on different ports that may be exposed outside the VM using a proper security group. Peers and orderers are connected to each other through their internal Docker ports, where the communication channels are TLS encrypted. The network nodes’ PKI artifacts are stored on the local file system of the VM. For storing those artifacts outside the file system, you may wish to use an HSM or any other PKI management system (e.g., Vault).
The provided web applications use a sample user identity management system restricted to a single pre-defined user. The purpose of the solution is to focus on Hyperledger Fabric capabilities consumed by a client, where user management is usually integrated with an identity management system based on specific project needs.
Note: The integration with a PKI management system or web application identity management system is outside the scope of this BoosterPack Sample Solution.
Scaling
HLF networks are powered by ordering service nodes and peer nodes. The network allows the participants to add any number of peers to the network so that high availability and horizontal scalability can be achieved. Peers can be hosted on different cloud providers or regions, so that hybrid cloud deployment and a high level of distribution can be achieved. The ordering service of HLF can also distribute the nodes (orderers) across different infrastructures, where every channel must maintain a manageable number of orderers to maintain a stable RAFT cluster (the RAFT consensus protocol is used in many other projects like Kubernetes). The network nodes are hosted and managed by the participants so that every one of them is responsible to host their peers on an infrastructure that allows a high level of horizontal or vertical scalability.
Availability
HLF nodes can be hosted on different cloud providers or regions. Higher node distribution usually means higher overall network availability. Therefore, each network participant may operate multiple nodes to reduce the risk of downtime for a particular class of transactions. For example, some transactions may require endorsements from a subset of the participants, so that faulty or inaccessible peers do not affect them.
This BoosterPack provides a solution to host the network nodes on a single VM. This is a good option for developing and building proof-of-concept applications. For production-grade networks and applications, it is expected and highly recommended to host the nodes on a variety of infrastructures in different regions, on the same or on multiple cloud providers.
API
Hyperledger Fabric nodes (orderers and peers) and Hyperledger Certificate Authorities provide APIs for management and operations (e.g., health checks, log level management, chaincode deployment/invocation, node-to-node communication, identity registration, and enrolment, etc.). The APIs are Web APIs based on gRPC. In most cases, it is highly recommended to secure the APIs using TLS. The following links provide technical instructions for enabling TLS on different nodes:
Note: In a highly secured and permissioned environment, a mutual TLS protocol can be used to further strengthen the security of communication protocols level by level, enabling only clients with trusted certificates to pass the mutual TLS server check.
Cost
The cost of operating an HLF network depends on the infrastructure chosen to accommodate various non-functional requirements on the network, like availability, performance, security, etc.
Production-grade networks may require several nodes in different geographical locations (or datacenters) to achieve high availability. Hardware Security Modules (HSM) may be used to store Private Key Infrastructure (PKI) artifacts like certificates and private keys.
For the Senofi Hyperledger Fabric network, we are using a single VM with few peers and orderers. The network artifacts are stored on the VM local file system. For reference, AWS and Azure charge $45/month for the 2 core 4GB instance which is the minimum resource required to run this Sample Solution.
A specific calculation of the required services and infrastructure will define the exact cost.
Any production network may change in the future due to added/removed nodes and participants. Ongoing network operational costs may increase or decrease accordingly.
License
All components of the Senofi Hyperledger Fabric Solution are subject to open-source licensing. You may consult the solution’s source code repositories to learn more about licensing terms.
