Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)KI
Posts
0
Comments
2,945
Joined
2 yr. ago

  • 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?

    https://en.wikipedia.org/wiki/Commitment_scheme

    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.

  • 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?

    This is where Zero Knowledge is used. A trusted third party (C) 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 (C) but the actual ages are not disclosed.

    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?

    It's an excellent solution for audits.

  • if we need centralized enforcement and off-chain enforcement, anyway, what actual value does a blockchain add compared to an access-controlled database?

    Enforcement of laws and documentation of ownership are two separate functions. Blockchain does the former only if everything is digital (like money).

    Let's take licence to drive as a pure real world enforcement example. There are multiple countries so there are multiple centralised databases. Blockchain allows all those databases to be merged without needing central access control