Transition from testnet to mainnet

The tutorials located at: Installing Cardano-node - Stake pool course seem to still reflect that the latest version is 1.25.1 when the traffic here says that it is 1.31.0. So I wonder if there are differences.

Also the tutorial discusses setup for testnet only but obviously the objective is to get on MainNet. Are there tutorials for making the transition?

Also when building the 1.31.0 version I get the following build error:

cabal: Failed to build generic-deriving-1.14.1 (which is required by
shelley-spec-ledger-test-, cardano-ledger-alonzo-test- and
others). See the build log above for details.

I am using the tutorial steps except using tag 1.31.0 vs tag 1.25.1

Not sure if this is the best answer but one of the main pitfalls with following tutorials and forums in fast developing ecosystems is that there are so many guides and not all are up to date and sometimes they even conflict.

I myself used the coincashew guide which got me up and running without too much hassle - just make sure you follow every step and ensure every command you paste actually goes through and there are no errors.
You may be able to salvage some of what you have already done but if your Node is not even synced yet then it might be best to start over(someone correct me if im wrong please). Syncing the blockchain will by far take the longest amount of time(around 36hours for me)

This brings up a good point there should probably be a definitive place to check where the latest up to date guides are which may already exist but I am not aware of it.

Alot of people also use the tools/setup guides here →

See here how to monitor for node version updates:

Thanks for the links, I will give them a try. Obviously need to get set up on testnet first before risking mainnet.

Thank you for the link. And I agree an up to date official guide would be most beneficial. Unfortunately asking developers to document the systems they develop is always like pulling teeth. After all isn’t the source code all the documentation anyone ever needs :wink:?

isn’t the source code all the documentation anyone ever needs

That’s true. However, if you want fast results, you could also do …


More on how to run a cardano node with docker is here.

Good option. Right now I am planning on using just ec2 instances to make it easier to set up security controls. But one thing I notice is that all instructions seem to expect that the actual nodes will have all the build tools installed. From a security standpoint I feel like the nodes running cardano shoud NOT have any build tools installed and that a seperate machine should be used for building the binaries. Any suggestions on documentation for building on one machine and using that built binary to set up a node?

The other security hole I see is that the user that runs the script and the build needs sudo access but clearly they don’t want root running these tools. But if a non root user has sudo then basically they are root. It would be more sensible to build on one machine as root and deploy to a second machine to be run as a non-privileged user with constrained permissions. There is plenty of room for improvement on the security architecture front for cardano nodes.

The coincashew guide goes through building the binaries for the cardano-node/CLI and then transferring that CLI to an air-gapped offline machine to use for signing your transactions so your payment keys are generated /stored offline from your block producing node.

I went straight onto mainnet from the coincashew guide - its pretty straight forward if you read everything carefully

@map84 is right, go through this document. You can build the binaries anywhere and copy them to cold, hot, env… The guide is very very detailed.

Use CNTTOLS ( if you don’t want to do everything manually. I prefer the manual approach when first time setting up a pool as you will learn much about Cardano along the way.

I am reading through these documents and following along. Great stuff on securing and hardening servers. I do have one question however. I would like to run my nodes in a VPN and expose them through an AWS load balancer so that I can have the full force of AWS security protecting against syn flood attacks and the like. I would also like to hide the actual IP addresses of the relay nodes thereby helping to conceal their geographic location from would be theives who favor gaining physical access to the hosts. The plan would be to leverage the load balancer IP addresses instead, thus only having the load balancer exposed to the internet and everything else running on a private network secured via IPSec VPN. Does anyone have any knowledge of this configuration?

I have no experience with load balancers but can offer some insight into my setup if that helps.

You can use multiple layers of firewall, from the instance itself (commonly UFW), to AWS firewall tools and or another network router/firewall.

You have to register at least 1 of your relays I.P addresses (or DNS) within your pool registration certificate and this can also end up being used as a metric for your pool relay uptime/reliability on pool comparison sites.

Some people, myself included run unregistered second relays which are not published thereby making them less susceptible to a DDOS adversary.

typically you only open up the exact ports required for the nodes. On relays you will open typically port 6000 to the universe ( and you most likely need ssh access. Most attackers go for low hanging fruit so you should change the default SSH port away from 22 and in AWS you should only allow access to SSH from your current public IP address or use a VPN address space your PC has access to. I actually setup a static route that masquerades traffic to the public IP address of my nodes behind my VPN IP address and then whitelist that IP address for node access. That way I don’t even need the VPN on my nodes.

Thanks. I decided to try running the workloads in Linode instead. I have a relay node and a block node running cardano but there are issues.
First issue is that the relay server is getting errors in the logs as follows:

Nov 26 21:22:05 relay1 cardano-node[40408]: [relay1:cardano.node.ErrorPolicy:Notice:56] [2021-11-26
21:22:05.12 UTC] IP ErrorPolicySuspendConsumer (Just (ApplicationExceptionTrace (HandshakeError (Refused NodeToNodeV_7 “version data mismatch: NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}, diffusionMode = InitiatorAndResponderDiffusionMode} /= NodeToNodeVersionData {networkMagic = NetworkMagic {unNetworkMagic = 1097911063}, diffusionMode = InitiatorAndResponderDiffusionMode}”)))) 200s


