chronological, 
Event sourcing and CRDTs as data storage
I think event sourcing and CRDTs can be combined to provide an alternative to the blockchain for general purpose 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.
Yjs is an efficient CRDT implementation in JavaScript.
An explanation of event sourcing
CRDTs can be simple
任意のテキストのCRDTを使用すると、任意のテキストフィールドへの2つの独立した変更をマージできるため、gitマージプロセスは必要ありません。
この記事では、任意のテキストのCRDTの速度について説明します https://josephg.com/blog/crdts-go-brrr/
これは、Googleドキュメントの同期やEtherpadに少し似ています。 2人のユーザーが同じドキュメントを変更でき、問題なくマージできます。これは、レコード内のすべてのフィールドに対して実行できます。したがって、多くのCRDTで表される0ooのカテゴリまたはアイデアを持つことができます。
With CRDTs for arbitrary text you can merge two independent changes to arbitrary text fields so no git merge process is necessary.
This article describes how fast CRDTs for arbitrary text can be https://josephg.com/blog/crdts-go-brrr/
It's a bit like Google docs synchronisation or Etherpad. Two users can modify the same document and they can be merged without issue. We can do this for every field in a record. So we could have 0oo category or idea represented by many CRDTs.
イベントソーシングシステムの逆転は、データを削減するときにエントリを単に除外することです
各変更は、イベントの履歴内の個別のバージョンです。履歴に対してリダクションを実行して、最終的な値を取得します。
詐欺や返金を排除するには、悪い取引を排除するだけです。もちろん、他のユーザーがあなたの排除を信頼する必要があり、それが記録システムになります。
現在の状態/値= reduce（これまでのすべてのイベント-除外されたイベントまたは除外されたアクター）
ユーザーが同じ一連のイベントを信頼している限り、ユーザーは同じ回答を得ることができます。ここで、答えはデータベース内のフィールドの現在の値、または元帳内の誰かのアカウントの残高です。
支払いを受けたサービスを受けられなかったなど、取引に異議を唱えることができれば、支払いは尊重されなかったと言えます。そして、他の人に私を信頼してもらうことができれば、私のお金は支出のために返還されます。私はただ私を信頼するために他の人が必要です。
A reversal in an event sourcing system is to simply exclude an entry when reducing the data
Each change is a separate version in the history of events. You run a reduction over the history to get a final value.
To exclude a scam or return money you just exclude the bad transactions..Of course you need other users to trust your exclusion then that becomes the system of record.
Current state/value = reduce(all events so far - excluded events or excluded actors)
As long as users are trusting the same set of events the users will get the same answers. Where answer is the current value of a field in the database or the balance of someone's account in the ledger.
If I can dispute a transaction - like I didn't receive services paid for I can say that my payment was not honoured and then if I can get others to trust me, my money is returned for spending. I just need others to trust me.
いくつかの中央当局への信頼が関係しているようです。仲裁人がいて、私たちは再び裁かれ、だまされました。それで十分でした。
It seems trust in some central authority is involved. There would be an arbitrator, and we would get judged again and cheated on. We had enough of that.
中央当局の信頼はありません。各ユーザーのイベントを個別に信頼する必要があります。
信頼できないユーザーを見つけた場合は、そのユーザーを禁止すると、今後および過去のトランザクションが無視されます。
誰もが自分の禁止リストを維持する必要があります。
Theres no trust of central authority. You have to trust each user's events individually.
If you see a user you dont trust, you ban them and that then ignores their transactions going forward AND historically.
Everybody has to maintain their own ban list.