pith. sign in

arxiv: 2601.22963 · v2 · submitted 2026-01-30 · 💻 cs.DC

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

Kegan Dougal This is my paper

Pith reviewed 2026-05-16 09:28 UTC · model grok-4.3

classification 💻 cs.DC
keywords CRDTgroup managementduelling adminsepoch eventsarbitrationfinalityavailabilityconsistency
0
0 comments X p. Extension

The pith

CRDTs for group permissions use optional epoch events to resolve concurrent admin conflicts with added finality while keeping availability.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows that CRDTs for managing group permissions can produce rollback behavior when multiple admins issue conflicting actions at the same time. In the duelling admins case, two equally privileged admins can revoke each other concurrently, and a malicious actor can exploit the lack of ordering to influence the outcome. The ERA method introduces optional epoch events that collect and order these events in batches without requiring peers to coordinate in real time. This creates a bounded total order inside each epoch and supplies finality on the resulting state. The approach matters for applications such as instant messaging because it reduces surprising permission changes while still letting replicas stay available during network partitions.

Core claim

Our ERA proposal arbitrates 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.

What carries the argument

Optional epoch events that provide asynchronous batch arbitration and impose a bounded total order on concurrent operations.

If this is right

  • Concurrent admin revocations in group CRDTs receive a bounded ordering that reduces rollback surprises.
  • The system continues to accept updates from any replica without waiting for global consensus.
  • Byzantine exploitation of concurrency is limited because epoch events supply an external ordering decision.
  • Permission states in the materialised view gain finality within each epoch while merge remains associative, commutative and idempotent.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Existing CRDT libraries for collaborative tools could adopt epoch events to handle permission conflicts without redesigning the core merge logic.
  • The batch-arbitration pattern may extend to other CRDT applications that manage shared access rights, such as document editing or database views.
  • Fully decentralized deployments would need a practical way to generate and distribute epoch events without introducing a single point of failure.

Load-bearing premise

An external arbiter introduced through epoch events can order concurrent events without violating the coordination-free and availability guarantees that define CRDTs.

What would settle it

A demonstration that epoch events force replicas to block or lose availability during a network partition would show the approach violates CRDT properties.

Figures

Figures reproduced from arXiv: 2601.22963 by Kegan Dougal.

