Corda vs Hyperledger Fabric: Comparing Distributed Ledger Frameworks

Corda vs Hyperledger Fabric: the comparison

Both frameworks are private and permissioned blockchains that enable strict access control for accessing the data – an essential feature for most enterprise applications. In general, they can process many more transaction per second than public blockchains.

1. Identity

The authentication/authorisation for both frameworks is based on a public key infrastructure (PKI) model and X.509 certificates. PKI infrastructure is the technology for user authentication via a digital identity that relies on public key cryptography. A user’s digital identity is created by a trusted party called a certificate authority (CA). The CA uses its key to create an X.509 certificate – a document that maps the user’s public key to their identity.

• Fabric. Each organisation in the network has its own certificate authority and can fully control the issuing and revocation of identity certificates. Moreover, they can add custom attributes to the X.509 certificates to get more fine-grained authorisation policies at the smart contract level. Fabric uses the concept of the membership service provider (MSP). MSP verifies whether a specific identity certificate has permission to operate on the network and links the user’s identity to a role, such as administrator, client or peer (transaction endorser). The user does not need to host the node to query or modify the data; only valid certificates and keys are required. Application clients can own their private keys and sign the transaction from the mobile app, browser or desktop without revealing their key to the third party.
• Corda. A node certificate is obtained through the network identity service. Before any node or organisation joins the network, a join request needs to be submitted. The identity service is responsible for conducting know your customer (KYC) verification. An organisation can join the network only after the request is approved by the identity service. The identity service acts as the root certificate authority for the network. Initially, Corda was designed for financial institutions (for instance, bank-to-bank interaction), so the idea was that each participant should have a node deployed.However, this is not always viable. In B2C scenarios, a user might need to have a separate account for each client, and it is challenging to have a separate running node for each one. Account SDK was added to allow having many users on a single node and make the framework more generalised. This approach has certain limitations, as users' private keys are stored on a node. It makes the framework inapplicable in situations when a user should have full control of their credentials.

Fabric is more flexible than Corda regarding identity management. It enables users to own their identity keys without the necessity to host a blockchain node. Owning the keys might be usable in some cases when the user needs to have full control of their data, like digital identity or electronic health records. In contrast, Corda keys are always stored on the blockchain node.

In Fabric, the user’s identity is bound to the certificate. It enables the creation of fine-grained access rules in the chaincode via certificate attributes. Each certificate can have a role or any custom attributes assigned. In Corda accounts, access rules should be implemented in the application layer. Accounts are just public keys, so you have no option to customise access rules in the smart contract.

2. Consensus

A blockchain consensus protocol is a set of rules for determining how to reach an agreement on global state changes in a distributed blockchain network. One of the fundamental flaws it is designed to solve is double-spending. Double-spending is sending digital asset more than once, like sending the same money twice to different parties.

There are different protocols used to reach consensus. Let's focus on just two protocols that are implemented or planned in Corda and Fabric frameworks.

Crash fault tolerance (CFT) – this protocol increases system resiliency in case some participants are unavailable. It is usually a cluster of parties that are able to operate if some of the parties could not be reached. Usually, CFT implementation is based on top of the RAFT protocol.

Byzantine fault tolerance (BFT) – this protocol operates in untrusted environments with malicious actors present in the system. It requires a cluster of mutually untrusted parties to agree on the state. BFT is slower than the CFT protocol.

• Fabric. There is a unique flow for reaching consensus based on Fabric’s transaction architecture: Execute-Order-Validate. The execute and validate phases are performed by a peer component; each organisation in the network has it is own peer. The orderer component performs the order phase. During the execute phase, an organisation’s peer executes smart contracts, determines changes and sets and endorses the change correctness. Order phase packages order transactions into a block and deliver them to the organisation nodes for validation. The validation phase verifies that all required endorsers approved the transaction and that the changeset was not already modified by previous transactions to prevent double-spending.The only place that CFT or BFT protocols can be applied is the order phase. In case a malicious actor gets control under the orderer component, they might skip specific transactions from processing, selectively deliver blocks to organisations or even send different blocks to different organisations to break the global state. A BFT protocol could resolve these vulnerabilities. Even without BFT in place, it is still impossible to perform a double-spending attack. At the moment, only the CFT protocol is production-ready. BFT remains under development.
• Corda. There is no global state, and data is shared between counterparties. Each transacting party gets the state history and verifies its validity. A further component is a notary that verifies whether another transaction has already consumed a specific state to detect double-spending. It is worth emphasising that a notary is the only component used for double-spending verification. A notary can be validating and non-validating.A validating notary verifies both the correctness of the transaction history and double-spending. A non-validating notary only verifies double-spending. A validating notary compromises security by getting access to the data. A non-validating notary does not have access to the data, but is vulnerable to a denial-of-state attack – a malicious user could pretend to modify another node state, resulting in a double-spend validation error. Currently, there is no production-ready implementation either for CFT or BFT, although Corda Enterprise has a high availability setup mode to resolve resiliency issues, as CFT does.

