Default value for MAX_HASH_COMPUTATION should be higher.

[Gr33nDrag0n69]

In current Lisk-Core v4.x, the hash onions are generated when a validator is configured on a lisk-core server. The maximum count is limited (For CPU & Memory consideration) to 10 000. (With current default value) Each time a validator generate a block, 1 hash is "used". At 84 blocks per day (average), it means after 119 days the hash pool will be depleted. Once the pool is depleted, you will still generate blocks but the reward will be lost.

MAX_HASH_COMPUTATION = 10000;

https://github.com/LiskHQ/lisk-sdk/blob/v6.0.1/framework/src/modules/random/constants.ts#L21C38-L21C42

This value should be higher. I think 200K would cover 5-6 years.

2 extra questions:

• Why/How the 10000 value was chosen.
• What is the outcome of patching to 200000 on production servers.

[Gr33nDrag0n69]

More infos here https://github.com/Gr33nDrag0n69/LiskCore4Tools/blob/main/MD/Core4_NpmInstall_MaxHashComputation_Patch.md

[Gr33nDrag0n69]

I updated the previous MD file with an example.

I found 1 thing worth mentioning.

Using the hash-onion method generate 1M by DEFAULT, it's inconsistent with lisk-sdk default of 10K

Also it look like it was just not well communicated.

Here an example i wrote:

https://github.com/Gr33nDrag0n69/LiskCore4Tools/blob/main/MD/Core4_NpmInstall_MaxHashComputation_Patch.md#how-official-undocumented-method

[shuse2]

@Gr33nDrag0n69 it looks good! We will update the documentation

10,000 hashes is the limit on the endpoint because it blocks the node too long for the req/res type of execution. For the production, the way you described should work good =)