Comments Off on Blockchain Interoperability & Survivability

Blockchain Interoperability & Survivability

Part 2: How Interoperability is Key to Survivability

The idea that a blockchain network can withstand a concerted attack simply because it consists of physically distributed nodes appears to be an untested and unproven proposition. We have not yet seen the extent of attacks possible on blockchain networks. Attacks can range from classic network-level attacks (e.g. network partitions; denial of services; etc.) to more sophisticated attacks targeting the particular constructs (e.g. consensus implementation), to targeting specific implementations of mining nodes (e.g. code vulnerabilities; viruses).

In the design of the Internet architecture, survivability was the most important goal of the Internet, especially if it was to be the blueprint for military packet switched communications facilities. It’s important to remember that the IP Internet was conceived in the late 1960s, with the backdrop of the Cold War.

Survivability here meant that if two entities are communicating over the Internet, and some failure causes the Internet to be temporarily disrupted and reconfigured to reconstitute the service, then the entities communicating should be able to continue without having to reestablish or reset the high level state of their conversation. Therefore, to achieve this goal, the state information which describes the on-going conversation must be protected. But more importantly, in practice this explicitly meant that it is acceptable to lose the state information associated with an entity if, at the same time, the entity itself is lost. This notion of state of conversation is core to the end-to-end principle. The best-effort delivery of IP datagrams in the connectionless-oriented model achieves this overall reliability and the survivability of the IP network.

For blockchain networks today, we can re-interpret the term “survivability” in the sense of the completion of an application-level transaction. Completion here means from its transmission by an end-user application (or by a smart contract on an origin blockchain) to its confirmation on a single blockchain network or across multiple blockchain networks. The application-level transaction may be composed of multiple ledger-level transactions (sub-transaction) and which may be intended for multiple distinct blockchain systems (e.g. sub-transaction for asset transfer, simultaneously with sub-transaction for payments and sub-transaction for taxes). Thus, comparing the IP routing paradigm, the notion of packets routing through multiple domains being opaque to the communications application (e.g. email application, browser) can be re-cast to the notion of sub-transactions confirmed on a spread of blockchain systems being opaque to the user application.

In the blockchain case reliability and “best effort delivery” becomes the challenge of ensuring that an application-level transaction is completed within “best reasonable time”, possibly independent of the actual blockchains where different ledger-level sub-transactions are completed and confirmed. The notion of “connectionless” here means that in a two party application-level engagement both parties should not care which specific blockchain systems confirmed their sub-transaction, so long as all confirmed sub-transactions add up to a confirmed application-level transaction.

This challenge brings forth a number of interesting functions which echo those posed in the early days of the Internet architecture development:

Application degree of awareness: To what degree must an application be aware of the internal constructs of a blockchain system in order to interact with it and make use of the blockchain. As a point of comparison, an email client application today is not aware of constructs of packets, MPDUs, routing and so on. It interacts with mail-server according to a high-level protocol (e.g. POP3, IMAP, SMTP) and a well-defined API.

Placement of functions dealing with reliability and commitments: What is the correct notion of “reliability” in the context of interoperable blockchain systems and where should the function of reliability be placed. Should a user application be even aware of the notion of the atomicity of transfers. In the case of the Internet architecture, reliability of transmission is provided by the TCP protocol, which has a number of flow control features that “hides” reliability issues from the higher level applications.

Semantic type of blockchain: What mechanism is needed to communicate to an external application the semantics of the ledger-level transaction supported by a given blockchain system. For example, a blockchain system for payments is different from one for recording assets, and furthermore different payments blockchains around the world may be implemented differently. Merely publishing an application-level API does not guarantee interoperability at the transaction level.

Distinguishability of blockchain systems: For an interoperable blockchain architecture, how does an application distinguish among blockchain systems (even if they have compatible semantics) and at what level should an application be aware.

Objective benchmarks for speed and throughput: How do external entities obtain information about the current performance of a blockchain system and what measure can be used to compare across systems. Should node-level performance information be made available as part of the measure for a blockchain’s reliability and throughput as function of the consensus algorithm used.