• daltotron@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I’m stupid, can you give me a like, more clear practical example of a good use of blockchain? Cause I get the sense that a good amount of this conflict, going off that flowchart, is going to be due to the evaluation of these situations as like, not needing to arise in the first place, or maybe like, a philosophical objection to the necessity of the technology, maybe. But I think a clearer example could help with this.

      • __dev@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        Git is not a blockchain. There is no distributed ledger; no consensus algorithm.

          • __dev@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            Key word distributed ledger. Git repositories don’t talk to each other except when told to do so by users.

            I shouldn’t need to explain why an access key is not a consensus algorithm. Seriously?

            • far_university1990@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              8 months ago

              https://en.m.wikipedia.org/wiki/Distributed_ledger no need to talk automatically, only distribution necessary without single point of failure. say „synchronized“, if you mean realtime synchronized then not in git, but synchronized manually.

              https://en.m.wikipedia.org/wiki/Consensus_(computer_science) only need to determine which block to commit to database, access key do that. if meant in term of „which repo is real one“, signed commit optional feature, maybe that speak against it being blockchain because not by default.

              • __dev@lemmy.world
                link
                fedilink
                arrow-up
                1
                ·
                8 months ago

                Distributed ledger data is typically spread across multiple nodes (computational devices) on a P2P network, where each replicates and saves an identical copy of the ledger data and updates itself independently of other nodes. The primary advantage of this distributed processing pattern is the lack of a central authority, which would constitute a single point of failure. When a ledger update transaction is broadcast to the P2P network, each distributed node processes a new update transaction independently, and then collectively all working nodes use a consensus algorithm to determine the correct copy of the updated ledger. Once a consensus has been determined, all the other nodes update themselves with the latest, correct copy of the updated ledger.

                From your first link. This does not describe how git functions. Did you actually read the page?

                The consensus problem requires agreement among a number of processes (or agents) for a single data value. Some of the processes (agents) may fail or be unreliable in other ways, so consensus protocols must be fault tolerant or resilient. The processes must somehow put forth their candidate values, communicate with one another, and agree on a single consensus value.

                From your second this. Again this description does not match with git.

                You’re right in that automation is not technically required; you can build a blockchain using git by having people perform the distribution and consensus algorithms themselves. Obviously that doesn’t make git itself a blockchain in the same way it doesn’t make IP a blockchain.