• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

How to create a no fuss Evo node in v19

xkcd

Well-known member
Masternode Owner/Operator
Evo nodes aka High Performance nodes https://www.dash.org/hpmn-faq/ are Masternodes that will be required to run Platform services in v20 onwards, slated for release in December 2023*. This node type requires the collateralisation of 4000 Dash. During v19 the network will be in a transitory period where an Evo node can be registered, but is not yet required to run the full gamut of platform services. During v19, the Evo node will be paid 4 blocks in a row and get four votes with each vote of the node. Post v20 the payments will change, where the node is paid once each cycle same as a regular masternode and then collects about 3/4 of its rewards from Platform once every 18 days. The advantage of running an Evo node now, during the v19 period is you signal your intent to run platform services when v20 is released and you get to host 1 node on one server instead of 4 as with 4 regular nodes, which saves you hosting fees and your time.

This guide will get you up and running an Evo node with no fuss as quick as possible!

Step 1. Send the collateral

Similar to regular masternodes, you need to send 4000 Dash in one transaction to an address you control, ideally in your Trezor hardware wallet. Once done, use the site https://chainz.cryptoid.info/dash/ to note the transaction hash and the index of the 4000 Dash outpoint. Alternatively, if you are using the core wallet, issue the command masternode outputs to find this same information.

Step 2. Generate new keys

In the core wallet, open the console and issue bls generate to create your BLS key pair and copy this to notepad for later. Use the Receive tab to name the address, and create the next 4 addresses for the following keys.

  • Owner
  • Voting
  • Payout
  • Funding
Copy these to notepad also.

Step 3. Funding the protx

In your core wallet, send 800 Duffs only to the address you labelled as 'Funding' this will be used to pay the transaction fee of the protx command.

Step 4. Generate the NodeID

The NodeID is a random string of 20 hex numbers that serves as a placeholder for now until in v20 when we change it with the actual nodeID we get when we install Platform using Dashmate or other. To generate the string issue the command below on any bash terminal, eg in Linux, MAC, or on the VPS.

Code:
head -c20 </dev/urandom|xxd -p

Record on your notepad this NodeID.


Step 5. Configure the VPS server.

Ideally use the Dash Mastenode Zeus to configure the server with no fuss and no delay. https://www.dash.org/forum/index.php?threads/dash-masternode-zeus-replacement-for-dashman.51618/ When prompted be sure to enter your BLS secret key that you generated earlier! During this step also record the IP address of the server in notepad.

Step 6. Create the protx invocation


The protx command you will need is protx register_prepare_hpmn

protx.PNG



eg

Code:
protx register_prepare_hpmn <collateralHash> <collateralIndex> <IP>:9999 <Owner> <BLS Pub key> <voting> 0 <payout> <nodeID> 26656 443 <Funding address>

Drop the above into the Dash wallet console and what comes back you need to copy out and sign with the address in your Trezor, or sign with the address in the core wallet if your funds are there, eg signmessage <collat address> <text> Once this is done, in the core wallet, you can submit the protx, eg, protx register_submit <TX> <Sig>

By this stage you are essentially done! Once the VPS is completely synced your node will be providing service to the network and running correctly.


V20 upgrade

Once v20 arrives, your upgrade path will be to reinstall the dashd and all Platform services on the VPS using Dashmate or some other tool and then issue a protx update_service_hpmn .... which will allow you set the correct nodeID and change the IP in case you need to move to a more powerful VPS. We estimate the requirements on the VPS to be about 2x that for v19.


Happy Evo noding !
 
Anyone has any idea why Dashmate gives this problem during 'dashmate setup' on a new Ubuntu 20.04.6 LTS deployment ?

'Cannot read properties of undefined (reading 'ip')'

Evo Node is already registered through DMT. Using 'dashmate setup' with Mainnet - Evolution masternode (4000) - already registered Yes.
This error comes right after providing BLS priv key and NodeID to Dashmate.

Firewall setup iaw official server configuration guide for mainnet :

ufw allow ssh/tcp
ufw limit ssh/tcp
ufw allow 9999/tcp
ufw logging on
ufw enable

I feel like i am missing something obvious.

When i give command 'curl -w "\n" -s https://api.ipify.org' it does show the correct server external ip address, but Dashmate just does not seem to be able to fetch it / reach it on Mainnet mode during dashmate setup. I previously had also additional ip addresses on this server, but those are currently not activated in Ubuntu 20.04.6 LTS with this new deployment, so Dashmate should only see 1 ip address.

I created a Github Issue for this --> https://github.com/dashpay/platform/issues/1262

@strophy & @xkcd & @pshenmic : any thoughts ?

