Cross-Chain Bridge Assessment Process

23

hey All. Please find answers below from the Axelar Network.

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

  • Technology: The Axelar Network is powered by a decentralized Proof of Stake protocol with multiple layers of security features and an ability to further customize security for Uniswap, if needed.
  • Team: The team has deep roots in cryptography, distributed systems, and consensus and has been designing and building secure infrastructure for many years.
  • Traction: The Axelar Network has been live for over a year, integrated over 32 chains through its stack to date, processed over $1.7 billion in volume, and working with major DEXs, Wallets, L1/L2, stablecoins, and other partners throughout the industry.

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

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

  • To date, Axelar has a TVL of $126 million and has processed over $1.78 billion in asset transfer volume. Over 32 networks have been connected to the Axelar network, and the network has processed 350k+ cross-chain transactions (Transfers | Axelarscan).
  • The network supports General Message Passing and many applications leverage it – bridging NFT, performing swaps, etc. These applications don’t “lock” TVL, but enable applications to compose across the ecosystems.

4. Provide a background on your team.

  • The assembled team has deep expertise in cryptography, distributed systems, and consensus. The core engineering team has research experience in some of the top academic institutions (e.g., MIT, Waterloo), and professional experience in some of the most renowned technology companies, such as Google, IBM, and Microsoft.
  • Co-founders Sergey Gorbunov and Georgios Vlachos were founding team members at Algorand, and are winners of multiple academic awards in cryptography. ​​
  • Core engineer João Sousa built the first practical implementation of Byzantine consensus, BFTSmart, which has inspired many researchers and this industry over the years.
  • Sergey Gorbunov has designed and published many core cryptographic protocols. He also led the effort to standardize BLS signatures; the standard in its draft in CFRG was followed by Ethereum 2.0 implementations and others.
  • Overall, the team has been assembled to build best-in-class security from the ground up: from design to engineering and operations around the network.
  • Here is our team page.

5. Please link your developer documentation.

(Please select “Developer” under “pick-a-role” to access the developer channel)

6. Does the bridge support arbitrary message passing?

  • Yes, arbitrary message passing was described in the Axelar white paper in January 2021, and Axelar released its General Message Passing (GMP) capability to mainnet in April 2022. For example, GMP enables developers building on one chain to call any function on any other connected chain. (We use the word “function” to encompass both smart contracts at the application layer and functions built at the protocol layer, as in Cosmos, for example.) That means complete composability across Web3.
  • Like all Axelar functions, General Message Passing relies on a permissionless validator set (delegated proof-of-stake) for security and a decentralized protocol that handles routing and translation.
  • Learn more here: General Message Passing | Axelar Network

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

  • Yes, the Axelar network code has been audited over 30 times and continues to go through continuous and rigorous audits.
  • Audits can be found here: GitHub - axelarnetwork/audits: Axelar network audits, with relevant findings, addressed before production deployments.

8. Is there a bug bounty program?

  • Yes, Axelar’s $2.25 million bug bounty program has been live since March 10, 2022, on Immunefi.
  • Axelar network and contracts are all open-source. We actively encourage comments and revisions from white-hat hackers.

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

  • The Axelar network can be upgraded following delegated proof-of-stake consensus. That is, anyone can post a proposal on the Axelar network and the Axelar token holders may elect to approve/deny it and the associated upgrade. Axelar network is controlled by a permissionless validator set and governance, as it is built on the Cosmos SDK.

  • A full list of network parameters and governance methods is available here.

  • The current instantiation of the Axelar Gateway contracts on the EVM chains are effectively light-clients: they’re responsible for keeping track of the Axelar validator set and communicating with applications that leverage Axelar.

  • Only the Axelar validators can collectively authorize decisions to process cross-chain transactions from/to the Gateways.

  • In the current instantiation, the gateways are upgradable subject to approval from an offline committee (4/8 threshold). This will change in the immediate future when all validators also need to collectively approve any upgrades to the gateways, essentially establishing end-to-end security via the Proof of Stake decentralized protocol.

For Uniswap, we can launch new Gateway contracts that are customized. For example, contracts can be non-upgradable, or Uniswap delegates or UNI token holders can govern upgrades. Such contracts would be governed by the Uniswap community while leveraging Axelar’s permissionless validator set for passing messages across chains. (See the Appendix for more details.) See the Appendix for more details.

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

  • The answer is incorporated above.

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?

Robust security comes from (a) the right design, (b) engineering practices, and (c) application-level security add-ons.

