Wsrtjtyk

I am a maintainer for Hyperledger Fabric, so I am obviously biased. But I have analyzed both and will try to stick to the facts. There is a lot of confusing information out there, I'll attempt to summarize the areas that you should investigate. You'll see that it all depends on your specific requirements (there are 'wins' and 'converts' on both sides).

• 
  

  Privacy

  
  
  
  
  
  • Fabric has multiple dimensions of privacy. You can use ‘channels' for complete data isolation between a set of organizations, where each channel is essentially its own private blockchain. Or you can use 'private data collections’ (since v1.2) when participants need to transact on the same blockchain, but keep data private to a subset of transactors. Private data is shared peer-to-peer, with hashes stored on the blockchain so that all peers can validate transactions, without ever disclosing the private data to unauthorized peers or the ordering service. Zero-knowledge proof asset transfer is also in the works for Fabric.
  
  
  • Corda is not technically a blockchain, rather it is a distributed ledger where transactors share data peer-to-peer. Network participants don't validate all transactions. Instead, transactions are sent to a ’notary’ to validate against "double-spends". The design premise is that nodes should only see their own transactions, as well as transactions required to verify input dependencies. Note that as time goes on and the ancestor dependency graphs get entangled, information that was previously considered private will increasingly be disclosed to other nodes as a necessary condition for validation.
  
  
  
  


• 
  

  Language support

  
  
  
  
  
  • Fabric has first class support for Go (since v1.0), Node.js (since v1.1), and Java (since v1.3), for both applications (via SDKs), and smart contracts.
  
  
  • Corda has support for Java and Kotlin.
  
  
  
  


• 
  

  Scalability

  
  
  
  
  
  • In Fabric you can build applications using either a balance model (like Ethereum) or a UTXO model (like bitcoin and Corda). Consider the workload and concurrency requirements when making a decision. In either model, you will see transaction invalidations if there are concurrent transactions competing for the same piece of state data, same as in Corda. For example if the blockchain is tracking land deeds or diamonds, or even commercial paper, where collisions would be rare for a specific asset, it may not make sense to model as UTXO (provenance would be easier to reason about as state changes on the asset). But for assets with high turnover, UTXO may likely be a better fit, where the smart contract consumes (deletes) prior input states and creates new output states. Note that Fabric plans to surface a first class UTXO API to make design choices more obvious for developers. Recall also that peers validate all transactions, this means you can load balance smart contract requests across peers and you'll get predictable response times and throughput.
  
  
  • Corda follows a UTXO model similar to bitcoin. Corda scales by adding more nodes, but I wouldn't expect a linear curve. This is because nodes don't validate all transactions up front (recall the privacy discussion above). Watch for scalability bottlenecks around the uniqueness (double-spend) and validation checks in the notary, and when a transaction has multiple inputs that requires a notary change transaction, and when nodes have to validate transactions with long dependency graphs. That is, if a node receives a transaction with a long dependency graph full of transactions that it has not validated in the past, it will have to request and validate all those transactions before validating the current transaction. This can take a long time depending on the length of the dependency graph. Throughput and latency can therefore be somewhat erratic. If you have use cases with increasingly longer dependency graphs, overall system performance could degrade over time as the number of transactions in the system accumulates.
  
  
  • For both Fabric and Corda, when looking at performance claims, look for research reports that go into these details, rather than best-case headlines and press releases. Better yet, try it out yourself against your specific workloads.
  
  
  
  


