Kydo from Stanford Blockchain here. We would love to chime in on the bridging part of this discussion.
Message passing is hard. So please do not take the rest of this as criticism.
First, to echo a few things @devenmatthews and @GFXlabs said earlier.
No amount of dollars can help you forge a digital signature. So, we believe in the future, when cryptographically-secured message passing exists, Uniswap should heavily prioritize it (not choosing it straightaway since the complexity could also increase attack surfaces).
This is an important question to answer explicitly with data (this behavior → this slash amount, etc). Moreover, we would add that the provider should lay out how to become a validator in the network. This demonstrates how easy it is to collude across your validator set.
We should not lock in one vendor when the possibility of choosing multiple exists.
The recency of the audits is very important. These unaudited features, especially the
delay mechanism, should not be implemented by Uniswap before a formal audit is complete.
Moreover, if your system requires honest interactions with external third parties, you should clearly explain how the external third parties work or link to their technical documentation (in another thread).
Second, we want to explore further the A Vendor-lock-in-free idea from @modong
We believe the best way forward, especially after the Nomad hack, is to use multiple bridge providers for message passing. We do not believe this is theoretically hard but would require significant engineering hours. We would love to see more discussion surrounding this topic.
Lastly, here’s what we think about the current providers.
We do not have the expertise to analyze the actual implementations and understand the complexity levels of each codebase; so we made our decision based on the assumption that all these implementations (up to the most recent audit) are equally secure/insecure.
Our ranking is subject to change, based on answers provided by the service providers.
Our tentative ranking is as follows:
- Celer & LayerZero
To us, all these providers pose significant risks (relative to native L2 bridges or light client bridges). So, the ranking should not be taken at face value that any provider is “better” than another. Note: we are talking about using this for governance instead of a simple bridge transfer. So the evaluation criteria are a lot stricter.
We ranked wormhole as number 1 because of its diverse validator set. However, we would love to understand how does Wormhole penalize malicious validators? Does Wormhole have legally binding agreements with each validator? If so, what actions can Wormhole pursue?
We ranked Celer and LayerZero second. Celer has a decently sized validator set but the economic guarantee behind them is much weaker. I do not see that being a fixable problem, therefore I placed them (Celer) second.
LayerZero depends heavily on Chainlink’s oracle relay service. However, I was not able to find any information with regard to Chainlink’s implementation on their documentation or your website. Can you share more with regard to how does this specific chainlink oracle work? And if it is similar to Chainlink’s price feed, who are the
multisig signers (providers) for it? With regard to the relayer, other than LayerZero, is there any other entity running a relayer? If Uniswap wants to run our own relayer, can LayerZero commit human capital to assist us in running it?
We believe the best course forward is the Multi-Provider-Aggregation method. I would love to hear thoughts from other technical delegates on the difficulties of the design and a potential timeline.
If the above method is infeasible, I would recommend using Wormhole at this point. However, BNB Uniswap should have the ability to switch the message-passing provider at a later date through governance.
We hope @devinwalsh could open a new thread specifically for x-chain messaging outside this one since this discussion is going to be important for future and past x-chain developments.
Edit 2: Add clarification around ranking.