ERA: Epoch-Resolved Arbitration for Duelling Admins in Group Management CRDTs

Conflict-Free Replicated Data Types (CRDTs) are used in a range of fields for their coordination-free replication with strong eventual consistency. By prioritising availability over consistency under partition, nodes accumulate events in different orders, and rely on an associative, commutative and idempotent merge function to present a materialised view of the CRDT. Under some circumstances, the state of the materialised view over time can appear to ‘‘roll back’’ previously applied events. When the materialised view is used to manage group permissions such as ones found in instant messaging applications, this can lead to surprising behaviour. This can occur when there are multiple concurrent events, such as in the Duelling Admins problem where two equally permissioned admins concurrently revoke each other’s permissions. Who wins? This article argues that a Byzantine admin can exploit concurrency to win the duel. As a result, an external arbiter is required to arbitrate an immutable happens-before relation between concurrent events. Arbitration occurs asynchronously in batches via optional ‘’epoch events’’, preserving availability. This introduces a bounded total order within epochs, and the resulting ‘‘finality’’ improves on the level of consistency CRDTs can provide.

💡 Research Summary

The paper addresses a subtle but critical safety issue that arises when Conflict‑Free Replicated Data Types (CRDTs) are used to manage group permissions: the “Duelling Admins” problem. In a CRDT, updates are merged using an associative, commutative, and idempotent function, which guarantees eventual convergence even under network partitions. However, non‑monotonic operations such as revoking an admin’s rights (demote) can cause previously applied events to be rolled back when two admins concurrently revoke each other. Existing systems like Keyhive and Matrix encode causal history in a hash‑directed‑acyclic‑graph (hash‑DAG) and use version vectors, but they remain vulnerable to Byzantine behaviours: equivocation (same event ID with different payloads) and backdating (inserting a past‑dated event to undo a revocation).

The authors formalise two safety and liveness properties: P1 – Authorization Safety (no user can execute an operation they lack permission for) and P2 – Availability (authorized users must be able to act even when isolated). They evaluate two conventional resolution strategies. User‑based ordering (seniority ranking) gives a deterministic winner by depth and hash order, yet it can be subverted by self‑demotion followed by a backdated revocation, breaking P1. Event‑based ordering (timestamp or event‑ID) allows both admins to “win” equally, but a malicious admin can consistently choose IDs that force perpetual roll‑backs. Consensus‑based approaches (majority voting, PoW, PoS) are either vulnerable to Sybil attacks or ill‑suited to CRDTs, which lack economic incentives.

To overcome these limitations the paper introduces a “finality node” – a neutral participant that periodically emits “epoch events”. An epoch event lists the current sources (leaves) of the hash‑DAG; these sources define a closed past that cannot be altered without detection. Events are then ordered first by epoch number, establishing a bounded total order inside each epoch. Events not yet assigned to an epoch remain in a pending epoch and are processed only after all earlier epochs have been finalized, regardless of their internal causal links. Epochs can be triggered automatically when a pending epoch reaches a size threshold or on‑demand for non‑monotonic operations like demote. Because epoch events themselves are part of the hash‑DAG and are assumed not to be backdated, they provide a form of “finality” – once an event is placed in an epoch, it cannot be rolled back by later concurrent events.

The authors argue that this mechanism satisfies both P1 and P2: safety is restored because a Byzantine admin can no longer retroactively cancel a revocation, and availability is preserved because epochs are generated asynchronously and only when needed, avoiding a global consensus round. They also discuss broader applicability: any CRDT that includes non‑monotonic updates (e.g., collaborative editing deletions, distributed file‑system permission changes) can benefit from epoch‑based arbitration without centralising authority.

In summary, the ERA (Epoch‑Resolved Arbitration) design offers a pragmatic middle ground: it introduces a lightweight, third‑party arbiter that imposes a deterministic ordering on concurrent, conflicting admin actions while retaining the core CRDT guarantees of eventual consistency and high availability. This resolves the duelling admins dilemma, mitigates backdating attacks, and extends the notion of finality to a broader class of replicated data structures.