Tldr

• Security is complex, and achieving robust security comes down to the right designs, engineering, processes & operations.
• Axelar continues to lead the innovation front for cross-chain security with its latest release adding new features.
• Axelar security is powered by a combination of:
  • Proof-of-stake decentralized design at the core.
  • Novel quadratic voting mechanism increases decentralization of the network.
  • Validator security policies, such as mandatory key rotations.
  • Network functions that enable mitigation of malicious interconnected chains [suspend traffic from them].
  • Contract limits that specify how much can be transferred over a time period.
  • Rigorous audits & bug bounties.

Introduction

Managing complexity, risks and benefits is something we’re used to by nature. Think of nuclear energy: the risk of catastrophic failure is widely understood; motivated by the benefit of a powerful energy source, we apply robust engineering to contain it.

In the end, security is a multidimensional problem with binary outcomes. Defining the security of a system is an incredibly complex task, but with rigorous models, designs and engineering practices, we can build systems that stand up to the worst attacks.

When it comes to cross-chain communication, security is the core that it must deliver. As we know too well, most cross-chain offerings to date have failed to deliver it, resulting in lost funds now counted in the billions. Beyond coding errors, most projects are failing at achieving robustness in one or both of two core properties.

• Safety: how many nodes in the system does an adversary need to compromise to double-spend or maliciously execute a transaction [that may lead to an invalid asset transfer, for instance]?
• Liveness: how many nodes in the system does the adversary need to compromise to halt the system?

At first glance, it might be attractive to tell the application developers to rely on their own validators or oracles to meet the above core properties. However, 30+ years of the history of security on the internet shows that application developers do not want to or cannot make security decisions due to time or resourcing constraints.

In security, “the more features the better” is false. Features add complexity and, when it comes to security, fewer options are better. Only absolute must-haves should be exposed to developers. There is a reason that encryption protocols have gone through decades of debates between cryptography and security experts to achieve strong security. Meanwhile, application developers simply know internet security as the “https” protocol they must use.

So how do we achieve the above properties with maximal robustness?

Step 1: Decentralize

In most Byzantine systems, if you break liveness, the system halts its operation, but an adversary would need to do much more to break safety. For instance, a blockchain may halt under a denial-of-service attack on its validators, limiting their ability to send messages and reach consensus. But to break the safety of the blockchain, the adversary might need to find vulnerabilities in validator nodes and extract their secret keys.

Robustness of such systems is thus achieved via diversification of software deployments. One validator might deploy on an Ubuntu machine, another on Debian, some in cloud environments, some on-premise [definitely the preferred route].

This kind of decentralization is critical to satisfy strong safety and liveness properties needed to handle cross-chain functions. This is why Axelar is built using the battle-tested proof-of-stake consensus with a diverse and dynamic validator set. Anyone can join, anyone can participate, anyone can contribute to the security of the network.

Step 2: Decentralize even more with quadratic voting

Once you have a system that is technologically capable of decentralization, you need to determine a mechanism to increase decentralization over time, and counteract concentration of power. Validators that do a good job operating their nodes tend to receive more delegations from the community and have higher stake in the system. Standard proof-of-stake systems use delegated weight to count how many votes a validator should have in the system. The unfortunate side effect of this is stake concentration: if a single validator has a lot of stake, they have a lot of influence in the system.

Vitalik Buterin and others have written about this problem, but to date no major blockchain has implemented a solution. Axelar is breaking new ground in this area. (You can read more here about Axelar's approach to quadratic voting and potential applications in DAOs, dPoS and PoS systems.)

We previously experimented with a dual-key approach: some requests were weighted by stake, as in standard proof-of-stake systems; for other operations, each validator had only one vote, and top validators were chosen. However, the problem with the one-vote approach comes up if you start scaling it to large validator sets. If, say, the top 100 validators are chosen, and in the bottom part of the list, each validator has 0.1% of the stake, then to collect 10 votes (representing 10% of all votes), the adversary needs to have only 1.1% of the stake.

Quadratic voting is a way to continue decentralizing the system while making it harder for validators to accumulate more votes. In sum, the number of votes each validator gets becomes a square root of their stake. A threshold of validators, weighted by the square root of the stakes, then must collectively co-authorize every cross-chain request. As validators accumulate stake, it becomes more difficult for them to accumulate voting power.

Note that Axelar implements quadratic voting for validation and processing of cross-chain transactions, but the underlying consensus follows the standard PoS staking model [1 token, 1 vote] for block production and rewards. Axelar implemented quadratic voting in its upgrade, code-named Maeve, announced Tuesday.

Step 3: Amplify stake security

With Interchain Security available in the Cosmos ecosystem in the coming months, one network can “borrow” 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.

Step 4: Plan for failures

No system, no matter how well designed, is invulnerable. A system must know how to react to failures, whether malicious or accidental. The Axelar network is architectured with a number of additional safety measures in mind.

Rate limits

The Axelar network supports arbitrary message passing, but certain major assets (USDC, FRAX, ETH) are implemented as “routing” assets on the network, which allows applications to send tokens with messages in one function. These assets are subsequently locked and minted across the Axelar gateways. The gateways have a rate limiting function, putting a cap on how much of each asset can be transferred in a given time interval.

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.

Audits

Axelar network code goes through continuous and rigorous audits. https://github.com/axelarnetwork/audits

Axelar network and contracts are all open-source. We actively encourage comments and revision from white-hat hackers. An active bug-bounty program incentivizes submissions.

Step 5: Application-level security add-ons

Atop its core liveness and safety properties, the Axelar network supports Turing-complete general message passing. This functionality enables application developers to build their own custom cross-chain security policies. For instance, a DeFi application may impose additional limits on the volume of transferred funds, repeat transactions, co-authoring large transfers, etc. These application-specific features can work alongside the network requirements to deliver even stronger security guarantee.