6 ms·
Yes, that's true. But in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? It can be cheaper and ea
by manmanic 8y ago
Yes, that's true. But in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? It can be cheaper and easier to deploy a blockchain than to build the necessary organizational structure to run a central database. Like I said, it's niche but it happens.
- JumpCrisscross 8y ago> in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? If you're at the scale where broad co-ordination is a problem, you're at the scale where the big boys can arrange a meeting. Alternatively, if you're at a scale where someone can get everyone on a blockchain, you're at the scale to create an industry organization.
- manmanic 8y agoI'm sorry but this does not always apply in the real world. Someone getting everyone onto a blockchain is a one-time project, perhaps with an annual maintenance fee. Running an industry organization is an order of magnitude (or two) more expensive. Trusting someone to build an (open source) application is not the same as trusting them to centrally host it.
- wmf 8y agoEvery successful cryptocurrency has had protocol upgrades which require governance and I imagine private blockchains will be similar. You can't just let it run. So if you have an industry organization to perform ongoing governance of the blockchain then it is probably cheaper to have that organization run a database.
- derefr 8y agoHow about a thing that's almost-but-not-quite a blockchain? E.g. a decentralized multi-master Event Sourcing datastore. No proof-of-work, no mining, no ledger. Anyone who can connect to the network (i.e. is whitelisted) can append whatever they like, and it'll get replicated to everybody. But nobody can delete/overwrite (without losing consensus); and every event is signed by its emitter. It's just an append-only log file that happens to exist in several (geographically distant) places at once. Get the actors together to standardize a format for the messages everyone's emitting, and then make some software (one shared implementation, many different ones, doesn't matter) to parse the log stream into a point-in-time representation you can load into an analytics tool. Seems to me that that sort of technology would fit this use-case a lot more closely than an Actual Blockchain™ would.
- marcosdumay 8y ago> It's just an append-only log file that happens to exist in several (geographically distant) places at once. That's the idea. Just add a proof of causality for the transactions that span more than one peer, and you've got a blockchain.
- derefr 8y agoNo. A log file under Paxos, for example, is not a blockchain. A blockchain is a chain of blocks. A block is a persistent record of all the information required for the consensus process, which is held onto by a node after the consensus process has completed for that node. A new blockchain node bootstrap-syncs to the network by just receiving blocks at random from peers and then evaluating the consensus rules against those blocks in order to decide what its deduced copy of the "chain" shall look like. And you can never throw those blocks away (just keeping the transaction log), either, because a new peer might want to bootstrap itself from you. This is not how multi-master sync in e.g. etcd or Postgres works. In those, consensus is a process that happens between all the nodes registered to a given cluster at any point in time. Each consensus-step happens between a known, fixed set of peers (fixed for the duration of that step, that is), consuming a fixed set of data that must be the same on all peers (the database before the update), and producing a new artifact (the updated database) that should be identical on all peers. After the consensus step completes, the inputs required to re-evaluate that particular consensus step are discarded by all peers. You can't go back and "watch history" happen again. You can only know what you've got right now. But, luckily, since what you've got right now is an append-only file, you can just read it and see everything that's happened historically. It's just a logical history, though, not the history of the consensus process itself. New nodes in such a system don't re-evaluate history to "reach consensus." They just pick a bootstrap peer to trust and slave themselves to it, synchronizing until they're an exact mirror of it. But—because all the nodes in the cluster keep their state in lockstep under consensus anyway—every node that is "in consensus" is as good as any other node that is "in consensus" for bootstrapping from. (And if you happen to bootstrap from a node that is lying about being "in consensus", then you'll quickly find that you can't obey the consensus protocol with the rest of the cluster using the data you bootstrapped.) A blockchain is a very specific kind of distributed database architecture. Just having a distributed append-only database does not automatically make something a blockchain. You can have distributed append-only databases that aren't blockchains. (Heck, there's an even more trivial case: a distributed append-only database owned by one party. How do you build that? Just deploy a master and some read-replicas, and tell the master to be append-only by policy! It should be pretty obvious, I hope, that that is not a blockchain.)
- mrtksn 8y agoCan you please give a more specific example to illustrate the case? From my perspective, blockchains are suitable for two things: People who want to misbehave(therefore they don't have legal recourse, independent of the morality of the extralegal actions) and people at war with each other that still need to have a relationship with each other. It's kind of the perfect technology for a collapsed civilization or the revolutionaries and criminals in the current world order.
- wmf 8y agopeople at war with each other that still need to have a relationship with each other So Wall Street banks?
- mrtksn 8y agoNo, not really :) More like Iran and Israel when they want to resolve a difficult situation in Syria where fighting is not preferred by both of the parties but they don't have a trusted 3rd party to handle the orderly resolution.
- spookthesunset 8y ago> But in some cases an industry mutual doesn't exist, and the regulator doesn't want to manage the database. Then what? Then you have a people & process problem, not a technical one. The Blockchain, A Real Database™ or even a CSV file won't solve your problems here.
- 6nf 8y ago> it's niche but it happens. Do you have an actual example?