Halving implementation in PRIZM

Hi people ! ✋🏻😎

In general, this article was planned to be published on Habré, focusing on the appropriate audience. People there are mostly IT-oriented, and for their understanding, pieces of code are shown with a description of the ongoing processes, and links to the source are given.

I tried several times to describe the same thing only in words, somewhere in more detail, somewhere not very much, and it’s good that I did this, because in the course of editing I found my mistakes that needed to be corrected in the original version.

After some time, I remembered the beginning of one song, I changed it a little:

a few days ago I wrote this article, but with the Habr's pace of moderation, I got tiref redoing the texts, so let everything in this article remain as it was

In the end, if something is not clear to someone, you can always clarify it in chats 😉

Have you heard about Halving?

Immediately I ask those to whom many things seem excessively obvious, do not throw stones too much 🙏

This material will be used in conjunction with other material as one of the elements of teaching beginners, including those who are not at all familiar with programming languages, so the article may not seem complete. Sorry 🙏 if your eyes start to cut

When a cryptocurrency halving occurs, the community expects a decrease in the future number of generated coins, and, accordingly, a potential reduction in the supply of these coins in the markets, hence an increase in market value.

In essence, Halving is the software creation of a cryptocurrency shortage. For a limited emission cryptocurrency, this event significantly affects the further operation of the entire network. We will just consider two such cryptocurrencies, or rather, how Halving is implemented in them.

In a global sense, Halving is necessary to control inflation of the total number of coins issued, and this is a very important component and an integral part of the economic model of many cryptocurrencies, and, of course, Prizm has its own Halving - is PARATAX. But let's start with Bitcoin

Bitcoin

In the Bitcoin blockchain, the implementation of Halving exactly corresponds to the meaning of the word - after 210,000 blocks (approximately 4 years), the maximum possible reward for miners per block becomes 50% less:

50 btc -> 25 btc -> 12.5 btc -> 6.25 btc -> 3.125 btc.. and so on

The calculation takes place according to the height of the current block, it is divided by the interval (nSubsidvHalvingInterval) set to 210,000

The determination of the possible number of coins generated is described in the GetBlockSubsidy() method

If the result of the division (halvings) is greater than or equal to 64, then the reward will be zero, that is, when the height of the current block reaches
64 × 210 000, miners will stop generating new bitcoins and will continue to collect only commissions from transactions

Given the fact that the Bitcoin blockchain tends to an interval of 10 minutes between the generation of blocks, the moment of mining the last bitcoin is likely to be observed by our great-grandchildren

After checking halvings, the number of coins is calculated, which the miner will later use to generate them. This is done by bitwise shifting to the right

nSubsidy >>= halvings;

Since the division result is written to an integer variable (int halvings), the fractional part of the result is simply discarded and the bitwise shift always occurs by an integer number of digits. And shifting to the right by one digit of the binary representation of a positive number is actually dividing this number by 2

PRIZM

PARATAX was introduced gradually and its first element was put into operation at the hight of 571800 with the advent of the PrizmCore version1.9.19 (09.08.2019). PrizmCore owners immediately had a window in the interface displaying 3.73%, which corresponded to the percentage of the current emission from the maximum.

From that moment on, the Paramining for each account, at the time of its generation, became less by the value of this percentage, but only the integer value of the percentage is involved in the calculation, its fractional part is discarded, as in the case of Bitcoin, for the same reasons - the result is assigned to an integer variable.

Since the emission of new coins in PRIZM is not the prerogative of forgсers, but a dynamic and individual value, for almost every coin owner, then the implementation of Halving by developers was made taking into account the individual characteristics of each account

After the appearance of PrizmCore version 1.10.3, at the height of 888888 (02.19.2020), the percentage of the current issue in the calculations of the number of coins generated increases by 2 times.

PARATAX began to look more like Halving, and Paramining began to be calculated by a compound percentage. But not everything is so literal, let's figure it out.

constants used:

the method that sets PARATAX:

How many coins are generated ?

As already mentioned, PRIZM has dynamic and individual generation of new coins. This means that for each account to whom coins should be generated now, first need to calculate an individual PARATAX

The order of calculations:

1. Calculate Paramining taking into account the usual PARATAX

Step 1. Call the method that sets PARATAX. Passing height = 0 to the method

Since 0 is less than 888888, PARATAX is set as a simple percentage of the current issue, but only a whole part of it.

Step 2. Next, we call the calculateOrdinaryInterest() method, where the number of coins is calculated taking into account the number of 86400 seconds (days) that have passed, reduced by the percentage of PARATAX set in the previous step

1. Step 3. The result is assigned to the ordinaryPayout variable
2. Calculate the Paramining by a compound percentage, taking into account the double PARATAX

Step 1. Call the method that sets PARATAX. Passing height = 888888 to the method, PARATAX is set depending on the Hold status of the account for which the calculation is being performed and adjusted by 97% or 98%, respectively, if the result of multiplying the usual PARATAX by 2 exceeds these constants.

