We continue to hear a lot about blockchain technology in networking, including a role for it in service lifecycle automation. Some have suggested it’s a critical technology in the latter, and while I think it could play a very useful role, I think that the value of blockchain there (as is the cases in many areas) is secondary to an architecture that directly addresses the problem.
Blockchain is a distributed mechanism for establishing the trustworthiness of something. Most people know it for the way it’s used in cryptocurrency, which is authenticating the ownership of a “cryptocoin” as a step toward accepting it from someone else. But as recent market shifts in the cryptocurrency space have shown, blockchain doesn’t make the currency worth anything. The application—in this case,the use of a cryptocoin as tender—is more than the blockchain.
Probably the best way to understand what blockchain could do in networking is to look at a broader topic where trust is an issue—electronic data interchange or EDI. The purpose of EDI was to allow electronic transactions to substitute for commercial paper,things like invoices, payment advices, orders, and so forth. I was involved for quite a while with the Data Interchange Standards Association (DISA), who formulated the EDI data models. One classic example of EDI trust was that someone thought they were ordering 10 watermelons when the seller interpreted the order as 10 truckloadsof watermelons.
The early solution to trust in EDI was to use an EDI network that acted as a transaction intermediary, receiving our watermelon order from the buyer and forwarding it to the seller. The network maintained a copy of the transaction and so would be able to establish that the order was in fact for either 10 or 10 truckloads. This process gave transactions the property of non-repudiation.
Blockchain could do the same thing without the need for that intermediary EDI network and its associated costs and security/compliance risks. A blockchained order would be immutable (as long as you don’t believe the encryption could be broken) and in fact could carry with it all the associated back-and-forth banter as well as other steps like payment, shipment, and so forth. Every step in the order/fulfillment process would be added to the chain, and the record would be authoritative.
Network services are commercial activities, and so the normal EDI-like blockchain mission could apply to them as easily as to the EDI needs of other verticals. A service order could be combined with all the steps associated with processing and fulfillment and put inside a blockchain to make it authoritative, meaning trusted and enforceable under contract. Some have suggested that this means blockchain is a necessary condition for automation of the service lifecycle because it’s necessary to represent service orders. Not so.
If you back to the days of EDI, you find something called the “bilateral agreement”, which is a contract between trading partners that describe how they exchange EDI data and establish trust. As long as the parties have a means of determining that they have a true copy of something, they can set legal policies to make that something authoritative and non-reputable. In point of fact, most commercial exchanges today happen electronically and don’t even bother with highly formalized bilateral agreements. Web transactions ask you to review and confirm, and that’s that.
The big issue I see, though, isn’t whether you need blockchained contracts but whether you have anything to process them with. That problem exists in two dimensions—the service lifecycle automation architectural model and the question of overhead.
An authoritative service order doesn’t process itself. Service lifecycle automation demands that the order be handled by software, at every stage in its processing and in the face of conditions that impact the utility of the service in such a way that remediation is required. The biggest problem that we face in service lifecycle automation is that we don’t have a broadly accepted model to do that.
The TMF had an approach (NGOSS Contract) but the resulting specification was never broadly adopted. OASIS TOSCA has been diddled to support the event-handling needed for service lifecycle automation, but the spec itself didn’t include event processing. I’m told the TMF is rethinking the whole NGOSS Contract thing, and that TOSCA is now adding event-handling to the specs. These steps could at least give us some formal models to work from, but implementations still have to be developed.
One might think that were, say, a TOSCA-modeled service order created using blockchain, we could add a layer of value to the overall service lifecycle automation process by formalizing how we created trust. Yes, but only if the result doesn’t blow the quality of handling of events, and it might.
Blockchain is a fairly high-overhead process, both in terms of the resources needed and the time required to make changes or decode the document. That overhead could complicate event processing by delaying the event’s delivery to the appropriate process. That might suggest that while blockchain could be used in the commercial exchange part of service order processing, it might be less appropriate when applied tot he “internal model” the operator uses as the basis for service lifecycle automation.
The overhead issue may also be decisive in applications of blockchain to internally generated events/transactions for the purpose of creating an audit trail. Journaling of activity is a strong piece of any security/compliance strategy, providing the journal is actually authoritative. However, the event processing can’t be inhibited by journaling delay,which a blockchain implementation could do.
To me, this adds up to a simple point, which is that to the extent to which service provider contracts and other documents are equivalent to EDI’s commercial paper, they’d be potential targets for blockchain implementation just as would be the case for other verticals’ EDI. Pan-provider services look like a good example of where blockchain could be applied, and so do services created by portals that effectively define a dynamic partnership between enterprises and operators. There might well be frequent changes to services in those situations. Elsewhere, I’m doubtful. We all know that blockchain-based EDI is far from pervasive (or even common) so it’s likely that the perceived benefits of such a shift are low in other industries. I don’t see a major reason to think service providers would find differently.
What is possible, though, is that blockchain will eventually form the basis for“service paper EDI” in the networking industry. Keep in mind, though, that EDI is an interface in its historical applications, meaning that it’s a means of passing commercial paper and not a means of recording the data those papers might contain when the usage is purely internal. That is surely going to be true with networking too, and blockchain won’t be used to encode databases or even internal events and transactions; there’s not enough value to overcome the issues of overhead.
Blockchain is not required for service lifecycle automation, or even particularly related to providing it. It could be fit into the commercial-exchange part of a service workflow, as it could be fit into other substitutions of electronic transactions for commercial paper. If we focus on realistic missions, we can avoid the now-epidemic problem of overhyping and misdirecting new technologies. We can also help service lifecycle automation focus on what’s really important there—the model.