RE: Privex Hive Node-in-a-Box Experience
You are viewing a single comment's thread:
At this rate the node is syncing up 10k blocks every 25 minutes or something
That is nightmarishly low number. On my development machine (while I was also working on it), the last full sync I've run (middle of February 2023, so up to block 72'230'000) was taking less than 1.9 ms per block. Newer blocks are even faster (they are either smaller than average or more packed with light operations like custom jsons).
I'm seeing that gtg and ausbitbank are running code that allows users to post data to chain even if the account in question doesn't necessarily have enough resource credits.
There were (way) more of such messages, but I've silenced them all up to HF26 (and I might move that even further once we are close to HF28), since they were just spam at this point. Those are results of turbulent times when RC was just introduced, old bugs, disagreements between witnesses running different minor versions of the code, or sometimes deliberate breaches of "soft consensus". The ones you've quoted are from the fact that your node is older than what @gtg and others are running. Last change removed the ability of account to go negative as a preparation for RC to become consensus. Since the change was retroactive (as all RC changes - no point in doing it differently yet), node of gtg thinks the account in question has more RC, because it never run into negative, while the node you are running still allowed it to dip into up to two hours worth of regen below line. Once your node is updated and replayed, the last "Accepting" message you will see will be from block 72'779'954. All those messages were diagnosed by the way.
Guess I'll have to figure that out along with what the account_subsidy_budget and account_subsidy_decay are.
Of all five RC pools witnesses are in control of subsidized account token pool - the one that contains "free account tokens" to be claimed for mountain of excess RC. The values you have are default ones and they were never changed. It is best to leave them as is :o) The only subsidy I can think of for Hive accounts are resource credits for accounts that have very low or zero HP You are thinking about
/**
* How many free accounts should be created per elected witness block.
* Scaled so that HIVE_ACCOUNT_SUBSIDY_PRECISION represents one account.
*/
int32_t account_subsidy_budget = HIVE_DEFAULT_ACCOUNT_SUBSIDY_BUDGET;
/**
* What fraction of the "stockpiled" free accounts "expire" per elected witness block.
* Scaled so that 1 << HIVE_RD_DECAY_DENOM_SHIFT represents 100% of accounts
* expiring.
*/
uint32_t account_subsidy_decay = HIVE_DEFAULT_ACCOUNT_SUBSIDY_DECAY;
share_type rc_adjustment; ///< compensation for account creation fee in form of extra RC
. All accounts have that, not just those with low HP (although it is only relatively significant for them).
Do you happen to know of an efficient way to run a node solely for transaction checking, without the need for signing or generating new blocks?
I vaguely recall hearing about a "light node."
Currently I use for testing purposes public nodes. (https://beacon.peakd.com/)
However, I was thinking it might be beneficial to run my own node to avoid consuming unnecessary resources from public nodes. This way, I could directly make API calls to my own node and experiment a little.
As for my current approach, it would be like to what edicted described in the post, but with a slight difference. I wouldn't configure the config file. I'd leave the witness and the public/private key lines commented out.
Running empty consensus node is very easy - once you have the binaries just
./hived -d .
and it will start syncing, even withoutconfig.ini
. You could actually start the node like that for a second to build default config, stop the node, add or remove plugins from the configuration, change paths to more convenient blockchain storage location, redirect logging and start it again from zero. The node will work by itself. This is enough for checking consensus and for using the node for communication withcli_wallet
. If you have trusted source of snapshot or block log, you can greatly speed up process of node reaching live mode.The problem is in the details. You've mentioned that you want to use APIs. Depending on which APIs you need, you might actually need not just the node but also Hivemind, and since it is now a HAF application, you might need HAF as well. Some APIs are still available from the node itself (at least partially) if you enable proper plugins. I have personally never set up and run full HAF node locally, so I can't help you with that.
wow! thanks alot, this information is so valuable for me.