Interoperability in the Age of Siloed Blockchains Pt. 1

Blockchain Interoperability has become a convoluted, somewhat mythical topic. For an idea that originated with the simple premise to develop ways for two blockchains to exchange information, the interoperability field today is flooded with technical complexity .

The purpose of Part 1 of our two-part series on Blockchain Interoperability is to provide an overview of the leading approaches to interoperability via intermediary networks, as well as the historical background that prompted a group of early bitcoiners to begin exploring the topic back in 2010.

In this post, we also explore the difference between interoperability and composability in the context of Ethereum, Cosmos, Polkadot, and why this distinction can undoubtedly alter one’s perspective on value creation.

Although the term blockchain interoperability has been used in various contexts, we simply define it as the ability to exchange information, especially as it relates to the ownership of various assets, from one cryptonetwork to another.

All blockchains, by definition, share a common data structure to organize and reach consensus on ownership changes. Even blockchains whose implementations vastly differ, like Bitcoin and Ethereum, make similar use of Merkle Trees to link transactions in time intervals, or blocks, that when chained together form a complete transaction history, a blockchain. While the term has become a semantic nightmare over the past five years, its etymology and technical essence continue to be the same for Bitcoin, Ethereum and most cryptonetworks in between.

Yet, in spite of such similarities, there are no reliable mechanisms through which an Ethereum smart contract could verify whether a Bitcoin transaction has been sufficiently confirmed, and vice-versa. As a result, what we have today is a plethora of blockchains that fundamentally share the same proof system, but that are siloed due to the lack of a robust transport layer for these proofs. This realization led to the development of distinct approaches to what came to be known as Blockchain Interoperability, particularly over the past three years, with varying levels of complexity.

In recent times, the term Blockchain Interoperability is used to describe a suite of completely different technologies being simultaneously pursued; from decentralized exchanges to federated sidechains to intermediary networks like Cosmos and Polkadot. This has resulted in confusion about what blockchain interoperability is and how it can be implemented. An aggravating factor was the rise of dozens of projects in late 2017 that leveraged the complexity of the term to market solutions and tokens that had nothing to do with bridging information between different cryptonetworks.

DAR’s Interoperability Intermediary Index (DII), one of the thematic indexes we created to better track performance and compare valuations on specific themes, shows a considerable decrease in price in tokenized interoperability solutions (ICX, AION, WAN and ATOM) following the 2017 speculative bubble.

Beyond the individual issues faced by nearly all DII constituents, we attribute this decrease in interest to the evolving complexity of interoperability as a topic, coupled with a lack of relatable use-cases for this technology and increased skepticism around tokenized solutions during the 2018 bear market.

While disappointments with the price performance of tokenized interoperability solutions have decreased mainstream interest in the technology as a whole, we continue to see the interoperability as an important next step as the industry matures. The core idea behind this thesis is that the ability to exchange information and assets across cryptonetworks will allow market forces to act more efficiently as different assets and applications are put to test as a whole.

Although crypto markets are generally integrated, the lack of meaningful usage of most decentralized applications, coupled with the never-ending hype around technology that is hard to understand, ultimately pose a barrier to market efficiency. We believe that increasing connectivity, especially between Bitcoin and Ethereum, can increase usage of applications that are useful and make vaporware easier to detect. In essence, interoperability can act as a catalyst to a project’s failure or success, and we see it as free-market primitive worth pursuing.

In DAR’s Interoperability Report issued to our clients last year, we identified the following list of potential benefits that motivated developers and researchers to begin exploring blockchain interoperability:

The ability for users and developers to choose specific applications across blockchains and let market efficiency challenge the product-market fit of all deployed applications.

Rather than having a single blockchain that processes and stores all transactions on a single thread, interoperability enables transfers of value to be parallelized across multiple networks. The computation of smart contracts can also be parallelized, thereby increasing the potential functionality of certain applications.

The ability to outsource and externalize features of a service, decentralized application, or financial product to a highly specialized network.

The ability to verify events and identities across blockchains, as well as the ability of an event in one blockchain to trigger the execution of a contract that resides in a different blockchain.

