Cross-Chain Bridge Assessment Process

10

Hey all, Asa and Jon from Hyperlane here.

We believe that Uniswap’s governance bridge selection criteria should prioritize safety and lack of vendor lock-in. Since this is a governance based use-case, the clear parameter to optimize for in this case is safety, while others such as speed or cost are irrelevant. Given this we are in clear support for the Multi Message Aggregator (MMA) design proposed by @Kydo , and previously by others such as @blockchaincolumbia and several bridge providers.

Below, we make the case for support for the MMA, and how the MMA design can be implemented with Hyperlane.

Safety via defense-in-depth

With respect to safety, believe the most important principle is defense-in-depth, a principle championed by the proposals from Kydo, Blockchain@Columbia, and others. In our opinion, the best approach to defense-in-depth is to aggregate the security models of multiple bridge providers as proposed by the MMA, as well as to optionally include security provided by elected members of the Uniswap community (e.g. via a Gnosis Safe).

As far as we can tell (and we are very biased), Hyperlane is the only platform that is able to provide this aggregation natively.

Bridge aggregation with Hyperlane Interchain Security Modules

With Hyperlane, users such as Uniswap can specify custom Interchain Security Modules (ISMs), smart contracts which contain the logic to verify their interchain messages.

This allows Uniswap to, for example, specify an ISM that requires the following:

  • Verification of the message by Wormhole
  • Verification of the message by Axelar
  • 4/6 signatures from Hyperlane validators unaffiliated with Uniswap (including well known entities such as Staked, Blockdaemon, Everstake, ZeePrime, and ZK Validator)
  • n/m signatures from Hyperlane validators run by designated members of the Uniswap community*

It’s worth noting that Hyperlane is the only interoperability provider that currently has this type of modular security architecture already in production. The Multisig ISM can be used today, without any additional development required. Additionally the required infrastructure has been open-sourced and there are comprehensive guides and documentation for its operation. Work on the Aggregation ISM has already begun irrespective of Uniswap’s assessment process, as the system was designed to allow for the simple and fast implementation of new security modules.

An example for the interface can be seen here:

/**
 * @notice Manages an ownable set of ISMs that must all verify an interchain
 * message before it is accepted.
 */
contract AggregationISM is IInterchainSecurityModule, Ownable {
  using AggregationIsmMetadata for bytes;
  using EnumerableSet for EnumerableSet.AddressSet;
  
  EnumerableSet.AddressSet private _isms;

  function addIsm(address _ism) public onlyOwner {
    require(_isms.add(_ism));
  }

  function removeIsm(address _ism) public onlyOwner {
    require(_isms.remove(_ism));
  }

  function verify(bytes calldata _metadata, bytes calldata _message)
    public
    view
    returns (bool)
  {
    for (uint256 i = 0; i < _isms.length(); i++) {
      IInterchainSecurityModule _ism = IInterchainSecurityModule(_isms.at(i));
      require(_ism.verify(_metadata.at(i), _message);
    }
    return true;
  }
}

Uniswap governance would be able to modify this ISM’s configuration over time (or change ISMs entirely). Potential changes to the ISM config include but are not limited to:

  • Require a message to pass through an optimistic security model
  • Add additional bridge providers to the aggregation
  • Require particular messages to also be approved by a Gnosis safe**
  • Modify the unaffiliated-with-Uniswap and/or affiliated-with-Uniswap validator sets

*Running a Hyperlane validator simply requires an AWS account, and RPC connection, and a machine to run on, and can be set up in ~30 minutes without any capital expenditures.

**This is, in-effect, similar to adding an additional Hyperlane validator set, but with fully offline keys

Vendor lock-in

If Uniswap were to use Hyperlane for interchain governance, our recommendation would be to use the Interchain Accounts API, an interchain application built on top of Hyperlane’s core messaging layer.

Interchain Accounts extend the control of an account on a local chain (e.g. Ethereum), allowing it to make arbitrary function calls on remote chains.

Because Interchain Accounts allow for arbitrary function calls, choosing Hyperlane today to implement the MMA would not prevent Uniswap from migrating to a different solution tomorrow, and it provides the easiest way for Uniswap to incorporate new security options as they materialize, as they each can be expressed as a new ISM.

To avoid confusion, we will make a separate post answering the 13 questions submitted by the Foundation.