I’ve followed the documentation as best as possible and I have a fully synced node on the mainnet, a partkey and an online transaction to register the key. I do not see the “VoteBroadcast” message in my node.log log file, so it seems that my node is not in the consensus. I don’t know what else to do.
My node is running Ubuntu 18.04, 2.2.0.stable.
Here is a summary of the commands I ran:
./goal wallet new
./goal account new
./goal account addpartkey -a DOLFW77QNYVZOKKIPNDMU2JRDQK7QQ7BJKMYH4JW22C6UTTVB35XDI74GM --roundFirstValid=10182256 --roundLastValid=20182256
./goal account partkeyinfo
./goal node generatetoken
Installed the python sdk
Cobbled together a python script from examples to register the key.
** See transaction B2JGUQ4GM7V7GPKOQYA5SVBDEDLLLDOWEQANDLQ3HUZFQFGXUSPQ
Unless I’m missing something, your node is all set up to vote on the consensus.
Keep in mind that the chances to vote directly derived from the amount of Algos your account has compared to the total amount of online stake.
According to algoexplorer, the online accounts total is 2,206,501,543.49, whereas your account has 23.010417. The chances for your node to be chosen to vote/propose are pretty slim… but it’s still there.
As @tsachi mentioned, with such a small amount the odds are like a lottery with a 1 in 2.2 billion chance - and you play 23 times. If you grep your log for VoteBroadcast, this is one indicator your node is broadcasting its vote for a VRF lottery it ‘won’.
ie:
grep VoteBroadcast $ALGORAND_DATA/node.log
Something like this might let you get a semi-persistent ‘watch’ on it:
Thanks @tsachi and @aojjazz, this helps me understand much better.
The ‘grep VoteBroadcast’ was from the documentation tutorial on how to join the consensus. It wasn’t clear to me that it only showed up in the log file when you ‘won the lottery’.
Also, it seems that the Python API is undergoing some significant changes right now. There is a ‘.future’ name space that looks like it will replace many objects. This difference in tutorial descriptions and examples in the Python SDK github made joining the consensus difficult since I couldn’t find a single example that did exactly what I wanted (the key register transaction). Although I guess I figured it out in the end.
Well, to add some nuance - the VoteBroadcast is just showing that your participation key matched on the VRF and is broadcasting that vote.
It doesn’t mean the other nodes will ‘care’ or whether or not your vote will ‘truly’ count if you know what I mean. By the time your vote arrives, the required vote thresholds may have already been reached by other votes all arriving in parallel. Any given node will often see different votes in different orders depending on proximity. The key is there still has to be enough votes to reach a particular threshold for the soft vote round and the certification vote round.
run carpenter against your data directory and you’ll see it visualize the logging data.
ie: a snippet:
The X/Y numbers are the weight of the vote and the current new ‘total’. The threshold for round 1 is 2267 - the threshold for round 2 is 1112.
The local node will consider the block valid assuming the votes it saw have enough stake to meet this critiera. The exact votes and order received from node to node can vary.
So… your small stake may actually ‘vote’ but the other nodes likely won’t care since they’ll likely have already seen votes from very high-stake nodes that caused them to meet their thresholds - at which point they ignore all subsequent votes.
