biglep@ understanding of additional design considerations and decisions.

Author: BigLep

FRCs/frc-0108.md

@@ -84,6 +84,9 @@ Notes:
 - `FinalityCertificate`s should be ordered by `GPBFTInstance` in ascending order for sequential validation and intermediate power table calculation. This also ensures deterministic generation of F3 snapshot from a given F3 finality certificate chain.
 - The first and last `FinalityCertificate` instances should match those in the [F3SnapshotHeader](#f3snapshotheader), respectively.
 - This [CARv1](https://ipld.io/specs/transport/car/carv1)-like format is ideal for dumping blocks via streaming reads as the [F3SnapshotHeader](#f3snapshotheader) can be loaded first and minimal state is required for ongoing parsing.
+- This is "CARv1-like" but not true CARv1 because data blocks are not content addressed by CIDs. 
+- The "varint-encoded byte length" prefixes follow the CARv1 format.  It is an implementation detail of the CARv1 format that we're bleeding through here.
+- We aren't CBOR-encoding all of F3Data to enable streaming with lower RAM requirements.  Node implementations are already experienced at streaming CARs, and we didn't want them to have to properly configure/use CBOR encoding/decoding in a streaming fashion.
 
 ### F3SnapshotHeader