In previous posts, we discussed how to take advantage of the unique properties of our stack to build a number of autonomous services in the Autonolas network, including oracles and asset management services. You’ll recall that a key point in the process of building an Autonolas agent service is the division of business logic into discrete "stages" that represent generic, reusable functionalities, and that other services can take these stages on board for their own purposes.

We believe that the reusability of service components in this fashion is the key to achieving an ever-growing ecosystem of autonomous services. These services will be both robust and require only minimal effort to build. In this post, we’ll extend these ideas by exploring the reusable properties of the Autonolas stack, and provide what we hope will be valuable insight into how it can be used to enhance the infrastructure of cross-chain bridges.

A Brief Overview of Cross-Chain Bridges

Following the approach presented in earlier posts, the first task in the design process of an Autonolas agent service is identifying and splitting the service’s business logic into easy-to-identify, high-level functionalities. In this case, rather than building an entire cross-chain bridge, our focus will be on some of the off-chain components of the bridge infrastructure. Let us first briefly recap some core concepts of bridges.

A cross-chain bridge is a service that enables transferring assets and information from a source blockchain x to a destination blockchain y. In the case of transferring tokens, we end up in blockchain y with a representation of an asset originally minted in blockchain x. Chains x and y might operate under entirely different, incompatible consensus mechanisms. It is precisely because of this potential protocol incompatibility that there may not be a method for the native transfer of tokens between the two chains.

Bridges can be classified according to a number of distinguishing features. One such classification is based on the bridge’s trust model, either trust-minimized or trusted.

