[RFC - Update] Deploy Uniswap v3 (1 / 0.3 / 0.05 / 0.01) on BNB Chain (Binance)

Proposal Discussion
49

Hey everyone,

Porter and Guy writing from a16z. Given the expiration of Uniswap V3’s BUSL license in early April, we’re generally in favor of deploying Uni V3 to other chains before that date to avoid the copy-paste rush that will likely ensue otherwise. This has the added benefit of ensuring there’s an official deployment cycle so users on those chains can trust they’re using the original code base – preempting possible bad actors or just carelessness. Deploying Uni V3 obviously won’t forestall forks from occurring, but at least it offers an official version to users seeking that forum.

Additionally, as @devinwalsh’s comments suggest, we would also be in favor of a more formal process for choosing third party service providers or integrations for Uniswap going forward.

In our eyes, it’s important that Uniswap is able to create a level, objective playing field for all parties wanting to build or aid in its development. The community remains the ultimate decider once those conditions are set, but it’s key to foster a structured process that enables outside parties to fairly compete on the merits of their proposal. Like anything else, this competition benefits Uniswap long-term as a credibly neutral, market-based platform. It should receive the best services, at the best prices (if pricing is included) by choosing from the widest selection of parties given the same set of operating instructions. A structured process allows time for appropriate due diligence, weighing of pros and cons for each provider, and a comparative analysis that is difficult to conduct otherwise.

For transparency and timing, and because an end-to-end process has not fully occurred for this particular vote, the second part of this post outlines our preferred choice for Uniswap’s bridge provider.

To that end, we believe that LayerZero offers the best bridging solution – for transparency, we invested in them. We believe they are the most secure, decentralized, and philosophically aligned partner for Uniswap. Full investment disclosures can be found here. You can read our original investment thesis here for historical context.

LayerZero uniquely offers the capability for Uniswap to own its own immutable smart contract, while also enabling Uniswap to change or upgrade the security model of the bridge at the community’s discretion in the future. They’ve also delivered: LayerZero built out an omnichain governance module for Uniswap, found here.

Our support in LayerZero’s offering stems from its:

(1) Immutability - Uniswap can deploy LayerZero’s contracts and own them without having a dependency on LayerZero. Other bridge deployments can be changed by the bridging provider, but Uniswap could choose to be the only one with the capability of upgrading its bridge.

(2) Open and permissionless nature - LayerZero is open source, modular, and ownable by the applications that integrate it. Please see LayerZero’s implementation for a Uniswap governance executor open source here. Uniswap can future proof its deployment by choosing the oracle, relayer, validation library, and blockchain confirmation parameters in its deployment.

(3) Creation of extendible immutable validation libraries - LayerZero is building multiple validation libraries and provides the most modular bridging architecture we’ve seen. Uniswap could choose to implement a new validation library (a ZK light client for example) when it becomes battle tested. Importantly, this upgrade could only be done by Uniswap itself. LayerZero enables Uniswap to own and run its own bridge.

To highlight a critical point, LayerZero alone offers the ability for Uniswap to run its own Oracle or Relayer network using the LayerZero architecture, providing the most secure and modular message delivery system because Uniswap itself is participating in its execution. If the Uniswap community sets its oracle, relayer, validation library, and block confirmations in the endpoint settings, there is nothing anyone else can do to change it – it is immutable and only in the hands of the Uniswap community. This embeds flexibility to also take advantage of future cryptographically secure validation layers.

Others have brought up the core concern of security considerations. To date, LayerZero has processed over $5B in transactions with over 700 applications deploying 2,000 contracts without a single hack. Other bridge providers cannot point to this track record. Past performance is not an absolute guarantee of future success, but it is a strong indicator. To @GFXlabs’ first evaluation criteria, “How long has the system been running, and how much value has it been responsible for?” In our opinion, LayerZero has a demonstrated track record of success at scale that is unique amongst bridge providers.

In this vein, cross-chain Uniswap deployments should not compromise the decentralization of the protocol unduly, or introduce unnecessary risk without careful consideration. We do not believe that arbitrarily upgradable contracts owned by the underlying bridging provider or controlled by an external third party are in line with the ethos of community-centric, decentralized governance. LayerZero offers a credible alternative to that reality for the Uniswap community.

