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