this post was submitted on 15 Apr 2025
1487 points (95.9% liked)
memes
14327 readers
2941 users here now
Community rules
1. Be civil
No trolling, bigotry or other insulting / annoying behaviour
2. No politics
This is non-politics community. For political memes please go to !politicalmemes@lemmy.world
3. No recent reposts
Check for reposts when posting a meme, you can only repost after 1 month
4. No bots
No bots without the express approval of the mods or the admins
5. No Spam/Ads
No advertisements or spam. This is an instance rule and the only way to live.
A collection of some classic Lemmy memes for your enjoyment
Sister communities
- !tenforward@lemmy.world : Star Trek memes, chat and shitposts
- !lemmyshitpost@lemmy.world : Lemmy Shitposts, anything and everything goes.
- !linuxmemes@lemmy.world : Linux themed memes
- !comicstrips@lemmy.world : for those who love comic stories.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
[Continued from the other reply]
Verifiability is not the same thing as trustworthiness. I believe I already said that.
Which is a long way of saying organisational solutions are needed for organisational problems like trustworthiness.
But not every Git repository that is cloned elsewhere is meant to stay identical. If anything, it's more of a federated system than a decentralised monolithic system, with each of the clones just doing their own thing.
Git repositories can work independently and local branches can do local things. Nothing in it forces everything to be committed to a "single ledger". Nothing about Git works on technically enforced "consensus". It just gives users the ability to make sure that if they choose a common branch, then they have the ability to build on that.
But nobody implements it that way. Especially the part about eliminating forks. The ability to create forks and branches in Git repositories is considered a feature.
In blockchains, they're considered undesirable, yet they happen anyway, because of bugs and users and developer meddling.
Again, you really shouldn't be going "well, this solution based on decades old technology kinda looks like blockchain if you squint a little bit."
Or you don't! Based on the above, if someone manages to build a system like that without blockchain, I'm sure you'll be there saying either "well they should have built a blockchain" or "it kinda vaguely looks like blockchain to me".
I brought it up only because you seemed concerned that privacy couldn't be achieved using blockchain
Yes, Blockchain is a bridge on the shoulders of giants, but before this bridge existed the practical implementation of an autonomous database didn't exist.
Sanity checks are very different from zk proofs. You can't sanity check to confirm that everyone is being paid the minimum wage.
That blockchain and zk removes the need for the auditors to confirm blockchain output. Only external data input requires verification.
This is the value put on blockchain data, not the integrity of the data itself.
There wasn't another fork where the hackers kept their loot. Consensus won.
This is just one example: If the on-chain contract gives permission to view the archive of a particular hash then the off-chain database encrypts the archive matching the hash with the requesters public address and makes that publicly available.
Not if the viewer can be anyone (or thing) in the world and that viewer has reason to distrust the integrity of the centralised database.
When you want to restrict access, but you don't necessarily want to define in advance who can read/write/modify (usually the latter is restricted but read is open). Usually write access is granted in exchange for cryptocurrency.
The data is immutable and highly accessible. It is also usually within an ecosystem of other similar data where synergies exist. The network effect is impossible with centralised databases.
True for read access. Not for write.
You still have authentication, but it is controlled in a decentralized manner (smart contracts) not by a centralised, possibly untrusted, entity.
The public address is known, but not the identities. A Know Your Customer type service can be performed if real world identities are essential.
This is just an array of public addresses. You can be as simple or sophisticated as you like with how you add to this.
It's decentralized access control and IDs.
Anyone can pick up a key and create their own access point, but in a manner that is integrated with everyone else's database.
We've added a database layer and a verification algorithm on top of TLS.
The key difference is the how combination of old technologies are integrated.
But just doing that you are missing the immutability and data verification side of the solution.
It's better because access is granted without having to ask permission of the database owner.
https://hbr.org/2022/01/how-walmart-canada-uses-blockchain-to-solve-supply-chain-challenges
https://toucan.earth/
https://www.energyweb.org/
https://opensc.org/
Taken independently, each component of blockchain can be implemented more efficiently in a centralised manner. Blockchain is for when you want a certain group of properties to exist concurrently.
But they don't think about accessibility or immutability. To scale across an industry you need everything.
They are now not frequent enough to be a problem.
On your own, yes.
It's the combination of properties blockchain offers cannot be achieved with traditional systems.
All the components are old but the combination is new.
If you want computation immutability and there is no centralised authority then you end up with blockchain.
In blockchain parlance a non identical clone is a fork. The consensus mechanism removes these. We agree Git is not blockchain, but I'm say that if we add enough constraints and it could be.
You brought up Git. I'm playing along with the analogy to aid your understanding.