Proposed implementation of a Vendor-Lock-in-Free Universal Governance Mechanism for Uniswap
We appreciate deBridge being included as one of the solutions proposed in the temperature check, but we’d also like to support points raised by @Kydo and @modong and express concern that the current temperature check process seems rushed in the sense there are options proposed by participants of the discussion that have not been explored. Moreover, we agree with Kydo and Mo that Uniswap should not lock in one vendor when the possibility of choosing multiple exists with a similar level of complexity to the proposed single-bridge solution.
Uniswap must consider several key objectives — to achieve a decentralized and resilient solution with no one point of failure, and to enact a solution that is consistent with the stated goals and objectives of the Uniswap community. In order to achieve this, Uniswap must avoid reliance on any one bridge/interoperability protocol.
A bridge-agnostic solution
Thus, we present a bridge-agnostic approach for Uniswap Cross-chain Governance which suggests leveraging multiple bridges for passing Governance Actions to secondary chains, and executing such Actions only whenever each was delivered by at least a given number of trusted bridges.
At its core, we propose using a set of permissionless smart contracts on both chains (the master chain — Ethereum in this case — where Governance resides, and any secondary chain — BNB Chain in this case, though there can be more) which together form a permissionless multibridge transport protocol on top of existing battle-tested governance model for secured delivering and executing cross-chain governance actions.
Technical breakdown
The first layer of this approach is a permissionless Uniswap Multibridge Sender contract, which is directly controlled by the Governor contract. This contract is responsible for keeping the whitelist of trusted bridges Governance decided to use for message passing, and their corresponding permissionless Bridge Adapter contracts. Whenever there is a necessity to execute a Governance Action in a secondary chain, a Proposal to call a Uniswap Multibridge Sender contract is published using the existing workflow.
When a Uniswap Multibridge Sender Contract receives a Governance Action from a Governor contract, it triggers permissionless Bridge Adapter contracts for every corresponding trusted bridge. These Bridge Adapter contracts are needed to unify interfaces and behavior that are typically different across cross-chain bridges’ contracts. When the Bridge Adapter is triggered, it calls its bridge’s Gate/Relayer contract, passing the Governance Action as a message and specifying the address of the corresponding trusted permissionless adapter on the other chain as a receiver.
Every time the message is successfully broadcasted to the destination chain by any of the trusted bridges, it actually lands on the corresponding destination Bridge Adapter (as specified upon sending). This message is here transformed into a unified structure with technical metadata taken from the bridge’s gate/relayer. This metadata may include the address that actually initiated a cross-chain call.
The unified structure is then passed to the Uniswap Multibridge Receiver Contract, which authenticates the message by checking that it was sent by and received by trusted Bridge Adapters. Then, the actual Governance Action is extracted from the message and is passed to the Delegated Governor contract along with a bridge ID it was sent through for a staging phase.
A Uniswap Delegated Governor Contract accepts Governance Actions from the Uniswap Multibridge Receiver Contract it trusts, grouping them by their hashes and by the bridge IDs they were broadcasted through. Whenever the number of messages coming from different trusted bridges and shipping the same proposal reach the consensus (for example, ⅔ of delivered messages), this proposal is allowed to be executed normally, as it happens within the existing governance framework used by Uniswap.
A more resilient and decentralized solution
The beauty of this approach lies not only in the fact that it is completely bridge-agnostic and thus won’t get stuck due to a third-party failure, but also in fact this approach and any of its underlying components may be governed the same way Uniswap is governed: whenever there is a necessity to disable a specific bridge, or add another one, or change the expected threshold of delivered messages — a Governance votes for Proposals on Ethereum which emit cross-chain Governance Actions, which are then broadcasted and executed as prescribed.
In conclusion, this bridge-agnostic approach will better prevent message forgery while increasing the durability and deliverability of messages, creating a more secure solution that is consistent and compatible with the governance logic of Uniswap. Crucially, this design allows for flexibility and fault-tolerance in the event any participating bridge fails without recovery.
A lot of good business shapes for this approach are described in @modong’s comment
Finally, this generic framework is more scalable than the single-bridge framework — it can be replicated for additional chains, enabling Uniswap to integrate new chains efficiently and safely while having full control over bridge-selection (useful in the scenario the chosen bridge does not support a new chain).
If deBridge is chosen for the temperature check and further governance voting, the Uniswap-deBridge integration will be built in the context of this bridge-agnostic framework and thus, will enable other bridges to participate.