FIP-0086: Fast Finality in Filecoin #896
Conversation
jsoares
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle,
anorth and
raulk
as code owners
Co-authored-by: Matej Pavlovic <matopavlovic@gmail.com>
FIPS/fip-xxxx.md
Outdated
|
|
||
| The participants in F3 are the storage providers (SPs) of the Filecoin network. The participation of each SP is weighted according to its quality-adjusted power (QAP), which is a function of the storage that the SP has committed to the network. This information is maintained in a system actor called the _power table_. | ||
|
|
||
| In short, each participant $p$ in the Filecoin network (i.e., a storage provider with power) runs F3 in a loop and feeds it input from EC. F3 returns a finalized prefix chain to EC, which updates the canonical chain to extend this F3-finalized prefix. More precisely, in each loop iteration $i$ (corresponding to the i-th instance of F3): |
There was a problem hiding this comment.
can we expand on what does F3 finalized mean?
There was a problem hiding this comment.
Possibly but no good explanation is coming to mind, other than the one that comes right below. Would you like to take a stab or provide a hint wrt what you think is unclear?
Co-authored-by: Matej Pavlovic <matopavlovic@gmail.com>
Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com>
Remove Bracha amplification of DECIDE and use explicit justification (to reflect final adjustment to protocol as per go-f3).
Updated to add FIP number
kaitlin-beegle
changed the title
jsoares
changed the title
|
|
||
| The current EC fork-choice rule selects, from all the known tipsets, the tipset backed by the most weight. As the F3 component finalizes tipsets, the fork-choice rule must ensure that the heaviest finalized chain is always a prefix of the heaviest chain, preventing reorganizations of the already finalized chain. | ||
|
|
||
| We achieve this by adjusting the definition of weight for a finalized prefix: the heaviest finalized chain is the one that **matches exactly the tipsets finalized by F3**, in that a tipset $t'$ that is a superset of finalized tipset $t$ in the same epoch is not heavier than $t$ itself, despite it being backed by more EC power. |
There was a problem hiding this comment.
oh interesting - what would EC do if F3 is halted and not finialize new tipsets?
There was a problem hiding this comment.
from below
In the event that F3 halts, the fork choice rule allows EC to continue to progress, building a chain of unbounded length, per the current rules, on the last F3-finalized prefix.
I assume that just means that there exists no F3-finalised prefix to be a superset of, so it falls back to normal EC rules.
There was a problem hiding this comment.
Right - my q is more about whether there is any latency on when the fallback triggers, how does the chain process know whether receiving no tip sets from F3 is cuz it’s halted or cuz it’s a null round on f3, and decided to proceed with EC or not
There was a problem hiding this comment.
There's no explicit switchover. New tipsets are always appended by EC to the heaviest known chain. By definition, the heaviest known chain must include the latest finalised prefix, but it doesn't "care" if this prefix is 1 or 100 epochs old. If no new prefixes are being finalised, it will still keep building on the heaviest known chain. So there's no decision moment or associated latency.
|
|
||
| We achieve this by adjusting the definition of weight for a finalized prefix: the heaviest finalized chain is the one that **matches exactly the tipsets finalized by F3**, in that a tipset $t'$ that is a superset of finalized tipset $t$ in the same epoch is not heavier than $t$ itself, despite it being backed by more EC power. | ||
|
|
||
| This redefinition of the heaviest chain is consistent with the abstract notion of the heaviest chain being backed by the most power because a finalized tipset has been backed by a super-majority of participants in GossiPBFT. In contrast, any non-finalized block in the same epoch is only backed in that epoch by the EC proposer. |
There was a problem hiding this comment.
To make sure im understanding this correctly - participants in gossipbft will proposes blocks and will be finalized by f3; SPs will propose blocks on EC; only those blocks exists in both f3 and EC would be considered as a final block on filecoin and get block rewards. Does this sound right?
There was a problem hiding this comment.
F3 proposals start from chainHead(), which returns the local EC chain, i.e. tipsets always start their life on the EC side. F3 periodically "freezes" a canonical prefix. Block rewards are disbursed in the context of SBC/EC but, of course, they'll only persist on the canonical chain (i.e. rewards that were earned in a fork that doesn't get selected go away with that fork). So yes, practical block rewards will be those in the canonical chain, which will exist in f3 and EC. Does that make sense?
This is upon convergence, of course. Different blocks may "exist" in different nodes' local views at a specific (yet to be finalised) point in time, as nodes may start with different EC chains and therefore submit different proposals to F3. Deciding for an EC chain that is not locally available is problematic, and this is handled in GossipBFT. But I'll let @ranchalp provide any nuance before I say something very stupid :)
|
|
||
| #### Verification by Filecoin node (“fast catch-up”) | ||
|
|
||
| A new Filecoin validating node can listen to GossiPBFT gossip to learn about the current instance number. They can then issue exchange requests to other nodes to fetch (in parallel) the complete sequence of finality certificates back to their genesis. **These certificates can be verified without reference to the EC chain.** |
There was a problem hiding this comment.
| A new Filecoin validating node can listen to GossiPBFT gossip to learn about the current instance number. They can then issue exchange requests to other nodes to fetch (in parallel) the complete sequence of finality certificates back to their genesis. **These certificates can be verified without reference to the EC chain.** | |
| A new Filecoin validator node ** |
|
I did another quick editor pass to unblock landing the draft first - The FIP is very detailed and well written. I will do another deeper pass when it comes to last call. |
Discussion: #809
The current Filecoin consensus mechanism only provides probabilistic finality. To simplify client implementations and provide some form of determinism, the protocol also includes a soft finality threshold, whereby miners at round N reject all blocks that fork off before N-900. This finalization delay of 900 epochs (7.5 hours) hinders user experience and limits applications built on Filecoin.
We specify a mechanism for fast finality with the F3 component. F3 is expected to finalize tipsets within tens of seconds during regular network operation, compared to the current 900-epoch finalization delay. It does so by leveraging GossiPBFT, an optimally resilient partially synchronous BFT consensus protocol, which runs in parallel with the current protocol, taking EC tipsets as input and providing finalized prefixes as output. EC’s fork choice rule is modified never to select away from the F3-finalized chain.
See also the summary of the implementers' sync (filecoin-project/core-devs#148 (comment)), where it was agreed to consider a sooner-than-nv23 F3-only upgrade. We're still working out a concrete timeline for potential deployment if accepted.
There are still open questions listed in the TODO section, none of which we think are blocking at the draft stage.
cc Jie Hou (@mb1896), Alex North (@anorth), Henrique Moniz (@hmoniz), Matej Pavlovic (@matejpavlovic), Aayush Rajasekaran (@arajasek), Alejandro Ranchal-Pedrosa (@ranchalp), Jorge Soares (@jsoares) and Marko Vukolic (@vukolic)