What is the Axelar network?
Axelar network is a decentralized state machine responsible for facilitating cross-chain requests. The network supports a few key protocols, such as Cross-Chain Gateway Protocol (CGP). CGP is at the heart of the system and allows us to easily onboard new chains with no constraints on the consensus rules and transfer information across them. In this post, we’ll take a look at what makes CGP tick and dive inside some details behind the stack. But first, let’s try to understand what led us to this architecture.
To start, here are the key components of the Axelar Network:
- Consensus
- Threshold cryptography
- Gateway contracts
- Validators
- Cross-chain daemons (aka relayers)
Why does the Axelar network need consensus to process cross-chain requests?
The rules for confirming cross-chain requests and processing them are encoded in a distributed protocol executed collectively by all validators. You can think of the Axelar network as a decentralized state transition machine, and requests submitted on the network trigger transitions from one state to another. Thus, the consensus allows us:
- To reach an agreement on the state of the system and execute CGP,
- Agree on the state of other chains to confirm cross-chain requests,
- Execute distributed logic to initialize multi-party key-generation and signing protocol,
- Handle membership changes, key-rotation, and incentives.
Finally, the consensus is a prerequisite for a number of multi-party threshold cryptography protocols which we describe below.
Why does the Axelar network need threshold cryptography?
Axelar gateways are collectively managed by the Axelar validators via threshold cryptography. That is, the majority of validators need to agree and collectively approve any transaction to be executed through the gateways. This is similar to how the majority of validators need to agree on state transitions on standard blockchains to authorize basic asset transfers from one user to another. The agreement results in a signed compact transaction. Having a single signature (collectively produced by the majority of validators) authorizing the transactions allows us to keep the transactions small, maintain low fees, and eliminate any requirements from the chains Axelar network interconnects (e.g., support for multi-signature, transaction limits, light clients, etc.). Many threshold protocols (e.g., ECDSA used by Bitcoin today) assume a reliable broadcast channel and peer-to-peer private channels between parties. This is where consensus also comes in pretty handy :).
Will every validator have to run nodes of all other chains?
Axelar network validators run nodes or light-clients of other chains. No custom logic needs to be coded for this — validators just download the software clients provided by the blockchain developers, expose RPC endpoints and point the Axelar nodes to those endpoints. Validators will be allowed to choose which chains they’ll validate requests for, and the incentives will be structured accordingly. It’s important to note that the threshold keys will be distributed across all validators for higher safety (we also have secondary keys that will be distributed across fewer validators, with much more limited power).
What types of commands does the network support?
- Generate a new chain key pair. A distributed threshold protocol is executed amongst all validators to generate the master key-pair for a chain that will interconnect with the Axelar protocol.
- Deploy a new gateway contract to a new chain. After this event, assuming a sufficient number of validators can verify transactions on that chain, it becomes interconnected through the Axelar infrastructure to all other chains. [For the Bitcoin network, custom scripts and UTXO management system is used instead. More on this later.]
- Generate a link address to transact from a source chain X to destination chain Y. This command returns a new address to which transactions can be made and subsequently the network will mint and represent them on the destination chain Y.
- Verify deposits on a source chain X. This triggers a 2nd layer consensus protocol on top of the Axelar network to finalize a deposit on a source chain. Essentially, all validators query their RPC endpoints to check if the transaction is “final” according to some rules (for PoW chains, it needs to be sufficiently deep in the chain, for PoS chains with instant finality — well, you get instant finality).
How does the state grow on the Axelar network?
The Axelar network only keeps track of information associated with the gateway contracts and cross-chain transactions. Hence, the data only grows with the amount of cross-chain transfers, and not with the size of the blockchains Axelar network connects. Furthermore, multiple cross-chain transactions are processed in batches.
What does it take to support a new chain on Axelar?
Axelar gateway contracts need to be ported to the smart contracts language of that platform. The contracts are “universal”, as they do not depend on the consensus or state of any other chains. For instance, mostly the same contracts are reused across all EVM chains. Next, a certain minimal threshold of the Axelar network validators need to run nodes to be able to verify requests in/out of the gateway contracts. The threshold is a tunable parameter in the system and will be set based on the experimentations in the testnet.
How is the information delivered across different blockchains?
When a transaction on chain A arrives at the gateway contract, it needs to be relayed to the Axelar network. Relayers or cross-chain daemons/processes are responsible for monitoring these gateway contracts, and upon seeing an inbound request, forwarding it to the Axelar network. Subsequently, the validators will query their RPC endpoints for chain A, vote on the transaction, trigger an internal state transition to process the transaction. For instance, if the transaction deposits some funds to the gateway contract, then validators record it and put it in a backlog from where it can be signed by all Axelar validators. Finally, anyone can relay the signed transaction to the destination chain.
It’s important to note that relayers are not trusted for the safety of the protocol. The decentralized protocol executed by the Axelar validator verifies (where applicable) each request submitted by the relayers. Furthermore, it’s sufficient to have 1 functional relayer to maintain liveness of the protocol.
In addition, many state transitions can be triggered by anyone on the network. For instance, when multiple cross-chain transactions are pending in the backlog to a destination chain, a single signing request on the network will process them all.
What does it take to monitor the health of the Axelar network nodes and validators?
Information about the health of the network may be observed by:
- a) Monitoring the logs emitted by the Axelar nodes,
- b) Querying the state of the ledger,
- c) Observing events emitted by the Axelar nodes and on the gateway contracts,
- d) Subscribing to the metrics exposed via Prometheus.
What are some of the interesting events that may be observed?
- Multi-party key-generation invocations, keys produced, failed attempts.
- Multi-party signing invocations.
- Keys and gateways accounts deployed to each chain.
- Active validators, their stake, delegations, whether they they miss producing blocks, or voting on events from the external chain or participate in keygen/sign ceremonies.
- Validators’ status in the network: for instance, if the validator wants to leave the network, they first have the “deregister” and wait until their shares are rotated out of the system. After their shares are rotated out of the system, they can unbond.
How can I get involved in the project?
We’re growing the ecosystem of node operators, wallet and monitoring infrastructure providers, developers, and hiring across various technical and ecosystem roles (https://axelar.network/careers)
A Technical Introduction to the Axelar Network was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.
