Ever since sharding and the internet of blockchains ideas were first introduced, maintaining composability has been a hot topic of discussion. Let's try to better understand the role bridges play in keeping our ecosystem composable.

While I've written about composability of dapps and wallets before, I don't believe I've explicitly defined the word "composable." Generally, I think composability is comprised of existence, flexibility, and reusability. As a pre-condition, everything should be accessible in a permissionless manner (i.e. sufficiently decentralized).

Existence

I believe that right now, most people think of bridges as "how can I get token A transferred from blockchain X to blockchain Y," or slightly fancier as "how can I swap token A on blockchain X for token B on blockchain Y."

In other words, right now the focus is on asset existence - meaning the same asset should exist on every chain. For example, USDC should exist on both Ethereum and Polygon and remain fungible between chains (almost as if they were the same ERC20 contract). Another example would be getting Bitcoin from its chain to Ethereum through the Ren wrapper as renBTC.

A second facet is continuous versus ubiquitous existence. Continuous is the earlier example where my tokens are either on chain A or chain B. However, some tokens may need to exist on multiple chains at the same time, hence, ubiquitous. This can apply to something like a proof token (NFT). Let's say I have an NFT representing my credit score which I can use to borrow with special terms inside some defi dapp. I wouldn't want to transfer this NFT across chains, since I'm likely borrowing from multiple chains at the same time. Hence, the NFT needs to exist on both chain A and chain B at the same time - and remain in sync on mints, transfers, and URI updates. This can be extended to DAOs as well, though this one is harder to think about since DAOs don't have a set contract standard.

A more technical way of framing asset existence is as the data on a blockchain. Usually, we either access data stored in a contract or we mutate the state by interacting with the contract. As far as I know, we don't have a good way of accessing or mutating data between chains, besides what is under research like optics or sharding. This means that currently, smart contracts (the logic and assets) are portable from chain to chain but are non-interactive between them. Instead of the vertical legos we're used to, we really only have horizontal integration right now. Each chain is built up as a walled city, with resources traded around between them all.

Flexibility and Reusability

I think that the scope of asset transfer for understanding bridges is a little narrow. The truth is, we've actually all been using bridges for years now! Let's redefine a bridge to be "the transport, authentication, and ordering of information between two or more parties."

This is very similar to how the internet works today, where data is split and transferred in packets between a web of nodes before reaching their desired destination (IP) and being put together in a specific order to represent the original data. Our extra layers of complexity with bridges involving blockchains come from security and verification:

• As chain B, can you trust the message being sent across the bridge is true, like when using wrappers like renBTC?
• Conversely as chain A, can you trust that the message you sent through was committed into a transaction (i.e. calling a smart contract on chain B)?
  I won't go deep into this today but you can learn more about the technical difficulties here and here.

Now, let's think about what common party-to-party bridges exist in the our ecosystem:

• database <> database (bridged by ACID methodologies and microservices)
• database <> blockchain (oracle networks that bridge data to a blockchain)
• blockchain <> database (event reader networks that bridge blockchain to a database)
• blockchain <> blockchain (the bridges we've been talking about for the internet of blockchains fit here)
• dapp <> dapp (everything in between is one large, flexible bridge)

I've observed that bridges are first built for a specific purpose of supporting data existence from point A to point B, but then become more and more flexible as they can be built upon by anyone).

Generally with any bridge there are three roles:

• Node Runner (manage the bridge infrastructure)
• Creator (developers who create a marketplace of possible interactions/queries to load onto nodes)
• User/Query Runner (consumers of data, who can use anything from the marketplace built by creators to port data from point A to point B through node runners)

Once these three roles have been set up nicely, you obtain the properties of flexibility and reusability. Let's look at some concrete examples:

• Chainlink: On Chainlink, you have a party that is specifically responsible for running a node that takes in requests from an on-chain oracle contract and returns the value from the endpoint queried. Creators are developers who can create external adapters that allow for API keys and complex logic (i.e. the data returned is a multi-key JSON object, and I can use an adapter to concatenate that into a bytes32 object to easily parse in solidity).
• theGraph: This service has the three roles most clearly defined, with indexers (node runners that read emitted events from on-chain), curators (creators of the subgraphs/API endpoints), and consumers (the ones running each query).
• Numerai: While their user use case may not be as flexible (given they are not purposed to output data on-chain past staking purposes), they allow creators to upload machine learning models onto hosted infrastructure. Given the prevalence of ML/AI in our world, I imagine that one day someone will provide a similar service/structure for running models with inputs/outputs on-chain.

Now for some bridges that I think will reach the same structure:

• Teller: While right now their node network supports only the transfer of your bank account data on chain, it is possible that they become a network that allows any fintech data provider to onboard and create a data service. This is similar to chainlink, but their infrastructure has better privacy management/implications.
• Mina: Speaking of privacy, Mina is actually a super interesting project because they enable use cases like Teller with their technology. Their tooling allows for a zk/privacy overlay end-to-end, which in my mind feels very similar to how we have gone from TCP/IP to VPN in the traditional internet world. I'm assuming they'll be like any node network where these privacy use cases can be built on top of it and used by anyone on another blockchain.

• Cosmos: With CosmWasm/IBC/Tendermint/Ethermint, you can actually start building logic into bridges that are similar to smart contracts (like DEXs). Some examples that have come out of their SDK are proof of stake style chains like Thorchain.
• Connext: With state channels/ILP, you get a level of user flexibility that is hard to manage with IBC. Their custom transfer definitions and routers may in the future allow for special use cases for DAOs, NFTs, and other self-managed multi-chain needs.

Building freely upon bridges gives us flexibility, and the shared infrastructure and split roles gives us reusability. Many of our bridges already have these two properties, and the bridges between blockchains are getting there as well. One day these bridges will enable full (veritcal/horizontal) existence as well, giving us composability across the ecosystem.

A Token from the Haert

We're all out here building bridges right now, trying out best to move in sync. Walls are being torn down, and the groundwork is being laid for the many future generations to build upon. We must exist together, with flexibility of mind, and a shared heart. There will be no walls in the metaverse. I wanted to represent this ethos in an algorithmically generated art piece from Ethereum data:

The identicons are generated from 100 unique Ethereum addresses. Through 100 rounds, each "block" moves towards the center following the Ethereum PoW Poisson distribution. The "heartbeat" is generated by the amplitudes of the sine transform of Ethereum transaction history.