Both frameworks do not have a production-ready implementation of the BFT protocol. The absence of the BFT implementation in Corda brings much higher security risks than it does in Fabric due to the possibility of a malicious user gaining control of the notary component and executing a double-spend attack.

3. Privacy

Privacy is a crucial aspect of enterprise applications. It is essential to know who conducted a modification and when, and to be certain that only authorised users and organisations can see the data.

• Fabric. There are two concepts for data segregation: channels and private data collections (PDCs). Channels are a private network available only to invited members, so no one else can access the data inside. A node can be joined to many channels at the same time. PDCs allow the sharing of information only to specific members or organisations within one channel; access to the data can be granted statically during smart contract installation or dynamically during execution. Private data collections never reveal the original data to the orderer component for block creation. The data is replicated directly between participating peers. Everyone else can see only the data hash. It provides proof of the existence of the data, but they can never know what the data is.In Fabric, the Identity Mixer implementation enables anonymous identities. It provides unlinkability and selective attribute disclosure by generating zero-knowledge proofs (ZKPs). Unfortunately, it is no longer in active development. For now, only the Java SDK is supported on the client side, and only the Go SDK is supported for chaincode. Identity revocation is not supported, and you cannot disclose custom attributes, only the role and the organisation unit name. It strongly limits situations in which this feature could be used. For example, anonymous identities could not be used to sign transactions in the browser. Private data collection combined with Identity Mixer hides both identity and asset details.
• Corda. This framework stands apart from most blockchain solutions as it doesn’t have a global state. Data is shared and verified from node to node on a need-to-know basis. Data might be visible to the notary component if it is a validating notary. Future asset owners need to validate the full transaction history from the point at which the asset was issued so they can see all transactions history data. There are techniques to ensure identity privacy, like state reissuing (to delete asset transfer history), transaction tear-off (to hide some parts of a transaction) and anonymous identities. Nevertheless, it is still essential to carefully consider who might have access to the data.Anonymous identities (or, in Corda, confidential identities) allow users to explicitly provide identity details only to the transaction counterparties, hiding identity details on history verification. Keys for anonymous identities are generated per transaction, so they cannot be traced. The Corda Accounts SDK is also based on anonymous identities. Accounts details need to be explicitly shared between counterparties. Corda’s confidential identities preserve the privacy of the user’s identity, but not the asset’s details (e.g. the amount of money or the real estate address). There is an ongoing investigation of zero-knowledge proofs (ZKPs) and/or trusted execution environments (TEEs) that allow verification of a transaction without revealing the content, though it is still a distance away from being production-ready.

Corda transactions are private by default. Confidential credentials make it possible to hide identities from future asset owners. Fabric allows users to explicitly configure privacy via channels or private data collections. It adds more complexity to the network management, especially when there are a lot of participants, but offers fine-grained control over who can access the data. Which approach is better depends on the particular use case.

4. Network governance

Governance is the system of rules and practices that control the network and it is participants. There is usually a network administrator with the right to add new members. Each organisation has an administrator to manage node infrastructure and participation in a particular smart contract process.