While we currently believe LayerZero is the best option, we will evaluate any other proposals in good faith and ultimately vote for what we think is best for Uniswap.

We appreciate everyone’s time and consideration.

5 Likes
50

We’re supportive of this plan of action (new snapshot soonish, gov vote close behind) for this particular case. Also very much into pursuing both a formal review process for bridge providers and investigating a multi-bridge solution as @AlexSmirnov lays out in a subsequent comment as a separate endeavor following the BNB Chain. I think each of those subsequent actions require some thought around the resources that’ll be required for their implementation and we’d be better served considering them in isolation rather than as a component of another proposal.

3 Likes
51

Hello! Chiming in on behalf of Blockchain at Berkeley:

We want to echo earlier statements by @devenmatthews and express support for the points raised by @modong @AlexSmirnov @Kydo and others that a multi-bridge, no lock-in solution is essential for the future health of cross-chain UNI governance.

Given the ongoing scrutiny and cooperation with the bridge providers, we believe that a temperature check for specific bridges at this stage may not be the most effective approach.

Currently, it is difficult to make a point-to-point comparison between the proposals from the four main contenders, since there is not enough detailed information on the proposals. Providing detailed, finalized proposal summaries from the bridges is essential for the community to decide on the best providers to move forward with.

It is important to note that there are some concerns regarding all the existing bridge providers and their ability to fully meet the needs of Uniswap’s governance message passing. While we recognize that each provider has its own unique strengths and weaknesses, it is essential that a thorough evaluation of all proposals is conducted to ensure that the best solution is chosen for the community. In particular, issues such as decentralization, economic incentives, and transparency of operations should be carefully considered before making a final decision.

Furthermore, we suggest that it may be beneficial to consider an alternative approach, such as outlining specific requirements for the ideal Uniswap bridge and choosing a vendor based on their ability to meet those specifications. This could help to avoid the “lesser of two evils” problem and ensure that the best solution is selected for the community.

2 Likes
52

Thank you Blockchain at Berkeley team. As promised, we will be providing a reference implementation very soon for this. The difficulty level of implementing a multi-bridge solution is not really harder than implementing a single-bridge solution.

2 Likes
53

Hi all, note that the Snapshot poll on which bridge to use for the BSC deployment is live now: Snapshot

1 Like
55

We’ve recently had open discussions with many of the delegate groups around the security features and fundamental architecture of LayerZero and its fitness for secure and scalable omnichain governance for the Uniswap protocol. The following are key topics and outcomes from the discussion shared publicly for the community’s awareness:

—LayerZero’s omnichain governance executor (complete open source code here) is designed to enable Uniswap governance to add, remove, or swap validation layer components directly from on-chain votes via GovernorBravo.

What this means: Security of the protocol’s cross-chain governance can scale with the protocol over time. Governance always maintains the ability to propose and vote to change parameters which, if passed, are executed on-chain via GovernorBravo and amended in the smart contracts owned by Uniswap.

—LayerZero created and deployed a gasless oracle for applications to participate easily in their own security

—Major Uniswap delegates and top stakeholders (such as the most strongly incentivized investors of the protocol, L1/L2 Foundations, and major security and infrastructure platforms) can run a gasless oracle as part of the network.

To provide additional context, several of these organizations are already actively involved in the ongoing decentralization of LayerZero’s validation layer.

What this means: We’ve implemented a gasless signing mechanism to allow a group of ad hoc parties to easily manage an ad hoc oracle network between them. The gasless oracle is a brand new feature we had planned to announce in late February; documentation will be completed shortly. The LayerZero Labs team will commit dedicated human capital and technical resources to assist teams to fully run the node; estimated set-up time is less than 2 hours from end-to-end per team.

We propose that Uniswap utilize a gasless oracle of at least 5+ signers. We recommend a consensus grouping of the most respected industry entities and aligned parties with Uniswap (which Uniswap has already done an amazing job attracting via its Delegates) which will provide the most secure and aligned security structure to the protocol itself.

—We propose that at launch, Uniswap chooses to pair a gasless oracle run by a minimum of 5+ significant Uniswap delegates and the LayerZero Labs relayer as their validation layer within the broader LayerZero security model.

