Whitepaper - Factom With Cover

The Entry Blocks encompass the full extent of possible Entries related to a ChainID. If an Entry
is not referred to in an Entry Block, it can be assumed not to exist. This allows an Application to
prove a negative, as described in the section Security and Proofs.
The Entry Block intentionally does not contain the Entries themselves. This allows the Entry
Blocks to be much smaller than if all the data was grouped together. Separating the Entries from
the Entry Blocks also allows for easier auditing of auditors. An auditor can post Entries in a
separate chain that approves or rejects Entries in a common chain. The audit can add reasons
for rejection in its Entry. If an Application trusts the auditor, they can cross reference that the
auditor has approved or rejected every Entry, without knowing what the Entry is. The Application
would then only attempt to download the Entries which passed the audit. Multiple auditors could
reference the same Entries, and the Entries would only exist once on the Distributed Hash Table
(DHT). Entries are expected to be significantly larger than the mere 32 bytes a hash takes up.
Lists of things to ignore do not have to have the full object being ignored for an Application to
know to ignore it.
An Entry detailing the specifics of a land transfer would be entered into a Chain where land
transfers of that type are expected to be found. One or more auditors could then reference the
hashes of land transfer in their own Chains, adding cryptographic signatures indicating a pass
or fail. The land transfer document would only need to be stored once, and it would be
referenced by multiple different Chains.
13