Extension chains

Supernova extension-chain

Supernova will be the first Zenon EVM based extension-chain. Pillars that want to participate in the extension-chain genesis must follow the instructions below.

  • Based on Cronos codebase
  • Full EVM support
  • xZNN used as native gas token
  • Transaction fees are burned according to EIP-1559
  • ZNNxZNN gas fee for redeem
  • xZNNZNN gas fee + 1% swap fee distributed to extension-chain Pillars

Testnet Parameters

Chain-id: supernova_74506-1
Native coin: xZNN
Management token: stake (only used for Cosmos functionalities)

Tutorial

I recommend using Ubuntu 22.04 or latest Debian with >4vCPUs and >8GB RAM to run an extension-chain Pillar.

Root access is required. The Supernova directory is located at /root/.supernova

  1. Prepare the environment
sudo apt update && apt upgrade -y
sudo apt install build-essential jq ufw
sudo ufw enable
sudo ufw allow 26656/tcp  # Tendermint P2P
sudo ufw allow 26657/tcp  # Tendermint RPC
sudo ufw allow 1317/tcp   # Cosmos SDK REST API
sudo ufw allow 8545/tcp   # EVM HTTP RPC
sudo ufw allow 8546/tcp   # EVM WS RPC
sudo ufw reload
  1. Install Go
git clone https://github.com/udhos/update-golang
cd update-golang
sudo ./update-golang.sh
source /etc/profile.d/golang_path.sh
  1. Clone the repo
cd ~ && git clone https://github.com/alienc0der/supernova
  1. Build from source:
cd supernova
git pull
make build
  1. Add supernovad to PATH
echo 'export PATH=$PATH:/root/supernova/build' >> ~/.bashrc
source ~/.bashrc
  1. Initialize supernovad. Replace pillar_moniker with the name of your Pillar.
supernovad init pillar_moniker --chain-id supernova_74506-1
  1. Add pillar_moniker key
supernovad keys add pillar_moniker
  1. Mint stake for the pillar_moniker account
supernovad add-genesis-account pillar_moniker 1500000000000000000000stake
  1. Open Syrius desktop wallet, import your producer keystore from the Pillar’s machine and sign a message

Obtain the your own tendermint/PubKeyEd25519 using the following command:

cat ~/.supernova/config/priv_validator_key.json | jq -r '.pub_key.value'

Extract the tendermint/PubKeyEd25519 public key and sign the following message:

Supernova *insert tendermint/PubKeyEd25519*

