FIP-0086: adjust converge message selection, define activation epoch (#1076)

* FIP-0086: adjust converge message selection, define activation epoch

Instead of using just the best ticket, use the best ticket that is
acceptable to us. From background gathered by me, the decision to use
the best ticket with no regard for acceptability was made for sake of
implementation simplicity, but the code converged to the point where
these two approaches are equivalent in complexity.

Signed-off-by: Jakub Sztandera <[email protected]>

* Update Delta to 6s

Signed-off-by: Jakub Sztandera <[email protected]>

---------

Signed-off-by: Jakub Sztandera <[email protected]>

Author: Kubuxu

FIPS/fip-0086.md

@@ -235,8 +235,11 @@ In the event that F3 halts, the fork choice rule allows EC to continue to progre
 
 ### Bootstrapping
 
-Integrating F3 into Filecoin follows the usual path for Filecoin upgrades. One epoch, $upgradeEpoch$, will be defined as the target epoch upon which participants upgrade Filecoin. Then, every participant starts the first instance of F3 with the tipset at the $upgradeEpoch$ minus the 900-epoch lookback as the head tipset of the first $baseChain$, which is assumed by design to be common to all participants.
+Integrating F3 into Filecoin follows the usual path for Filecoin upgrades. One epoch, $activationEpoch$, will be defined as the target epoch upon which participants upgrade Filecoin. Then, every participant starts the first instance of F3 with the tipset at the $activationEpoch$ minus the 900-epoch lookback as the head tipset of the first $baseChain$, which is assumed by design to be common to all participants.
 
+$activationEpoch$ is defined as follows:
+ - Calibration network: 2081674
+ - Mainnet network: XXXXXXX
 
 ### GossiPBFT Consensus
 
@@ -393,7 +396,7 @@ A [merkle tree](#merkle-tree-format) is built from these encoded `ECTipset` valu
 * `BestTicketProposal(M)`
     * Let $M$ be a clean set of CONVERGE messages for the same round.
     * If $M = ∅$, the predicate returns $baseChain$.
-    * If $M \ne ∅$, the predicate returns $m.value$ and $m.evidence$, such that $m$ is the message in $M$ with the smallest ticket after adjusting for the power of the sender ($\frac{-log(t)}{m.sender.power}$). M will never be empty as the participant must at least deliver its own CONVERGE message.
+    * If $M \ne ∅$, the predicate returns $m.value$ and $m.evidence$, such that $m$ is the message in $M$ which value is in $C$ or fulfills `justification phase is PREPARE AND mayHaveStrongQuorum(value, r-1, COMMIT, ⅓)`, with the smallest ticket after adjusting for the power of the sender ($\frac{-log(t)}{m.sender.power}$). M will never be empty as the participant must at least deliver its own CONVERGE message.
     * The power adjustment is performed in exponentially distributed ticket space. The ticket is first hashed with Blake2b-256, truncated to 16 bytes which are then interpreted as big-endian fixed-point number with 128bits of precision. The resulting fixed-point number $t$ is in range $[0, 1)$. The $t' = \frac{-log(t)}{m.sender.power}$ provides exponentially distributed $t'$. The logarithm can be approximate, but should provide at least 32bits of precision. After this transformation, the $t'_m$ are compared and the smallest one is picked.
 
 * `Aggregate(M)`
@@ -678,9 +681,9 @@ An instance of GossiPBFT requires a seed that must be common among all participa
 
 GossiPBFT ensures termination provided that (i) all participants start the instance at most $\Delta$ apart, and (ii) the estimate on Δ is large enough for $\Delta$-synchrony in some round (either because of the real network delay recovering from asynchrony or because of the estimate increasing).
 
-[Given prior tests performed on Gossipsub](https://research.protocol.ai/publications/gossipsub-v1.1-evaluation-report/vyzovitis2020.pdf) (see also [here](https://gist.github.com/jsoares/9ce4c0ba6ebcfd2afa8f8993890e2d98)), sent messages are expected to reach almost all participants within 3 seconds, with a majority receiving them even after 2 seconds. However, if several participants start the instance $Δ + ε$ after some other participants, termination is not guaranteed for the selected timeouts of $2*Δ$. Thus, the protocol does not rely on an explicit synchrony bound for correctness. Instead, the estimate of Δ is increased locally within an instance as rounds progress without decision.
+[Given prior tests performed on Gossipsub](https://research.protocol.ai/publications/gossipsub-v1.1-evaluation-report/vyzovitis2020.pdf) (see also [here](https://gist.github.com/jsoares/9ce4c0ba6ebcfd2afa8f8993890e2d98)), sent messages are expected to reach almost all participants within 6 seconds, with a majority receiving them even after 2 seconds. However, if several participants start the instance $Δ + ε$ after some other participants, termination is not guaranteed for the selected timeouts of $2*Δ$. Thus, the protocol does not rely on an explicit synchrony bound for correctness. Instead, the estimate of Δ is increased locally within an instance as rounds progress without decision.
 
-The synchronization of participants within an instance is achieved with a timeout exponentially increasing each round. Participants start each instance with `Δ=3s` and for each round, set the phase timeout to `2 * Δ * BackOffExponent^{round}`.
+The synchronization of participants within an instance is achieved with a timeout exponentially increasing each round. Participants start each instance with `Δ=6s` and for each round, set the phase timeout to `2 * Δ * BackOffExponent^{round}`.
 
 As an optimization, participants may finish a phase once its execution is determined by the received messages, without waiting for the timeout. For example, if a participant receives QUALITY messages from all participants, it can proceed to the next phase without waiting for the timeout. More generally, if the remaining valid messages to be received cannot change the execution of the phase, regardless of the values contained in the messages, then a participant may continue to the next phase.
 
@@ -1000,7 +1003,7 @@ This FIP requires a network upgrade to take effect since it changes the EC fork
        - EC finalizes tipsets
        - Honest participants do not participate anymore to finalize anything  (handbrake)
 4. Integration tests:
-   - Test 0th instance: all participants start by assuming $baseChain$ is epoch number ($upgradeEpoch$ minus 900).
+   - Test 0th instance: all participants start by assuming $baseChain$ is epoch number ($activationEpoch$ minus 900).
      - EB: F3 successfully bootstraps with a decision.
      - Test under Byzantine behavior (<⅓ QAP) and network delays.
    - Test upgrade: same as above, but perform a test in calibration (or simulated upgrade), not in isolation (as above).