LogoLogo
  • Imua
    • About
  • Manifesto
    • The Problems
    • The Principles
  • Architecture
    • Imua Design Principles
    • Imua Network
    • Imua Modules
    • Client Chain Bridges
      • Trustless Verification of Client Chain State
      • Handling Race Conditions between Imua and Client Chains
    • Client Chain Contracts
  • Concepts
    • Ecosystem
      • Re/stakers
      • Operators
      • Services (AVS)
        • Service Integration with Imua
        • Service Committee
        • Service Integration Details
    • restaked Proof-of-Stake (rPOS)
    • Multi-Token Restaking
    • Multi-Chain Restaking with Trustless Bridging
    • Voting Power
    • Price Oracle
    • Flexible Integration with AVS
    • Tribe Staking
  • Governance
  • Risk Management
    • Risk Analysis
      • Risk Modeling
      • Risk Parameters
      • Crypto-Economic Risk
      • Unintended Slashing
      • Black Swan Events
    • Risk Mitigation
      • Smart Contract Simplicity
      • Audits
      • Slashing Prevention
      • Slashing Vetos
      • Insurance Pools
      • Circuit Breakers
  • Components
    • Testnet
    • Oracle Module
      • Reaching Consensus on Asset Prices
      • Penalty
      • Implementation Detail
    • Smart Contracts
    • Explorer
    • Registry
  • Validator Setup
    • Prerequisites
    • Node Install
    • Compiling Binary from Source
    • Oracle Price Feeder
    • Running the Node
    • Snapshot
    • Register Option 1 (Bootstrap)
    • Register Option 2 (Post Network Launch)
    • Deposit Tokens
    • Delegating Tokens
    • Confirm Election Status
    • Faucets
    • Managing The Validator
    • Security Best Practices
    • Risks & Mitigation
    • Participation in Governance
    • FAQs & Resources
  • Testnet Upgrade to v1.1.1
  • AVS Setup
    • AVS Overview
    • Prerequisites
    • Building the AVS in Imua
    • Hello-World-AVS Example
    • Becoming AVS Operator
    • AVS Register and Deploy
    • AVS Task Example
    • Enhanced and Automated Edition of hello-avs integration guide&example
  • Whitepaper (2023)
    • .pdf
  • FAQ
    • What problems is Imua solving?
    • What are the main design trade-offs that had to be made with an omnichain design?
    • Does the omnichain design imply added trust assumptions (relative to a single-chain design)?
    • What concurrency-related challenges would you face with a different design?
    • How does Imua integrate with new chains?
    • Do specific chains prove unique challenges w.r.t. integration?
    • How is the cross-chain communication is achieved?
    • What are the known attack / censorship vectors here, if any?
    • Are the restaked tokens being pooled in a centralized account?
    • Who will run the validators in the Imua network?
    • Is Imua an AVS?
    • How does Imua address the risks of overloading L1 social consensus?
    • Does the Imua queuing system raise concerns around latency?
    • What are the main benefits of an omnichain design?
Powered by GitBook
On this page
  • Installing Imua Binary
  • Firewall
  • Initializing the Node
  1. Validator Setup

Node Install

Instructions for preparation and binary set up

PreviousPrerequisitesNextCompiling Binary from Source

Last updated 2 days ago

You will be managing three keys which will be referenced throughout this guide. These keys are the account key, the consensus key, and the ETH private key. Please keep this in mind as you proceed with the installation steps.

Installing Imua Binary

The binary to run an Imua node is calledimuad, which stands for Imua daemon. The binary can be downloaded from Imua's (Option 1) or built from (Option 2).

Option 1: Downloading the Binary

Versions 1.1.0 and 1.1.1 are intended for use with the imuachaintestnet_233-8 network. To join the network faster, it is recommended that validators use version 1.1.1 along with a .

VERSION="1.1.1"
wget -O imuad_${VERSION}.tar.gz "https://github.com/imua-xyz/imuachain/releases/download/v${VERSION}/imuachain_${VERSION}_$(uname -s)_$(uname -m | sed 's/x86_64/amd64/' | sed 's/aarch64/arm64/').tar.gz"

Extract the binary and move it somewhere within$PATH (likely /usr/bin/). Doing so will require root privileges.

tar -xvzf imuad_${VERSION}.tar.gz
mv bin/imuad /usr/bin/

Check that it is installed and reports the correct version.

imuad version
1.1.1

Option 2: Compiling from Source

Detailed instructions are available .

Firewall

Depending on the configuration, a node will listen on many ports, such as those for the API (gRPC or REST for Cosmos, HTTP / Websocket RPC for Ethereum), Prometheus, pprof, Tendermint, etc. At the bare minimum, incoming connections should be allowed on the p2p port which defaults to 26656 over TCP. Other incoming connections (barring SSH or anything else you need to connect to the server) can be blocked for increased network layer security.

