FIP-0063: Add upgrade and protocol change details (#914)

* FIP-0063: Add upgrade and protocol change details

* Address review

FIPS/fip-0063.md

@@ -34,6 +34,8 @@ For further details on these new features and their implementation we refer the
 
 ## Specification
 
+### Beacon Verification
+
 Currently drand verification is performed in two stages:
 
 1. hash the previous beacon’s signature and the current beacon round number using SHA256 
@@ -69,17 +71,29 @@ The details of `quicknet` chain info are:
 }
 ```
 
-- retrieve every 10th beacon
+### Beacon Sourcing
 
 The way beacons are retrieved must be adapted to fetch every 10th beacon instead of every beacon to accommodate for Filecoin epochs. In previous iterations of filecoin, operators could request drand beacons with monotonically increasing round numbers, as the drand and filecoin epochs were aligned. Upon switching to the new scheme, consumers must ensure they request the right drand epoch over either HTTP or gossipsub.
 
-`quicknet` genesis was on 1692803367, while Filecoin Genesis was on 1598306400, thus Filecoin block 3547000 (2024-01-08 12:20:00 (UTC)) should be mapped to our drand quicknet round 3971011 because `1598306400+3547000*30 == 1692803367+3971011*3`  and all subsequent Filecoin rounds are mapped to multiple of 10 after that: `3971011+x*10`
+For a Filecoin epoch at time `T` seconds, we source randomness from a round at time `T - 30` seconds. Thus, the beacon round 
+corresponding to a filecoin epoch at time `T` is calculated as `(T - 30 - 1692803367)/3 + 1`, where 1692803367 is the genesis timestamp of Quicknet, and 3 is the period duration of Quicknet.
+
+### Block Headers
+
+Blocks should only ever include one beacon entry in their header, for the round corresponding to the Filecoin epoch as described above.
+This is a change from existing behaviour, where block headers sometimes include multiple beacon entries (specifically when built on "null" tipsets). Storing multiple beacons is no longer necessary as the unchained nature of Quicknet does not require us to keep and validate the full history of consecutive rounds.
+
+### Upgrade
+
+The switch to Quicknet will happen in a network upgrade. All blocks produced in the new network version should source their beacons from Quicknet.
+
+### Catch-up
+
+If drand halts, Filecoin stops producing blocks. Once drand comes back online, it produces randomness faster until it catches up to the expected present round. 
 
-- account for new catch-up time
+Filecoin, too, has a similar catch-up mechanism that consumes the expected beacons (per the mapping defined above) as they become available. Quicknet has a catch-up time of 2s per beacon, and so the total catch-up time per Filecoin epoch is increased from 15 seconds to 20 seconds. 
 
-The new catch-up time of 2s per beacon will result in a longer catch-up period per Filecoin epoch of 20 seconds rather than the current 15 seconds; any monitoring, alerting, reporting or automation relying on the existing catchup time must be updated with the new period of 20s.
-When fetching only every 10th beacon with a catch-up time of 2 seconds per round, the total catch-up time per Filecoin epoch is slightly increased from 15 seconds to 20 seconds. This is only applicable in times of drand outage,  of which there have been none since the launch of Filecoin. 
-If drand goes down, Filecoin stops producing blocks. Once drand comes back online, it produces randomness slightly faster, but Filecoin's recovery is bound by this time-frame.
+This is only noticeable in case of a drand outage, of which there have been none since the launch of Filecoin. Nevertheless, any monitoring, alerting, reporting, or automation relying on the existing catch-up time should be updated with the new period of 20s. 
 
 ## Design Rationale