(watching this thread and wondering..) On Tue, Jan 9, 2018 at 2:39 AM, Peter Kristolaitis <alte...@alter3d.ca> wrote:
> On 2018-01-08 10:19 PM, John Levine wrote: > >> In article <0c45eee2-ffcb-2066-1456-eb2d38075...@alter3d.ca>, >> Peter Kristolaitis <alte...@alter3d.ca> wrote: >> >>> We can build all of the above in other ways today, of course. But >>> there's certainly something to be said for a vendor-supported solution >>> that is inherent in the platform and requires no additional >>> infrastructure. ... >>> >> No additional infrastructure? Blockchains need multiple devices that >> are online and have enough storage to keep a full copy of the chain. >> > There is absolutely no reason that the networking equipment itself can't > both operate the blockchain and keep a full copy. It's a pretty good bet > that your own routers will probably be online; if not, you have bigger > problems. > > I don't know that offloading computation on already busy network devices is a win for the rest of the network though. I don't know that you want to depend on local storage on devices which could be thousands of miles away from the people who can replace the hdd/ssd/storage-item.. especially when that storage is critical to the operations of the device. It turns out it's both expensive in time and pesos to fly someone into west-africa/east-asia/china/texas to repair a device in an emergency (unplanned work). The storage requirements aren't particularly onerous. The entire Bitcoin > blockchain is around 150GB, with several orders of magnitude more > transactions (read: config changes) than you're likely to see even on a > very large network. SSDs are small enough and reliable enough now that the > physical space requirements are quite small. > > I really don't think storage is the only problem here, and 'aren't particularly onerous' overlooks a whole host of actual problems in operations with blockchains... which just using git/sccs/cvs/etc fixes for your standard configuration management concerns. All of the git/sccs/cvs/etc avoid 'lots of storage necessary on remote devices' and 'lots of compute required on remote deices'. > They make sense in an environment with multiple sophisticated parties >> that sort of but not entirely trust each other, but there aren't as >> many of those as you might think. >> > You (presumably) trust your own routers. There is absolutely no reason > that your own little network can't run your own private blockchain. In > fact, for my use case of configuration management, you wouldn't WANT to use > a single global public blockchain. > > someone 12 messages back asked: "why is this better/different/etc from just using git/sccs/cvs/etc for configuration management/revision-control?" I've not seen that answered, except by the speculative: "well, it's a cool buzzword" comment. > - Peter >
