[mike_hearn]

As someone who built a platform for business/governmental 'enterprise blockchain' apps, humor me whilst I mount a defense of them here.

Firstly, forget all about outspending the network. None of the platforms an organization like the DMV might consider use proof of work (I'd hope). Standard within that space are BFT algorithms, or even non-BFT algorithms like Raft, or even a simple centralized DB (but which only holds tx ordering info, not the actual tx contents themselves).

Enterprise blockchain platforms try to solve the following problem: there are many situations where different organizations would benefit from a proper digitization of a business process, but it doesn't happen because the political/business costs of placing one organization in control of that process is too great. In turn that requirement comes from the software industry only delivering systems that assume one party controls everything. If the business process you're automating exists entirely within an organization, or if you can get all the organizations to buy into a single platform company, then it works. If those two things aren't true then we got nothing for you and so you end up with "digitized" processes that often are little more fancy than emailing PDFs or XLS files around. Or the government steps in to provide something at which point the ability to innovate or evolve that process grinds to a halt, because their only goal is system stability and not feature development.

One thing to note here - I learned whilst working on some of these projects that whilst they may sometimes appear nonsensical on the surface, that was usually due to lack of domain knowledge on my part. For example there was a project to try and put land registration in the UK "on the blockchain" (concretely, using the platform I worked on) and so I asked early on whether this really made sense because, surely, the government is the central point of truth for land ownership? Where's the inter-organization aspect? Well, guess what, turns out there are tons of obscure business processes around the buying and selling of land in which the land registry plays a key part, but it's only one organization amongst several, and a big part of the schlepp-work here is coordinating all those organizations and moving documents (i.e. hand written database transactions) between them. Once the domain experts walked me through those processes in detail and explained what they wanted, I realized it wasn't nonsensical at all. There were a lot of cases like that, where in theory I was selling the tech to them, but in reality they were explaining the need to me.

So what to do? These problems would go away and the impact of IT would be much greater, if we had two difficult-to-make things:

1. Some sort of multi-master database system in which the masters didn't trust each other, which could work together over the internet such that each company or organization could run a node themselves.

2. Social institutions that could set up and make use of such systems without any one party gaining too much power over the others.

Due to the enormous pre-existing demand that existed for automating all these difficult-to-automate business processes, when people realized that Bitcoin basically worked by solving (1) and to some unclear extent also (2), they jumped on it. Except of course the whole design philosophy of the tech really wasn't what they needed or wanted, hence the evolution of dedicated platforms like Corda that tossed out proof of work, added conventional tech like X.509, per-node RDBMS and so on.

Now in practice a lot of these projects fizzled out, which is one reason why we get threads like this one on HN. Having seen a lot of these projects in action, the issue was really that both (1) and (2) were never fully solved. For (1) the tech problems are hard because it's all the difficult bits of distributed computing and distributed databases, with lack of trust thrown in on top, combined with really difficult deployment environments (like banks), combined with many of the platforms advertised to such projects going off into the technical weeds with things like new programming languages. But the tech issues pale in comparison to (2), the social difficulties of coordinating multiple institutions in the design and implementation of complicated IT projects. In fact that was by far the hardest part and in the end the real sticking point. Without capitalist ownership incentives projects don't make progress - look at IRC vs Slack for a particularly stark example - and so often these projects got spun out into startups. But then you're back to relying on a third party. At first it didn't seem like too much of a compromise because they would just write the software, and the institutions would at least run it so the startups wouldn't get everyone's data like in a classical SaaS situation, and the platforms were designed to allow for some level of divergence and forking. But then often the customers started running out of steam and just wanted to pay someone else to run it all, so it degraded back down to being SaaS but with more overhead.

In the end the thing that stopped most of these projects being successful wasn't that the core problem statement was wrong, or even that the tech wasn't good enough (though sometimes it struggled to meet people's needs). It was actually that most non-tech orgs have developed an unwritten cultural rule of institutionally "sandboxing" tech projects to avoid the potential for career damage when they inexplicably blow up (due to mismanagement but the people involved often don't realize that). For as long as projects are confined to the sandbox marked "innovation team" everyone is happy. When it comes to real implementation, the executives start looking for ways to outsource it all so if things go wrong they can point the finger at the vendor - they want "one throat to choke" in the lingo.

This dynamic causes organizations to diverge. Either they successfully make the transition to being a sort of tech company, in which case they want to own all the platforms and probably can, or they become hollowed out customers of vendor's pre-packaged business automations in which they experience less career risk, but struggle to differentiate.

[mjburgess]

You still havent provided a use-case. As far as I can tell what you're describing is business services connected by web APIs -- ie., the internet + microservices.

Ie., "enterprise blockchain" is just SoA.

That's status quo.

I still don't see where the need for a peer-to-peer consensus model comes from. One party to the system is the authority: they create the data about the relevant things. Or if there is a genuine multi-party authority problem, why would an algorithmic consensus model work?

If the UK and EU disagree, that isnt solvable by a p2p technical consensus protocol.

In what case are multiple peers in receipt of distributed transactions whose "integrity" can be resolved by a technological consensus process? (Subject to networked incentives, etc.)

The single use case here is clear: adversarial economic transactions.

The problem with this use case is also clear: fraud doesnt occur because the transactions themsevles are in disagreement; it occurs becuase people are falible. So we need reversability in the system. etc. etc.

[mike_hearn]

I just mentioned one use case: land ownership management. But there are plenty of other use cases in for example logistics (trade finance is a complex multi-party business process), in invoicing, in supply chain handling, and indeed of course in inter-firm payments or anything between governments.

"As far as I can tell what you're describing is business services connected by web APIs -- ie., the internet + microservices."

Web API tech (I assume you mean REST here) doesn't provide even a fraction of what's required.

"I still don't see where the need for a peer-to-peer consensus model comes from. One party to the system is the authority"

No, in most of these use cases there isn't a single party that's the authority and one that's subservient. Consider a simple example: company A wishes to buy something physical from company B. In an ideal system the act of sending the money would be atomic with the act of marking the relevant invoice as paid, and possibly in turn with the act of signing the paperwork saying the goods were delivered in acceptable condition. Today you can't do that because there is no one organization that's the authority for the banking system and the invoice between the organizations and the delivery tracking. So you have to do three steps independently and then they inevitably get out of sync (a "break"), requiring manual reconciliation ("rec") to locate and patch things up. Banks alone have departments devoted to nothing but that.

With a proper solution - call it what you want - you'd be able to make a single database transaction that updates the state of all three things simultaneously and atomically, such that everyone involved in the transaction is always on the same page, yet only finds out the relevant data they need to know and no more.

Most transactions don't fall neatly into the category of friendly or adversarial. People want to cooperate but they also have their own incentives, and when mistakes happen people want the consequences to fall elsewhere. P2P consensus helps because it means you can established shared schemas, shared agreement that the coded-in business logic has been followed, everyone sees the same state on their screens when they go look at the details, etc. You can't get into a position where one party says they paid for something and the other party thinks they didn't. It's all basic enough stuff but our current tech just can't do it.

[mjburgess]

You say land use, but your explanation of the need is economic -- that use case is already conceded. It's bad on other grounds.

You haven't explained why a land registry is appropriately modelled by a peer-2-peer adversarial database system.

There is an authority here: the state. Land is /registered/ with the state.

If there are multiple parties with a claim to land, that dispute requires a non-technical consensus model called 'the law' and its resolution is not final. The state retains the privilege, as it must, to revise its decisions.

Trying to replace courts with blockchains is a dumb idea, so silly that its proposal immediately signals a profound ignorance of the problem domain.

Which is: People.

[mike_hearn]

You're mis-understanding the use case.

It's been some years but my recollection of the explanation is something like this. The process of buying/selling houses and land involves many organizations. There is the land registry, the bank, lawyers, conveyancers and possibly others I've forgotten about. To actually complete a sale requires coordination of all of these. Today this is done with lots of human-readable documents bouncing around, maybe in digital form if you're lucky, wet ink signatures, lots of people who are just sort of trusted because they're pillars of society and so on. There's lots that can go wrong even in the absence of a dispute over who actually owns the land currently, it's very slow and it's very hard to digitize. Land registry exposing some documented HTTP endpoints doesn't fix anything because it doesn't solve any of the coordination or security or privacy problems.

[mjburgess]

Yes, but for the same reason blockchain doesn't

Those are problems coordinating people --- not nodes holding duplicate and adversarial copies of datasets

The whole blockchain sales pitch is lie or fallacy of ambiguity.

Ie., the 'consensus' of a blockchain isn't social and indeed makes social consensus much harder

since it aims for immutability and so on

[mike_hearn]

The consensus is largely social, because for a transaction to commit it must be (digitally) signed by the correct counterparties, and people holding duplicated and adversarial copies is a real problem that does cause disruption to business on a daily basis. If two organizations have two documents that claim to be the same thing but differ, how do you decide who wins? Ideally you never get into that situation but it can easily happen in many ways.

Still, I'm not trying to sell this stuff to you. If you don't believe these problems or the use cases exist, fine; the world is full of people who deal with them and would indeed like solutions.