A forced GrandPa authorities change consists in forcing a change in the GrandPa authorities.
There are two problems that need to be solved:
When a force change occurs, it doesn't get signed by the current authorities. GrandPa warp sync is unfortunately based upon the assumption that each set finalizes the change to the next set. We would have to include more information in the GrandPa warp sync payload, notably the headers of the blocks that lead to the forced change.
Light clients only verify block headers and not block bodies, meaning that we don't have any indication that a forced change is actually legitimate. A malicious validator could emit an invalid block, and light clients can't detect that it's invalid with only the header. We would have to execute this block in particular, but the storage of the parent might no longer be available on the network.
The pragmatic solution at the moment is to generate a checkpoint (i.e. a snapshot of the chain) from a full node after the forced change and update the chain specs.
A forced GrandPa authorities change consists in forcing a change in the GrandPa authorities.
There are two problems that need to be solved:
When a force change occurs, it doesn't get signed by the current authorities. GrandPa warp sync is unfortunately based upon the assumption that each set finalizes the change to the next set. We would have to include more information in the GrandPa warp sync payload, notably the headers of the blocks that lead to the forced change.
Light clients only verify block headers and not block bodies, meaning that we don't have any indication that a forced change is actually legitimate. A malicious validator could emit an invalid block, and light clients can't detect that it's invalid with only the header. We would have to execute this block in particular, but the storage of the parent might no longer be available on the network.