Even if one needs trust that there's lack of tampering, publishing a real-time transaction log is in many cases sufficient, just as long as you're willing to trust that the central point is ordering transactions fairly. Which is fine in the case where there's a legal relationship between the entities involved.
Edit: help me understand why you disagree
For example I still often hear people say the blockchain is cool but the value token isn't. When I tell them blockchain without a value token doesn't incentivise decentralised mining and it's just a regular old database, there's just no real response because their point was a talking point they read somewhere.
I stopped talking about it around 2015, I just got bored of having the same conversations.
The moment that was, in retrospect, pivotal was being summoned to a meeting with some of our sales guys and an industry analyst as an 'authority' on blockchain (when really I'm just someone who had an interest in it). The analyst went on a long rant about how 'Smart Contracts' were going to revolutionise the insurance industry by being able to execute payouts automatically and how agreements were all going to be automated etc. etc. I tried to explain that 'Smart Contracts' weren't really 'smart' or 'contracts' and that what she was thinking about would probably be better described as 'Ricardian Contracts' (which don't require a blockchain to exist), but I could tell by the glazed over expression in her eyes that she was so sold on her notion of Smart Contracts that there was little to no chance that I was going to be able to dissuade her in a 15 minute discussion.
These private institutions have way too much arbitrary power to decide the fates of others with opaque & inconsistent reasoning-- I see nearly anything providing a check against that power as useful. I'm no longer convinced blockchain tech is a viable answer, but I do think having a variety of non-consolidated payment processors to choose from is a good thing.
Payment processors have also been known to discriminate against perfectly legal businesses for a long list of random things some old jackass in a suit decided were too 'unsavory'.
I think these organizations are wrong to meddle so much rather than being passive facilitators as originally envisioned. They have a right to exclude things which put their assets at risk, as well as a legal obligation to assist law enforcement where appropriate, but beyond that neutrality and privacy should be the rule.
Typically, it's because of fraud, not unsavory-ness. Fraud on the customer's side, not the business'.
The solution to that is not making every transaction put the weight of fraud solely on the customer.
Even if they did want that for some reason, most countries have anti money-laundering laws where you have to be able to stop doing business with certain parties.
Really, you can keep adding hashes to your log, but a client needs to save old hashes and have some access to old logs before they can verify anything.
IMO, a large reason everything went blockchain is you can tack it in without changing anything. Just setup a process to modify your logs and boom another buzzword.
Having global consensus (PoW) is a different matter, but that doesn't mean what you are saying isn't a blockchain.
There is a good conversation me and @geofft had the other day, would love your thoughts on it: https://news.ycombinator.com/item?id=17000401
In practice, many of these organizations talking about using in-house blockchains have legal trust relationships and systems of laws in common, and they won't only be relying on a transaction log to make sure the record isn't getting fiddled.
And often the threat model isn't related to changing the historical ledger anyhow; there is a lot of fraud, embezzlement, and other financial crime that attacks other points in the system. That requires a significant system of financial controls, which will be sufficient to catch ledger tampering as well. Meaning that the checksums become a modest nice-to-have, not a significant anti-fraud technique.
You are saying because these types of verified logs can't control for other variables, they do not represent a "complete" set of the system, and therefore aren't as useful for fraud analysis? Hmm.
But this is where I feel like calling a cryptocurrency economic model a "blockchain" is just a silly misappropriation of a word. To me, clearly "blockchain" is not like "capital" or "communes", a blockchain is a cryptographically verified data structure. However, I do hear a lot of people throwing around the word "blockchain" just to reference an economic model, which seems excessive.
I like your point though, and well described.
So, while Blockchain has nothing directly to do with being distributed, that's just a useful feature but requires proof of work of some kind, or someone can quickly manufacture several blocks.
Fair point about it being distributed
The Proof of Work solves a separate problem, that of Double-Spending. The Proof of Work here isn't arbitrarily to slow the system itself down, just to slow non-canonical histories.
But that itself is not the "blockchain" (thus the "how do you define it?" question, I'm curious to hear your take), I'm just playing devil's advocate: A lot of people who weren't around in the 70s are now calling verified logs a "blockchain", now it is a stupid buzzword, but at what point do we consolidate the word for an idea, versus argue there are semantic differences?
The real problem here is organisations jumping on the bandwagon without really understanding what they're doing.
Sure, when Maersk uses a private blockchain to track shipments, it's hard to see how it improves on an ordinary database.
But let's say you want to build a prediction market for official corruption. The minute you start taking bets on which government officials are taking bribes, you'll have a powerful people trying to take you offline.
It's extremely difficult to build a completely anonymous and decentralized application to do this, but decentralized nodes with anonymous validators that you control is a potential hybrid that's resistant to censorship.
Feel free to think up all the rules you want to prevent this, but a motivated entity can always simply pay large numbers of people to act on their behalf. If they're good at it, you won't know until it's too late.
Past a certain point, involving people's actual identities in the nitty gritty real world becomes increasingly necessary to establish trust. There are exceptions, but AFAICT they mostly rely on being uninteresting to would-be attackers.
Or did I miss something?
I've found myself asking that frequently with the blockchain/cryptocurrency mania. The answer has always been no.
If you just want to avoid tampering, you're better off with servers publishing (signed) messages and clients storing those in an append-only log; a good example are the CT logs: https://en.wikipedia.org/wiki/Certificate_Transparency
This is a little like how I used to not understand why banks or other large firms cared about blockchains at all - isn't the point to get rid of them? Then it became clear that the problem of individuals trying to sync views of balances over the internet without powerful middlemen is a scaled down (or up) instance of a more general problem that lots of firms have between themselves, trying to sync data between organisations. And that this is a legitimate problem to want to solve with peer to peer technologies.
The main reasons you see companies deploying "blockchain but we control all the nodes" - an apparently nonsensical setup - are twofold:
1. They do want the ability for other orgs to run nodes in their blockchain network, or rather, some of their customers want the ability to run their own nodes and rely on the centralised firm less. But many customers don't care. They prefer to trust a centralised authority, at least given the current state of technology. Therefore, firms want the ability to decentralise selectively in response to demand.
2. They're doing a tech refresh. The world is full of financial middlemen who have platforms decades old that have been incrementally patched and upgraded over time, often with lots of customers. They decide it's time to do a rebuild onto more modern tech, but they can't justify a from-scratch rewrite unless there is a significant difference that can't just be bolted on to the existing architecture. Decentralisation is an example of such a change. By betting on blockchain tech now, they open up the possibility of totally new business arrangements in future that would have been blocked by centralisation/lock-in fears today.
If you decide to make your existing business app selectively decentralisable - perhaps in order to unlock new features or products in an environment where customers are concerned about data sharing - then it makes sense that you'd maintain one platform, run all the nodes yourself and migrate users to it in bulk. You've opened up new options for yourself and if later the business winds change and you don't want to allow this anymore, OK, you have a slightly more complex architecture than a plain old SQL DB but modern DLT systems like Corda (the one I work on) map blockchain data through to relational databases anyway so you can still use a lot of the same tools and processes that you're used to. It's not quite such a huge leap as it'd have once have been.
Why might some customers not want to be decentralised? A situation we see a lot is where a business or industry group wants to allow people to run their own nodes, but isn't sure the usability of taking part in a P2P network is high enough for everyone (or are sure it isn't). Remember that many businesses have very small or sclerotic IT departments, or no IT department at all, and peer to peer networks are historically associated with piracy, viruses, spam etc. So that + the prevalence of the web means that setting up anything that isn't HTTP to port 80, like a business P2P node, is considered to be a bit novel and exotic.
Again, because Corda is designed for large firms it has features that help with this, in particular for really large and paranoid firms like banks where the internal IT departments don't always trust each other :) But ultimately if you're trying to pull off a major platform migration, you don't want it to hit the rocks if some users reject the idea of running local infrastructure and just want an ordinary web app.
This exact problem is prevalent in the Bitcoin and Ethereum communities too. Many users don't run nodes or even SPV wallets. They just dump all their coins on an exchange and trust a centralised service completely. They could go full P2P but that involves small sacrifices like having to back up your private keys, so they choose centralised trust instead. The nice thing about cryptocurrencies is users can choose their own configuration.
As a consequence of all this, a popular feature request for Corda and something we're spending a lot of time thinking about is how to split a node up, so parts of a node run in some cloud somewhere, and other parts run locally on e.g. a mobile or desktop app. For instance private keys and transaction signing could be done locally, with everything else run remotely - this is "share the my data but not my authority". In more advanced setups you allow people to migrate from hosted nodes to local nodes and back again in smooth automated ways.
I don't think we've written much on the topic of deployment with centralised nodes before though.
Is there any software out there that I could readily adapt to provide the same properties and guarantees without incurring hundreds of hours of development and testing?
Well, yes, it would have been possible. There are a couple of minor things the blockchain does better and a couple of things it does worse for this use case, but fundamentally, I believe the blockchain based solution was cheaper to build and will be cheaper to maintain.
People need to consider these solutions in the context of whether or not they solve business problems effectively, and put aside knee jerk reactions based on technological prejudices.
By using ethereum, we didn't need to write microservices to front the database, we didn't need to configure the database (not trivial if you want serializability https://blog.dbi-services.com/oracle-serializable-is-not-ser... ), we didn't need to write any cryptography code, we don't need to run any kind of infrastructure (let alone expensive, distributed infrastructure) to allow people to interact with and update the data. We get broadcasting of changes to clients so that the UIs can be kept up to date for free too.
We do have to carefully audit our smart contracts, but they are much smaller pieces of code than the microservices and triggers that we would otherwise have written.
Mainly, because our use case was similar to the crypto-asset tracking use case, there was a lot of code we could rely on already in ethereum that we would have had to write ourselves in the RDBMS world.
By the way, did you use any historical data from the tracking? Does ethereum provide good tools to analyze that?
If you can trust the miner, why not just use a regular RDBMS? The controller is the primary/master, you just need to disallow UPDATEs and DELETEs, and to have a constraint that prevents an account from spending more than they received. The other nodes are read-only replicas.
(To the complaint that a single master doesn't scale: it should scale as well as a single miner. They're both the only writer to the database.)
I suppose I could implement my own hash-chain to verify the authenticity? (aka, no missing data)
In my country, all invoicing software must implement that (it's part of the SAF-T format that we must deliver to the IRS), and it took us less than ten lines of Ruby to do it. It's literally concatenating a few strings, then using some crypto library to hash and sign it.
Verification is just doing the same process, then checking if the signed hashes match.
But your blockchain client will know immediately if the single miner has rewritten the block chain. It won't be able to download any new blocks based on the one it current thinks is head.
So while you can't stop the miner from doing what you said, no one will be fooled when it happens.
Actually, it's much worse from an efficiency point of view. Which means that all those applications are fad-driven.
I'm sure there can be genuinely useful applications for blockchain tech, but for now the only truly compelling one I'm aware of is to execute unlawful transactions (I don't count speculating on the price - something I've done too a bit - as genuinely useful).