Hard Fork 25 is coming, this is a plan for hard fork 26, so....

Ok, I may sound crazy because the number of (total) witnesses has been the same since forever, but hear me out.

20+1 looks too centralized to me and I was reading the code for Hive to see if that could be changed, it can, however it would need a lot of support.

So, what if instead of 20+1 we become 25+2? I have read the code and IT CAN BE DONE, BUT I CAN NOT DO IT ALONE, it would be my first time contributing to the code of Hive, it is an important change, and support is needed.

Why do it?

Hive is centralized with only 20 witnesses shuffled + 1 "random". It is easy that most of them are in only one continent, or multiple ones are in the same country. If we increase it once, we can increase it later, we have to be brave and discover new frontiers, more witnesses, faster block times, smart contracts...

But let us start by what seems to be the most simple one, which is this one I am proposing.

Doing it is showing that a step towards a more decentralized and improved blockchain can be taken, we can get there. It would be a total revolution on Hive as a whole.

But there is no way I can do it alone, I need to be "adopted" by a more experienced Hive developer to help make this change, and more importantly, the community and the current witnesses have to agree on it and support this change.

It happened before

We can see in the code that originally there were 19 witnesses, plus 1 Proof of Work miner, and another runner witness, so 19+1+1

On Hard Fork 17 it was changed to 20+1 (removed proof of work)

So it can be done again, we can, and should, change it to show that Hive is not stagnated. Optionally and preferrably, we could and should reduce the block time so that each round continues at 1 minute (plus the extra runner witnesses), but that seems like a complicated task because of integers and because it would cascade more changes, I am proposing the basic, the block time can be improved later.

To-Do

Another thing is that the inflation should be adjusted, blocks can and should faster with the increase of witnesses.

For that, we ignore the "+1" and the new "+2". So, right now there are 20 main witnesses and a 3 second block time, that means each of the core witnesses gets 1 block per minute, and I think it is great, but if we increase to 25 witnesses the block time should, ideally, be reduced to 2.4s (60 seconds divided by 25 witnesses) so that every one of the 25 core witnesses gets a block every minute (and then the 2 other ones). However, I was reading the code and apparently the block time is measure in seconds as an integer, that means a fraction can not exist, and would be a bit harder to implement.

So I will focus on the changes I found needed to increse the number of witnesses to 25+2, if it is well-received by the community, and if someone can help, we can then explore what it would take to change the block time.

The code I found

So, by reading the code (someone please, correct or help me out here) there is a variable that conveniently sets the number of witnesses every round

You can see it on the file hive/libraries/protocol/include/hive/protocol/config.hpp

These are the lines that counts the "core" witnesses since Hard Fork 17

#define HIVE_MAX_VOTED_WITNESSES_HF17         20
#define HIVE_MAX_MINER_WITNESSES_HF17         0
#define HIVE_MAX_RUNNER_WITNESSES_HF17        1

So we add the new lines for the hard fork 26:

#define HIVE_MAX_VOTED_WITNESSES_HF26         25
#define HIVE_MAX_MINER_WITNESSES_HF26         0
#define HIVE_MAX_RUNNER_WITNESSES_HF26        2

But there is another key variable that ensures the maximum number of TOTAL witnesses:
#define HIVE_MAX_WITNESSES 21

That would be kept, but added another one:
#define HIVE_MAX_WITNESSES_HF26 27
to reflect the 25+2 witnesses for a new fork with, for the first time, a different number of TOTAL WITNESSES.

Cascading the changes

Now we need to find where to append the extra code so that the blockchain and database knows from which fork the number of witnesses changed

On the file
hive/libraries/chain/database.cpp
we do it on the
void database::apply_hardfork( uint32_t hardfork )
switch case right after the hard fork 25:

case HIVE_HARDFORK_1_25:
    {
      modify( get< reward_fund_object, by_name >( HIVE_POST_REWARD_FUND_NAME ), [&]( reward_fund_object& rfo )
      {
        rfo.curation_reward_curve = linear;
        rfo.author_reward_curve   = linear;
      });
      modify( get_dynamic_global_properties(), [&]( dynamic_global_property_object& gpo )
      {
        gpo.reverse_auction_seconds = 0;
        gpo.early_voting_seconds    = HIVE_EARLY_VOTING_SECONDS_HF25;
        gpo.mid_voting_seconds      = HIVE_MID_VOTING_SECONDS_HF25;
      });
      break;
    }
    case HIVE_HARD_FORK_1_26:
    {
      static_assert(
        HIVE_MAX_VOTED_WITNESSES_HF0 + HIVE_MAX_MINER_WITNESSES_HF0 + HIVE_MAX_RUNNER_WITNESSES_HF0 == HIVE_MAX_WITNESSES,
        "HF0 witness counts must add up to HIVE_MAX_WITNESSES" );
      static_assert(
        HIVE_MAX_VOTED_WITNESSES_HF17 + HIVE_MAX_MINER_WITNESSES_HF17 + HIVE_MAX_RUNNER_WITNESSES_HF17 == HIVE_MAX_WITNESSES,
        "HF17 witness counts must add up to HIVE_MAX_WITNESSES" );
      static_assert(
          HIVE_MAX_VOTED_WITNESSES_HF26 + HIVE_MAX_MINER_WITNESSES_HF26 + HIVE_MAX_RUNNER_WITNESSES_HF26 == HIVE_MAX_WITNESSES_HF26,
          "HF26 witness counts must add up to HIVE_MAX_WITNESSES_HF26" );

      modify( get_witness_schedule_object(), [&]( witness_schedule_object& wso )
      {
        wso.max_voted_witnesses = HIVE_MAX_VOTED_WITNESSES_HF26;
        wso.max_miner_witnesses = HIVE_MAX_MINER_WITNESSES_HF26;
        wso.max_runner_witnesses = HIVE_MAX_RUNNER_WITNESSES_HF26;
      });
      break;
    }

And then there are other 15 code occurrencies of "HIVE_MAX_WITNESSES" that would have to take into account the new "HIVE_MAX_WITNESSES_HF26", would they need to be changed, or added an "if/else" to account for the fork? That is why I need support from more experienced developers, and the community, if this idea is crazy enough that it might just work.

Anyone back it up?