Why and How Krakin’t needs to invent the new controlled supply and a mining model
Bitcoin’s controlled supply mechanism is well known and information about it can be easily obtained from the Internet. The same mechanism can be applied to Krakin’t, however, there is one big difference in a design, and that is, the proof of burning.
Without getting into a mechanism how the burning will apply to earning, even if everyone kept their tokens to themselves, there are a few basic constraints that need to be solved first.
Bitcoin controls a supply by halving the supply every 210000 blocks. This is great because the supply is always increasing and we can simply follow the number of blocks and do the basic division of the numbers. However, since Krakin’t is neither increasing nor decreasing with a current supply, it means that we can make the virtual blocks as if going backward and forward in time. This means that we could go back to block 1 and go forward to any other block at any time. For that, given the current supply only, we must be able to derive the block number, reward era, rewards per block, and when to issue the rewards. In this process, the halving is always happening, per block and it makes no sense to wait 210000 blocks.
The problem with this design is that we are limited with the costs of Ethereum and the math that we can apply. It would cost enormous amounts of money to create a table and simply load it onto a block-chain, although that would be the simplest and the fastest solution when calculating the numbers. The next best option is to derive the math formula, which is the option Krakin’t has already investigated.
Since we are not given decimals and negative numbers with Solidity (Ethereum programming language for tokens) we also have a limited supply of the math functions. The math functions that we can use are simply +,-,*,/ and then also the min, max, step, sign with the logical operators if-then, and,or,xor,greater-than(-or-equals),less-than(-or-equals), not. We can also track the history of the movement to derive the moving averages, although, in my opinion, it is not as useful since we can go back and forward the blocks.
This is hardly enough to be able to formulate the bitcoin’s supply model represented by:
where we have to know what block we are in, at any point in time, simply by knowing the current supply of the tokens.
Currently, there are tools that can enable us to do such modelling, and one of them is called Eureqa. It is (currently) an old piece of software that helps designing the math formulas. Although old, it does work most of the times. Since our table is going to be finite, we will have the maximum number of tokens that can exist, but the maximum will never happen. Therefore, it is a matter of using the spread-sheet, designing the pattern, running it with Eureqa and our limited math formulas… then correcting the errors, and repeating over and over again until we get a good model.
One thing that must be kept in mind is that formulas must be as simple as possible in order for the mining to cost as least as possible.
I will stop the writing right here because there will be more components to the mining model, while the final formulas and a mechanism will be revealed one day in the future, as soon as we enable the platform for supporting the projects.