Example message (use your own tendermint/PubKeyEd25519 extracted earlier using the cat command instead of the dummy “EmqJ95SK1AyKdTpauS9Fv7zmWrfIG+y+vX7h5vRQF9E=”:

Supernova EmqJ95SK1AyKdTpauS9Fv7zmWrfIG+y+vX7h5vRQF9E=

Copy the signature. You will need it in the next step.

  1. Issue gentx command with the signature from the previous step

Please note that the last parameter is --details *insert signature*. Replace insert signature with the actual signature from the previous step.

supernovad gentx pillar_moniker 1000000000000000000000stake --chain-id supernova_74506-1 --moniker="pillar_moniker" --min-self-delegation="1000000" --details *insert signature* --ip="127.0.0.1"

If successful, you will get the following message in the terminal window:

Genesis transaction written to /root/.supernova/config/gentx/gentx-0x0x0x0x0x0x0x0x0x0x.json.

:triangular_flag_on_post: :triangular_flag_on_post: :triangular_flag_on_post: Privacy warning: remove the “memo” field from the gentx that contains the public IP of the VPS instance where the validator will be hosted. For a secure operation of the extension-chain validator, please check Step 11.

  1. Send me via DM the resulting gentx-0x0x0x0x0x0x0x0x0x0x.json. Once there are more than 5 extension-chain Pillars, I will compile the genesis.json and post it here. After that we can coordinate to unleash the Supernova.

  2. Setup a Sentry node for the extension-chain Pillar (optional, recommended)

Create a new VPS with similar specs. Follow Steps 1 - 5. After that, initialize the sentry node:

supernovad init sentry --chain-id supernova_74506-1

Navigate to the configuration directory and edit the config.toml file with the parameters from the tables below. Peers are identified by node_id@ip:port. In order to get the node_id, use the following command:

supernovad tendermint show-node-id
vim /root/.supernova/config/config.toml

Validator Node Configuration

Config [p2p] Setting
pex false
persistent_peers list of sentry_node_id@ip:port
private_peer_ids none
unconditional_peer_ids optionally list sentry_node_id@ip:port
addr_book_strict false

Sentry Node Configuration

Config [p2p] Setting
pex true
persistent_peers validator_node_id@ip:port, optionally list sentry_node_id@ip:port
private_peer_ids validator_node_id
unconditional_peer_ids validator_node_id@ip:port, optionally list sentry_node_id@ip:port
addr_book_strict false
  1. Enable EVM RPC endpoint for the Sentry node (optional)

SSH into your Sentry instance. Navigate to the configuration directory and edit the app.toml file with the parameters from the table below.

vim /root/.supernova/config/app.toml
Config [json-rpc] Setting
address 0.0.0.0:8545
ws-address 0.0.0.0:8546
  1. Setup a seed node (optional)

Create a new VPS with similar specs. Follow Steps 1 - 5. After that, initialize the seed node:

supernovad init seed --chain-id supernova_74506-1

Navigate to the configuration directory and edit the config.toml file with the parameters from the table below.

Seed Node Configuration

Config [p2p] Setting
laddr tcp://0.0.0.0:26656
external_address vps_instance_public_ip:26656
seed_mode true
  1. Add Supernova seed nodes (kudos @0x3639 @tapwoot @coinselor)

Navigate to the configuration directory and edit the config.toml file with the following seed nodes:

seeds = "b91ab16e7454eeaabcb0d4c5d2f900a08ed518aa@5.196.22.239:26656,7efe3e47afbbf38c44179d3802aee4cad7af47eb@208.115.200.55:26656,7cd3cb605a8da6a7be20736c171ee33d307d6f88@3.94.70.251:26656"
  1. Setup a Systemd service (optional, recommended)
cp /root/supernova/build/supernovad /usr/local/bin/supernovad
sudo nano /etc/systemd/system/supernova.service

Assuming you’ve completed Step 5, paste the following configuration:

[Unit]
Description=supernova service
After=network.target
[Service]
LimitNOFILE=32768
User=root
Group=root
Type=simple
SuccessExitStatus=SIGKILL 9
ExecStart=/usr/local/bin/supernovad start
ExecStop=/usr/bin/pkill -9 supernovad
Restart=on-failure
TimeoutStopSec=10s
TimeoutStartSec=10s
[Install]
WantedBy=multi-user.target

Save and reload the configuration:

systemctl daemon-reload

Now please wait until the genesis.json contains all xchain Pillars that want to participate in the Gensis of the Supernova extension-chain.

After the final version of the genesis.json is uploaded on your machine, please start the supernovad service:

systemctl start supernova.service

:exclamation::exclamation::exclamation: Please make sure you’re running the latest supernovad binary :exclamation::exclamation::exclamation:

cd /root/supernova
git pull
make build
4 Likes

I’ve included the steps to run a seed node. It will be used to bootstrap the p2p network. All nodes will initially connect to the seed node(s).

1 Like

Pretty amazing.

How do you (or the community at large really) view the pros/cons of forking/launching their own extension chains?

For example if build_republic wanted to launch an extension chain with the same specs and call it “Andromeda” to set parameters for people building in our community, is that accretive or needlessly complex?

3 Likes

Positive. This is the idea of extension-chains: add value and enhance NoM. They should also inherit security from NoM and, by extension (in the future) from Bitcoin. You can view them as side-chains like Cosmos app-chains or Polkadot para-chains, but with a more streamlined approach regarding setup and security. This will be the next milestone in developing an ecosystem of NoM extension-chains.

I would encourage Build Republic to launch their own custom extension-chain that fits their users’ needs.

2 Likes

I wanted to be 100% sure that we need to sign the message from the producer address and NOT the pillar address. if that is the case @aliencoder I need to redo mine.

Yes. The reason we use the producer keystore is that it already acts as a “hot” wallet by participating in momentum signing for consensus operations. DO NOT touch the Pillar owner keystore. It must be kept in cold storage.

OK I need to redo what I sent you.

I find this step confusing. Omitting pex/addr_book_strict, no doubts there:

For the Sentry (single sentry setup):

persistent peers = "validator-node-id@validatorip:26656" (assumed p2p tendermint port)
private_peer_ids = "validator-node-id"
unconditional_peer_ids = "validator-node-id"

For the Validator (multiple sentry setup as an example) :

persistent peers = "sentry1-node-id@sentry1ip:26656,sentry2-node-id@sentry2ip:26656"
private_peer_ids = ""
unconditional_peer_ids = "sentry1-node-id,sentry2-node-id"

Does this look right?

just wanted to confirm that port 26656/tcp is the only port needed for peering and basic node functions.

I setup a seed node with no issues. I wanted to confirm these instructions do not mention starting the binary. I assume that will come later?

Yes.

I’ve included a systemd service setup in the tutorial as a final step, check it out!

1 Like

I’ve updated the post. The service must be started after everyone that wants to participate has the genesis.json file properly loaded.

I’m still gathering gentxs from Pillars. I’ll wait until Friday night for new entries.

Thank you everyone for your participation and commitment so far! :alien:

4 Likes

My plan is to start without the sentry first. That is just one more thing to troubleshoot if something is wrong. Once the testnet is up and running, I will add the sentry, but only after I know the network is up and my validator is working as expected.

Is there anyone in the community who might be able to spin up professional docs (def. A-Z worthy) for launching an extension chain?

Most EVM L2s are Optimism-based, likely in no small part to their docs: Getting Started with the OP Stack | Optimism Docs

1 Like

:exclamation::exclamation::exclamation: Please make sure you’re running the latest supernovad binary :exclamation::exclamation::exclamation:

cd /root/supernova
git pull
make build

Kudos to @0x3639 @tapwoot for the seed nodes. Please add them in the config.toml (Step 14).

1 Like

Some participants provided either malformed or invalid signatures.

Malformed signatures: @mehowz
Invalid signatures: @0x3639 @nbd

Update: @SultanOfStaking is ready now :white_check_mark:

1 Like

A+ tryhard alien :saluting_face: .

Can we currently vote on AZ with producer keystore? This would make sense to keep the Pillar key in cold storage.

My producer keystore has indeed the pub key exposed, but it just has a random “unknown” transaction from a random day. I had never imported it/used it on syrius until I signed the gentx. How can this be?

Actually all producer keystores must have the pubkey exposed because they are signing momentums. But I’ve only searched in the Zenon Tools explorer UI.

I need the public key in hex format. I’ll ask again for both the public key and the signature.

Current status:

@0x3639 :white_check_mark: :seedling:
@coinselor :white_check_mark: :seedling:
@tapwoot :white_check_mark: :seedling:
@mehowz :white_check_mark: :seedling:
@SultanOfStaking :white_check_mark:
@edgepillar :white_check_mark:
@sugoibtc :white_check_mark:
@nbd :white_check_mark:

Kudos again @0x3639 @coinselor @tapwoot for the seeder nodes :seedling:

5 Likes

I see @coinselor was added to the seed list. Do we need to update the config.toml to add his IP?

1 Like

I recommend updating the config.toml with all 3 seeder nodes.