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