Byzantine fault tolerance

In a system hosting shared mutable data, we may allow any participant to mutate data. However, there should be some limits to what participants can do.
In CRDTs, usually a machine is identified using some random identifier or one that is uniquely drawn from the system in some way. Conventional CRDTs are not byzantine fault tolerant in that any peer can use any identifier, including those of others.

Attack vectors

- Denial of service
    - Sending data to a topic will lead to an epidemic broadcast. i.e. work of unit 1 translates to work of unit ep(|T|), where |T| is the popularity of the topic, and ep a function that estimates the costs for epidemic broadcast for a given size.
    CM:
        - Proof of work - Size:
            - proportional to the size of the topic? Sounds terrible TBH
            - dependent on the rate of events? i.e. there is a rate of progress for a topic. The maximal speed with which any peer can produce updates (without PoW) is linked to this rate (total? per participant? average? max?)
        - Proof of stake-ish? amount of data that can be added for free (without PoW) should be less than the stake. Stake could be:
            - ratio of membership time. (divide your membership period by the sum of all membership periods; this could be considered your stake. Your edit-count divided by the total number of edits shouldn't exceed this; otherwise => PoW). Sibylline lurkers are still a significant danger.
            - Number of edits that are part of the consensus
        - Rate limiting to average rate?
    - Overloading a topic: Sending many updates to a topic brings the risk of making that topic inaccessible or useless, as the useful/valid data is drowned out by useless/invalid data.
    CM
- Deleting data: Users may delete the data of other users    
CM: Use subjective-tombstoning (marking the data as deleted by a given user) instead of deletion-replication (broadcasting the deletion in a way that the data is actually deleted)
- Sybil attack