"but projects like the State of California’s effort to put auto registration on a blockchain are likely to simplify the painful process of dealing with the Department of Motor Vehicles."
This is one of the most outrageously ridiculous sentence fragments I've ever read in my entire life. Just utterly deranged. Like literally what could blockchain offer the California DMV that a centralized database could not?
I have to agree, and on top of everything i deem this a straight up wishful reversal of the likely outcome:
Vehicle registration is governed by a central authority _by law_, not by technical necessity.
Therefore blockchaining-up the storage of registrations themselves will likely do very little to remove the need to deal with the responsible department -- it might rather make dealing with the DMV _much worse_ since they'll not have full authority over their records anymore, while third parties might be able to interface with them however they see fit, yet with no official communication channels with the department and zero authority over the actual legal side of registrations.
And even if they do keep full control over the nodes & contracts and just make it "Blockchain" for the buzzwords sake, the immutable nature of those records could very well end up being of little more use than having a persistent "paper trail", yet make it an absolute nightmare to correct human errors if the tech isn't implemented very carefully, and if personnel isn't very well versed in handling this new system.
At the very best, it could give retail more accessible ways of handling registrations directly on sale, but that'd still mandate a huge additional support and oversight effort by the department and might easily result in a much worse shitshow than current bureaucratic issues could ever be.
Imo it can be useful for authenticating records, especially in a global context where you might not have access to any local authentication routes.
Like if you’re hiring a remote worker who went to college in some small Bangladeshi university, it’s not straightforward to authenticate their degrees. If the record was somehow on the blockchain, you could authenticate it even if there was no local infrastructure in Bangladesh to route your authentication demands.
The thing that struck me is that, besides that deranged sentence, the author comes off as quite reasonable. He said he was an early believer in crypto and blockchains, but he doesn't deny all the crazy bad shit that has gone on with crypto.
So the fact that one of the best examples he can think of to defend the utility of blockchain is this deranged sentence just shows how hard it is for people to give up on things that they've invested a lot of their personal belief in. There is just "no there there", but it will take a long time for folks to realize it.
A peer-to-peer decentralised network of database nodes which is "immutable" only insofar as a peer cannot afford to outspend the network... is useful for what ?
The only use-case identified so far is defeating state regulation of finance, ie., crime.
It's not the compute, which is abitarily centralised. It's not the code. It's not the interpretation of the data. It's the consensus of which dataset is the valid one. That "consensus" is dependent on the nodes which form it being honest and not being outspent.
That's kinda insane right? Why make which version of a dataset is the right one dependent on adversarial peers with malign economic incentives?
Oh right, because you're trying to brute force your way to an alternative economic system. That's the only use case of this mixture of technological absurdities -- and it's a dumb one which will disappear on contact with regulatory oversight.
Blockchains distributed consensus model *is* based on contingent economic incentives. This isnt a "technology" is a peer-to-peer data validation network which works only insofar as it can bribe its participants.
I struggle to find examples that "require" decentralized workflows. Money seems like the most successful example, although cryptocurrecy works worse than fiat in practice for most use cases.
CA DMV records? Loyalty programs? What's wrong with a database? What's the requirement for decentralized workflows?
> I struggle to find examples that "require" decentralized workflows
Storing factoids that (1) can't be repudiated by anyone (including the initial reporter), (2) can support attestations in the future (I can prove to anyone that I bought something years ago without showing the thing or making myself known), and (3) can only be deanonymized if and when the user wants it to happen.
These all sound very cool, but they still sound like solutions in search of problems.
1 - Non-repudiation can be done with cryptographic signatures. Storing signed data doesn't require a blockchain. I think the major improvement is related to time-stamping, although there's lots of prior work there.
2 - When would someone ever need to prove this? If you can't prove the "what" or the "who", how is this useful?
3 - For Bitcoin, no, there's lots of tools to de-anonymize users. For others, I think that's true, but what's the use case beyond money laundering?
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.
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.
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.
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.
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.
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.
If you think carefully about how consensus between people is resolved, you'll realise an immutable append-only ledger makes that process harder, not easier.
Digital signatures can be added to any piece of data: add a column to a database. It's a catastrophe to make a private key a requirement of adding to a ledger, since in practice, people lose/steal/etc. them.
Yes, you can add digital signatures to any kind of data. Basic REST doesn't do this however, so already we're beyond what it does.
Now think it through some more: with what certificate is that signature associated? You need some sort of PKI that's built to a level that can replace wet ink signatures in all business transactions. What bytes are signed? You need some agreement on serialization because you can't actually sign a database column unless it's just a byte array. Now how do you get that signature to people? It has to stay associated with the data as it moves around, which it won't do it if it's just sitting in a database column, so you need some protocol to ensure it gets to the right place at the right time. But transactions are ultimately performed between people, or legal identities, not IP addresses, so you need a way to map those. Domain names aren't it because they don't represent e.g. sub-departments, subsidiaries, individual employees, so you need a naming service that reflects organizational structures in a less ad-hoc way.
Finally, what happens if two users click "Submit" near simultaneously on two conflicting edits? You need some way to resolve the conflict, but recall, these are peer institutions. There isn't one that's the authority and one that's not. That's the whole problem we're trying to solve. So you need some sort of consensus algorithm that can resolve transactions that conflict, which reflects the peer to peer nature of the underlying business relationships.
By the time you've built all of that + lots more, you've got an enterprise blockchain platform. Does it actually contain blocks? Well, the one I designed didn't actually, and sometimes we didn't even call it a blockchain at all. But that's the terminology the business world settled on for this type of system.
So a service-oriented architecture with digital signing. It seems this is just being rebranded "enterprise blockchain", presumably because CEOs have heard they should have one.
The need for "consensus" in distributed systems has been established for decades -- today whether via Kafka, Enterprise Buses, APIs, etc. Many of these systems are already cryptographically secure.
But blockchain isnt a solution to any kind of distributed consensus across a database network; nor any kind of security problem.
Blockchain "solves" only the problem where the compute-and-store nodes of that distributed system are incentivised to be adversarial at the data-transmission level; ie., to lie about what data theyve seen. If you don't have that problem, a blockchain isn't a solution.
In the case of land records, medical records -- whatever you care to mention, a node sending false information would break the law. A person lying to the blockchain would break the law.
The problem of reconciling data across businesses with misaligned incentives is the heart of what's today called "data engineering". Businesses build APIs around their data systems, and insofar as they choose to integrate it's because their incentives are aligned to do so.
The reason business do not integrate is because they don't want to.
There is no case here where multiple stakeholders will both share data and be adversarial at the data-transmission level.
If several parties are inclined to lie, then those lies will go into the blockchain verbatim. The blockchain solves data-transmission consensus, *NOT* data-interpretation consensus. That requires law, contracts, and so on.
See, for example, NFTs. An NFT is not a transfer of any rights whatsoever, it's a group of scammers cosplaying a legal system. It's a database whose entires are meaningless -- theyre urls.
Likewise, if you think clearly about all these alledged use cases you'll find its people lying about what "consensus" means in BC, what "decentarlisation" means, etc. OR simply extremely misinformed.
Problems of social consensus are not solvable by adding to your database system 100s of nodes presumed to be liars. Problems of social centralised are made worse by this system. Problems of social trust are made worse by this system.
Adversarial, irreversal, peer-to-peer, "mega infrastructure", multi-node, etc. etc. systems fuck trust; they fuck decentralisation; and they fuck their users.
When social census, trust, cooperation, and centralisation are "at issue", the "failure modes" lie with people: they forget, they lose, they want to lie at the level of the interpretation of the data, they are scammed, they are careless -- etc.
Systems which solve "human failure modes" look nothing like blockchains -- BCs make solving those problems harder.
This is why the area is one huge series of scams. The technology itself create spontaneous systems of mutual exploitation.
Unless you just mean "enterprise SoA with digital signing" -- then the issue is that's not what "blockchain" means.
To the extent that this is an accurate characterization of the status quo, its a social problem, not a technological one. No amount of technology will save us from power and its abuse and, in fact, the idea that technology will save us from the problem of building and participating in a just society is, in my opinion, part of the spectacle that keeps us docile in the face of power.
That is a social problem you solve with social solutions - progressive taxes, UBI, comprehensive safety nets, etc.
Silicon valley has this perverted obsession with applying technological solutions to societal issues. They have phenomenal hammers, but not everything is a nail.
Your response here, and a lot of the supportive responses to it, highlight what I find so aggravating about the crypto/blockchain community: no explicit, discrete examples, just a lot of hand wavy "oh, it takes a lot of work but when it comes you'll know it!!" wishful thinking. Top that off with the common (you aren't doing this BTW but I see it all over HN) "See how the HN hivemind just hates crypto!" whenever sceptics ask for explicit, unambiguous details on the utility of the technology.
I'll play devil's advocate, because I do actually think there is one place blockchain could be useful: as a backend settlement layer for financial institutions. If you ever get into things like banking or credit cards, you'll find that our current settlement technology is kind of insane - it's basically a digitization of paper file driven processes from 70 years ago. Things like big clearing houses are largely necessary as a result of these processes, and I could see blockchain obviating some of that.
Even then, though, it takes blockchain from being this "changing the world technology" to a relatively minor efficiency improvement. I also still wouldn't bet on it, because even though the existing system is complicated and crazy, it still works, and it's not totally clear to me that existing players have enough incentives to actually change the system.
There's been a few examples of use cases said by others in this thread, and your financial settlement use case is a great one. Any time you need to move money around multiple parties based on a clear set of rules or criteria, blockchain could be useful. Insurance claims, international remittances, lending, to name a few. Anywhere a valuable process is still dominated by paper (and there are surprisingly many).
Generally, being able to program the management of money (i.e. if personA meets a certain criteria, send $X to personA) in a transparent system can be incredibly powerful.
Man, blockchain tech is falling so far behind on the user experience front that it’s not even funny.
There was a bug on Sushiswap, a few days back, that required revoking access to the contract for each token.
To do that, you had to first somehow find the exact contract, find it on Etherscan, give it “write” access from your wallet, then revoke access to each token one by one from your wallet.
This process has literally not changed in 3 years. Metamask is almost 100% the same as it was in 2020.
All that money and dev energy is going into building increasingly esoteric DeFi ponzis. None of them want to fix the actual problem of bringing more users.
Total active crypto users outside of exchanges is in the tens of thousands at most.
I can maybe see some "chain of custody" type stuff for vehicle titles and transfers. But, of course, regular old cryptographic signing into a regular ledger works for that.
They can. There's presumably some value in things like digitally signing odometer entries, titles marked as salvage, etc, from dealerships to discourage meddling. It's an area where corruption/fraud has been around a long time.
Edit: Note that I never pitched a blockchain. I mentioned digitally signed entries in a regular ledger would work.
And I'm not saying signing is a panacea. Just adds some accountability that either the key owner made the entry, or lost control of their key. So it shores up historical holes like bribing an underpaid DMV employee to doctor your title.
How does a decentralized system emerge to solve this? Crypto currencies reward the network with tokens self-contained within the network. What would be given to the public to run this network?
Also tying the state of physical reality with a digital ledger is...nearly impossible without simply granting authority to a central player to dictate what the truth state is. How can a blockchain guarantee what is written into it comports with the state of the physical world (which exists separate from it?).
This can sort of be done centrally, but then you have to trust this party, at which point they should just run a more efficient regular database. But how can a decentralized network write information to this shared database? How can any of the information be verified? Even honest actors have no means of verifying what they are writing to it is true.
Think about it.. there is some odometer somewhere whose state is going to be written. How is it determined? When one reads the ledger, how can you trust what you see there matches the true state of the odometer or whatever? See how this chasm between ledger and physical reality can't really be bridged? These sovereign state matters at the end of the day require to defer to what the state says anyways. A rube goldbergian blockchain solution tacked on top solves nothing here.
I'm saying something about currencies because arguably it is the only legitimate use-case for "block chains" as popularly understood.
How is this hypothetical non-currency decentralized ledger written to? Who has rights to do so? And how does the rest of the network verify that what any individual writes to it is valid?
Open public ledgers work because they reward actors (with a currency, used and existing inside the network itself) for securing the network and validating transactions. How does a non-currency ledger reward people for running nodes? How are transactions validated..proof of work? How is consensus reached?
If one reads the ledger, how do you verify what it says matches the real state of the physical world it supposedly represents?
If you're saying this is none of these things, then why call it "block chain", vs just a permissioned database, centrally controlled?
> There's presumably some value in things like digitally signing odometer entries, titles marked as salvage, etc, from dealerships to discourage meddling. It's an area where corruption/fraud has been around a long time.
What value do you presume?
Having the odometer readings digitally signed in a blockchain database does zilch to prevent fraud. The fraud happens when the person inputs the reading.
Likewise, "titles marked as salvage . . . from dealerships to discourage meddling" -- what about blockchain discourages "meddling" over what can be done with a centralized database in the control of the state?
I've never heard of this project, so I can't speak to its implementation, however blockchain to handle DB + access api for relatively slow db operations I think is one of the rare great current blockchain use-cases. If done well it has the potential to be a piece of open-sourced infrastructure. And once it's done once well, it could be replicated to every dmv-like entity (IE almost every permit or sign-off based process) in the world. And the comparison to a state-run database, I think many of us would agree that is an area where there is plenty of room for improvement.
But this is the first I'm hearing of this project, so I'm not advocating for it specifically.
> blockchain to handle DB + access api for relatively slow db operations I think is one of the rare great current blockchain use-cases
Ok, sure, it's OK for car registration to be slow and expensive in compute terms.
But what benefit does blockchain have here? What could blockchain possibly add that a private database maintained by the state with otherwise equivalent functionality couldn't do better?
This is a textbook situation where there is a trusted third party. In fact, the state is the party whose opinion controls in this situation. It's not like people are registering cars for fun, the are doing it because it's a government requirement.
In this case, I'm saying that the state can leverage the blockchain for infrastructure and DB access/permission/security. I haven't worked in this specific space, but having a state-affiliated key signing off on a blob of data and store that on the blockchain (and using a standardized open-source front-end for state-side or citizen-side view and editing) has potential to be a much more elegant and robust solution than every state agency around the world creating it's own front and back-end.
I agree that in this case it's not about abstracting trust from centralized authority.
1. At initial rollout, I don't imagine end users would be in charge of their own keys. State-managed keys un-does some of the benefit of being on the blockchain at all, however it sets up a modularity for the future where people could choose to take their own keys.
2. The blockchain can still have similar checks for fraud. IE I'd still imagine the DMV-approved key needs to sign-off on whatever transactions normally pass through the dmv, and perhaps with in-person paperwork. Some crypto maximalists imagine a world where cars and houses are on the blockchain and there are smart-keys or something that prove ownership. That doesn't seem realistic or desirable, however smartcontracts that mimic our current checks could be a big improvement over our current state administration.
It might remove the need for the state to be involved at all, other than for litigation purposes. You’re basically saying things are fine already, which a lot of people disagree with.
Aren't CRDTs more preferable for most open source projects such as databases for ML training, weights, etc? I think blockchains have some utility in that scope (perhaps at a meta level rather than all transactions).
I would much prefer using CRDTs with ipfs/torrent (the best systems for downloading ML data) for any database rather than any centralized system.
I for one totally trust an organization that can't operate a "pick a number" machine correctly to get my official ID and driver's license right on the block chain.
A permissioned blockchain might be good for that scenario.
If each DMV office had its own read/write copy of the database and it replicated to all the others, that would be a workable answer. Each police department and maybe even every police car, could update itself asynchronously, so if a police car went out of network range it would still have a complete copy of the database. If there were 100 million registered cars and 10 kb of data per car that’s a very comfortable 1 TB of data and if each car got updated once a year that is about 10 GB a day which is a lot for a mobile plan but no trouble to update when you get back to the station.
The government blockchain projects that I'm aware of that have had some success (AFAIK. I've been away from the space for a while and was only ever peripherally involved, e.g. https://digital.gov.bc.ca/digital-trust/) it was more about having information exchange and a coherent view of information across a multitude of organizations. Not so much the cryptography, immutability, etc.
Mind you I'm actually not sure what the CA DMV would gain. It seems they're the only source of truth that matters with respect to CA residents. Title information maybe given that does move from owner to owner.
But how could title information be decentrally controlled? How would random 3rd parties running a node (and why would they do this? What would be their compensation?) be able to verify anything about the state of some thing that exists in the physical world like claim to title? How is consensus reached? If one reads the chain, how do you verify what it says is true?
All of this still requires a central authority to decide these things, so they should just manage the database themselves. The "public" would not be permitted to just write to this permisionlessly.
In what sense are they "blockchains" (as understood in the "crypto" sense) if they are not de-centrally written to? Is there proof of work? Distributed consensus? Can the public read entries from the ledger and verify something cryptographically?
Who is the arbiter of truth in private/business blockchain? Public blockchains that produce currencies reward operators of nodes with a token that is self-contained within the system. How does any of this map to private/business chains, or any other "blockchain" that is somehow mapping some truth state external to the chain into it? It seems these words are thrown around without any meaning, for marketing purposes.
It's sort of unfortunate that blockchain was ever used as a term for business distributed ledgers. The Hyperledger Foundation has a ton of material online. (As do many others.) Proof of work is not used. The ledger is typically not open to the public or only to a limited degree. There are various other consensus mechanisms depending upon the requirements.
Proponents would likely say that a public blockchain would make it easy to prove, verify ownership of <vehicle/property>, maybe even transfer it, but then so could a centralized database with a publicly accessible API. It's an modernization issue at the end of the day, not a data storage issue.
I haven't owned a car for very long. Are there ever cases where the status of a registration is in dispute? This plan essentially makes their database public, hopefully encrypted, with registrants having means to decrypt their own record. Maybe that could help in some cases.
> Like literally what could blockchain offer the California DMV that a centralized database could not?
"After attempts to restore from backups failed because backups turned out to be incorrect, DMV head had to admit that they lost some data from the centralized database after a black-hat hackers attack. 'Please go to DMV and re-register your vehicle', the head was quoted as saying, 'because you're required by law to drive in a registered vehicle'"
You say that, but it's clearly not true. Imagine all the problems of the DMV as it is now, plus dealing with a buggy blockchain app where people use malware to steal your car registration. Or, in 10 years, when you have to download and install buggy, poorly-maintained apps and figure out how they work, just to sell your car. It can definitely be worse.
This is one of the most outrageously ridiculous sentence fragments I've ever read in my entire life. Just utterly deranged. Like literally what could blockchain offer the California DMV that a centralized database could not?