• Fabric. The Fabric network is managed by multiple organisations. There are orderer organisations and a consortium of application organisations. Application organisations can create different application channels with different sets of participants. In the early days of Fabric, orderer organisations were in control of who could join the consortium, and all of the application channels were connected to the single orderer organisations’ group. With Fabric 2.3, it is now possible to create an application channel and selectively join individual orderers’ organisations. It allows scaling horizontally, as each orderer can be added to a different channel.Each channel is managed by policies that determine whether all organisations, the majority of organisations or only selected organisations can approve changes (e.g. add new participants to the channel). Each organisation is responsible for provisioning its administrators. Channel administrators are responsible for managing smart contract installation flow. Before a smart contract can be installed or updated, it needs to be approved by the required number of an organisation’s administrators.
• Corda. A network administrator is responsible for onboarding new organisations and the configuration of network parameters. Organisation administrators manage the node configuration and participate in smart contracts, flow installation, and update processes (in explicit mode). There is an option to create a segregated network within the Corda network. This makes it possible to have a custom notary, hide participants and control subnet configuration, preserving the possibility of joining global networks in the future.Corda allows the creation of a business network – a logical subnet within the Corda network. Business network administrators can approve new members, assign member roles or delete members. Global network participants do not know about business network participants. It is possible to create a flow that allows only business network participants to communicate with each other.

Corda governance is more centralised, as a single organisation controls the nodes, onboarding and network configuration. In Corda, a node can participate in only one network. By default, users can communicate with every node in the network as soon as they have a smart contract installed. They can explicitly forbid another node to interact with their node, or have more fine-grained access via the Corda business network.

Fabric’s governance structure makes it possible to create and define channels, where participants together control the network configuration and smart contract management. Both frameworks can review and approve new smart contract versions before upgrading.

5. Development

It is important to consider how easy it is to find new developers for the product and how long it might take for newcomers to be able to work at full capacity.

• Fabric. There is a new architecture for transaction execution – Execute-Order-Validate, which eliminates non-determinism in the transaction. As a result, any standard programming language can be used for smart contract development. Presently, Go, Java and Node.js are supported. There are also SDK libraries written in Go, Java, Node.js and Python. Although it sounds beneficial to use so many different languages, it can be difficult to find a developer who knows both Fabric and one of the supported languages at the same time.In general, working with Fabric’s smart contracts is reminiscent of API service development, where users validate input parameters, format the data, and do read/writes to the storage. Authorisation and endorsement policies can be defined declaratively during chaincode installation or at the code level.
• Corda. The transaction architecture requires code execution to be deterministic. A modified Java VM is used to achieve determinism. The main programming languages in Corda are Kotlin and Java. Unlike other blockchain implementations, a smart contract in Corda consists of three blocks: state, contract function and flow. The state is the data of the smart contract. The contract function verifies whether state changes are valid. The flow is responsible for initiating communication between parties, creating the input/output state, verifying state change validity and gathering all required signatures from counterparties. There are different built-in flows to validate a transaction, collect required signatures and notarise the transaction. It can be time-consuming to understand all Corda SDK libraries.

The learning curve is relatively similar for both frameworks. However, it is strongly recommended that an experienced developer drives blockchain development, as it is very easy to head in the wrong direction.

6. Deployment

Due to the distributed nature of the blockchain, deployment of a new private network is not a trivial task. Blockchain deployment frameworks are far from perfect and often users end up crafting their own solutions.

• Fabric. There are many interacting components – provided as docker containers – and it is up to the users to make a working solution from these parts. In 2021, there are still companies doing their production deployment via fabric samples scripts. Those scripts are great for learning, but they do not meet the highly available and reliable solution criteria. There are lots of different deployment frameworks that have been crafted to make life easier, driven either by Hyperledger or an open-source community. However, they are still far from ideal, so it is likely that a good DevOps engineer will be required to support network deployment. The IBM blockchain platform is currently the most mature deployment platform.
• Corda. There are two main options: join the existing public Corda network or create a private network. The Corda network is a publicly available network of Corda nodes, and the goal is to create one global network for everyone. As Corda has no global state and data is shared on a need-to-know basis, adding more nodes does not affect the overall performance of the network. However, the node needs to be exposed to the public internet, which might be difficult to achieve for some highly regulated enterprises.There is the option to create your own network. Corda Enterprise has a Network Manage tool to enable this. Alternatively, there is a free network map service/doorman implementation that is provided by the Cordite community, with a more limited feature set – no HSM support, no flows for approving new user requests, etc.

Deploying and managing the network on both Fabric and Corda is not an easy task. With Corda, there is the great option of joining the Corda network, where you will need to deploy only your node. Fabric does not have a global network and usually requires new network deployment for each use case.

