This will be our (Stanford Blockchain) final post here in this thread. More posts revolving around this issue can be found at Cross-Chain Bridge Assessment Process.
To save time and be succinct, we will focus this thread mainly on the top two contenders, LayerZero (LZ) and Wormhole (WH).
We would love to discuss further around other protocols in the thread above.
First at foremost, we enjoyed chatting with different bridge providers and their advocates. We believe as contentious as this vote is, this will not be the end for the cross-chain (x-chain for shorthand) governance discussion but the beginning.
TLDR
We believe regardless of who will win the vote, this result should be temporary and should be immediately changed/updated when the Cross-Chain Bridge Assessment Process concludes. Our vote only convenes that we support the following protocol for a period of fewer than three months. In long term we believe Multi-Message-Aggregation (MMA) is the solution.
We have voted for LZ as the current preferred bridge provider. However, our vote is contingent on a few criteria. If LZ cannot fulfill these criteria, we wish to withdraw our support.
- Uniswap governance message passing will use Uniswap-community-run oracle and NOT the default oracle by ChainLink.
- The Uniswap-community-run oracle is mainnet functional no less than 3 days after the passing of the snapshot vote.
- The Uniswap-community-run oracle have no less than 5 independent signers.
- LZ will provide sufficient technical support for all oracle signers.
If LZ fails to deliver on ANY of the criteria above, Stanford Blockchain Club will NOT support LZ being the bridge provider for Uniswap governance.
Quick word:
We want to say that although the current snapshot will only have one “winner,” it does not mean the work other bridge providers did is wasted. In the next three weeks (laid out in the Cross-Chain Bridge Assessment Process), we would love to continue these conversations and find a long-term and more sustainable solution for x-chain governance.
As we have briefly mentioned in our previous posts (1,2), none of these solutions fits all our requirement and all of them poses serious governance risk to Uniswap; therefore we should not just decide once and move on from this issue. Instead, we should take UF’s proposal seriously and contribute more if not less time and energy to it.
Some key risks: Both WH and LZ’s oracle/relayer networks lack a slashing mechanism for malicious oracles. WH’s contract can be upgraded (can be patched with workarounds). LZ’s relayer is currently just LZ’s core team.
On bridging:
At Stanford Blockchain Club, we understand the difficulties of building bridges and more importantly, the current security gap between any bridge and the Ethereum network. We also recognize how early bridging technologies are and the security assumptions for these bridges might be drastically different from traditional blockchains.
We are not making statements about future designs of these bridges or what they could be; we are stating what we are seeing right now.
LZ and WH on a high level are both multisig bridges.
WH is a 1/1 multisig, with the 1 being 19 validators forming a 13/19 multisig.
LZ is a 2/2 multisig, with 1 being 5 Uniswap members, and the other 1 being LayerZero Lab.
If Ethereum’s current security level is 100, what would you assign to LZ and WH?
Therefore, we would not choose either of them to be the sole message-relaying solution for Uniswap long term. However given we have to make a decision now, we believe the LZ solution is the marginally better one.
Use all of them:
We believe the correct near-term solution is message aggregation from multiple bridges.
From our conversation with bridge providers and other delegates, we believe this is the most logical next step for x-chain governance in Uniswap.
We have proposed an in-depth design on the other thread, but this graph captures it well.
The governance flow is as follows:
- Uni Gov passed on Ethereum.
- Payload to different bridge contracts sent from Timelock.
- Different bridges relay to
dst, BSC in this case. - Bridges send governance payload to
Message Selection Contract. - A 11/15
multisigdecides which message payload to execute.
Security analysis and design trade-offs are discussed more in the post.