The development begun even before the CBR poll, so we did not know whether CBR will be and how much the constant block reward will be. I wanted to create a solution that could be released to production (after testing) in a dormant state and then only turned on by contract transaction.
The first attempt was kind of a flop, but still I think it could have worked. The current version is combined with block version update and is improved in other areas.
This will be more about the block version change and almost none about CBR. When we want to change anything that influences the consensus protocol, like block acceptance rules or reward rules, we need to arrange that the whole network starts using the new protocol rules at the same time, otherwise uncontrollable number of forks would emerge gradually as users upgrade. For this purpose we use block versions and tie any new rules to new version. Current is v9.
Traditionally we used block versions tied to a hard-coded block height. Eg: 1100000. We made a humble guess on what the block height would be when most users had updated, wrote this number into the gridcoin source and announced a release. You can imagine that guessing the block height to put there is, well still a guess. We usually choose two weeks.
Now this “soft” update would allow use to make a release without such hard height trigger, but instead trigger the block version upgrade remotely, when we see that enough users had upgraded. What is more, if we find a issue between the release and activation of the update, we will have the option to back off last minute and not perform the activation.
The “soft” mode is made by quite simple rules:
Those are all the hard coded rules! But this way the update will simply not happen. To make it happen, client with modified code will be distributed to controlled group of people who will then try to stake the first v10 block.
Remember that standard consensus and reorganize rules still apply. If there would be large number of nodes(weight) that reject the updated block, chain would fork at that point and soon the fork resolver will pick the fork with more weight and possibly roll back the update. A clarification: the rollback will only happen if the old version has more stake weight support than the new on (technically chainTrust).
If the update does roll back (excluding 1/2 reorgs), it is only indication that we did a mistake, timed our first block wrong, and the network was not yet ready. Or someone is doing 51% attack on the network, in which case we are screwed anyway.
For peace of mind, we will release a leisure upgrade later, that will no longer support old version blocks above some height. That will prevent any massive rollback, which should be already not possible, due to so called txPrev bug - feature.
The only downside that I see is that we do not know the exact block height the update will happen. This is concern for exchanges and speculative stakeholders. This problem is not insolvable, thou. We can just make a promise on the time we will will execute the update. After all, it has been accepted, by not one, but 4 blockchain polls.
As a last option a hard block height trigger can be trivially added to CheckBlock, but I would still like to see how it behaves on testnet.
