How do (and should) partitions work in Filecoin?


Given that Filecoin is a consensus protocol that anyone can participate in, what happens in the event that the network’s voting power ends up partitioned into 3 equal regions? The two common answers to this are either for the network to stall until a majority of the voting power can be assembled into 1 partition (e.g. Algorand), or for the network to continue operating by forking into 3 separate networks (e.g. Bitcoin).

Which approach does Filecoin currently take, and are there any thoughts about how this evolves going forwards?


@adin. This is of course an important question and one that we want to help the Filecoin WG think through as we consider various governance mechanisms.


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.

  1. We should have a high likelihood of finality in the protocol. So partitions should be assumed to be temporary. (design requirement).
  2. 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.
  3. 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).
  1. 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.