Learn more about Axelar
Technical Details of the Axelar Network
Let’s take an in-depth look at the technical architecture of the Axelar network and how it is used to bridge blockchain ecosystems
A deep dive into Axelar
An Open, Decentralized Cross-Chain Network
Cross-chain requests must collectively be authorized by (almost) all validators because Axelar’s bridges are backed up by threshold accounts. From a technical standpoint, a network where anyone can help in securing these bridges needs to meet the following requirements:
- Open membership: Anyone should be able to become a validator
- Membership updates: A validator’s key needs to be revoked if they leave the system
- Incentive and slashing mechanisms: Malicious behaviors should be identifiably and punishable through slashing
- Consensus: The network’s validators will have to reach consensus on the latest state of each invocation of threshold schemes
- Key-management: The keys of validators in the Axelar network are rotated and will be split between online and offline parts. Similarly to ordinary validators in a PoS system, Axelar validators need to guard their threshold keys.
Axelar implements a Delegated Proof-of-Stake model in its network. As a result, community members will be able to elect a set of validators to run the consensus. Multiple threshold shares will be assigned to larger validators to account for their weight as standard threshold schemes treat every validator identically without considering their “weight” in the consensus.
Validators
The basic functions that validators perform in the network
The validators in the Axelar network perform different functions within the ecosystem. These basic functions include:
Threshold Key Generation
Validators run a threshold daemon process which is responsible for keeping the secret state secure. This includes these four steps for each phase of the protocol:
- State keeping: the state of the protocol is kept in the local memory of a validator
- Message generation: the secret daemon is called to generate the message for other validators as per the protocol description
- Message propagation: the messages are propagated to other validators either via the private channels or via the broadcast
- Execution of state transition functions: in order to update its state and move on to the next phase of the protocol where the above steps are repeated, each validator executes state transition functions
This process results in the generation of a threshold public key on the Axelar chain. The key can then be displayed back to the application that generated the initial request or to the user (e.g., when trying to make a deposit).
Threshold Signing
In the Axelar network, signing requests are processed similarly to key-generation requests. Signing requests are, for example, invoked when a user wishes to deposit an asset on one of the chains or wants to withdraw therefrom. Messages are propagated via every validator’s local memory and the Axelar blockchain view. As a function of these messages, state transition between the rounds is triggered.
Handling changes in validator membership
In order to allow for new stakeholders joining the validator set, the set will be rotated periodically. The threshold key needs to be updated upon such an update to the validator set and will then be shared across the new set. To prevent updating the threshold key frequently, validators are rotated every T blocks.
Threshold Key Generation and Signing in the Presence of Rotating Validators
A request for a new key or threshold signature may be issued by be issued by the Axelar blockchain at round R. To prevent the consensus from slowing down, validators produce the signature before round R+10 starts.
Securing the Axelar Network
Network Security
Blockchain systems face a variety of threats, such as double spending and colluding validators rewriting the chain’s history. New attack vendors are introduced once chains interoperate, as is the case in the Axelar network. Let’s have a look how Axelar eliminates these threats.
Securing the Axelar Network
Axelar’s Network Security Explained
Axelar’s Security Mechanisms
Our recent projects
To prevent the aforementioned attack vendors, Axelar is using the following mechanisms for securing the network.
Fallback Mechanisms
What happens if the Axelar network stalls?
Should the Axelar network stall as a result of the high threshold, the emergency unlock key takes control of the network. Secret shares of the recovery key are then generated by a simple protocol. Each validator in the network shares a random value. By summing up these values, the recovery secret key is generated. Shares are encrypted under the public keys of the recovery users and then added up homomorphically. This protocol results in a recovery public key RPK and potentially thousands of encryptions of the shares of the corresponding secret key that are distributed on chain to their owners.
In the case a blockchain connected to Axelar breaks, limits on the USD value of assets that can be moved in and out of the chain can be imposed. This prevents the malicious chain from stealing large fractions of assets before Axelar validators detect it. Through the Axelar governance module, a vote can determine what happens in such situations, such as restarting the connection from where it left off. In case of Ethereum, a custom Ethereum recovery key can be used to determine what happens to the ETH assets.
Axelar’s Core Protocols
Up next: A Deep Dive Into Axelar’s Protocol Suite
