Spinning up a testnet node - first user experience

1

Hey folks, yesterday I got a testnet node up and running on a little digitalocean droplet. It was a reasonably painless experience and I’m excited to be taking part.

I kept a sort of stream of consciousness log of what I was doing as I set up the node. I’m posting it here in case it’s useful to anyone.

  • First, read the docs
    • “getting started”
      • Okay there’s a download link for binaries
      • A simple description of how to start the binary. Looks like it bootstraps a connection without much configuration, great.
      • I’m going to need to wait for it to sync up, presumably there’s not a lot to sync right now but I wonder where it stores it’s state.
      • Hmm, mining blocks is different to just running a node, which makes sense to me but I wonder how obvious that will be to people who haven’t run other blockchain clients before. Anyway, I’m going to want to do that so let’s take a look at the full node setup
      • Oh the link is broken, off we go to report that
    • “full node setup”
      • Right yeah we’ll need to specify where the node stores it’s data
      • I can set my own bootstrap nodes, not really interested in that right now
      • Right, we need an account, presumably the keys for that are stored in the data dir?
      • Right, I can specify a node key pair if I want. But do I want to? Probably, I’m planning on running this on a digital ocean droplet and I don’t want to worry about it disappearing with my keys. So I guess I’ll generate a keypair and store the private key elsewhere. Or can I just let it start up and then download the private key? I’ll try that first.
      • What monitoring do I want? I’ll probably run this using systemd and just rely on the logs in the journal. Happy to send Polkadot telemetry.
      • I’m not going to expose the RPC for now, I can always tunnel to it if I want access for my own uses.
  • Okay, let’s get started then, firs to spin up a Digital Ocean droplet. I’m just going to use a tiny $5 one for now, with a 50Gb block store, I’m guessing the chain is going to be pretty small for a while
  • Right, droplet up, let’s grab the binaries.
    • Downloaded from the github release, can’t see any kind of hash I can use to verify integrity of download
  • Alright, running the binary with --data-path set to the block store I’ve attached to this droplet
    • There’s a bunch of output, some stuff about the versions of various components, the chain name, a line about initializing genesis state. Then this slightly confusing Highest known block at #0. What does that mean? The highest known block is 0?
    • Mining is disabled, which is fine, I’m just seeing how the thing runs right now.
    • I have 7 peers apparently, very exciting.
    • Output has changed from syncing to idle after a few minutes, I’m guessing that means we’re synced up now? I’m not certain though, feels like the logs should say that if that’s the case?
  • Right, let’s try running a few queries against our node to see if it’s working
    • Ha, listing organisations shows monadic, looks like things are working.
  • Okay, now I want to see if I can get this thing to mine
    • Shutting down the node
    • running radicle-registry-cli account generate mining
    • Hmm, some kind of error: “Failed to read accounts file: Permission denied”. What is an accounts file?
    • Okay that was just an artifact of something about the way this droplet had been set up. For some reason ~/.local was owned by root, fixing that solved the problem. I just figured that out by running ls in the home directory and looking for things that didn’t belong to my user though, might be useful to log where the CLI is trying to create the accounts file. I couldn’t see anything about it in the help
    • Right, now to startup the node again but this time with --mine <address>
      • Okay now we have “Role: Full” which looks good
      • I’m seeing logs saying stuff like “Prepared block for proposing” which also looks like a good sign
      • Interestingly this time the “highest known block” log line says “highest known block at #11211”, I wonder if the #0 before was a bug?
      • I’m confused abut whether these prepared block for proposing log lines mean that my node has a block it’s proposing, or whether this is something that’s happening on the network. It happens immediately after a log line saying imported ... so I’m guessing the latter. Checking my own balance shows a balance of 0 still so that adds up.
      • I have no idea what the hashrate of the network is right now and I’m running on a tiny droplet so I guess it’s fairly unlikely I’ll mine anything any time soon.
      • Ah I’ve just noticed that the docs say “If your node successfully mined a block and imported it will log Imported own block”, cool.
  • Right, now I’m going to wrap this all up in a systemd unit file
    • I’ve just copied the binaries into /usr/local/bin and made a simple unit file with the invocation I was using on the command line
    • Unit is running fine, logs are showing a warn though: sc_basic_authorship::basic_authorship Timeout fired waiting for transaction pool to be ready. Proceeding to block production anyway. What does that mean?
    • Hmm, it might not be worth worrying about. It also fires when I run the binary in the shell, it’s just that in the shell the log levels aren’t visible so it didn’t worry me.
  • Final thing then, I want to download my private key. From the previous error I’m guessing it’s in .local somewhere.
    • Right, in ~/.local/share/redicle-registry-cli/accounts.json there’s a json file containing a mining.seed key, I’ll just save that somewhere safe.
  • Oh look at that, I just checked my balance and I have 2000uRad funfunfun
5 Likes
2

I’m sure the @registry will want to read this.

Thanks Alex!

3

Thanks again for the great feedback! We started recording this in issues (#413, #412, #411). Feel free to chime in there.

One thing we didn’t convey properly is the relationship between account keys and the mining address. You created the mining account with radicle-registry-cli account generate on the machine that is running the node and used the SS58 address that was output as the --mine argument. It’s not necessary to generate (and store) the account on the machine that is running the node. In fact a miner does not access any confidential keys at all. It only needs the public SS58 address of the account that should be the mining beneficiary. If you have any suggestions how to better explain this it would be very much appreciated.

1 Like
4

Thanks again Alex, great to see this type of feedback :raised_hands:

5

Happy to help :slightly_smiling_face:

Regarding the account keys stuff. I think the source of my confusion was this line in the full node docs:

Every node has a key pair, which is used to identify it on the P2P network. It’s useful for building ties with other nodes. By default the key pair is generated on every startup, but you can set it manually to store and reuse later. To do that, you must pass the private key file on the node startup:

I read that and somehow came to the conclusion that the private key of the node was required for the mining process. This did confuse me a bit as my experience with other blockchains was different but I haven’t read (or seen) a detailed spec of the Radicle blockchain so I just carried on.

I think what would have worked for me would have been to add a few sentences to the start of the “mining” section, which currently looks like this:

You can support the network by mining blocks. Miners receive rewards from successfully mined blocks. To collect your rewards, you need an account.

Instead, some general recommendations about where to generate that account and how to secure it would have helped.

You can support the network by mining blocks. Miners receive rewards from successfully mined blocks. To collect your rewards, you need an account. Accounts are identified by an address derived from some private data. The mining node only needs access to the address, we suggest running the following commands on a different machine and/or storing the account file in a secure location.

Hmm, this is not very general because it only works in situations like mine where you’re setting up a dedicated server for mining. Probably the most important thing is just to explain that the node doesn’t need the seed.

1 Like
6

Yeah, I see how that led to confusion.

Thank you so much for your extensive and clear feedback, @alexgood.
I am gladly addressing it. If you have a chance to have a look at the issues listed above by @geigerzaehler and the PR’s raised for some (more to come), it’d be awesome.