Also there is a whole bunch of warnings during dashmate installation (npm install -g dashmate), that may or may not be related to this (i suspect not) :

Knipsel.JPG



(i ran npm install -g [email protected] to update npm itself (which cleared the vulnerabilities), but the errors in yellow are something new to me (different from when i tested Dashmate on Testnet awhile back). I suspect this Github pull request is related to those yellow warnings somehow : https://github.com/dashpay/platform/pull/1245
 
Last edited:
Hey, I feel like IP address detection looks a bit broken, because last few times it have not filled me the ip address. I will look into that soon.

There is a new `0.24.17` dashmate version, it fixes your `cannot read properties` error

Yellow warnings are OK, it complains about your Node version. The project soon will be migrating on the Node v18 completely, so when you switch it to 18 you won't get this message.
 
Thank you pshenmic, after issuing a npm update -g dashmate command the dashmate setup would indeed let me enter my ip address.
So its all good now. I was really worried the problem was at my side (that i screwed something up), good to see it fixed today.
 
@pshenmic

I now have the problem that after a successfull sync, my ip adress can not be connected to by CActiveMasternodeManager according to core.log
CActiveMasternodeManager::Init -- ERROR: Could not connect to "myipaddress"
I suspect this is due to dashmate not binding my ip address in the dash.conf (which i can't change myself, as it is controlled by dashmate)
My current dashmate controlled dash.conf (with a lot of unnecessary spaces between commands, which i removed here) :


# general
daemon=0 # leave this set to 0 for Docker
logtimestamps=1
maxconnections=256
reindex=0

debuglogfile=/var/log/dash/core.log
logips=0

# JSONRPC
server=1
rpcuser=*******
rpcpassword=*********
rpcwallet=main

rpcallowip=127.0.0.1
rpcallowip=172.16.0.0/12
rpcallowip=192.168.0.0/16

rpcworkqueue=64
rpcthreads=16

# external network
listen=1
dnsseed=0
allowprivatenet=0

externalip=********

# ZeroMQ notifications
zmqpubrawtx=tcp://0.0.0.0:29998
zmqpubrawtxlock=tcp://0.0.0.0:29998
zmqpubrawblock=tcp://0.0.0.0:29998
zmqpubhashblock=tcp://0.0.0.0:29998
zmqpubrawchainlocksig=tcp://0.0.0.0:29998
zmqpubrawchainlock=tcp://0.0.0.0:29998
zmqpubrawtxlocksig=tcp://0.0.0.0:29998

masternodeblsprivkey=**********

# network
port=9999
bind=0.0.0.0
rpcbind=0.0.0.0
rpcport=9998

I created a new Github issue for this : https://github.com/dashpay/platform/issues/1266

core.log shows the following by the way :

2023-07-27T05:47:49Z Using data directory /home/dash/.dashcore
2023-07-27T05:47:49Z Config file: /home/dash/.dashcore/dash.conf
2023-07-27T05:47:49Z Config file arg: allowprivatenet="0"
2023-07-27T05:47:49Z Config file arg: bind="0.0.0.0"
2023-07-27T05:47:49Z Config file arg: daemon="0"
2023-07-27T05:47:49Z Config file arg: debuglogfile="/var/log/dash/core.log"
2023-07-27T05:47:49Z Config file arg: dnsseed="0"
2023-07-27T05:47:49Z Config file arg: externalip="********"
2023-07-27T05:47:49Z Config file arg: listen="1"
2023-07-27T05:47:49Z Config file arg: logips="0"
2023-07-27T05:47:49Z Config file arg: logtimestamps="1"
2023-07-27T05:47:49Z Config file arg: masternodeblsprivkey=****
2023-07-27T05:47:49Z Config file arg: maxconnections="256"
2023-07-27T05:47:49Z Config file arg: port="9999"
2023-07-27T05:47:49Z Config file arg: reindex="0"
2023-07-27T05:47:49Z Config file arg: rpcallowip="127.0.0.1"
2023-07-27T05:47:49Z Config file arg: rpcallowip="172.16.0.0/12"
2023-07-27T05:47:49Z Config file arg: rpcallowip="192.168.0.0/16"
2023-07-27T05:47:49Z Config file arg: rpcbind=****
2023-07-27T05:47:49Z Config file arg: rpcpassword=****
2023-07-27T05:47:49Z Config file arg: rpcport="9998"
2023-07-27T05:47:49Z Config file arg: rpcthreads="16"
2023-07-27T05:47:49Z Config file arg: rpcuser=****
2023-07-27T05:47:49Z Config file arg: rpcworkqueue="64"
2023-07-27T05:47:49Z Config file arg: server="1"
2023-07-27T05:47:49Z Config file arg: zmqpubhashblock="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Config file arg: zmqpubrawblock="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Config file arg: zmqpubrawchainlock="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Config file arg: zmqpubrawchainlocksig="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Config file arg: zmqpubrawtx="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Config file arg: zmqpubrawtxlock="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Config file arg: zmqpubrawtxlocksig="tcp://0.0.0.0:29998"
2023-07-27T05:47:49Z Using at most 256 automatic connections (1048576 file descriptors available)
2023-07-27T05:47:49Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2023-07-27T05:47:49Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2023-07-27T05:47:49Z Script verification uses 7 additional threads
2023-07-27T05:48:12Z CActiveMasternodeManager::Init -- ERROR: Could not connect to *******
 
Last edited:
I have not seen this error before, what are you trying to do? Provide more information how to reproduce it. What type of node are you running and what exactly is not working? Does it fail to sync?

Bind is correct, because dashd is running inside the container, so it should be 0.0.0.0.
 
I have not seen this error before, what are you trying to do? Provide more information how to reproduce it. What type of node are you running and what exactly is not working? Does it fail to sync?

Bind is correct, because dashd is running inside the container, so it should be 0.0.0.0.

I am trying to get my Evo Node up and running, it now hits that error.
This happens after sync. Also quorum initializations are starting to fail now.
 
Last edited:
I don't quite get it still, what do you mean my evo node up an running? There is no evo in the mainnet, it will only run core in this mode
 
I don't quite get it still, what do you mean my evo node up an running? There is no evo in the mainnet, it will only run core in this mode
There are currently some 30 Evo Nodes active on Dash Mainnet, connected to L1. This became possible after Dash Core v19 sucessfully activated.
After Platform get released (Dash Core v20) those Evo Nodes need to update, so they can connect to both L1 (Dash network) and L2 (Platform).
Evo Nodes currently receive 4x mn rewards through Dash Core v19. After Dash Core v20 activation the masternode reward logic changes for Evo Nodes.

My problem was actually due to ufw getting disabled (most likely after a reboot), eventhough i enabled it before on root and this should protect it against reboots.

sudo ufw status : disabled

in root :

ufw allow ssh/tcp ---> already running
ufw limit ssh/tcp ---> already running
ufw allow 9999/tcp --> existing rule
ufw logging on --> Could not update running firewall
ufw enable --> Firewall is active and enabled on system startup

This happened to me before on a previous Ubuntu system, which i fixed in etc/rc.local (just added 'ufw enable' there) but this can't be done in Ubuntu 20.04.6 LTS that easily it seems, as rc.local is not supported there anymore.

I guess i will need to check if ufw is still enabled after each reboot.
No more errors now in core.log (old debug.log). Evo Node now running stable.

Anyone have any tips to keep ufw firewall more firmly enabled on Ubuntu 20.04.6 LTS, even after reboots ?
Update : https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd
 
Last edited:
I strongly suggest to setup with Dash Masternode Zeus and follow the guide in post #1, DashMate is not ready for prime time and not even required for a v19 evonode at all.
 
I agree that Dashmate is not as stable as devs assured me awhile back on one of the Dash Platform and Core Development updates, where they started to discuss Dashmate with more details. For example Dashmate ip address detection issue during setup should not have emerged this late in the game with Evo Nodes already on Mainnet, same for Dashmate's 'reindex reworked' getting merged relatively late (after Evo Nodes were already on Mainnet).

With Evo Nodes already running on Mainnet there should be a clear focus and priority on fixing Dashmate bugs that threaten the Dashmate stability. There are still a lot of issues open related to Dashmate --> https://github.com/dashpay/platform/issues
How far any of those relate to the stability with regards to setting up and mainting Evo Nodes through Dashmate, i don't know.

Bugs that were reported by me earlier on this Dash forum and still linger in Dashmate (0.24.18) :

* when using PUTTY with its default small window, the output of 'dashmate status & dashmate status xxx' commands get misaligned often (scaling issue most likely, when using a maximized PUTTY window the problem disappears).

Knipsel.JPG

* Incorrect return of PoSe Penalty (we do need the actual PoSE score in 'dashmate status' as well, not just in 'dashmate status masternode'), and when an Evo Node has just been newly started the following is incorrect : Last paid time incorrect, Payment queue position incorrect, Next payment time incorrect. I rather have those on n/a untill it gets paid for the first time, instead of providing misleading information to MNO's (particularly the Next payment time). It does make me wonder why DMT and the Dash Core wallet can fetch Next payment correctly from the start (newly setup) and Dashmate can't.....

Knipsel.JPG



I do find the simplicity of Dashmate and how it maintains itself through Docker nice to work with, and prefer to use it over manual installation or other ways of setting up an Evo Node. But Dashmate has to work reliably from the start now Evo Nodes are already on Mainnet (L1), and i suspect Dashmate will mainly be used to setting them up and maintaining them. Current number of Evo Nodes on Mainnet : 43
 
Last edited:
  • Like
Reactions: daf
@qwizzie

Sorry, that this happened, I have prepared UI fixes for the things you mentioned, and added a task for a small terminal sizes https://github.com/dashpay/platform/issues/1273
I have already prepared all the code, I will release a new build very soon.

But honestly, if we look at the things more precisely, we can see that all these are UI issues or just typos. I can't agree with you that dashmate is not production ready.
Dashmate already has been proven by months of production in the dash networks (mainnet, testnet, devnets) deployed by dash-network-deploy tool. And personally by me in the platform explorer project, it just works without any issues for weeks. The only thing I rarely do is to update and restart the node if needed.

Regarding IP address detection, I have improved overall stability of detection algorithm, but there are few cases where it will not be detected and filled automatically.
For example, if you are setting up your dashmate masternode with DMT, you already have your node registered in the DMT, so you only need to paste the actual values from the DMT. In this case, the field will be empty

Also, I could not reproduce your issue with last paid time, I even deployed a test masternode in the testnet myself, but after getting READY status, I can see that both fields last block time and last paid time were null. Do you know how can I reproduce it?

Not sure what you mean by mentioning `reindex reworked`, the feature of reindexing your core node have been there in the dashmate already for quite time. I developed it a year ago, but recently improved the workflow of this command to enable this feature in the different components of the platform. It is now possible to use it in the backend systems as well, you can pass a flag to the command and it will be executed in the non-blocking way so you can request it via API.

There are still a lot of issues open related to Dashmate --> https://github.com/dashpay/platform/issues
Those are not issues but rather tasks to track. We are tracking features and issues in the github to make sure we won't forget about it.

I admit there could be issues that we are not aware.
This is basically because developers doesn't really use this tool personally in all the ways. I usually run local networks, fullnodes, but I don't have masternodes so I don't know if there any more issues.
Would be good if anyone could help me. If we start each using separate dashmate features, we will have stable workflows at least for a basic stuff.
For example, I am using dashmate testnet evo fullnode in the platform-explorer project so I can ensure you that this flow is working, if there will be any other people who can also run mainnet masternode, mainnet evonode and so on, together we will stabilize the dashmate by resolving individual issues in the each cases. What do you think?

Probably we should make a separate thread for dashmate discussion :) :)


