SafeContract for NEW network

[maratP]

Issue:

POA Network used to have SafeContract: 0x8bf38d4764929064f2d4d3a56520a76ab3df415b which was used in spec.json and could be used in order to spinup new networks with its own ABI code

Later there were several HFs and spec.json had to be modified with new contracts and specific block numbers when those should take effect. (Example: spec.json lines 16 and 19)

Now, for NEW networks this contract (0x8bf38d4764929064f2d4d3a56520a76ab3df415b) would be outdated and unless MOC and Validators apply all HFs on tops of it, it won't be upto date

Pavel, as discussed, please suggest new SafeContract that could be used for new POA Clone Networks

[phahulin]

Do you also want to replicate Block Reward contract functionality (with Emission funds etc) or would it suffice to have a fixed block reward value for validators the way POA Core had before Nov 2018?

[phahulin]

With a BlockReward contract, it will most likely require two-step process where the network is initially launched with a fixed reward and then HF is performed to switch to BlockReward contract.

[maratP]

Yes, I am also looking for BlockReward contract. There were several HFs, so would like to know which contract should be used first. (initial launch with a fixed reward) and also which HF should be applied and which one COULD be skipped or could they be combined?

[6proof]

With a BlockReward contract, it will most likely require two-step process where the network is initially launched with a fixed reward and then HF is performed to switch to BlockReward contract.

It may be good to always have the two-step option (begin with fixed reward with option for HF to add BlockReward) as well as a single-step option that includes the BlockReward on initial deployment.

Having options is important for blockchain node maintenance. For example, Validator or bootnode operators who sequentially update existing nodes as patches or Hard Forks become available have no issues. However, if an existing node operator chooses to deploy a new instance of a running node, perhaps as a method of refreshing underlying operating system, increasing storage space, deploying secondary bootnodes, etc., it is important that the node comes up in a fully functional state without need of additional patching.

Branch specific instances could be excellent solution. For example, Master may include fixed reward only, POA Core and Sokol will include BlockReward, etc. Such a method allows new network deployments to select the type of network deployment best suited for that horizontal community. This will be interesting to test both in the lab and the wild.