The whole point of the system in question was that the relevant invoice information is stored in the database.
Traditional invoicing is bilateral. You have no idea about the components that make up the end product being invoiced. Solving this is both organisational and technical.
What if they decide to sell the end product to someone else?
that company is only required to use the system to do business with the company that implemented this centralised system,
Not if you are looking further up or down the supply chain. Someone providing components will not be able to predict the final destination so will be unable to interact with the correct proprietary system.
What you want to access the database of someone else without needing read permissions?
Nothing prevents designing the centralised system in a way that information is available to parties that need it.
If access to that system can be altered at the whim of the database owner then it is unacceptable
Nothing prevents the other company adopting a policy that such invoice information is publicly available.
If information needs to be published in a public, immutable, traceable manner. Then Blockchain is the only technology that can solve this.
But nothing prevents it being tailored to all stakeholders.
If it can be altered then there is no guarantee if business for stakeholders. They will not engage.
There’s a reason why DBAs spend a lot of time thinking about primary keys and unique identifiers.
You are now describing Blockchain technology. Primary keys are held by each stakeholder and uniqueness is cryptographicly guaranteed.
Trustworthiness is, again, a thing that blockchain doesn’t solve. “Trustlessness” only guarantees data/transaction immutability,
So blockchain does solve it.
it doesn’t guarantee organisational problems like fraud (as cryptocurrency market demonstrates).
Nor was this claimed.
And if you don’t trust a company in organisational sense, why do business with them to begin with?
Because you want money. Businesses want a solution where trusting a particular organisation isn’t necessary.
The whole point of the system in question was that the relevant invoice information is stored in the database.
Traditional invoicing is bilateral. You have no idea about the components that make up the end product being invoiced. Solving this is both organisational and technical.
What you’re talking about is using technical solution to mitigate problems in the organisational level. There’s little you can do on technical level to 100% ensure that invoice information is correct and matches what is actually happening in the real world. Blockchain doesn’t solve the organisational side of this, nor does it bring anything new to the table.
What if they decide to sell the end product to someone else?
that company is only required to use the system to do business with the company that implemented this centralised system,
Not if you are looking further up or down the supply chain. Someone providing components will not be able to predict the final destination so will be unable to interact with the correct proprietary system.
If you want the entire supply chain to be covered by the system, you have to either build one giant big traditional system to manage everything, or (the blockchain variant) one giant big blockchain system to manage everything. Or - hear me out - a series of interoperable systems, which is how things generally work.
By the way, I didn’t remember this earlier on, but what do you do in cases where the supply chain is deliberately opaque? What if this information is something that companies cannot, for one reason or other, share with one another? Not necessarily a nefarious reason, but sometimes it is. There’s plenty of companies that definitely do not want to discuss where their products originated in, even internally. Walmart included, it seems.
What you want to access the database of someone else without needing read permissions?
Nothing prevents designing the centralised system in a way that information is available to parties that need it.
If access to that system can be altered at the whim of the database owner then it is unacceptable
But nothing stops them from accessing (and copying) the information while they have legitimate access to it! Nothing stops publicly available information from being mirrored either. Archival of such records is usually considered to be a good thing. Also, perhaps at this point unsurprisingly, it can be done without a blockchain.
And what do you propose happens when the blockchain just straight up isn’t accessible anymore for one reason or other? Nothing in blockchain specifically ensures this kind of longevity. All it does is say “hey, here’s some data, it can be easily copied to another node”, which isn’t special in itself. It’s the same problem as mirroring data by other means.
Nothing prevents the other company adopting a policy that such invoice information is publicly available.
If information needs to be published in a public, immutable, traceable manner. Then Blockchain is the only technology that can solve this.
Cryptographic signatures are a thing, you know. Nothing prevents people from adding signatures on publicly released documents. Ensures integrity/source. Publication can still be covered by other means.
But nothing prevents it being tailored to all stakeholders.
If it can be altered then there is no guarantee if business for stakeholders. They will not engage.
Again, hard forks in cryptocurrency world would suggest blockchain isn’t a magical solution to this problem either.
There’s a reason why DBAs spend a lot of time thinking about primary keys and unique identifiers.
You are now describing Blockchain technology. Primary keys are held by each stakeholder and uniqueness is cryptographicly guaranteed.
So you do see there’s no difference between the two things. For practical purposes it doesn’t matter one bit if you’re tracking an invoice by an invoice number or by some cryptographic hash identifier. Exactly what I was saying: blockchain doesn’t improve things one way or other here.
Trustworthiness is, again, a thing that blockchain doesn’t solve. “Trustlessness” only guarantees data/transaction immutability,
So blockchain does solve it.
Um, no, it doesn’t. Trustworthiness is a social concept, trustlessness is a technical one. Blockchain can only ensure trustlessness, it can’t ensure trustworthiness. Fraud happens outside of the technical domain. That was my point.
it doesn’t guarantee organisational problems like fraud (as cryptocurrency market demonstrates).
Nor was this claimed.
You claimed centralised systems are untrustworthy. You failed to demostrate how blockchain systems by contrast are trustworthy.
I’m just saying blockchain technology, while trustlessness, has so far failed to create a trustworthy economic platform for cryptocurrencies.
How do you propose blockchain technology can create trustworthy system of any other kind through technological means, then?
And if you don’t trust a company in organisational sense, why do business with them to begin with?
Because you want money. Businesses want a solution where trusting a particular organisation isn’t necessary.
But as the cryptocurrency market has shown, blockchain by itself cannot prevent fraud. So blockchain so far isn’t a solution for this problem, then?
What you’re talking about is using technical solution to mitigate problems in the organisational level.
No. Blockchain is for solving intraorganisational problems. I.e. How can the invoices of your suppliers be made available.
There’s little you can do on technical level to 100% ensure that invoice information is correct and matches what is actually happening in the real world.
This is known as the Oracle problem.
a series of interoperable systems, which is how things generally work.
But they don’t work, because one cannot confirm who entered or manipulated the data, or whether the data has been altered in a malicious manner.
what do you do in cases where the supply chain is deliberately opaque? What if this information is something that companies cannot, for one reason or other, share with one another?
But nothing stops them from accessing (and copying) the information while they have legitimate access to it!
True with or without blockchain.
it can be done without a blockchain.
Blockchain controls access without needing to set up authentication for all users.
And what do you propose happens when the blockchain just straight up isn’t accessible anymore for one reason or other?
If availability is important then you run your own node. You also choose a flavor of blockchain that has very little downtime.
Nothing in blockchain specifically ensures this kind of longevity.
Agreed, blockchain creates permanent immutability, it does not guarantee permanent availability.
Nothing prevents people from adding signatures on publicly released documents.
Agreed, cryptography defines ownership, hash linked lists defines immutability. The two together (with a validation engine) defines blockchain.
Ensures integrity/source. Publication can still be covered by other means.
Again, hard forks in cryptocurrency world would suggest blockchain isn’t a magical solution to this problem either.
Hard forks are not a big problem. You just choose a fork to support.
For practical purposes it doesn’t matter one bit if you’re tracking an invoice by an invoice number or by some cryptographic hash identifier.
From an internal organisational perspective, yes.
But the invoice number from company A will not match the invoice number from company B. Nor can it be seen by company A that company C provided parts to company B
From a multi organisational perspective exposing a globally unique hash tree is much more controlled and useful.
Fraud happens outside of the technical domain. That was my point.
Agreed. Blockchain immutability documents fraud, but it doesn’t mitigate it.
You claimed centralised systems are untrustworthy. You failed to demostrate how blockchain systems by contrast are trustworthy.
Centralised systems can imperceptibly alter their databases and calculation algorithms. Blockchain systems cannot.
I’m just saying blockchain technology, while trustlessness, has so far failed to create a trustworthy economic platform for cryptocurrencies.
Blockchain systems are mathematically verifiable. As a platform they are entirely trustworthy. The value people put on that trustworthiness is an entirely different subject.
But as the cryptocurrency market has shown, blockchain by itself cannot prevent fraud.
It eliminates accounting fraud. It has never claimed to eliminate all fraud.
So blockchain so far isn’t a solution for this problem, then?
What you’re talking about is using technical solutions to mitigate problems in the organisational level.
No. Blockchain is for solving intraorganisational problems. I.e. How can the invoices of your suppliers be made available.
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.
There’s little you can do on technical level to 100% ensure that invoice information is correct and matches what is actually happening in the real world.
This is known as the Oracle problem.
Yup. One of the problems blockchain doesn’t solve. Can’t fix organisational problems without organisational effort.
a series of interoperable systems, which is how things generally work.
But they don’t work, because one cannot confirm who entered or manipulated the data, or whether the data has been altered in a malicious manner.
Make logging changes a design requirement, then. Nothing stops people from documenting the changesets. Cryptographically hashed and signed, if you’re feeling paranoid.
what do you do in cases where the supply chain is deliberately opaque?
Zero Knowledge isn’t a “blockchain” solution, it’s just a cryptographical solution.
(I keep mentioning this because we’ve seen plenty of this in blockchain hype. Blockchain proponents keep raving about how blockchain fixes everything, while forgetting that the solutions they’re talking about are cryptography fundamentals that predate blockchain stuff by decades, and can be actually used much more efficiently in non-blockchain solutions.)
And, of course, it’s functionally equivalent to the company staff sanity checking things, which - let’s face it - they have to do anyway. It’s no improvement over non-zero-knowledge solution.
Never mind that this doesn’t address the opaqueness of the supply chain at all. Just because you have a trusted adjudicator doesn’t mean deliberate fraud doesn’t happen. I’d argue relying too much on technical system do the adjudication can actually sometimes be worse - “the computer says everything is good” is a great way to increase complacency about the procedure.
Any other ideas?
But nothing stops them from accessing (and copying) the information while they have legitimate access to it!
True with or without blockchain.
Precisely. So blockchain offers no advantage either way there. Glad we agree there.
it can be done without a blockchain.
Blockchain controls access without needing to set up authentication for all users.
Now that’s genuinely fascinating - exactly how does that work?
If you don’t set up any authentication for particular items, then how do you control access? Isn’t setting up access control by definition dependant on some kind of authentication? If the users aren’t identified, how is this different from the information being available publicly?
More importantly, how is this enabled by blockchain specifically? My own knowledge is mostly from public blockchains, and those obviously have no access control whatsoever, the entire ledger is public, duh.
Can you give me concrete examples of this kind of system in use?
And what do you propose happens when the blockchain just straight up isn’t accessible anymore for one reason or other?
If availability is important then you run your own node. You also choose a flavor of blockchain that has very little downtime.
This can be done much more efficiently by just mirroring the data directly. If availability is important, your average content delivery network just obliterates the throughput of all blockchain solutions in comparison. Just have the data mirrored on geographically nearest datacenter! Or the server in your closet, if you want!
Again, hard forks in cryptocurrency world would suggest blockchain isn’t a magical solution to this problem either.
Hard forks are not a big problem. You just choose a fork to support.
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?
This is why you have to actually think about what happens when actual users are using the system, sometimes with malicious intent. If the designers are immediately saying “it’s not a big problem” to some issue that has already caused big problems elsewhere, you just can’t ignore that. That warrants scrutiny. That’s salesman talk, not designer talk.
For practical purposes it doesn’t matter one bit if you’re tracking an invoice by an invoice number or by some cryptographic hash identifier.
From an internal organisational perspective, yes.
But the invoice number from company A will not match the invoice number from company B. Nor can it be seen by company A that company C provided parts to company B
From a multi organisational perspective exposing a globally unique hash tree is much more controlled and useful.
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?
Surprise, if you are actually designing a massive system, this kind of design requirements come naturally. You just identified the problem - companies A, B, and C don’t have common standard for invoice numbers. Solution: Make sure they all do that in the next iteration of the system. And you can even make that a cryptographic hash if you fancy!
Fraud happens outside of the technical domain. That was my point.
Agreed. Blockchain immutability documents fraud, but it doesn’t mitigate it.
So I take it you agree blockchain solution is not trustworthy in itself, then?
If fraud happens, then you need actual organisational level investigation anyway. If your system has the verifiability functionality, then you certainly can document fraud.
Speaking of which:
Centralised systems can imperceptibly alter their databases and calculation algorithms. Blockchain systems cannot.
Blockchain systems are mathematically verifiable. As a platform they are entirely trustworthy.
Verifiability (as part of trustlessness systems) isn’t the same thing as trustworthiness in the organisational domain. We already went through this.
Also, mathematical verifiability isn’t the same as organisational verifiability. No amount of hashing will say the contracts you’re operating on are valid at the organisational level. So you need the organisational policy to determine whether the information is trustworthy anyway.
You said that blockchain documents fraud but doesn’t mitigate it. This is correct. Blockchain system would leave a record of a mistaken or malicious entry. But it’s still going to be there at the end of the day when the problem will be sorted out at the organisational level.
By the way, again somewhat unsurprisingly, nothing stops centralised system from being verifiable and immutable. There’s one massive example of this: Git.
It coincidentally uses the same cryptographic building blocks as blockchain systems: hashes and Merkle trees. Changes are verifiable through hashes, changesets are immutable through Merkle trees. But instead of trying to build automated consensus mechanisms or access controls, ultimately, Git solves trustworthiness problem entirely differently than blockchain systems: users have to implement access control, users have to verify incoming information. All trustworthiness questions are answered at the organisational level where it belongs. Also, Git works both as a centralised system and as an interoperable system, because, again, workflows are settled at organisational level where they belong.
The value people put on that trustworthiness is an entirely different subject.
What a massive hand-wave. “Oh, this system is theoretically safe. Unless people want to actually use it. Then it kinda depends.” Or: “Oh, the actual usage of the system is out of the scope of the design.”
Blockchain advocates put way too much emphasis on the theoretical viability. People who build actual systems that actual fallible end users use tend to put more emphasis on all of the factors that go into designing the system. 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.
But as the cryptocurrency market has shown, blockchain by itself cannot prevent fraud.
It eliminates accounting fraud. It has never claimed to eliminate all fraud.
It doesn’t eliminate accounting fraud - as we just discussed, it only makes the fraud evident. Or as you said, “blockchain immutability documents fraud”. In other words, you can see if someone tried to mess with things, but it’s still up to the organisation to actually do something about it.
So blockchain so far isn’t a solution for this problem, then?
It’s an excellent solution for audits.
That’s what I’ve been trying to tell you when I said technical solutions can mitigate problems, not solve them. If the system has verifiability built in, then that’s a technical solution that helps audits. And you don’t need blockchain for that.
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.
Traditional invoicing is bilateral. You have no idea about the components that make up the end product being invoiced. Solving this is both organisational and technical.
Not if you are looking further up or down the supply chain. Someone providing components will not be able to predict the final destination so will be unable to interact with the correct proprietary system.
If access to that system can be altered at the whim of the database owner then it is unacceptable
If information needs to be published in a public, immutable, traceable manner. Then Blockchain is the only technology that can solve this.
If it can be altered then there is no guarantee if business for stakeholders. They will not engage.
You are now describing Blockchain technology. Primary keys are held by each stakeholder and uniqueness is cryptographicly guaranteed.
So blockchain does solve it.
Nor was this claimed.
Because you want money. Businesses want a solution where trusting a particular organisation isn’t necessary.
What you’re talking about is using technical solution to mitigate problems in the organisational level. There’s little you can do on technical level to 100% ensure that invoice information is correct and matches what is actually happening in the real world. Blockchain doesn’t solve the organisational side of this, nor does it bring anything new to the table.
If you want the entire supply chain to be covered by the system, you have to either build one giant big traditional system to manage everything, or (the blockchain variant) one giant big blockchain system to manage everything. Or - hear me out - a series of interoperable systems, which is how things generally work.
By the way, I didn’t remember this earlier on, but what do you do in cases where the supply chain is deliberately opaque? What if this information is something that companies cannot, for one reason or other, share with one another? Not necessarily a nefarious reason, but sometimes it is. There’s plenty of companies that definitely do not want to discuss where their products originated in, even internally. Walmart included, it seems.
But nothing stops them from accessing (and copying) the information while they have legitimate access to it! Nothing stops publicly available information from being mirrored either. Archival of such records is usually considered to be a good thing. Also, perhaps at this point unsurprisingly, it can be done without a blockchain.
And what do you propose happens when the blockchain just straight up isn’t accessible anymore for one reason or other? Nothing in blockchain specifically ensures this kind of longevity. All it does is say “hey, here’s some data, it can be easily copied to another node”, which isn’t special in itself. It’s the same problem as mirroring data by other means.
Cryptographic signatures are a thing, you know. Nothing prevents people from adding signatures on publicly released documents. Ensures integrity/source. Publication can still be covered by other means.
Again, hard forks in cryptocurrency world would suggest blockchain isn’t a magical solution to this problem either.
So you do see there’s no difference between the two things. For practical purposes it doesn’t matter one bit if you’re tracking an invoice by an invoice number or by some cryptographic hash identifier. Exactly what I was saying: blockchain doesn’t improve things one way or other here.
Um, no, it doesn’t. Trustworthiness is a social concept, trustlessness is a technical one. Blockchain can only ensure trustlessness, it can’t ensure trustworthiness. Fraud happens outside of the technical domain. That was my point.
You claimed centralised systems are untrustworthy. You failed to demostrate how blockchain systems by contrast are trustworthy.
I’m just saying blockchain technology, while trustlessness, has so far failed to create a trustworthy economic platform for cryptocurrencies.
How do you propose blockchain technology can create trustworthy system of any other kind through technological means, then?
But as the cryptocurrency market has shown, blockchain by itself cannot prevent fraud. So blockchain so far isn’t a solution for this problem, then?
No. Blockchain is for solving intraorganisational problems. I.e. How can the invoices of your suppliers be made available.
This is known as the Oracle problem.
But they don’t work, because one cannot confirm who entered or manipulated the data, or whether the data has been altered in a malicious manner.
This is where Zero Knowledge is used. A trusted third party © certifies some data as correct (I.e. a birthday) then the supplier can then create a proof that all their employees are over 18 as certified by © but the actual ages are not disclosed.
True with or without blockchain.
Blockchain controls access without needing to set up authentication for all users.
If availability is important then you run your own node. You also choose a flavor of blockchain that has very little downtime.
Agreed, blockchain creates permanent immutability, it does not guarantee permanent availability.
Agreed, cryptography defines ownership, hash linked lists defines immutability. The two together (with a validation engine) defines blockchain.
Ensures integrity/source. Publication can still be covered by other means.
Hard forks are not a big problem. You just choose a fork to support.
From an internal organisational perspective, yes.
But the invoice number from company A will not match the invoice number from company B. Nor can it be seen by company A that company C provided parts to company B
From a multi organisational perspective exposing a globally unique hash tree is much more controlled and useful.
Agreed. Blockchain immutability documents fraud, but it doesn’t mitigate it.
Centralised systems can imperceptibly alter their databases and calculation algorithms. Blockchain systems cannot.
Blockchain systems are mathematically verifiable. As a platform they are entirely trustworthy. The value people put on that trustworthiness is an entirely different subject.
It eliminates accounting fraud. It has never claimed to eliminate all fraud.
It’s an excellent solution for audits.
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.
Yup. One of the problems blockchain doesn’t solve. Can’t fix organisational problems without organisational effort.
Make logging changes a design requirement, then. Nothing stops people from documenting the changesets. Cryptographically hashed and signed, if you’re feeling paranoid.
Zero Knowledge isn’t a “blockchain” solution, it’s just a cryptographical solution.
(I keep mentioning this because we’ve seen plenty of this in blockchain hype. Blockchain proponents keep raving about how blockchain fixes everything, while forgetting that the solutions they’re talking about are cryptography fundamentals that predate blockchain stuff by decades, and can be actually used much more efficiently in non-blockchain solutions.)
And, of course, it’s functionally equivalent to the company staff sanity checking things, which - let’s face it - they have to do anyway. It’s no improvement over non-zero-knowledge solution.
Never mind that this doesn’t address the opaqueness of the supply chain at all. Just because you have a trusted adjudicator doesn’t mean deliberate fraud doesn’t happen. I’d argue relying too much on technical system do the adjudication can actually sometimes be worse - “the computer says everything is good” is a great way to increase complacency about the procedure.
Any other ideas?
Precisely. So blockchain offers no advantage either way there. Glad we agree there.
Now that’s genuinely fascinating - exactly how does that work?
If you don’t set up any authentication for particular items, then how do you control access? Isn’t setting up access control by definition dependant on some kind of authentication? If the users aren’t identified, how is this different from the information being available publicly?
More importantly, how is this enabled by blockchain specifically? My own knowledge is mostly from public blockchains, and those obviously have no access control whatsoever, the entire ledger is public, duh.
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. If availability is important, your average content delivery network just obliterates the throughput of all blockchain solutions in comparison. Just have the data mirrored on geographically nearest datacenter! Or the server in your closet, if you want!
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?
This is why you have to actually think about what happens when actual users are using the system, sometimes with malicious intent. If the designers are immediately saying “it’s not a big problem” to some issue that has already caused big problems elsewhere, you just can’t ignore that. That warrants scrutiny. That’s salesman talk, not designer talk.
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?
Surprise, if you are actually designing a massive system, this kind of design requirements come naturally. You just identified the problem - companies A, B, and C don’t have common standard for invoice numbers. Solution: Make sure they all do that in the next iteration of the system. And you can even make that a cryptographic hash if you fancy!
So I take it you agree blockchain solution is not trustworthy in itself, then?
If fraud happens, then you need actual organisational level investigation anyway. If your system has the verifiability functionality, then you certainly can document fraud.
Speaking of which:
Verifiability (as part of trustlessness systems) isn’t the same thing as trustworthiness in the organisational domain. We already went through this.
Also, mathematical verifiability isn’t the same as organisational verifiability. No amount of hashing will say the contracts you’re operating on are valid at the organisational level. So you need the organisational policy to determine whether the information is trustworthy anyway.
You said that blockchain documents fraud but doesn’t mitigate it. This is correct. Blockchain system would leave a record of a mistaken or malicious entry. But it’s still going to be there at the end of the day when the problem will be sorted out at the organisational level.
By the way, again somewhat unsurprisingly, nothing stops centralised system from being verifiable and immutable. There’s one massive example of this: Git.
It coincidentally uses the same cryptographic building blocks as blockchain systems: hashes and Merkle trees. Changes are verifiable through hashes, changesets are immutable through Merkle trees. But instead of trying to build automated consensus mechanisms or access controls, ultimately, Git solves trustworthiness problem entirely differently than blockchain systems: users have to implement access control, users have to verify incoming information. All trustworthiness questions are answered at the organisational level where it belongs. Also, Git works both as a centralised system and as an interoperable system, because, again, workflows are settled at organisational level where they belong.
What a massive hand-wave. “Oh, this system is theoretically safe. Unless people want to actually use it. Then it kinda depends.” Or: “Oh, the actual usage of the system is out of the scope of the design.”
Blockchain advocates put way too much emphasis on the theoretical viability. People who build actual systems that actual fallible end users use tend to put more emphasis on all of the factors that go into designing the system. 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.
It doesn’t eliminate accounting fraud - as we just discussed, it only makes the fraud evident. Or as you said, “blockchain immutability documents fraud”. In other words, you can see if someone tried to mess with things, but it’s still up to the organisation to actually do something about it.
That’s what I’ve been trying to tell you when I said technical solutions can mitigate problems, not solve them. If the system has verifiability built in, then that’s a technical solution that helps audits. And you don’t need blockchain for that.
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.