The ability of a contract in one blockchain to secure or collateralize a balance in a different chain. This balance can then be used by the contract as collateral for financial derivatives, leveraged products, bankruptcy clawbacks, liens, and any use-case that may require collateralization or security deposits.

Interoperability may enable the stakeholders of one network to engage in the transaction validation and governance of a different network. Similarly, it enables stakeholders to operate as staking pools and deploy stake strategically across network that make use of that mechanism. More on this in Part 2 of this series.

While blockchain interoperability may seem like one of the most cutting-edge, meta topics this industry has to offer, the concept itself is almost as old as Bitcoin.

In fact, the idea of bridging information between multiple blockchains running in parallel (the general concept of sidechains) dates back to 2010, with the proposal of BitDNS; a Bitcoin-based Domain Name Service (a database that converts human-readable URLs into numeric IP addresses). Although never implemented in Bitcoin, BitDNS was instrumental to kick off the initial discussions on blockchain interoperability and the potential use cases for sidechains in the following years.

Nine years after the concept of sidechains was introduced, working implementations to facilitate blockchain interoperability are still in their infancy. From our perspective, current blockchain interoperability can be divided into four general categories:

While each of the four (very) general approaches described in the diagram above carry their own peculiarities, the ultimate goal is the same: take asset/information from one blockchain chain, validate its existence and preconditions (e.g. time-locks), and recreate it synthetically in chain B.

If you have read about blockchain interoperability in the past, you have likely seen the use of the word atomic, as in atomic swaps. This term is frequently used in the context of blockchain interoperability to describe the guarantee that either all underlying operations of an asset exchange (such as a swap) will occur successfully, or no operations occur at all. Atomicity is a requirement in the absence of a third party, because if one side of the swap were to fail while the other succeeds, one of the parties would be asymmetrically harmed.

Trustless and non-custodial systems that enable atomic transfers of assets such as cross-chain atomic swaps are particularly hard to develop, since they require the engineering of a singular system that satisfies completely different blockchains, like Bitcoin and Ethereum. That means specific data structures, digital signatures and consensus finality must be translated and generalized, which is no easy feat. This has led to the creation of several interoperability intermediaries whose approach to this problem is to have a tokenized, standalone blockchain with its own consensus engine and smart contract functionality to bridge the flow of assets across blockchains.

To better understand the concept of interoperability through intermediation, consider the following hypothetical scenario: Alice, who stores part of her savings in Bitcoin, desires to get a loan from a bank that operates on the Ethereum network. In order to assess the risk of this loan, the bank needs to audit Alice’s financial history and take possession of a collateral in case she misses a couple of payments. Through an interoperability intermediary, the bank creates a smart contract (a multisig) on Bitcoin that effectively locks Alice’s collateral for the duration of the loan. With the help of the intermediary, that contract can programmatically return the collateral to Alice, or transfer it to the bank in the case of negligence. This way, Alice can select which network to store her collateral, but still benefit from the services offered by other networks.

Back in 2016, the idea of using an intermediary to relay cross-chain communications was thought to simplify many of the frictions preventing fully interoperable blockchains. Because different networks require different confirmation times (economic finality thresholds, for the technically inclined), the existence of a coordinator was believed to make the flow of information across cryptonetworks simpler and potentially safer in the event of reorgs or consensus failures. Although this is true from a high level perspective, the added layer of intermediation has proved to be incredibly challenging to construct and secure over the past years.

As interoperability intermediaries evolved into full-fledged smart contract platforms, they began to face the very same implementation challenges in their consensus engines, virtual machines and networking protocols as projects like Ethereum.

Because the line between interoperability intermediary and smart contract platform got blurred as implementation problems surfaced, a key distinction must be made to effectively assess current approaches to connecting blockchains — the difference between interoperability and composability. While these terms are often used interchangeably, outlining their differences undoubtedly alters one’s perspective on value creation, especially in the context of highly-expressive smart contract networks like Ethereum, Cosmos and Polkadot.

