In my previous piece on the hurdles to blockchain adoption I spoke about PKI. The main takeaway is how many of the problems purported to be solved by blockchain based technologies can just as easily be solved with public key infrastructure or just an x509 certificate, as the actual lever being used is the public/private key pair not the blockchain itself. In today’s entry we are going to look at the problem of reliability, and what the risks are in putting all your eggs into a decentralized basket. This is especially relevant today after the recent dust storm knocked a big chunk of the network offline.
First off, decentralized or distributed systems are designed as such to avoid specific failure points. It doesn’t matter if one node is down where there 100s of others exactly the same. And this is true to a degree, and a lot of the resiliency of cryptocurrencies comes from the fact that no node is critical to the system itself and if any one node or set of nodes go down the rest should keep humming along without really even noticing. However this creates its own challenges, like message coherency and ordering. You don’t inherently know if a message came to you from next door, or from next door via global circumnavigation a dozen times. Or both, one after another. You also will eventually run in the issue of simply not having a director or system owner able to correct issues or settle questions of legitimacy. All updates require consensus. Even the Chia updates require consensus, despite them being a private company in charge of the code. We, as farmers and users of the XCH coin, cannot be forced to update – merely convinced.
So how does this affect adoption? Well, it depends on what is being adopted. The strengths and weaknesses of cryptocurrencies are similar in nature to those of BitTorrent when it comes to enterprise adoption, so we can see immediately what kind of enterprises will use it first, and how. For BitTorrent the first big enterprise use case has become a meme, which is “Linux ISOs”. More explicitly though, it is large open source projects who need to distribute many gigabytes of data to users and do not have large bandwidth budgets. They happily trade control over the swarm, it will continue going after they leave in many cases, in order to leverage the other member’s bandwidth for distribution.
But for a commercial enterprise, like a bank or publicly traded company, they do not distribute data to users through BitTorrent. Even in situations where they could, and it would be cheaper, it is not a common occurrence. The reason for that is that they lose reliable control over the process, and enterprises are notorious control freaks. In terms of cryptocurrency adoption in large, conservative enterprises, reliability will be a concern in many forms. Without control over the network they put their services on, they can remain subject to things like transaction storms changing the fee structure underneath them, or disrupting the network enough to make payment finalization time many times more than expected. So even in situations where the network is technically reliable, a strength of properly distributed systems, it will not be treated as reliable to the enterprise that does not control the levers. Reliably distribute network messages? Yes. Reliably able to instantly effect change, or shut the whole thing down? No.
Because neither Chia Network nor their customers will have exclusive control over what happens on the Chia network it creates a reliability issue needs to either be solved (unlikely, as it is the nature of distributed systems) or overcome with utility. There needs to be a compelling enough reason to adopt the technology that enterprises are willing to overlook the passing of control from central authorities to the mob. And the bar is high. The rush to the cloud over the last 10 years has been all about moving control internally at the enterprise into the hands of a larger, more competent central authority. The adage about “the cloud is just someone else’s computer” is true, but the the actual expectation is that the “someone else” is better at managing computers properly than almost anyone else. With cryptocurrencies the “someone else” is literally just someone else, a random network participant that could do something like send millions of mojo around in a circle for no discernable reason whatsoever.
This is why the codename projects at Chia, Atari and Asteroids, are of such interest to me. If they have produced a product which passes the bar for reliability while running on top of a distributed system that could be very valuable to organizations. There are benefits to distributing the cost of running infrastructure, and cryptocurrency does that very well. And if they can improve the actual reliability of the distributed network via software optimization, that will help a lot too. I also think it will be worth it to someone, eventually, for someone to develop enterprise middleware for the Chia ecosystem that cuts all us dirty farmers out from being a core participant, at least from the perspective of enterprise customers. If I could guarantee that my node only connected to other trusted nodes and the rest of the network through secure proxies I would be very happy. as a CISO with services running on top of the network This will need some configuration files, some WAF rules, possibly a specifically signed set of certificates with a different root of trust. Shouldn’t be too tough, and would likely help Chia alleviate the concert some customers might have with running Full Nodes any Joe Schmo can connect to.
Reliability will come in many forms, and there are a few ways to look at it. But when developing and selling a product like the Chia Network you need to consider all of them. The Enterprise Architects at the banks and governments they are targeting certainly will.