Figure 1
Figure 1. Figure 1: DAGs of causal histories demonstrating detectable vs undetectable backdating. Each event points to their causal predecessor. The highlighted event is an attempt to backdate. 3 Problem Statement Consider a hash DAG of membership events. Each member can have one of the following roles: 1. Reader: The member can read events in the DAG. This is the lowest level role. 2. Writer: The member can write events into… view at source ↗
Figure 2
Figure 2. Figure 2: The duelling admins problem. Which user remains an Admin depends on how demote events are sorted. Sorting by user centralises authority. Sorting by event ID causes repeated rollbacks. 3.2 Design Considerations Firstly, the protocol cannot forbid equal-permissioned users from demoting each other because the user who first gained that permission can backdate, as shown in [PITH_FULL_IMAGE:figures/full_fig_p0… view at source ↗
Figure 3
Figure 3. Figure 3: Even if equal-permissioned roles are forbidden from demoting each other, backdating can subvert this. demote(𝑎, 𝑎, Writer) executes first, meaning 𝑎 is no longer authorised to promote(𝑎, 𝑏, Admin). Seniority ranking [19] formalises this and is defined as [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Admin operations are ordered before Writer op￾erations. As a result, write(𝑏) is not authorised because 𝑏 is now a Reader. join(𝑎) join(𝑏) promote(𝑎, 𝑏, Writer) demote(𝒂, 𝒃, Reader) demote(𝑎, 𝑎, Reader) write(𝑏) × 𝑎 = Admin 𝑎 = Admin, 𝑏 = Reader 𝑎 = Admin, 𝑏 = Writer 𝑎 = Admin, 𝑏 = Reader 𝑎 = Reader, 𝑏 = Reader 𝑎 = Reader, 𝑏 = Reader [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: User 𝑎 backdated event demote(𝑎, 𝑏, Reader) de￾spite not being authorised to demote anymore. Whether it executes before or after demote(𝑎, 𝑎, Reader) depends solely on attacker-controlled data. This breaks safety property P1. The self-demotion and duelling admins problem highlight a tension between the two possible ways events sent by the same permission level can be ordered without consensus. User-based o… view at source ↗
Figure 7
Figure 7. Figure 7: The partial execution order for events in [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figure 6
Figure 6. Figure 6: Epochs define a closed past [7] to prevent backdat￾ing. Event 𝑏3 is in a pending epoch, despite it pointing to an earlier event in a previous epoch. 5 Discussion The motivation behind epochs is to achieve finality for CRDT state in order to meet safety property P1. The duelling admins problem is a manifestation of the lack of finality in CRDT state. This means epochs only need to be sent in response to non… view at source ↗
Figure 8
Figure 8. Figure 8: Concurrent epochs can cause history to determin￾istically re-order events 𝑑 and 𝑒. If epoch1 < epoch2 then {𝑎, 𝑏, 𝑐, 𝑒} → 𝑑. If epoch2 < epoch1 then {𝑎, 𝑏, 𝑐, 𝑑} → 𝑒. rewritten as there is no guarantee that each node will agree on which events are in which epoch, but it does prevent a malicious finality node from manipulating CRDT state to its advantage. An additional approach is to encrypt the underlying … view at source ↗
read the original abstract

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, peers 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. Rollbacks 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? Different solutions and their trade-offs are examined. A Byzantine admin can exploit concurrency to influence the duel, whereby we argue that an external arbiter is required to order concurrent events. Our ERA proposal arbitrates 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 1 minor

Summary. The paper examines the Duelling Admins problem in CRDT-based group management, where concurrent admin actions can cause rollbacks in permission states. It proposes the ERA mechanism, which introduces optional epoch events to arbitrate such conflicts asynchronously in batches. This approach aims to preserve availability while providing a bounded total order within epochs, thereby improving the finality and consistency level beyond standard CRDT guarantees.

Significance. If successfully implemented with decentralized epoch generation, ERA could enhance the usability of CRDTs in permission-sensitive applications like instant messaging by reducing surprising rollback behaviors without introducing coordination overhead. The approach addresses a practical limitation in strong eventual consistency for group management scenarios.

major comments (1)
  1. Abstract: The central claim that optional epoch events can be injected asynchronously to impose a bounded total order while preserving coordination-free CRDT properties is load-bearing but unsupported; the manuscript supplies no algorithm, derivation, or proof showing that epoch generation itself can be expressed as an associative, commutative, and idempotent operation that any replica can emit independently.
minor comments (1)
  1. The abstract references a 'Byzantine admin' threat model without defining its scope or how it interacts with epoch events; this should be clarified for precision.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review and the recommendation for major revision. We appreciate the focus on the central claim regarding epoch events and will strengthen the manuscript to address this point explicitly.

read point-by-point responses

  1. Referee: [—] Abstract: The central claim that optional epoch events can be injected asynchronously to impose a bounded total order while preserving coordination-free CRDT properties is load-bearing but unsupported; the manuscript supplies no algorithm, derivation, or proof showing that epoch generation itself can be expressed as an associative, commutative, and idempotent operation that any replica can emit independently.

    Authors: We agree that the abstract's claim requires more explicit support in the manuscript to be fully substantiated. The full paper (Section 3) defines epoch generation as an independent local operation triggered by detection of duelling admin events, with the merge function specified as taking the maximum epoch identifier (with replica-ID tie-breaking). This construction is associative, commutative, and idempotent by design, allowing any replica to emit epochs without coordination. We will add a dedicated algorithm listing, a short derivation, and a proof of the CRDT properties (in a new subsection or appendix) to make this rigorous and directly address the concern. revision: yes

Circularity Check

0 steps flagged

No circularity: new epoch mechanism introduced without reduction to inputs or self-citations

full rationale

The paper presents a design proposal for ERA using optional epoch events to batch-arbitrate concurrent admin actions in group CRDTs. The abstract and description frame this as an additive construct that preserves availability and coordination freedom while adding bounded ordering inside epochs. No equations, fitted parameters, or derivations are shown that equate a 'prediction' to its own inputs by construction. No self-citation chain or uniqueness theorem is invoked to force the choice. The central claim rests on the explicit introduction of epoch events as a new operation type rather than any self-referential or fitted reduction. This matches the default expectation of a non-circular design paper.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

Central claim rests on standard CRDT merge properties (associativity, commutativity, idempotence) and introduces epoch events as a new arbitration construct; no free parameters or invented entities with independent evidence are described.

axioms (1)
  • standard math CRDT merge functions must be associative, commutative, and idempotent to guarantee strong eventual consistency
    Stated explicitly in the abstract as the foundation for CRDT behavior
invented entities (1)
  • epoch events no independent evidence
    purpose: asynchronous batch arbitration of concurrent admin actions
    New construct introduced by the proposal to impose bounded total order within epochs

pith-pipeline@v0.9.0 · 5503 in / 1236 out tokens · 22206 ms · 2026-05-16T09:28:14.624908+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

28 extracted references · 28 canonical work pages · 1 internal anchor

  1. [1]

    d.].Certificate Transparency: The list of current, usable logs.https: //certificate.transparency.dev/logs/

    [n. d.].Certificate Transparency: The list of current, usable logs.https: //certificate.transparency.dev/logs/

    work page

  2. [2]

    d.].Developing with Riak KV Data Types.https://docs.riak.com/ riak/kv/2.2.3/developing/data-types/ ERA: Epoch-Resolved Arbitration for Duelling Admins in Group Management CRDTs

    [n. d.].Developing with Riak KV Data Types.https://docs.riak.com/ riak/kv/2.2.3/developing/data-types/ ERA: Epoch-Resolved Arbitration for Duelling Admins in Group Management CRDTs

    work page

  3. [3]

    d.].Distributed Data - Akka Documentation.https://doc.akka.io/ libraries/akka-core/2.5/distributed-data.html?language=scala

    [n. d.].Distributed Data - Akka Documentation.https://doc.akka.io/ libraries/akka-core/2.5/distributed-data.html?language=scala

    work page

  4. [4]

    Matrix Specification v1.17.https://spec.matrix.org/v1.17/

    2025. Matrix Specification v1.17.https://spec.matrix.org/v1.17/

    work page 2025

  5. [5]

    Matrix Specification v1.17: Room Version 12.https://spec.matrix

    2026. Matrix Specification v1.17: Room Version 12.https://spec.matrix. org/v1.17/rooms/v12/#state-resolution

    work page 2026

  6. [6]

    Paulo Sérgio Almeida. 2024. Approaches to Conflict-free Replicated Data Types.ACM Comput. Surv.57, 2, Article 51 (Nov. 2024), 36 pages. doi:10.1145/3695249

    work page doi:10.1145/3695249 2024

  7. [7]

    Paulo Sérgio Almeida. 2024. A Framework for Consistency Models in Distributed Systems. arXiv:2411.16355 [cs.DC]https://arxiv.org/abs/ 2411.16355

    work page arXiv 2024

  8. [8]

    Paulo Sérgio Almeida and Ehud Shapiro. 2025. The Blocklace: A Byzantine-repelling and Universal Conflict-free Replicated Data Type. arXiv:2402.08068 [cs.DC]https://arxiv.org/abs/2402.08068

    work page arXiv 2025

  9. [9]

    Keyhive Authors. [n. d.].Keyhive Group Membership De- sign.https://github.com/inkandswitch/keyhive/blob/keyhive-wasm/ 0.0.0-alpha.54/design/group_membership.md

    work page

  10. [10]

    Eric Brewer. 2012. CAP Twelve years later: How the "Rules" have Changed.Computer45 (02 2012), 23–29. doi:10.1109/MC.2012.37

    work page doi:10.1109/mc.2012.37 2012

  11. [11]

    Vitalik Buterin, Daniël Reijsbergen, Stefanos Leonardos, and Georgios Piliouras. 2019. Incentives in Ethereum’s Hybrid Casper Protocol. In 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). 236–244. doi:10.1109/BLOC.2019.8751241

    work page doi:10.1109/bloc.2019.8751241 2019

  12. [12]

    Tom Celig, Tim Ockenga, and Detlef Schoder. 2025. Distributional equality in Ethereum? On-chain analysis of Ether supply distribution and supply dynamics.Humanities and Social Sciences Communications 12 (03 2025). doi:10.1057/s41599-025-04728-9

    work page doi:10.1057/s41599-025-04728-9 2025

  13. [13]

    Marcus Dansarie. [n. d.].Roughtime — datatracker.ietf.org.https: //datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/

    work page

  14. [14]

    John R. Douceur. 2002. The Sybil Attack. InRevised Papers from the First International Workshop on Peer-to-Peer Systems (IPTPS ’01). Springer-Verlag, Berlin, Heidelberg, 251–260

    work page 2002

  15. [15]

    Florian Jacob, Saskia Bayreuther, and Hannes Hartenstein. 2021. On Conflict-Free Replicated Data Types and Equivocation in Byzantine Setups. arXiv:2109.10554 [cs.DC]https://arxiv.org/abs/2109.10554

    work page arXiv 2021

  16. [16]

    Florian Jacob, Luca Becker, Jan Grashöfer, and Hannes Hartenstein

    work page

  17. [17]

    InProceedings of the 25th ACM Symposium on Access Control Models and Technologies(Barcelona, Spain)(SACMAT ’20)

    Matrix Decomposition: Analysis of an Access Control Approach on Transaction-based DAGs without Finality. InProceedings of the 25th ACM Symposium on Access Control Models and Technologies(Barcelona, Spain)(SACMAT ’20). Association for Computing Machinery, New York, NY, USA, 81–92. doi:10.1145/3381991.3395399

    work page doi:10.1145/3381991.3395399

  18. [18]

    Florian Jacob and Hannes Hartenstein. 2024. Logical Clocks and Mono- tonicity for Byzantine-Tolerant Replicated Data Types. InProceedings of the 11th Workshop on Principles and Practice of Consistency for Dis- tributed Data(Athens, Greece)(PaPoC ’24). Association for Computing Machinery, New York, NY, USA, 37–43. doi:10.1145/3642976.3653034

    work page doi:10.1145/3642976.3653034 2024

  19. [19]

    Florian Jacob and Hannes Hartenstein. 2025. To the Best of Knowledge and Belief: On Eventually Consistent Access Control. InProceedings of the Fifteenth ACM Conference on Data and Application Security and Privacy(Pittsburgh, PA, USA)(CODASPY ’25). Association for Computing Machinery, New York, NY, USA, 107–118. doi:10.1145/ 3714393.3726520

    work page arXiv 2025

  20. [20]

    Martin Kleppmann. [n. d.].Keynote: Byzantine Eventual Consistency and Local-First Access Control.https://martin.kleppmann.com/2025/ 03/31/papoc-keynote-byzantine.html

    work page 2025

  21. [21]

    Martin Kleppmann. 2025. Byzantine eventual consistency and local- first access control.https://speakerdeck.com/ept/byzantine-eventual- consistency-and-local-first-access-control?slide=69

    work page 2025

  22. [22]

    Martin Kleppmann and Heidi Howard. 2020. Byzantine Eventual Consistency and the Fundamental Limits of Peer-to-Peer Databases. arXiv:2012.00472 [cs.DC]https://arxiv.org/abs/2012.00472

    work page arXiv 2020

  23. [23]

    Martin Kleppmann, Adam Wiggins, Peter Van Hardenberg, and Mark McGranaghan. 2019. Local-first software: you own your data, in spite of the cloud. InProceedings of the 2019 ACM SIGPLAN In- ternational Symposium on New Ideas, New Paradigms, and Reflec- tions on Programming and Software. ACM, Athens Greece, 154–178. doi:10.1145/3359591.3359737

    work page doi:10.1145/3359591.3359737 2019

  24. [24]

    Satoshi Nakamoto. 2009. Bitcoin: A Peer-to-Peer Electronic Cash System. (May 2009).http://www.bitcoin.org/bitcoin.pdf

    work page 2009

  25. [25]

    Nuno Preguiça, Carlos Baquero, Paulo Sérgio Almeida, Victor Fonte, and Ricardo Gonçalves. 2010. Dotted Version Vectors: Logical Clocks for Optimistic Replication. arXiv:1011.5808 [cs.DC]https://arxiv.org/ abs/1011.5808

    work page internal anchor Pith review Pith/arXiv arXiv 2010

  26. [26]

    Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski

    work page

  27. [27]

    InStabilization, Safety, and Security of Distributed Systems, Xavier Défago, Franck Petit, and Vincent Villain (Eds.)

    Conflict-Free Replicated Data Types. InStabilization, Safety, and Security of Distributed Systems, Xavier Défago, Franck Petit, and Vincent Villain (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 386–400

    work page

  28. [28]

    Brooklyn Zelenka and Alex Good. [n. d.].Keyhive: Local-first Access Control.https://www.inkandswitch.com/keyhive/notebook/

    work page