A Non-Technical Guide for Running a Stake Pool: Part 2
This article series is meant to provide a guide for non technical people to understand what is involved in running a Cardano Stake Pool. We hope pool operators can pick up a few tidbits along the way as well! Part 1 of was focused on choosing a server and can be found here.
Part 2: Building Software and Networking
Building the Cardano Node
The Haskell software which will run on the main net is currently called “cardano-node” and can be found on Github (https://github.com/input-output-hk/cardano-node). Github is an extremely popular software code hosting platform. Nerdy side note, it is called Github, because it uses a popular version control program called git. Git allows for versioning/tracking of all changes ever made to the source code (and is a developers best friend). The software developed by IOHK is open source, which means that anyone can look at the actual code, for example…
pTextViewCmd =
Opt.subparser $
mconcat
[ Opt.command “decode-cbor”
(Opt.info (TextViewInfo <$> pCBORInFile <*> pMaybeOutputFile)
$ Opt.progDesc “Print a TextView file as decoded CBOR.”
)
]
If your head doesn’t hurt from seeing that, you must be a Haskell developer! Most operators will never need to or want to look at the code, but the fact that it is open source means that anyone can find and report bugs and the developers can’t hide back doors or other nefarious things in the software.
The process of turning the source code (head hurt from above), into machine code an operator can run is called compiling. Nerdy side note two, not all programming languages require compiling, some are interpreted, meaning an interpreter turns it into machine code when it runs (i.e. Javascript). Programs do need compiled to run on different systems. For example, a program compiled to run on Windows, won’t work on a Mac. Often times, open source projects will provide builds of their software for these different systems. Right now, the cardano-node project doesn’t, so this means operators have to compile the software first.
The compiling process is different depending on the programming language, but the basic process involves installing the right dependencies, downloading the source code from Github, and running the proper build commands. The output of this process is the cardano-node executables!
Running the Software / Networking
Now that the software is built and is compiled for the system, it is time to get it running. Running the software involves passing in the appropriate config files to the executable. The config files define the location of the network (where to connect) as well as a multitude of other parameters. These files are provided by IOHK, so getting a single relay node running is relatively straightforward. Wait, did I just hear “relay” node, are they racing? The cardano-node software can be started as a “relay” or “block producing” nodes. The block producing nodes are the ones that will actually create blocks and broadcast them out. The relay nodes exist to receive the broadcasted blocks and relay them to the wider network, as well as relay blocks from the wider network to the block producing node.
It is important to note that the actual cardano-node software is the same whether it is being run as a relay or block producing node, it is just configured to start differently. The idea is that the block producing node will be isolated from the internet and only be able to communicate with it’s relay nodes. It is up to the pool operator to configure the relay and block producing nodes appropriately. There is nothing stopping an operator from running one block producing node open to the world with no relay nodes (DO NOT DO THIS). There is also nothing stopping operators from running one block producing and multiple relay nodes on the same server (while this is fine for a test network, we HIGHLY recommend against doing this when the main network starts).
You may be wondering why we are so adamant that the different nodes be isolated. This is for several reasons. The most important is that the block producing nodes will hold some of the operators private keys, which means it needs to be as secure as possible (we will talk about keys more in another article) and needs to be running to make blocks. The more open a node is to the internet, the easier it is to target. Ideally, the block producing node should be closed off from the internet completely and only communicate with the relay nodes. The second reason is that having multiple relay nodes on different servers, or virtual machines, adds resiliency into the setup, so if one relay node goes down, the pool can keep producing blocks through another relay.
How the operator goes about setting up the network topology is heavily dependent on how the operator chooses to run the pool. If the pool is running in the cloud, relay nodes could be put in different data centers. If running at home, the operator may isolate the nodes in different virtual machines or maybe even different servers.
Summary
As you can see, the first thing to do after choosing where to run the software, is to compile it so it can be run. In the future, the compiled software may be provided so this step will be simplified to just downloading the appropriate version and build for the chosen operating system. After the software is built, the operator can start configuring it to run in an appropriate network topology and connect it to the larger Cardano network.