In the future, if most companies have Fabric infrastructure in place, it will be easier. If users need to deploy a private network for Corda, deployment efforts will be similar for both Fabric and Corda. One more point worth mentioning is that using Fabric involves much more certificate management. In Fabric, every network participant, including clients and network components, has their own certificate. This requires careful designing of the certificate expiry and revocation flows for both end-users and application components. In Corda, you only need to take care of the node identity and the TLS certificate.

7. Tokenization

Tokenization is a process that converts assets (real estate, stocks, fiat money) into a digital representation. It allows for easy creation of new markets for any possible type of asset. It is mostly used in financial institutions, real estate, digital currency, etc.

There are two types of token: fungible (stocks, options, digital currency) and non-fungible (real estate property, artwork, diamonds, land rights). Fungible tokens as digital currency representation are usually intensively exchanged, and the performance of this solution should be carefully considered.

And, there are two popular approaches to managing digital token states – account and unspent transaction output (UTXO).

The account model is used in Ethereum. It looks similar to a network of bank accounts, where each user has an account and money transfer is the process of subtracting an amount from one account and moving it to another account. It is a relatively simple solution, although it has performance penalties for actively used accounts, as you can only update information for one account at a time.

The UTXO model is used in Bitcoin. It looks like paper money in your wallet. If a user wants to give someone $50, they need to get the required bills from their wallet and give them to the other person. If a user only has a $100 banknote, the transaction will exchange it for two $50 bills, give one to the other person and give the user the other as change. In general, the UTXO model can provide higher throughput, as it is possible to select different banknotes for different transactions in parallel. However, the UTXO model is more difficult to develop.

• Fabric. The Fabric framework currently lacks a token library. There were plans to add the alpha release of FabToken, but it was postponed. For now, it is possible to implement a custom token either using the account model or the ERC20 standard. It is important to be aware of the performance limitations: what works well in Ethereum, with its roughly 15 transactions per second, might not work well with Fabric with its hundreds of transactions per second. The UTXO model could be implemented in Fabric, although this would not be a trivial task.
• Corda. As it was initially designed for financial institutions, Corda already has a Token SDK for fungible and non-fungible tokens. The Corda state is based on the UTXO model. It provides libraries to collect the required number of tokens, and token collection could be done in parallel to multiply different transactions at the same time.

Corda has a built-in Token SDK designed to efficiently manage both fungible and non-fungible tokens. The Corda state model is based on UTXO, allowing the processing of token transactions in parallel. For example, an e-commerce store could receive a high number of transactions per second, with each transaction updating its balance. The Corda UTXO model will handle this case more efficiently than the account state model. Fabric does not currently have a built-in token SDK. The only option is for users to create their own.

8. Ledger storage

Blockchain is a distributed ledger, where ledger is the history of records about asset modifications. Users can append asset changes to the ledger state, but cannot alter the existing state. The underlying ledger storage affects application design and performance.

• Fabric. The Fabric ledger consists of two components: blockchain and world state. Blockchain is a transaction log that records all the historical changes made to an asset and is implemented as a file. World state contains the current state of the asset and is implemented as a database. There are two options for world state storage: LevelDb and CouchDb; both are no-SQL databases. CouchDB provides more advanced query capabilities. Although there is a limitation that prevents efficient queries, a nested objects schema should not be used as this increases write concurrency errors. As it is no-SQL, there are very limited options for joining different documents types. Therefore, it is better to design a data schema to be more write-oriented and, for complex queries, utilise off-chain storage. In this way, it’s possible to transform and move the data to the off-chain storage in a format that is more suitable for complex queries.
• Corda. Ledger data is not shared globally. Each node contains only data relevant to the node’s owner. Data is stored in the relational database. Community Corda has the support of H2 and Postgres. Corda Enterprise supports even more databases: Azure SQL, SQL Server, Oracle and PostgreSQL. It means that it’s possible to store ledger data in an existing database and use all the capabilities of relational databases to query and join the data from both the ledger and the application.

Corda allows you to work with relational databases. It gives clear benefits in designing complex queries and even combining ledger data with application data. Fabric supports only no-SQL databases and there are limited options to design its structure in an efficient way for both reads and writes in a way that avoids concurrency conflicts. With a complex asset schema, it is better to design Fabric storage for write-only requests and use an off-chain database for querying.

9. Attachments

There are certain cases when you need to enhance a smart contract with file attachments, such as a legal agreement attached to the contract to facilitate dispute resolution, an invoice pdf or contract code sources.