PS
I wanted to deploy changes and reply to you almost in the same day, but the weekend happened, and I could not make it fast because of the necessary approvals.
I will try to improve this process, I hope I will be able to make alpha releases myself, so I can give it out faster to the community
(y)(y)
 
@qwizzie

Sorry, that this happened, I have prepared UI fixes for the things you mentioned, and added a task for a small terminal sizes https://github.com/dashpay/platform/issues/1273
I have already prepared all the code, I will release a new build very soon.

But honestly, if we look at the things more precisely, we can see that all these are UI issues or just typos. I can't agree with you that dashmate is not production ready.
Dashmate already has been proven by months of production in the dash networks (mainnet, testnet, devnets) deployed by dash-network-deploy tool. And personally by me in the platform explorer project, it just works without any issues for weeks. The only thing I rarely do is to update and restart the node if needed.

Regarding IP address detection, I have improved overall stability of detection algorithm, but there are few cases where it will not be detected and filled automatically.
For example, if you are setting up your dashmate masternode with DMT, you already have your node registered in the DMT, so you only need to paste the actual values from the DMT. In this case, the field will be empty

Also, I could not reproduce your issue with last paid time, I even deployed a test masternode in the testnet myself, but after getting READY status, I can see that both fields last block time and last paid time were null. Do you know how can I reproduce it?

