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.
@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.
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.
Please make sure you’re running the latest supernovad
binary
cd /root/supernova
git pull
make build
Kudos to @0x3639 @tapwoot for the seed nodes. Please add them in the config.toml
(Step 14).
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
@coinselor
@tapwoot
@mehowz
@SultanOfStaking
@edgepillar
@sugoibtc
@nbd
Kudos again @0x3639 @coinselor @tapwoot for the seeder nodes
how many do we need active for the extension to run?
A minimum of 3 extension-chain Pillars.
I’ll wait for @mehowbrainz @nbd and after that I’ll post the genesis.json
with genesis_time
12 hours into the future, such that everyone will have enough time to upload the genesis and start the supernova
service.
Unfortunately, I’ve discovered a small mistake in the gentx
command (the chain-id
) and you’ll need to redo the genesis transaction for your extension-chain Pillar.
rm -rf /root/.supernova/config/gentx/gentx-*
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"
Please note that I’ve added the --ip
parameter where I’ve specified the localhost instead of the public IP. We can’t remove the memo
field after it’s signed because we invalidate the signature by doing so.
Check the hash of the genesis.json
file:
sha256sum genesis.json
Should output:
76852615be093232825da9e16bc801445316a191bb7e4e7f806fde0cc9b42478
Commands to run:
supernovad tendermint unsafe-reset-all
rm /root/.supernova/config/genesis.json
nano /root/.supernova/config/genesis.json
Paste the contents of the genesis.json
and Control+x
to exit and Y
to save.
Fixing the supernova.service
:
cp /root/supernova/build/supernovad /usr/local/bin/supernovad
Edit this line from supernova.service
:
…
ExecStart=/usr/local/bin/supernovad start
…
systemctl daemon-reload
After that you can start the supernova service
:
systemctl start supernova.service
Please add @mehowbrainz’s seed node to the seeds
entry in the config.toml
:
seeds = "b91ab16e7454eeaabcb0d4c5d2f900a08ed518aa@5.196.22.239:26656,7efe3e47afbbf38c44179d3802aee4cad7af47eb@208.115.200.55:26656,7cd3cb605a8da6a7be20736c171ee33d307d6f88@3.94.70.251:26656"
I will prepare the mainnet rollout for Supernova ZVM. We still need to accomplish 2 things in the meanwhile:
- A fully functional explorer: @mehowz’s dev is helping us with devops and @0x3639 can host the archive node for it.
- A fully functional bridge interface to seamlessly swap
ZNN
andxZNN
. Here @dexter703 can help us or anyone that has experience with frontend development.
Is it possible to have a P2P bridge in S Y R I U S?
The swaps between xZNN
and ZNN
are enabled by the bridge orchestrators
. If anyone is interested in creating a bridge interface in Flutter, then we can integrate it directly into Syrius.
But we first need support for Ethereum in Syrius to make this possible (Supernova uses Ethereum’s secp256k1
and RPCs to operate).
@aliencoder If you need any help with art stuff, or a collection to test (NFT) please let me know via TG (@itsdyddy) or here.
You can prepare a new collection for the extension-chain mainnet launch (zoon).
Hello, Aliens
I’ve re-purposed the Zenon Bridge interface to support Supernova ZVM.
Supernova Testnet Bridge interface:
@0x3639 @mehowbrainz @aliencoder you can start testing it.
Thank you @dexter703! You’ve done an amazing work so far!
I’ve released a statically linked supernovad
binary with rocksdb
support to enable faster transaction throughput and block sync.
rocksdb
is much more efficient than goleveldb
given that it’s written in C++
and is maintained by Facebook:
Please download and update your supernovad
binary:
https://github.com/alienc0der/supernova/releases/tag/v0.0.1-50-g365b09c-2-gf52ef95
If you’re running a supernova
node, please:
- Delete all blockchain files from
~/.supernova/data
directory, - Add
db_backend = "rocksdb"
to~/.supernova/config/config.toml
. - Resync from scratch.
rocksdb
is not compatible withgoleveldb
format.
It is mandatory by all Pillars that run extension-chain validators to upgrade to supernovad
with rocksdb
support.