In the future, governance may choose to update these hyperparameters via an on-chain governance process enabling robust, flexible, and governance driven security.

We thank the delegate groups who reached out to us for their time and commitment to Uniswap governance and look forward to conversations with more stakeholders over the coming days.

7 Likes
56

I’m voting for LayerZero because based on my reading of the thread & professional experience I believe that is the best option.

I would note though, if there was an abstain / wait option I would’ve chosen that. I do not believe this is the type of decision that is well suited for a token vote. I’m a big fan of @devinwalsh’s plan to form a committee to evaluate options in depth and I would follow the recommendations there.

I also question if a bridge is even strictly needed right now. Since its only bridging governance commands presumably this could be added later? I’d prefer that option.

3 Likes
57

Adding my own two cents here, for context we provide security audits to both LayerZero and Wormhole.

The security models are quite fundamentally different, but both bridges - as far as we can tell - care very deeply about security. In my opinion, the primary question voters should evaluate is which security model/assumptions they think is more suitable for Uniswap, as opposed to the implementation risks which are relatively minimal.

1 Like
58

Thank you for posting this updated proposal, LayerZero.

We believe this proposal addresses a lot of the questions we have raised before. And their ability to change Chainlink with a set of Uniswap-aligned oracle validators is very promising.

For total transparency, LayerZero reached out to us and addressed most of our technical concerns.

One thing we believe we undervalued, in our initial assessment, is the immutability of the bridge. Many hacks happen because of simple upgrades. Under LayerZero’s design, the underlying infrastructure (LayerZero protocol) is immutable. The changeable parts, the Oracle (header sync) and Relayer (MIP), can only be changed by Uniswap governance.

Given the immutability and LayerZero’s new proposed Oracle, we would like to signal to the community that we have tentatively moved LayerZero as our preferred bridge provider for BNB.

We would also love to see more documentation provided from LayerZero’s side, especially around the oracle and relayer services.

3 Likes
59

Hi Everyone,

Several folks have asked for our opinion on the current vote and the abnormal governance process. First, we would like to emphasize that the overall goal here is to deploy UniV3 on BSC in the near future, and we have been pleasantly surprised by the demand for the DEX to deploy on BSC. As for the abnormal governance process, we’re supportive of the Foundation’s move to post the Snapshot so Ilia can finalize the BSC deployment and their proposed working group to conduct a thorough review of each bridge.

GFX Labs has cast our vote for Wormhole in the current snapshot, and while we’ve made our concerns about Celer clear in the forum thread, we haven’t done the same for Layerzero.

Our primary resources for researching Layerzero

For context, Layerzero messages are sent from the local Endpoint. Oracles are responsible for moving block headers from the source to the destination. Upon delivery, Relayers can deliver the transaction’s proof to the destination Endpoint. This model, in its current implementation, is a 2-of-2 msig.

Messages are sent to a verifying library. The verifying library (VL) manages oracles and Relayers on behalf of the application. The Ultra Light Node (ULN) is a VL. The Endpoint manages the relationship between the user application (UA) and the VL (the ULN, in practice). The UA selects a VL via the Endpoint. The UA may also configure that VL directly (e.g. by selecting a Relayer in the VL). Relayers submit proofs to the VL (the ULN, in practice), and the VL chooses how to validate these. In the ULN, the owner chooses proof validation libraries and may choose any contract.

Applications are intended to choose their own VL & Relayer since they can configure which library to use in the Endpoint contract. The Endpoint owner sets a default VL. However, the ULN is the only verifying library that exists, so all apps must use it.

We tried to review how the Relayer worked, but according to the docs the Relayer is not open-source at this time, which seems to line up with L2Beat’s concern of the Relayer contract being unverified.

Additionally, the only info we found in the governance section was “info coming soon!” This was not the answer we were expecting since there is an owner on the Ethereum Endpoint and UltraLightNodev2 contracts. The owner appears to be a 2/5 Gnosis Multisig. While the Endpoint isn’t a traditional proxy contract, it does rely upon referenced contracts for core logic and operation. The below owner controllable functions appear to be able to alter the functionality significantly.

