| Hi there - Richard Brown, CTO of R3 here. We support and maintain Corda, an open source permissioned blockchain (that is not currently part of Hyperledger). Brian has done a good job of putting Hyperledger's case and I agree with him in a lot of his responses. But I wonder if there's a broader point to be made too. One of the key questions being asked here, it seems, is: what problem (if any!) do permissioned blockchains solve? Put another way: if you're not trying to build a censorship-resistant, decentralised payments network, for example, why do you need any of this stuff? To be frank, where I think _some_ private blockchain platforms have gone wrong is that they have never satisfactorily answered this question. Instead, there has been a leap of magical thinking from "Bitcoin is amazing" to "let's cargo-cult some of the same ideas and use them to solve (unspecified) problems in business." This is not a critique of Hyperledger btw... It's true I've made some high-profile critiques of Hyperledger Fabric's design choices in the past but that isn't my point here. Indeed, I'd hope most of the Hyperledger community would agree with this post. The thought process we went through when we designed Corda at its most simple was: how can we build a system that allows parties who wish to transact (but who don't fully trust each other) to maintain accurate shared records of their dealings with each other without reliance on a third party? I know that _sounds_ either vacuous or trivial but I really don't believe it is. I still don't think I've written a totally satisfactory description of my vision but the article linked to below probably comes closest (scroll quickly past the shilling I do for our commercial distribution at the top and tail... the meat is in the middle!) https://medium.com/corda/markets-are-decentralised-and-the-s... tl:dr of that piece: firms who transact with each other in the real world - with paper and phone calls and faxes - don't need a centralised third party toll-taker to manage and record their transactions for them. So why is our instinctive response to introduce one when those same firms decide to transact electronically? Whether it's a centralised database (who runs it? what do they charge? what power do they have? who holds them accountable? what happens if it goes down?) or a formally constituted infrastructure firm like in the financial markets, adding a centralised entity where previously there were none feels like inadequacies in technology forcing industries to change their market structures. Tail wagging the dog. And yet, without such a thing, you end up in a total mess with each firm holding and maintaining their own records, which are invariably out of sync (out of consensus) with their counterparts. A key problem we try to solve with Corda is to enable trading partners to connect their applications to each other in a way that ensures they're in sync at all times. And this requires far more than just conveying data from one side to the other... it's ensuring it's interpreted and processed in the same way - deterministically, in the same order. Indeed, the abstract for the Corda technical whitepaper actually calls it a "decentralised database" (note: not "distributed database"). This takes you into a completely different design space where many (but, crucially, not all) of the same principles underpinning public blockchains are needed... but where requirements such as transaction finality, strong identity, interop/integration with existing systems, reuse of existing codebases, developer productivity, ability to deploy behind a firewall yet connect to peers across the internet, etc., come into play. The result is that platforms like Corda look similar to public blockchains on one level (chains of transactions, deterministic execution of business logic, digital signing of transactions, decentralised consensus algorithm to confirm and order transactions) but also very different (no crypto economic incentive, settlement finality, runs on the JVM so the world's 10m Java developers can use it easily and so on) |