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

[raz]

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.”

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.

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.

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.

@GFXlabs

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

• Docs
• Ethereum Endpoint
• Ethereum UltraLightNodev2
• L2 Beat

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.

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.

@GFXlabs

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.

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.

@GFXlabs

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.

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.

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.

@GFXlabs

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.

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.

@GFXlabs

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.

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.

@GFXlabs

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.

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

@GFXlabs

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.

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