Nov 26 21:16:34 relay1 cardano-node[40408]: [relay1:cardano.node.DnsSubscription:Warning:60] [2021-11-26 21:16:34.74 UTC] Domain: “” Failed to start all required subscriptions

I am running on testnet if that means anything i can see that the domain is, but there doesn’t seem to be a relays-new.cardano.testet.iohk

The second issue is that the block node can’t seem to connect to my relay node.

I used the directions located here: Guide: How to build a Cardano Stake Pool - CoinCashew

You can find the latest configurations here:

Both errors tell that you are trying to start a mainnet node. Network magic 764824073 and is mainnet.

Check the link above. Testnet magic is 1097911063 and topology

I suggest you use the Topology Updater for testnet as well.

See CoinCashew tutorial about how to setup the topologyUpdater scripts.

You need to pass the magic query parameter in both scripts by adding &magic=1097911063 to the URLs.

It takes at least 3 hourly heartbeats from your node so the topologyUpdater picks you up into an active nodes list. Then it’s just a wait until other nodes refresh their topology and you get included in their lists.
You should continue running topologyUpdater hourly in order to signal that your node is alive.

@mcrio Thanks! Looks like I copied the topology.json from the tutorial and inserted in to my testnet-topology.json file thus pointing to the wrong net.

I noticed something it seems like cardano will mix blockchains if you switch from testnet to mainnet. How is it possible that cardano doesn’t have stronger integrity checking on the integrity of it’s block chain?

The first error say that there is a mismatch between network magics, so I assume you may have used mainnet config files as well, beside the topology file?

Honestly, I never tried switching parameters from testnet to mainnet on the same installation. I assume it’ll either override the testnet database or keep them side by side.

Before going to mainnet clean all testnet related files. What I suggest is going with a clean OS install, making sure there are no undesirable configuration left from testing, and documenting each step you take. Later when you do any changes to the OS or the app you keep documenting everything.

I figured out that by going into $NODE_HOME/db and running rm -rf * the system starts synching again. But what I dont know is why GridLive view shows me that I am 94% synched and still only at epoch 171, when the mainnet is at epoch 305 right now.

Do you know of any other tools that can be used to introspect and validate the block chain that is stored locally. I saw one tool that moves the block chain to a postgress db for analysis but I don’t know that I want to install postgress on my block nodes.

You can execute cardano-cli query tip --mainnet and check syncProgress for the sync progress.

You are probably referring to db-sync GitHub - input-output-hk/cardano-db-sync: A component that follows the Cardano chain and stores blocks and transactions in PostgreSQL

This may be correct as at the beginning there were far fewer transactions per epoch than today.

When I run cardano-cli query tip --mainnet I get the following:
cardano-cli: HandshakeError (Refused NodeToClientV_10 “version data mismatch: NodeToClientVersionData {networkMagic = NetworkMagic {unNetworkMagic = 1097911063}} /= NodeToClientVersionData {networkMagic = NetworkMagic {unNetworkMagic = 764824073}}”)

This leads me to believe something is wrong