Hyperledger Fabric vs R3 Corda: A Business Perspective

Aw Kai Shin
12 min readJun 2, 2020

--

Source

Blockchain technologies have come a long way since its first successful iteration in the Bitcoin protocol. For those keeping track of the industry, so much has happened since then but enterprise use cases of the technology is still considered to be in its discovery phase. Among those use cases that have been successfully rolled out, there are two platforms that will pop up more often than not: Hyperledger Fabric and R3 Corda. Comparing the architecture of these two platforms from a business approach would shed some light into what exactly enterprises are looking for when it comes to adopting blockchain technologies. After all, enterprise adoption is one of the best ways to separate actual value from the hype (in most cases).

For those more knowledgeable about Corda, I am aware that it is not strictly speaking a blockchain system but it has always been mentioned in the same breath as other enterprise blockchains. Rather than being bogged down by the semantics, it would be valuable to understand why such a design choice was made. As with all other enterprise software, the best place to start is the professional services available for each platform. No matter how good your software, adoption will be difficult if there is no support, training, or integration services.

Please note that the below is to the best of my knowledge as I wrote this to solidify my understanding of both protocols. I would be happy to make any changes if you spot any error or room for improvement. :)

Professional Support

If the names did not give it away already, the two companies responsible for the products are Hyperledger and R3.

  • Hyperledger was established under the Linux Foundation and is meant to be an open source community focused on delivering enterprise-grade blockchain deployments. There is some subtlety behind this organisation as IBM and Digital Asset were the original contributors to Fabric in 2016. Big Blue with its depth of services is not the only one providing support of the Fabric protocol, more well known names include Accenture, Ant Financial, Huawei, SAP, and Samsung (full list here)
  • R3 was founded in 2014 and is the sole service provider behind the Corda network, which was open-sourced in November 2016. R3 divides its offerings into Corda and Corda Enterprise. Corda Enterprise contains all the core Corda functionality, but also includes the Corda Firewall, support for high-availability (HA) Node and Notary deployments, and compatibility with Hardware Security Modules. R3’s professional services are only extended to users of Corda Enterprise. That being said, the initial R3 consortium had the backing of industry giants such as Goldman Sachs, Barclays, JP Morgan, and UBS (full list here).

Of note is that both platforms are open-sourced and have an active development community with hundreds of contributors to their Github page. Both companies provide certification and training tools for their respective protocols. Where they differ is in professional services and support as this is provided by the vendors in Fabric’s case as compared to straight from R3 for Corda. Having never had the chance to be on the receiving end of either service, I can only infer the reliability given that these are all very well-established brands. Besides, nothing makes it easier to generate interest in a product than quoting such brands because of the assurance and recognition that such brands carry.

Applicability

Enterprise technologies are rarely ever used straight out of the box, especially at the architecture layer which is where block chain technologies are. The first consideration that has to be taken into account prior to even approaching a cost/benefit analysis is the relevance of the protocol to the issue that the particular organization is trying to solve. This forms the catalyst for organizations looking into new technology solutions, solutions which must be flexible enough to adapt to their use case while minimizing time spent on industry standard compliance. This flexibility will also aid in upgrading the protocol as and when needed for the foreseeable future.

  • Fabric was designed at its core to be configured to meet the diversity of enterprise use case requirements. This is achieved via: pluggable ordering service ; pluggable membership service provider; pluggable endorsement and validation policy; optional P2P gossip service; ledger supports a variety of DBMS. Fabric supports different version levels which enables rolling upgrades of Fabric nodes.
  • Corda’s design was initially driven by the needs of regulated financial institutions but has since been generalized. Consequently, Corda leverages upon industry-standard protocols while offering pluggable notaries. Corda supports platform versioning via configuration of minimum and target versions. Corda 4.0 currently partially supports rolling upgrades with full support being planned.

Fabric is the more configurable of the two and therefore should be able to cover a wider range of use cases. The extent to which this is advantageous will be determined by alignment to existing industry protocols, this is where Corda might hold the advantage. One key advantage which Fabric’s flexibility does provide is that it enables its vendors to release a myriad of Fabric protocol implementations which were written from different business perspectives.

Of note is that Corda does not fully support rolling upgrades as of this article so any upgrade of the nodes will result in service disruption for the period of the upgrade. However, Corda does use persistent queues on the networking level which means connection need not be persistent and will be completed when the requested node is back online.

Network Membership and Identity

