Peras is incompatible with HFC block counting #92

The HFC currently uses block counting to confirm an era transition. Also see here for more info. This approach relies on the fact that k blocks arise between the "voting deadline" (currently 6k/f before the era transition, but could be earlier as of Conway governance) and 3k/f before the next era.

This approach doesn't really work well with Peras for two reasons (there are other reasons why block counting is potentially problematic, see IntersectMBO/ouroboros-consensus#389):

1. There might not actually be k blocks within 3k/f slots. In Peras, the notion of chain growth targets weight of chains. For example, a chain having weight at least k in 3k/f slots does not automatically imply that there actually are k blocks in those 3k/f slots.

   It would be very non-trivial to make the HFC aware of weight as certificates are not actually on-chain.

   Still, the probability to have less than k blocks in 3k/f slots might only be slightly higher than in Praos, so this particular point might not be a dealbreaker in and of itself.

2. Peras can cause the time translation horizon to recede.

   The historical motivation (cf "17.4.3 Stability should not be approximated" in The Cardano Consensus and Storage Layer report) to use block counting was to ensure that the time translation horizon of the tip of the selection can never shrink. This was guaranteed by the fact that we never switch to a shorter chain, so once we had adopted k blocks, an era transition will be known forever. This is in contrast to "slot counting" (ie requiring 3k/f slots after the voting deadline), where we might switch to a denser (but not shorter) chain whose tip is before 3k/f after the voting deadline.

   With Peras, we can now switch to a shorter (but weightier) chain, negating this benefit of block counting compared to slot counting.

   (Note that in all of these cases, the reduction of the time translation horizon is purely temporary; as soon as the chain has grown sufficiently, the same slots can be translated again, and the translation did not change, ignoring chain growth disasters.)

Therefore, the goal is to get rid of block counting; either replacing it with slot counting (simple case) or getting rid of "double stability" entirely somehow; also see IntersectMBO/ouroboros-consensus#420.

Also see #11 for past discussions