How we launched our Axelar validator
The team at RBF is in it for the tech, and the RBF Staking team has put together this guide based on how they became more actively involved in the community.
David Jurica also previously covered plans to launch our mainnet Axelar validator.
What hardware did we use?
For the Axelar validator, we have chosen two bare metal servers, each located in a different data center (DC), and we can easily switch between them in case of an outage in either DC.
Tech specs of the servers:
- Dual Xeon Gold 6326 (16 core, 2,9 GHz base clock)
- 128 GB RAM in 16 modules for maximum memory throughput
- 4 TB storage (RAID 10)
In this case it crucial to understand the architecture.
What does the Axelar architecture look like?
In this diagram we use only the Cosmos and Ethereum network for the sake on readability, but in reality there are multiple chains on the Cosmos side – e.g. Terra, Cosmos, Osmosis, Juno, Injective.
There are also multiple EVM compatible chains – e.g. Ethereum, Avalanche, Fantom, Polygon, Moonbeam.
What are the main components?
- Axelar validator
- This is the main component that communicates with other nodes via P2P and secures the network’s consensus via Tendermint BFT.
- Axelar network itself is preparing sign batches that can be relayed to appropriate EVM compatible chains.
- The KMS server is a dedicated machine that is network-separated from the internet.
- This machine has the HSM key inside, and using tmkms, it is signing each Axelar block. Importantly:
- The validator key resides in HSM and never leaves it
- HSM itself signs the blocks
- It listens to events from the Axelar network, such as signing requests, and verifying events on EVM chains. It’s connected to EVM compatible RPC nodes of external chains, where it queries for events such as deposit confirmations and message send.
- On one side it is connected to the Axelar network, where it reads instructions what to verify. On the other side, it’s connected to EVM compatible RPC nodes of external chains, where it verifies that batches were executed correctly from Axelar.
- gRPC service which wraps rust implementation of multi-party signing protocols, such as, ECDSA multisig, GG20 threshold-ECDSA protocol (t of n), into RPC calls invoked by vald.Signs transaction batches for sending to smartcontracts on destination chains
- It has to be executed in highly secured environment.
What components sit outside the validator space?
- Cosmos Hub blockchain is the layer 0 blockchain of Cosmos
- It relays messages from two IBC channels
- Must be connected to full nodes of both chains it’s relaying messages between
- If the relayer finds IBC transaction in a block, then it sends the same transaction to the destination blockchain
EVM Relayer, Ethereum / Gateway SC
- The EVM relayer queries the Axelar network/full node for signed batches, and then it sends the batch as data in a transaction to the Gateway contract address on the appropriate chain.
- The EVM relayer is basically IBC relayer but optimized for relaying transactions to EVM compatible chains through gateway smart contracts. As with the IBC relayer – an operator of this relayer has to pay for transaction fees on destination chain.
RBF and Axelar network:
Since the RBF team is hands-on when it comes to the tech, the staking team first tested the software on testnet, and following an investment, starting a mainnet validator is a clear next step in our journey with Axelar.
We think Axelar provides so many opportunities for other projects in the crypto world and other validators’ teams.
Together with my colleague, Tomas Eminger, it’s important that our work is challenging, and we can learn something new to push ourselves forward. Axelar is a great example of really well designed software, which looks intimidating, but with deeper understanding there is beauty in this solution.
So if you are interested in participating in a new and interesting crypto project and community, we’re sure you’ll be very welcome in the Axelar community.
If you have any questions, you can contact me at TG (@Dave_Rockaway) or on my Twitter account (David J | RBF).
David Jurica is Head of Validator Infrastructure and Blockchain SRE. David is responsible for staking, validator infrastructure and communication with the global tech community. Prior to joining Rockaway, David worked as Chief Technology Officer (CTO) at a Czech startup where he was responsible for servers and infrastructure within the Czech Republic and the Slovakia Republic.