How does a new Kaspa ATAN verify history it downloads from an untrusted peer?

A new Accepted Transactions Archival Node (ATAN) that bootstraps from an existing one must download transaction data and their ordering, then validate both against a cryptographic proof tied to a commitment available on any standard pruning Kaspa node. Because the source ATAN is considered untrusted, the new node cannot simply accept the data at face value — it must check the download against information the broader Kaspa network independently holds. This matters because it illustrates a core Kaspa principle: even when a node learns its history from a single peer, the network's built-in cryptographic commitments keep that data verifiable without trusting any one source.