Put simply, composability is the ability to define (and change) the specific requirements of an application within a singular environment and according to their particular needs. In cloud computing, for example, composability is a popular approach to IT infrastructure since it allows developers to choose and scale cloud services as their applications evolve. Through platforms like AWS, system admins don’t have to physically acquire, configure and maintain specialized hardware in order to support their businesses.

Composability is the ability to define (and change) the specific requirements of an application within a singular environment and according to their particular needs.

Instead, they can select computation, storage, network tools, and identity solutions as standalone, modular services, and change them as needed within the same environment. Composability is what smart contract platforms are all about, as they attempt to emulate these similar benefits to dApp developers. On the other hand, interoperability, as it is idiomatically used in crypto, is analogous to a system’s ability to source services and exchange information between different environments, like AWS and Azure, or Bitcoin and Ethereum.

Interoperability, as it is idiomatically used in crypto, is analogous to a system’s ability to source services and exchange information between different environments, like AWS and Azure, or Bitcoin and Ethereum.

To better contextualize this difference, let’s look at composability on Ethereum more closely. Ethereum pursues composability through a singular verification environment for Turing-complete computation, the Ethereum Virtual Machine (EVM). By doing so, Ethereum dApps are, at least theoretically, able to leverage existing services within the network and, like on AWS, outsource specialized features such as stable payments, identity solutions, protocol governance solutions, or decentralized storage.

While one could see this as a type of interoperability, it is restricted to a singular environment, and has nothing to do with bridging exogenous environments or cryptonetworks. As such, the use of interoperability in this context can be highly misleading as it contradicts the etymology of the term. Instead, the use of composability is more appropriate as it describes the interactions between interoperable applications that share the very same environment.

Naturally, the specialization of services within a single system is beneficial because it allows developers to focus on the core value proposition of their applications, rather than have to build all components of their dApps from the ground up. Imagine a hypothetical ride-sharing dApp I’ll call dUber (decentralized Uber). By launching on a platform like Ethereum, the developers of dUber can outsource location services, identity management, payment technologies, and corporate governance by using existing solutions in the network.

While this may all sound great, it is, nevertheless, very difficult to implement in practice. Beyond the obvious challenge of being able to scale the application, one of the biggest deterrents of composability on Ethereum has been the rise of the utility token model, whereby ownership of a dApp’s native token is required to access its services. While certain applications may require a separate token for governance or quasi-equity, its simplistic use as a gatekeeper has undoubtedly damaged composability on Ethereum. Rather than being able to pay for various specialized services with ETH, either the application, its developers or users will have to deal with an added friction.

One of the biggest deterrents of composability on Ethereum has been the rise of the utility token model, whereby ownership of a dApp’s native token is required to access its services.

This reinstates the requirement for decentralized exchanges (DEXes) to facilitate programmatic access to specific tokens, which ultimately worsened the semantic nightmare of Blockchain Interoperability. And while there are dozens of projects pursuing DEXes, the overwhelming majority of them still face fundamental challenges, such as finding ways to mitigate the risks of front-running and collusion. Even if those problems were to be addressed by future DEXes, the challenge to source token liquidity prior to using a specialized service would still remain. For this reason, the requirement of specific assets to source specialization through application services has negatively affected composability on Ethereum.

Ethereum’s revamped roadmap, ETH2.0, is intended to ease some of these frictions as its ultimate goal is to enable a composable architecture whereby each specialized service or dApp can have its own standalone blockchain, or shard. Blockchain sharding has been Ethereum’s main approach to scalability as it involves partitioning the network into a number of independent shards, thereby enabling parallel computation. If successfully implemented, sharding can improve scalability and composability on Ethereum.

Under this new roadmap, a Beacon chain will relay information to specific shards, which may represent standalone dApps and/or specialized cryptoassets. This may ease the requirement introduced by utility tokens of a highly functional, programmatic, and liquid DEX, as assets locked in the Beacon chain can be synthetically created in specialized shards. Nevertheless, Ethereum’s base layer is at least a couple of years away from deploying these technologies.