Identity on the network is the next logical place to start as the value of blockchain derives from its members. After identifying the members in the network, the protocol must provide a way for users to administer identities in order to control network access.

  • Fabric has a built-in Fabric Certificate Authority (CA) which manages digital identities of participants via X.509 certificates. Public Key Infrastructure (PKI) provides a list of verifiable identities via a chain of trust and a Membership Service Provider (MSP) turn verifiable identities into the members of a blockchain network by holding the peer’s public key. MSP defines the rules that govern the valid identities and hence act as the trusted authority. MSPs have control over two domains: locally on an actor’s node or in a channel configuration.
  • Corda’s Identity Service controls admission into the network by approving certificate signing requests. Network Operators are responsible for enforcing rules regarding info required and KYC processes in order to be granted a certificate. This certificate maps nodes to real-world legal identity and public key. Subsequently, Corda then maps node identity to an IP address via the Network Service Map which makes it discoverable to the network. An optional Naming Layer is added on top based on X.509 certificate hierarchies rooted at a single certificate authority for each network. Certificate chain linking a confidential identity is distributed on a need to know basis.

Both protocols builds on the well-established X.509 standard and therefore relies on a trusted authority to define and issue an identity on the network. This is a safe assumption as both these networks are permissioned with the identities of the participant’s being known. Both protocols are also able to encapsulate the role of the identity administrator depending on the ledgers which they each have access to. One minor advantage Corda does have is in its optional Name Layer which just maps the identities in the network in a more human-readable way. Overall, the identity framework for both should be familiar to most developers.

Ease of Development

The war between business people and developers have been ongoing since the beginning of code and for good reason, both parties tend not to share the same language when communicating about the same product. That being said, by making the protocols more approachable to the developers, it will go a long way to achieving buy in for the technology.

  • Fabric enables its smart contracts to be authored in general programming languages. This is achieved via the execute-order-validate architecture relative to the order-execute-validate found in most public blockchains. The latter requires smart contracts to be deterministic, otherwise, consensus might never be reached. Consequently, Fabric’s execute-order architecture eliminates any non-determinism as inconsistent results can be filtered out before ordering. Fabric’s exposes its APIs via SDKs which come in many flavors: Go, Java, Node.js, and Python. Although Fabric has a native utility called Chaintool, development tools will vary by vendor with tools such as IBM Blockchain Platform receiving the reddot award.
  • Corda’s smart contracts run in a modified Java VM which was tweaked with determinism in mind. Smart contracts in Corda can therefore be written in Java or Kotlin. Corda also provides developer tools ranging from: Corda Network Builder, Network Bootstrapper, DemoBench, Node Explorer, Checkpoint Tooling.

Both protocols do not tie the developer to a domain-specific language, meaning that companies do not have to take into account additional costs of training their headcount. With that being said, Fabric has a clear advantage in terms of the number of languages available on the platform especially since this also includes Java. Both protocols have a wide range of developer tools that can be utilized but aren’t directly comparable as this is largely provided by the vendor in Fabric’s case as compared to directly by the owning company in Corda’s case. Although Fabric might seem to have the upper hand here, Corda does have the concept of CorDapps which is discussed below.

Note: Fabric 2.0 does have the concept of external builders and launchers which is loosely based on Heroku buildpacks.

Contract as Code

Much of the work done by the developers of an organization joining a blockchain network will usually be in the form of writing smart contracts that encapsulates their own business logic. It is the smart contract that enables the performance of credible transactions without the need for a trusted third party. Even when the developer is familiar with the smart contract language, there will be certain rules or best practices which they will have to follow.

  • Fabric’s transaction logic is defined via smart contracts. These smart contracts are in turn defined within Fabric’s concept of a chaincode. Chaincode is Fabric’s way of packaging related smart contracts into related technical containers for deployment. In terms of getting started on writing your own smart contract, Fabric does provide some tutorials in its documentation as well as a host of sample projects which exposes developers to common Fabric code patterns.
  • Corda uses the concept of CorDapps which is comparable to smart contracts. The CorDapp’s goal is to allow nodes to reach agreement on updates to the ledger by defining flows that Corda node owners can invoke over RPC. Corda’s flow concept automates the process of agreeing ledger updates via predefined steps that the node runs to achieve a specific update. Corda provides built-in flows to automate common tasks. Tutorials and many sample projects are also available in their documentation.

Both platforms seem to be similar when it comes to the learning curve for developing smart contracts with sufficient tutorials to cover the key concepts of the protocol. Corda’s flow concept seems to be similar to an SDK with extended capabilities, as it requires installation of CorDapp on the node in order to communicate with other nodes. Of note, the development of smart contracts is purely in the domain of the developer as both platforms abstracts the operational aspects of the smart contract.

Network Governance (Individual network level)

