.png)
This document further elaborates on the Archiving constructions described in Proposed Archiving Constructions (v2.2) in tying together the archived history segments into a single canonical history.
The motivation is to find the minimal amount of information needed to verify that a particular chunk of data is a part of canonical history.
As a result of any approach described in Proposed Archiving Constructions, we end up with a segment of some pieces, some commitments to those pieces, and a segment commitment (records root). From here on, we assume we have a way to prove any piece or chunk inclusion into its respective archived segment.
Since the segments are ordered, they naturally form the history as a vector of such segments. Therefore, we can also naturally measure the time in the archival history in segments. At some particular moment in history, for instance, when history is $l$ segments long, we can compute a commitment (digest) to the history as a vector commitment to the segment roots.
$H = \{s_0…s_l\}$
We define the history digest $C(H)$ as KZG commitment to cryptographic hashes of segment roots.
This digest is the minimal amount of data needed to verify history as it remains constant no matter how much history grows.
Since the blockchain history is not static, the digest cannot be static as well. We utilize the homomorphic property of KZG commitments to update the digest every time a new segment is archived.
TODO Add concrete formulas and API for updating commitments from Tomescu’s aSVC
After a new segment is archived, the next block includes the new segment’s commitment and an update key.
Nodes update their local digest accordingly.
The running cost of reducing the history verification to such a digest is an additional KZG proof whenever some chunk(s) of data need to be proven as part of history. The farmers would also need to update their local proofs for the segments (or pieces of segments) they store. However, this is better than generally in stateless cryptocurrencies since the digest changes only once per archived segment (~100 blocks) instead of every block and sequentially in a single position only. Moreover, farmers can collect logs of updates they need to apply to proofs and only do so when they win a block challenge and need to submit proof.