Event sourcing and CRDTs as data storage

+1  

I think event sourcing and CRDTs can be combined to provide an alternative to the blockchain for general purpose data storage

YAML 想法

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.

chronological,





(別通知) (可選) 請,登錄

使用用於任意文本的 CRDT,您可以將兩個獨立的更改合併到任意文本字段,因此不需要 git 合併過程。

這篇文章描述了任意文本的 CRDTs 的速度有多快 https://josephg.com/blog/crdts-go-brrr/

這有點像 Google 文檔同步或 Etherpad。兩個用戶可以修改同一個文檔,並且可以毫無問題地合併它們。我們可以對記錄中的每個字段執行此操作。所以我們可以有許多 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.


事件溯源系統的一個逆轉是在減少數據時簡單地排除一個條目

每個更改都是事件歷史中的一個單獨版本。您對歷史進行歸約以獲得最終值。

要排除騙局或退款,您只需排除不良交易。當然,您需要其他用戶信任您的排除,然後這將成爲記錄系統。

當前狀態/值 = 減少(到目前爲止的所有事件 - 排除的事件或排除的參與者)

只要用戶信任同一組事件,用戶就會得到相同的答案。其中 answer 是數據庫中某個字段的當前值或分類帳中某人帳戶的餘額。

如果我可以對交易提出異議——比如我沒有收到支付的服務,我可以說我的付款沒有兌現,然後如果我能讓別人信任我,我的錢就會被退回。我只需要別人信任我。

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.