Distributed Ledger Frameworks Comparison: Corda vs Hyperledger Fabric

Blockchain is currently the most rapidly developing technology. There are a number of blockchain frameworks on the market — including Ethereum, Fabric, Corda, Indy, and Quorum — and many others seem to be coming out almost daily. In this article, we will take a deep dive and analyse two popular frameworks for blockchain-based enterprise solutions: Corda vs Hyperledger Fabric.

Below you’ll find an extensive comparative analysis of the two frameworks, covering the following aspects:

Disclaimer: We’ve drawn a comparison between Fabric 2.3.1 and Corda/Corda Enterprise OS 4.7.

What is Corda?

Corda is an open-source blockchain platform that streamlines the management of legal contracts and other shared information between mutually trusting parties. Corda was initially designed for applications in financial institutions. There is also its commercial edition — Corda Enterprise. Corda Enterprise extends the Corda edition and supports additional features including commercial database support (Oracle, MSSql), HSM, performance improvements (parallel flow execution), high availability node setup and tools for Corda network deployment.

What is Hyperledger Fabric?

Hyperledger Fabric is an open-source blockchain framework that enables the development of blockchain-based products, solutions and applications. Fabric is a platform designed to fit different use cases. It has modular architecture (plug-and-play) and allows the user to change elements such as consensus, transaction validation design, ledger storage and identity storage.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.


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 use cases. It is like Lego: 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.

Originally published at https://labs.eleks.com on April 16, 2021.

Distributed Ledger Frameworks Comparison: Corda vs Hyperledger Fabric was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.