(watching this thread and wondering..) On Tue, Jan 9, 2018 at 2:39 AM, Peter Kristolaitis <alter3d@alter3d.ca> wrote:
On 2018-01-08 10:19 PM, John Levine wrote:
In article <0c45eee2-ffcb-2066-1456-eb2d38075007@alter3d.ca>, Peter Kristolaitis <alter3d@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