• Trusted bridges typically involve external parties that need to be trusted to carry out security-sensitive operations. Users give up control of their assets and transfer the assets they would like to bridge to the trusted party. For example, the trusted party accepts user’s A tokens on chain x and issues the corresponding token instance of A on chain y. This requires that the trusted party have a pool of tokens on both chains. When the corresponding transactions are considered final on chain x, the trusted party makes tokens available on chain y. In case of probabilistic finality, one considers a transaction (almost) final after a given number of confirmations. The trust assumptions of this kind of bridge (i.e., that the bridge operator is not going to “run away” with the user's assets) basically relies on the reputation of the operator.

• In contrast, in trust-minimized bridges, users do not have to place trust in a single entity or authority; instead the security is based on cryptographic properties that ensure its correctness. This type of bridge makes extensive usage of smart contract operations on each end of the bridge (i.e., on chains x and y). As a result, the security is equivalent to that of the underlying chain with the weaker security, and no new trust assumptions are added.

We can also classify bridges at the level of operation design. There are three main approaches: lock and mint (lock assets on the source chain and mint assets on the destination chain); burn and mint (burn assets on the source chain and mint assets on the destination chain), and atomic swaps (swap assets on the source chain for assets on the destination chain with another party).

• In the case of lock and mint, what happens is that a number of token-instance-of-A-on-chain-x are “blocked” on chain x and the same number of token-instance-of-A-on-chain-y are “generated” on chain y. How this blocking and generating processes occur depends on the type of bridge. This mechanism is achieved through smart contracts on each chain: a user willing to have a representation of their A-tokens on chain y will first execute a contract call locking such tokens on chain x, and later, an off-chain process (such as a keeper) will monitor the interactions with that smart contract and will instruct the smart contract living on chain y to mint (or transfer from a pool) the corresponding tokens on chain y for the user. Parties involved are incentivized to operate correctly, and slash mechanisms can be put in place to report misbehavior or illegitimate reports.

• The case of burn and mint is similar, with the exception that a number of token-instance-of-A-on-chain-x are burned and no longer available. In the case of atomic swaps, a number nA of token-instance-of-A-on-chain-x are exchanged by a number nB of token-instance-of-A-on-chain-y in a manner similar to a token swap in a decentralized exchange. This is the protocol used by Hop Exchange, which we will be discussing in more detail below.

Autonolas Services Inside the Bridge Infrastructure

A bridge infrastructure consists of a number of different entities and components that work together, both on-chain and off-chain, to implement the bridge functionality. We will now consider two types of bridge design which are particularly well-suited to improvement by an Autonolas agent service. These architectures fall into the category of trust-minimized bridges that are externally verified, and/or operated. In such a bridge, a group of external validators verify the transactions and possibly provide liquidity. Two examples that we will be examining are Celo Optics and Hop Exchange. What follows is a brief outline of their architectures, and some insights into how they could benefit from an Autonolas agent service implementing one of their components.

Use Case 1: Decentralizing the Updater in Optics

Celo Optics Bridge is a new bridge design without header verification which aims to provide cheap cross-chain communication. In order to bridge information from chain x to chain y, a Home contract on chain x receives and aggregates such transactions. Then, an off-chain actor called Updater periodically observes the chain x Home contract, signs attestations to new batches of transactions, and publishes the signed attestation to the Home contract. Another external off-chain component called Relayer polls chain x for new signed updates, and forwards them to chain y. Also, a number of Watchers periodically monitor both chains and report any Updater misbehavior (e.g. signing illegitimate transactions). If an Updater is found guilty of misbehavior, a slashing mechanism punishes their assets on chain x. We refer here for the complete details.

Clearly, the untrusted Updater is a candidate to be built as an Autonolas agent service, since this will reduce the amount of trust required in that party. Here we depict the main stages of an Updater agent service built in Autonolas. We’d like to point out that several of these stages have already been discussed and reused in previous services presented in this blog (e.g., here and here), but we include them here for completeness:

• Agent Registration: implements the registration of agents, i.e., the commitment of the agents to participate in the service.
• Safe Deployment: deploys a Gnosis safe contract, which is a multisig smart contract wallet that requires a minimum number of signers from a signers group to approve a transaction for it to be valid. The group of signers are the agents that are part of the service. This assures that no single agent from the group can compromise the funds contained in it and means agents do not hold any meaningful funds themselves. This is a requirement to send transactions to the destination chain.
• Monitor and Sign: Agents periodically monitor the Home contract waiting to collect an appropriate batch of transactions. Once this happens, the agents sign the batch data structure (which is a Merkle tree) using, for example, a k-of-n threshold signature scheme with distributed key generation. The result of this stage is that the transaction is ready to be submitted on the destination chain. That is, agents agree on what is the contract call to be executed on the destination chain.
• Transaction submission: Actual submission of the transactions of the agreed operation to be executed on the destination blockchain.
• Reset and Pause: Wait for a while and restart the main cycle of the service again.

Following our line when discussing complex services in previous posts, let us focus on the newly introduced stage in this service, i.e., the Monitor and Sign stage. This stage can be encoded as a finite-state machine which looks as follows:

Now, we will take a look at the conceptual execution flow of this stage through its constituent states and events:

1. The agents in the service periodically observe either blockchain looking for a batch of transactions waiting to be signed.
2. Once a suitable batch is detected, agents distributedly sign the transaction. We assume that agents are using a threshold signature scheme to sign the data structure containing the batch of transactions, therefore, no single agent is in possession of the signing key of the service.
3. Once there is consensus on the operation to be executed (i.e., the valid threshold signature), the agents agree on the transaction hash of the operation. As occurred in the case of the Oracle Service, there is a special “dummy” state (Finished state), which is used to mark where the next stage (Transaction Submission) is going to be connected. Recall again that the output of this stage does not send any transaction to the blockchain: it produces the transaction hash to be sent to the Transaction Submission stage. Also, you can see a number of events in the finite-state machine indicating certain error conditions (e.g., no consensus on the agents of the service).

Use Case 2: Decentralizing Bonders in Hop

The Hop exchange protocol allows bridging of tokens almost instantly between either layer-2 (Polygon, xDai, Arbitrum and Optimism) rollup sidechains, or a layer-2 and their layer-1 network, e.g. Ethereum. A rollup is an off-chain mechanism that allows for grouping of transactions taking place outside the blockchain into batches, providing a mechanism to guarantee the validity of these transactions on-chain. A smart contract is in charge of receiving a summary of these updates and the proofs of validity of what has been executed off-chain.

The Hop protocol achieves its high speed when bridging tokens through the use of a Bonder, which is a market maker that provides the liquidity at the destination chain in the exchange upfront, in return for a small fee. This credit is extended by the Bonder in the form of hTokens, which are then swapped for their native token through an automated market maker.

The Bonder is usually a single, external party that verifies and provides liquidity upfront. But, as identified in the Hop whitepaper, relying on a single Bonder to be available and to have enough liquidity at all times might be overly optimistic. Moreover, if the Bonder is unavailable, transfers will propagate throughout the bridge at a much lower rate, diminishing the main value-add provided by this bridge design.

One option could be to substitute the single Bonder for a network of Bonders. Substituting the Bonder with an Autonolas agent service helps to create a more reliable system, while also removing the challenges that naturally emerge when we consider a simple network of Bonders (e.g., choosing which Bonder is rewarded for a particular transfer without clogging the service).

A simplified sketch of the stages of an FSM App implementing such a component looks like this:

Observe that this agent service bears a lot of resemblance to the agent service used in the example service we described for Celo Optics. Concretely, the stage that differs is the “Monitor and Provide Liquidity” stage. A simplified way of defining the finite-state machine for this stage is as follows.

1. The agents in the service periodically observe the potential source blockchain looking for contract calls indicating that a bridge of assets is requested.
2. After finishing the previous stage, the agents reach a consensus on the concrete operation that needs to be executed (and in what destination chain). It could be the case that no operation needs to be executed (i.e., no asset bridge was requested in the previous observation interval, or the transaction was finally deemed invalid). This situation is marked through the event NO_ACTION. The service will indefinitely loop between these two states if there is no contract call to bridge assets.
3. Once there is consensus on the operation to be executed (i.e., there is valid, pending token transfer operation), the agents agree on the transaction hash of the operation. This will be submitted by the next stage, i.e., Transaction submission, and the funds will be released in the appropriate chain for the corresponding user.

Note that given the fast bridge operation requirement in this case, the observation interval must be sufficiently short to meet the system requirements.

Also, note that in the Autonolas agent services proposed above (for the case of Celo Optics and Hop) no stage related to the deployment of smart contracts on the respective chains are required. As expected, this is the case, because unlike the Autonolas Oracle, these services implement only one part of the overall service infrastructure.

Conclusion

If you have been following our series of technical posts (1, 2), you will immediately notice how the effort required to develop such complex components within a bridge service is greatly reduced thanks to the composable nature of the Autonolas Agent Services: Most of development efforts will be focused precisely on the few specific stages that need to be adapted for the business logic needs of the particular off-chain component(s).

Get Involved

While there is not yet an implementation of an Autonolas Bridge in the wild, we hope that this post has given you confidence in the feasibility of building one. We have highlighted the importance of the composable nature of services in the Autonolas Stack, which allows us to build services that are fully decentralized, secure, robust, trust-minimized and crypto-economically secured on-chain.

If you are interested in learning to build your own autonomous services, we’d like to point you to the latest version of our Academy. The refreshed Academy now includes a self-guided course you can follow at your own pace. These materials will provide you with the tools required to start building your own off-chain services.

Additionally, for those of you who are brave enough, we will be offering a mentorship course, the Builder Track, for developers who have successfully completed the self-guided portion of the Academy.

You can learn more about the Academy, and get started with the materials here.

In any case, you are always welcome to reach out to us on Discord if you need community support when building your services, and we also invite you to follow us on Twitter to stay up to date on all our latest developments.