Public
Authored by Mark Brooker

PoS testing brain dump

Some random thoughts about testing on the Crown PoS testnet.

I generally assume testers are somewhat familiar with setting up systemnodes/masternodes because in the Crown PoS implementation only nodes stake. There are PoS testnet install/upgrade instructions at https://gitlab.crown.tech/walkjivefly/crown-core/snippets/5 which are very similar to the normal SN/MN installation instructions in the Crown forum (https://forum.crown.tech/index.php?topic=7705.0 and https://forum.crown.tech/index.php?topic=7706.0)

Test plan

There is no formal testing plan. Test anything you can think of. Some possibilities are:

  • node creation
    • startup, shutdown and operation
  • normal sends
  • instant sends
    • to yourself and others
  • proposal preparation and submission
  • proposal voting
  • obviously make sure you're receiving node rewards and stake rewards. On testnet they are respectively 4.5, 0.9 and 3.6 tCRW.
  • take a look at your nodes' debug.log files. If you see errors please follow the instructions below...

What to do if you find a problem

If you encounter a problem please mention it in the Discord #testing-mn-pos channel and/or check if it has already been reported in Gitlab https://gitlab.crown.tech/crown/crown-core/issues If the problem has not been reported yet, and you know how to, please open a new issue for it.

Block generation times

The block time on testnet is 90 seconds instead of 60. If you think there's an issue with the block generation times you can get an idea of the timing by:

cd .crown/testnet3
grep UpdateTip debug.log

This will show you the times your node received blocks which is usually a close approximation to when they were generated. If you look to the right end of each line you can see the actual block generation times.

Checking node status

Here's a little script check_node that you can install on your node by:

wget https://gitlab.crown.tech/uploads/-/system/personal_snippet/6/ee556560c50b296355bd6ebb2bd6dcab/check_node
chmod +x check_node
sudo mv check_node /usr/local/bin

You can run it remotely by something like:

ssh pmn01 check_node label

where label is something to remind you which node you're checking. I expect there's a PuTty equivalent, but don't do winbloze so don't know what it is. It reports the protocol version, node current block height, masternode or systemnode status text and staking status.

If you have a bunch of nodes you can simplify checking the status of all of them by adapting this script checkpos. Edit the list of node names to suit your ssh configuration, stick it somewhere in your path and run it whenever you feel curious. The checkpos script runs check_node on each node, eg:

mark@x230:~/bin$ checkpos
morra1: 27988 - Masternode successfully started - "staking_active" : true,
morra2: 27988 - Masternode successfully started - "staking_active" : true,
pmn01: 27988 - Masternode successfully started - "staking_active" : true,
pmn02: 27988 - Masternode successfully started - "staking_active" : true,
...

It can also send an additional command when required, eg:

mark@x230:~/tmp$ checkpos crown-cli getblockhash 27929
morra1: 27974 - Masternode successfully started - "staking_active" : true,
460b4c9ccab49e121740826dca5c7db73884b41028fc3070e53c193e0ee3b7aa
morra2: 27974 - Masternode successfully started - "staking_active" : true,
460b4c9ccab49e121740826dca5c7db73884b41028fc3070e53c193e0ee3b7aa
...

The additional command can be anything you like but the script is super simple. It doesn't do anything clever with the arguments so shell processing might mean some commands don't work as expected. You might have to get creative with quoting and escape characters!

Check which version of the code you're running and/or when the node was (re-)started

grep "Crown version" ~/.crown/testnet3/debug.log

You need this info if you open an issue in Gitlab and use the standard bug template. If you installed the node using the pos-server-install.sh script this grep might well return no results because...

logrotate

pos-server-install.sh configures logrotate to rotate debug.log and instantsend.log daily to try to prevent storage exhaustion. logrotate is configured to rename and compress upto 4 days worth of logs. If you don't find what you're looking for in debug.log you can use gunzip to uncompress previous logs.

If you restart a node it is possible to lose debug.log information because by default Crown uses shrinkdebugfile=1 which truncates debug.log if it larger than 10MB (iirc) at startup. To prevent this you can configure shrinkdebugfile=0 in crown.conf

How big is testnet?

You can get the answer from the GUI wallet masternode and systemnode tabs, but if you're not a GUI wallet user you can

crown-cli masternode count
crown-cli systemnode count

Actually, you can use crown-cli commands even if you are a GUI wallet user.

Simplifying access to testnet wallet when it shares a machine with your normal wallet

Create an alias or shell script for each of the commands you want to use. For example I have these aliases:

alias pcrowncli='/home/mark/.crownpos/bin/crown-cli -testnet -conf=/home/mark/.crownpos/crownpos.conf -datadir=/home/mark/.crownpos'
alias pcrownd='/home/mark/.crownpos/bin/crownd -testnet -conf=/home/mark/.crownpos/crownpos.conf -datadir=/home/mark/.crownpos'
alias pcrownqt='/home/mark/.crownpos/bin/crown-qt -testnet -conf=/home/mark/.crownpos/crownpos.conf -datadir=/home/mark/.crownpos'

so I can easily

pcrowncli sendtoaddress tWherever loadsadosh
pcrowncli mnbudget nextblock

etc

Edited
680 Bytes
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment