Slashdot Mirror


Why Decentralization Matters (medium.com)

Chris Dixon has an essay about the long-term promise of blockchain-based networks to upend web-based businesses such as Facebook and Twitter. He writes: When they hit the top of the S-curve, their relationships with network participants change from positive-sum to zero-sum. The easiest way to continue growing lies in extracting data from users and competing with complements over audiences and profits. Historical examples of this are Microsoft vs Netscape, Google vs Yelp, Facebook vs Zynga, and Twitter vs its 3rd-party clients. Operating systems like iOS and Android have behaved better, although still take a healthy 30% tax, reject apps for seemingly arbitrary reasons, and subsume the functionality of 3rd-party apps at will. For 3rd parties, this transition from cooperation to competition feels like a bait-and-switch. Over time, the best entrepreneurs, developers, and investors have become wary of building on top of centralized platforms. We now have decades of evidence that doing so will end in disappointment. In addition, users give up privacy, control of their data, and become vulnerable to security breaches. These problems with centralized platforms will likely become even more pronounced in the future.

1 of 93 comments (clear)

  1. Re:Ha ha right by ceoyoyo · · Score: 3, Informative

    Yup, that right there is what I mean. "Git is an scm... it has nothing to do with a blockchain...." Git is an scm, yeah. But scm is a description (and a very high level one at that) of what it does, not what it is or how it works.

    The heart of git is a tree-type data structure where every node on the tree contains a database transaction. A transaction in a generalized database framework is anything that modifies the database. In git, those transactions are changes to the documents you're tracking (the "diffs" you mentioned*). But the nodes also contain other things... your name, e-mail address etc. Oh, and two more things: each node in the git tree contains the SHA hash of the previous node, and the SHA hash of itself including the hash of the previous node. This data structure is called a hash tree, or Merkle tree. The defining characteristic of such a tree is that, because each node's hash depends on the hash of the previous node, you can't change a node, or it's connections, without changing all the downstream nodes, and the integrity of the whole thing is pretty quick to verify. Is this sounding suspiciously familiar yet?

    So back in 1991 some comp sci dudes were playing around with some ideas involving lists of records and timestamps and hashes and stuff (your spidey sense should definitely be tingling now....). A year later they wrote this paper about using Merkle trees to collect records together into blocks and make the whole thing more efficient. Then, a decade or so later, this guy Szabo cooked up an idea he called "bit gold" that was supposed to use these chains of hash-secured records as a kind of ledger, as the basis for a payment system. Fast forward another few years and somebody using the pseudonym "Satoshi Nakamoto" wrote some stuff about "block chains" (yes, whoever he was, he had a functional spacebar) and using them as a ledger system....

    Anticipating the pedants, the currently sexy implementations of block chains have a wee problem with deciding who gets to add nodes to them, a problem which (usually) isn't shared by git. So if it makes you happier, imagine that I post my github address on Slashdot and whoever guesses the password gets to make a change to the repo, at which point I change the password to something else, et cetera. And we all periodically vote about whether each other's changes are shit or not.

    * unlike other scms, git doesn't actually store diffs, it stores snapshots of changed files.