But it doesn’t solve these problems. It’s one thing to say that maybe blockchain can give you tools to facilitate intraorganisational problem-solving. It’s entirely another to say that it solves the problem. That’s salesman talk, not system designer talk.
Now it’s the English language you are picking a fight with? I will happily state that
Excel solves my accounting problems.
Make logging changes a design requirement, then. Nothing stops people from documenting the changesets. Cryptographically hashed and signed, if you’re feeling paranoid.
Add in verification of changes according ru a strict set of rules and you have reinvented blockchain.
Zero Knowledge isn’t a “blockchain” solution, it’s just a cryptographical solution.
It is blockchain compatible. Essential for most layer 2 blockchains. Anyway I only introduced it because you asked about privacy.
the solutions they’re talking about are cryptography fundamentals that predate blockchain stuff by decades
But it took decades for someone to realize that these technologies could be covid combined. Neural networks were first proposed in 1944
And, of course, it’s functionally equivalent to the company staff sanity checking things
Not at all. The proof is entirely separate from the underlying data.
Just because you have a trusted adjudicator doesn’t mean deliberate fraud doesn’t happen.
It’s game theory. The only thing an auditor really sells is their reputation.
If you don’t set up any authentication for particular items, then how do you control access?
Pre defined rules set by smart contracts.
Isn’t setting up access control by definition dependant on some kind of authentication?
No. You don’t necessarily need to know anything about whoever is interacting with your blockchain.
If the users aren’t identified, how is this different from the information being available publicly?
Because the information is limited to a subset of users, who’s identity is not needed.
More importantly, how is this enabled by blockchain specifically?
Via private keys and hashed data.
public blockchains obviously have no access control whatsoever, the entire ledger is public, duh.
Smart contracts control access on a case by case basis. Only the hash of the data is registered on the blockchain.
Can you give me concrete examples of this kind of system in use?
This can be done much more efficiently by just mirroring the data directly.
That’s exactly what each full node does. The node also checks that the current state is coherent which is a stronger requirement than a database mirror.
So if you regret signing a contract in this fancy supply chain blockchain, you can just choose a new fork to support, one without this contract?
No. Consensus mechanisms usually make this prohibitively expensive to do, even in the short term.
Umm, how is this different from enacting a policy that states that invoice numbers have to be globally unique and have to follow a certain format?
Because that policy has to be enforced in an immutable, attributable way by a group of actors that don’t trust each other.
Surprise, if you are actually designing a massive system, this kind of design requirements come naturally.
You are so close. The natural design limit of this massive database/computational system with common standards where no single actor has control, is a blockchain.
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.
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.
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.
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.
You have to consider the ways people can break the system. You have to address organisational problems. You can’t handwave it away as being out of the scope.
Again. You are so close. 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.
.
It doesn’t eliminate accounting fraud - as we just discussed, it only makes the fraud evident.
The block calculations (the accounts) are transparent and verified by all nodes. Accounting fraud is impossible.
If the system has verifiability built in, then that’s a technical solution that helps audits. And you don’t need blockchain for that.
If you want a technical solution to scale across multiple untrustworthy entities, that has verifiability, immutability, accessibility and transparency, then you will end up designing a blockchain.
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”.
Now it’s the English language you are picking a fight with? I will happily state that Excel solves my accounting problems.
Add in verification of changes according ru a strict set of rules and you have reinvented blockchain.
It is blockchain compatible. Essential for most layer 2 blockchains. Anyway I only introduced it because you asked about privacy.
But it took decades for someone to realize that these technologies could be covid combined. Neural networks were first proposed in 1944
Not at all. The proof is entirely separate from the underlying data.
It’s game theory. The only thing an auditor really sells is their reputation.
Pre defined rules set by smart contracts.
No. You don’t necessarily need to know anything about whoever is interacting with your blockchain.
Because the information is limited to a subset of users, who’s identity is not needed.
Via private keys and hashed data.
Smart contracts control access on a case by case basis. Only the hash of the data is registered on the blockchain.
https://en.wikipedia.org/wiki/Commitment_scheme
That’s exactly what each full node does. The node also checks that the current state is coherent which is a stronger requirement than a database mirror.
No. Consensus mechanisms usually make this prohibitively expensive to do, even in the short term.
Because that policy has to be enforced in an immutable, attributable way by a group of actors that don’t trust each other.
You are so close. The natural design limit of this massive database/computational system with common standards where no single actor has control, is a blockchain.
Data internal to the blockchain is 100% trustworthy, otherwise new blocks could not be verified.
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.
Git is decentralized. Everyone has a copy.
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.
Again. You are so close. 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. .
The block calculations (the accounts) are transparent and verified by all nodes. Accounting fraud is impossible.
If you want a technical solution to scale across multiple untrustworthy entities, that has verifiability, immutability, accessibility and transparency, then you will end up designing a blockchain.
[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”.