Not sure what you mean by mentioning `reindex reworked`, the feature of reindexing your core node have been there in the dashmate already for quite time. I developed it a year ago, but recently improved the workflow of this command to enable this feature in the different components of the platform. It is now possible to use it in the backend systems as well, you can pass a flag to the command and it will be executed in the non-blocking way so you can request it via API.
It is fine if IP address detection is not always detecting our ip address and we need to fill it in. But that part at some point did not work either and only got fixed a week ago (the 'cannot read properties fix'). That was a bug that prevented those Evonode owners that already registered on DMT from completing the dashmate setup process. Not exactly an UI issue or a typo.

The Reindex Reworked arrived from this issue --> https://github.com/dashpay/platform/issues/788 (Feb 2023 !!) which in the end linked to pull request https://github.com/dashpay/platform/pull/1212 (29th of June 2023). The orginal issue states :

Expected behavior

Reindex command should not change the config and ask user for additional command executions. Instead, command arguments should be used to turn local dashcore container into reindex mode. You don't actually need to edit any dashmate or dashcore configs.

Current Behavior

Reindex command actually changes dashmate config and re-renders all the configs.

So also not exactly an UI issue or a typo, and something that got me some trouble on Testnet before. Reindex would just not start on my Evo node on Testnet. It would also not let me out of the (failing) reindex process either (if i remember correctly). I think it was connected somehow with above mentioned issue. I was just surprised such an issue with Dashmate reindex would take so long to fix. I just hope the Dashmate reindex command works as intended now on Mainnet (have not tested it yet).