Option 1: Using UFW

# Block all incoming connections
ufw default deny incoming
# Allow SSH over port 22
ufw allow ssh
# Allow P2P incoming connections
ufw allow 26656/tcp
# Activate the firewall
ufw enable

Option 2: Using Firewalld

# Block all incoming connections
firewall-cmd --set-default-zone=drop
# Allow SSH over port 22
firewall-cmd --permanent --add-service=ssh
# Allow P2P incoming connections
firewall-cmd --permanent --add-port=26656/tcp
# Activate the firewall
firewall-cmd --reload

Initializing the Node

Once the binary is downloaded, the node needs to be initialized before it can join the network. The initialization process requires generating the validator key (even though the node may not be a validator) and the node’s configuration files.

CHAIN_ID="imuachaintestnet_233-8"
MONIKER="moniker" # an ASCII alphanumerical string
HOMEDIR="/home/$USER/.imuad" # this is the default if not provided
cosmovisor init $(which imuad)
imuad --home $HOMEDIR init $MONIKER --chain-id $CHAIN_ID
imuad --home $HOMEDIR config chain-id $CHAIN_ID

The validator's private key is stored in $HOMEDIR/config/priv_validator_key.json in plaintext. It is recommended to back this key up, since it is used by the validator to sign blocks. Alternatively, passing --recover to init will prompt for a BIP-39 mnemonic to be entered, from which the validator key is derived. In that case, the mnemonic may be backed up instead.

The public key corresponding to the validator key can be converted to the bytes32 format for use in Solidity (you might need to install jq).

imuad --output json --home $HOMEDIR keys consensus-pubkey-to-bytes | jq -r .bytes32
0xf0f6919e522c5b97db2c8255bff743f9dfddd7ad9fc37cb0c1670b480d0f9914

Keyring backend

imuad --home $HOMEDIR config keyring-backend file

Add an Account

You can generate a new key for use with the network, or recover an existing one with the --recover option. This key will be linked to an account, which is used to sign transactions on the network. All account addresses on Imua begin with "im1," indicating they're part of Imua.

ACCOUNT_KEY_NAME="my_key"
imuad --home $HOMEDIR keys add $ACCOUNT_KEY_NAME

- address: im17ekpjxmvm3k2dd2wg8f6jezsnk3dn388s3xn6y
  name: my_key
  pubkey: '{"@type":"/ethermint.crypto.v1.ethsecp256k1.PubKey","key":"ArhBGG18F0+kSqJksNJWoAF8NxunIgP7ySgnw622T3RR"}'
  type: local

**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.

example anchor example account example bone example entry example breeze example divorce example wrong example turkey example joy example seek example dune example chef

Ensure you back up the mnemonic phrase in a safe place.

Seeds

All nodes connect to seed nodes so that they can find their peers. Open the $HOMEDIR/config/config.toml file to find the seeds and the persistent_peers lines and edit them to match the following:

$HOMEDIR/config/config.toml
# Comma separated list of seed nodes to connect to
seeds = "5dfa2ddc4ce3535ef98470ffe108e6e12edd1955@seed2t.exocore-restaking.com:26656,4cc9c970fe52be4568942693ecfc2ee2cdb63d44@seed1t.exocore-restaking.com:26656"

# Comma separated list of nodes to keep persistent connections to
persistent_peers = "d5b8d5ac3f399d0fdd1678fa0f419bd0e55f944d@peer1t.exocore-restaking.com:20000,63ab38c845a9cd41f9626db0fd0a227d2407eb3e@peer2t.exocore-restaking.com:26656"

Other configuration

Changes in $HOMEDIR/config/config.toml and $HOMEDIR/config/app.toml may be made to activate and deactivate RPC servers or other features. For all nodes including validators, it is recommend to set at least minimum-gas-prices = "0.0001hua" in app.toml. For validators specifically, setting grpc.enable = true in app.toml is necessary to communicate with the price feeder.

$HOMEDIR/config/app.toml
###############################################################################
###                           Base Configuration                            ###
###############################################################################

# The minimum gas prices a validator is willing to accept for processing a
# transaction. A transaction's fees must meet the minimum of any denomination
# specified in this config (e.g. 0.25token1;0.0001token2).
minimum-gas-prices = "0.0001hua"

<! -- truncated -->

###############################################################################
###                           gRPC Configuration                            ###
###############################################################################

[grpc]

# Enable defines if the gRPC server should be enabled.
enable = true

Another type of key, known as the account key (referenced as$ACCOUNT_KEY_NAME), is used to sign transactions before they are broadcasted to the network. This key is protected by the keyring backend; it defaults to os which is not well suited for headless systems. It is recommended to change it to either file (which will use a password to protect the keys) or pass (which will use ). Refer to the for more details.

releases page
source
snapshot
here
pass
Cosmos SDK documentation