Event sourcing and CRDTs as data storage

I'm not particularly fond of the block chain. It functions as a distributed ledger but I think there is a simpler combination of technologies that provides a slightly different architecture for general purpose data storage.

One problem with block chain is the centralisation of miners and the proof of work is inefficient.

If you disagree with the network, you have to be a miner to change the course of transactions on the network. There are no chargebacks on Bitcoin. You cannot get money transferred to the wrong address or reverse stolen money.

You cannot 'disagree' or 'vote against' other actors in the system. Also a problem with bitcoin is the landed wealth problem. Essentially early adopters or early adopters in the case of commercial coins get the lion's share of wealth in any cryptocurrency. It's inherently unfair, like aristocratic wealth from birth. Nobody earns their bitcoins.

So this idea is to represent a ledger of transactions as both as a CRDT so that arbitrary transactions can be combined in any order from any peer. The second is that events are event sourced so the new state of the system is the product of applying a reduction function over all past events.

To disagree with the system state, you simply exclude or create reversing events to the transaction stream. This undoes previous transactions.

So if you used this event sourcing with CRDTs to indicate ownership, a community of people would have to mark other sources of information as trusted to get the final decision of the network.

This system also tracks debts automatically as balances may not reconcile. (If people decide to reverse a transaction en masse, the reversed transactions could cause a negative balance elsewhere in the system)

Event sourcing helps produce a final state in a simple CRUD app. Two users on a P2P network can edit the same field in a record and this will produce two different versions of the data. They are mergeable through CRDTs merge operator and event sourced reduction.