Recommend this page to a friend! |
Classes of Scott Arciszewski | Chronicle | docs/internals/01-design-philosophy.md | Download |
|
DownloadDesign PhilosophyContents
Chronicle ExplainedThe main purpose of Chronicle's design was to enable technologists to propose a non-blockchain solution when blockchainiacs sink their talons into an otherwise well-intended project. Specifically, Chronicle is narrowly focused on systems with a limited number of writers in a mostly-centralized topology where it makes good engineering sense to implement decentralized verification of the central hub. Any attempt to turn Chronicle into a cryptocurrency will be rejected. In a similar vein, any proposals to make Chronicle "trust-less" or have multiple branching paths will most likely not be considered. What Chronicle Is
What Chronicle Isn't
Mostly CentralizedAlthough Chronicle favors centralized systems (i.e. single writer, or very few writers all publishing to the same server), its trust model favors decentralized verification. How this works is simple:
If you combine these two features (replication and cross-signing), it's very easy to compose a system that is resilient to targeted attacks:
These two features make it extremely easy for anyone to conclusively verify that a given Chronicle's contents were not changed after-the-fact. That's it. There's nothing more to our security model. It allows you to digitally sign and timestamp messages, which can in turn be used to build various security features. Cryptographic DesignChronicle uses a hash-chain data structure built with the BLAKE2b hash function. Specifically, two hashes are calculated for each record:
In effect, this ties each record not only to the immediate previous entry
(since the previous hash is used as the BLAKE2b key of the current hash,
recursively), but also to the entire immutable history since the first
block (since the Why Implement a Hash Chain Instead of a Merkle Tree?While we don't discount the usefulness of Merkle Trees, properly implemented Merkle trees (i.e. domain separation for leaf nodes to prevent duplicate record injection, or double-spending attacks in cryptocurrency) forces writers to rehash up to half the entire history in order to calculate the Merkle root. (This assumes that the child node of the first half of the history is cached for performance purposes. If it's not, you have to rehash the entire history every time you append a record.) When you have many gigabytes of data stored in the Chronicle, the performance implications of rehashing half of recent history becomes clear. A hash chain data structure consisting of two hashes ( You only need the previous record's And yet, because of how each hash is constructed, so long as BLAKE2 remains unbroken, you can guarantee the append-only nature of this data structure. (For anyone not familiar, BLAKE2 is at least as secure as SHA3 but faster than MD5 on 64-bit platforms.) Furthermore, since Chronicle's publishing model is centralized (while verification is decentralized), we don't need the other advantages of Merkle trees. A simple hash-chain suffices. In short: Our hash-chain data structure affords us the same relevant security properties you'd expect of an equivalent system implemented with Merkle trees, while being significantly faster with large histories. Hash-Chain Pseudo-Code
|