(A) The design: A decentralized permissionless network with a many-to-many communication model. The decentralized and permissionless model has the best practical security guarantees as it encourages diverse validator deployments, incentivizes validators to guard their keys, promotes good behavior, and punishes bad behavior.

  • Axelar is the full-stack decentralized transport layer. At the core, it is powered by delegated proof-of-stake consensus to validate cross-chain messages. Applications can instantiate additional validation logic across connected paths that may be governed by the application token, permissioned set, light-client, zk proofs, or other available technologies. Our approach is to:

    • (a) Offer the best-in-class security via decentralization as the default that solves most use cases for developers.
    • (b) Allow developers to customize security as needed.

  • The Axelar network itself comprises a validator set responsible for maintaining the network and executing transactions. The validators run the Cross-Chain Gateway Protocol, a multi-party cryptography overlay that sits on top of a Layer-1 blockchain. They are responsible for performing read and write operations to Gateways deployed on connected external chains, voting and attesting to events on those chains.

  • Axelar Gateways are effectively smart contracts that connect the Axelar network to its interconnected external chains. Validators monitor Gateways for incoming transactions, which the validators READ. They then reach a consensus on the validity of that transaction and, once agreed, WRITE to the destination chain’s Gateway to execute the cross-chain transaction.

  • The validators and Gateways compose the core infrastructure layer. They guarantee both safety and liveness of the core functions governed by delegated proof-of-stake. It’s important to note that relaying across Axelar and its interconnected networks is completely permissionless. This guarantees that no one can censor user transactions and delivers 100% liveness guarantees (assuming the interconnected networks and the Axelar network are running). If relayers are down, the user or anyone else can post transactions, themselves. If one of the interconnected networks is halted or undergoing an upgrade, the packets are just queued up at the network layer and can subsequently be posted (or re-posted) when the networks are back up.

  • Proof-of-stake decentralized design at the core - Axelar is built using battle-tested delegated proof-of-stake consensus with a diverse and dynamic validator set. Anyone can join, anyone can participate, and anyone can contribute to the security of the network.

  • Novel quadratic voting mechanism increases decentralization of the network - to further decentralize the network, cross-chain messages are approved iff they’re authorized via the quadratic voting rule. That is, the voting power of each validator is equivalent to the square root of their stake. A threshold of validators (currently 60%), weighted by the square root of the stakes, must collectively co-authorize every cross-chain request. With quadratic voting, as validators accumulate stake, it gets harder for them to accumulate voting power.

  • Amplify stake security - With Interchain Security available in the Cosmos ecosystem in the coming months, one network can “borrow” the security of other networks. This would allow it to increase the stake used for validation on the network, making any economic attack much more difficult. We also have plans to allow ETH holders to contribute to Axelar’s security, via the restaking model that Eigenlayer introduced recently.

(B) Engineering and operational practices:

  • Key rotations on the network - Validators of the Axelar network maintain keys that allow them to co-authorize cross-chain requests, similarly to how they co-authorize every block on the blockchain. Validators are strongly encouraged to implement best practices for isolating these keys and are required to rotate them periodically. Key rotations secure the network against a persistent attacker, who might try to accumulate malicious keys by compromising validators sequentially.
  • Continuous unit tests & end-to-end tests through the stack - While audits are great, achieving robust security often comes from having the right internal processes to identify and correct bugs. Continuous unit tests and end-to-end tests help discover vulnerabilities and bugs early in the pipeline.
  • Audits and bug bounties (see above).

(C) Application-level security add-ons:

  • Customize security - Additional paths can be secured by deploying additional validator sets, light-clients, and/or zero-knowledge proofs when available. We think this will be the best instantiation for the Uniswap community: leverage the robust Axelar network for all default traffic. If there is a highly valuable/sensitive transaction, utilize the additional UNI elected validator set for co-signing. See the Appendix for more details on how we propose customizing security for Uniswap.
  • Rate limits - The Gateways and the Axelar network have a rate-limiting function, which limits how much of each asset can be transferred in a given time interval.

Sitting atop the validators and Gateways are Axelar services and APIs that enable developers to access the tools and infrastructure enabled by those validators and Gateways. These services and APIs do not add any security assumptions: they make developers’ and users’ interactions in the interchain much simpler, but are fully permissionless: anyone can execute the relevant functions on-chain, themselves].

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

  • A majority of Axelar validators attest to messages that pass from Ethereum to a destination chain. The voting threshold is 60%, based on the validator’s quadratic stake (current stake distribution: Validators | Axelarscan). An adversary who can corrupt 60% of voting power can pass fraudulent messages. The adversary could try to corrupt enough servers to do this, but mechanisms such as key rotations & rate limits minimize the potential of these attacks.

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

  • The adversary can withhold messages by attacking validators that hold 40% of the quadratic stake. This can be done by corrupting validators or launching a denial-of-service attack.
  • Note that because relaying is permissionless, those attacks don’t apply to relayers. If certain relayers are compromised, any community member can come in and relay 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.

  • Axelar validators get slashed on the Cosmos SDK level, the same way that validators of any other Cosmos chains get slashed for misbehavior.
  • There is a penalty for validators who don’t maintain sufficient uptime. When a validator doesn’t vote on enough cross-chain events, they’re penalized with a loss of stake and rewards.
  • Validators who misbehave significantly (double signing blocks, not participating for a long period of time) get jailed.

