this post was submitted on 15 Apr 2025
1487 points (95.9% liked)

memes

14327 readers
2941 users here now

Community rules

1. Be civilNo trolling, bigotry or other insulting / annoying behaviour

2. No politicsThis is non-politics community. For political memes please go to !politicalmemes@lemmy.world

3. No recent repostsCheck for reposts when posting a meme, you can only repost after 1 month

4. No botsNo bots without the express approval of the mods or the admins

5. No Spam/AdsNo 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

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] umbraroze@slrpnk.net 1 points 3 days ago (1 children)

[Continued from the other reply]

So I take it you agree blockchain solution is not trustworthy in itself, then?

Data internal to the blockchain is 100% trustworthy, otherwise new blocks could not be verified.

Verifiability is not the same thing as trustworthiness. I believe I already said that.

External data added to a blockchain is transparent and traceable, but requires additional verification to be considered trustworthy. Fraud is identified by these additional non blockchain processes.

Which is a long way of saying organisational solutions are needed for organisational problems like trustworthiness.

By the way, again somewhat unsurprisingly, nothing stops centralised system from being verifiable and immutable. There's one massive example of this: Git.

Git is decentralized. Everyone has a copy.

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.

If you enforce signing of git commits and only accept data in commits that follow strict rules linked to signers public keys, and create a mechanism to eliminate forks, then you have a blockchain.

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."

Follow this thinking to its logical conclusion for an industry wide database/computer where actors can join at will, and you will end up designing a blockchain.

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".

Zero Knowledge is not inherently a blockchain advantage and blockchain doesn't help or hinder this any way.

I brought it up only because you seemed concerned that privacy couldn't be achieved using blockchain

invention of blockchain was little more than an interesting chapter in the big history book of cryptography.

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.

But company employees sanity checking the business data is also separate from the underlying data.

Sanity checks are very different from zk proofs. You can't sanity check to confirm that everyone is being paid the minimum wage.

They can hire independent auditors if something really fishy is going on. What are you getting at?

That blockchain and zk removes the need for the auditors to confirm blockchain output. Only external data input requires verification.

As we have seen from cryptocurrencies, people are perfectly willing to sacrifice their integrity and abscond with ridiculous amounts of money.

This is the value put on blockchain data, not the integrity of the data itself.

Need I remind you what happened with The DAO and Ethereum in 2016? Someone messed with the blockchain, so the blockchain developers messed people back?

There wasn't another fork where the hackers kept their loot. Consensus won.

But smart contracts are just software (running on mining nodes) operating on data (in the blockchain). How do you control the access to the data?

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.

And can't this be implemented more efficiently on centralised services anyway?

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.

So why set up access control then? If you don't care about who is interacting with the system, why have access control? If you actually do care who has access to the information after all, how do you do that without authenticating?

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.

And in what sense is this different from traditional publishing systems?

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.

If the information is available publicly, then it doesn't matter to the publisher who is accessing it?

True for read access. Not for write.

But how do you limit the information to a subset of users without authentication?

You still have authentication, but it is controlled in a decentralized manner (smart contracts) not by a centralised, possibly untrusted, entity.

If their identities are not verified, how do you know how to limit that information to that set of users?

The public address is known, but not the identities. A Know Your Customer type service can be performed if real world identities are essential.

How do you create an "user group" without specifying who the users in the group are?

This is just an array of public addresses. You can be as simple or sophisticated as you like with how you add to this.

...If the users in fact do have keys, then that's just access control and user identities, isn't it?

It's decentralized access control and IDs.

You can't issue people keys without knowing who they are, right?

Anyone can pick up a key and create their own access point, but in a manner that is integrated with everyone else's database.

You've invented TLS from ground up.

We've added a database layer and a verification algorithm on top of TLS.

Blockchain proponents reinventing old cryptography concepts and calling it a blockchain revolution really isn't surprising.

The key difference is the how combination of old technologies are integrated.

Nothing stops people from using private keys and hashed data on non-blockchain systems. That's just bog standard identity management.

But just doing that you are missing the immutability and data verification side of the solution.

Smart contracts are just software that have distributed execution on the mining nodes. They don't inherently implement access control any better than software that is run on the servers elsewhere.

It's better because access is granted without having to ask permission of the database owner.

concrete examples of a system in use.

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/

Yes, exactly! Except less efficient, like I said.

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.

Modern distributed database folks spend quite a lot of time thinking about ensuring consistency and working on efficiency. So do people who build centralised databases.

But they don't think about accessibility or immutability. To scale across an industry you need everything.

Are the hard forks not a big problem

They are now not frequent enough to be a problem.

is forking in fact prohibitively expensive to do?

On your own, yes.

You know what, we're going in circles. I try to get to the bottom of why something blockchain related can't be done with traditional systems.

It's the combination of properties blockchain offers cannot be achieved with traditional systems.

Your problem is that you think you have something new here. It's not.

All the components are old but the combination is new.

There's nothing "natural" about ending up with a blockchain.

If you want computation immutability and there is no centralised authority then you end up with blockchain.

not every Git repository that is cloned elsewhere is meant to stay identical. Nothing in it forces everything to be committed to a "single ledger".

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.

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."

You brought up Git. I'm playing along with the analogy to aid your understanding.