On Running Infrastructure and Bridges
There’s been a lot of back and forth in the thread around immutability, decentralization, trusted entities, and degrees of control by cross-chain messaging protocols. We wanted to clarify these discussion points by calling out the two ways Uniswap would integrate a messaging layer and comparing the guarantees of both Wormhole and LayerZero under each scenario.
Simply put, the two scenarios are:
- Uniswap runs infrastructure
- Uniswap doesn’t run infrastructure
Uniswap runs infrastructure
LayerZero
LayerZero suggests that integrators can either use their “default” configuration, a low-security option or run infrastructure via a “custom” configuration.
The latter model is proposed as the method by which the application developer (in this case Uniswap) can avoid collusion risk between the default Oracle and Relayer infrastructure operators within LayerZero. Additionally, in this model, Uniswap or its delegates would need to run infrastructure such as a “gasless Oracle” (which has not been released yet), which the LayerZero Relayer would pick up and deliver to the destination. Relayers in LayerZero are always permissioned and are required for liveness and security, thus Uniswap would also have to run Relayer infrastructure. The Relayer source code is currently not open-source, so Uniswap would need to implement a bespoke untested solution or run LayerZero’s proprietary implementation.
However, this may still be problematic. Due to the Proof Library requiring ongoing mitigation with each chain, a non-default config is **insufficient until the issue above is addressed. The LayerZero team can add a new default chain config, register a default proof handler, and exploit an application in a single atomic transaction. The application cannot mitigate this using configuration. Applications can only mitigate via a custom relayer and potentially an “approved chains” list in the application itself. The flagship application on LayerZero, Stargate, itself is semi-immutable and will have a difficult time mitigating this issue, and would need to make a custom Proof Library to implement the approved chains list.
TL;DR — if Uniswap does not want to trust LayerZero’s current default configuration, it needs to run its own infrastructure. Even when doing so, there are underlying issues that necessitate further action from LayerZero’s team to truly make any custom infrastructure setup truly trustless.
Wormhole
We want to clarify that if Uniswap wants to run its own infrastructure with Wormhole, it can achieve the same level of customization that LayerZero touts, as no protocol has a monopoly on deploying bespoke infra. If desired, Uniswap can configure a deployment of Wormhole, which improves upon the security guarantees of LayerZero’s default while also ensuring sovereign security relative to the canonical Wormhole deployment.
Wormhole’s contracts are designed so that the Guardian set is customizable on initial deployment (see here: Setup.sol) and can further be rotated via an in-protocol governance mechanism whereby the current guardian set can vote on the next guardian set. Should Uniswap delegates decide to run their own infrastructure, they may run their own oracle nodes by following instructions at Operations.md. In this model, Uniswap oracles produce signed observations (VAAs) which can be submitted permissionlessly on the target chain (BNB), so no relayer infra is needed, and therefore no need to manage gas funds. However, relayers can very easily be made permissioned if desired, which would allow Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
From a security and operational load perspective, however, we could offer Uniswap to layer their signers on top of Wormhole i.e. extend the already robust Guardian set with their additional validators. This option surpasses the level of flexibility and security of LayerZero’s oracle (in this case Wormhole) and Relayer (chosen by Uniswap) mode in which Uniswap benefits from Wormhole’s significantly more robust signer set but is safe as long as the signer set does not collude with the Uniswap chosen signers. We start from the far stronger base of 19 signers and can arbitrarily increase security beyond that with additional Uniswap-affiliated validators. The easiest way to produce these additional signatures is for the Uniswap DAO signers to download and run the existing, open-source, and in-production Wormhole oracle software. After verifying the Wormhole signatures, the Uniswap governance contract can verify these additional signatures from the selected Uniswap DAO signers. Additionally, relayers can very quickly be permissioned, allowing Uniswap to run a permissioned relayer like the one discussed in the LayerZero model.
While the proxy contract can point to different implementations, the Wormhole implementation contract is immutable. Thus it is trivial to verify governance messages against a specified implementation. While there are multiple ways to accomplish this, the most straightforward is just including the pinned implementation as an external library in your deployment.
This deployment can be done in a fully permissionless manner without having to trust (or ever interact) with the 19 Guardians that operate the default Wormhole deployment.
Uniswap doesn’t run infrastructure
LayerZero
The security assumption of LayerZero’s default configuration is that the default Oracle and Relayer are independent. Uniswap would have to trust a 2/2 multisig of these two components. The relayer is unverified, but LayerZero claims that this is not an issue:
“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.
[…]
*****These smart contracts can only quote pricing and do not affect security in any way, therefore being verified is irrelevant to its purpose.”
This statement contradicts with the LayerZero whitepaper, which claims the following:
“Given two entities that do not collude, if (1) one entity can produce a block header for the block containing tA on chain A, (2) the other entity can independently produce the proof for tA on that block (transaction proof), and (3) the header and transaction proof in fact agree, then the communication protocol can deliver m to the client on chain B with the guarantee that tA is stably committed on chain A.”
The Oracle is responsible for producing the block headers, and the Relayer is responsible for the inclusion proofs — these responsibilities are far beyond on-chain gas quoting.
“LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).”
At this point, it’s unclear if there are other Oracle/Relayer options available to choose from outside of the default. In any case, if the Oracle and Relayer collude, they can forge messages.
Contract upgradeability is a critical discussion point. It’s true that bugs can be introduced in upgrades, but upgrades can (and do) fix existing bugs. Presenting only one side of this coin is misleading at best.
If any bugs are discovered in LayerZero’s contracts, patching them would be a significant task. Such a scenario would involve the proof validation code being implemented with a patch, and then all affected user applications would have to change their configurations to the patched implementation.
Wormhole
The 19 Guardians that operate Wormhole’s default deployment are the largest PoS validator companies. The safety assumption is that of an honest superminority (at least 7 of them are honest) or, conversely, that there are no 13 colluding entities. The equivalent assumption under LayerZero’s setup is that the 2 entities do not collude. The contracts are upgradeable via a governance mechanism that requires the approval of 2/3+ of the Guardians. Importantly, the Wormhole cross-chain governance solution has already been tested (see above) and implemented on testnet and is ready for production.
Happy to answer any additional questions.