This place hides the reason for such phenomena, which in the community were called as "jumps" PARATAX

Step 2. Call the calculateCompoundInterestInternal() method, where the number of coins is calculated taking into account the number of periods of 50 seconds over the elapsed time, reduced by the percentage of PARATAX that is already set to double and adjusted.

a small digression about "jumps":

When the current emission increases by 1%, the getParataxPercent() method returns the percentage of the current emission without a fractional part.

For example, the current emission = 1 234 567 891 pzm
1 234 567 891 * 100 / 6 000 000 000 = 20,5761315167 %
The return value will be = 20
Next, the returned value is multiplied by 2, in our example long percent = 40

That is, with the usual Paramining = 100 pzm, the result of the calculations will be: 100 - 40% = 60 pzm (6000 indivisible kopecks)

When the current emission reaches 21%, the value 42 will be assigned to the variable percent
Accordingly, the result will be:
100 - 42% = 58 pzm

The difference is not very noticeable. But the higher the current emission, the more the difference is felt

Let's look at the latest "jumps":

The current emission will reach 46%
The value 92 is assigned to the variable percent
Result: 100 - 92% = 8 pzm

The current emission will reach 47%
The value 94 is assigned to the variable percent
Result: 100 - 94% = 6 pzm

The difference between 8 and 6 = 25%, that is, the Paramining for each account was recalculated by 25% downwards

The current emission will reach 48%
The value 96 is assigned to the variable percent
Result: 100 - 96% = 4 pzm
The difference between 6 and 4 = 33.3(3)%, that is, the Paramining for each account was miscalculated by 33% downwards

The current emission will reach 49%
The percent variable is assigned the value 98
Result: 100 - 98% = 2 pzm
The difference between 4 and 2 = 50%, that is, the Paramining for each account was recalculated by 50% downwards.
Well, just some kind of Halving 😁

It follows from this that when the current emission reaches 50%, the value 100 will be assigned to the variable percent

Calmly ✋, everything is fine, Paramining will not disappear, the constant 98% comes into play

When the current emission reaches 50%, the double PARATAX, taken into account after calculating the Pertaining by a compound percentage, will remain the same, changes will only be within the Hold status. But the normal PARATAX will continue to increase following the emission

But both Paramining will still depend on the current emission, more on this in the article below

And so, back to our order

1. ordinaryPayout
2. Step 3. The result is assigned to the compoundPayout variable
3. The two results obtained are compared and the one that is smaller is always selected:

This place hides the reason for such a phenomenon, which the community called the "red zone"

"red zone"

The fact is that in the official web tool of the ParaMining calculator from the developers of PRIZM (there is a link to GitHub prizm.space), the very place, the very day and all the days following it, where the Paramining calculated by a compound percentage with double PARATAX begins to exceed the usual Paramining with a simple PARATAX, are colored red

Also in the official web TOOL visualizer from the developers of PRIZM, the scale on which the arrow moves displaying the current account's Paramining is decorated in a rainbow gradient. This creates a visual effect of the Paramining speed dial. And the part where this speed becomes maximum is colored red

Back to order

1. ordinaryPayout
2. compoundPayout
3. if (ordinaryPayout < compoundPayout)
4. After choosing the smaller of the two calculations, the number of coins decreases once again 😱 in decreaseAmountByGenesis() method

The selected smallest number of coins is reduced by the coefficient of the remaining issue. The coefficient never exceeds one (1), 1 is 100% of the emission.

For example:
If the current emission = 49%, then the coefficient = 1 - 0.49 = 0.51

But in this case, the fractional part is taken into account in the value of the current emission, so for example:
If the current emission = 49.56%, then the coefficient = 1 - 0.4956 = 0.5044

Thus, the number of coins is multiplied by the resulting coefficient and here, as a result, only an integer (long) value remains, the fractional part is discarded, that is, the result of multiplication is rounded down (to whom it is more convenient to understand)

More examples:
When the current emission reaches 55%, the coefficient will be = 1 - 0.55
The number of coins will be multiplied by 0.45

When the current emission reaches 61.234%, the coefficient will be =
1 - 0.61234. The number of coins will be multiplied by 0.38766

Well, I think how the coefficient of the remaining emission is calculated should be extremely clear. But it is not at all obvious that the very "jumps" mentioned above are also diluted by changing the whole value of the result, after multiplying the calculated dynamic coefficient of the remaining emission by the selected smallest number of coins. That is, the total amount of coins generated changes dynamically within the same percentage of PARATAX.

About "jumps" in more detail:

Let's walk through the same examples with emissions again, but now we will take into account the extreme, threshold values of the current emission and the coefficient of its remainder. To do this, we will need to increase our conditional normal Paramining, because 100 pzm for example already seems to be too small a value 🙂

So, let's imagine that the usual Paramining without taking into account PARATAX for some period of time was 1000 pzm, then if:

The current emission will reach 46.99%
PARATAX multiplied by 2 = 92
1000 - 92% = 80 (8000 indivisible kopecks)
Coefficient = 1 - 0.4699 = 0.5301
8000 * 0.5301 = 4240 indivisible kopecks
Generated coins = 42.4 pzm

The current emission will reach 47%
PARATAX multiplied by 2 = 94
1000 - 94% = 60
Coefficient = 1 - 0,47 = 0,53
6000 * 0,53 = 3180
Generated coins = 31,8 pzm
The difference between 42.4 pzm and 31,8 pzm = 25 %

The current emission will reach 47.99%
PARATAX times 2 = 94
1000 - 94% = 60
Coefficient = 1 - 0.4799 = 0.5201
6000 * 0.5201 = 3120
Generated coins = 31.2 pzm

The current emission will reach 48%
PARATAX multiplied by 2 = 96
1000 - 96% = 40
Coefficient = 1 - 0,48 = 0,52
4000 * 0,52 = 2080
Generated coins = 20,8 pzm
The difference between 31,2 pzm and 20,8 pzm = 33,3(3) %

The current emission will reach 48,99%
PARATAX multiplied by 2 = 96
1000 - 96% = 40
Coefficient = 1 - 0,4899 = 0,5101
4000 * 0,5101 = 2040
Generated coins = 20,4 pzm

The current emission will reach 49%
PARATAX multiplied by 2 from now on, always = 98 (97 if there is a Hold status)
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,49 = 0,51
2000 * 0,51 = 1020
3000 * 0,51 = 1530 (Hold status)
Generated coins = 10,2 pzm or 15,3 pzm
The difference between 20,4 pzm и 10,2 pzm = 50 %
The difference between20,4 pzm и 15,3 pzm = 25 % (Hold status)

The current emission will reach 49,99%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,4999 = 0,5001
2000 * 0,5001 = 1000
3000 * 0,5001 = 1500 (Hold status)
Generated coins = 10 pzm or 15 pzm

The current emission will reach 50%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,5 = 0,5
2000 * 0,5 = 1000
3000 * 0,5 = 1500 (Hold status)
Generated coins = 10 pzm or 15 pzm

There is no difference, that is, there will be no "jump" on the 3 billion emission !

It follows from this that a further increase in the emission will dynamically smoothly adjust the number of coins generated.

The current emission will reach 50,99%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,5099 = 0,4901
2000 * 0,4901 = 980
3000 * 0,4901 = 1470 (Hold status)
Generated coins = 9,8 pzm or 14,7 pzm

The current emission will reach 51%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,51 = 0,49
2000 * 0,49 = 980
3000 * 0,49 = 1470 (Hold status)
Generated coins = 9,8 pzm or 14,7 pzm
There is no difference

The current emission will reach 51,99%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,5199 = 0,4801
2000 * 0,4801 = 960
3000 * 0,4801 = 1440 (Hold status)
Generated coins = 9,6 pzm or 14,4 pzm

The current emission will reach 52%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,52 = 0,48
2000 * 0,48 = 960
3000 * 0,48 = 1440 (Hold status)
Generated coins = 9,6 pzm or 14,4 pzm
There is no difference

I hope these gradual steps more clearly outline the situation with "jumps" and the generation of coins in general.

If I was not mistaken and no one drilled a hole in my calculator, it turns out that we will gradually reach these values:

more precisely, not us, but ..
have you already wondered whose great-grandchildren will live up to this time?

The current emission will reach 98,99%
1000 - 98% = 20
1000 - 97% = 30 (Hold status)
Coefficient = 1 - 0,9899 = 0,0101
2000 * 0,0101 = 20
3000 * 0,0101 = 30 (Hold status)
Generated coins = 0,2 pzm or 0,3 pzm

You can help your great-grandchildren calculate further conditional generation, but then you will need to take even more conventional Paramining as a basis without taking into account PARATAX. Less than 0.01 pzm(1 indivisible kopecks) will not be generated, 0 (zero) will simply remain in the integer variable

Back to order

1. ordinaryPayout
2. compoundPayout
3. if (ordinaryPayout < compoundPayout)
4. decreaseAmountByGenesis()
5. Well, in conclusion, our reduced number of coins is adjusted, if necessary, as follows:

The value of the constant MAX_BALANCE_AFTER_PARAMINING_PAYOUT_NQT is given at the beginning of the article, where it can be seen that it is set as 100 million.
This is 100 million indivisible parts - kopecks of pzm, which corresponds to 1 million pzm.

If our reduced number of coins is added to the current balance and as a result the balance is more than 1 million pzm, then our reduced number of coins is adjusted by = 1 000 000 - the current balance.

Thus, the total individual amount of coins generated cannot raise the balance of the account for which it is generated more than 1 000 000 pzm.

P.s. At the time of writing, the issue of PRIZM is gradually approaching 50% 😉