lecture_vdLLP (#10)

Co-authored-by: amaury <ajoly@aviatrix.com>
Reviewed-on: https://amauryjoly.fr/gitea/amaury_joly/bwconsistency/pulls/10

docs/présentation_consistence_faible/script.md

+# Script présentation Consistence Faible
+
+## Plan
+
+1. Présenter un processus séquentiel classique
+   - exemple: processeur mono coeur
+2. Introduire le concept de cohérence via la cohérence forte (le plus intuitif)
+   - exemple: processeur multi coeur, application distribuée centralisé
+   - notions: respect de l'ordre, atomicité, isolation
+3. Introduire le concept de cohérence faible
+   - exemple: application distribuée décentralisé
+4. Définir les propriétés d'un système réparti
+5. (?) Présenter les concepts de modélisations (histoires concurrentes)
\ No newline at end of file

recherches/perrin.md

+# Concurrence et cohérence dans les systèmes répartis
+
+## Autheur: Matthieu Perrin
+
+## Reflexions
+
+Un peu de mal a comprendre les bornes de cohérence.
+Ca veut dire quoi composable ?
+
+## Définitions
+
+Système réparti: Collection d'entités de calcul autonomones connectées en vue d'accomplir une tâche commune.
+
+Entités de calcul: (ou processus). Entité d'un réseau capable de décision en fonction de stimuli.  
+
+Cohérence forte: Les objets ciblés cachent la concurrence et se comportent comme si tous les accès etait sequentiels.
+
+## Introduction
+
+Un système réparti est caractérisé par:
+
+- L'échelle du système
+- Les moyens d'interactions
+- Gestion des fautes (c.f.: reynal18 attacks) (et nombre de fautes acceptables)
+- Rapport au temps (y a t'il une horloge partagé ?)
+
+## Les histoires concurrentes
+
+Une histoire concurrente est un ensemble d'évenements partiellement ordonnés par un ordre de processus et étiquetés par des opérations.
+
+3 primitives possibles:
+
+- Broadcast (diffusion fiable):
+  - Validité: tout message reçu est émis par un processus
+  - Uniformité: tout message reçu par un processus est recu par tout les autres processus
+- FIFO Broadcast (idem Broadcast):
+  - Réception FIFO: tout message reçu par un processus est reçu dans l'ordre d'émission
+- Causal Broadcast (idem FIFO Broadcast):
+  - Réception causale: Tout message m' envoyé par un processus après reception d'un message m est aussi reçu après m chez tout les autres processus
+
+## Modèles
+
+Cohérence forte impossible dans des environements crédibles de cloud. (Trop de risques de déni de services)
+
+Ci dessous une liste des differents paradigmes de modélisation de système répartis:
+
+### Cohérence Sequentiel
+
+Cohérence Sequentiel (SC): Les objets ciblés cachent la concurrence et se comportent comme si tous les accès etait sequentiels.  
+Le but est de mimer le comportement "comme si" un serveur centralisait et ordonnait l'information. (Ca peut etre le cas ou non, il faut juste que la propriété soit respectée).  
+Y a un débat sur une notion de la cohérence séquentielle. La première formalisation de ce type de cohérence formulé par Lamport oublie de mentionner la notion de "synchronisation". Ce qui peut conduire a des comportements non cohérents. Elle permet par exemple l'existence d'histoires infinies qui viennent s'ajouter les unes derrières les autres. Ce qui serait absurde dans un système réel. (Exemple: infinité de lecture suivie d'une infinité d'écriture).  
+Il y a donc débat sur la notion de cohérence séquentielle avec une école qui considére ce cas comme plausible, et une autre qui souhaite rajouter une notion de synchronisation.
+
+### Linéarisibilité
+
+Il y a ici un lien fort entre l'order d'action du processus et son intégration au système. Il y a une synchronicité plus forte.  
+Ici lorsqu'un processus souhaite acceder à un objet, si il n'entre en conflit avec aucune action d'écriture, il récupere la valeur antérieur à son éxécution. (propriété: Registre Sûr).  
+Si plusieurs processus veulent acceder à un objet, et entrent en concurrence avec une écriture, alors ils ne peuvent retourner seulement la valeur avant ou après l'écriture (propriété: Registre Régulier).  
+Si deux lectures ne sont pas concurrentes, alors elles doivent rétourner une valeur au moins aussi récente que la lecture antérieur. (propriété: Registre Atomique).
+
+### Serialisabilité
+
+ACID: Atomicité (une transaction est soit completement acceptée soit completement avortée), Cohérence (Un transaction éxécutée dans un état correct emmène vers un état correct), Isolation (Les transactions n'interferent pas entre elles), Durabilité (une transaction accepté n'est pas remise en cause).
+
+La serialisabilité est similaire à la linéarisibilité, à la difference que des transactions peuvent être avortés. Cela à pour effet de rendre le système moins "fort" en terme de consistence.
+
+### Convergence
+
+La convergence est une notion de cohérence faible. Elle définit un systèmes qui peut à un instant t être divergent, mais qui finira sur un temps infinit à converger vers un état commun.
+
+### Convergenece forte
+
+La convergence forte est une extension de la convergence où notre histoire est diviser en plusieurs états. Chaques transaction se trouve dans un état avec d'autres transaction avec qui elle partage un "passé commun". On définit le passé commun comme la base de connaissance antérieur à l'éxécution de la transaction.
+
+#### Data type pour la convergence
+
+Les types de données vue pour les autres modèles sont peu adapté pour modeliser les interactions dasn le cas de la convergence. On privilégie plutot des types de données qui permettent de définir des états (ex: OR-SET).
+
+### Intention
+
+L'intention est une notion qui tend à aplliquer la cohérence en fonction de l'intention des utilisatuers. Elle trouve son sens particulièrement dans l'éditions collaborative lors d'écritures concurentes. Mais sa spécification reste flou et c'est un concept qui semble difiicile à appliquer.
+

recherches/vanDerLindeLeitaoPreguica.md

+# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
+
+## Authors: van der Linde, Leitao, Preguica
+
+## Definition
+
+causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
+
+Attacks on causal consistency:
+
+- Tempering: a node submit an operation to anticipate a pending operation actually not yet executed by the system.
+- Omitting dependencies: a node used only a subset of the operations in the dependency. He will be able to submit a concurrent task to the system.
+- Unseen dependencies (also called add): a node submit an operation that depends on an operation that he didn't see. It can be usefull for the attacker to anticipate the operation. (This is different from tempering because in this case the operation does not exist yet).
+- Combining omitting and unseen: a node can omit a dependency and submit an operation that depends on an operation that he didn't see.
+- Sibbling generation: creating two differents operations with the same id. The attacker could create a permanent state divergence between the nodes.
+
+## Summary
+
+### Solutions used in the paper
+
+#### Secure Causal Consistency
+Autors defined the properties of a secure causal consistency: Immutable History, No Future Dependencies, Causal Executions, Limitted Omission, and Eventual Sibling Detection.
+
+The algorithms they propose used the following solutions for each property:
+
+- Immutable History: The nodes sign the operations and the dependencies. The nodes can't temper the history because they can't sign the operation.
+- No Future Dependencies: Each operations includes a hash of all direct causal dependencies. The nodes can't omit dependencies because they can't sign the operation.
+- Causal Executions: The nodes need to verify, before executing an operation, that all the dependencies are executed.
+- Limitted Omission: It's by design impossible due to the metadata (hash of the dependencies).
+- Eventual Sibling Detection: Many mechanism are used:
+  - a node is able to detect when two operations with the same id are send from differents paths.
+  - a node is able than the hash of the dependencies is different with the hash provide by the operation.
+  - the nodes are comparing the dependencies of the operation between them. If they are different, they are able to detect the sibbling generation.
+
+#### Secure Strict Causal Consistency
+
+The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel SGX. Thus the usage of a hash of the dependencies is unnecessary.
+An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow.
+This sollution was not explored in the paper due to this issue.