• Fabric. Although you can potentially store files inside the Fabric ledger, it is strictly discouraged, as it drastically affects the performance of the application. It is recommended that only the file hashes are kept in the ledger. If a smart contract-related attachment needs to be stored, it will be necessary to implement custom offline storage.
• Corda. Attachments are supported as part of the transaction flow. A file can be uploaded and attached to any smart contract. Moreover, it’s possible to verify attachment content during transaction execution. With Corda, there are some limitations imposed on the file sizes, so it might not be a good option for large videos or clinical photos.

Corda has built-in attachment support, meaning it’s possible to implement document management flows or attach invoices to the smart contract. This will save the time involved in implementing external file storage. Fabric does not have built-in attachment support.

10. Oracle service

A blockchain oracle is an external service that provides smart contracts with off-chain data. Smart contracts by design should be deterministic, and they should not access an external service directly as the data could change very frequently, preventing participants from reaching consensus. An oracle creates a proxy between smart contracts and external data. External information can be anything like currency exchange rates, sport event results or a hotel booking availability calendar.

• Fabric. There is no implementation of an oracle service in Fabric. However, Fabric is flexible enough to enable oracle implementation. You can have a separate oracle organisation, with its own smart contact, acting as an oracle service. Only the oracle organisation can write the data, and everyone else can read it. In that way, an oracle smart contract can be called from within a client’s smart contract. An oracle organisation’s signature could be enforced in a client’s smart contract via an endorsement policy.
• Corda. The Corda architecture has an SDK for the creation of an oracle service. Transaction flow can communicate with an oracle service for signing to ensure everything is correct. Corda architecture supports transaction tear-offs to filter out parts of a transaction that the oracle does not need to verify the data. Transaction tear-off is based on a Merkle tree structure.

Corda has built-in oracle support offering the ability to tear off confidential parts of a transaction before verifying the oracle data. Fabric, however, requires custom oracle implementation.

11. Performance

Comparing the performance of blockchain frameworks is not an easy task. Performance results depend on the node count, network topology, network latency, payload size, and underlying database storage. Usually, official performance benchmarks are collected under optimal conditions: a high-performance PC with 32/64 GB of RAM and 8/16 CPU cores, closely connected components to ensure minimal latency and a minimal, reasonable amount of nodes. As a result, the production deployment might be slower than the provided performance benchmarks, so it is always better to conduct a performance test in the environment that the framework will be used. Performance optimisation is a large topic for a short article, so we just reference official benchmarks and outline the main points to start with.

• Fabric. There is a Hyperledger Performance and Scale Working Group that leads the process of performance testing standardisation for Hyperledger. This group is developing key metrics and basic terms for performance evaluation. The group has created a benchmark test for Fabric using Hyperledger Caliper, a tool designed for testing the performance of blockchain frameworks. The system topology under test is relatively simple. it consists of two peers and one orderer component, where peers belong to different organisations. Default test scenario is to write assets to the storage. You can get benchmarks results for both Go and JavaScript here.There are certain criteria affecting the performance of Fabric: the global state replication and the total node count, the endorser count, the orderer cluster topology and configuration, the number of organisations, the chaincode complexity and the language used. In general, the more complex the network is, the slower it is. LevelDb is faster than CouchDb, and chaincode written in Go should be faster than that written in JavaScript.
• Corda. The performance of Corda is tightly coupled with the Corda Enterprise version, as the community version has certain limitations. In the community version, a node can only process one flow at a time. In the Enterprise version, flow concurrency can be increased, drastically improving the performance of a single node.Corda Enterprise has support for MSSql, Oracle and PostgreSQL. The community version also supports PostgreSQL, which should scale much better than the default H2 database. It should be taken into account that benchmarks for the community version of Corda were collected for H2 storage. Default test scenario – issue tokens and do multiple token transfers from one node to another. More details of the Corda Enterprise benchmarks can be found here.The major difference between Corda and most other blockchain implementations is that there is no global state replication, meaning that there is potentially no limit on the network size. Still, there are certain bottlenecks, like transaction notarising (that can be handled by adding more notaries to the network), flow complexity increasing the number of network communication round trips, and the state history length affecting transaction time as all state changes should be replicated to the counterparties for verification.

