Les CRDT sont des types de données qui supporte de manière intrinsèque les critères de convergence (Strong Eventual Consistency) et de cohérence pipeline (qui est un compromis entre la validité et la Localité d'état).

Pour y parvenir, un type de donnée dit CRDT doit proposer une bibliothèque d'opérations qui sont commutatives l'une à l'autre. Ainsi pour deux suites d'opérations $S$ et $S'$, soit $L$ l'ensemble contenant tous les termes de $S$ et $L'$ l'ensemble contenant tous les termes de $S'$. Si $L$ et $L'$ sont indiscernables, alors les résultats de $S$ et $S'$ l'est aussi. [REF CRDT]
 
Ces types de données présentent un très grand intérêt pour le problème de l'édition collaborative. En effet, ils permettent de mettre en place des approches qui sont dites local-first. C'est à dire que les modifications sont dans un premier temps appliquées localement au client, pour ensuite être éventuellement fusionnées, sans avoir à gérer d'hypothétiques conflits (puisque le type de donnée ne le permet pas).

Cette approche est déjà utilisée par certains projets déjà en production, notamment à travers le protocole YATA [REF YATA] qui trouve son implémentation dans l'application Yjs. Yjs est une application de prise de note, d'organisation et de productivité utilisant des CRDT, ce qui lui permet d'être résilient aux pannes réseaux et de permettre une synchronisation entre plusieurs terminaux pour un seul client sans utiliser d'entité centrale. Cette solution apporte toutefois une limite, qui est le manque de clarté dans l'expérience utilisateur sur ce qui est synchronisé et ce qui ne l'est pas. Ce comportement est toute fois intrinsèque au design de l'application est relève d'un compromis technique.

L'usage des CRDT dans Yjs est toutefois assez limité, puisque proposant une application "un seul utilisateur". Et pour cause, l'ajout de plusieurs utilisateurs introduit une nouvelle problématique qui est celle des droits d'accès et d'édition.
Dans l'approche d'Yjs, rien de ce que peut soumettre l'utilisateur ne peut provoquer d'état illégal. Puisque par définition TOUT est accepté. De plus, aucun comportement arbitraire et malveillant n'a à être envisagé puisqu'une nouvelle fois, il n'y a pas de notion de malveillance.

Mais si Yjs fait ce choix, c'est parce que les CRDT passe très mal l'épreuve du problème des généraux byzantins. Le problème des généraux byzantin est un problème connu en algorithmie distribuée. Il vise à introduire dans notre système des noeuds aux comportements arbitraires. C'est à dire des noeuds qui dévieraient du protocole attendu afin de réaliser des actions aléatoires, imprévisibles et irrationnelles (dans le cas d'un bug dans l'implémentation par exemple), ou bien des actions malveillantes et donc rationnels (dans le cas d'une attaque du protocole par un membre malveillant du réseau).

% En effet les CRDT ne proposent aucun mécanisme permettant de mitiger les actions d'un attaquant. Reprenons l'exemple d'Yjs, qui ne définit pas de notion d'état illégal. Ceci est du au fait que pour satisfaire les propriétés des CRDT, le choix de YATA est d'utiliser un "grow only set". C'est à dire une structure de donnée qui ne peut que s'agrandir. La seule opération possible est donc l'insertion d'un élement, facilitant ainsi la commutativité des opérations, Et la suppression y est traitée comme une opération spécifique d'insertion du point de vue de la structure de donnée, la donnée ne disparait donc pas, mais se voit attribuer un "marqueur" qui la rend invisible.

% Ainsi la notion de légalité dans un grow only set n'existe pas puisque toutes les suites d'opérations sont valides. Or si Bob tente d'insérer dans une zone de texte où seule Alice a le droit en écriture, il est attendu que l'opération soit rejetée. Ce qui n'a pas de sens dans un grow only set, et empêcherait la convergence des états à la fin de l'exécution.

% Pour palier à ce problème, l'approche du PCDO

