| Let's look at another project that needed a such a ledger: the certificate transparency project. One implementation of it, google's, uses leveldb: https://github.com/google/certificate-transparency Another one out there uses postgres. It turns out that you can use traditional databases in many cases where you think you need a blockchain, and you'll be able to waste vastly less energy on proof-of-work and vastly less time dealing with the terrible mess that is "blockchain". The reason not to use "blockchain" is that it has 200 definitions, all of them full of people trying to get rich, not getting things done. Databases have long-since solved the problem of storing and distributing data. Distributed stores like etcd, zookeeper, and so on have long since solved the problem of duplicating data. Very few people need byzentine fault tolerance (due to having a large number of untrusted actors with write access), which is the only time the additional complexity blockchain includes is actually useful |
Hence we shall issue signed receipts to all clients and providers then setup a system to pay out a large bounty if someone can produce a signed receipt not in our weekly-published-log. We'll automate the bounty, but perhaps a third party will also offer a validator. We will not even need Postgres for it, just nginx and a filesystem.
But that is not interesting enough by itself, and mentioning digital signatures just confuses people more. So we call it a Single-Issuer-Blockchain: Now people instantly get the idea.