Cross-Chain Bridge Assessment Process

30

omnichain-governance-executor
omnichain-governance-executor1764×721 8.32 KB

1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.

Leading Adoption: LayerZero is the most widely used cross-chain messaging protocol by a significant margin (2k contracts deployed on mainnet, nearly 20k contracts on testnet). The protocol supports thousands of applications and has secured millions of messages and billions of dollars.

Longstanding Security: The protocol has never suffered a single exploit despite being deployed and used at scale. It is no coincidence that LayerZero is the most widely adopted cross-chain messaging protocol and also has never suffered an exploit. Since inception, LayerZero Labs has been committed to a set of best-in-class security practices (see below for breakdown). All of the core protocol code is immutable meaning the smart contracts cannot be upgraded by the LayerZero Labs team once deployed. In contrast, the majority of the stolen user funds ($3.1B in 2022) from cross-chain bridges and messaging protocols are attributed to upgrades made by cross-chain messaging teams and the consequent application contagion. Immutability matters.

Protocol Alignment: Uniswap is the gold standard for immutable and permissionless systems; the protocol was deliberately built with completely immutable core contracts and designed to limit risk exposure to the protocol while leaving some surface area of control to governance. LayerZero is built with the exact same principles: completely immutable core contracts and agency in the hands of (Uniswap) governance to control security hyperparameters. We believe the gold standard for a secure messaging layer is one that allows protocol ownership and transparency of immutable contracts.

2. How long has the system been running on mainnet?

11 Months

3. How much value has the system secured? (Current TVL, total transaction volume)

The system currently secures billions in TVL, has secured a peak of more than $8.4b in TVL and has processed more than $6b+ total transaction volume.

4. Provide a background on your team.

The LayerZero Labs team includes founders with multiple venture backed exits and leading engineers from AWS, Coinbase, the office of the CTO at Redhat and backgrounds in academia, research and algorithms for some of the most widely adopted technologies across all of the internet stack. We’ve also been backed by one of the strongest cap tables in the space, winning votes of confidence in the team and underlying technology from world class organizations such as Sequoia, a16z, Coinbase, Circle, and Uniswap Labs.

5. Please link your developer documentation.

6. Does the bridge support arbitrary message passing?

Yes, LayerZero’s arbitrary messaging primitive is described here.

7. Has the current deployed bridge code been audited? By a third party?hat attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?

LayerZero Labs has commissioned 35+ audits with the most recent audits on Github here. Nearly all code written by LayerZero Labs since inception have been immutable smart contracts audited externally and rigorously reviewed internally at least 3+ times each. LayerZero is the only major cross-chain messaging protocol to have secured significant transaction volume ($5B+) over time without any exploit, compromise of key infrastructure, or loss of user funds.

8. Is there a bug bounty program?

Yes, LayerZero Labs offers the highest bug bounty program in the world at $15m.

9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.

There is no part of the LayerZero protocol that is upgradeable. Our proposal has the Uniswap DAO in control of choosing its own hyperparameters so that only the Uniswap DAO can change with an on-chain governance vote.

10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?

Yes, the owner can set default hyperparameters for messaging. Our proposal has the Uniswap DAO in control of choosing its own hyperparameters so that only the Uniswap DAO can change with an on-chain governance vote.

11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?

At its core the LayerZero protocol allows the user application to set an arbitrary number of parties to attest the validity of a message between two chains. We propose that the DAO set Chainlink as the oracle and a consortium of Uniswap Delegates to act as a decentralized relayer network.

We have already spoken to a number of delegates who have agreed to participate as validators within the relayer, however should the DAO not wish to use this they can set an alternative relayer such as LayerZero Labs, Blockdaemon or Gelato.

The trust assumption would be that Chainlink and the chosen Relayer are not actively colluding against the Foundation’s wishes to forge messages. Bear in mind that Chainlink already secures $75B+ of dollars today and has secured $7T+ of economic value of transactions and the delegates are by far the most economically aligned with the Uniswap DAO and already have a significant surface of influence over Uniswap governance via voting power.

12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.

The risk of an adversary passing a fraudulent message from Ethereum to the destination chain is near zero; For a message to be forged, the adversary would need to simultaneously and independently corrupt the entire consortium of Uniswap delegates as well as Chainlink. It’s worth noting that if the consortium of Uniswap delegates wanted to collude they already likely have enough voting power to collude directly via governance and have no need to do it via the messaging layer on top of the additional burden of needing to corrupt Chainlink as well.

13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.

The consortium of Uniswap delegates and Chainlink would need to be willfully withholding the message. In this case, it would be both obvious to everyone that this was happening and who was responsible and allow the Uniswap DAO to change their configuration to remove the malicious party and successfully deliver the message.

14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.

If any of the actors in the Uniswap delegate network were to act maliciously and sign an incorrect message, it would be publicly observable and the other Uniswap delegates would withhold signature. This would carry huge reputational risk to the malicious delegate and result in the Uniswap DAO ejecting them from the relayer network.

Chainlink oracles in the Chainlink DON carry huge reputational risk and already secure $75B+ today. If one were to sign a forged message, they would face removal from the Chainlink DON and risk huge reputational risk in all of their core businesses.

15. Provide any additional information you would like here.