From an individual’s perspective, any new technologies mean learning additional skills to replace or even add on to the current one. When it comes down to it, majority of workers would prefer that their responsibilities are clearly defined so that they don’t end up spending unpaid hours completing something outside their given job scope. Reducing the management complexity of new technologies will not only make this scope delineation easier but also make governing such technologies much simpler.

  • Fabric’s network governance can be summarised into 3 distinct layers, each having separate and independent configurations: network level owned by network administrators; channel level owned by node administrators; node level owned by individual organisations. The network and channel levels require consensus for any changes but each organization is still provided the flexibility of implementation via the node level. The starting organization receives all administrative rights upon network initialization and can split responsibility accordingly by on boarding another organisation’s CA. The Network Administrator defines a consortium whose members then become equal administrators when a channel is initialized using this consortium definition. Chaincode installation on a channel requires that the required number of endorsements are met as the chaincode while installation on a node requires the Node Administrator’s approval.
  • Corda’s identity hierarchy has a single root which is the node’s network operator. The network operator is responsible for signing the certificates that bind a human readable name to a public key, thereby also delegating authority over the sub-namespace of a single legal identity. Corda does not confine authority delegation to just sub-namespaces so it is up to the network operator to define. The Corda platform is currently unable to handle the ambiguity of multiple certificates for the same identity in different parts of the hierarchy. Any changes to the network parameters needs to be signed by the network operator. Communication setup between nodes is therefore also dependent on both node operators coordinating with each other as well with the designated notary cluster.

Fabric’s architecture does provide the platform with a more defined governance structure. In the case of Corda, a lot of the governance is determined between the network operators of that sub-network. Both platforms delegate responsibility to the user which has the best knowledge about their own businesses and therefore empowers shared self-governance within the larger protocol framework. Both platforms provide sufficient flexibility and security when configuring their trust boundaries but personally I find the Fabric model much easier to reason about mainly due to the fact that governance complexity tends to grow quicker in Corda’s case.

Privacy

Much of the competitive advantage in the modern economy comes from data. As such, data in an enterprise network should only be shared on a need-to-know basis. Consequently, the network will have to account for the varied privacy requirements facing the business network.

  • Fabric uses the concept of channel which establishes a sub-network where only members registered to channel will have visibility of its transactions. Additionally, Fabric also has a private data feature which is scoped to the channel and allows for use cases where you want all channel participants to see a transaction while keeping a portion of the data private. The private data is distributed P2P via gossip amongst the authorised channels. The hash of the actual private data is endorsed, ordered, and written to the ledgers of every peer on the channel.
  • Corda’s ledger is subjective to each peer’s perspective with each peer only seeing a subset of facts on the ledger. No peer is aware of the ledger in its entirety. Communication is P2P with any broadcasts having to use the Network Map Service to loop over. Corda has the concept of filtered transactions which is implemented via what it calls transaction tear-offs. The transaction proposer uses a nested Merkle Tree approach to “tear-off” any parts of the transaction that doesn’t need to be seen by the orderer or third party oracles.

The main difference between the privacy approach is that Fabric broadcasts a transaction to all members of a channel while Corda does this on a peer by peer basis. It does seem like the Corda ledger architecture will face a higher management overhead as the number of P2P relationships grow as it has to be configured on a case by case basis. Fabric’s management of ledger visibility is done at the channel configuration level and the only time P2P relationships have to be managed are in the case of its private data feature. The channel architecture also focuses more on the why rather than the who which makes it easier to reason about all a peer’s relationship from a business perspective.

Conclusion

There are of course many other aspects of both platforms which can be compared but this article is starting to get really long so the above will just have to do as a starting point. Moreover, though a lot of the technical implementation differs, many of the core functionalities are available across both platforms with scalability being a non-issue. The main takeaway from this is that Fabric is designed with modularity in mind while Corda has a stronger focus on industry standards.

Like most things, the answer as to which is better for your use case is that it depends but more likely than not, Fabric would be more applicable due to its flexibility not only in terms of architecture but also its vendor governance model. Nevertheless, while looking for a permissioned blockchain network, Corda should also definitely be considered given it’s industry focus as well as single point of contact, which is the R3 organization. Given the track record of both these protocols, it does seem like there continues to be sufficient demand for both and I’m excited to see how these platforms continue to evolve.

Thanks for staying till the end. Would love to hear your thought/comments so do drop a comment. I’m active on twitter @AwKaiShin if you would like to receive more digestible tidbits of crypto-related info or visit my personal website if you would like my services :)

--

--

Aw Kai Shin

Web3, Crypto & Blockchain: Building a More Equitable Web | Technical Writer @FactorDAO | www.awkaishin.com