feat: brioche hard fork; halving block reward

[egonspace]

Brioche hard fork includes the following.

• block reward halving system
• not use RewardAmount from the gov contract for block reward any more
• brioche config includes brioche hard fork block, first halving block, halving period, halving rate, finish halving block, block reward amount

And added some refactoring about validation for Fees and Reward fields of a block.

The following tested manually.

• [x] Hard fork test with a private local chain.
  • 2 nodes
  • start with master version and upgrade it with brioche binary
  • [x] brioche hard fork starting
  • [x] brioche reward amount
  • [x] starting brioche halving
  • [x] finishing brioche halving
  • [x] halving period
  • [x] halving rate
• [x] Mainnet syncing with brioche version

[jed-wemade]

There is no Brioche config validation whether configs are same among the nodes. Without the validation, the below test vector would be passed.

func TestRewardValidation(t *testing.T) {
    ...
    byzantineConfig := &params.ChainConfig{
        ChainID:      gspec.Config.ChainID,
        LondonBlock:  gspec.Config.LondonBlock,
        BriocheBlock: gspec.Config.BriocheBlock,
        Brioche: &params.BriocheConfig{
            BlockReward:       gspec.Config.Brioche.BlockReward,
            FirstHalvingBlock: gspec.Config.Brioche.FirstHalvingBlock,
            HalvingPeriod:     new(big.Int).Div(gspec.Config.Brioche.HalvingPeriod, big.NewInt(2)), // different period!!
            FinishRewardBlock: gspec.Config.Brioche.FinishRewardBlock,
            HalvingTimes:      gspec.Config.Brioche.HalvingTimes,
            HalvingRate:       gspec.Config.Brioche.HalvingRate,
        }
    }

Node cannot catch the difference before applying config from correct nodes. Hence, nodes set by wrong config params would compromise the safety.

[egonspace]

There is no Brioche config validation whether configs are same among the nodes. Without the validation, the below test vector would be passed.

func TestRewardValidation(t *testing.T) {
  ...
  byzantineConfig := &params.ChainConfig{
      ChainID:      gspec.Config.ChainID,
      LondonBlock:  gspec.Config.LondonBlock,
      BriocheBlock: gspec.Config.BriocheBlock,
      Brioche: &params.BriocheConfig{
          BlockReward:       gspec.Config.Brioche.BlockReward,
          FirstHalvingBlock: gspec.Config.Brioche.FirstHalvingBlock,
          HalvingPeriod:     new(big.Int).Div(gspec.Config.Brioche.HalvingPeriod, big.NewInt(2)), // different period!!
          FinishRewardBlock: gspec.Config.Brioche.FinishRewardBlock,
          HalvingTimes:      gspec.Config.Brioche.HalvingTimes,
          HalvingRate:       gspec.Config.Brioche.HalvingRate,
      }
  }

Node cannot catch the difference before applying config from correct nodes. Hence, nodes set by wrong config params would compromise the safety.

Unfortunately, we don't have a mechanism to compare configurations with other nodes. But if you think about it, you can see that synchronizing configurations between nodes is not conceptually correct. This is because, for example, different config settings are indispensable for nodes during the hard fork upgrade.

[jed-wemade]

Unfortunately, we don't have a mechanism to compare configurations with other nodes. But if you think about it, you can see that synchronizing configurations between nodes is not conceptually correct. This is because, for example, different config settings are indispensable for nodes during the hard fork upgrade.

I got it. It is general hard fork situation. I was concern different configs make same state among nodes for a while. The config affects on future halving blocks, and fork will be done by major nodes.

[egonspace]

Unfortunately, we don't have a mechanism to compare configurations with other nodes. But if you think about it, you can see that synchronizing configurations between nodes is not conceptually correct. This is because, for example, different config settings are indispensable for nodes during the hard fork upgrade.

I got it. It is general hard fork situation. I was concern different configs make same state among nodes for a while. The config affects on future halving blocks, and fork will be done by major nodes.

According to your good advice, if the next fork information is different when handshaking with peer, I left a logging so that we could prepare for it in advance.

WARN [05-28|17:28:03.345] Checking ForkID: different next fork     peer=f6215791327f1b5a52a763297a5263407a92ea2fa586a7b887410ef9e5b6800d peerForkID="{Hash:[44 77 205 215] Next:0}" myForkID="{Hash:[44 77 205 215] Next:607147}" error=nil