Notamment un problème connu qui est celui de l'équivocation. L'équivocation est le fait pour un noeud malveillant devant normalement envoyer une information à l'ensemble des noeuds d'un réseau distribué, d'envoyer une opération $A$ à une partie du réseau et une opération $B$ à l'autre partie. Créant ainsi une divergence dans les suites d'opérations que maintiennent chaque partie concernée du réseau. 
Plusieurs papiers tendent à montrer qu'une certaine classe de CRDT peut être améliorée afin de mitiger ce problème. Une approche intéressante consiste en la mise en place d'un DAG (un graph dirigé acyclique) stockant tous les états atteints par le réseau ainsi que leurs parents. Et d'accrocher une trace de ce DAG à l'opération qui est envoyé aux autres noeuds. Ainsi l'ensemble des noeuds légitimes seraient en capacité de détecter si leur propre DAG manque d'information, et seraient donc à même de redemander l'information manquante. [REF MEG22] Cette solution proposerait ainsi un mécanisme de resynchronisation entre noeuds légitimes.

Un autre aspect limitant des CRDT est qu'ils ne conviennent pas à tous les types d'applications. En effet, de par leur aspect commutatif, ils ne peuvent opérer que sur des données qui ne présentent pas de notion d'états illégaux. Prenons le cas d'un compteur sur lequel nous pouvons appliquer des opérations d'additions ou de soustractions (et qui sont donc commutatives les unes avec les autres). Peu importe si nous appliquons toutes les soustractions puis toutes les additions, ou bien l'inverse, ou encore un mélange aléatoire de celles-ci. Le compteur qui se verra évoluer au fil du temps n'entrera jamais dans un état "interdit".

Or, dans beaucoup d'application nous avons besoin de restreindre la donnée à un ensemble d'état dits valides. Et d'interdire un ensemble d'état dits invalides. Ce serait le cas dans le traitement d'un solde d'une carte de débit. L'utilisateur peut soumettre un ensemble d'opérations qui vont venir débiter ou créditer la carte. Mais même si l'utilisateur ne cherche pas à dépenser de l'argent qu'il ne possède pas, nous ne pouvons pas appliquer les opérations dans tous les ordres possibles. Par exemple si toutes les opérations de débit sont soumises les unes après les autres, le solde se trouvera en négatif ce qui n'est pas permis, même pour un état qu'on pourrait qualifier de "temporaire".

C'est pour palier à ce problème que Reynal [REF Raynal 23] propose un nouveau type de donnée qui hérite des CRDT et qu'il nomme PCDO (Process-Commutative Distributed Objects). cette solution améliore les CRDT pour proposer un type de donnée empêchant l'atteinte d'état illégaux. Pour ce faire il divise les opérations possibles en deux groupe. Les opérations qui sont réalisables par tous les membres du réseau, et les opérations qui sont spécifiques à un acteur. Il définit alors deux règles. Les opérations communes ne doivent jamais permettre d'atteindre un état illégal. Et seule l'application de plusieurs opérations spécifique à un seul processus permet d'atteindre un état illégal.

Cette solution contraint en réalité l'usage des CRDT, puisqu'elle semble reposer sur la mise en place de plusieurs registres SWMR (Single Writer Multiple Reader) comme théorisé par Lamport en 198X [REF LAMPORT SWMR]. Cette approche ne posant en effet aucun problême de cohérence sur le registre en tant que tel, puisque l'ordre est défini par le seul noeud capable d'édition. La somme de ses registres propose par contre une cohérence partielle, puisque les opérations se retrouvent ordonnées via un ordre lui-même partiel.

Le contre coüt est donc dans la généralisation de ce type de donnée, puisqu'il demande à ce que l'application découpe la donnée partagée en plusieurs registres SWMR ce qui n'est pas applicable dans tous les contextes.

Pour ces raisons, l'application des CRDTs pour l'édition collaborative n'est pas évidente. Puisque dans un contexte multi-utilisateur avec des politiques de contrôle d'accès au document (et dans le corps du document), les CRDT se retrouvent peu résistantes aux problématiques d'édition malveillante. De plus, l'application des CRDT à l'édition collaborative ne résout pas tous les problèmes de résolutions de conflits, et certains cas de figure peuvent encore causer des incohérences et à terme des divergences importantes dans le document final.

