This is a key question, right now we’re trying to pin down how our consensus mechanism deals with finality, which determines this. There are a lot of ideas here, and I’ll name a few that are mine. This is personal thoughts vs canonical answers. Ie, Nicola, Why, anyone, please correct me.
- We should have a high likelihood of finality in the protocol. So partitions should be assumed to be temporary. (design requirement).
- The fork mostly affects the power table’s reflection of reality. We call this Storage Power Consensus (vs Expected Consensus which determines how a leader who gets to mine is selected with the power table as input).
We should resample the Storage power at regular intervals, using parameters we draw from contingency/finality to ensure it’s not resampled to take into account temporary partitions.
- Within a partition, there are two key cases:
- Client and miner end up in the same partition
- in this case, miner still gets paid as PoSTs get reflected
- Client and miner are in different partitions
- in this case, parameter choice around slashing will affect whether miner is punished (same sort of arg as in 2).
- There are some choices we can try and make to ensure work is not wasted by the fork, with PoSTs on the “wrong” side of the partition getting reused. I’m thinking specifically of Fruitchains right now, and basically enabling leaders to include proofs from orphan blocks to increase the weight of their chain (enabled by a gossip protocol).
FYI, insofar as I know, this is still in design space rather than spec’d out.