Gavin Wood, Ethereum’s main implementer and the founder of Polkadot, was one of the first researchers to formalize the notion of a highly composable framework for decentralized applications. Wood’s 2016 Polkadot white paper introduced a relatively simple architecture that attempted to circumvent the implementation challenges faced by Ethereum at a time when the research around sharding, hypercubes and Casper was becoming increasingly complex. As an active Ethereum developer on Parity, Wood had first-hand experience over the years on the challenges associated with implementing redesigns and changes to Ethereum.

His solution was to develop Polkadot as an alternative that maximizes composability by allowing multiple iterations of the same blockchain, or parachains, to interoperate between each other. Since the introduction of Polkadot, DAR has been following the evolution of both project’s roadmaps closely and it has been interesting to see how the general architecture of Polkadot and Ethereum has somewhat converged over time, especially after Ethereum revamped its roadmap.

Much like Polkadot’s Relay chain, Ethereum’s Beacon chain will act as a hub that connects multiple shards, or parachains, together. Both hubs are also responsible to validate transactions, relay messages and serve as randomness oracles for the selection of block validators under Proof-of-Stake. The repurposing of ideas seems to be unilateral, as Polkadot also seems to have borrowed a lot of concepts from Ethereum. In November 2018, Polkadot released details about GRANDPA, its flagship consensus engine, which embodies much of Ethereum’s work on Casper.

With sharding, relay hubs, and Casper-based consensus, the idealized versions of both Polkadot and Ethereum are undoubtedly similar. However, in spite of these architectural similarities, Polkadot has been structured from the ground up to facilitate composability, whereas plenty of engineering and coordination will be required to implement composability atop Ethereum’s existing ecosystem of applications and tokenized services.

To maximize composability, Polkadot has created Substrate, a framework for creating Polkadot-compatible parachains. Through this framework, Polkadot dApps are not required to build all the networking and consensus code from scratch, just like ERC20 tokens can leverage Ethereum’s existing networking infrastructure, rather than having to build their own. The difference is that Substrate was developed to work as if each ERC token had its own standalone network with unique features and validator sets.

The distinction between interoperability and composability is particularly relevant here because contrary to popular belief, Polkadot was not natively designed to bridge different cryptonetworks like Bitcoin and Ethereum. Instead, the team has focused on making Substrate-based chains fully composable, but only interoperable amongst themselves. Although it is true that they have plans for a set of bridge contracts able to connect Polkadot to other networks, their main focus is undeniably on Substrate. As such, Polkadot will require developers to organically migrate to the platform and begin to build applications on top of it; something that took Ethereum over three years to achieve.

Although dApps like Aragon are considering building secondary networks on Polkadot, proportionate levels of adoption and value accrual to Ethereum will most likely take a long time. While Polkadot’s focus on composability may pay out in the long-run, the project might struggle to defend its valuation as it acquires developers in the short-to-mid-run, even more so considering that its ICO treasury is still locked after the Parity multi-sig bug. Nevertheless, it has been interesting to follow the progression of Polkadot’s research.

Cosmos has taken a more pragmatic approach to both interoperability and composability by basing its stack on a suite of existing technologies. While the entirety of the project is certainly complex, its foundation is based on interconnected instances of the Ethereum Virtual Machine (EVM) running on Tendermint; a pBFT consensus engine. Consensus design is one of the most important elements of interoperability through intermediation, and the Cosmos team has been working on Tendermint since 2014.

Although there are key implementation differences between Ethereum and Cosmos, such as different data structures, serialization formats, and digital signature algorithms, the latter’s use of the EVM carries the benefits of better interoperability and supporting infrastructure given the EVM’s status as the industry’s most predominant virtual machine. The simple combination of Tendermint and the EVM also enables Cosmos to leverage the existing ecosystem of Ethereum developer tools and open source applications, but still shard its chain for improved composability, interoperability and scalability.

