It is a poor idea to use blockchain for government registries. If you want transparency, simply publish signed daily updates and that's enough. Just use simple DB with backups, and optionally, a printer printing changes on a paper.
Also, SQL database is much more convenient to use, it has query language and indices unlike a blockchain.
Yes, if you have a centralized model you don't need it. Just saying that this incident is the exact risk a blockchain is meant to mitigate through redundancy. You can say you don't care about this risk, but it doesn't change the truth of the statement.
Now you may argue "that is a blockchain, not every blockchain is associated with a shitcoin" but to be frank that ship has sailed, if you wanted to defend that you'd have had to do a lot more work over the past decade.
What do you mean by "More Work" here?
There were plenty of tests and pilots of systems like that described. Dual goals of reducing the cost of transferring property and publicly attesting all current ownership. Real lawyers and real lawmakers developed proposals to integrate these sort of services with current public land registries.
The issue as far as I see it isnt the "work" its the "antiwork". If you want to learn about land sale nft pilots you literally have to put -metaverse into the google search to weed out the metaverse nonsense. Theres just too much noise around blockchain for even the best signal to penetrate. The stupid monkey nft guys really fucked the whole space. Probably take another decade to dig out all the toxic waste from blockchains reputation.
A blockchain is essentially that, just with the daily update that's being signed also including the signature and hash of the previous day.
Blockchain as a technology is actually useful here. It does not mean automatically that blocks have to be mined by third parties, although pseudocurrencies have gone that route for decentralization reasons.
depends on configuration, you can make any traditional web service replicated (replication is one and only thing that protects data in decentralized ledger, same as DNA is stored in every cell) using something like CometBFT on top. Mining/PoS or VM - all optional.
Blockchain doesn't have anything esp. to do with data loss. It solves exactly one problem which is distributed double spending in accounting ledgers.
What's wrong with paper records backup up a digital record and audit trail. This all seems like a solution for a non-problem to me.
It's not. Blockchains are only eventually consistent among nodes. They're designed for synced backups among adversarial peers.
There's no reason for a government agency to use one internally. There are better ways to sync backups when the people with access to make updates are also authorized to do so.
A git repo with cryptographically signed commits solves all the same problems without the headache.
If your proposal is 'something like git, with a few modifications to make it suitable for this use case', then that's exactly what I'm proposing. What you will need, once you've considered all requirements to the best extent feasible, will be a blockchain. Eg you do need the ability to make protocol updates, no matter the time scale of transactions.
Firstly, git does not use MD5. It uses SHA1.
Secondly, since 2017 git has shipped with an implementation of SHA1 (sha1dc) that detects the collision attack you describe, which for this use case renders it a non-issue.
Thirdly, git supports `git init --object-format=sha256` which removes the whole issue for anyone who cares to do so.
I think git as-is solves the problem nicely. The only additional value blockchain provides is the ability for someone to point at it and say "look! A use for blockchain exists!" which isn't worth the downsides it'll bring.
Not sure if you're being deliberately obtuse here but this isn't an issue with the cadence of real estate transactions. Real estate ledgers do not need to support HFT.