onlyOwner functions on the EndPoint contract:

  • setSendVersion
  • setDefaultSendVersion
  • setDefaultReceiveVersion
  • renounceOwnership
  • transferOwnership

onlyOwner functions on the UltraLightNodeV2 contract:

  • setLayerZeroToken
  • setTreasury
  • addInboundProofLibraryForChain
  • setDefaultConfigForChainId
  • setDefaultAdapterParamsForChainId
  • setRemoteUln
  • setChainAddressSize
  • renounceOwnership
  • transferOwnership

The ULN’s owner can set the oracle, relay, proof systems, and other security parameters. It appears that the owner can entirely bypass the oracle/relay system in their current implementation.

Through this process, we arrived at the conclusion that Layerzero is not ready to be integrated with Uniswap. However, as developers ourselves, do we realize that the development process is fluid and that research is ongoing. Our vote reflects the current state of development and available information.

1 Like
60

Hi raz from LayerZero.

So I want to first say we’ve never spoken to GFX Labs (despite reaching out) and although we now have time scheduled tomorrow (Monday), this analysis was written without a single question sent to us. I’ve gone through and done a line-by-line response to everything above but wanted to tl;dr some of the obvious mistakes in the analysis in case they get lost below in the broader post.

Firstly, GFX Labs missed the _getAppConfig() function which is the very first line of validateTransactionProof() with comments “Retrieve UA’s configuration using the _dstAddress from arguments.”

1
11600×149 106 KB

Taking a look at this function, you can clearly see that the first thing that it does is retrieve the User Application’s config and the default config.

2
21600×113 87 KB

Then it goes through each config item and if and only if the configurations are not set, the contract sets it to the default config item.

3
31154×150 17.7 KB

The crux of the GFX Labs argument seems to be centered around the perceived ability for the LayerZero ULN owner to be able to modify application parameters, however this is clearly not possible and enforceable in the immutable base layer of the code.

This seems clearly misleading as the two parties (oracle and relayer) are abstracted accounts with arbitrary implementation e.g. a fully decentralized network, not to mention the current proposal which I had assumed GFX Labs had reviewed extensively prior to this is for a new architecture with a number of major Uniswap delegates participating within the validation set.

The owner of the ULN contract cannot choose proof libraries on behalf of the user application. The owner can only add new proof libraries (i.e. append-only registry) of which the user application can select from.

The ULN can hold multiple validation libraries within itself for applications to choose from (ex. A zk-Validation Library could be added to the ULN V2 as a different method for verifying messages). This is an explicit design decision; LayerZero’s architecture supports the evolution of best cryptographic security practices. These libraries and the ULN itself are immutable and only by selection of the user application.

Most other bridges and messaging protocols offer blanket validation techniques and only upgradeable smart contracts. Many notable hacks have occurred due to a buggy upgrade forced upon applications built on top of a bridge’s infrastructure, including two identical instances from Wormhole resulting in a $10m bug bounty paid and then later reducing their bug bounty from $10m to only $2.5m.

4
41600×381 161 KB

To be clear, both of these issues are completely separate from the $325m hack Wormhole suffered.

We believe critical infrastructure should be immutable, open source, and always owned by user applications.

It is common practice to not open source or verify Oracle and Relayer smart contracts. These smart contracts are only responsible for on-chain quoting in gas. All validation logic resides immutably in the messaging library. In a competitive marketplace of Oracles and Relayers, unique pricing mechanisms are often the proprietary edge for providers. These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.

The governance section of our documentation is in reference to the upcoming open source governance module we proposed in this forum thread (see above).

The Endpoint Contracts are for setting default configurations for developers to be able deploy and test easily. It is recommended that applications desiring more control over their security opt to set their own configuration settings. Default configuration cannot override user application configured settings; this is an explicit design decision and a feature of a true protocol.

The UltraLightNodeV2 settings are a combination of default configurations and one-time setters for adding new chains and proof libraries. The multisig owner cannot change any existing configurations set by the user or modify any existing validation libraries.

This statement is both entirely verifiably false and addressed in the opening part of the post.

