Suggested hook points for trustless network consensus algorithm.

[brentarias]

The Merkle-CRDT technical paper suggests a Merkle-DAG is suited for a trustless network (and thus presumes a consensus algorithm) and a CRDT typically presumes a trusted network (and thus opts for inherent CRDT type instance convergence capabilities, in lieu of a consensus algorithm).

So when combined, a Merkle-CRDT presumably needs an additional consensus layer when deployed on a trustless or semi-trusted network to safeguard against bad actors. What hook points would you recommend be explored for that purpose? Conceptually, this is a pre-commit validation step which blacklists an entire IPFS node which has submitted a nefarious DAG branch, or at least blacklists the CID of the DAG branch so submitted.

I think it would be helpful to update the project README with comments about "considerations for a trustless network". Similarly I would like to know if the technical paper's allegation of Merkle-DAG reliance on a consensus mechanism is for go-ds-crdt (1) fulfilled with a particular algorithm, and which one if the answer is "yes" or otherwise (2) if go-ds-crdt might simply be leveraging "inherent CRDT type instance convergence" capabilities in lieu of a consensus mechanism.

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[hsanjuan]

Similarly I would like to know if the technical paper's allegation of Merkle-DAG reliance on a consensus mechanism is for go-ds-crdt (1) fulfilled with a particular algorithm, and which one if the answer is "yes" or otherwise (2) if go-ds-crdt might simply be leveraging "inherent CRDT type instance convergence" capabilities in lieu of a consensus mechanism.

go-ds-crdt does not have an integrated consensus layer (case 2).

With CRDTs, depending on what you are doing, you can perform checks on updates and put rules that define what is a "valid" update, but this has some limits in the default framework. For example, by default, Merkle-CRDTs are supposed to ensure convergence with network partitions of arbitrary duration. That means that you may receive updates on top of any DAG node (not necessarily the "current" root) any time. Thus you must keep memory of the full Merkle-DAG in case such thing happens. There's no concept of epoch, or time for that matter, so that participating peers can agree on what is before/after other than causal updates on the same branch... one can see that if you are trying to implement a ledger in this framework, you cannot deal with the double-spending problem that requires proper ordering of everything.

Otherwise said, you cannot have a rule saying: "you are only allowed to update the DAG from this particular root" (or "reject updates that used information that was not up to date". Thus you need a global clock and this is were I think consensus is needed.

If you have an agreed-upon clock you can now do everything a blockchain does because you've kind of become a blockchain. You can use it for example to forget history by agreeing on a "state snapshot" that is valid at a given time. Depending on what you are doing you may not need to use the consensus constantly but perhaps only occasionally, but still. If you need byzantine properties etc. you are pretty much going to end up having an actual blockchain. Note that while you can make that updates follow certain rules, there's always the possibility that an attacker issues many valid updates, something which is difficult to limit without a global view, global counter, global agreement.

[brentarias]

In the context of speculating the use of Merkle-CRDT, or its underlying premise(s), for creating a ledger or blockchain...of what value might there be in it (viz. key-value pairs) carrying transactions via the UTXO-paradigm, rather than account-balance paradigm? How much technical burden would the UTXO-paradigm resolve? For example, to what extent might that resolve the non-commutative nature of (financial) transactions? To what extent, if any, would that reduce the need for an "agreed-upon clock"? For the sake of speculation, these questions are temporarily suspending the broader concerns of consensus on a trustless network.

[hsanjuan]

With UTXO is the same right? You need the notion of what happened before so that you know how much is unspent.