How about a thing that's almost-but-not-quite a blockchain? E.g. a decentralized multi-master Event Sourcing datastore. No proof-of-work, no mining, no ledger. Anyone who can connect to the network (i.e. is whitelisted) can append whatever they like, and it'll get replicated to everybody. But nobody can delete/overwrite (without losing consensus); and every event is signed by its emitter. It's just an append-only log file that happens to exist in several (geographically distant) places at once.
Get the actors together to standardize a format for the messages everyone's emitting, and then make some software (one shared implementation, many different ones, doesn't matter) to parse the log stream into a point-in-time representation you can load into an analytics tool.
Seems to me that that sort of technology would fit this use-case a lot more closely than an Actual Blockchain™ would.
No. A log file under Paxos, for example, is not a blockchain.
A blockchain is a chain of blocks. A block is a persistent record of all the information required for the consensus process, which is held onto by a node after the consensus process has completed for that node. A new blockchain node bootstrap-syncs to the network by just receiving blocks at random from peers and then evaluating the consensus rules against those blocks in order to decide what its deduced copy of the "chain" shall look like. And you can never throw those blocks away (just keeping the transaction log), either, because a new peer might want to bootstrap itself from you.
This is not how multi-master sync in e.g. etcd or Postgres works. In those, consensus is a process that happens between all the nodes registered to a given cluster at any point in time. Each consensus-step happens between a known, fixed set of peers (fixed for the duration of that step, that is), consuming a fixed set of data that must be the same on all peers (the database before the update), and producing a new artifact (the updated database) that should be identical on all peers. After the consensus step completes, the inputs required to re-evaluate that particular consensus step are discarded by all peers. You can't go back and "watch history" happen again. You can only know what you've got right now.
But, luckily, since what you've got right now is an append-only file, you can just read it and see everything that's happened historically. It's just a logical history, though, not the history of the consensus process itself.
New nodes in such a system don't re-evaluate history to "reach consensus." They just pick a bootstrap peer to trust and slave themselves to it, synchronizing until they're an exact mirror of it. But—because all the nodes in the cluster keep their state in lockstep under consensus anyway—every node that is "in consensus" is as good as any other node that is "in consensus" for bootstrapping from. (And if you happen to bootstrap from a node that is lying about being "in consensus", then you'll quickly find that you can't obey the consensus protocol with the rest of the cluster using the data you bootstrapped.)
A blockchain is a very specific kind of distributed database architecture. Just having a distributed append-only database does not automatically make something a blockchain. You can have distributed append-only databases that aren't blockchains.
(Heck, there's an even more trivial case: a distributed append-only database owned by one party. How do you build that? Just deploy a master and some read-replicas, and tell the master to be append-only by policy! It should be pretty obvious, I hope, that that is not a blockchain.)
Nah, git retains its commit history, so it's actually closer to a blockchain approach than what I'm describing. Plus, with git, the syncs [with git-push and git-fetch] are async, such that a "cluster" of git-using nodes is never "in consensus" as a whole.
Picture instead, something more like a document synced in realtime using Operational Transformations (via SubEthaEdit, Etherpad, Google Docs, etc.), purely peer-to-peer (so specifically like SubEthaEdit) and without any peer expected to retain any history of the OT sync process itself (so you can't "wind back" the document like you can on Google Docs.) Except, now, also picture that if you try to broadcast any OT events other than an insert OT, the other nodes will just ignore those OT events, causing your document to fall out of sync with everyone else's. So the document itself can only ever grow, and nothing can be redacted or changed once it has been inserted.
So now you've got this single document that everyone can "write" to (but never change anything that's already been "written.") Now just make everyone always put their new writes at the end, so they're not breaking up anyone else's message. Now you've got a durable, distributed message bus.
(If you've ever used a wiki Talk page—or the old original C2 wiki where every page was a Talk page—the rule there for posting a new "chat message" to a page, is that you should append them onto the end of the existing "chat messages" of everyone else. If you put it anywhere else, another editor will revert your edit. This rule by itself is enough to allow for a functional chat system/forum with a complete logical "conversation" history! Same idea here—just that it's the database-node software that's automatically "reverting" bad edits. In all other senses, it's just a regular distributed file.)
Git is a DAG where each child of a hashed node is equally valid. For transactions and assets, what we need is a linked list (a chain) and therefore, some rule like "the longest chain is the TRUE chain".
Blockchains are also DAGs. This is the basis of the 51% attack. It is completely possible for a blockchains to fork. The consensus algorithm is how a particular branch is chosen as the winner. But the reason you need them is because blocks fire DAGs.
Get the actors together to standardize a format for the messages everyone's emitting, and then make some software (one shared implementation, many different ones, doesn't matter) to parse the log stream into a point-in-time representation you can load into an analytics tool.
Seems to me that that sort of technology would fit this use-case a lot more closely than an Actual Blockchain™ would.