Slashing and locking in the Axelar network

Rewards slashing in the Axelar network is designed to incentivize validators to avoid undesirable behavior, such as losing liveness, failing to vote correctly on external chains’ events, double-signing, etc. Rewards are accrued at the end of every block and released depending on the reward type. The slashing mechanisms in the Axelar network are unique to each inflation component.

Within the TM consensus rewards, the slashing rules are set as follows:

  • Validators will lose the TM Consensus rewards if they lose liveness and get jailed if they don’t participate for a longer duration.
  • Validators need to sign 50% of the blocks in every 35,000-block window.
  • Given a block time of five seconds, this corresponds to maintaining total liveness for at least one day in every two-day window.
  • They lose 0.01% of rewards per block for downtime and 2% for double signing blocks.

If the validators lose liveness for more than 50% of the window, then they are locked (“jailed” in Cosmos terminology, forbidden from rejoining the validator set) for two hours (about 1,440 blocks), after which they would need to unlock themselves. Axelar network implements an unbonding period of seven days.

For multi-party signing protocols (MSigs), the liveness of the broadcaster account is signaled through “heartbeat” messages sent every 50 blocks by the validator. Validators are considered “active” if their latest heartbeat message was received within the last 50 blocks, they are not suspended from MSigs, they have missed signing less than 5% of the blocks in the last signed-blocks window for consensus, and are considered “live” by the consensus layer. Accrued rewards are released whenever validators submit a heartbeat. A snapshot of “active” validators is taken to determine participation in MSig protocol. If an “active” validator failed to participate in MSigs, then they are considered to have lost liveness and are suspended from further MSigs participation for 8,500 blocks (which is about ½ day with five-second block times), along with losing their accrued rewards. If a validator fails to submit a heartbeat message, they stop accruing MSig rewards for every block until their next heartbeat. For example, in the diagram below, a validator missed the 3rd and 6th heartbeat, so they don’t accrue (i.e lose) MSig rewards for 2 * 50 = 100 blocks.

For external chain voting, all validators registered as chain maintainers can vote on events. A validator’s share of voting power is equivalent to the square root of the stake delegated to them, divided by the square root of the total stake delegated to all validators. Validators who submitted the majority vote have their accrued rewards released. To incentivize liveness and good behavior, validators who fail to vote or submit the minority vote lose their accrued rewards.

15. Appendix

A multi-path instantiation for Uniswap

We propose to instantiate interoperability for Uniswap by passing messages via

  1. the Axelar decentralized network, powered by delegated proof-of-stake consensus and many safety features, and
  2. augment it with an additional Uniswap-specific validator set and a secondary Gateway II (could even elect two additional validator sets).

The Uniswap-specific validator set may be elected by the UNI token holders.

  • We deploy a validatorElector contract on Ethereum where UNI token holders can select an external validator set.
  • The elected validators download and run an instance of the Axelar external worker process.
  • This process allows them to listen for events from the source chains, and co-sign and authorize cross-chain transactions that are subsequently approved at the destination Gateway II.

Next, a custom Message Auth Policy contract can be instantiated to authorize messages of different value/importance from the two independent Gateways. For instance, we can authorize messages of lower importance as long as one of the Gateways approves them. We can authorize messages of higher importance if and only if both Gateways approve them. See our recent blog post for how to instantiate deployments based on different validation logic using Axelar (https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps).

Composing bridge Gateways and custom logic between them is not new to us. In fact, this is precisely the instantiation we’re collaborating on with Circle for the Composable USDC.

Finally, as different validation logic becomes available (e.g., light clients, ZK-proofs), they can be implemented between the Axelar network and its interconnected chains. No need to have external validator methods once these connections go live, but we can still rely on multiple validation paths to avoid dealing with bugs.

Given our proposal incorporates the multi-path approval framework, if the community decides to go to the multi-bridge provider model, the Axelar team would be open to working with another provider that can implement/deploy an independent Gateway/validation logic.

3 Likes