• 
  

  Database and Queryability

  
  
  
  
  
  • Fabric has a state database based on either LevelDB or CouchDB, both support key range queries. This allows you to query across assets (unlike Ethereum-based projects which only have keyed lookups). CouchDB also supports ad hoc declarative JSON queries (more straightforward for people with SQL query experience, and not to be confused with the older CouchDB MapReduce support). CouchDB is a JSON database similar to MongoDB, but managed as a completely open source database (Apache). The option to use a queryable JSON data model in Fabric alleviates the requirements of having a fixed SQL schema, which is especially important in this space as new network participants will continually bring new data requirements (consider the challenge of getting 100 organizations to agree to schema changes, and the task of upgrading schemas and migrating data in each of their databases for each contract update). The JSON data model allows for flexibility and sparse data structures where the contract authors are in control of the data choices (e.g. whether to allow optional organization-specific data). Fabric has a built-in event infrastructure that enables creation of reporting databases via event processing. Using this approach, participants can choose their favorite SQL database for integrated reporting with their existing enterprise data, or any other database type or analytics engine for that matter. Note that events are replayable (since v1.1), both to ensure consistency between the blockchain and any reporting database, and to support blockchain analytics after the fact.
  
  
  • Corda supports SQL databases including H2, SQLServer, and PostgreSQL, for both the platform and applications. This approach has pros and cons. You can query with existing SQL tools, but consider the schema implications mentioned above.
  
  
  
  


