Interplanetary Consensus Protocol tTNT IPC devnet

Guide to Setting Up tTNT devnet as local IPC subnet with One Validator

Prepare Your Environment

instructions are somewhat specific to Ubuntu 22.04LTS and Debian Linux variant operating systems

Ensure you have the necessary dependencies installed, including Docker and Rust.

sudo apt update
sudo apt install build-essential clang cmake pkg-config libssl-dev protobuf-compiler git curl

# Install Rust
curl https://sh.rustup.rs -sSf | sh
source $HOME/.cargo/env

# Install cargo-make
cargo install --force cargo-make

# Install Docker
sudo apt install docker.io
sudo systemctl start docker
sudo systemctl enable docker

Clone the IPC Repository and Build

Clone the IPC repository and build the binaries.

git clone https://github.com/consensus-shipyard/ipc.git
cd ipc
make

Initialize Your Config

alias ipc-cli="cargo run -q -p ipc-cli --release --"
ipc-cli config init

Create a new wallet for the validator.

ipc-cli wallet new --wallet-type evm

Export the private key for the newly created wallet.

ipc-cli wallet export --wallet-type evm --address --hex > ~/.ipc/validator_1.sk

Connect to Filecoin calibration testnet with metamask

Network Name: Filecoin - Calibration testnet
RPC URL: https://filecoin-calibration.chainup.net/rpc/v1
ChainID: 314159
Currency Symbol: tFIL
Block Explorer URL: https://calibration.filscan.io/en

Deploy your tTNT IGAS contract with tFIL testnet

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract IGAS is ERC20, Ownable {
    uint256 private immutable INITIAL_SUPPLY = 100_000_000 * 10**18;

    constructor() ERC20("tTHRUST", "tTNT") Ownable(msg.sender) {
        _mint(msg.sender, INITIAL_SUPPLY);
    }
}

Filecoin mainnet IPC configuration

keystore_path = "~/.ipc"

# Filecoin Calibration
[[subnets]]
id = "/r314159"

[subnets.config]
network_type = "fevm"
provider_http = "https://api.calibration.node.glif.io/rpc/v1"
gateway_addr = "0x1AEe8A878a22280fc2753b3C63571C8F895D2FE3"
registry_addr = "0x0b4e239FF21b40120cDa817fba77bD1B366c1bcD"

Calibration testnet IPC configuration (incomplete) to use the deployed IGAS token as the gas token.

deploy required contracts from ipc/contracts/src/

Update ~/.ipc/config.toml:

keystore_path = "~/.ipc"

[[subnets]]
id = "/r314159"

[subnets.config]
network_type = "Filecoin - Calibration testnet"
provider_http = "https://filecoin-calibration.chainup.net/rpc/v1"
gateway_addr = "0x1AEe8A878a22280fc2753b3C63571C8F895D2FE3"
registry_addr = "0x0b4e239FF21b40120cDa817fba77bD1B366c1bcD"
gas_token_addr = "0xec745aaeb606b0da0474c95575d629eb331be7e7"

Create the tTNT IPC subnet specifying the custom gas token and setting the minimum validators to 1 for local tTNT devnet

ipc-cli subnet create --parent /r314159 --min-validator-stake 1 --min-validators 1 --bottomup-check-period 300 --from <WALLET_ADDRESS> --permission-mode collateral --supply-source-kind native --gas-token <IGAS_CONTRACT_ADDRESS>

Bootstrap the subnet by joining with your single validator

ipc-cli subnet join --from=<WALLET_ADDRESS> --subnet=<SUBNET_ID> --collateral=10 --initial-balance 1

Start the validator node using Docker. Replace <SUBNET_ID> and other placeholders with actual values:

cargo make --makefile infra/fendermint/Makefile.toml \
    -e NODE_NAME=validator-1 \
    -e PRIVATE_KEY_PATH=~/.ipc/validator_1.sk \
    -e SUBNET_ID=<SUBNET_ID> \
    -e CMT_P2P_HOST_PORT=26656 \
    -e CMT_RPC_HOST_PORT=26657 \
    -e ETHAPI_HOST_PORT=8545 \
    -e RESOLVER_HOST_PORT=26655 \
    -e PARENT_GATEWAY=`curl -s https://raw.githubusercontent.com/consensus-shipyard/ipc/cd/contracts/deployments/r314159.json | jq -r '.gateway_addr'` \
    -e PARENT_REGISTRY=`curl -s https://raw.githubusercontent.com/consensus-shipyard/ipc/cd/contracts/deployments/r314159.json | jq -r '.registry_addr'` \
    child-validator


By following these steps, you can set up a local tTHRUST tTNT subnet with a single validator for development purposes. This setup allows you to test and develop your dApps and custom gas tokens in a controlled environment. Make sure to replace all placeholder values with actual values specific to your deployment. This guide assumes you have basic knowledge of deploying smart contracts and working with Docker.

Understanding Subnet ID in IPC

Subnet ID is a unique identifier for a subnet in the Interplanetary Consensus (IPC) network. It is used to distinguish and address subnets within the hierarchical structure of IPC. When you create a subnet, the system assigns it a unique ID, which is essential for managing and interacting with the subnet.

Create tTNT Subnet

When you create a subnet using the ipc-cli, the command will return the Subnet ID of your tTNT

ipc-cli subnet create --parent /r314159 --min-validator-stake 1 --min-validators 1 --bottomup-check-period 300 --from <WALLET_ADDRESS> --permission-mode collateral --supply-source-kind native --gas-token <IGAS_CONTRACT_ADDRESS>


