[Consensus Check] Fix the Cross Chain Messaging Bridge on Arbitrum

Proposal Discussion
1

Background:

On Ethereum, Uniswap Labs governance consists of a suite of smart contracts. However, in addition to its original deployment on Ethereum L1 mainnet, Uniswap contracts are also deployed on four additional domains - Polygon, Optimism, Celo, and Arbitrum.

Uniswap deployments on these domains do not have native access to the on-chain governance system, nor the UNI tokens which grant voting power in this system on Ethereum mainnet; in order for the existing Uniswap governance system to execute proposals governing these deployments, there must be some method of passing governance decisions from Ethereum mainnet to other domains.

Presently, this method has been implemented differently for each of the four chains. The system governing Optimism and Polygon follow similar design principles, and should be functional for passing proposals.

The system governing the Arbitrum deployment was mis-configured due to a mis-communication between developers, and will require more involved intervention to repair.

Problem:

Arbitrum was initially going to allow L1 addresses to pass calls directly to L2 with msg.sender preserved. After realizing security issues with this approach, Arbitrum team instead shifted their approach to use aliasing (this method transforms L1 addresses to be a different address when represented on an L2):

Uniswap Labs was not made aware of this change in approach before deploying on Arbitrum. The Uniswap Factory was deployed with the owner set to the same, unaliased address of the L1 Uniswap Timelock contract.
To verify, see: owner address Address 0x1a9c8182c09f50c8318d769245bea52c32be35bc | Arbiscan set at UniswapV3Factory | Address 0x1F98431c8aD98523631AE4a59f267346ea31F984 | Arbiscan
This address on Arbitrum is an EOA (not a contract) which nobody has the private key to control
The governance deployer key on Arbitrum has burned the nonce that could deploy a contract to this address, verifiable here: Address 0x41653c7d61609d856f29355e404f310ec4142cfb | Arbiscan
Therefore, nobody can execute governance proposals on Arbitrum in the current state

Solution:

To fix the cross chain messaging bridge, Arbitrum proposes the following:

  1. Final governance vote kicks off (after Temperature and Consensus checks pass).
  2. Before the vote passes, Arbitrum will add a temporary exception to disable address-aliasing for messages from the L1 TimeLock contract, 0x1a9c8182c09f50c8318d769245bea52c32be35bc. Arbitrum will notify the Uniswap community via the Uniswap governance forum once this is done.
  3. Once the final on-chain governance vote passes, the Uniswap governance contract will send a cross-chain message from the L1 Timelock contract to call setOwner on the L2 Uniswap factory, setting the owner to the L1 Timelock’s address alias, 0x2BAD8182C09F50c8318d769245beA52C32Be46CD.
  1. We will be able to see when this is completed on-chain. Arbitrum will re-enable aliasing for the L1 Timelock contract address. Once this is complete, cross-chain governance between Uniswap and Arbitrum will be fully functional.

Conclusion

Uniswap is currently the leading decentralized exchange by TVL on Arbitrum, and if this proposal passes the temperature check and continues along the governance process, it will strengthen the current relationship between the two projects.

Snapshot Poll: Snapshot

2 Likes