I hope the line by line was helpful. I know we haven’t gotten to speak yet but looking forward to speaking to GFX Labs tomorrow and addressing any outstanding concerns and walking through the proposed security configuration in detail.

-raz

5 Likes
61

Hey all, it’s Abdullah from Blockchain at Michigan

Firstly, we are glad to see the community’s ability to coordinate an unorthodox approach for deciding the Uni<>BNB bridge via an extra temp check. In an instance like this, it is imperative that we derive a quantitative measure for what the community is feeling as opposed to a soft metric like forum-based sentiment.

To that end, we believe that instead of prolonging the bridge discussion beyond necessary means, it is important for us to efficiently decide on a single messaging system. After one solution is implemented, we can focus on a multi-bridge system. The primary reason for this haste, as @Porter mentioned, is the limited amount of time we have to deploy Uni v3 prior to the license expiring on April 1st of this year. Perhaps this urgency is not warranted for other L1s–but for BNB Chain, quick deployment is necessary due to the BNB community’s hankering to quickly deploy forked code (the BNB ecosystem is very much quantity over quality at the moment) and capture much of the present user activity.

As of now, we are inclined to side with LayerZero for handling cross-chain governance. We put Wormhole and Celer in a similar bucket due to their reliance on a validator set, emblematic of a proof of authority mechanism. Naturally, such designs are less decentralized and subject to collusion.

Potentially, Celer’s current total stake is not large enough from a dollar-value standpoint to be secure. Over time, this should resolve since the ability of an entity to buy up 2/3 of staking dominance will become harder–granted the SGN system proves viable over time and the CELR token remains strong. As for Wormhole, they have stood the test of a major exploit and have since made their system more robust, with a continual promise to prevent future exploits via a large bug bounty program and a multitude of audits. However, our main contention with Wormhole is, again, the limited 19-entity validator set. We realize the credibility of the guardians and how much stake they have to lose from a reputation perspective. But when the going gets tough, entities often focus on doing whatever they can to merely survive, forgoing their pristine reputation.

We are not limiting the merits of Wormhole or Celer; however, we feel that when the option to select a system that allows for a higher degree of control over the messaging stack is present, we should select that method. LayerZero would allow the Uni community to control its parameters (oracle and relayer) however it deems fit without the risk of collusion between a handful of validators. Yes, the risk assumption for LZ is that the relayer and oracle are themselves uncorrupted–Uniswap is not likely to face this issue. Unlike other applications using LZ, Uniswap has a robust, distributed governance base. The alteration of the relayer and oracle would require the community to collectively decide parameters, making malicious activity very difficult. That is, unless a hacker alters the parameters by subverting the governance process somehow.

We will cast our vote later tonight after our final discussions with Jump and LayerZero.

4 Likes
62

Hi Raz,

We devoted a chunk of time to reviewing and researching a bit over the last few days. The questions and concerns raised in our message come from our good-faith efforts to review the resources available. To recap, as part of our review of Celer’s system, we identified significant differences between what was advertised and what is actually happening. Since then, we’ve been attempting to verify anything we read on the forum as part of our own due diligence process.

We have made efforts to review each bridge with the limited knowledge and resources we have available. While we have a pre-relationship with Wormhole, GFX only works with projects that we believe in and have first-hand knowledge about. Our primary duty, however, is to advocate for Uniswap’s success. While our post might, in hindsight, contain some inaccuracies, it was made with good intentions after reviewing publicly available documentation and included an open offer to utilize your technology — importantly, many of the core criticisms remain.

Regarding the only owner functions. We’ll edit our prior post to reflect that change. Thank you for the clarification.

LayerZero is running the Relayer, and Chainlink is running the Oracle. While these are independent entities of which multiple could theoretically exist to process messages, only two exist at this time. This is functionally a 2/2 multisig, both parties must agree; otherwise, the message will not be processed. We were able to find information on how to run an oracle, but as you said, the existing relayer is currently closed source, and we cannot find an MVP example for a full relayer setup (both on and off-chain components).

  • Could you help us understand what would happen to message passing if either of these two systems went offline?
  • What would happen if the two systems colluded?
  • We assume the goal is to have multiple relayers. Can you estimate when you think the code or simpler version of the relayer might be released so additional members can participate?
  • What is the incentive for new participants to join the system as an oracle or relayer?

