Trends and Opportunities of the Interoperable Web3 Stack
By Brian Kerr — Member of FinTech Connector / San Francisco
The Web3 stack consists of the emerging technologies built on top of blockchains like Ethereum and Bitcoin to support decentralized applications.
Interoperability of blockchains promises to enable a host of new Web3 use cases and applications including digital asset portability, trustless decentralized exchange, and cross-chain smart contract communication. A number of teams are working on interoperability solutions which break down into categories such as atomic swaps, relayer chains, DEXs, and interoperable state channel networks.
However, even the most widely adopted blockchains like BTC, ETH, and XRP are still unable to interoperate without the use of a centralized counterparty.
Recent work within the Interledger Community by companies like Kava Labs, Coil, and Strata Labs is showing that trust-minimized interoperability is finally possible. Kava Labs recently demonstrated the world’s first streaming payments between ETH and XRP using the Interledger Protocol (ILP).
This display of practical interoperability has forced us to think deeper about the impacts of interoperability on the blockchain industry as a whole. This article describes why we believe it is only a matter of time before all open networks interoperate. As interoperation breaks down walls created by network effects and distribution, token holding preference amongst users will likely shift, causing massive value accrual to a new set of highly specialized blockchains which we describe below.
Interoperability is Imminent
Interoperability protocols like ILP allow blockchains to communicate without modifying the underlying blockchain. This means any developer can integrate an open network using ILP without needing the buy-in from core developers or participants of that network. Even if stakeholders of BTC and ETH don’t want to interoperate, the ledgers will be integrated once interoperability standards permeate the Web3 stack.
With technology like ILP, the integration of all major open networks is just a matter of time. Soon, developers and users will have the luxury of choice between crypto assets and the services they offer without being siloed from other networks.
Emerging Service-oriented Architecture
The specialization of blockchains is an outcome we’ve seen in the developing Web3 stack as a result of the scalability trilemma that requires blockchains to choose fundamental trade-offs between decentralization, throughput, and safety.
Blockchain specialization can generally be placed into the following categories:
1. dApp Platforms (ETH, EOS, ADA, etc)
2. Store-of-Value Blockchains (BTC)
3. Privacy Blockchains (XMR, ZEC)
4. Stability Blockchains (Basis, DAI)
5. Specialized Application Blockchains — designed for specific applications (SIA, STEEM)
Due to the imminent interoperability of open networks and their specializations, it is clear a service-oriented architecture (SOA) for blockchains will form. Just like web developers can combine specialized web services, interoperability will allow blockchain developers to combine capabilities from different blockchains to meet their particular development needs.
In this way, interoperability will bring new capabilities to developers while also creating competition between blockchain-based Web3 services.
Demand for Interoperable Transactions
Transactions between different blockchains for Web3 services is an essential operation. It is highly likely that the majority of these transactions will be high-volume, low-value transfers. We are starting to see this trend in new web monetization models, streaming payments, machine-to-machine transactions (IOT), real-time energy purchasing, and a host of other Web3 services.
Developers and users will need to conduct transactions with each specialized blockchain service within the emerging service-oriented architecture. Normally this would require them to hold all the specific crypto assets needed to transact with services they want to access. This is an impossible ask, especially since these assets will often be prompted automatically by business logic in code and be needed just-in-time at sporadic intervals and volumes, as in the case of API calls for web services.
Interoperability solutions like ILP enable users to hold a single asset to conduct transactions, allowing them to convert just-in-time at any level of usage, unbeknownst to the user, for all Web3 services.
The central question is: Which assets will people hold and use for Web3 transactions?
Blockchains for Web3 Transactions
Naturally users would want to use BTC, ETH and other widely available assets as the single currency used to transact with the various services. Unfortunately, due to the majority of Web3 use cases requiring rapid, high-volume, and low-value transactions, the way these blockchains have specialized makes them unsuitable for most Web3 uses. In order for Web3 transactions to have an acceptable user experience they need to be fast, have low setup cost, a low continual usage cost, and be verifiably secure.
SoV chains like BTC optimize for high security, slow evolution, and slow finality. Even with layer-2 implementations like Lightning, the network still results in slow payment channel creation along with high fees, untenably long timeouts, ultra-high node switching costs, and large cross-currency latency making it near impossible to use for Web3 use cases requiring fast payment channel creation and quick settlement.
dApp platforms like ETH and EOS won’t work either because they optimize for developers to use blockchain resources for application development. Today the top dApp platform, Ethereum, has its resources nearly completely consumed by dApps. The permissionless nature of these systems means that they will persistently have scaling challenges to meet the needs of increasingly complex dApps. To meet this demand, dApp platforms will use active governance, rapid technological experimentation at the consensus and second layers, and trade off more decentralization in order to scale. These traits are incompatible with the payments use case, where resources should be completely dedicated to payment transactions, technology should change at a slower pace, and the minimum viable decentralization is higher.
The available layer-one solutions capable of delivering seamless interoperation of Web3 services are conspicuously lacking. What is needed at a minimum is a blockchain capable of rapid creation and settlement of interoperable payment channels. Ideally it should also be equipped with a state machine capable of formal verification to provide surety and security when moving value between different blockchains.
Due to the fundamental trade-offs of blockchains, interoperability will lead to two categories of blockchain assets:
1. Blockchains that specialize in applications and services.
2. Blockchains that specialize to interoperate Web3 services seamlessly.
Given the lack of current viable layer-one solutions for the latter, this presents a huge opportunity for a new specialized blockchain to play a central role in the Web3 ecosystem as the programmable money of choice that provides access to all other blockchain services.
For a robust and resistant Web3 system in the long-term, it is likely there will need to be several blockchains that serve the role of interoperable Web3 money. These too may specialize either by providing enhanced speed and efficiencies or additional resistance to threats via privacy implementations, etc.
As Web3 applications become more widely used, the blockchains positioned in this new role will be poised to accrue significant value as the preferred currency held in Web3.
About Kava Labs
Kava Labs is building a new open-source blockchain designed and optimized as the asset of choice for interoperable Web3 transactions. We believe decentralized fast-finality consensus, deep support for payment channels that preserve privacy, and formal verification are key ingredients to meeting the needs of Web3 use cases.
DISCLAIMER: The following article is republished with the express permission of the author Brian Kerr. The original article was published on Medium on September 18, 2018.