As we contemplate moving the mining process from Gnosis chain to another chain, the question has come up of whether it is worth planning for potential future mining migrations. Ultimately it is hard to predict which chain will be the best home for reputation mining in the long run, and so adding support for possible migrations seems wise.
This issue will summarize the open and closed questions related to this functionality.
OVERVIEW:
The process for migrating reputation mining to a new chain will likely look something like this:
A block number is chosen on the current mining chain to be the block after which no new reputation mining cycles will be created. This block can be chosen arbitrarily far in advance.
Any reputation mining currently going before this block can continue to resolution (for example, an extended dispute).
Once the final reputation state is determined, it is sent out to all other chains as the final action. This message may be followed up with a separate message terminating mining on that chain, or a flag, or something else.
After this, mining will begin on the new chain. For all intents and purposes, mining remains identical, except that the address of the mining chain is updated on all networks. The new mining chain should be configured with bridge information for the non-mining chains.
DETAILS:
Make it possible to set the miningChainId, perhaps through an updateMiningChainId function call which can be sent across the bridge.
Reputation updates sent across the bridge after the deprecation event should be rejected and stored as "pending", ultimately sent to the new chain after the update.
OPEN QUESTIONS:
Will nonces/counters continue to function after mining chain updates?
What happens if the new mining chain block numbers are much lower than the old mining chains?
Do the reputation keys (0x{colonyId}{skillId}{userId}) need to be migrated?
As we contemplate moving the mining process from Gnosis chain to another chain, the question has come up of whether it is worth planning for potential future mining migrations. Ultimately it is hard to predict which chain will be the best home for reputation mining in the long run, and so adding support for possible migrations seems wise.
This issue will summarize the open and closed questions related to this functionality.
OVERVIEW:
The process for migrating reputation mining to a new chain will likely look something like this:
DETAILS:
miningChainId, perhaps through anupdateMiningChainIdfunction call which can be sent across the bridge.deprecationevent should be rejected and stored as "pending", ultimately sent to the new chain after the update.OPEN QUESTIONS:
0x{colonyId}{skillId}{userId}) need to be migrated?