We have deployed our omnichain governance executor on Goerli testnet and BNB testnet and executed a fee switch from (0,0) to (4,5). Below are the contract addresses and the layerzeroscan transaction.

proposalSender on ethereum-goerli: 0x78F386bf7F5c638b14e166Fa31F8c66BBb654b4B

governanceExecutor on bnb-testnet: 0x3CE8305175Bfa090278568461aee8e64B5C220F5

Uniswap v3 pool on bsc-testnet: 0x881A6726B06CEc80Dd512f5f2556242ECaCA8700

Here is the transaction on LayerZero Scan: Cross Chain Message | LayerZero

Security in anything boils down to the weakest link. The most common weak links in messaging protocols are (1) client diversity and (2) upgradeability.

1) Client diversity:

Many middlechain messaging protocols and bridges celebrate their “decentralization” by touting the number of validators in their network. For example a system might have 19 validators, and to achieve consensus, their service needs at least 13 signatures. However, those features are not the weakest link in this system; the client diversity is. All of these validators are running the same piece of software developed by the same team. The weakest link comes from the team that provides the source code and software updates. A simple bug or hack from external parties could push code to force signatures on malicious network traffic.

This isn’t a new concern in crypto, as it was a fairly significant issue with the Ethereum community before POS when most of the clients and miners in the network were running Geth. Today Ethereum has the luxury of 4 or 5 unique clients built and maintained by different respective development teams thereby reducing the risk of developer-related attacks (e.g. pushing an upgrade with a smart contract bug, human engineered hack). Pre-POS, one of the main reasons lack of client diversity wasn’t a major concern with Ethereum was the fact that if Geth performed an attack, the network could rollback to a previous version of Geth and erase from history the previous attack; a necessary rollback would be a major blow to Ethereum but not a fatal one. In contrast, lack of client diversity is a major risk for bridges because the bridges themselves reach finality; bridges don’t have the luxury of rolling back chains, every action is final. Therefore when using a middlechain messaging protocol– by design, lacking client diversity– users and applications are not accepting the security of X validator decentralized network but rather the security of the weakest link: the creator company itself.

(2) Upgradeability:

Most, if not all, messaging frameworks (besides LayerZero – the entire protocol is composed of immutable smart contracts) are upgradeable. Developer teams push upgradeable code so they can optimize for rapid releases of the latest and greatest technology and enjoy the advantage of fixing bugs or issues in their code with limited overhead time. This feature is a double edged sword; if teams have the power to fix issues, it also means they have the power to create them. In other words, even the most secure application built on top of a mutable messaging framework will always carry existential risk the code that is in production today is not the same code in production tomorrow.

Upgradability has been a long standing source of significant and repeated issues within the existing messaging frameworks. The last two bug bounties paid out by Wormhole were due to upgradeability issues. The Wormhole developer team upgraded a contract and forgot to set parameters. They left themselves exposed for weeks to an attack and were incredibly fortunate to have whitehats report it and collect a partial payout of the $10m bounty. Shortly after this first payout, the team performed the same issue again and paid another $10m bounty. Had a blackhat found this issue both times, the attacker could have bricked the bridge and locked up $1.8B. In 2022, Wormhole additionally lost over $325M. The recent hack of the Nomad bridge which occurred this summer was due to an upgrade which introduced a bug that allowed anyone to forge arbitrary messages and resulted in the exploit of more than $200M that still has never been recovered.

Commitment to a security operations and engineering mandate of immutable code is a challenging but critical path to take in designing the strongest, most secure, and high integrity infrastructure for developers to build upon.

As your team has familiarized themselves, at a high-level, LayerZero’s architecture consists of endpoints (immutable smart contract libraries) and independent oracles and relayers. The independence and diversity of available oracles and relayers are a unique aspect of the protocol design. LayerZero has an ever-growing array of oracles and relayers all running their own custom client software, meaning that when an application chooses, say Chainlink Oracles and the LayerZero Labs Relayer, the application developers know that both components are built by teams running completely different clients. This significantly reduces the attack surface of the messaging framework. Additionally, LayerZero by design empowers applications with the option to run a component within their messaging layer. For example, an application can opt to use multiple oracles and relayers, each their own custom clients, one of which is run by the application itself. Thus, the security of the messaging layer remains decentralized but backstopped by the veto of the application-run oracle or relayer.

LayerZero’s code is completely immutable and LayerZero Labs can never upgrade the existing code. One of our team’s core theses is that the best-in-class messaging protocol can and should evolve with best security practices and cryptographic research. In practice, LayerZero Labs can write new immutable smart contract libraries to offer as additional libraries for applications to choose from / opt-in to. Applications always maintain the choice to opt-in to libraries set as default just as they may choose to evaluate new offerings of libraries and point their contracts accordingly. A developer can choose to use the same libraries that have secured billions of dollars in TVL over the past year and maintain usage of those libraries for the next 20+ years without ever having to accept new code without interference from any LayerZero Labs activity. A developer can choose to use the longest tested library for a month and then opt later to use a library leveraging novel cryptographic proofs. LayerZero evolves and scales with research while protecting the agency and chosen security of the application developer in perpetuity. This design puts security in the hands of applications and does not render applications dependent on LayerZero Labs in any way.

3 Likes