Bridge

Overview

Bridging solutions can be fall into one of four quadrants across two axes: security and expressivity.

Ideally a rollup inherits security form its DA layer. However, committees offer a way to bridge without implementing a full proof system. Committee-based bridges will be useful in two cases:

1. Quickly providing a bridging solution to projects in the Chopin ecosytem before light client verification is available; and
2. Providing a bridging solution for Chopin-based apps that have a tech stack that cannot be proven. The customizability of Chopin Framework may lead some teams to choose technical freedom over trust-minimized briding in some cases.

The endgame for interoperability would be for any non-Chopin blockchain to be able to read any state from any Chopin blockchain. In other words, a developer writing a smart contract on another chain could essentially "call the API" of a Chopin-based app. Under the hood, this would not literally generate an HTTP request, instead it would pass the call through the fully expressive bridge. In theory, there is no reason that other chains cannot also have read-only access directly to the DB—allowing them to tokenize and trade any part of the internal state of a Chopin-based app.

However, another simpler approach is to only bridge tokens. This can make tokens within Chopin-based apps compatible with the rest of DeFi. It is simpler and quicker to implement and, unlike the fully expressive bridge, adds compatibility with existing tools, like Ethereum wallets.

We won't discuss the endgame much here because it is dependent on other initiatives, such as light client verification. This document will explore more short-term solutions.

Committees

Hyperlane

I have been recommended Hyperlane quite a bit for this use case. I see two ways to get this working.

1. Use the EVM integration. See chain emulation for more details. In short, by creating EVM-compatible RPC endpoints, Chopin-based apps can become compatible with any given EVM tool—including Hyperlane.
2. Create a custom Hyperlane integration. This would probably be ideal, but there is not much information listed on their website. See below for more details.

If you're excited about building on top of these or bringing Hyperlane to other new ecosystems, reach out on our Discord! (Source)

Tendermint

L1

Under this model, each validator would run it's own full node of a given Chopin-based app. Most likely, each app would want to be it's own L1—however, it would be possible to put multiple apps under the same L1 so that they don't each need to bootstrap their own validator set (this does not have unlimited scalability). Technically speaking, this model would not require a separate DA layer, because each app could provide its own DA. The benefit of using a separate DA layer, though, is that there would be a "sovereign rollup" mode that could inherit the security of the much more secure DA layer. This would be useful for consumers, despite the fact that bridging would only be as secure as the Tendermint instance.

Hub Model

Taking inspiration from Dymension, there could be a single L1 that acts as a hub for all Chopin-based apps (rollups). This is likely the most efficient way to batch all rollups into a single validator set (aka a single committee).

Actively Validated Service

Another option is to build an AVS (i.e. with Eigenlayer) that certifies state commitments. I have not explored this option much, but I like being able to restake an existing token as collateral. This could be quite compelling.

Compatibility Strategies

Chain Emulation

This is a powerful concept that is likely a good idea in it's own right, even if it is not used for bridging. The idea is to create an EVM-compatible RPC endpoint that is able to read and write to the state of a Chopin-based app in a structured manner that enables tokens built with Chopin Framework to become ERC20-compatible.

A simple of example of how this could be useful is to enable Ethereum wallets to hold Chopin-based tokens.

ERC20 tokens have a few set functions that must be described.

• totalSupply
• balanceOf
• transfer
• approve
• transferFrom
• allowance
• name
• symbol
• decimals

By simply requiring Chopin app developers to define these functions in TypeScript, we can give their tokens ERC20-compatibility. Here is how it could work:

1. Add an limited RPC endpoint at the domain chopin-app-sequencer.com/_chopin/evm-rpc
2. This endpoint would listen for eth_call, eth_sendTransaction, and any other essential RPC requests.
3. When the call is made, the endpoint would parse the request and call the appropriate function on the Chopin-based app.
4. The response would be sent back to the caller in the expected format.

With this basic functionality, Ethereum wallets like MetaMask wouldn't know the difference between a Chopin app and an Ethereum chain. All a wallet needs, is an RPC URL and basic metadata.

A more complex version of this strategy could be employed in order to gain compatibility with EVM based bridges.

A side benefit of this strategy is that formalizing the token format in an EVM-compatible manner will make native settlement to Ethereum easier in the future.