The Cosmos Software Development Kit (SDK) is Cosmos’s equivalent to the Substrate framework on Polkadot. Like Substrate, the Cosmos SDK is intended to facilitate composability across networks connected to the Cosmos Hub by standardizing consensus and networking code. The SDK was designed to serve an ecosystem where various open-source modules, such as privacy add-ons or user identity solutions, can be added to an application as needed. An integral part of this system is an application security model to delineate what the individual modules of an application can or cannot do.

Such permissions are implemented via object-capabilities (ocaps), which, put simply, can programmatically prevent malicious or buggy modules from changing specific states, such as reserve balances or contract ownership. We found this approach to composability and application security to be interesting, since the unpredictability of highly complex smart contracts on Ethereum has resulted in a number of hacks in the past couple of years. Nevertheless, opcaps are not a silver bullet as developers are still required to properly define the interactions between modules.

Beyond composability, Cosmos has sketched out how its network will handle interoperability between the Cosmos Hub and exogenous networks. Their proposed schema to the interoperability challenge involves the introduction of additional intermediary blockchains, or Peg Zones, between the Cosmos Hub and exogenous networks like Ethereum. As intermediaries, Peg Zones can provide probabilistic guarantees of economic finality (i.e. the irreversibility of a block) for Proof-of-Work blockchains.

For example, when a transaction is included in an Ethereum block with the purpose of being bridged to Cosmos, the Peg Zone applies a finality threshold of 100 block confirmations before considering it valid. This finality checkpoint lowers the probability of the transactions being reverted in the peg chain in the event of a blockchain reorganization or a 51% attack. A clear benefit of this type of intermediation is the simplified custody of cross-chain assets. Balances are shared by all Cosmos users through a centralized multi-signature smart contract wallet, thereby facilitating inflows and outflows of liquidity.

Other projects, including Polkadot, have flirted with a similar architecture. More recently, the Loom Network has leveraged Plasma, an Ethereum-based sidechain, to provide similar intermediation to Ethereum users. Given how challenging interoperability through intermediation has proven to be, we expect the layered structure put forth by Peggy to become the blueprint for cross-chain interoperability through intermediation.

Exogenous blockchains and Peg Zones are connected to the Cosmos Hub by two main protocols, Inter-Blockchain Communication (IBC) protocol and the Application Blockchain Interface (ABCI) protocol. The IBC protocol is essentially a messaging system that keeps track of the state, or total balance, of all connected zones. Since any communication needs to be validated, another integral aspect of Cosmos (and Tendermint, specifically) is the ABCI protocol, which operates as a network socket protocol that connects the Tendermint consensus engine to the various applications in the platform.

In the context of Peggy, the IBC controls the inflows and outflows of user funds from and to Ethereum, whereas the ABCI handles the consensus on the validity of these transactions. To contextualize this mechanism, consider the following example: Alice has funds in an Ethermint Zone in Cosmos, and wants to send tokens to Ethereum. Through the IBC, Alice is able to send these funds from her local Zone to the Peggy Peg Zone. Since signatures in Cosmos are done using the Edwards-curve Digital Signature Algorithm (EdDSA), which is different than Ethereum’s Elliptic Curve Digital Signature Algorithm (ECDSA), the ABCI is used to translate signatures to a language Ethereum can understand and verify.

Peggy also relies on a network of Relayers that are responsible for posting batches of transactions and the accompanying translated signatures to an Ethereum smart contract that acts as a custodian. Once posted, Cosmos users can then transact in the Ethereum network.

Witnesses, which are Cosmos users running full nodes on Ethereum, are responsible for informing Peggy about state changes that have occurred in Ethereum. At every 100-block interval, witnesses attest to the finality of an array of Ethereum transactions that are being sent back to Peggy. Through Relayers and Witnesses, Cosmos may provide complete by-directionality from and to Ethereum.

While we suspect this general schema to proliferate in the interoperability-through-intermediation field, full deployment of solutions like Peggy will still take time. At this point, Cosmos’s IBC protocol still needs to be refined and based on our review of the Peggy repository, by-directionality is at least a year away. Nevertheless, Cosmos is close to releasing a Peggy-based unidirectional bridge from Ethereum to Cosmos and it should be interesting to see how it is used.