With regards to my issue with Last Paid time : Last Paid time is not yet fixed on dashmate status. It shows 3487.71 days instead of Never. It has indeed been fixed for dashmate status masternode (different command). Last paid block looks fine on both commands.

See : https://www.dash.org/forum/index.php?threads/v19-3-0-release-announcement.53942/#post-235605

Knipsel.JPG


It is indeed better that i create a new thread next time on dash.org/forum for issues with Dashmate on Mainnet.
Something similiar to this one : https://www.dash.org/forum/index.php?threads/platform-v0-24-with-dashmate-on-testnet-issues.53721/ but then for Mainnet.

It is also good to read you are thinking about getting some help with Dashmate, i was actually thinking the same thing now Dashmate is being used actively by MNO's to setup Evonodes .. that maybe you should have some help. But i was thinking more about you getting some help from another dev, maybe sub-delegate some dashmate work to another dev ? That is something you could discuss with DCG, to see if they are open to it. Then maybe open a job on the Dash Incubator for it ? Or maybe one of DCG devs do not mind helping you out here longterm ?

I am looking forward to the release of Dashmate v0.24.20 and appreciate the fixes.
 
Last edited:
So also not exactly an UI issue or a typo, and something that got me some trouble on Testnet before. Reindex would just not start on my Evo node on Testnet. It would also not let me out of the (failing) reindex process either. In the end i had to destroy and rebuild my test server. I think it was connected somehow with above mentioned issue. I was just surprised such an issue with Dashmate reindex would take so long to fix. I just hope the Dashmate reindex command works as intended now (have not tested it yet).
I think you mistook the task description. It was about process improvement, not about any bug reported or existed. I personally checked the command before starting the work and it was working on my local and in the devnet. I don't know what the happened in your case, but it should be safe to interrupt reindex command in any case. By the way, I found the original reindex feature issue https://github.com/dashpay/platform/issues/103

Cannot read properties was a clearly typo in the migrations file. I am going to prevent that dumb thing, by writing few e2e tests that will ensure basic flows are working on the CI before publishing https://github.com/dashpay/platform/issues/1275

With regards to my issue with Last Paid time : Last Paid time is not yet fixed on dashmate status. It shows 3487.71 days instead of Never. It has indeed been fixed for dashmate status masternode (different command). Last paid block looks fine on both commands.
I just checked master branch, and I could not reproduce it. I have created a fresh masternode in the testnet, then I set up my dashmate and was able to see all the fields correctly. Could it be the case when you are reviving or migrating existent masternode to the dashmate?


Screenshot 2023-08-03 at 12.54.36.png
Screenshot 2023-08-03 at 12.54.45.png


I have created a dashmate discussion thread, you may post your questions there
 
Actually, are the “target specs for HPMNs” (“high performance 4K”), mentioned here, still valid?
 
Actually, are the “target specs for HPMNs” (“high performance 4K”), mentioned here, still valid?

Mostly, but I think 8GB RAM will be enough for a DMZ install, if using DashMate, 16GB might be required.
 
  • Like
Reactions: daf
Hello Dashers!

The first post on this thread remains the best way to create a new 4,000 Dash so called Evonode in 2024 and now there is a page that auto-generates that nodeID for you, so you don't have to use a random string.


From this page, scroll down and copy the JSON text, the first ID is the nodeID used in the protx setup, however, keep the whole chunk as it will be used later when you set up your platform services. If you do the set up this way, you won't need to issue that protx update_service because the masternode will be correctly configured from the very start!

Hint: Just save the JSON in a text file somewhere in your .dashcore directory so you can come back to it later when you need to fetch the node_key for tenderdash.
 
Back
Top