The main advantage of Corda is that it does not have global state replication. In theory, it’s possible to have one global network for all organisations without performance penalties. It’s still possible to measure performance for each individual node in the network. Default test cases from provided benchmark performance are relatively similar (if we use the Fabric Go chaincode). An investigation of the dependency between the Fabric network size and performance will be explored in our next article, as the available benchmark tests were usually conducted using a limited number of participants.

Corda vs Hyperledger Fabric: use cases throughout industries

1. Finance, banking and digital assets, and real estate

Both frameworks are suitable for these cases. Corda has advantages due to its inherent data privacy, as data is not shared globally. In Corda, confidential identities can be used to hide previous owners’ data. However, asset details will still be visible for future owners. In Fabric, users might need to create multiple channels or private collections for each private collaboration, complicating network management. With private data collections, it’s possible to use Identity Mixer to hide the identity of the creator of a transaction.

Corda comes with many built-in components: a token SDK, attachments for legal prose and invoices and oracles for retrieving real-time data. A developer needs to provide a custom implementation of these features in Fabric.

2. Supply chain (health care medicine tracking, cargo and energy)

Both frameworks should work well for supply chain use cases to track asset provenance and movements. In some cases, it might be necessary to store asset prices in the blockchain and hide prices from certain participants. For example, a wholesaler would not want to show a retailer how much he paid the producer for goods.

In this case, Fabric offers the ability to update private and public data in the same transaction, so asset ownership changes are visible for everyone but prices are only visible between seller and buyer. In Corda, prices and asset movements in one transaction will be visible for all participants, so it would be necessary to split asset ownership change and money exchange into different transactions.

3. Insurance

Insurance business flow usually involves private communication between different parties. The insured creates a claim for the insurer and the insurer verifies the claim via third parties such as a hospital or the police. Usually, these interactions are one to one, and not shared with other participants in the network. Corda provides such privacy by default. In Fabric, it is necessary to define these private relationships explicitly.

4. Budgeting, government grants and public procurement

Fabric might be of benefit in use cases that require high transparency between all participants as it has a shared global state. It’s possible to implement the same in Corda, but it requires sharing information explicitly between every interested party.

5. Digital identity, voting and personal health care records

Personal data privacy has received significant attention in recent years. In Europe, the General Data Protection Regulation (GDPR) was adopted to protect users’ anonymity, their unlinkability and their right to be forgotten. Currently, neither Fabric nor Corda are GDPR compliant. All personal information must be stored off-chain. only encrypted or hashed personal data should be stored on-china and, ideally, a new key should be generated for each transaction.

Both frameworks can provide anonymity and unlinkability if private user credentials are stored on the server side. Corda does not allow storage of credentials on the client side. Fabric enables client-side transaction signing, but anonymous credentials are available only for the Java SDK, so you could not use this feature in a browser or on an iPhone.

These limitations make both frameworks partially applicable for defined use cases. They might not work where full anonymity must be preserved and credentials must be stored on the client side.

In such cases, integration with Hyperledger Indy might be needed. Indy is designed to manage digital identities, and it is compliant with GDPR. In general, Fabric provides more features to manage identities. It enables identity registration and the signing of transactions on the client side, and it allows the creation of certificates with custom attributes to enhance transaction validation and access control flows.

Conclusion

As is often the case when two mature frameworks are compared, it is not so easy to identify a winner. The short answer to the question of which framework to choose is that it depends. We believe that Fabric could cover more possible business use cases for blockchain. It is like a Lego puzzle: users can take the bricks and craft whatever experience they want. It has a more thoroughly designed identity and key management architecture to allow users to own their identity keys without the necessity to host a blockchain node, and it allows users to configure fine-grained security access on the chaincode level.

As for Corda, we really like the idea of the Corda network, where users join the global network and get access to all existing participants. As is the case in Fabric, users might end up with many segregated subnets.

For some cases, Corda will just play better, as it already has some unique features ready to go. Corda features, like attachments, the UTXO model and oracles, offer capabilities that are not as easy or, in some cases, not possible to implement in Fabric.

It is worth mentioning that in Corda, lots of features are only available in the Enterprise version, like commercial databases (Oracle, MSSql), HSM, parallel flow execution, high availability mode and private network deployment tools. In Fabric, everything is open source, though you might need a commercial deployment tool like the IBM blockchain platform.

By Volodymyr Derecha, Research and Development Engineer at ELEKS.