Welcome to Crums, a new, non-invasive approach for generating and using unimpeachable receipts from tamper-proof private or public ledgers. At scale.
The first products concern a ledger that is a general purpose notary called a timechain.
Its only purpose is to dole out evidence of witnessing things (as represented by their SHA-256 hashes). This uses
a new commitment scheme called a skip ledger. (See the skipledger-base module in the
skipledger project. Note changes, ongoing refactorings in the README there.)
Technically, a timechain is actually a very special-purpose ledger. Unlike more regular ledgers, timechains cannot recreate the receipts they doled out from their ledgers; they can only verify whether a given [witness] receipt was actually generated by them. Timechains, in fact, do not really use the skip ledger's partial reveal property: they don't even know how to recreate the receipts that make up the commitment hash for a time block (the so called cargo hash).
The next set of tools under development concern issuing receipts from general ledgers. Unlike timechains, regular (think more tabular) ledgers, contain persistent data from which receipts can be generated at will. Here, these receipts do use the commitment scheme's partial reveal property. Specifically, a ledger owner can prove the contents of any row in their ledger against any commitment hash of their ledger issued on or after it included that row.
Note, the notion of a ledger is quite general. It needn't be a regular bookkeeping ledger: anything you can only add to, in some unit of chunks (which we'll just call rows) qualifies. For example, livestreams and log files can both be modeled as ledgers.
The following is a partial list of already prototyped products under development:
- morsels. Binary archives for proving items in muliple ledgers.
A morsel file is a bundle of provable receipts from ledgers. Morsel files support both the merging and fine-grained redaction of their contents. A morsel's data from one ledger often cross references an item in one of its other ledgers. As an example, morsels model timechains just like any other ledger: a ledger's state (it's hash) may be witnessed (referenced) in a crumtrail (the witness receipt) embedded in the same morsel. - log-ledge. Calculates the hash of a log file (up to the nth or last line).
Calculating the hash of a log-like file this way allows one to later differentially reveal (and prove) any of its lines (and redact any word/token) against the committed hash. If you're already storing the hash of such files somewhere, calculating their hash this way enjoys these advantages. This may be especially relevant if log files are presently saved for their evidentiary value. Witnessing this hash on a timechain is a better choice than witnessing the straight hash of the log file. - sql-adaptor. Defines a ledger using an SQL query and provides a live view of its proof structures.
Though the adaptor maintains it proof structures in its own SQL tables, importantly, its workings do not involve annotating existing tables in anyway. Rather, it only ever reads existing tables: it shouldn't even have write-access to the tables it queries. All of a user's work designing a ledger is encapsulated in the SQL query they define to create a ledger-consistent view. - reports. Simple template engine for generating reports from morsels.
This generates customizable, brandable, user-facing PDF from morsel data. Such "reports" can take many forms: an invoice, a receipt, a contract: anything that makes its way into a ledger. This works using a DSL that tells the software how entries in a morsel are grouped (keyed) and assembled into individual PDF "reports".
There is a long list of products and services I hope to develop around and on top of these concepts. Many of these ought to be general-purpose. But their requirements will only crystalize after we tackle more "verticals". If you have a vertical you'd like to develop (or would like seen developed) drop me a line, let's discuss.
Babak Farhang (babak at crums dot io)
December 2024