Description
Making updates in the consensus slashing rules PR it has occurred to me that we don't have the necessary things to actually compute consensus slashing from within the SlashConsensusFault state machine method.
(1) To slash when there are overlapping ticket rounds SlashConsensusFault needs some way to read ticket round numbers from the two proving block headers. Because Height is moving to a measure of the number of blocks in a chain and no longer a measure of tickets the block data structure needs to include a round number to evaluate this slashing condition only from block headers. Alternatively we could have nodes maintain round number locally and include a new method on the state machine execution context that looks up and returns the base round number of a block.
(2a) To slash when there is a dropped ancestor block we need proof that there is a chain of blocks from b1 back to ancestor TipSet A such that another block b2 is a valid extension of A but is not in A. One way to do this is by adding in an execution context function that can return ancestors of b1 up to the parent of A.
(2b) It is harder to handle the case where the SlashConsensusFault caller's chain is built off of b1 and the fork is built off of A. In this case the execution context will not in general have access to the fork as it may not be stored locally and the methods on the execution context should not trap into the network. It seems like the best way to handle this is to carry a list of block headers from b1 to the parent of A in the slashing message. The parent hashes and block signatures can be processed to prove the existence of the fork from b1 to A within SlashConsensusFault, and again the relationship between b2 and A can be proven using A's parent. This mechanism will handle the (2a) case and should be used there too to keep things simpler.