hotstuff 的 proposer 轮换策略好像都是基于 HighQC、view number 这些，因为这些信息是所有 validator 达成共识的。那是否会有 proposer 轮换卡死的可能，举个例子：

比如 LibraBFT 的 hotstuff 方案中，当 validator 触发超时时，新 proposer 收集到 2f+1 的超时消息从而产生一个 Timeout Certificate(TC)，正常情况下，此时新 proposer 会广播这个 TC 来对 validators 视图进行切换，所有 validators 的 view_number+1，然后广播一个新的提案，开启对新视图的共识。

但如果 proposer 恶意不广播 TC 也不广播新的提案呢？由于视图切换都是基于 QC 或者 TC 的，因此这种情况下其余 validator 的视图号 view number 并不会增加，HighQC 也不变，HighTC 也不变，那此时要基于什么轮换 Proposer 呢？不就一直卡在作恶的 proposer 上了吗？

Tendermint 就不会有这个问题，即使 proposer 故意不广播新提案，validators 也会对新的 Round 投 nil 票，超过 2f+1 的 nil 票会使得 Round+1，从而换掉之前的 Proposer。

那么 hotstuff 要如何解决这个 proposer 轮换卡死的问题，还是说 hotstuff 的 proposer 轮换有其他的变量在里面？