# Ceramic Network - Anchoring and Conflict Resolution

https://developers.ceramic.network/learn/advanced/consensus/

## Anchoring

1. Blockchain is used as a "world clock" (timestamps) to determine which commit was first in case of merge
2. Each user's stream can create a special "anchor" commit
3. Ceramic is packing anchor commits into the Merkle tree
4. Twice per day (current settings) Merkle root is published to the Ethereum Mainnet blockchain - "Anchoring TX"
5. Ceramic network provider is paying for the gas
6. ??? Ceramic network updates the stream with the blockchain TX ID of the anchor TX and stream status is now Anchored
7. ??? Where Merkle tree data is stored? i.e. how Merkle proof is generated when CR compares 2 anchors?


## Conflict resoultion (CR) algorithm

1. If there are anchors in both branches -> select one with the earliest anchor (by time)
2. If both anchors are in the SAME blockchain block -> ??? maybe Ceramic will select one that is earlier in the Merkle tree ???
3. If there is anchor only in one branch -> select it
4. If there are no anchors in both branches -> longest branch is selected (see "Long tail attack" below)
5. In case lenght of branches is equal -> branch is selected randomly, but deterministically on all nodes.

## Design flaws

1 - Currently multi-writer logs are disabled in Ceramic (from their Discord):

> Currently, native multi-writer streams are not supported. A solution that I used in a hackathon was to make the controller of the stream a DID NFT from an ERC-1155 which allows you to create multiple tokens with the same token id. You just give a token to whomever you want to have access.

2 - Lost writes:

> "If there are conflicting unanchored branches that have the same length, then the system picks the winning log arbtrarily, but deterministically, to ensure that all nodes come to agreement on the same log, even if there is no good information available to use to decide which to prefer. This can result writes being lost in certain rare instances where there are conflicting updates published within a few seconds of each other."

3 - Lost writes:

> "Ceramic Streams today are updated using a read-modify-write approach. This means that write conflicts can result in writes being lost in some specific scenarios. Consider an app that wants to add a new entry to an array contained within a TileDocument stream."
...
"This behavior is usually not a problem for Ceramic, since most Ceramic streams are controlled by a single end user, who will not be making multiple simultaneous updates to a given stream at the same time. This does mean, however, that Ceramic is not well suited at the moment to applications that depend on allowing multiple end users to update a single stream simultaneously."

4 - No CRDTs currently:

> "In the future, Ceramic plans to offer StreamTypes that use CRDTs to encode updates to Streams, which will allow simultaneous updates to be merged automatically without conflict. Such plans, however, are currently still in the research phase"

5 - Anchor commits in one blockchain block can not be easily compared with other anchors in the same block

If 2 anchors ARE in the same blockchain block (currently 1 TXs per 12 hours), then you CAN NOT rely on that to compare who was earlier. Order of anchors in the Merkle tree is determined by how Ceramic's anchoring service saw these anchors (i.e. who was first, who was second).

*This can be fixed by increasing number of blockchain TXs per day. However this is costly.*

## Possible attacks

1 - Data witholding attack:

> "A user could author a commit, get it anchored, but not tell anyone about it. Then in the future they could reveal this secret commit and revert the state of the stream to what it was at the time of that secret write.
>
> Most of the time this isn't a problem because streams are generally owned by the end user, and a user has no incentive to mess with the history of their own streams. Once you start trading ownership of streams, however, this means that if someone buys control of a stream from the previous controller, the new controller needs to trust that the old controller isn't sitting on any secret commits, otherwise the old controller could re-assert control of the stream at any point"

This can be fixed by settings "settlement lockup period", i.e. anchors older than N minutes should be discarded. Still that makes Anchoring even less useful.

2 - Long tail attack:

To make your branch win during the conflict resoultion you can push 100500 records to make it longer.

3 - Censorship attack:

Ceramic provider is able to never post your anchor commit to the blockchain. This can be fixed only by using YOUR own anchoring service. However in this case dispute resoulution alg should work with many anchoring services. And it looks like that is not an easy task.

4 - Anchor commits reordering attack:

Order of N anchor commits in a single merkle tree (in one blockchain block or TX) is determined by the Ceramic network anchoring service - merkle tree generation code. This can be hacked or tweeked.

## Resume

Current implementation of Ceramic Network's **Anchoring** and **Conflict Resolution** mechanisms won't help to merge conflicting changes. It only allows to choose deterministically which commits to **throw away**.

**Conflict Resolution** mechanism is prone to different attacks and has many flaws.