• 
  

  Platform support

  
  
  
  
  
  • Fabric runs on various architectures from x86 up to s390 mainframe, which is still favored by many banking customers due to best-in-class hardware security. But most people run Fabric on regular hardware, and often times on the cloud, as the major cloud providers have embraced Hyperledger Fabric offerings (AWS, Azure, IBM, Oracle, SAP).
  
  
  • Corda runs in a JVM (sorry, I'm not aware of the exact platforms supported or cloud options).
  
  
  
  


• 
  

  Open Source and Governance

  
  
  
  
  
  • Fabric is 100% open source and governed by Hyperledger, brought to you by the Linux Foundation. The Hyperledger Fabric community continues to grow, and we are seeing new capabilities in Fabric every quarter as a result.
  
  
  • Corda is managed by private firm R3. There is an open source offering with reduced capabilities, and a proprietary enterprise offering with their full capabilities.
  
  
  
  

I applaud your question. What better way to spark a lively debate between employees of two fierce competitor companies than to ask which one of their competing products is better? The tension is almost tangible, I can smell the sparks from here! It's also quite entertaining how each side tries to appear courteous while poking holes in one another's arguments. Capitalism at its best. Bravo!

As for your question, I think the correct answer is: it's hard to know for sure. Each side will readily offer you technical and non-technical arguments, performance measurements and testimonies, all rife with bias. This does not mean of course that one isn't better than the other. Really what you're looking for is technical, objective, third party comparisons, which are hard to come by, as this space is just too new and unexplored. So much so that we don't even have an established benchmark to compare performance numbers, let alone privacy or governance features!

Therefore I would highly recommend trying each for yourself. Read the whitepapers. How well does your business model map onto the respective technologies? How easy would it be to migrate your existing stack? If it's a new stack, how easy is it to pick up each and build something working?

In any case, I would take most of the replies to this question with a handful of salt, especially the ones admittedly written by employees.

Disclaimer: I'm a Corda platform developer.

I'm the lead engineer on the Corda project, so take what I say here with a small pinch of salt. I'm obviously biased and riven with conflicts of interest but .... I'll do my best to sound neutral anyway ;) Below I'll summarise the reasons why projects switch to Corda from other platforms.

Firstly, although this is now changing, switching from other platforms is a topic we have a great deal of experience with, because it's common for people to start with Ethereum or Fabric first and then switch to Corda afterwards. Corda started later than these projects and didn't have a big bubble or IBM's marketing might behind it to spread the word, so it's a bit less well known. We have picked up a lot of business from people who were unhappy with the other platforms.

You can read some comments from b3i and TradeIX here. b3i is a large insurance consortium and switched Fabric->Corda after about a year of development:

https://www.btcethereum.com/blog/2018/09/14/r3s-cordacon-event-sees-big-news-packed-talks-and-blockchain-converts/

The comments in that article are typical. We hear about these things again and again:

• Corda's privacy model is easier to reason about and scales better. "We'd need bazillions of channels with Fabric which is impractical, but Corda doesn't need channels" comes up a lot. I think the most recent version of Fabric has added more features to try and reduce this problem but I haven't heard much about that yet.


• Java/Kotlin are better languages than Go. Whilst you can use Java with Fabric in theory, it's not really a first class citizen. Lots of companies have lots of business logic already written in Java or languages that run on the JVM (see my corda.js demo at CordaCon for what I mean here), and we've taken great pains to ensure it's easily reused in Corda. For instance in the ISDA CDM hackathon around half of all competition entrants used Corda, I guess partly because the ISDA CDM (a common domain model for derivatives trading) is Java based.


• In particular with Java the tooling is much better. Go lacks a lot of tools that Java developers take for granted. For instance, interactive debugging isn't really a common thing in Go-world.


• Fabric's data model is based on Ethereum's and inherits the same scaling issues. To model tokens you end up with a "token app" that records a balance table. Deutsche Borse did a study recently where they tried to push performance on Fabric high, and what they saw is that many transactions were failing due to races. Ethereum has the same problem. Corda uses the UTXO model in which you can only get this kind of livelock if everyone is competing over the same state not the same app but the standard design patterns the UTXO model uses means this virtually never happens.


• Fabric has two data stores, neither of which are in my view particularly helpful for developers (LevelDB and an IBM-developed database called CouchDB). CouchDB is the only one that supports any kind of queries, but it's very problematic - their idea of a query language is "write a MapReduce in JavaScript running on an ancient JS engine" (spidermonkey), which is hardly easy compared to SQL. Corda uses relational databases natively, so you can query ledger data with ordinary SQL, use the decades of experience and rich tooling available for SQL databases and so on. In contrast basically nothing exists for CouchDB.


• Fabric is sometimes, perhaps unfairly, seen as a way for IBM to sell more mainframes. Fabric doesn't actually need to run on mainframes but the commercial version ("IBM Blockchain") apparently is pushed in concert with them. Likewise for Bluemix...


• We're trying to build a global peer to peer network in which apps interoperate. The governance is going to be entirely open - we're setting up a non profit foundation in the Netherlands and there are drafts of the constitutional documents and initial policy proposals on the corda-network@groups.io mailing list. If the Fabric guys are doing the same then I haven't heard of it. We believe that apps that interact with each other will be a massive part of how blockchain technology helps business take place in future. Fabric tends to be deployed in isolated islands, it seems.


• We hear a lot that people really love our documentation. I don't know if that reflects a lack on the part of other platforms or whether we're just better than expected, but we hear this all the time. We keep the docs in the same git repository as our code and use the code review process to enforce that all code changes simultaneously update the docs, so we were able to establish a "documentation culture" early on.

Finally, in the interests of fairness, I've heard of one case of a company going Corda -> Fabric. I believe it was quite some time ago, possibly ~2 years ago, but I only heard about it recently. They thought Fabric was easier to deploy, but I never found out what the specific concerns were. We've been doing a lot of work throughout 2018 on productionization with better performance, better admin tools, better docs, the Corda Firewall program etc so I hope that they wouldn't have such concerns anymore.

Disclaimer: I lead the Solutions Engineering team for R3, so not claiming to be unbiased either. I don't feel qualified to opine on Fabric, but I'm happy to make a few comments about Corda...

Scaling

• 
  

  Corda scales really well. A user put this best:
  http://www.dtcc.com/news/2018/october/16/dtcc-unveils-groundbreaking-study-on-dlt

  
  
  

  The 6300 trades per second is actually about 19k TPS at the network
  level.

  
  
  

  The performance of components will continue to improve, of course, but the design is such that no single component limits the ability of the network.

  
  

Platforms

• 
  

  Corda relies on a JVM, so is designed to run on pretty-much any hardware that anyone wants to. While most people use an x86, it'll run on ARM or other ISAs. I don't know if anyone has we've ever tried running on a '390 but I daresay there's not a problem for any compliant Java implementation.

  
  
  

  When it comes to hosting Corda is agnostic too, whether it's any of the cloud platforms or running on-premises in a multi-layered network architecture.

  
  

Technology Choices

• 
  

  While Corda is often touted as "the blockchain for Finance", it's used being used almost anywhere a blockchain can make sense (and the Corda community keep developing new uses all the time).

  
  
  

  Starting with finance means starting with one of the hardest markets. This is an area in which privacy, reliability, stability, scalability, operational deployability, etc., are all incredibly important. Corda was designed from the outset with these requirements in mind, and, of course, by meeting these needs then it can meet the needs of other, less strictly regulated, applications too. Some of the implementation may look a little conservative, but it's pretty certain that the things it is built with will continue to be around, understood, and supported in 20 years (or any time into the future) when the smart contract logic written today may be being checked for the first time in two decades by those future systems.

  
  

Industries

• 
  

  People are building applications on Corda across a huge range of industries (including quite a few that came to Corda from other platforms ;-)). If you want to get a sense of just a few of these then you can check out the video playlists from CordaCon 2018, although this is just a small sample:

  
  
  

  DevDay: https://www.youtube.com/playlist?list=PLf4g0MzKRvGn4mG-vF06k9XgcHKEHH5c4

  
  
  

  BizDay: https://www.youtube.com/playlist?list=PLf4g0MzKRvGkVeZwJm2MHMue2JrqxMtlV

  
  

