Introduction to Axelar
Preliminaries of the Axelar Network
Let’s take an in-depth look at the technical components of the Axelar network
Introduction to Axelar
Preliminaries of the Axelar Network
Let us begin our introduction to the technical components of the Axelar network by having a look of the underlying preliminaries of the network.
Protocol Threshold
Each validator in the Axelar network has a weight – a number ranging from 0 to 1 – denoting each validator’s voting power. When added together, the voting power of all validators add up to 1.
If validators run their node in a way that is consistent with the protocol’s rules, they are correct. In order to finalize a block (or sign cross-chain requests), the total weight of correct validators needs to be above the protocol threshold. Axelar’s blockchain works in a partially synchronous setting. For this reason, it requires a protocol threshold of 2/3.
Axelar’s Delegated-Proof-of-Stake blockchain is maintained by validators who run Byzantine Fault Taulerant (BFT) consensus at each round in order to finalize a block. Once a block is finalized, a new BFT consensus is run, and so on.
Validators are elected by means of stake delegation. Users in the Axelar network are free to run a validator node or can stake (i.e. delegate) their voting power to an existing validator. Validators will then vote on the behalf of their delegators.
Threshold Signatures
Cryptographic Preliminaries
By means of utilizing a threshold signature scheme, a group can split a secret key for a signature. This can be done in such a way that a specified number of parties can jointly produce a signature. Below that number, no party can produce a signature.
Properties of Threshold Signatures
The properties of threshold signatures are especially desirable for a decentralized network such as the Axelar network. These properties include:
Security against a dishonest majority
Threshold schemes without the restriction of only being secure when the majority of parties is honest, are secure against a dishonest majority. Axelar as a cross-chain platform must maximize the safety of its network by being able to tolerate as many corrupted parties as possible.
Pre-signatures, non-interactive online signing
In order to reduce the burden of communication between the involved parties to sign a message, a significant portion of the work can be done “offline.” During this offline phase where a local computation is done, a pre-signature is created. Each party then announces their shares of the signature and once public, the actual signature can be revealed by combining these signature shares.
Robustness
In robust decentralized networks, T.Keygen and T.Sign succeed if at least the specified number of parties are honest, even if malicious parties send malformed messages.
Fault attribution
Fault attribution is characterized by the ability to identify, punish or exclude bad actors in T.Keygen or T.Sign. Without fault attribution, the network’s participants have to bear the costs imposed by bad actors. This also allows to economically disincentivize malicious behavior via slashing rules.
Security in concurrent settings
A requirement for a secure signature scheme in a concurrent setting is that multiple instances of the signing algorithms and the keygen can be involved in parallel. Both ECDSA as well as Schnorr schemes satisfy these requirements.