Parameters Explanation

    --parent /r314159: Specifies the parent subnet. For the root subnet, this is a fixed value.
    --min-validator-stake 1: Minimum stake required for validators.
    --min-validators 1: Minimum number of validators needed for the subnet.
    --bottomup-check-period 300: Checkpoint period.
    --from <WALLET_ADDRESS>: Address of the wallet creating the subnet.
    --permission-mode collateral: Permission mode.
    --supply-source-kind native: Supply source kind.
    --gas-token <IGAS_CONTRACT_ADDRESS>: Address of the custom gas token contract.

After running the command, you will receive an output similar to:

"id": "/r314159/t410fx2xy6x6idpy6yfywiilp6uitq4eerhpdr72wtmi"

Store the Subnet ID

Make sure to store this Subnet ID safely, as you will need it for subsequent operations within the tTNT subnet, such as adding validators, joining the tTNT subnet, or interacting with contracts deployed on the tTNT subnet.

Using the Subnet ID

Joining the Subnet

When validators or participants join the tTNT subnet, they use the Subnet ID to specify which subnet they are joining:

Store the Subnet ID

Make sure to store this Subnet ID safely, as you will need it for subsequent operations within this subnet, such as adding validators, joining the subnet, or interacting with contracts deployed on the subnet.
Using the Subnet ID
Joining the Subnet

When validators or participants join the subnet, they use the Subnet ID to specify which subnet they are joining:

When deploying the validator node, use the Subnet ID to configure the node appropriately:

cargo make --makefile infra/fendermint/Makefile.toml \
    -e NODE_NAME=validator-1 \
    -e PRIVATE_KEY_PATH=~/.ipc/validator_1.sk \
    -e SUBNET_ID=<SUBNET_ID> \
    -e CMT_P2P_HOST_PORT=26656 \
    -e CMT_RPC_HOST_PORT=26657 \
    -e ETHAPI_HOST_PORT=8545 \
    -e RESOLVER_HOST_PORT=26655 \
    -e PARENT_GATEWAY=`curl -s https://raw.githubusercontent.com/consensus-shipyard/ipc/cd/contracts/deployments/r314159.json | jq -r '.gateway_addr'` \
    -e PARENT_REGISTRY=`curl -s https://raw.githubusercontent.com/consensus-shipyard/ipc/cd/contracts/deployments/r314159.json | jq -r '.registry_addr'` \
    child-validator

The gateway_addr and registry_addr are specific addresses used within the IPC framework for managing the subnet’s interactions with the parent chain and its internal registry of addresses. These addresses are essential for the proper functioning and communication of your IPC subnet with the main chain.

Understanding gateway_addr and registry_addr

Gateway Address (gateway_addr):

  • The gateway_addr is the address of the gateway contract on the parent chain (in this case, the Filecoin Calibration testnet). This contract is responsible for handling cross-chain transactions and ensuring that messages and state changes can be propagated between the parent chain and the subnet.

Registry Address (registry_addr):

  • The registry_addr is the address of the registry contract on the parent chain. This contract maintains a record of various subnets, their associated addresses, and relevant metadata. It is crucial for the hierarchical organization and management of subnets within the IPC framework.

The Subnet ID is crucial for identifying and managing tTNT subnets within the IPC framework. It is created when you run the subnet creation command and is returned in the output. Store this ID safely, as you will need it for all subsequent operations related to the tTNT subnet. This ID ensures that all interactions, configurations, and operations are correctly targeted to the intended subnet.

cryptocurrency news

blockchain buzz

Proof of Stake vs. Delegated Proof of Stake: A Comprehensive Analysis

Blockchain technology has introduced a new paradigm in decentralization, trust, and financial systems. At the core of these blockchain networks are consensus mechanisms, which ensure that all participants agree on the state of the ledger. Two popular consensus mechanisms are Proof of Stake (PoS) and Delegated Proof of Stake (DPoS). This article delves into the intricacies of both mechanisms, outlining their advantages and disadvantages, and introduces the concept of Litenode Staking within DPoS. Proof of Stake (PoS) Proof of Stake is a consensus mechanism where validators are chosen to create new blocks and validate transactions based on the number of […]

Learn More

Foundry for solidity development

Foundry is swiftly becoming a cornerstone in the world of Ethereum development, thanks to its robust suite of tools designed to optimize the workflow of Solidity smart contract development. With its roots deeply embedded in the principles of efficiency, speed, and reliability, Foundry offers developers an exceptional environment to compile, test, deploy, and interact with smart contracts on EVM networks. What is Foundry? Developed by the Foundry-rs team and supported by Paradigm, Foundry integrates essential developer tools such as Forge, Cast, and Anvil, each tailored for specific stages of the smart contract lifecycle. This integrated approach not only simplifies but […]

Learn More

What is IBC?

Inter-Blockchain Communication (IBC) is a protocol that allows different blockchain networks to communicate with each other. It enables the transfer of tokens and other data across different blockchain platforms in a secure and decentralized manner. IBC is particularly useful in creating interconnected ecosystems where multiple blockchains can work together seamlessly. Why Use IBC with LAIR3-BDK? Integrating IBC with the LAIR3-BDK (Layer 3 Blockchain Development Kit) offers several benefits: How IBC Works IBC operates using a set of standardized protocols that handle the communication between blockchains. Here’s a simplified overview of how IBC works: Detailed Explanation of IBC Integration with LAIR3-BDK […]

Learn More