Supernova EVM extension-chain

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"
  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
3 Likes

what ports need to be open?

how should we respond to this question?

root@evm:~/supernova# supernovad keys add DeeZNNutz.com
Enter keyring passphrase (attempt 1/3):

I will provide the next steps zoon.

At the moment we should focus on creating the genesis.json file.

Input a strong passphrase. Make sure you remember it. You’ll need it each time you make operations involving the deeznnutz key.

should we add jq?

1 Like

just wanted to confirm that this is the message we need to sign in syrius (with the pillar address), correct?

How long till mainnet?

I get this response. I did replace --details *insert signature* with --details MY SIGNATURE FROM SYRIUS

Error: failed to fetch ‘validator’ from the keyring: validator.info: key not found
Usage:

I also noticed this command has --details without = and the others have --command="info". I also noticed --chain-id supernova_73406-1 does not have an =. Is this correct?

Thanks and congrats @aliencoder. #HyperGrowth Pillar be participating with 1 validator for the moment, open to more if needed but would like to let others join.

1 Like

Just added it.

The message you need to sign in syrius using the Pillar’s producer keystore is “Supernova insert tendermint/PubKeyEd25519” where tendermint/PubKeyEd25519 was extracted earlier using the cat ~/.supernova/config/priv_validator_key.json | jq -r '.pub_key.value' command.

Testnet and after that mainnet.

Good catch. I’ve edited the post. Replace validator with pillar_moniker from Step 6.

Flags can be used either way: --details SIGNATURE or --details="SIGNATURE", doesn’t matter.

It works both ways. The chainId is supernova_73406-1. This is the Cosmos chainId format. The EVM will have 73406 chain identifier.

DeeZ Bizzles was able to complete the steps.

2 Likes

Does it run on the same machine as the pillar or a separate one? What are the hardware requirements?

1 Like

If you have high specs on the Pillar you can run it on the same machine, but I don’t recommend it. A separate instance is better in the long run.

How about storage? The differences in the specs you linked are quite significant.

image

1 Like

Indeed, the storage can add up by a lot over a long period of time. I think the community should also run some archive nodes in order to be able to setup a reliable block explorer.

1 Like

@0x3639 volunteered to run a seed node that will be used to bootstrap the p2p network. I’ve updated the post to include instructions on how to run a seed node (step 13).

Anyone else that want to run a seed node?

Is this just a sentry/public node with a file with hardcoded ips for other seed nodes?

I’m still wainting on VPS provisioning. Would it make sense to have the Validator be a full archival node and connect to two sentries that act as pruned nodes? Can I have one of those pruned sentries act as a seed node? Then, sign me up.

Also, can you point out where to change the prunning setting, so I can set the validator as an archival node. Or, if that’s the default, change it for the sentries.

No. It’s used by other nodes to discover peers. Nothing is hardcoded. While the seed node itself doesn’t need a list of seeds, its nodeID@IP:PORT will be shared with other nodes in the network. They will add the seed node’s address to their config.toml under p2p.seeds.

It’s possible, yes.

I wouldn’t mix sentries with seed nodes. They serve different purposes. One sentry per validator is enough at the moment.

Navigate to /root/.supernova/config/app.toml and set pruning = nothing for an archival node.

1 Like

As long as pillar is behind sentry we can skip this for now? Know not priority but a topology specific to NoM similar to the referenced material would be helpful with pillars, sentries, orchestrators, evm, public nodes, soon sentinels

You can install the Tendermint Sentry on one of your existing NoM Sentry machines. They shouldn’t overlap since they’re using different ports.