Disclaimer: I'm a product manager for IBM Blockchain and support our teams contributing to Hyperledger Fabric. I’m also biased, but will do my best to explain why I see users choosing Hyperledger Fabric as their platform as neutrally as possible.

Diverse community and governance

• The software development process is 100% transparent. Anyone can participate in code contributions, as well in the governance process of the project.


• Hyperledger itself is supported by 250+ members. Fun Fact: R3 is actually a member.

Industry Agnostic Platform

• Hyperledger Fabric is a development platform designed to be applicable across all industries and their use cases. If there is a blockchain use case, Fabric can support it. Companies with use cases in finance, distribution and logistics, public sector, insurance, telecom, industrial, and retail sectors have all chosen to build on Hyperledger Fabric. This is enabled by Fabric’s modular architecture - pluggable endorsement, database, consensus, identity, and chaincode foster diverse application development tailored to specific use-cases. The Hyperledger Fabric community understands that there is no one size fits all approach to blockchain.


• Some very prominent FSS organizations actively building on Hyperleder Fabric: We.Trade, MUFG, and CLS.

Freedom of Choice

• Building on Hyperledger Fabric allows to you choose the compute platform which serves you best. It is a core offering of IBM, Amazon, Microsoft, SAP, and Oracle. When you have the largest cloud competition competing for blockchain workloads, you’ll see these competitors racing to provide the best experience and capabilities for the common code base in order to acquire those workloads. This benefits users of Fabric.

Always on operations engineered with enterprise capabilities

• Fabric delivers upon operational features in addition to the blockchain capability. Fabric supports the full lifecycle of installing, deploying, and updating chaincode/smart contracts with flexible governance policies. It supports rolling upgrade of peer software. It also supports a variety of cryptographic algorithms for signing/verifying/identity attestation. Comprehensive penetration testing is performed and evaluated by the community upon releases.

Innovative Capabilities

• Zero knowledge proofs for privacy preserving asset transfer, Burrow EVM integration to execute Ethereum smart contracts, new consensus models and native token functionality are Fabric capabilities being delivered in the next 6 months. You can be sure the community will continue to drive innovation into the releases to keep up with the rapidly changing blockchain space.

If you want to learn more and meet community members, come join the Rocketchat: https://chat.hyperledger.org/

If we compare these two platforms in terms of performance, definitely Fabric is the better one.

With Fabric v1.1 & beyond, we can achieve >2000 tps (http://www.mscs.mu.edu/~mascots/Papers/67.pdf).

For Corda, the reported performance number we have seen so far is only 170 tps (https://medium.com/corda/transactions-per-second-tps-de3fb55d60e3)

Though the hardware and benchmark used for these two studies might be different, I believe that these numbers were generated with a best-case scenario (that can achieve the maximum performance) for the respective platforms.

Technologically speaking, both platforms are very similar. You have to look at the matters outside of technology, mainly at project development governance (community vs single company-dominated) and availability of all components under a permissive open-source model (Corda is available in two versions which do not come up with identical toolset) to make an informed decision which one is better for your use case.