As for the unique signing model proposed, we’ve discussed with a few delegates about utilizing a multisig for UniV3 deployments over a bridge and came to the rough conclusion that delegates would not be comfortable being on that multisig due to the perceived legal risks. Our intent is not to need additional signers. Thus our efforts have been put toward finding a bridge partner. The recommendation of additional signers seems to speak to the lack of parties participating in Layerzero 0.

Suppose Uniswap was to consider the signer method. Would it not make the most sense to utilize Chainlink’s Oracle system directly, with the Uniswap signers filling the role as the relayer? It seems that would be the strongest combination because the alternative would be to remove the most secure component (Chainlink) from the stack and replace it with the least secure solution (Uniswap Signers).

To make sure we are on the same page - is this also the only current possible configuration, assuming that Uniswap does not take charge of the Oracle or Bridge duties?

If this is the case, then what is the true cost of using L0 as a relayer? Assuming that Uniswap will not move to run its own relayer, is there any other mechanism to prevent a monopolistic relayer from price-gouging messages through an upgrade? If not, how quickly would Uniswap be able to modify its cross-chain infrastructure such that it could continue performing cross-chain messaging at a reasonable price?

Thank you for the clarification.

While that makes sense, we think it would have saved a lot of time for everyone if the owner functionality was better documented.

Thank you for the prompt answers. We appreciate the clarification, and I’m sure the other delegates reading the thread do as well.

As a final request for now, can you please deploy your proposed system on testnet and link the relevant transactions as we have done with Wormhole? We don’t want to delay the BSC deployment any further than necessary.

1 Like
63

I like the new governance flow, but it is difficult to find the snapshot post/link in this thread. Have to keep scrolling up to find this post, when checking on the vote status.

A suggestion if possible: have a “snapshot is live” button under the thread scroller on the right side where the “reply to thread” and “notifications” buttons are.

1 Like
64

Throwing in some comments here. We’ll preface by saying that considering how “unexpected” this discussion arose, we appreciate the UF team for their quick thinking and on the feet decisions.

When looking at the main debate surrounding L0 and Wormhole, we’re still internally conflicted on which is ultimately the best, and think each has benefits of their own. Ultimately, we don’t think this proposed structure of finding a bridge partner is ideal and sets a bad precedence. We propose:

  • A working group that gets set up will “whitelists” all bridges looking to be a bridging solution. This can be confirmed with a governance vote if deemed necessary.
  • Once a bridge passes this step, they will enter an “approved” pool
  • When “x-chain” wants to deploy, they can work out individual relations with any “approved” bridge as their partner
  • As @Kydo mentioned with us, the partner bridge for “x-chain” can be multiple bridges that cross check each other and can decrease further the chance of malicious actors.

Overall, this reasoning stems from: 1) we believe there are multiple valid bridges/solutions to this question. 2) Combining L0 & Wormhole & maybe other bridges with a majority rules outcome will present the best security 3) Puts incentives with bridges and “x-chain” better in our opinion to market compete in each situation.

3 Likes
65

Just to be completely objective when we are choosing a bridge for Uniswap v3, I ask all community members also to read the report published today by James Prestwich, regarding the potential vulnerabilities in LayerZero contracts.

@GFXlabs @pennblockchain @AbdullahUmar @Kydo @Porter

:exclamation:Full article: ZeroValidation - by James Prestwich - Proof of James

We are very much looking forward to the comments from the LayerZero team @raz , as our snapshot bridge poll is coming to an end tomorrow.

3 Likes
66

I would say that’s one of the least objective posts of all time. I responded to it here albeit in not a very formal tone and I’d like to state clearly that it’s both wrong, misleading, and has absolutely 0 impact on the proposed Uniswap architecture because as discussed in the proposal Uniswap would not be using the defaults and would be selecting their own oracle, relayer, and VL.

7 Likes
67

Did anyone consider Axelar?

With Osmosis opting for it over Wormhole in their search for a canonical Ethereum bridge, which some might argue was more thorough, I think it’s worth considering.

1 Like
68

Thanks for the clarification, Bryan!

69

Yup 100%! Just want to make sure there is clarity