5 ms·
I’ve said it before, and I’ll say it again: It’s because “blockchain” software is a thing that already exists, but its superclass, “distributed log of signed p
by derefr 6y ago
I’ve said it before, and I’ll say it again:
It’s because “blockchain” software is a thing that already exists, but its superclass, “distributed log of signed proofs” software, isn’t a thing that already exists (except in the form of the subclass, blockchain software.)
There are tons of use-cases for which a “distributed log of signed proofs” is the perfect fit. Have you got an architecture where nodes independently make “stuff” and want to publish it “somewhere” for other nodes to find — where the other nodes have some independent criterion they can apply to validate published “stuff” to decide whether to accept or ignore it for their own use? For example, have you got a sharded data warehouse, where each shard is publishing its own write-ahead log segments for replicas of that shard to use? Well, add a “distributed log of signed proofs”, and now your closed data warehouse becomes an open network where anyone can have their own “shard”, and anyone can choose to replicate from a “shard” they trust.
(Yes, DHTs and/or gossip networks are sort of like this — but neither provides durability or linearization. If you want a new node to be able to look up historical “stuff” from publisher-nodes that aren’t online any more, then you need durability; and if you want your “stuff” validation algorithm to — at least within a sliding window — reject duplicate “stuff” from the log, then you need linearization.)
It just so happens that all the software that exists, that offers the “distributed log of signed proofs” guarantee, also offers the additional guarantee of all the nodes doing the validation of proofs serially, reducing over each new proof against an accumulator of an existing global consensus state, to build a new global consensus state, where proofs can only be valid relative to a specific “base” global consensus state. We call such proofs-relative-to-a-state “blocks”, and we call the resulting system “a blockchain.”
Most of these use-cases don’t need that additional guarantee. It doesn’t get them anything, and it costs a lot (e.g. in the inability to concurrently validate proofs; in the requirement to keep a forever-growing durable representation of global consensus state around on disk; etc.)
But the people building these systems are generally practical engineers, who “buy” blockchain software (and just ignore the features they don’t need), rather than attempting to “build” their own “distributed log of signed proofs” software with no known antecedent.
- mumblemumble 6y agoI am coming to think that it's precisely the "distributed" bit that nobody really wants. For example, distributed version control systems are often held up as an example of some form of precedent for blockchain-type technologies. But I've never actually seen a truly distributed (in the blockchain sense) deployment of Git. It's technically possible, but it just doesn't seem to happen. Similarly, I'm not sure people actually want immutability. They want the ability to edit history, they just want it to not be an everyday thing. In a discussion about the relative merits of different distributed version control systems, someone invariably points out that the thing Git has that makes it more usable in practice than any of the others is that it allows you to rewrite history. In the repositories I manage, I even mandate it, in the form of requiring people to rebase before merging into the main branch so that we can linearize history. As salty former Mercurial user, I used to do the opposite and ban the practice, until I realized that rebasing and squashing is more practical in the long run. I'm trying to run a software project, not an episode of Hoarders.
- throwawaygh 6y agoGit is used almost exclusively in a centralized fashion. The use patterns really aren't all that different from SVN, even if having a local copy is kinda nice. But, like you said, having a local copy isn't really the same thing as decentralized. "master" is still a thing. More importantly, the next big shift in version control technology is/will be back toward centralization. You already see this with eg Google Docs. Far inferior to Word, but preferred by many because of the free and highly functional live-multi-collaborator-editing feature. Someday we'll look back and wonder why merge hell lasted so long into the age of ubiquitous gigabit internet. Not that there won't sometimes be merges, but far rarer.
- deleted 6y ago[deleted]
- dale_glass 6y agoGit is very much used in a distributed fashion. Eg, on github. Right now, I'm working on one of the forks of a dead commercial project. Our fork in turn has 61 forks right now, some of which may diverge further and have multiple people working on them, which at some point may or not contribute things upstream.
- mumblemumble 6y agoBut not in the blockchain sense. All those forks aren't independently contributing to a single source of truth in a peer-to-peer manner. In practice, those forks generally serve one of two purposes. Either they're for working separately on changes that you intend to submit upstream to the agreed-upon central repository, or you're intending to legitimately fork the project and create your own new central repository that's relatively independent of the original. Despite from the fact that, thanks to our industry's love for overloading technical jargon, we happen to use the word "distributed" to describe both use cases, they're really quite different in practice.
- dale_glass 6y ago
- TimJRobinson 6y agoScuttlebutt and GUN.eco seem to be what you're describing.