Frosty Consensus Details

Do you have any PDFs discussing how Frosty (leadered consensus for block production) will work/is this still a priority? I haven’t been able to find anything substantive about it in the docs/repo or through Google searches.

If I’m understanding Snowman consensus correctly, it seems like there could be a “worst-case” honest participant scenario where multiple validators try to create the same block at the same height with slightly different contents. Is mitigating this scenario (and the extra communication overhead/delayed finalization associated with it) the main motivation for Frosty or is there some other inspiration?

I’m assuming Frosty may also include some setting to allow for batching transactions to minimize block header overhead (I guess that would be up to the “ProduceBlock” implementation)?


There are quite a few interesting reasons to want to implement Frosty. The main reason Frosty hasn’t been implemented yet is just because there have been more critical features that needed attention. It’s still going to be implemented and is quite high on my task list.

A few highlights:

  • As you mentioned block contention is a major reason that introducing a leader can improve the performance.
  • DDoS protection is much more simple to implement in the leadered context than the non-leadered context. Reducing code complexity generally makes the network more stable and secure.
  • Snowball is an extremely efficient verifier. However, its performance can degrade while there are conflicts more so under a strong byzantine adversary.

Wasn’t leaderlessness one of the main selling points of Avalanche? To consider removing it makes it feel a bit of a dishonest marketing thing.

Frosty won’t necessarily be implemented on the C-chain. It could be used as the basis for other contract chains, either on the primary network or on subnets.

1 Like