[Temperature Check] Uniswap x Aurora: Expanding our Multichain Future

[devinwalsh]

Thanks @ishaan, Blockchain at Michigan, and Proximity Labs for putting together this proposal!

I want to dig in to the security of the governance messaging passing bridge.

As background for the community, @tobyshorin summarized some of the risks to insecure implementations of bridges in his UGM Findings + Recommendation post here.

My chief concern is the risk of an attack that would send a malicious, invalid message to a cross-chain deployment of Uniswap v3 that would turn on fees and sends the fees to an attacker’s address, and/or changes ownership of the deployment’s Factory contract to the attacker’s address. This is a major security risk for the Protocol, and would also damage Uniswap’s reputation.

Thank you for using the template for cross-chain deployments here, however I do want to further clarify some of the information.

@ishaan

• Does the bridge support arbitrary message passing?
• Yes, once the relevant connector will be deployed

So to clarify here - it sounds like today, the bridge does NOT SUPPORT arbitrary message passing. Can you confirm? If this is correct can you please edit in the Consensus check (if Temp check is passed).

Will there be an audit of this contract prior to going live? Uniswap governance would be the first user of this connector contract?

@ishaan

• Is the bridge secured by a trusted entity, by a multi-sig, or a protocol/set of incentivized nodes?
• The bridge is secured by multi-sig. Security is provided by implementing light-clients of both networks on the counterpart network: Ethereum light client on NEAR and NEAR light client on Ethereum.

Can you further clarify how this works?

Who are the members of the multi-sig? What is the difference between the Relayers and the multisig?

Is there a risk that the multi-sig could be subject to a Ronin or Horizon style hack which could send a malicious message of the type described above?

@ishaan

• Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is the security provided by another third-party entity?
  • Rainbow bridge leverages both chains’ security (Ethereum and Near) through the use of Provers on both chains: EthOnNearProver NEAR contract in Rust and NearOnEthProver Ethereum contract in Solidity to verify Ethereum events and Near contract execution results. On Near, trust relies that at no time, 2/3 of the validators stake are honest. Not only the bridge, but also all other applications on NEAR operate under this assumption.

Can you clarify this - where does the multi-sig come into play?

@ishaan

• Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?

  • The rainbow bridge is based on trustless assumptions with no selected middleman to transfer messages or assets between chains. Because of this, anyone can interact with its smart contracts. When players with bad intentions submit bad information, it would be challenged by independent Watchdogs watching the Near blockchain. Similar attacks on the Rainbow Bridge have been dismissed resulting in the loss of the hacker’s funds

• What are the ramifications of fraud to the malicious actor?

  • The bridge requires having a watchdog service that monitors submitted NEAR headers and challenges any headers with invalid signatures. For added security, independent users can run several watchdog services. In the event one entity runs a majority of the watchdogs, fraudulent messages can be processed

Who are the watchdogs? How many are there, and how are they incentivized?