Re: Blockchain and Networking

[Christopher Morrow <morrowc.lists () gmail com>]

(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