Technical features of Web 3.0 on the example of Axelar Network

Usually, all the features of blockchains are available exclusively within these blockchains, which makes it impossible for ecosystems to interact with each other. Developers are forced to make a choice about which blockchain will be more suitable for them.

Accelar Network helps blockchains interact with each other by providing a decentralized network. Projects/blockchains do not need to make any changes on their side.

Interoperability is the ability of a product or system, the interfaces of which are completely open, to interact and function with other products or systems without any restrictions on access and implementation.

There is a problem that users cannot interact with any application and blockchain of their choice directly from their wallet.

Axelar Network that we are talking about solves this problem, being the so-called bridge between blockchains (not to be confused with ordinary crypto bridges, which simply transfer coins from one blockchain to another (but it can do that too)). This allows developers to make services available on all blockchains while increasing flexibility for both developers and users.

According to their whitepaper:

Axelar stack provides a decentralized network, protocols, tools, and APIs that allow simple cross-chain communication. Axelar protocol suite consists of cross-border routing and transfer protocols. Byzantine consensus, cryptography, and incentive mechanisms are designed to achieve high safety and liveness requirements unique for cross-chain requests.

The average user doesn’t care if the app uses TRX, SOL, or BSC. He needs it just “to work.” Developers do not need to decide between ETH, NEAR (hi to its developers), Solana, and other networks choosing advantages and disadvantages for themselves and for users. He also needs to choose what is more suitable for solving a particular problem.

The protocol core consists of the Cross-Chain Gateway protocol and the Cross-Chain Transfer protocol.

By and large, the former is responsible for the very interaction between blockchains. The second is for the transfer, locking/unlocking of funds between different blockchains.

CGP (Cross-Chain Gateway, the first one) is used to connect autonomous blockchain ecosystems to each other and provide routing between networks. Blockchains do not need to be built in the same programming language. Instead of writing custom solutions (in fact, crutches), developers just need to connect their extremely valuable creations to a common system that takes care of the interaction between ecosystems.

CTP (the second one, the cross-chain transport protocol), as already mentioned, is responsible for the transfer, locking/unlocking of funds between different blockchains. But he will also be responsible for triggers. With “such and such an event”, do “something” in another network. This also works with smart contracts. Think of it as something like HTTP, or an application layer protocol. Users can use simple API requests similar to GET, POST.

Among the features I would highlight:

Plug and play. Everything is so clear here. Minimum effort to get the desired result

Cross-chain routing. Think of it as the Routing Protocol on our web.

Upgradability support. When one blockchain is updated, the other will not be affected. Simply and logically.

Uniform language for applications. Remember the comparison with HTTP. It is basically the same everywhere.

Security is supported by DPOS (delegated proof of stake) — users give their stake. As part of the consensus, validators run the client software of other blockchains, which allows them to check their state. Validators report these states to Axelar, and once there are enough of them, the state of bitcoin, ethereum, and other chains are written to Axelar.

Now there will be very technical moments, so either listen carefully or don’t listen at all.

So, each validator has a weight between 0 and 1 indicating the strength of that particular validator’s vote. The weights of all validators add up to 1. A validator is valid if it launches a node that complies with the rules of the Axelar protocol. To finalize blocks or sign requests between Axelar chains, valid validators with a total weight greater than a threshold are required. This number is between 0.5 and 1.

Validators run a Byzantine Fault Tolerant (BFT) consensus on every round i to complete block i. Once the i block is completed, a new BFT consensus is started to complete the i+1 block, and so on.

Different blockchains operate with different network assumptions. Synchronous communication means that there is a fixed upper bound on the delivery time of a message, where this time is known and can be built into the protocol. Asynchronous communication means that delivery can take an arbitrarily long time, and we know that consensus protocols cannot be built for asynchronous networks even with only one malicious validator. The trade-off between synchrony and asynchrony is the assumption of partially synchronous communication. The network may be completely asynchronous up to some unknown global stabilization time (GST), but after GST the communication becomes synchronous with a known upper bound ∆.

For synchronous networks, it is usually set as ½ or ⅔. The current threshold, in fact, for all currently supported ones is set at 51 percent, according to Axelarscan. When connecting ecosystems through Axelar, the connection will work at the highest threshold. Here is an example. Bitcoin — synchrony, COSMOS — partial synchrony. So, we’re working to the fullest.

The Axelar blockchain operates in a partially synchronous mode and therefore requires a threshold of 2/3, but it is possible to improve the threshold requirement by assuming that other existing blockchains are secure and leveraging their security.

Cryptographic Preliminaries

Digital signatures. The digital signature scheme is a set of algorithms. Keygen issues a pair of keys (PK, SK). Only the owner of the SK can sign messages, but anyone can verify signatures with the other public key.

Next, you will need an understanding of several protocols, so we will not go deeper.

Cross-Chain Asset Transfer

Let’s move on to something more real. The bridge between blockchains. If you don’t know, then here is the point. There is a coin/token in one network, you need a coin/token (same or different) in another network.

Here is how Cross-Chain Asset Transfer works:

1. The user (or an application acting on behalf of the user) sends a request, which is subsequently routed to the Axelar network.

2. Axelar validators use threshold cryptography to collectively create a new deposit address (dS) and publish it on the Axelar blockchain.

3. The user (or an app) monitors this address on the Axelar blockchain. The user sends tokens to this address. Nothing extraordinary, just a normal transaction on the blockchain of the original network.

4. The transaction is placed on Accelar. Validators send a request through the API of our original blockchain for the presence of such and such a transaction, and if the answer is “yes, there is such”, then they report this to Axelar.

5. As soon as the number of validators saying that the transaction was (or was not) carried out becomes more than the threshold, then Axelar asks the validators to sign another transaction that sends the required number of wrapped tokens from Axelar.

6. Validators sign the transaction. The signature is included in the block of the so-called round R+11.

7. Anyone can take the signed value from this block R + 11 and post it to the desired blockchain.

8. The request has been serviced, once this signed value is posted on that blockchain the transfer is processed.

In the meantime, here is a minimal summary:

In two words — one protocol and an API and your incredibly important application with a little bit of magic can work with all ecosystems.

Since the topic is rather complicated, we will stop here. If you want me to cover other parts, then let me know.

This was the script for the podcast Jun. Programming [Python/Django]. DevRootIT

https://axelar.network/
https://axelar.network/wp-content/uploads/2021/07/axelar_whitepaper.pdf
https://en.wikipedia.org/wiki/Border_Gateway_Protocol
https://axelar.network/wp-content/uploads/2021/07/axelar_whitepaper.pdf
Consensus in the presence of partial synchrony. https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf.
Flexible round-optimized schnorr threshold signatures. https://eprint.iacr.org/2020/852

My media: Telegram | Youtube | Podcast | Articles | All links