fix du devcontainer

Co-authored-by: amaury <ajoly@aviatrix.com>
Reviewed-on: #10

.devcontainer/devcontainer.json

@@ -2,11 +2,11 @@
 // See: https://containers.dev/ for the "official" DevContainer specifications
 {
     "name": "latex-default", //Add the name your DevContainer Here,
-    "image": "pandoc/latex:latest-ubuntu", //Add the name of your Docker image here. See: https://hub.docker.com for available containers
+    "image": "texlive/texlive", //Add the name of your Docker image here. See: https://hub.docker.com for available containers
     "containerEnv": { //Add your build arguments here
         "DEBIAN_FRONTEND": "noninteractive"
     },
-    "runArgs": [], //Add you docker run arguments here
+    // "runArgs": ["--net=host"], //Add you docker run arguments here
     "updateContentCommand": ".devcontainer/install-tools.sh", //Path to the installation script run inside the DevContainer
     // "customizations": {
     //     //Add your customizations here
@@ -20,6 +20,7 @@
                 "james-yu.latex-workshop",
                 "eamodio.gitlens",
                 "jenselme.grammalecte",
+                "jebbs.plantuml"
             ],
             "settings": {
                 "grammalecte.allowedExtension": ".md,.rst,.adoc,.asciidoc,.creole,.t2t,.tex",

.devcontainer/install-tools.sh

@@ -8,8 +8,14 @@ apt update
 tlmgr install preprint
 
 # installation de grammalecte
-apt install python3 unzip -y
+apt install python3 unzip wget -y
 mkdir /root/.grammalecte
 cd /root/.grammalecte
 wget https://grammalecte.net/zip/Grammalecte-fr-v2.1.1.zip
-unzip Grammalecte-fr-v2.1.1.zip
+unzip Grammalecte-fr-v2.1.1.zip
+
+#Installation de plantuml
+cd /tmp/
+wget https://github.com/plantuml/plantuml/releases/download/v1.2025.10/plantuml-1.2025.10.jar
+mkdir /usr/share/plantuml/
+mv plantuml-1.2025.10.jar /usr/share/plantuml/plantuml.jar

.gitignore

@@ -0,0 +1,50 @@
+# === Fichiers générés par LaTeX ===
+*.aux
+*.bbl
+*.blg
+*.brf
+*.fdb_latexmk
+*.fls
+*.idx
+*.ilg
+*.ind
+*.lof
+*.log
+*.lot
+*.nav
+*.out
+*.snm
+*.synctex.gz
+*.toc
+*.vrb
+*.xdv
+
+# === Répertoires de build ===
+_build/
+build/
+out/
+*.run.xml
+auto/
+
+# === Fichiers temporaires d'éditeurs ===
+*~
+*.swp
+*.bak
+*.backup
+*.tmp
+*.orig
+
+# === Nextcloud ===
+.sync-exclude.lst
+.sync_*.db*
+*.nextcloud.log
+*.owncloud.log
+*.owncloudsync.log
+*.sync.log
+*.nextcloudsync.log
+
+# === macOS (si tu travailles sur Mac) ===
+.DS_Store
+
+# === Windows ===
+Thumbs.db

.sync-exclude.lst

@@ -0,0 +1,15 @@
+]*.aux
+]*.log
+]*.toc
+]*.out
+]*.synctex.gz
+]*.bbl
+]*.blg
+]*.fdb_latexmk
+]*.fls
+]*.nav
+]*.snm
+]*.vrb
+]_build/
+]build/
+].git/

Administration/Dossier demande CIFRE ANRT/.sync-exclude.lst

@@ -0,0 +1,5 @@
+]*.log
+]*.aux
+]*.blg
+]*.out
+]*.el

Administration/Dossier demande CIFRE ANRT/.vscode/settings.json

@@ -0,0 +1,17 @@
+{
+    "emeraldwalk.runonsave": {
+        "commands": [
+            {
+                "cmd": "pandoc -o ${fileDirname}/${fileBasenameNoExt}.pdf ${file}",
+                "match": "\\.t2t$",
+            }
+        ]
+    },
+    "grammarly.selectors": [
+        {
+            "language": "plaintext",
+            "scheme": "file",
+            "pattern": "sujet-cifre.t2t"
+        }
+    ]
+}

Administration/Dossier demande CIFRE ANRT/Makefile

@@ -0,0 +1,39 @@
+# 
+# txt2tags et TeX makefile générique 
+#
+
+# Outils
+FORGE:=.
+TXT2TAGS:=~/bin/txt2tags
+
+###################################################################
+# Par convention le source doit avoir le même nom que le répertoire 
+## nom du répertoire courant
+## Mais ici c'est le dernier fichier t2t qui compte
+MAINT2T:= $(notdir $(abspath $(shell ls -rt *.t2t | tail -1)))
+MAIN:= $(patsubst %.t2t,%,${MAINT2T})
+
+all: ${MAIN}.pdf
+
+# NB : par défaut aucune sortie : faire make NODEBUG= sinon
+NODEBUG= >/dev/null
+
+
+########## Mise en Forme
+%.tex: %.t2t %.bbl config.sujet.t2t sujet.tex
+	${TXT2TAGS} -T sujet.tex  -t tex -o $@ $<
+
+include ${FORGE}/Makefile.tex
+
+
+%.bib.tex:%.bib getbib.t2t
+	@echo $*
+	${TXT2TAGS} -t tex -o $*.bib.tex getbib.t2t 
+
+
+%.bbl:%.bib.tex
+	pdflatex $<
+	rm $*.bib.pdf
+	bibtex $*.bib
+	mv $*.bib.bbl $@
+

Administration/Dossier demande CIFRE ANRT/Makefile.tex

@@ -0,0 +1,110 @@
+# 
+# txt2tags et TeX makefile générique 
+# E.Godard  --  29/05/2001
+#           --  22/08/2005
+#           --  23/05/2007
+#           --  20/08/2007
+#	    --  03/12/2009
+#	    --  09/09/2012
+
+# Le fichier principal doit porter le même nom que le répertoire
+# courant.  
+# make -> fichier postscript (sans màj bibliographie)
+# make final -> force la màj des pages,etc par double compilation
+
+
+LATEX := latex -file-line-error
+PDFLATEX := pdflatex -file-line-error
+
+ALLT2T = $(wildcard *.t2t)
+T2TDEP = $(filter-out $(MAIN).t2t,$(ALLT2T)) # les autres sont des dépendances
+ECRAN = ${MAIN}.pdf	# pdf = présentation
+PAPIER = ${MAIN}.x6.pdf # x6.pdf = à imprimer pour distribution/correction
+
+FIG := $(wildcard *.fig)
+PSTEX := $(FIG:.fig=.pstex)
+PSTEX_T := $(FIG:.fig=.pstex_t)
+FIGPDF := $(FIG:.fig=-fig.pdf)
+FIGTEX := $(FIG:.fig=-fig.tex)
+
+
+final: 
+	touch ${MAIN}.force
+	make ${ECRAN}
+	sleep 1;touch ${MAIN}.force
+	make ${ECRAN} 
+	make ${PAPIER}
+#	sleep 1;touch ${MAIN}.force
+#	make ${PAPIER}
+
+$(MAIN).force: 
+	touch $@
+
+.PHONY: all final clean mrproper
+
+debug.${TARGET}:
+	@ls -l $(TEMPLATEFILE) $(TARGETCONF) ${PARAMT2T}
+
+#### Dépendances génériques latex
+%.pdf: %.tex ${FIGPDF} ${FIGTEX}
+	${PDFLATEX} -jobname=$* $< 
+
+%.x6.pdf: %.pdf
+	pdfnup --nup 3x2 --outfile $@ $< 
+
+%.x2.pdf: %.pdf
+	pdfnup --nup 1x2 --outfile $@ $< 
+
+%-fig.pdf: %.fig
+	fig2dev -L pdftex -F $< $@
+
+%-fig.tex: %.fig
+	fig2dev -L pdftex_t -F -p $*-fig.pdf $< $@
+
+# Latex ne gère pas le svg
+%.pdf: %.svg
+	inkscape -A $@ $<
+
+# Obsolète ??
+%.dvi: %.tex 
+	${LATEX} -jobname=$* $<
+
+%.ps: %.dvi 
+	dvips $< -o
+	echo $@ >> $(CVSIGNORE)
+
+
+%.x6.ps: %.handout.ps
+	# hack pour éliminer la dernière page (vide actuellement)
+	mv $< tmp.$<
+	psselect -p-_2 tmp.$< $<
+	rm tmp.$<
+	# paramètres d'après la doc beamer
+	psnup -6  -m15 -W128mm -H96mm $< > $@
+
+
+
+%.pstex: %.fig
+	fig2dev -L pstex -F $< $@
+
+%.pstex_t: %.fig
+	fig2dev -L pstex_t -F -p $*.pstex $< $@
+
+%.gz: %
+	gzip $<
+
+# Nettoyage
+clean:
+	rm -vf *.log *.aux *.bbl *.blg *.ilg *.toc *.lof *.lot *.idx *.ind *.out *.nav *.snm ${MAIN}.force
+
+mrproper: clean
+	rm -vf ${MAIN}.x6.ps ${MAIN}.ps ${MAIN}.pdf ${MAIN}.dvi $(PSTEX) $(PSTEX_T) ${MAIN}.tex
+
+# Si il y a uniquement des dépendances locales 
+$(MAIN).tgz: $(ALLT2T) $(FIG) $(MAIN).pdf Makefile 
+	tar zcf $@ $+
+
+LOCALRULES=$(wildcard Makefile*.local)
+include ${LOCALRULES}
+
+

Administration/Dossier demande CIFRE ANRT/My Library.bib

@@ -0,0 +1,258 @@
+
+@article{saito_optimistic_2005,
+	title = {Optimistic {Replication}},
+	volume = {37},
+	url = {https://inria.hal.science/hal-01248208},
+	doi = {10.1145/1057977.1057980},
+	abstract = {Data replication is a key technology in distributed systems that enables higher availability and performance. This article surveys optimistic replication algorithms. They allow replica contents to diverge in the short term to support concurrent work practices and tolerate failures in low-quality communication links. The importance of such techniques is increasing as collaboration through wide-area and mobile networks becomes popular.Optimistic replication deploys algorithms not seen in traditional “pessimistic” systems. Instead of synchronous replica coordination, an optimistic algorithm propagates changes in the background, discovers conflicts after they happen, and reaches agreement on the final contents incrementally.We explore the solution space for optimistic replication algorithms. This article identifies key challenges facing optimistic replication systems---ordering operations, detecting and resolving conflicts, propagating changes efficiently, and bounding replica divergence---and provides a comprehensive survey of techniques developed for addressing these challenges.},
+	language = {en},
+	number = {1},
+	urldate = {2023-06-09},
+	journal = {ACM Computing Surveys},
+	author = {Saito, Yasushi and Shapiro, Marc},
+	year = {2005},
+	pages = {42},
+	file = {Saito et Shapiro - 2005 - Optimistic Replication.pdf:/home/amaury/Zotero/storage/4WJX5IAN/Saito et Shapiro - 2005 - Optimistic Replication.pdf:application/pdf},
+}
+
+@article{singh_zeno_2009,
+	title = {Zeno: {Eventually} {Consistent} {Byzantine}-{Fault} {Tolerance}},
+	abstract = {Many distributed services are hosted at large, shared, geographically diverse data centers, and they use replication to achieve high availability despite the unreachability of an entire data center. Recent events show that non-crash faults occur in these services and may lead to long outages. While Byzantine-Fault Tolerance (BFT) could be used to withstand these faults, current BFT protocols can become unavailable if a small fraction of their replicas are unreachable. This is because existing BFT protocols favor strong safety guarantees (consistency) over liveness (availability).},
+	language = {en},
+	author = {Singh, Atul and Fonseca, Pedro and Kuznetsov, Petr and Rodrigues, Rodrigo and Maniatis, Petros},
+	year = {2009},
+	file = {Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:/home/amaury/Zotero/storage/K6J2UEBK/Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:application/pdf},
+}
+
+@inproceedings{shakarami_refresh_2019,
+	title = {Refresh {Instead} of {Revoke} {Enhances} {Safety} and {Availability}: {A} {Formal} {Analysis}},
+	volume = {LNCS-11559},
+	shorttitle = {Refresh {Instead} of {Revoke} {Enhances} {Safety} and {Availability}},
+	url = {https://inria.hal.science/hal-02384596},
+	doi = {10.1007/978-3-030-22479-0_16},
+	abstract = {Due to inherent delays and performance costs, the decision point in a distributed multi-authority Attribute-Based Access Control (ABAC) system is exposed to the risk of relying on outdated attribute values and policy; which is the safety and consistency problem. This paper formally characterizes three increasingly strong levels of consistency to restrict this exposure. Notably, we recognize the concept of refreshing attribute values rather than simply checking the revocation status, as in traditional approaches. Refresh replaces an older value with a newer one, while revoke simply invalidates the old value. Our lowest consistency level starts from the highest level in prior revocation-based work by Lee and Winslett (LW). Our two higher levels utilize the concept of request time which is absent in LW. For each of our levels we formally show that using refresh instead of revocation provides added safety and availability.},
+	language = {en},
+	urldate = {2023-06-09},
+	publisher = {Springer International Publishing},
+	author = {Shakarami, Mehrnoosh and Sandhu, Ravi},
+	month = jul,
+	year = {2019},
+	pages = {301},
+	file = {Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:/home/amaury/Zotero/storage/XQNWKF7H/Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:application/pdf},
+}
+
+@article{misra_axioms_1986,
+	title = {Axioms for memory access in asynchronous hardware systems},
+	volume = {8},
+	issn = {0164-0925, 1558-4593},
+	url = {https://dl.acm.org/doi/10.1145/5001.5007},
+	doi = {10.1145/5001.5007},
+	abstract = {The problem of concurrent accesses to registers by asynchronous components is considered. A set of axioms about the values in a register during concurrent accesses is proposed. It is shown that if these axioms are met by a register, then concurrent accesses to it may be viewed as nonconcurrent, thus making it possible to analyze asynchronous algorithms without elaborate timing analysis of operations. These axioms are shown, in a certain sense, to be the weakest. Motivation for this work came from analyzing low-level hardware components in a VLSI chip which concurrently accesses a flip-flop.},
+	language = {en},
+	number = {1},
+	urldate = {2023-06-08},
+	journal = {ACM Transactions on Programming Languages and Systems},
+	author = {Misra, J.},
+	month = jan,
+	year = {1986},
+	pages = {142--153},
+	file = {Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:/home/amaury/Zotero/storage/KZP2774N/Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:application/pdf},
+}
+
+@article{lamport_interprocess_1986,
+	title = {On interprocess communication},
+	volume = {1},
+	issn = {1432-0452},
+	url = {https://doi.org/10.1007/BF01786228},
+	doi = {10.1007/BF01786228},
+	abstract = {Interprocess communication is studied without assuming any lower-level communication primitives. Three classes of communication registers are considered, and several constructions are given for implementing one class of register with a weaker class. The formalism developed in Part I is used in proving the correctness of these constructions.},
+	language = {en},
+	number = {2},
+	urldate = {2023-06-08},
+	journal = {Distributed Computing},
+	author = {Lamport, Leslie},
+	month = jun,
+	year = {1986},
+	keywords = {Communication Network, Computer Hardware, Computer System, Operating System, System Organization},
+	pages = {86--101},
+	file = {Lamport - 1986 - On interprocess communication.pdf:/home/amaury/Zotero/storage/XV7AEARN/Lamport - 1986 - On interprocess communication.pdf:application/pdf},
+}
+
+@book{lipton_pram_1988,
+	title = {{PRAM}: {A} {Scalable} {Shared} {Memory}},
+	shorttitle = {{PRAM}},
+	language = {en},
+	publisher = {Princeton University, Department of Computer Science},
+	author = {Lipton, Richard J. and Sandberg, Jonathan S.},
+	year = {1988},
+	note = {Google-Books-ID: 962epwAACAAJ},
+	file = {Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:/home/amaury/Zotero/storage/3ZYT3WT4/Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:application/pdf},
+}
+
+@inproceedings{hutto_slow_1990,
+	title = {Slow memory: weakening consistency to enhance concurrency in distributed shared memories},
+	shorttitle = {Slow memory},
+	url = {https://www.computer.org/csdl/proceedings-article/icdcs/1990/00089297/12OmNvSKNPr},
+	doi = {10.1109/ICDCS.1990.89297},
+	abstract = {The use of weakly consistent memories in distributed shared memory systems to combat unacceptable network delay and to allow such systems to scale is proposed. Proposed memory correctness conditions are surveyed, and how they are related by a weakness hierarchy is demonstrated. Multiversion and messaging interpretations of memory are introduced as means of systematically exploring the space of possible memories. Slow memory is presented as a memory that allows the effects of writes to propagate slowly through the system, eliminating the need for costly consistency maintenance protocols that limit concurrency. Slow memory processes a valuable locality property and supports a reduction from traditional atomic memory. Thus slow memory is as expressive as atomic memory. This expressiveness is demonstrated by two exclusion algorithms and a solution to M.J. Fischer and A. Michael's (1982) dictionary problem on slow memory.},
+	language = {English},
+	urldate = {2023-06-06},
+	publisher = {IEEE Computer Society},
+	author = {Hutto, P. W. and Ahamad, M.},
+	month = jan,
+	year = {1990},
+	pages = {302,303,304,305,306,307,308,309--302,303,304,305,306,307,308,309},
+	file = {Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf:/home/amaury/Téléchargements/Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf:application/pdf},
+}
+
+@article{lamport_how_1979,
+	title = {How to {Make} a {Multiprocessor} {Computer} {That} {Correctly} {Executes} {Multiprocess} {Programs}},
+	volume = {C-28},
+	issn = {1557-9956},
+	doi = {10.1109/TC.1979.1675439},
+	abstract = {Many large sequential computers execute operations in a different order than is specified by the program. A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order. For a multiprocessor computer, such a correct execution by each processor does not guarantee the correct execution of the entire program. Additional conditions are given which do guarantee that a computer correctly executes multiprocess programs.},
+	number = {9},
+	journal = {IEEE Transactions on Computers},
+	author = {{Lamport}},
+	month = sep,
+	year = {1979},
+	note = {Conference Name: IEEE Transactions on Computers},
+	keywords = {Computer design, concurrent computing, hardware correctness, multiprocessing, parallel processing},
+	pages = {690--691},
+	file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/IVGSSPNE/1675439.html:text/html;Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:/home/amaury/Zotero/storage/GY8CWGUV/Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:application/pdf},
+}
+
+@article{mosberger_memory_1993,
+	title = {Memory consistency models},
+	volume = {27},
+	issn = {0163-5980},
+	url = {https://dl.acm.org/doi/10.1145/160551.160553},
+	doi = {10.1145/160551.160553},
+	abstract = {This paper discusses memory consistency models and their influence on software in the context of parallel machines. In the first part we review previous work on memory consistency models. The second part discusses the issues that arise due to weakening memory consistency. We are especially interested in the influence that weakened consistency models have on language, compiler, and runtime system design. We conclude that tighter interaction between those parts and the memory system might improve performance considerably.},
+	language = {en},
+	number = {1},
+	urldate = {2023-06-06},
+	journal = {ACM SIGOPS Operating Systems Review},
+	author = {Mosberger, David},
+	month = jan,
+	year = {1993},
+	pages = {18--26},
+	file = {Mosberger - 1993 - Memory consistency models.pdf:/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.pdf:application/pdf},
+}
+
+@incollection{goos_causal_1995,
+	address = {Berlin, Heidelberg},
+	title = {From causal consistency to sequential consistency in shared memory systems},
+	volume = {1026},
+	isbn = {978-3-540-60692-5 978-3-540-49263-4},
+	url = {http://link.springer.com/10.1007/3-540-60692-0_48},
+	language = {en},
+	urldate = {2023-06-06},
+	booktitle = {Foundations of {Software} {Technology} and {Theoretical} {Computer} {Science}},
+	publisher = {Springer Berlin Heidelberg},
+	author = {Raynal, Michel and Schiper, André},
+	editor = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan and Thiagarajan, P. S.},
+	year = {1995},
+	doi = {10.1007/3-540-60692-0_48},
+	note = {Series Title: Lecture Notes in Computer Science},
+	pages = {180--194},
+	file = {Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:/home/amaury/Zotero/storage/B8UNWUSA/Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:application/pdf},
+}
+
+@phdthesis{kumar_fault-tolerant_2019,
+	type = {{PhD} {Thesis}},
+	title = {Fault-{Tolerant} {Distributed} {Services} in {Message}-{Passing} {Systems}},
+	school = {Texas A\&M University},
+	author = {Kumar, Saptaparni},
+	year = {2019},
+	file = {Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:/home/amaury/Zotero/storage/Q9XK77W9/Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:application/pdf;Snapshot:/home/amaury/Zotero/storage/7JB26RAJ/1.html:text/html},
+}
+
+@article{somasekaram_high-availability_2022,
+	title = {High-{Availability} {Clusters}: {A} {Taxonomy}, {Survey}, and {Future} {Directions}},
+	volume = {187},
+	issn = {01641212},
+	shorttitle = {High-{Availability} {Clusters}},
+	url = {http://arxiv.org/abs/2109.15139},
+	doi = {10.1016/j.jss.2021.111208},
+	abstract = {The delivery of key services in domains ranging from finance and manufacturing to healthcare and transportation is underpinned by a rapidly growing number of mission-critical enterprise applications. Ensuring the continuity of these complex applications requires the use of software-managed infrastructures called high-availability clusters (HACs). HACs employ sophisticated techniques to monitor the health of key enterprise application layers and of the resources they use, and to seamlessly restart or relocate application components after failures. In this paper, we first describe the manifold uses of HACs to protect essential layers of a critical application and present the architecture of high availability clusters. We then propose a taxonomy that covers all key aspects of HACs -- deployment patterns, application areas, types of cluster, topology, cluster management, failure detection and recovery, consistency and integrity, and data synchronisation; and we use this taxonomy to provide a comprehensive survey of the end-to-end software solutions available for the HAC deployment of enterprise applications. Finally, we discuss the limitations and challenges of existing HAC solutions, and we identify opportunities for future research in the area.},
+	urldate = {2023-06-06},
+	journal = {Journal of Systems and Software},
+	author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
+	month = may,
+	year = {2022},
+	note = {arXiv:2109.15139 [cs, eess]},
+	keywords = {Computer Science - Distributed, Parallel, and Cluster Computing, Computer Science - Networking and Internet Architecture, Electrical Engineering and Systems Science - Systems and Control},
+	pages = {111208},
+	file = {arXiv.org Snapshot:/home/amaury/Zotero/storage/B4KCP9BG/2109.html:text/html;Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:/home/amaury/Zotero/storage/K3LQZLC8/Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:application/pdf},
+}
+
+@book{perrin_concurrence_2017,
+	title = {Concurrence et cohérence dans les systèmes répartis},
+	isbn = {978-1-78405-295-9},
+	abstract = {La société moderne est de plus en plus dominée par la société virtuelle, le nombre d’internautes dans le monde ayant dépassé les trois milliards en 2015. A la différence de leurs homologues séquentiels, les systèmes répartis sont beaucoup plus difficiles à concevoir, et sont donc sujets à de nombreux problèmes.La cohérence séquentielle fournit la même vue globale à tous les utilisateurs, mais le confort d\&\#39;utilisation qu\&\#39;elle apporte est trop coûteux, voire impossible, à mettre en oeuvre à grande échelle. Concurrence et cohérence dans les systèmes répartis examine les meilleures façons de spécifier les objets que l’on peut tout de même implémenter dans ces systèmes.Cet ouvrage explore la zone grise des systèmes répartis et dresse une carte des critères de cohérence faible, identifiant plusieurs familles et démontrant comment elles peuvent s’intégrer dans un langage de programmation.},
+	language = {fr},
+	publisher = {ISTE Group},
+	author = {Perrin, Matthieu},
+	month = sep,
+	year = {2017},
+	note = {Google-Books-ID: 6DRlDwAAQBAJ},
+	file = {Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:/home/amaury/Téléchargements/Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:application/pdf},
+}
+
+@article{van_der_linde_practical_2020,
+	title = {Practical client-side replication: weak consistency semantics for insecure settings},
+	volume = {13},
+	issn = {2150-8097},
+	shorttitle = {Practical client-side replication},
+	url = {https://dl.acm.org/doi/10.14778/3407790.3407847},
+	doi = {10.14778/3407790.3407847},
+	abstract = {Client-side replication and direct client-to-client synchronization can be used to create highly available, low-latency interactive applications. Causal consistency, the strongest available consistency model under network partitions, is an attractive consistency model for these applications.},
+	language = {en},
+	number = {12},
+	urldate = {2023-06-06},
+	journal = {Proceedings of the VLDB Endowment},
+	author = {Van Der Linde, Albert and Leitão, João and Preguiça, Nuno},
+	month = aug,
+	year = {2020},
+	pages = {2590--2605},
+	file = {Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:/home/amaury/Zotero/storage/5TJ3SA56/Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:application/pdf},
+}
+
+@article{decandia_dynamo_2007,
+	title = {Dynamo: {Amazon}’s {Highly} {Available} {Key}-value {Store}},
+	abstract = {Reliability at massive scale is one of the biggest challenges we face at Amazon.com, one of the largest e-commerce operations in the world; even the slightest outage has significant financial consequences and impacts customer trust. The Amazon.com platform, which provides services for many web sites worldwide, is implemented on top of an infrastructure of tens of thousands of servers and network components located in many datacenters around the world. At this scale, small and large components fail continuously and the way persistent state is managed in the face of these failures drives the reliability and scalability of the software systems.},
+	language = {en},
+	author = {DeCandia, Giuseppe and Hastorun, Deniz and Jampani, Madan and Kakulapati, Gunavardhan and Lakshman, Avinash and Pilchin, Alex and Sivasubramanian, Swaminathan and Vosshall, Peter and Vogels, Werner},
+	year = {2007},
+	file = {DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:/home/amaury/Zotero/storage/KDHRPBGR/DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:application/pdf},
+}
+
+@misc{misra_byzantine_2021,
+	title = {Byzantine {Fault} {Tolerant} {Causal} {Ordering}},
+	url = {http://arxiv.org/abs/2112.11337},
+	abstract = {Causal ordering in an asynchronous system has many applications in distributed computing, including in replicated databases and real-time collaborative software. Previous work in the area focused on ordering point-to-point messages in a fault-free setting, and on ordering broadcasts under various fault models. To the best of our knowledge, Byzantine faulttolerant causal ordering has not been attempted for point-topoint communication in an asynchronous setting. In this paper, we first show that existing algorithms for causal ordering of point-to-point communication fail under Byzantine faults. We then prove that it is impossible to causally order messages under point-to-point communication in an asynchronous system with one or more Byzantine failures. We then present two algorithms that can causally order messages under Byzantine failures, where the network provides an upper bound on the message transmission time. The proofs of correctness for these algorithms show that it is possible to achieve causal ordering for point-to-point communication under a stronger asynchrony model where the network provides an upper bound on message transmission time. We also give extensions of our two algorithms for Byzantine fault-tolerant causal ordering of multicasts.},
+	language = {en},
+	urldate = {2023-07-12},
+	publisher = {arXiv},
+	author = {Misra, Anshuman and Kshemkalyani, Ajay},
+	month = dec,
+	year = {2021},
+	note = {arXiv:2112.11337 [cs]},
+	keywords = {Computer Science - Distributed, Parallel, and Cluster Computing},
+	file = {Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:/home/amaury/Zotero/storage/P2R366US/Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:application/pdf},
+}
+
+@inproceedings{tseng_distributed_2019,
+	title = {Distributed {Causal} {Memory} in the {Presence} of {Byzantine} {Servers}},
+	doi = {10.1109/NCA.2019.8935059},
+	abstract = {We study distributed causal shared memory (or distributed read/write objects) in the client-server model over asynchronous message-passing networks in which some servers may suffer Byzantine failures. Since Ahamad et al. proposed causal memory in 1994, there have been abundant research on causal storage. Lately, there is a renewed interest in enforcing causal consistency in large-scale distributed storage systems (e.g., COPS, Eiger, Bolt-on). However, to the best of our knowledge, the fault-tolerance aspect of causal memory is not well studied, especially on the tight resilience bound. In our prior work, we showed that 2 f+1 servers is the tight bound to emulate crash-tolerant causal shared memory when up to f servers may crash. In this paper, we adopt a typical model considered in many prior works on Byzantine-tolerant storage algorithms and quorum systems. In the system, up to f servers may suffer Byzantine failures and any number of clients may crash. We constructively present an emulation algorithm for Byzantine causal memory using 3 f+1 servers. We also prove that 3 f+1 is necessary for tolerating up to f Byzantine servers. In other words, we show that 3 f+1 is a tight bound. For evaluation, we implement our algorithm in Golang and compare their performance with two state-of-the-art fault-tolerant algorithms that ensure atomicity in the Google Cloud Platform.},
+	booktitle = {2019 {IEEE} 18th {International} {Symposium} on {Network} {Computing} and {Applications} ({NCA})},
+	author = {Tseng, Lewis and Wang, Zezhi and Zhao, Yajie and Pan, Haochen},
+	month = sep,
+	year = {2019},
+	note = {ISSN: 2643-7929},
+	keywords = {asynchrony, Byzantine faults, causal memory, Computer crashes, Consensus protocol, distributed storage system, Emulation, evaluation, Fault tolerance, Fault tolerant systems, History, Servers, tight condition},
+	pages = {1--8},
+	file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/DDV34ULW/8935059.html:text/html},
+}

Administration/Dossier demande CIFRE ANRT/Portion de message joint

@@ -0,0 +1,5 @@
+_______________________________________________
+Fsi mailing list
+Fsi@liste.lis-lab.fr
+https://mailman.lis-lab.fr/lists/listinfo/fsi
+

Administration/Dossier demande CIFRE ANRT/_sujet-cifre.fdb_latexmk

@@ -0,0 +1,98 @@
+# Fdb version 4
+["bibtex sujet-cifre"] 1703348836 "sujet-cifre.aux" "sujet-cifre.bbl" "sujet-cifre" 1703348837 2
+  "sujet-cifre.aux" 1703252674 2196 578250cc933fcbf3d403233ab65be64b ""
+  (generated)
+  "sujet-cifre.bbl"
+  "sujet-cifre.blg"
+  (rewritten before read)
+["pdflatex"] 1703348835 "/home/amaury/Nextcloud/Thèse/Administration/cifre/_sujet-cifre.tex" "_sujet-cifre.pdf" "_sujet-cifre" 1703348837 0
+  "/etc/texmf/web2c/texmf.cnf" 1702042508 475 c0e671620eb5563b2130f56340a5fde8 ""
+  "/home/amaury/Nextcloud/Thèse/Administration/cifre/_sujet-cifre.tex" 1703348834 21411 ac3e290fd951eeb95f9d8be8941fb746 ""
+  "/usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map" 1577235249 3524 cb3e574dea2d1052e39280babc910dc8 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/jknappen/ec/tcrm1000.tfm" 1136768653 1536 e07581a4bb3136ece9eeb4c3ffab8233 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmbx10.tfm" 1136768653 1328 c834bbb027764024c09d3d2bf908b5f0 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmbx12.tfm" 1136768653 1324 c910af8c371558dc20f2d7822f66fe64 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmmi12.tfm" 1136768653 1524 4414a8315f39513458b80dfc63bff03a ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmmi6.tfm" 1136768653 1512 f21f83efb36853c0b70002322c1ab3ad ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmmi8.tfm" 1136768653 1520 eccf95517727cb11801f4f1aee3a21b4 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr12.tfm" 1136768653 1288 655e228510b4c2a1abe905c368440826 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr17.tfm" 1136768653 1292 296a67155bdbfc32aa9c636f21e91433 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr6.tfm" 1136768653 1300 b62933e007d01cfd073f79b963c01526 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr8.tfm" 1136768653 1292 21c1c5bfeaebccffdb478fd231a0997d ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy10.tfm" 1136768653 1124 6c73e740cf17375f03eec0ee63599741 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm" 1136768653 1116 933a60c408fc0a863a92debe84b2d294 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy8.tfm" 1136768653 1120 8b7d695260f3cff42e636090a8002094 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmti10.tfm" 1136768653 1480 aa8e34af0eb6a2941b776984cf1dfdc4 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmtt10.tfm" 1136768653 768 1321e9409b4137d6fb428ac9dc956269 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/latex-fonts/lasy6.tfm" 1136768653 520 4889cce2180234b97cad636b6039c722 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx10.pfb" 1248133631 34811 78b52f49e893bcba91bd7581cdc144c0 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12.pfb" 1248133631 32080 340ef9bf63678554ee606688e7b5339d ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb" 1248133631 35752 024fb6c41858982481f6968b5fc26508 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb" 1248133631 32722 d7379af29a190c3f453aba36302ff5a9 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb" 1248133631 32362 179c33bbf43f19adbb3825bb4e36e57a ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmti10.pfb" 1248133631 37944 359e864bd06cde3b1cf57bb20757fb06 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmtt10.pfb" 1248133631 31099 c85edf1dd5b9e826d67c9c7293b6786c ""
+  "/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii" 1461363279 71627 94eb9990bed73c364d7f53f960cc8c5b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty" 1575674566 24708 5584a51a7101caf7e6bbf1fc27d8f7b1 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty" 1576625341 40635 c40361e206be584d448876bba8a64a3b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty" 1576016050 33961 6b5c75130e435b2bfdb9f480a09a39f9 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty" 1576625273 7734 b98cbb34c81f667027c1e3ebdbfce34b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty" 1576625223 8371 9d55b8bd010bc717624922fb3477d92e ""
+  "/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty" 1644112042 7237 bdd120a32c8fdb4b433cf9ca2e7cd98a ""
+  "/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty" 1575499628 8356 7bbb2c2373aa810be568c29e333da8ed ""
+  "/usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty" 1576625065 31769 002a487f55041f8e805cfbf6385ffd97 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty" 1576878844 5412 d5a2436094cd7be85769db90f29250a6 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty" 1600895880 17859 4409f8f50cd365c68e684407e5350b1b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty" 1576015897 19007 15924f7228aca6c6d184b115f4baa231 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty" 1593379760 20089 80423eac55aa175305d35b49e04fe23b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty" 1578692523 15682 94f55b803e160cf7fb6e4d77d07cfe1d ""
+  "/usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty" 1576624663 7008 f92eaa0a3872ed622bbf538217cd2ab7 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty" 1576191570 19336 ce7ae9438967282886b3b036cfad1e4d ""
+  "/usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty" 1576625391 3935 57aa3c3e203a5c2effb4d2bd2efbc323 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/article.cls" 1667332637 20144 d5ecf0a5140c8d8d8b72cbe86e320eff ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty" 1667332637 3052 30236f0cc243a8651b82240dfd2e8b9d ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty" 1667332637 2462 8ce5f9a9c63002f2c1af03c262cf29af ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo" 1667332637 8448 c33a4e1cb35cee9b33c2b21033b73e39 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty" 1579991033 13886 d1306dcf79a944f6988e688c1785f9ce ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg" 1459978653 1213 620bba36b25224fa9b7e1ccb4ecb76fd ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg" 1465944070 1224 978390e9c2234eab29404bc21b268d1e ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def" 1663965824 19448 1e988b341dda20961a6b931bcde55519 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty" 1654720880 7233 e46ce9241d2b2ca2a78155475fdd557a ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty" 1654720880 18387 8f900a490197ebaf93c02ae9476d4b09 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty" 1654720880 8010 a8d949cbdbc5c983593827c9eec252e1 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty" 1654720880 2671 7e67d78d9b88c845599a85b2d41f2e39 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx" 1667332637 2885 9c645d672ae17285bba324998918efd8 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty" 1654720880 4023 293ea1c16429fc0c4cf605f4da1791a9 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty" 1580250785 17914 4c28a13fc3d975e6e81c9bea1d697276 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def" 1668456740 48272 52af74196dd55e6c486243beada2adcd ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty" 1668456740 222727 cfc4e76008392378678e691ec73ef8f0 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty" 1668456740 12947 2cb391007415dfa63f4c5ba1610afddb ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def" 1668456740 14249 c27c0c7065e940126403e065c08683b6 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def" 1668456740 117125 a8ce97e3b03f76decc5ad7e8d4da3088 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty" 1655478651 22555 6d8e155cfef6d82c3d5c742fea7c992e ""
+  "/usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty" 1665067230 13815 760b0c02f691ea230f5359c4e1de23a7 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def" 1673989714 30429 213676d4c7327a21d91ddaed900e7b81 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg" 1279039959 678 4792914a8f45be57bb98413425e4c7af ""
+  "/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty" 1575499565 5766 13a9e8766c47f30327caf893ece86ac8 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty" 1485124581 14857 82c76ebe8f06becf69ab309565b2a0cb ""
+  "/usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty" 1576624809 9878 9e94e8fa600d95f9c7731bb21dfb67a4 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty" 1657483315 9714 ba3194bd52c8499b3f1e3eb91d409670 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/url/url.sty" 1388531844 12796 8edb7d69a20b857904dd0ea757c14ec9 ""
+  "/usr/share/texlive/texmf-dist/web2c/texmf.cnf" 1681034085 39561 34c98e380bf7c7201ee6a7909aff625a ""
+  "/usr/share/texmf/fonts/enc/dvips/cm-super/cm-super-ts1.enc" 1636152094 2900 1537cc8184ad1792082cd229ecc269f4 ""
+  "/usr/share/texmf/fonts/type1/public/cm-super/sfrm1000.pfb" 1636152094 138258 6525c253f16cededa14c7fd0da7f67b2 ""
+  "/usr/share/texmf/web2c/texmf.cnf" 1681034085 39561 34c98e380bf7c7201ee6a7909aff625a ""
+  "/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map" 1702459634 4623455 fa0568a71dd9a288d6c226ee477506c6 ""
+  "/var/lib/texmf/web2c/pdftex/pdflatex.fmt" 1702459746 7881417 4ad1cca5899ad0336eafc70d53f9d6c2 ""
+  "_sujet-cifre.aux" 1703348836 1130 e2e682d5d1e2592618502651edd65195 "pdflatex"
+  "_sujet-cifre.out" 1703348836 0 d41d8cd98f00b204e9800998ecf8427e "pdflatex"
+  "_sujet-cifre.tex" 1703348834 21411 ac3e290fd951eeb95f9d8be8941fb746 ""
+  "_sujet-cifre.toc" 1703348836 0 d41d8cd98f00b204e9800998ecf8427e "pdflatex"
+  "sujet-cifre.bbl" 1703348837 0 d41d8cd98f00b204e9800998ecf8427e "bibtex sujet-cifre"
+  (generated)
+  "_sujet-cifre.aux"
+  "_sujet-cifre.log"
+  "_sujet-cifre.out"
+  "_sujet-cifre.pdf"
+  "_sujet-cifre.toc"
+  (rewritten before read)

Administration/Dossier demande CIFRE ANRT/_sujet-cifre.fls

@@ -0,0 +1,497 @@
+PWD /home/amaury/Nextcloud/Thèse/Administration/cifre
+INPUT /etc/texmf/web2c/texmf.cnf
+INPUT /usr/share/texmf/web2c/texmf.cnf
+INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
+INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
+INPUT /home/amaury/Nextcloud/Thèse/Administration/cifre/_sujet-cifre.tex
+OUTPUT _sujet-cifre.log
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/latex-fonts/lasy6.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT ./_sujet-cifre.aux
+INPUT _sujet-cifre.aux
+INPUT _sujet-cifre.aux
+OUTPUT _sujet-cifre.aux
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+OUTPUT _sujet-cifre.out
+OUTPUT _sujet-cifre.pdf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr17.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr12.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr8.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr6.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmmi12.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmmi8.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmmi6.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy10.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy8.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr12.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmbx12.tfm
+OUTPUT _sujet-cifre.toc
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmbx10.tfm
+INPUT /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmti10.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/jknappen/ec/tcrm1000.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmbx12.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmtt10.tfm
+INPUT ./sujet-cifre.bbl
+INPUT sujet-cifre.bbl
+INPUT ./sujet-cifre.bbl
+INPUT sujet-cifre.bbl
+INPUT _sujet-cifre.aux
+INPUT ./_sujet-cifre.out
+INPUT ./_sujet-cifre.out
+INPUT /usr/share/texmf/fonts/enc/dvips/cm-super/cm-super-ts1.enc
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx10.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmbx12.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmti10.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmtt10.pfb
+INPUT /usr/share/texmf/fonts/type1/public/cm-super/sfrm1000.pfb

Administration/Dossier demande CIFRE ANRT/_sujet-cifre.tex

@@ -0,0 +1,403 @@
+\documentclass{article}
+\usepackage{graphicx}
+\usepackage{paralist} % needed for compact lists
+\usepackage[normalem]{ulem} % needed by strike
+\usepackage[urlcolor=blue,colorlinks=true]{hyperref}
+
+\title{Cohérences faibles pour le cloud zero-trust}
+\author{SUJET DE RECHERCHE}
+\begin{document}
+\date{Emmanuel Godard (LIS) -- Corentin Travers (LIS)\\emmanuel.godard@lis-lab.fr et corentin.travers@lis-lab.fr}
+\maketitle
+
+
+\tableofcontents
+
+
+\textbf{Mots-clefs:} Cloud, Sécurité par conception, Structures et algorithmes distribués, Cohérences faibles, Systèmes byzantins
+
+\hypertarget{toc1}{}
+\section*{Résumé}
+
+Les applications collaboratives en temps réel sont de plus en plus utilisées 
+dans le cadre de la mise en place de systèmes de travail à distance. Ces 
+applications sont souvent basées sur des architectures client-serveur 
+centralisées, ce qui pose des problèmes de sécurité et de confidentialité. Les 
+données sont stockées sur un serveur centralisé, ce qui implique que les 
+utilisateurs doivent faire confiance à un tiers pour la gestion de leurs 
+données. De plus, ces architectures sont souvent vulnérables aux attaques par 
+déni de service, et ne permettent pas de garantir la confidentialité des 
+données.
+
+Pour répondre à ces problématiques, nous proposons d'explorer des
+solutions d'échange de l'information basées sur des architectures sans
+tiers de confiances à travers des approches dites zero-trust et/ou
+pair à pair. Ces solutions nous permettraient de proposer de solutions
+à haut niveau de sécurité tout en garantissant une certaine résilience
+du système. Pour conserver des performances fortes notamment en haute
+disponibilité, les cohérences faibles sont fréquemment utilisées.
+
+Dans ce contexte, nous proposons d'étudier les propriétés de cohérences faibles 
+appliquée aux problématiques liées au cloud. Dans un premier temps sera réalisé 
+un état de l'art sur les solutions byzantines sans primitives cryptographiques, 
+ainsi que sur les différentes implémentations existantes (WP1). Une deuxième 
+étape consistera à proposer des solutions plus efficaces mais utilisant des 
+primitives cryptographiques (WP2). Enfin, une dernière étape consistera en la 
+production d'une preuve de concept de solution de stockage clef/valeurs 
+utilisant les algorithmes retenus aux étapes précédentes (WP3).
+
+\pagebreak
+
+\hypertarget{toc2}{}
+\section*{Problématique}
+
+Depuis les travaux pionniers des années 80, par Lamport
+\cite{LamportInterprocess1986} et Misra \cite{MisraAxioms1986} notamment, la
+gestion de la réplication est au cœur des développements du numérique
+en terme de haute disponibilité. L'une des problématiques
+fondamentales est d'offrir aux développeurs d'applications une
+abstraction de la mémoire répliquée qui soit à la fois simple à
+utiliser et permette de mobiliser de manière souple et résistante
+aux défaillances l'intégralité des ressources distribuées.
+Cette voie de recherche a produit la notion de \textit{cohérence des données}
+dont les nombreuses déclinaisons permette de s'adapter aux meilleurs
+compromis d'usage et spécificités de chaque application.
+
+La tendance actuelle autour de la mise en Cloud des applications
+informatiques implique des modifications importantes dans les usages
+et les modes de développement des nouvelles applications. Dans le cadre de nouvelles facilités d'usage, où la maintenance de l'infrastructure est déléguée à un prestataire, cela a conduit à une centralisation des
+ressources. Cela ré-introduit des problématiques classiques en termes de
+sécurité : nécessité de confiance/souveraineté ou bien
+\textit{point central de défaillance} (SPOF).
+
+De nouvelles approches dites \textit{sans-confiance} (zero-trust) ont donc
+été proposées pour continuer à utiliser ces ressources cloud sans dépendre d'un prestataire particulier. Elles nécessitent à la fois des architectures multi-fournisseurs et des approches cryptographiques avancées. 
+
+\medskip
+
+Du point de vue des programmeurs, il est souvent avantageux de
+considérer de telles applications sur le nuage comme un seul système
+centralisé. Cela nécessite que les structures de données utilisées
+aient une propriété dite de \textit{cohérence forte}.
+
+En conditions réelles, les serveurs peuvent avoir à supporter des
+conditions de fonctionnement très difficiles. Il est bien connu, à la
+fois des théoriciens et des praticiens, par le théorème CAP (Consistency, Availability, Partition tolerance) que des
+compromis de fonctionnement sont souvent nécessaires. En particulier,
+si c'est la cohérence forte qui est recherchée, le temps de calcul
+est proportionnel à la latence de \textbf{tout} le réseau. Ce qui diminue en
+pratique la disponibilité.
+
+Si l'on se réfère au théorème CAP, en appliquant la cohérence forte il 
+est impossible de mettre en place un système hautement résilient, tout 
+en fournissant une application hautement disponible. Ces deux points 
+pouvant néanmoins se retrouver être essentiels dans la réalisation 
+d’une application collaborative.
+
+L’approche pair-à-pair implique en effet une grande résistance du système
+face à la panne. Les répliques sont emmenées à se déconnecter les uns des 
+autres et à avoir des différences de latences importantes et inégales. 
+La non-maitrise du poste et de l’environnement d’exécution de l’application 
+nous pousse à imaginer des systèmes pouvant résister aux pires situations 
+possibles. 
+
+Dans le même temps, la nature de l’application recherchée, qui est la 
+collaboration en temps réel, est liée à la question de la 
+haute disponibilité. Le but étant de permettre à des répliques différentes 
+d’accéder à la même donnée partagée pour un travail en temps réel. Il ne 
+serait donc pas acceptable de proposer des temps de latences trop 
+conséquents entre deux modifications. 
+
+Etant donnée l’impossibilité de satisfaire ces deux aspects nous nous 
+tournons vers l’étude des cohérences faibles, et notamment de la convergence. 
+On peut ainsi définir comme convergent les systèmes respectant la propriété suivante : 
+
+Si les répliques arrêtent de proposer des modifications, alors ces mêmes répliques doivent éventuellement atteindre un état cohérent.
+
+La convergence (ou Eventual Consistency) est particulièrement étudiée. Ainsi 
+un certains nombres de structures de données distribuées proposant de respecter la convergence ont 
+vu le jour. Néanmoins à elles seules, celles-ci ne permettent pas de résoudre notre 
+problématique. En effet cette propriété n'offre pas de garantie sur les comportements durant 
+l’exécution, là exactement où l’incohérence au sein du système est permise 
+par la convergence. Or il ne suffit pas qu’un document converge à terme pour 
+en faire une application d’édition collaborative satisfaisante. Mais il faut aussi 
+proposer des mécanismes pour résoudre les conflits, qui sont inévitables 
+dans l'approche collaborative. Cette résolution doit être réalisée de la manière la 
+plus optimale pour maximiser la préservation du sens donné à chaque modification 
+par la réplique qui l’a émise.
+
+Ces questions ont bien entendu été très étudiées et les différentes solutions 
+proposées particulièrement adaptées dans notre contexte sont les
+\textit{types des données répliqués} (ou Replicated Data Type).
+Il en existe deux classes, les types de 
+données répliquées commutatives (CmRDT), dont les opérations donnent le 
+même résultat, peu importe leurs ordres d’exécutions locales. 
+Et les structures de données convergentes (CvRDT), par exemple un système où 
+la donnée viserait à croitre continuellement convergeant ainsi vers une 
+structure maximale. Ces deux classes sont regroupées sous la dénomination 
+de type de données sans conflit (CRDT) et sont en réalité équivalentes l’une 
+à l’autre \cite{ShapiroConflictFree2011}.
+
+\medskip
+
+En outre, pour proposer des solutions véritablement sécurisées dans un
+contexte zéro-trust, les conditions de fonctionnement les plus
+difficiles à considérer sont lorsque des serveurs ou des clients
+participants ont été compromis et ne respectent pas strictement le
+protocole. Dans la littérature, cela s'appelle un fonctionnement
+byzantin.
+
+Etant données ces contraintes difficiles de disponibilité et de sécurité,
+assurer une propriété
+de cohérence forte peut être très coûteux en calcul et en temps. Les
+exigences applicatives ne sont parfois pas compatibles avec de telles
+conditions de fonctionnement. On peut alors considérer des données
+avec des propriétés dites de \textit{cohérences faibles}.
+
+\hypertarget{toc3}{}
+\section*{État de l'art}
+
+Le paysage des propriétés de \textit{cohérences faibles} est relativement
+complexe. On peut distinguer trois grandes familles de cohérences
+faibles \cite{Raynal18}, \cite{MPBook}:
+
+\begin{compactitem}
+\item la sérialisabilité
+\item la cohérence causale
+\item la cohérence éventuellement forte
+\end{compactitem}
+
+Si la cohérence éventuellement forte est en général recherchée pour
+les applications collaboratives, elle est particulièrement
+coûteuse. La sérialisabilité est plus simple à implémenter mais
+produit parfois des transactions qui ne terminent pas. Ces situations
+d'erreur doivent alors être gérées par l'application.
+La cohérence
+causale maintient l'ordre causal perçu par chaque processus et permet
+en général d'implémenter des structures de données de plus haut niveau 
+de manière efficace.
+Le lecteur pourra se référer à la cartographie assez exhaustive de
+M. Perrin \cite{MPBook}.
+
+\hypertarget{toc4}{}
+\subsection*{Résultats Algorithmiques}
+
+Les premiers travaux sur des outils collaboratifs sécurisés dans un 
+contexte de haute disponibilité
+datent de 2009, cependant les recherches plus
+systématiques concernant la sécurité des cohérences dites faibles sont
+en fait très récentes.
+En 2009, Sing \textit{et al.} propose le système Zeno qui est le premier
+à proposer un algorithme byzantin qui privilégie la disponibilité sur 
+la cohérence (forte). Il offre une robustesse byzantine à la 
+cohérence éventuellement forte \cite{SinghZeno2009}. L'algorithme montre 
+de manière expérimentale de meilleures performances de disponibilité 
+que les algorithmes byzantins classiques.
+
+Il existe actuellement essentiellement des études et solutions
+partielles pour la cohérence causale \cite{TsengDistributed2019} et
+\cite{VanDerLindePractical2020}.  Tseng \textit{et al.} présentent des bornes
+exactes de calculabilité dans un cadre byzantin d'un côté et donnent
+un algorithme dont les performances sont comparées avec ceux de la
+plateforme Google Compute.  Van Der Linde \textit{et al.} présentent un
+système pair-à-pair résistant aux attaques byzantines qui offre des
+garanties de cohérence causale. Leur évaluation considère que malgré
+une architecture pair-à-pair, les performances, notamment en termes de
+latence sont très bonnes en comparaison avec une architecture
+client-serveur classique.
+
+En complément de ces algorithmes, Misra et Kshemkalyani ont montré
+dans \cite{MisraByzantine2021} que dans un contexte asynchrone, il n'est
+pas possible de proposer de la consistance causale même avec un seul
+participant byzantin.
+
+L'une des particularités de \cite{VanDerLindePractical2020} est de proposer
+également une réflexion sur les défaillances byzantines dans un
+contexte de cohérences faibles. Un système pair-à-pair tel que celui
+de \cite{MisraByzantine2021} justifie de proposer de nouvelles attaques où
+un participant exploite les informations des couches basses de
+réplication pour créer des attaques au niveau applicatif.
+
+L'application de critères de cohérences faibles ne suffit pas à
+satisfaire le cadre de notre problématique. Le contexte du cloud pose
+notamment de grande questions en termes de centralisation et de
+gouvernance des données, avec un marché dominé par quelques acteurs
+majeurs auxquels les utilisateurs doivent faire confiance de manière
+aveugle. Posant ainsi de grande question sur la confidentialité et la
+souveraineté de leurs informations.
+
+C'est dans ce contexte qu'intégrer la notion d'un cloud zero-trust est
+essentiel en ancrant nos réflexions dans une approche
+pertinente d'un point de vue industriel et réglementaire. Le zero-trust comme défini
+par le NIST dans la SP 800-207 \cite{RoseZero2020} est un modèle de sécurité qui ne fait
+confiance à aucun tiers, et qui ne fait aucune hypothèse sur la
+sécurité du réseau. Il permet ainsi de se préserver des comportements
+malveillants émis par les intermédiaires diminuant la surface
+d'attaque et limitant les comportements byzantins aux seuls clients
+qui eux ont accès aux données.
+
+Evidement ce dernier point est aussi à considérer. C'est pourquoi une
+approche de sécurité centrée sur la donnée en plus des communications
+peut aussi être envisagé en adoptant des approches dites "Data Centric". 
+C'est-à-dire de considérer la donnée elle-même comme un acteur vivant du 
+système en lui attribuant des processus de contrôle d'accès et de suivie 
+\cite{BayukDatacentric2009}. Ces questions représentent des enjeux grandissants et
+sont considérés par les acteurs étatique et inter-étatique à l'image de l'OTAN
+qui statut sur ces problématiques à travers les STANAG 4774 et 4778. Ces 
+questions sont largement étudiées depuis les années 2010 avec des travaux comme 
+\cite{GoyalAttributebased2006, MullerDistributed2009} qui définisse des solutions 
+pour mettre en place du chiffrement par attribut. Consistant à émettre des clés 
+de chiffrements dépendantes de droits, et donc de permettre de définir des 
+politiques de sécurité. Des travaux comme \cite{YanFlexible2017} propose des 
+solutions plus adaptées au cloud en se basant sur des architectures plus 
+flexibles et avec une plus grande granularité dans la définition des droits.
+
+Néanmoins sur les aspects du zero-trust et de la sécurité centrée sur
+la donnée, il n'existe pas encore de travaux académiques concernant
+une formalisation consensuelle de ces notions. Et ces termes sont
+soumis à de nombreuses interprétations. Il reste donc à spécifier
+formellement ces différents termes pour comprendre quelles propriétés
+sont à satisfaire pour réaliser de la cohérence faible dans un
+contexte zero-trust.
+
+\hypertarget{toc5}{}
+\subsection*{Implémentations Existantes}
+
+Des projets actuels tentent d'implémenter des protocoles de cohérences faibles pour la mise en place d'applications collaboratives en temps réel. Parmi ces projets on peut citer yjs \cite{Yjs2023} qui implémente le protocole YATA \cite{NicolaescuRealTime2016} et qui permet d'assurer une convergence forte (ou SEC d'après le référentiel de Perrin) à travers un système de type CRDT. 
+D'autres projets plus anciens tel qu'Etherpad utilise des solutions plus simples à base de résolution de conflit continue, assurant aussi une convergence forte mais réalisant des opérations algorithmiques plus complexes en termes de mémoire et de temps de calcul vis-à-vis des CRDTs \cite{AppJetEtherpad2011}.
+
+\hypertarget{toc6}{}
+\section*{Objectifs}
+
+Les objectifs de cette thèse sont à la fois d'étudier les trois types
+de cohérence faible en situation byzantine et de définir des
+algorithmes byzantins efficaces pour pouvoir les implémenter. Puisque
+la cohérence causale est déjà bien étudiée, ce sont les deux autres
+cohérences qui seront les principaux axes de recherche de cette thèse.
+
+La première étape (WP1) consistera à étudier des solutions byzantines
+sans primitives cryptographiques, ou avec des primitives
+raisonnablement coûteuses, c'est-à-dire notamment sans calcul
+homomorphe. Une étude des implémentations existantes sera réalisée
+pour notamment déterminer les garanties offertes par ces solutions
+dans le vocabulaire des cohérences faibles.
+
+La deuxième étape (WP2) consistera à produire des solutions plus efficaces
+mais qui utilisent des primitives cryptographiques nécessitant des
+primitives de partage de secret avancées et/ou de calcul homomorphe.
+
+Une dernière étape (WP3) consistera en la production d'une preuve de concept
+de solution de stockage \textit{clef/valeurs} utilisant les algorithmes
+retenus aux étapes précédentes.
+
+\hypertarget{toc7}{}
+\section*{Méthodologie et Planning}
+
+Une revue précise des modèles de calcul distribué pour lesquels des
+solutions (principalement de consistance causale) ont été proposées
+sera établie dans le but de déterminer l'ensemble des hypothèses,
+théoriques et pratiques, de validité de ces solutions. En parallèle de
+cetté étude, en relation avec l'entreprise Scille, une liste
+d'attaques sur les architectures pair-à-pairs à cohérence faible sera
+établie.  L'accent sera mis sur la production de connaissances
+nouvelles (nouvelles solutions par rapport à l'état de l'art mais
+également nouvelles attaques).
+
+Les algorithmes seront tout d'abord validé de manière formelle
+avant de voir une preuve de concept développée.
+
+Le WP1 se déroulera en 2024, le WP2 en 2025, et le WP3 en ZO26.
+
+\hypertarget{toc8}{}
+\section*{Modalités de Suivi et d'Échange}
+
+Le doctorant participe aux réunions hebdomadaires de suivi de
+l'entreprise Scille. Les partenaires se rencontreront tous les trois
+mois pour un point d'avancée sur les travaux.
+
+Il participera également aux réunions physiques de
+l'entreprise tous les 6 mois.
+
+\hypertarget{toc9}{}
+\section*{Moyens Matériels}
+
+Le doctorant sera hébergé au Laboratoire d'Informatique et des
+Systèmes. Il bénéficiera de l'environnement scientifique et technique
+d'un laboratoire UMR CNRS de 800 personnes, dont environ 400 personnels permanents .
+
+Du côté de l'entreprise Scille, qui fonctionne en \textit{full remote}, le
+doctorant aura accès à un banc d'essai cloud hébergé par
+l'entreprise. 
+
+\hypertarget{toc10}{}
+\section*{Retombées Attendues}
+
+Du côté du laboratoire LIS, les retombées attendues sont les publications scientifiques suivantes :
+
+\begin{compactitem}
+\item état de l'art et synthèse concernant les consistances faibles byzantines
+\item propositions et preuves de nouveaux algorithmes dans le contexte zéro-trust
+\end{compactitem}
+
+Du côté de l'entreprise Scille, il est attendu une mini-maquette de
+synchronisation et collaboration cloud, une preuve de concept des
+algorithmes sus-cités ainsi que du conseil et de l'expertise dans le
+domaine du "développement scientifique" des produits développés par Scille, notamment \texttt{parsec}.
+
+\hypertarget{toc11}{}
+\section*{Équipe}
+
+\hypertarget{toc12}{}
+\subsection*{Équipe  Algorithmique Distribuée (DALGO)}
+
+L'équipe Algorithmique Distribuée (responsable Arnaud Labourel) fait
+partie du Laboratoire d'Informatique et Systèmes (LIS CNRS UMR 7020).
+du Laboratoire d'Informatique et Systèmes (LIS CNRS UMR 7020).  C'est
+une équipe de recherche reconnue au plus haut niveau international,
+avec 8 membres permanents dont les centres d'intérêt vont des
+algorithmes distribués fiables, de la confidentialité dans les
+systèmes distribués aux réseaux de communication, ainsi qu'aux
+algorithmes de graphes, aux agents mobiles et à l'IoT,
+
+\hypertarget{toc13}{}
+\subsection*{Encadrants}
+
+\textbf{Emmanuel Godard} est professeur à l'Université Aix-Marseille. Ses
+  intérêts de recherche portent principalement sur la compréhension et
+  la maximisation de la décentralisation (en un sens large) dans les
+  systèmes distribués. Il est expert en algorithmique et calculabilité distribuées.
+
+\textbf{Corentin Travers} est Maître de Conférences à l'Université
+  Aix-Marseille.  Ses intérêts de recherche portent sur les
+  algorithmes distributés robustes et efficaces pour les systèmes à
+  mémoire partagée ou les réseaux distribués. Il est expert en algorithmique et complexité distribuées.
+
+\textbf{Marcos Medrano} est ingénieur R\&D chez Scille. Diplômé d'un master de recherche en sciences 
+  de l'informatique et mathématique appliqué. Il est en charge de la stratégie de développement
+  du produit Parsec et réalise le lien entre les ingénieurs et les intervenants académiques.
+
+\hypertarget{toc14}{}
+\subsection*{Choix du Candidat}
+
+L'équipe DALGO est partie prenante du Master "Fiabilité et Sécurité
+Informatique" de l'Université Aix-Marseille. Ce parcours de master est
+labellisé \textit{SecNumEdu} par l'ANSSI. À l'automne 2022, le sujet
+proposé avec l'entreprise Scille a été présenté à l'ensemble des
+étudiants de master. Suite à cet appel à candidature, M. Amaury Joly a
+été retenu pour un stage de recherche préliminaire de 6 mois sur le
+thème des consistances faibles au laboratoire LIS.
+
+Les notes de M. Amaury Joly sont très bonnes, il obtient une mention
+bien au master. Il présente en outre un très bon double profil à la
+fois théorique et technique, sa motivation pour les activités de
+recherche en lien avec la sécurité du Cloud est très forte, il est le
+candidat parfait pour un tel sujet de recherche.
+
+{\footnotesize
+
+\input{sujet-cifre.bbl}
+}
+
+% LaTeX2e code generated by txt2tags 3.4 (http://txt2tags.org)
+% cmdline: txt2tags -t tex --toc sujet-cifre.t2t
+\end{document}

Administration/Dossier demande CIFRE ANRT/config.sujet.t2t

@@ -0,0 +1,4 @@
+
+%!template: sujet
+
+

Administration/Dossier demande CIFRE ANRT/getbib.t2t

@@ -0,0 +1,10 @@
+
+
+
+%!postproc(tex): \\maketitle ""
+%!postproc(tex): \\clearpage ""
+
+
+''' \nocite{*}
+''\bibliography{''%%OUTFILE(%F)''}''
+''' \bibliographystyle{alpha}

Administration/Dossier demande CIFRE ANRT/presentation-labo.tex

@@ -0,0 +1,98 @@
+\documentclass{article}
+
+\usepackage[french]{babel}
+\usepackage{graphicx}
+\usepackage{hyperref}
+\usepackage{svg}
+
+\begin{document}
+
+\title{Laboratoire d'accueil : le LIS}
+
+\date{}
+\maketitle
+
+
+\begin{abstract}
+  Ce document présente le laboratoire d'Informatique et Système (LIS) ainsi que l'équipe d'accueil. 
+\end{abstract}
+
+\section{Présentation du LIS}
+Le LIS Laboratoire d’Informatique et Systèmes est une Unité Mixte de Recherche (UMR) sous tutelles du Centre National de la Recherche Scientifique (CNRS) rattachée à l’Institut des sciences informatiques et de leurs interactions (CNRS Sciences informatiques), de l’Université d’Aix-Marseille (AMU) et de l’Université de Toulon (UTLN). L’Ecole Centrale de Marseille est par ailleurs partenaire du LIS. Ses locaux sont situés sur les campus de Saint-Jérôme et de Luminy à Marseille et sur le campus de l’Université de Toulon. Ce laboratoire regroupe les activités de recherche relevant principalement des sections 06 et 07 du CNRS et des sections 27 et 61 du CNU. Le LIS fédère plus de 375 membres dont 190 permanents chercheurs et enseignants chercheurs et 20 personnels ingénieurs, administratifs, techniques, sociaux et de santé  (IT/IATSS).
+
+Le LIS mène des recherches fondamentales et appliquées dans les domaines de l’informatique, de l’automatique, du signal et de l’image. Il est composé de 20 équipes de recherche et structuré en 4 pôles :
+\begin{figure}[htbp]
+  \centering
+  % \includegraphics[scale=.4]{lis_pole.pdf}
+  \caption{Structuration en pôles du LIS}
+  \label{fig:pole}
+\end{figure}
+
+Les recherches menées au LIS trouvent généralement une finalisation dans des domaines applicatifs aussi divers que le transport, la santé, l’énergie, l’environnement, la défense, etc. Le LIS a ainsi un lien fort avec le monde socio-économique et une activité contractuelle importante. Ces nombreuses activités de valorisation lui permettent de s’impliquer dans plusieurs pôles de compétitivités (pôle Mer, Pôle Solutions Communicantes Sécurisées SCS, Pôle Risques, pôle Eurobiomed et le pôle OPTITEC) et être membre de l’institut Carnot STAR.Une des caractéristiques notables du LIS se situe dans la multidisciplinarité des compétences qu’il regroupe. Cet éventail de compétences complémentaires permet à l'unité d’être impliqué dans plusieurs actions nationales et locales structurantes telles que les instituts de convergence ILCB « Institut Langage, Communication et Cerveau » et Centuri « Centre Turing des Systèmes Vivants »), ainsi que dans l’institut « Archimède » de l’Initiative d’Excellence A*Midex regroupant les activités de recherche en Mathématique, Informatique et interactions sur les sites d’Aix-Marseille et Toulon.
+
+Les chercheurs et enseignants-chercheurs de l'unité s’impliquent dans différentes formations de l’Université d’Aix-Marseille et de l’Université de Toulon (IUT, Licences, Masters, école d’ingénieur Polytech Marseille, école d’ingénieur SeaTech Toulon) ainsi qu’à l’Ecole Centrale de Marseille (ECM) dans les spécialités informatique, génie électrique et automatique.
+
+
+\subsection{Historique et géographie}
+
+Le LIS est né le 1er janvier 2018 de la fusion de deux laboratoires :
+\begin{itemize}
+\item  Le Laboratoire d’informatique fondamentale de Marseille (ex-UMR7279), le LIF, laboratoire qui regroupait en 2017 63 chercheurs et enseignants-chercheurs répartis dans 7 équipes de recherche, 7 personnels ITA / BIATSS, et une trentaine de membres non-permanents (doctorants et post-doctorants). Les thématiques du LIF relevaient toutes de l’informatique et étaient centrées sur l’algorithmique, la combinatoire, les méthodes formelles, les modèles de calcul, la complexité, l’apprentissage, les bases de données et la fouille de données, et le traitement automatique des langues; et
+\item Le Laboratoire des sciences de l’information et des systèmes (ex-UMR7296), le LSIS, laboratoire qui regroupait en 2017 117 chercheurs et enseignants-chercheurs répartis dans 12 équipes de recherche, 18 personnels ITA / BIATSS, et environ 140 membres non-permanents (doctorants, post-doctorants et ingénieurs sous contrat). Les thématiques du LSIS étaient organisées selon trois axes : l’informatique (logique, représentation des connaissances, contraintes, systèmes d’information, fouille de données, recherche d’information), l’automatique (analyse, commande, diagnostic-pronostic de systèmes complexes non-linéaires, discrets ou mécaniques, et de la productique) et l’image (modélisation graphique et analyse et traitement d’images).
+\end{itemize}
+
+Le LIS développe ses activités sur trois sites officiels :
+\begin{itemize}
+\item 
+  Marseille Sud : campus de Luminy ;
+  \item 
+ Marseille Nord : campus de Saint-Jérôme ;
+\item
+  Toulon : campus de la Garde.
+\end{itemize}
+
+\subsection{Production scientifique}
+La production scientifique du laboratoire s'élève à 1728 publications sur la période 2016-2021 (source : rapport d'évaluation du laboratoire en prévision de la visite de l'HCERES (Haut Conseil de l'Évaluation de la Recherche et de l'Enseignement Supérieur).) Ces publications se répartissent comme suit :
+
+\begin{figure}[htbp]\centering
+  
+  \begin{tabular}{|l|c|c|c|c|c|c|c|}
+    \hline
+    \textbf{LIS} &\textbf{all} & \textbf{2016} & \textbf{2017} & \textbf{2018} & \textbf{2019} & \textbf{2020} & \textbf{2021} \\
+    \hline
+\textbf{totalité}& 1728 & 289 & 291   & 295 & 294  & 288 & 271 \\
+\textbf{Revues}  & 687  & 107 & 119   & 105 & 104  & 126 & 126 \\
+\textbf{Conférences avec actes} & 924 & 167 & 158  & 176 & 159  & 141 & 123 \\
+\textbf{Directions d’ouvrage}  & 28 & 6 & 5  & 5 & 3  & 3 & 6  \\
+    \textbf{Chapitres d’ouvrage}   & 89 & 9 & 9 & 9 & 28  & 18 & 16 \\
+                                                                  \hline
+\end{tabular}
+\caption{Publications du LIS sur la période 2016-2021}
+\end{figure}
+
+
+\section{Équipe DAlgo}
+Le doctorant développera son activité au sein de l'équipe DAlgo (Distributed Algorithms)  située sur le campus de Luminy. Le concept de système distribué est fondamental tant pour les applications pratiques que pour les fondements théoriques de l'informatique. Un système distribué est un environnement où plusieurs processus travaillent ensemble pour atteindre un but commun ; dans un tel système, les différents processus ne peuvent communiquer directement qu'avec un nombre limité d'autres processus. Nous cherchons à déterminer quels sont les résultats globaux qui peuvent être obtenus dans ces systèmes où les actions des processus n'ont qu'un impact local. L'équipe DALGO s'intéresse à la puissance de calcul des différents modèles distribués et à la complexité des problèmes associés.
+
+Les sujets d'intérêt principalement considérés par l'équipe sont :
+\begin{itemize}
+\item 
+  Conception et analyse d'algorithmes distribués
+  \item 
+    Systèmes d'agents mobiles
+    \item 
+      Systèmes à mémoire partagée et tolérance aux pannes
+    \item 
+    Modélisation de réseaux dynamiques
+  \item 
+    Systèmes embarqués et programmation synchrone
+  \end{itemize}
+  
+  L'équipe de se compose de 8 permanents (1 directeur de recherche CNRS, 5 maîtres de conférences et 2 professeures d'université) et de 4 non permanents (3 doctorants et un post-doctorant). Son responsable actuel est \href{mailto://arnaud.labourel@lis-lab.fr}{Arnaud Labourel}.
+
+\end{document}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: t
+%%% End:

Administration/Dossier demande CIFRE ANRT/sujet-cifre.bbl

@@ -0,0 +1,194 @@
+\newcommand{\etalchar}[1]{$^{#1}$}
+\begin{thebibliography}{VDLLP20}
+
+\bibitem[App11]{AppJetEtherpad2011}
+AppJet.
+\newblock Etherpad and {{EasySync Technical Manual}}.
+\newblock
+  https://raw.githubusercontent.com/ether/etherpad-lite/master/doc/easysync/easysync-full-description.pdf,
+  2011.
+
+\bibitem[Bay09]{BayukDatacentric2009}
+Jennifer Bayuk.
+\newblock Data-centric security.
+\newblock {\em Computer Fraud \& Security}, 2009(3):7--11, March 2009.
+
+\bibitem[BGYZ14]{BurckhardtReplicated2014}
+Sebastian Burckhardt, Alexey Gotsman, Hongseok Yang, and Marek Zawirski.
+\newblock Replicated data types: Specification, verification, optimality.
+\newblock In {\em Proceedings of the 41st {{ACM SIGPLAN-SIGACT Symposium}} on
+  {{Principles}} of {{Programming Languages}}}, pages 271--284, {San Diego
+  California USA}, January 2014. {ACM}.
+
+\bibitem[DHJ{\etalchar{+}}07]{DeCandiaDynamo2007}
+Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati,
+  Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall,
+  and Werner Vogels.
+\newblock Dynamo: amazon's highly available key-value store.
+\newblock In Thomas~C. Bressoud and M.~Frans Kaashoek, editors, {\em
+  Proceedings of the 21st {ACM} Symposium on Operating Systems Principles
+  ({SOSP})}, pages 205--220. {ACM}, 2007.
+
+\bibitem[GPSW06]{GoyalAttributebased2006}
+Vipul Goyal, Omkant Pandey, Amit Sahai, and Brent Waters.
+\newblock Attribute-based encryption for fine-grained access control of
+  encrypted data.
+\newblock In {\em Proceedings of the 13th {{ACM}} Conference on {{Computer}}
+  and Communications Security}, pages 89--98. {ACM}, October 2006.
+
+\bibitem[HA90]{HuttoSlow1990}
+P.~W. Hutto and M.~Ahamad.
+\newblock Slow memory: Weakening consistency to enhance concurrency in
+  distributed shared memories.
+\newblock In {\em Proceedings.,10th {{International Conference}} on
+  {{Distributed Computing Systems}}}, pages 302--309. {IEEE Computer Society},
+  January 1990.
+
+\bibitem[KB17]{KleppmannConflictFree2017}
+Martin Kleppmann and Alastair~R. Beresford.
+\newblock A {{Conflict-Free Replicated JSON Datatype}}.
+\newblock {\em IEEE Transactions on Parallel and Distributed Systems},
+  28(10):2733--2746, October 2017.
+
+\bibitem[Kum19]{KumarFaultTolerant2019}
+Saptaparni Kumar.
+\newblock {\em Fault-{{Tolerant Distributed Services}} in {{Message-Passing
+  Systems}}}.
+\newblock PhD thesis, Texas A\&M University, 2019.
+
+\bibitem[{Lam}79]{LamportHow1979}
+{Lamport}.
+\newblock How to {{Make}} a {{Multiprocessor Computer That Correctly Executes
+  Multiprocess Programs}}.
+\newblock {\em IEEE Transactions on Computers}, C-28(9):690--691, September
+  1979.
+
+\bibitem[Lam86]{LamportInterprocess1986}
+Leslie Lamport.
+\newblock On interprocess communication.
+\newblock {\em Distributed Computing}, 1(2):86--101, June 1986.
+
+\bibitem[LS88]{LiptonPRAM1988}
+Richard~J. Lipton and Jonathan~S. Sandberg.
+\newblock {{PRAM}}: {{A Scalable Shared Memory}}.
+\newblock Technical report, Princeton University, Department of Computer
+  Science, 1988.
+
+\bibitem[Mis86]{MisraAxioms1986}
+J.~Misra.
+\newblock Axioms for memory access in asynchronous hardware systems.
+\newblock {\em ACM Transactions on Programming Languages and Systems},
+  8(1):142--153, January 1986.
+
+\bibitem[MK23]{MisraByzantine2021}
+Anshuman Misra and Ajay~D. Kshemkalyani.
+\newblock Byzantine fault-tolerant causal ordering.
+\newblock In {\em 24th International Conference on Distributed Computing and
+  Networking, ({ICDCN})}, pages 100--109. {ACM}, 2023.
+
+\bibitem[MKE09]{MullerDistributed2009}
+Sascha M{\"u}ller, Stefan Katzenbeisser, and Claudia Eckert.
+\newblock Distributed {{Attribute-Based Encryption}}.
+\newblock In Pil~Joong Lee and Jung~Hee Cheon, editors, {\em Information
+  {{Security}} and {{Cryptology}} {\textendash} {{ICISC}} 2008}, volume 5461,
+  pages 20--36. {Springer Berlin Heidelberg}, {Berlin, Heidelberg}, 2009.
+
+\bibitem[Mos93]{MosbergerMemory1993}
+David Mosberger.
+\newblock Memory consistency models.
+\newblock {\em ACM SIGOPS Operating Systems Review}, 27(1):18--26, January
+  1993.
+
+\bibitem[NJDK16]{NicolaescuRealTime2016}
+Petru Nicolaescu, Kevin Jahns, Michael Derntl, and Ralf Klamma.
+\newblock Near {{Real-Time Peer-to-Peer Shared Editing}} on {{Extensible Data
+  Types}}.
+\newblock In {\em Proceedings of the 19th {{International Conference}} on
+  {{Supporting Group Work}}}, pages 39--49. {ACM}, November 2016.
+
+\bibitem[Per17]{MPBook}
+Matthieu Perrin.
+\newblock {\em {Concurrence et coh{\'e}rence dans les syst{\`e}mes
+  r{\'e}partis}}.
+\newblock {ISTE Group}, September 2017.
+
+\bibitem[Ray18]{Raynal18}
+Michel Raynal.
+\newblock {\em Fault-{{Tolerant Message-Passing Distributed Systems}}: {{An
+  Algorithmic Approach}}}.
+\newblock {Springer}, September 2018.
+
+\bibitem[RBMC20]{RoseZero2020}
+Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly.
+\newblock Zero {{Trust Architecture}}.
+\newblock Technical report, {National Institute of Standards and Technology},
+  August 2020.
+
+\bibitem[RS95]{RaynalCausal1995}
+Michel Raynal and Andr{\'e} Schiper.
+\newblock From causal consistency to sequential consistency in shared memory
+  systems.
+\newblock In Gerhard Goos, Juris Hartmanis, Jan Leeuwen, and P.~S. Thiagarajan,
+  editors, {\em Foundations of {{Software Technology}} and {{Theoretical
+  Computer Science}}}, volume 1026, pages 180--194. {Springer Berlin
+  Heidelberg}, {Berlin, Heidelberg}, 1995.
+
+\bibitem[SCB22]{SomasekaramHighAvailability2022}
+Premathas Somasekaram, Radu Calinescu, and Rajkumar Buyya.
+\newblock High-{{Availability Clusters}}: {{A Taxonomy}}, {{Survey}}, and
+  {{Future Directions}}.
+\newblock {\em Journal of Systems and Software}, 187:111208, May 2022.
+
+\bibitem[SFK{\etalchar{+}}09]{SinghZeno2009}
+Atul Singh, Pedro Fonseca, Petr Kuznetsov, Rodrigo Rodrigues, and Petros
+  Maniatis.
+\newblock Zeno: Eventually consistent byzantine-fault tolerance.
+\newblock In Jennifer Rexford and Emin~G{\"{u}}n Sirer, editors, {\em
+  Proceedings of the 6th {USENIX} Symposium on Networked Systems Design and
+  Implementation ({NSDI})}, pages 169--184. {USENIX} Association, 2009.
+
+\bibitem[SPBZ11]{ShapiroConflictFree2011}
+Marc Shapiro, Nuno Pregui{\c c}a, Carlos Baquero, and Marek Zawirski.
+\newblock Conflict-{{Free Replicated Data Types}}.
+\newblock In {\em Stabilization, {{Safety}}, and {{Security}} of {{Distributed
+  Systems}}}, volume 6976, pages 386--400. {Springer Berlin Heidelberg},
+  {Berlin, Heidelberg}, 2011.
+
+\bibitem[SS05]{SaitoOptimistic2005}
+Yasushi Saito and Marc Shapiro.
+\newblock Optimistic {{Replication}}.
+\newblock {\em ACM Computing Surveys}, 37(1):42, 2005.
+
+\bibitem[SS19]{ShakaramiRefresh2019}
+Mehrnoosh Shakarami and Ravi Sandhu.
+\newblock Refresh {{Instead}} of {{Revoke Enhances Safety}} and
+  {{Availability}}: {{A Formal Analysis}}.
+\newblock In {\em 33th {{IFIP Annual Conference}} on {{Data}} and
+  {{Applications Security}} and {{Privacy}} ({{DBSec}})}, volume LNCS-11559,
+  page 301. {Springer International Publishing}, July 2019.
+
+\bibitem[TWZP19]{TsengDistributed2019}
+Lewis Tseng, Zezhi Wang, Yajie Zhao, and Haochen Pan.
+\newblock Distributed {{Causal Memory}} in the {{Presence}} of {{Byzantine
+  Servers}}.
+\newblock In {\em {{IEEE}} 18th {{International Symposium}} on {{Network
+  Computing}} and {{Applications}} ({{NCA}})}, pages 1--8, September 2019.
+
+\bibitem[VDLLP20]{VanDerLindePractical2020}
+Albert Van Der~Linde, Jo{\~a}o Leit{\~a}o, and Nuno Pregui{\c c}a.
+\newblock Practical client-side replication: Weak consistency semantics for
+  insecure settings.
+\newblock {\em Proceedings of the VLDB Endowment}, 13(12):2590--2605, August
+  2020.
+
+\bibitem[Yjs23]{Yjs2023}
+Yjs/yjs: Shared data types for building collaborative software.
+\newblock https://github.com/yjs/yjs, December 2023.
+
+\bibitem[YLWV17]{YanFlexible2017}
+Zheng Yan, Xueyun Li, Mingjun Wang, and Athanasios~V. Vasilakos.
+\newblock Flexible {{Data Access Control Based}} on {{Trust}} and
+  {{Reputation}} in {{Cloud Computing}}.
+\newblock {\em IEEE Transactions on Cloud Computing}, 5(3):485--498, July 2017.
+
+\end{thebibliography}

Administration/Dossier demande CIFRE ANRT/sujet-cifre.bib

@@ -0,0 +1,462 @@
+@misc{AppJetEtherpad2011,
+  title = {Etherpad and {{EasySync Technical Manual}}},
+  author = {AppJet},
+  year = {2011},
+  urldate = {2023-12-10},
+  howpublished = {https://raw.githubusercontent.com/ether/etherpad-lite/master/doc/easysync/easysync-full-description.pdf},
+  file = {/home/amaury/Zotero/storage/F5SV2JTZ/easysync-full-description.pdf}
+}
+
+@article{BayukDatacentric2009,
+  title = {Data-Centric Security},
+  author = {Bayuk, Jennifer},
+  year = {2009},
+  month = mar,
+  journal = {Computer Fraud \& Security},
+  volume = {2009},
+  number = {3},
+  pages = {7--11},
+  issn = {1361-3723},
+  doi = {10.1016/S1361-3723(09)70032-6},
+  urldate = {2023-12-08},
+  abstract = {The authoritative control objectives for access to data have always been something along the lines of: ``Confirm that user access rights to systems and data are in line with defined and documented business needs, and that job requirements are attached to user identities{\ldots}. Ensure that critical and confidential information is withheld from those who should not have access to it.''1},
+  file = {/home/amaury/Zotero/storage/2YRZBICQ/Bayuk - 2009 - Data-centric security.pdf;/home/amaury/Zotero/storage/KC3F5F86/S1361372309700326.html}
+}
+
+@inproceedings{BurckhardtReplicated2014,
+  title = {Replicated Data Types: Specification, Verification, Optimality},
+  shorttitle = {Replicated Data Types},
+  booktitle = {Proceedings of the 41st {{ACM SIGPLAN-SIGACT Symposium}} on {{Principles}} of {{Programming Languages}}},
+  author = {Burckhardt, Sebastian and Gotsman, Alexey and Yang, Hongseok and Zawirski, Marek},
+  year = {2014},
+  month = jan,
+  pages = {271--284},
+  publisher = {{ACM}},
+  address = {{San Diego California USA}},
+  doi = {10.1145/2535838.2535848},
+  urldate = {2023-11-17},
+  abstract = {Geographically distributed systems often rely on replicated eventually consistent data stores to achieve availability and performance. To resolve conflicting updates at different replicas, researchers and practitioners have proposed specialized consistency protocols, called replicated data types, that implement objects such as registers, counters, sets or lists. Reasoning about replicated data types has however not been on par with comparable work on abstract data types and concurrent data types, lacking specifications, correctness proofs, and optimality results.},
+  isbn = {978-1-4503-2544-8},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/KQNF7XLE/Burckhardt et al. - 2014 - Replicated data types specification, verification.pdf}
+}
+
+@inproceedings{DeCandiaDynamo2007,
+  author       = {Giuseppe DeCandia and
+                  Deniz Hastorun and
+                  Madan Jampani and
+                  Gunavardhan Kakulapati and
+                  Avinash Lakshman and
+                  Alex Pilchin and
+                  Swaminathan Sivasubramanian and
+                  Peter Vosshall and
+                  Werner Vogels},
+  editor       = {Thomas C. Bressoud and
+                  M. Frans Kaashoek},
+  title        = {Dynamo: amazon's highly available key-value store},
+  booktitle    = {Proceedings of the 21st {ACM} Symposium on Operating Systems Principles
+                   ({SOSP})},
+  pages        = {205--220},
+  publisher    = {{ACM}},
+  year         = {2007},
+  url          = {https://doi.org/10.1145/1294261.1294281},
+  doi          = {10.1145/1294261.1294281},
+  timestamp    = {Wed, 14 Nov 2018 10:55:11 +0100},
+  biburl       = {https://dblp.org/rec/conf/sosp/DeCandiaHJKLPSVV07.bib},
+  bibsource    = {dblp computer science bibliography, https://dblp.org}
+}
+@inproceedings{GoyalAttributebased2006,
+  title = {Attribute-Based Encryption for Fine-Grained Access Control of Encrypted Data},
+  booktitle = {Proceedings of the 13th {{ACM}} Conference on {{Computer}} and Communications Security},
+  author = {Goyal, Vipul and Pandey, Omkant and Sahai, Amit and Waters, Brent},
+  year = {2006},
+  month = oct,
+  pages = {89--98},
+  publisher = {{ACM}},
+  doi = {10.1145/1180405.1180418},
+  urldate = {2023-12-08},
+  abstract = {As more sensitive data is shared and stored by third-party sites on the Internet, there will be a need to encrypt data stored at these sites. One drawback of encrypting data, is that it can be selectively shared only at a coarse-grained level (i.e., giving another party your private key). We develop a new cryptosystem for fine-grained sharing of encrypted data that we call Key-Policy Attribute-Based Encryption (KP-ABE). In our cryptosystem, ciphertexts are labeled with sets of attributes and private keys are associated with access structures that control which ciphertexts a user is able to decrypt. We demonstrate the applicability of our construction to sharing of audit-log information and broadcast encryption. Our construction supports delegation of private keys which subsumes Hierarchical Identity-Based Encryption (HIBE).},
+  isbn = {978-1-59593-518-2},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/Z9NEMU4F/Goyal et al. - 2006 - Attribute-based encryption for fine-grained access.pdf}
+}
+
+@inproceedings{HuttoSlow1990,
+  title = {Slow Memory: Weakening Consistency to Enhance Concurrency in Distributed Shared Memories},
+  shorttitle = {Slow Memory},
+  booktitle = {Proceedings.,10th {{International Conference}} on {{Distributed Computing Systems}}},
+  author = {Hutto, P. W. and Ahamad, M.},
+  year = {1990},
+  month = jan,
+  pages = {302--309},
+  publisher = {{IEEE Computer Society}},
+  doi = {10.1109/ICDCS.1990.89297},
+  urldate = {2023-06-06},
+  abstract = {The use of weakly consistent memories in distributed shared memory systems to combat unacceptable network delay and to allow such systems to scale is proposed. Proposed memory correctness conditions are surveyed, and how they are related by a weakness hierarchy is demonstrated. Multiversion and messaging interpretations of memory are introduced as means of systematically exploring the space of possible memories. Slow memory is presented as a memory that allows the effects of writes to propagate slowly through the system, eliminating the need for costly consistency maintenance protocols that limit concurrency. Slow memory processes a valuable locality property and supports a reduction from traditional atomic memory. Thus slow memory is as expressive as atomic memory. This expressiveness is demonstrated by two exclusion algorithms and a solution to M.J. Fischer and A. Michael's (1982) dictionary problem on slow memory.},
+  langid = {english},
+  file = {/home/amaury/Téléchargements/Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf}
+}
+
+@article{KleppmannConflictFree2017,
+  title = {A {{Conflict-Free Replicated JSON Datatype}}},
+  author = {Kleppmann, Martin and Beresford, Alastair R.},
+  year = {2017},
+  month = oct,
+  journal = {IEEE Transactions on Parallel and Distributed Systems},
+  volume = {28},
+  number = {10},
+  eprint = {1608.03960},
+  primaryclass = {cs},
+  pages = {2733--2746},
+  issn = {1045-9219},
+  doi = {10.1109/TPDS.2017.2697382},
+  urldate = {2023-12-10},
+  abstract = {Many applications model their data in a general-purpose storage format such as JSON. This data structure is modified by the application as a result of user input. Such modifications are well understood if performed sequentially on a single copy of the data, but if the data is replicated and modified concurrently on multiple devices, it is unclear what the semantics should be. In this paper we present an algorithm and formal semantics for a JSON data structure that automatically resolves concurrent modifications such that no updates are lost, and such that all replicas converge towards the same state (a conflict-free replicated datatype or CRDT). It supports arbitrarily nested list and map types, which can be modified by insertion, deletion and assignment. The algorithm performs all merging client-side and does not depend on ordering guarantees from the network, making it suitable for deployment on mobile devices with poor network connectivity, in peer-to-peer networks, and in messaging systems with end-to-end encryption.},
+  archiveprefix = {arxiv},
+  langid = {english},
+  keywords = {Computer Science - Databases,{Computer Science - Distributed, Parallel, and Cluster Computing}},
+  file = {/home/amaury/Zotero/storage/BQVG57MU/Kleppmann et Beresford - 2017 - A Conflict-Free Replicated JSON Datatype.pdf}
+}
+
+@phdthesis{KumarFaultTolerant2019,
+  title = {Fault-{{Tolerant Distributed Services}} in {{Message-Passing Systems}}},
+  author = {Kumar, Saptaparni},
+  year = {2019},
+  school = {Texas A\&M University},
+  file = {/home/amaury/Zotero/storage/Q9XK77W9/Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf;/home/amaury/Zotero/storage/7JB26RAJ/1.html}
+}
+
+@article{LamportHow1979,
+  title = {How to {{Make}} a {{Multiprocessor Computer That Correctly Executes Multiprocess Programs}}},
+  author = {{Lamport}},
+  year = {1979},
+  month = sep,
+  journal = {IEEE Transactions on Computers},
+  volume = {C-28},
+  number = {9},
+  pages = {690--691},
+  issn = {1557-9956},
+  doi = {10.1109/TC.1979.1675439},
+  abstract = {Many large sequential computers execute operations in a different order than is specified by the program. A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order. For a multiprocessor computer, such a correct execution by each processor does not guarantee the correct execution of the entire program. Additional conditions are given which do guarantee that a computer correctly executes multiprocess programs.},
+  keywords = {Computer design,concurrent computing,hardware correctness,multiprocessing,parallel processing},
+  file = {/home/amaury/Zotero/storage/GY8CWGUV/Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf;/home/amaury/Zotero/storage/IVGSSPNE/1675439.html}
+}
+
+@article{LamportInterprocess1986,
+  title = {On Interprocess Communication},
+  author = {Lamport, Leslie},
+  year = {1986},
+  month = jun,
+  journal = {Distributed Computing},
+  volume = {1},
+  number = {2},
+  pages = {86--101},
+  issn = {1432-0452},
+  doi = {10.1007/BF01786228},
+  urldate = {2023-06-08},
+  abstract = {Interprocess communication is studied without assuming any lower-level communication primitives. Three classes of communication registers are considered, and several constructions are given for implementing one class of register with a weaker class. The formalism developed in Part I is used in proving the correctness of these constructions.},
+  langid = {english},
+  keywords = {Communication Network,Computer Hardware,Computer System,Operating System,System Organization},
+  file = {/home/amaury/Zotero/storage/XV7AEARN/Lamport - 1986 - On interprocess communication.pdf}
+}
+
+
+
+@TechReport{LiptonPRAM1988,
+  author = 	 {Lipton, Richard J. and Sandberg, Jonathan S.},
+  title = 	 {{{PRAM}}: {{A Scalable Shared Memory}}},
+  institution =  {Princeton University, Department of Computer Science},
+  year = 	 1988,
+  key = 	 {TR-180-88 }}
+
+
+@article{MisraAxioms1986,
+  title = {Axioms for Memory Access in Asynchronous Hardware Systems},
+  author = {Misra, J.},
+  year = {1986},
+  month = jan,
+  journal = {ACM Transactions on Programming Languages and Systems},
+  volume = {8},
+  number = {1},
+  pages = {142--153},
+  issn = {0164-0925, 1558-4593},
+  doi = {10.1145/5001.5007},
+  urldate = {2023-06-08},
+  abstract = {The problem of concurrent accesses to registers by asynchronous components is considered. A set of axioms about the values in a register during concurrent accesses is proposed. It is shown that if these axioms are met by a register, then concurrent accesses to it may be viewed as nonconcurrent, thus making it possible to analyze asynchronous algorithms without elaborate timing analysis of operations. These axioms are shown, in a certain sense, to be the weakest. Motivation for this work came from analyzing low-level hardware components in a VLSI chip which concurrently accesses a flip-flop.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/KZP2774N/Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf}
+}
+
+
+@inproceedings{MisraByzantine2021,
+  author       = {Anshuman Misra and
+                  Ajay D. Kshemkalyani},
+  title        = {Byzantine Fault-Tolerant Causal Ordering},
+  booktitle    = {24th International Conference on Distributed Computing and Networking,
+                  ({ICDCN})},
+  pages        = {100--109},
+  publisher    = {{ACM}},
+  year         = {2023},
+  url          = {https://doi.org/10.1145/3571306.3571395},
+  doi          = {10.1145/3571306.3571395},
+  timestamp    = {Sun, 15 Jan 2023 18:32:09 +0100},
+  biburl       = {https://dblp.org/rec/conf/icdcn/MisraK23.bib},
+  bibsource    = {dblp computer science bibliography, https://dblp.org}
+}
+
+@article{MosbergerMemory1993,
+  title = {Memory Consistency Models},
+  author = {Mosberger, David},
+  year = {1993},
+  month = jan,
+  journal = {ACM SIGOPS Operating Systems Review},
+  volume = {27},
+  number = {1},
+  pages = {18--26},
+  issn = {0163-5980},
+  doi = {10.1145/160551.160553},
+  urldate = {2023-06-06},
+  abstract = {This paper discusses memory consistency models and their influence on software in the context of parallel machines. In the first part we review previous work on memory consistency models. The second part discusses the issues that arise due to weakening memory consistency. We are especially interested in the influence that weakened consistency models have on language, compiler, and runtime system design. We conclude that tighter interaction between those parts and the memory system might improve performance considerably.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.pdf}
+}
+
+@book{MPBook,
+  title = {{Concurrence et coh{\'e}rence dans les syst{\`e}mes r{\'e}partis}},
+  author = {Perrin, Matthieu},
+  year = {2017},
+  month = sep,
+  publisher = {{ISTE Group}},
+  abstract = {La soci{\'e}t{\'e} moderne est de plus en plus domin{\'e}e par la soci{\'e}t{\'e} virtuelle, le nombre d'internautes dans le monde ayant d{\'e}pass{\'e} les trois milliards en 2015. A la diff{\'e}rence de leurs homologues s{\'e}quentiels, les syst{\`e}mes r{\'e}partis sont beaucoup plus difficiles {\`a} concevoir, et sont donc sujets {\`a} de nombreux probl{\`e}mes.La coh{\'e}rence s{\'e}quentielle fournit la m{\^e}me vue globale {\`a} tous les utilisateurs, mais le confort d\&\#39;utilisation qu\&\#39;elle apporte est trop co{\^u}teux, voire impossible, {\`a} mettre en oeuvre {\`a} grande {\'e}chelle.~Concurrence et coh{\'e}rence dans les syst{\`e}mes r{\'e}partis~examine les meilleures fa{\c c}ons de sp{\'e}cifier les objets que l'on peut tout de m{\^e}me impl{\'e}menter dans ces syst{\`e}mes.Cet ouvrage explore la zone grise des syst{\`e}mes r{\'e}partis et dresse une carte des crit{\`e}res de coh{\'e}rence faible, identifiant plusieurs familles et d{\'e}montrant comment elles peuvent s'int{\'e}grer dans un langage de programmation.},
+  googlebooks = {6DRlDwAAQBAJ},
+  isbn = {978-1-78405-295-9},
+  langid = {french},
+  file = {/home/amaury/Téléchargements/Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf}
+}
+
+@incollection{MullerDistributed2009,
+  title = {Distributed {{Attribute-Based Encryption}}},
+  booktitle = {Information {{Security}} and {{Cryptology}} {\textendash} {{ICISC}} 2008},
+  author = {M{\"u}ller, Sascha and Katzenbeisser, Stefan and Eckert, Claudia},
+  editor = {Lee, Pil Joong and Cheon, Jung Hee},
+  year = {2009},
+  volume = {5461},
+  pages = {20--36},
+  publisher = {{Springer Berlin Heidelberg}},
+  address = {{Berlin, Heidelberg}},
+  doi = {10.1007/978-3-642-00730-9_2},
+  urldate = {2023-12-08},
+  abstract = {Ciphertext-Policy Attribute-Based Encryption (CP-ABE) allows to encrypt data under an access policy, specified as a logical combination of attributes. Such ciphertexts can be decrypted by anyone with a set of attributes that fits the policy. In this paper, we introduce the concept of Distributed Attribute-Based Encryption (DABE), where an arbitrary number of parties can be present to maintain attributes and their corresponding secret keys. This is in stark contrast to the classic CP-ABE schemes, where all secret keys are distributed by one central trusted party. We provide the first construction of a DABE scheme; the construction is very efficient, as it requires only a constant number of pairing operations during encryption and decryption.},
+  isbn = {978-3-642-00729-3 978-3-642-00730-9},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/CWKWPE9S/Müller et al. - 2009 - Distributed Attribute-Based Encryption.pdf}
+}
+
+@inproceedings{NicolaescuRealTime2016,
+  title = {Near {{Real-Time Peer-to-Peer Shared Editing}} on {{Extensible Data Types}}},
+  booktitle = {Proceedings of the 19th {{International Conference}} on {{Supporting Group Work}}},
+  author = {Nicolaescu, Petru and Jahns, Kevin and Derntl, Michael and Klamma, Ralf},
+  year = {2016},
+  month = nov,
+  pages = {39--49},
+  publisher = {{ACM}},
+  doi = {10.1145/2957276.2957310},
+  urldate = {2023-12-01},
+  isbn = {978-1-4503-4276-6},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/SV3MSLKD/Nicolaescu et al. - 2016 - Near Real-Time Peer-to-Peer Shared Editing on Exte.pdf}
+}
+
+@book{Raynal18,
+  title = {Fault-{{Tolerant Message-Passing Distributed Systems}}: {{An Algorithmic Approach}}},
+  shorttitle = {Fault-{{Tolerant Message-Passing Distributed Systems}}},
+  author = {Raynal, Michel},
+  year = {2018},
+  month = sep,
+  publisher = {{Springer}},
+  abstract = {This book presents the most important fault-tolerant distributed programming abstractions and their associated distributed algorithms, in particular in terms of reliable communication and agreement, which lie at the heart of nearly all distributed applications. These programming abstractions, distributed objects or services, allow software designers and programmers to cope with asynchrony and the most important types of failures such as process crashes, message losses, and malicious behaviors of computing entities, widely known under the term "Byzantine fault-tolerance". The author introduces these notions in an incremental manner, starting from a clear specification, followed by algorithms which are first described intuitively and then proved correct. The book also presents impossibility results in classic distributed computing models, along with strategies, mainly failure detectors and randomization, that allow us to enrich these models. In this sense, the book constitutes an introduction to the science of distributed computing, with applications in all domains of distributed systems, such as cloud computing and blockchains. Each chapter comes with exercises and bibliographic notes to help the reader approach, understand, and master the fascinating field of fault-tolerant distributed computing.},
+  googlebooks = {J6BtDwAAQBAJ},
+  isbn = {978-3-319-94141-7},
+  langid = {english},
+  keywords = {Computers / Computer Science,Computers / Information Technology,Computers / Networking / General,Technology \& Engineering / Telecommunications}
+}
+
+@incollection{RaynalCausal1995,
+  title = {From Causal Consistency to Sequential Consistency in Shared Memory Systems},
+  booktitle = {Foundations of {{Software Technology}} and {{Theoretical Computer Science}}},
+  author = {Raynal, Michel and Schiper, Andr{\'e}},
+  editor = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan and Thiagarajan, P. S.},
+  year = {1995},
+  volume = {1026},
+  pages = {180--194},
+  publisher = {{Springer Berlin Heidelberg}},
+  address = {{Berlin, Heidelberg}},
+  doi = {10.1007/3-540-60692-0_48},
+  urldate = {2023-06-06},
+  isbn = {978-3-540-60692-5 978-3-540-49263-4},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/B8UNWUSA/Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf}
+}
+
+@techreport{RoseZero2020,
+  title = {Zero {{Trust Architecture}}},
+  author = {Rose, Scott and Borchert, Oliver and Mitchell, Stu and Connelly, Sean},
+  year = {2020},
+  month = aug,
+  institution = {{National Institute of Standards and Technology}},
+  doi = {10.6028/NIST.SP.800-207},
+  urldate = {2023-12-08},
+  abstract = {Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterpriseowned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource. This document contains an abstract definition of zero trust architecture (ZTA) and gives general deployment models and use cases where zero trust could improve an enterprise's overall information technology security posture.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/6PRUAJZ3/Rose et al. - 2020 - Zero Trust Architecture.pdf}
+}
+
+@article{SaitoOptimistic2005,
+  title = {Optimistic {{Replication}}},
+  author = {Saito, Yasushi and Shapiro, Marc},
+  year = {2005},
+  journal = {ACM Computing Surveys},
+  volume = {37},
+  number = {1},
+  pages = {42},
+  doi = {10.1145/1057977.1057980},
+  urldate = {2023-06-09},
+  abstract = {Data replication is a key technology in distributed systems that enables higher availability and performance. This article surveys optimistic replication algorithms. They allow replica contents to diverge in the short term to support concurrent work practices and tolerate failures in low-quality communication links. The importance of such techniques is increasing as collaboration through wide-area and mobile networks becomes popular.Optimistic replication deploys algorithms not seen in traditional ``pessimistic'' systems. Instead of synchronous replica coordination, an optimistic algorithm propagates changes in the background, discovers conflicts after they happen, and reaches agreement on the final contents incrementally.We explore the solution space for optimistic replication algorithms. This article identifies key challenges facing optimistic replication systems---ordering operations, detecting and resolving conflicts, propagating changes efficiently, and bounding replica divergence---and provides a comprehensive survey of techniques developed for addressing these challenges.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/4WJX5IAN/Saito et Shapiro - 2005 - Optimistic Replication.pdf}
+}
+
+@inproceedings{ShakaramiRefresh2019,
+  title = {Refresh {{Instead}} of {{Revoke Enhances Safety}} and {{Availability}}: {{A Formal Analysis}}},
+  shorttitle = {Refresh {{Instead}} of {{Revoke Enhances Safety}} and {{Availability}}},
+  booktitle = {33th {{IFIP Annual Conference}} on {{Data}} and {{Applications Security}} and {{Privacy}} ({{DBSec}})},
+  author = {Shakarami, Mehrnoosh and Sandhu, Ravi},
+  year = {2019},
+  month = jul,
+  volume = {LNCS-11559},
+  pages = {301},
+  publisher = {{Springer International Publishing}},
+  doi = {10.1007/978-3-030-22479-0_16},
+  urldate = {2023-06-09},
+  abstract = {Due to inherent delays and performance costs, the decision point in a distributed multi-authority Attribute-Based Access Control (ABAC) system is exposed to the risk of relying on outdated attribute values and policy; which is the safety and consistency problem. This paper formally characterizes three increasingly strong levels of consistency to restrict this exposure. Notably, we recognize the concept of refreshing attribute values rather than simply checking the revocation status, as in traditional approaches. Refresh replaces an older value with a newer one, while revoke simply invalidates the old value. Our lowest consistency level starts from the highest level in prior revocation-based work by Lee and Winslett (LW). Our two higher levels utilize the concept of request time which is absent in LW. For each of our levels we formally show that using refresh instead of revocation provides added safety and availability.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/XQNWKF7H/Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf}
+}
+
+@incollection{ShapiroConflictFree2011,
+  title = {Conflict-{{Free Replicated Data Types}}},
+  booktitle = {Stabilization, {{Safety}}, and {{Security}} of {{Distributed Systems}}},
+  author = {Shapiro, Marc and Pregui{\c c}a, Nuno and Baquero, Carlos and Zawirski, Marek},
+  year = {2011},
+  volume = {6976},
+  pages = {386--400},
+  publisher = {{Springer Berlin Heidelberg}},
+  address = {{Berlin, Heidelberg}},
+  doi = {10.1007/978-3-642-24550-3_29},
+  urldate = {2023-12-08},
+  abstract = {Replicating data under Eventual Consistency (EC) allows any replica to accept updates without remote synchronisation. This ensures performance and scalability in large-scale distributed systems (e.g., clouds). However, published EC approaches are ad-hoc and error-prone. Under a formal Strong Eventual Consistency (SEC) model, we study sufficient conditions for convergence. A data type that satisfies these conditions is called a Conflict-free Replicated Data Type (CRDT). Replicas of any CRDT are guaranteed to converge in a self-stabilising manner, despite any number of failures. This paper formalises two popular approaches (state- and operation-based) and their relevant sufficient conditions. We study a number of useful CRDTs, such as sets with clean semantics, supporting both add and remove operations, and consider in depth the more complex Graph data type. CRDT types can be composed to develop large-scale distributed applications, and have interesting theoretical properties.},
+  isbn = {978-3-642-24549-7 978-3-642-24550-3},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/QK99TF5K/Shapiro et al. - 2011 - Conflict-Free Replicated Data Types.pdf}
+}
+
+
+@inproceedings{SinghZeno2009, 
+  author       = {Atul Singh and
+                  Pedro Fonseca and
+                  Petr Kuznetsov and
+                  Rodrigo Rodrigues and
+                  Petros Maniatis},
+  editor       = {Jennifer Rexford and
+                  Emin G{\"{u}}n Sirer},
+  title        = {Zeno: Eventually Consistent Byzantine-Fault Tolerance},
+  booktitle    = {Proceedings of the 6th {USENIX} Symposium on Networked Systems Design
+                  and Implementation ({NSDI})},
+  pages        = {169--184},
+  publisher    = {{USENIX} Association},
+  year         = {2009},
+  url          = {http://www.usenix.org/events/nsdi09/tech/full\_papers/singh/singh.pdf},
+  timestamp    = {Thu, 12 Nov 2020 16:34:18 +0100},
+  biburl       = {https://dblp.org/rec/conf/nsdi/SinghFKRM09.bib},
+  bibsource    = {dblp computer science bibliography, https://dblp.org}
+}
+
+@article{SomasekaramHighAvailability2022,
+  title = {High-{{Availability Clusters}}: {{A Taxonomy}}, {{Survey}}, and {{Future Directions}}},
+  shorttitle = {High-{{Availability Clusters}}},
+  author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
+  year = {2022},
+  month = may,
+  journal = {Journal of Systems and Software},
+  volume = {187},
+  eprint = {2109.15139},
+  primaryclass = {cs, eess},
+  pages = {111208},
+  issn = {01641212},
+  doi = {10.1016/j.jss.2021.111208},
+  urldate = {2023-06-06},
+  abstract = {The delivery of key services in domains ranging from finance and manufacturing to healthcare and transportation is underpinned by a rapidly growing number of mission-critical enterprise applications. Ensuring the continuity of these complex applications requires the use of software-managed infrastructures called high-availability clusters (HACs). HACs employ sophisticated techniques to monitor the health of key enterprise application layers and of the resources they use, and to seamlessly restart or relocate application components after failures. In this paper, we first describe the manifold uses of HACs to protect essential layers of a critical application and present the architecture of high availability clusters. We then propose a taxonomy that covers all key aspects of HACs -- deployment patterns, application areas, types of cluster, topology, cluster management, failure detection and recovery, consistency and integrity, and data synchronisation; and we use this taxonomy to provide a comprehensive survey of the end-to-end software solutions available for the HAC deployment of enterprise applications. Finally, we discuss the limitations and challenges of existing HAC solutions, and we identify opportunities for future research in the area.},
+  archiveprefix = {arxiv},
+  keywords = {{Computer Science - Distributed, Parallel, and Cluster Computing},Computer Science - Networking and Internet Architecture,Electrical Engineering and Systems Science - Systems and Control},
+  file = {/home/amaury/Zotero/storage/K3LQZLC8/Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf;/home/amaury/Zotero/storage/B4KCP9BG/2109.html}
+}
+
+@inproceedings{TsengDistributed2019,
+  title = {Distributed {{Causal Memory}} in the {{Presence}} of {{Byzantine Servers}}},
+  booktitle = {{{IEEE}} 18th {{International Symposium}} on {{Network Computing}} and {{Applications}} ({{NCA}})},
+  author = {Tseng, Lewis and Wang, Zezhi and Zhao, Yajie and Pan, Haochen},
+  year = {2019},
+  month = sep,
+  pages = {1--8},
+  issn = {2643-7929},
+  doi = {10.1109/NCA.2019.8935059},
+  abstract = {We study distributed causal shared memory (or distributed read/write objects) in the client-server model over asynchronous message-passing networks in which some servers may suffer Byzantine failures. Since Ahamad et al. proposed causal memory in 1994, there have been abundant research on causal storage. Lately, there is a renewed interest in enforcing causal consistency in large-scale distributed storage systems (e.g., COPS, Eiger, Bolt-on). However, to the best of our knowledge, the fault-tolerance aspect of causal memory is not well studied, especially on the tight resilience bound. In our prior work, we showed that 2 f+1 servers is the tight bound to emulate crash-tolerant causal shared memory when up to f servers may crash. In this paper, we adopt a typical model considered in many prior works on Byzantine-tolerant storage algorithms and quorum systems. In the system, up to f servers may suffer Byzantine failures and any number of clients may crash. We constructively present an emulation algorithm for Byzantine causal memory using 3 f+1 servers. We also prove that 3 f+1 is necessary for tolerating up to f Byzantine servers. In other words, we show that 3 f+1 is a tight bound. For evaluation, we implement our algorithm in Golang and compare their performance with two state-of-the-art fault-tolerant algorithms that ensure atomicity in the Google Cloud Platform.},
+  keywords = {asynchrony,Byzantine faults,causal memory,Computer crashes,Consensus protocol,distributed storage system,Emulation,evaluation,Fault tolerance,Fault tolerant systems,History,Servers,tight condition},
+  file = {/home/amaury/Zotero/storage/DDV34ULW/8935059.html}
+}
+
+@article{VanDerLindePractical2020,
+  title = {Practical Client-Side Replication: Weak Consistency Semantics for Insecure Settings},
+  shorttitle = {Practical Client-Side Replication},
+  author = {Van Der Linde, Albert and Leit{\~a}o, Jo{\~a}o and Pregui{\c c}a, Nuno},
+  year = {2020},
+  month = aug,
+  journal = {Proceedings of the VLDB Endowment},
+  volume = {13},
+  number = {12},
+  pages = {2590--2605},
+  issn = {2150-8097},
+  doi = {10.14778/3407790.3407847},
+  urldate = {2023-06-06},
+  abstract = {Client-side replication and direct client-to-client synchronization can be used to create highly available, low-latency interactive applications. Causal consistency, the strongest available consistency model under network partitions, is an attractive consistency model for these applications.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/5TJ3SA56/Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf}
+}
+
+@article{YanFlexible2017,
+  title = {Flexible {{Data Access Control Based}} on {{Trust}} and {{Reputation}} in {{Cloud Computing}}},
+  author = {Yan, Zheng and Li, Xueyun and Wang, Mingjun and Vasilakos, Athanasios V.},
+  year = {2017},
+  month = jul,
+  journal = {IEEE Transactions on Cloud Computing},
+  volume = {5},
+  number = {3},
+  pages = {485--498},
+  issn = {2168-7161},
+  doi = {10.1109/TCC.2015.2469662},
+  urldate = {2023-12-08},
+  abstract = {Cloud computing offers a new way of services and has become a popular service platform. Storing user data at a cloud data center greatly releases storage burden of user devices and brings access convenience. Due to distrust in cloud service providers, users generally store their crucial data in an encrypted form. But in many cases, the data need to be accessed by other entities for fulfilling an expected service, e.g., an eHealth service. How to control personal data access at cloud is a critical issue. Various application scenarios request flexible control on cloud data access based on data owner policies and application demands. Either data owners or some trusted third parties or both should flexibly participate in this control. However, existing work hasn't yet investigated an effective and flexible solution to satisfy this demand. On the other hand, trust plays an important role in data sharing. It helps overcoming uncertainty and avoiding potential risks. But literature still lacks a practical solution to control cloud data access based on trust and reputation. In this paper, we propose a scheme to control data access in cloud computing based on trust evaluated by the data owner and/or reputations generated by a number of reputation centers in a flexible manner by applying Attribue-Based Encryption and Proxy Re-Encryption. We integrate the concept of context-aware trust and reputation evaluation into a cryptographic system in order to support various control scenarios and strategies. The security and performance of our scheme are evaluated and justified through extensive analysis, security proof, comparison and implementation. The results show the efficiency, flexibility and effectiveness of our scheme for data access control in cloud computing.},
+  langid = {english},
+  file = {/home/amaury/Zotero/storage/EGDZNP8U/Yan et al. - 2017 - Flexible Data Access Control Based on Trust and Re.pdf}
+}
+
+
+@misc{Yjs2023,
+  title = {Yjs/yjs: Shared data types for building collaborative software},
+  year = {2023},
+  month = dec,
+  urldate = {2023-12-10},
+  abstract = {Shared data types for building collaborative software},
+  howpublished= {https://github.com/yjs/yjs},
+  keywords = {collaboration,collaborative-editing,crdt,decentralized,offline-first,p2p,peer-to-peer,realtime,shared-editing,yjs}
+}

Administration/Dossier demande CIFRE ANRT/sujet-cifre.bib.tex

@@ -0,0 +1,18 @@
+\documentclass{article}
+\usepackage{graphicx}
+\usepackage{paralist} % needed for compact lists
+\usepackage[normalem]{ulem} % needed by strike
+\usepackage[urlcolor=blue,colorlinks=true]{hyperref}
+
+\begin{document}
+
+
+
+\nocite{*}
+
+\bibliography{\%\%OUTFILE(\%F)}
+\bibliographystyle{alpha}
+
+% LaTeX2e code generated by txt2tags 3.4 (http://txt2tags.org)
+% cmdline: txt2tags -t tex -o sujet-cifre.bib.tex getbib.t2t
+\end{document}

Administration/Dossier demande CIFRE ANRT/sujet-cifre.fdb_latexmk

@@ -0,0 +1,138 @@
+# Fdb version 4
+["bibtex sujet-cifre"] 1703349640 "sujet-cifre.aux" "sujet-cifre.bbl" "sujet-cifre" 1703349643 0
+  "./sujet-cifre.bib" 1703349561 35633 eb9c295338e2f11b2795051cccfdc15d ""
+  "/usr/share/texlive/texmf-dist/bibtex/bst/base/alpha.bst" 1292289607 23907 a5f93555796fb564b924339521f10a7c ""
+  "sujet-cifre.aux" 1703349642 2410 7d821f63649e6fb10b152fb0ebebfc83 "pdflatex"
+  (generated)
+  "sujet-cifre.bbl"
+  "sujet-cifre.blg"
+  (rewritten before read)
+["pdflatex"] 1703349641 "/home/amaury/Nextcloud/Thèse/Administration/cifre/sujet-cifre.tex" "sujet-cifre.pdf" "sujet-cifre" 1703349643 0
+  "/etc/texmf/web2c/texmf.cnf" 1702042508 475 c0e671620eb5563b2130f56340a5fde8 ""
+  "/home/amaury/Nextcloud/Thèse/Administration/cifre/sujet-cifre.tex" 1703349638 22635 18540184f97b7f69bc632bd622f241f9 ""
+  "/usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc" 1165713224 4850 80dc9bab7f31fb78a000ccfed0e27cab ""
+  "/usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map" 1577235249 3524 cb3e574dea2d1052e39280babc910dc8 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/courier/pcrr8r.tfm" 1136768653 1292 bd42be2f344128bff6d35d98474adfe3 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/courier/pcrr8t.tfm" 1136768653 1384 4632f5e54900a7dadbb83f555bc61e56 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8r.tfm" 1136768653 2532 9ad73cf4dd2173a847f2a5f5608e0b9a ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8t.tfm" 1136768653 3456 16dd534f88eb2bd21ebc7203786b436e ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm" 1136768653 1804 7b5f73028f6509167f47ace9d69509ed ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm" 1136768653 2796 d37c29814a6717720ee1a7c9a0b2c3b8 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8t.tfm" 1136768653 3820 ee5b9d58608ae328e43c6e2bfd4ff851 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplri8r.tfm" 1136768653 2720 70000d5e623e601132eab3cded5b819b ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplri8t.tfm" 1136768653 3684 929c666381f7272e81481908b735ccba ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm" 1136768653 1296 45809c5a464d5f32c8f98ba97c1bb47f ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/latex-fonts/lasy6.tfm" 1136768653 520 4889cce2180234b97cad636b6039c722 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/fplmr.tfm" 1136768653 1032 7fa31d93ecd4cbdfac02c7a1ebc6facc ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm" 1136768653 2080 40a71f65088bdd047622ce295520749e ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm" 1136768653 1828 bb8add3bd19426549f9267c88b0cb8bd ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm" 1136768653 1012 955c4ca523d7827d33db91a33412b048 ""
+  "/usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm" 1136768653 1316 b4037e9c09961a72f8476628774e1ec1 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb" 1248133631 35752 024fb6c41858982481f6968b5fc26508 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb" 1136849748 45758 19968a0990191524e34e1994d4a31cb6 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/urw/palatino/uplb8a.pfb" 1136849748 52406 dad2f72863a03727d5f536c64a69c452 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/urw/palatino/uplr8a.pfb" 1136849748 52665 661b1e6b26edb5f50dd491f8a701cb57 ""
+  "/usr/share/texlive/texmf-dist/fonts/type1/urw/palatino/uplri8a.pfb" 1136849748 50022 90249cba7e3e4e9845f80328d6f9bd13 ""
+  "/usr/share/texlive/texmf-dist/fonts/vf/adobe/courier/pcrr8t.vf" 1136768653 2184 8475af1b9cfa983db5f46f5ed4b8f9f7 ""
+  "/usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplb8t.vf" 1136768653 2316 c3899bd8afb459a9a5a9a546bf3029a2 ""
+  "/usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplr8t.vf" 1136768653 2324 a163806de13ddf37313d2ee968aa0a98 ""
+  "/usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplri8t.vf" 1136768653 2308 5bc0a90b83a3fd7d37d34ef3b64d7e8a ""
+  "/usr/share/texlive/texmf-dist/fonts/vf/public/mathpazo/zplmr7t.vf" 1136768653 1532 73e2c76c81e4f977ab65540630baf4f0 ""
+  "/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii" 1461363279 71627 94eb9990bed73c364d7f53f960cc8c5b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty" 1575674566 24708 5584a51a7101caf7e6bbf1fc27d8f7b1 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/babel-french/francais.ldf" 1672694451 1294 f58ed8751f8f234095d2eea6b6804cc8 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/babel-french/french.ldf" 1672694451 66230 1d451d08deedf2659df2fe99052bfb3a ""
+  "/usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty" 1672087451 151218 8947adcfe23774a8b34494ca536618c3 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-fr.ini" 1661803479 4250 a2f817bda0df06df543d55698ea94f77 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex" 1498512262 336 f27942ba034bde85aef544115290ec5d ""
+  "/usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def" 1672087451 6927 c99434e82ec03074d3c501f7fb71e190 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty" 1576625341 40635 c40361e206be584d448876bba8a64a3b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty" 1576016050 33961 6b5c75130e435b2bfdb9f480a09a39f9 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty" 1576625273 7734 b98cbb34c81f667027c1e3ebdbfce34b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty" 1576625223 8371 9d55b8bd010bc717624922fb3477d92e ""
+  "/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty" 1644112042 7237 bdd120a32c8fdb4b433cf9ca2e7cd98a ""
+  "/usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty" 1572645307 1057 525c2192b5febbd8c1f662c9468335bb ""
+  "/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty" 1575499628 8356 7bbb2c2373aa810be568c29e333da8ed ""
+  "/usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty" 1576625065 31769 002a487f55041f8e805cfbf6385ffd97 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty" 1576878844 5412 d5a2436094cd7be85769db90f29250a6 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty" 1600895880 17859 4409f8f50cd365c68e684407e5350b1b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty" 1576015897 19007 15924f7228aca6c6d184b115f4baa231 ""
+  "/usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty" 1593379760 20089 80423eac55aa175305d35b49e04fe23b ""
+  "/usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty" 1578692523 15682 94f55b803e160cf7fb6e4d77d07cfe1d ""
+  "/usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty" 1576624663 7008 f92eaa0a3872ed622bbf538217cd2ab7 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty" 1294273053 1635 717cb53b4323c7ff0cf7f675b11dfe05 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty" 1576191570 19336 ce7ae9438967282886b3b036cfad1e4d ""
+  "/usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty" 1576625391 3935 57aa3c3e203a5c2effb4d2bd2efbc323 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/article.cls" 1667332637 20144 d5ecf0a5140c8d8d8b72cbe86e320eff ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty" 1667332637 3052 30236f0cc243a8651b82240dfd2e8b9d ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty" 1667332637 2462 8ce5f9a9c63002f2c1af03c262cf29af ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty" 1654720880 5119 4ce42f43368f652f9c9522d943cce8e4 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty" 1654720880 5048 84b05796b49b69e2d4257d537721c960 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu" 1654720880 1990 846f138013b8f9b1eb25530aca1cb8a2 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu" 1654720880 3534 9e491fb32e35bfff6b9ba316480f2ffc ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo" 1667332637 8464 63bf71cc1214ffdd38288da73a7ca182 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu" 1654720880 12786 1d31c639b01407e8ed545252503231bc ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu" 1654720880 5133 2b6b3086fbdf70953c13e087cbcffa1a ""
+  "/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def" 1654720880 11506 48e87c4d4c8b8f9871b6f60996d0a635 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty" 1137109962 1360 df2086bf924b14b72d6121fe9502fcdb ""
+  "/usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty" 1472166125 10197 204f75d5d8d88aa345a8c402e879e63b ""
+  "/usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty" 1579991033 13886 d1306dcf79a944f6988e688c1785f9ce ""
+  "/usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty" 1668028059 18450 88279bf67c81e69f8e3f1c1bad1a26c5 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty" 1338588508 22449 7ec15c16d0d66790f28e90343c5434a3 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty" 1578002852 41601 9cf6c5257b1bc7af01a58859749dd37a ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg" 1459978653 1213 620bba36b25224fa9b7e1ccb4ecb76fd ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg" 1465944070 1224 978390e9c2234eab29404bc21b268d1e ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def" 1663965824 19448 1e988b341dda20961a6b931bcde55519 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty" 1654720880 7233 e46ce9241d2b2ca2a78155475fdd557a ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty" 1654720880 18387 8f900a490197ebaf93c02ae9476d4b09 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty" 1654720880 8010 a8d949cbdbc5c983593827c9eec252e1 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty" 1654720880 2671 7e67d78d9b88c845599a85b2d41f2e39 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx" 1667332637 2885 9c645d672ae17285bba324998918efd8 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty" 1654720880 4023 293ea1c16429fc0c4cf605f4da1791a9 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty" 1580250785 17914 4c28a13fc3d975e6e81c9bea1d697276 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def" 1668456740 48272 52af74196dd55e6c486243beada2adcd ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty" 1668456740 222727 cfc4e76008392378678e691ec73ef8f0 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty" 1668456740 12947 2cb391007415dfa63f4c5ba1610afddb ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def" 1668456740 14249 c27c0c7065e940126403e065c08683b6 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def" 1668456740 117125 a8ce97e3b03f76decc5ad7e8d4da3088 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty" 1655478651 22555 6d8e155cfef6d82c3d5c742fea7c992e ""
+  "/usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty" 1665067230 13815 760b0c02f691ea230f5359c4e1de23a7 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def" 1673989714 30429 213676d4c7327a21d91ddaed900e7b81 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg" 1279039959 678 4792914a8f45be57bb98413425e4c7af ""
+  "/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty" 1575499565 5766 13a9e8766c47f30327caf893ece86ac8 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg" 1585170648 1830 e31effa752c61538383451ae21332364 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty" 1585170648 80964 64e57373f36316e4a09b517cbf1aba2e ""
+  "/usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty" 1585170648 204271 bae5b2d457283e99567249c1990510be ""
+  "/usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty" 1585170648 77022 ee25ce086f4a79d8cf73bac6f94c02a5 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty" 1673469821 3590 84b3e4e53745df51ce7e737e4475abe0 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty" 1485124581 14857 82c76ebe8f06becf69ab309565b2a0cb ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty" 1586716065 803 1508145d595475dad3d7fb46782a0f94 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty" 1586716065 1499 de0ad166b701b820e03588a29bb30798 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty" 1586716065 8976 3f18c815295e2a2949e87fa743bcb489 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/omlzplm.fd" 1137110629 638 2349dd185efcefd0c3380a2601df0cee ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/omszplm.fd" 1137110629 455 c09241d92b40b1b84eb2bb5776606aea ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/omxzplm.fd" 1137110629 322 fb88cb3e5f25cf1596ba8826c4210e0e ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1ppl.fd" 1137110629 961 06b773644d960aac68add40fcb596208 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1zplm.fd" 1137110629 436 5e7baa1a259bab50a2bdffad6426f38c ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1pcr.fd" 1137110629 798 d5895e9edc628f2be019beb2c0ec66df ""
+  "/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ppl.fd" 1137110629 774 5747d3f33ec2f7c4881c94e931a130b1 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty" 1576624809 9878 9e94e8fa600d95f9c7731bb21dfb67a4 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty" 1657483315 9714 ba3194bd52c8499b3f1e3eb91d409670 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty" 1654720880 4545 4c279ac9292a1be8afa9ab2f1d3299c2 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def" 1660425649 8944 1cf5de165d8b3a9de8975b4e3f40e814 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/url/url.sty" 1388531844 12796 8edb7d69a20b857904dd0ea757c14ec9 ""
+  "/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty" 1655066402 56148 51a9a8571c07b9921892ae11063ae853 ""
+  "/usr/share/texlive/texmf-dist/web2c/texmf.cnf" 1681034085 39561 34c98e380bf7c7201ee6a7909aff625a ""
+  "/usr/share/texmf/web2c/texmf.cnf" 1681034085 39561 34c98e380bf7c7201ee6a7909aff625a ""
+  "/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map" 1702459634 4623455 fa0568a71dd9a288d6c226ee477506c6 ""
+  "/var/lib/texmf/web2c/pdftex/pdflatex.fmt" 1702459746 7881417 4ad1cca5899ad0336eafc70d53f9d6c2 ""
+  "sujet-cifre.aux" 1703349642 2410 7d821f63649e6fb10b152fb0ebebfc83 "pdflatex"
+  "sujet-cifre.bbl" 1703349641 8056 728100759c72bde6cb870d71fda7d269 "bibtex sujet-cifre"
+  "sujet-cifre.out" 1703349642 0 d41d8cd98f00b204e9800998ecf8427e "pdflatex"
+  "sujet-cifre.tex" 1703349638 22635 18540184f97b7f69bc632bd622f241f9 ""
+  (generated)
+  "sujet-cifre.aux"
+  "sujet-cifre.log"
+  "sujet-cifre.out"
+  "sujet-cifre.pdf"
+  (rewritten before read)

Administration/Dossier demande CIFRE ANRT/sujet-cifre.fls

@@ -0,0 +1,818 @@
+PWD /home/amaury/Nextcloud/Thèse/Administration/cifre
+INPUT /etc/texmf/web2c/texmf.cnf
+INPUT /usr/share/texmf/web2c/texmf.cnf
+INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
+INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
+INPUT /home/amaury/Nextcloud/Thèse/Administration/cifre/sujet-cifre.tex
+OUTPUT sujet-cifre.log
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
+INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/paralist/paralist.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ulem/ulem.sty
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/latex-fonts/lasy6.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/url/url.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/atbegshi/atbegshi.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/atveryend/atveryend.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ucs/utf8x.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/utf8.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/utf8.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/utf8.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/utf8.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/a4wide/a4wide.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/ntgclass/a4.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/mathpazo.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/helvet.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/courier.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ppl.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8t.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-french/francais.ldf
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-french/francais.ldf
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-french/francais.ldf
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-french/francais.ldf
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-french/french.ldf
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/carlisle/scalefnt.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/tools/xspace.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/listings/lstlang1.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/comment/comment.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
+INPUT ./sujet-cifre.aux
+INPUT sujet-cifre.aux
+INPUT sujet-cifre.aux
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
+INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/locale/fr/babel-fr.ini
+OUTPUT sujet-cifre.aux
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
+INPUT ./sujet-cifre.out
+INPUT sujet-cifre.out
+INPUT ./sujet-cifre.out
+INPUT sujet-cifre.out
+INPUT ./sujet-cifre.out
+INPUT sujet-cifre.out
+INPUT ./sujet-cifre.out
+INPUT sujet-cifre.out
+INPUT ./sujet-cifre.out
+INPUT ./sujet-cifre.out
+OUTPUT sujet-cifre.out
+OUTPUT sujet-cifre.pdf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omlzplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omlzplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omlzplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omlzplm.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omszplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omszplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omszplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omszplm.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omxzplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omxzplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omxzplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/omxzplm.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1zplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1zplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1zplm.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/ot1zplm.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplr8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm
+INPUT /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplr8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplb8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplr8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplb8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplri8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplri8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplri8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplb8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplb8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/public/mathpazo/zplmr7t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/fplmr.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1pcr.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1pcr.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1pcr.fd
+INPUT /usr/share/texlive/texmf-dist/tex/latex/psnfss/t1pcr.fd
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/courier/pcrr8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/courier/pcrr8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/courier/pcrr8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8t.tfm
+INPUT ./sujet-cifre.bbl
+INPUT sujet-cifre.bbl
+INPUT ./sujet-cifre.bbl
+INPUT sujet-cifre.bbl
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplri8t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7m.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7y.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7v.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/zplmr7t.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplr8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/adobe/palatino/pplri8t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplri8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/vf/public/mathpazo/zplmr7t.vf
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/mathpazo/fplmr.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/adobe/palatino/pplr8r.tfm
+INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr10.tfm
+INPUT sujet-cifre.aux
+INPUT ./sujet-cifre.out
+INPUT ./sujet-cifre.out
+INPUT /usr/share/texlive/texmf-dist/fonts/enc/dvips/base/8r.enc
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/urw/courier/ucrr8a.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/urw/palatino/uplb8a.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/urw/palatino/uplr8a.pfb
+INPUT /usr/share/texlive/texmf-dist/fonts/type1/urw/palatino/uplri8a.pfb

Administration/Dossier demande CIFRE ANRT/sujet-cifre.t2t

@@ -0,0 +1,409 @@
+Cohérences faibles pour le cloud zero-trust
+SUJET DE RECHERCHE
+Emmanuel Godard (LIS) -- Corentin Travers (LIS)\\emmanuel.godard@lis-lab.fr et corentin.travers@lis-lab.fr
+
+%!postproc: "\\clearpage" ""
+%!preproc(tex): \[([^]]*)\] ''\\cite{\1}''
+%!postproc: SUJETCOURT ""
+
+
+
+**Mots-clefs:** Cloud, Sécurité par conception, Structures et algorithmes distribués, Cohérences faibles, Systèmes byzantins
+
+
+% Plan:
+
+% - l’état de l’art,
+% - les objectifs,
+% - la méthodologie de recherche,
+% - un planning prévisionnel du déroulement de la thèse (diagramme de Gantt suggéré),
+% - les modalités de suivi et d’échanges entre les partenaires,
+% - les moyens et matériels mis à disposition par chaque partenaire,
+% - les retombées attendues pour chaque partenaire,
+% - les encadrants et contributions techniques de chaque partenaire,
+% - les modalités et motivations du choix du candidat,
+% - des références bibliographiques récentes citées à bon escient.
+
+
+
+
+= Résumé =
+
+Les applications collaboratives en temps réel sont de plus en plus utilisées 
+dans le cadre de la mise en place de systèmes de travail à distance. Ces 
+applications sont souvent basées sur des architectures client-serveur 
+centralisées, ce qui pose des problèmes de sécurité et de confidentialité. Les 
+données sont stockées sur un serveur centralisé, ce qui implique que les 
+utilisateurs doivent faire confiance à un tiers pour la gestion de leurs 
+données. De plus, ces architectures sont souvent vulnérables aux attaques par 
+déni de service, et ne permettent pas de garantir la confidentialité des 
+données.
+
+Pour répondre à ces problématiques, nous proposons d'explorer des
+solutions d'échange de l'information basées sur des architectures sans
+tiers de confiances à travers des approches dites zero-trust et/ou
+pair à pair. Ces solutions nous permettraient de proposer de solutions
+à haut niveau de sécurité tout en garantissant une certaine résilience
+du système. Pour conserver des performances fortes notamment en haute
+disponibilité, les cohérences faibles sont fréquemment utilisées.
+
+Dans ce contexte, nous proposons d'étudier les propriétés de cohérences faibles 
+appliquée aux problématiques liées au cloud. Dans un premier temps sera réalisé 
+un état de l'art sur les solutions byzantines sans primitives cryptographiques, 
+ainsi que sur les différentes implémentations existantes (WP1). Une deuxième 
+étape consistera à proposer des solutions plus efficaces mais utilisant des 
+primitives cryptographiques (WP2). Enfin, une dernière étape consistera en la 
+production d'une preuve de concept de solution de stockage clef/valeurs 
+utilisant les algorithmes retenus aux étapes précédentes (WP3).
+
+
+
+''' \pagebreak
+
+= Problématique =
+
+Depuis les travaux pionniers des années 80, par Lamport
+[LamportInterprocess1986] et Misra [MisraAxioms1986] notamment, la
+gestion de la réplication est au cœur des développements du numérique
+en terme de haute disponibilité. L'une des problématiques
+fondamentales est d'offrir aux développeurs d'applications une
+abstraction de la mémoire répliquée qui soit à la fois simple à
+utiliser et permette de mobiliser de manière souple et résistante
+aux défaillances l'intégralité des ressources distribuées.
+Cette voie de recherche a produit la notion de //cohérence des données//
+dont les nombreuses déclinaisons permette de s'adapter aux meilleurs
+compromis d'usage et spécificités de chaque application.
+
+
+La tendance actuelle autour de la mise en Cloud des applications
+informatiques implique des modifications importantes dans les usages
+et les modes de développement des nouvelles applications. Dans le cadre de nouvelles facilités d'usage, où la maintenance de l'infrastructure est déléguée à un prestataire, cela a conduit à une centralisation des
+ressources. Cela ré-introduit des problématiques classiques en termes de
+sécurité : nécessité de confiance/souveraineté ou bien
+//point central de défaillance// (SPOF).
+
+De nouvelles approches dites //sans-confiance// (zero-trust) ont donc
+été proposées pour continuer à utiliser ces ressources cloud sans dépendre d'un prestataire particulier. Elles nécessitent à la fois des architectures multi-fournisseurs et des approches cryptographiques avancées. 
+
+''' \medskip
+Du point de vue des programmeurs, il est souvent avantageux de
+considérer de telles applications sur le nuage comme un seul système
+centralisé. Cela nécessite que les structures de données utilisées
+aient une propriété dite de //cohérence forte//.
+
+
+En conditions réelles, les serveurs peuvent avoir à supporter des
+conditions de fonctionnement très difficiles. Il est bien connu, à la
+fois des théoriciens et des praticiens, par le théorème CAP (Consistency, Availability, Partition tolerance) que des
+compromis de fonctionnement sont souvent nécessaires. En particulier,
+si c'est la cohérence forte qui est recherchée, le temps de calcul
+est proportionnel à la latence de **tout** le réseau. Ce qui diminue en
+pratique la disponibilité.
+
+Si l'on se réfère au théorème CAP, en appliquant la cohérence forte il 
+est impossible de mettre en place un système hautement résilient, tout 
+en fournissant une application hautement disponible. Ces deux points 
+pouvant néanmoins se retrouver être essentiels dans la réalisation 
+d’une application collaborative.
+
+L’approche pair-à-pair implique en effet une grande résistance du système
+face à la panne. Les répliques sont emmenées à se déconnecter les uns des 
+autres et à avoir des différences de latences importantes et inégales. 
+La non-maitrise du poste et de l’environnement d’exécution de l’application 
+nous pousse à imaginer des systèmes pouvant résister aux pires situations 
+possibles. 
+
+Dans le même temps, la nature de l’application recherchée, qui est la 
+collaboration en temps réel, est liée à la question de la 
+haute disponibilité. Le but étant de permettre à des répliques différentes 
+d’accéder à la même donnée partagée pour un travail en temps réel. Il ne 
+serait donc pas acceptable de proposer des temps de latences trop 
+conséquents entre deux modifications. 
+
+Etant donnée l’impossibilité de satisfaire ces deux aspects nous nous 
+tournons vers l’étude des cohérences faibles, et notamment de la convergence. 
+On peut ainsi définir comme convergent les systèmes respectant la propriété suivante : 
+
+Si les répliques arrêtent de proposer des modifications, alors ces mêmes répliques doivent éventuellement atteindre un état cohérent.
+
+La convergence (ou Eventual Consistency) est particulièrement étudiée. Ainsi 
+un certains nombres de structures de données distribuées proposant de respecter la convergence ont 
+vu le jour. Néanmoins à elles seules, celles-ci ne permettent pas de résoudre notre 
+problématique. En effet cette propriété n'offre pas de garantie sur les comportements durant 
+l’exécution, là exactement où l’incohérence au sein du système est permise 
+par la convergence. Or il ne suffit pas qu’un document converge à terme pour 
+en faire une application d’édition collaborative satisfaisante. Mais il faut aussi 
+proposer des mécanismes pour résoudre les conflits, qui sont inévitables 
+dans l'approche collaborative. Cette résolution doit être réalisée de la manière la 
+plus optimale pour maximiser la préservation du sens donné à chaque modification 
+par la réplique qui l’a émise.
+
+Ces questions ont bien entendu été très étudiées et les différentes solutions 
+proposées particulièrement adaptées dans notre contexte sont les
+//types des données répliqués// (ou Replicated Data Type).
+Il en existe deux classes, les types de 
+données répliquées commutatives (CmRDT), dont les opérations donnent le 
+même résultat, peu importe leurs ordres d’exécutions locales. 
+Et les structures de données convergentes (CvRDT), par exemple un système où 
+la donnée viserait à croitre continuellement convergeant ainsi vers une 
+structure maximale. Ces deux classes sont regroupées sous la dénomination 
+de type de données sans conflit (CRDT) et sont en réalité équivalentes l’une 
+à l’autre [ShapiroConflictFree2011].
+
+''' \medskip
+
+En outre, pour proposer des solutions véritablement sécurisées dans un
+contexte zéro-trust, les conditions de fonctionnement les plus
+difficiles à considérer sont lorsque des serveurs ou des clients
+participants ont été compromis et ne respectent pas strictement le
+protocole. Dans la littérature, cela s'appelle un fonctionnement
+byzantin.
+
+Etant données ces contraintes difficiles de disponibilité et de sécurité,
+assurer une propriété
+de cohérence forte peut être très coûteux en calcul et en temps. Les
+exigences applicatives ne sont parfois pas compatibles avec de telles
+conditions de fonctionnement. On peut alors considérer des données
+avec des propriétés dites de //cohérences faibles//.
+
+
+
+= État de l'art =
+
+Le paysage des propriétés de //cohérences faibles// est relativement
+complexe. On peut distinguer trois grandes familles de cohérences
+faibles [Raynal18], [MPBook]:
+
+- la sérialisabilité
+- la cohérence causale
+- la cohérence éventuellement forte
+
+
+Si la cohérence éventuellement forte est en général recherchée pour
+les applications collaboratives, elle est particulièrement
+coûteuse. La sérialisabilité est plus simple à implémenter mais
+produit parfois des transactions qui ne terminent pas. Ces situations
+d'erreur doivent alors être gérées par l'application.
+La cohérence
+causale maintient l'ordre causal perçu par chaque processus et permet
+en général d'implémenter des structures de données de plus haut niveau 
+de manière efficace.
+Le lecteur pourra se référer à la cartographie assez exhaustive de
+M. Perrin [MPBook].
+
+
+== Résultats Algorithmiques ==
+
+Les premiers travaux sur des outils collaboratifs sécurisés dans un 
+contexte de haute disponibilité
+datent de 2009, cependant les recherches plus
+systématiques concernant la sécurité des cohérences dites faibles sont
+en fait très récentes.
+En 2009, Sing //et al.// propose le système Zeno qui est le premier
+à proposer un algorithme byzantin qui privilégie la disponibilité sur 
+la cohérence (forte). Il offre une robustesse byzantine à la 
+cohérence éventuellement forte [SinghZeno2009]. L'algorithme montre 
+de manière expérimentale de meilleures performances de disponibilité 
+que les algorithmes byzantins classiques.
+
+Il existe actuellement essentiellement des études et solutions
+partielles pour la cohérence causale [TsengDistributed2019] et
+[VanDerLindePractical2020].  Tseng //et al.// présentent des bornes
+exactes de calculabilité dans un cadre byzantin d'un côté et donnent
+un algorithme dont les performances sont comparées avec ceux de la
+plateforme Google Compute.  Van Der Linde //et al.// présentent un
+système pair-à-pair résistant aux attaques byzantines qui offre des
+garanties de cohérence causale. Leur évaluation considère que malgré
+une architecture pair-à-pair, les performances, notamment en termes de
+latence sont très bonnes en comparaison avec une architecture
+client-serveur classique.
+
+En complément de ces algorithmes, Misra et Kshemkalyani ont montré
+dans [MisraByzantine2021] que dans un contexte asynchrone, il n'est
+pas possible de proposer de la consistance causale même avec un seul
+participant byzantin.
+
+
+L'une des particularités de [VanDerLindePractical2020] est de proposer
+également une réflexion sur les défaillances byzantines dans un
+contexte de cohérences faibles. Un système pair-à-pair tel que celui
+de [MisraByzantine2021] justifie de proposer de nouvelles attaques où
+un participant exploite les informations des couches basses de
+réplication pour créer des attaques au niveau applicatif.
+
+L'application de critères de cohérences faibles ne suffit pas à
+satisfaire le cadre de notre problématique. Le contexte du cloud pose
+notamment de grande questions en termes de centralisation et de
+gouvernance des données, avec un marché dominé par quelques acteurs
+majeurs auxquels les utilisateurs doivent faire confiance de manière
+aveugle. Posant ainsi de grande question sur la confidentialité et la
+souveraineté de leurs informations.
+
+C'est dans ce contexte qu'intégrer la notion d'un cloud zero-trust est
+essentiel en ancrant nos réflexions dans une approche
+pertinente d'un point de vue industriel et réglementaire. Le zero-trust comme défini
+par le NIST dans la SP 800-207 [RoseZero2020] est un modèle de sécurité qui ne fait
+confiance à aucun tiers, et qui ne fait aucune hypothèse sur la
+sécurité du réseau. Il permet ainsi de se préserver des comportements
+malveillants émis par les intermédiaires diminuant la surface
+d'attaque et limitant les comportements byzantins aux seuls clients
+qui eux ont accès aux données.
+
+Evidement ce dernier point est aussi à considérer. C'est pourquoi une
+approche de sécurité centrée sur la donnée en plus des communications
+peut aussi être envisagé en adoptant des approches dites "Data Centric". 
+C'est-à-dire de considérer la donnée elle-même comme un acteur vivant du 
+système en lui attribuant des processus de contrôle d'accès et de suivie 
+[BayukDatacentric2009]. Ces questions représentent des enjeux grandissants et
+sont considérés par les acteurs étatique et inter-étatique à l'image de l'OTAN
+qui statut sur ces problématiques à travers les STANAG 4774 et 4778. Ces 
+questions sont largement étudiées depuis les années 2010 avec des travaux comme 
+[GoyalAttributebased2006, MullerDistributed2009] qui définisse des solutions 
+pour mettre en place du chiffrement par attribut. Consistant à émettre des clés 
+de chiffrements dépendantes de droits, et donc de permettre de définir des 
+politiques de sécurité. Des travaux comme [YanFlexible2017] propose des 
+solutions plus adaptées au cloud en se basant sur des architectures plus 
+flexibles et avec une plus grande granularité dans la définition des droits.
+
+Néanmoins sur les aspects du zero-trust et de la sécurité centrée sur
+la donnée, il n'existe pas encore de travaux académiques concernant
+une formalisation consensuelle de ces notions. Et ces termes sont
+soumis à de nombreuses interprétations. Il reste donc à spécifier
+formellement ces différents termes pour comprendre quelles propriétés
+sont à satisfaire pour réaliser de la cohérence faible dans un
+contexte zero-trust.
+
+== Implémentations Existantes ==
+
+Des projets actuels tentent d'implémenter des protocoles de cohérences faibles pour la mise en place d'applications collaboratives en temps réel. Parmi ces projets on peut citer yjs [Yjs2023] qui implémente le protocole YATA [NicolaescuRealTime2016] et qui permet d'assurer une convergence forte (ou SEC d'après le référentiel de Perrin) à travers un système de type CRDT. 
+D'autres projets plus anciens tel qu'Etherpad utilise des solutions plus simples à base de résolution de conflit continue, assurant aussi une convergence forte mais réalisant des opérations algorithmiques plus complexes en termes de mémoire et de temps de calcul vis-à-vis des CRDTs [AppJetEtherpad2011].
+
+= Objectifs =
+
+Les objectifs de cette thèse sont à la fois d'étudier les trois types
+de cohérence faible en situation byzantine et de définir des
+algorithmes byzantins efficaces pour pouvoir les implémenter. Puisque
+la cohérence causale est déjà bien étudiée, ce sont les deux autres
+cohérences qui seront les principaux axes de recherche de cette thèse.
+
+La première étape (WP1) consistera à étudier des solutions byzantines
+sans primitives cryptographiques, ou avec des primitives
+raisonnablement coûteuses, c'est-à-dire notamment sans calcul
+homomorphe. Une étude des implémentations existantes sera réalisée
+pour notamment déterminer les garanties offertes par ces solutions
+dans le vocabulaire des cohérences faibles.
+
+La deuxième étape (WP2) consistera à produire des solutions plus efficaces
+mais qui utilisent des primitives cryptographiques nécessitant des
+primitives de partage de secret avancées et/ou de calcul homomorphe.
+
+Une dernière étape (WP3) consistera en la production d'une preuve de concept
+de solution de stockage //clef/valeurs// utilisant les algorithmes
+retenus aux étapes précédentes.
+
+
+= Méthodologie et Planning =
+
+Une revue précise des modèles de calcul distribué pour lesquels des
+solutions (principalement de consistance causale) ont été proposées
+sera établie dans le but de déterminer l'ensemble des hypothèses,
+théoriques et pratiques, de validité de ces solutions. En parallèle de
+cetté étude, en relation avec l'entreprise Scille, une liste
+d'attaques sur les architectures pair-à-pairs à cohérence faible sera
+établie.  L'accent sera mis sur la production de connaissances
+nouvelles (nouvelles solutions par rapport à l'état de l'art mais
+également nouvelles attaques).
+
+Les algorithmes seront tout d'abord validé de manière formelle
+avant de voir une preuve de concept développée.
+
+Le WP1 se déroulera en 2024, le WP2 en 2025, et le WP3 en ZO26.
+
+= Modalités de Suivi et d'Échange =
+
+Le doctorant participe aux réunions hebdomadaires de suivi de
+l'entreprise Scille. Les partenaires se rencontreront tous les trois
+mois pour un point d'avancée sur les travaux.
+
+Il participera également aux réunions physiques de
+l'entreprise tous les 6 mois.
+
+= Moyens Matériels =
+
+Le doctorant sera hébergé au Laboratoire d'Informatique et des
+Systèmes. Il bénéficiera de l'environnement scientifique et technique
+d'un laboratoire UMR CNRS de 800 personnes, dont environ 400 personnels permanents .
+
+Du côté de l'entreprise Scille, qui fonctionne en //full remote//, le
+doctorant aura accès à un banc d'essai cloud hébergé par
+l'entreprise. 
+
+
+
+= Retombées Attendues =
+
+Du côté du laboratoire LIS, les retombées attendues sont les publications scientifiques suivantes :
+- état de l'art et synthèse concernant les consistances faibles byzantines
+- propositions et preuves de nouveaux algorithmes dans le contexte zéro-trust
+
+
+Du côté de l'entreprise Scille, il est attendu une mini-maquette de
+synchronisation et collaboration cloud, une preuve de concept des
+algorithmes sus-cités ainsi que du conseil et de l'expertise dans le
+domaine du "développement scientifique" des produits développés par Scille, notamment ``parsec``.
+
+
+
+= Équipe =
+
+==  Équipe  Algorithmique Distribuée (DALGO) ==
+
+L'équipe Algorithmique Distribuée (responsable Arnaud Labourel) fait
+partie du Laboratoire d'Informatique et Systèmes (LIS CNRS UMR 7020).
+du Laboratoire d'Informatique et Systèmes (LIS CNRS UMR 7020).  C'est
+une équipe de recherche reconnue au plus haut niveau international,
+avec 8 membres permanents dont les centres d'intérêt vont des
+algorithmes distribués fiables, de la confidentialité dans les
+systèmes distribués aux réseaux de communication, ainsi qu'aux
+algorithmes de graphes, aux agents mobiles et à l'IoT,
+
+
+== Encadrants ==
+
+**Emmanuel Godard** est professeur à l'Université Aix-Marseille. Ses
+  intérêts de recherche portent principalement sur la compréhension et
+  la maximisation de la décentralisation (en un sens large) dans les
+  systèmes distribués. Il est expert en algorithmique et calculabilité distribuées.
+
+**Corentin Travers** est Maître de Conférences à l'Université
+  Aix-Marseille.  Ses intérêts de recherche portent sur les
+  algorithmes distributés robustes et efficaces pour les systèmes à
+  mémoire partagée ou les réseaux distribués. Il est expert en algorithmique et complexité distribuées.
+
+**Marcos Medrano** est ingénieur R&D chez Scille. Diplômé d'un master de recherche en sciences 
+  de l'informatique et mathématique appliqué. Il est en charge de la stratégie de développement
+  du produit Parsec et réalise le lien entre les ingénieurs et les intervenants académiques.
+
+
+
+== Choix du Candidat ==
+
+L'équipe DALGO est partie prenante du Master "Fiabilité et Sécurité
+Informatique" de l'Université Aix-Marseille. Ce parcours de master est
+labellisé //SecNumEdu// par l'ANSSI. À l'automne 2022, le sujet
+proposé avec l'entreprise Scille a été présenté à l'ensemble des
+étudiants de master. Suite à cet appel à candidature, M. Amaury Joly a
+été retenu pour un stage de recherche préliminaire de 6 mois sur le
+thème des consistances faibles au laboratoire LIS.
+
+Les notes de M. Amaury Joly sont très bonnes, il obtient une mention
+bien au master. Il présente en outre un très bon double profil à la
+fois théorique et technique, sa motivation pour les activités de
+recherche en lien avec la sécurité du Cloud est très forte, il est le
+candidat parfait pour un tel sujet de recherche.
+
+% Références depuis %%INFILE.bib
+''' {\footnotesize
+''\input{sujet-cifre.bbl}''
+''' }
+

Administration/Dossier demande CIFRE ANRT/sujet-cifre.tex

@@ -0,0 +1,436 @@
+\documentclass[11pt]{article}
+\usepackage{graphicx}
+\usepackage{paralist} %% needed for compact lists
+\usepackage[normalem]{ulem} %% needed by strike
+\usepackage[urlcolor=blue,colorlinks=true,breaklinks]{hyperref}
+\usepackage[utf8x]{inputenc}  %% char encoding
+\usepackage{framed} %% frame multipages
+% \usepackage{fullpage}
+\usepackage{a4wide}
+\usepackage{mathpazo} %% math & rm
+\linespread{1.05}        %% Palatino needs more leading (space between lines)
+\usepackage[scaled]{helvet} %% ss
+\usepackage{courier} %% tt
+\normalfont
+\usepackage[T1]{fontenc}
+\usepackage[francais]{babel} %% en francais
+\usepackage{xspace} %% gestion des espaces après une macro
+\usepackage{listings}
+\lstset{breaklines}
+\lstset{language=java}
+\lstset{escapechar=§}
+\usepackage{xcolor}
+
+
+\usepackage{comment} %%%% comment env
+
+%%%%%%%%%%%%%%
+%% fancy et brouillon
+%% Date en haut de page
+%% A commenter pour la version finale
+\usepackage[margin=2.5cm]{geometry}
+\usepackage{fancyhdr}
+%% Header and footer
+\fancyhf{} %%clear head and footer
+\fancyhead[C]{\thepage} %%draft
+\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
+\fancyfoot[C]{\textsc{SUJETCOURT}}
+\fancypagestyle{premiere}{%% première page
+\fancyhf{} %%clear head and footer
+\fancyfoot[L]{\textbf{LIF}}
+\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
+\fancyfoot[C]{\textsc{SUJETCOURT}}
+\fancyhead[C]{}%%\includegraphics[scale=0.25]{logo-lif.png}} %%UFR
+}
+\fancypagestyle{notete}{%% première page
+\fancyhf{} %%clear head and footer
+\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
+\fancyfoot[C]{\textsc{Sujet}}
+}
+
+\newcommand{\myversion}{\textit{version du \today{}}}
+
+\pagestyle{plain}
+
+\title{Cohérences faibles pour le cloud zero-trust}
+\author{SUJET DE RECHERCHE}
+\begin{document}
+
+\date{Emmanuel Godard (LIS) -- Corentin Travers (LIS)\\emmanuel.godard@lis-lab.fr et corentin.travers@lis-lab.fr}
+\maketitle
+
+\textbf{Mots-clefs:} Cloud, Sécurité par conception, Structures et algorithmes distribués, Cohérences faibles, Systèmes byzantins
+
+\section*{Résumé}
+
+Les applications collaboratives en temps réel sont de plus en plus utilisées 
+dans le cadre de la mise en place de systèmes de travail à distance. Ces 
+applications sont souvent basées sur des architectures client-serveur 
+centralisées, ce qui pose des problèmes de sécurité et de confidentialité. Les 
+données sont stockées sur un serveur centralisé, ce qui implique que les 
+utilisateurs doivent faire confiance à un tiers pour la gestion de leurs 
+données. De plus, ces architectures sont souvent vulnérables aux attaques par 
+déni de service, et ne permettent pas de garantir la confidentialité des 
+données.
+
+Pour répondre à ces problématiques, nous proposons d'explorer des
+solutions d'échange de l'information basées sur des architectures sans
+tiers de confiances à travers des approches dites zero-trust et/ou
+pair à pair. Ces solutions nous permettraient de proposer de solutions
+à haut niveau de sécurité tout en garantissant une certaine résilience
+du système. Pour conserver des performances fortes notamment en haute
+disponibilité, les cohérences faibles sont fréquemment utilisées.
+
+Dans ce contexte, nous proposons d'étudier les propriétés de cohérences faibles 
+appliquée aux problématiques liées au cloud. Dans un premier temps sera réalisé 
+un état de l'art sur les solutions byzantines sans primitives cryptographiques, 
+ainsi que sur les différentes implémentations existantes (WP1). Une deuxième 
+étape consistera à proposer des solutions plus efficaces mais utilisant des 
+primitives cryptographiques (WP2). Enfin, une dernière étape consistera en la 
+production d'une preuve de concept de solution de stockage clef/valeurs 
+utilisant les algorithmes retenus aux étapes précédentes (WP3).
+
+\pagebreak
+
+\section*{Problématique}
+
+Depuis les travaux pionniers des années 80, par Lamport
+\cite{LamportInterprocess1986} et Misra \cite{MisraAxioms1986} notamment, la
+gestion de la réplication est au cœur des développements du numérique
+en terme de haute disponibilité. L'une des problématiques
+fondamentales est d'offrir aux développeurs d'applications une
+abstraction de la mémoire répliquée qui soit à la fois simple à
+utiliser et permette de mobiliser de manière souple et résistante
+aux défaillances l'intégralité des ressources distribuées.
+Cette voie de recherche a produit la notion de \textit{cohérence des données}
+dont les nombreuses déclinaisons permette de s'adapter aux meilleurs
+compromis d'usage et spécificités de chaque application.
+
+La tendance actuelle autour de la mise en Cloud des applications
+informatiques implique des modifications importantes dans les usages
+et les modes de développement des nouvelles applications. Dans le cadre de nouvelles facilités d'usage, où la maintenance de l'infrastructure est déléguée à un prestataire, cela a conduit à une centralisation des
+ressources. Cela ré-introduit des problématiques classiques en termes de
+sécurité : nécessité de confiance/souveraineté ou bien
+\textit{point central de défaillance} (SPOF).
+
+De nouvelles approches dites \textit{sans-confiance} (zero-trust) ont donc
+été proposées pour continuer à utiliser ces ressources cloud sans dépendre d'un prestataire particulier. Elles nécessitent à la fois des architectures multi-fournisseurs et des approches cryptographiques avancées. 
+
+\medskip
+
+Du point de vue des programmeurs, il est souvent avantageux de
+considérer de telles applications sur le nuage comme un seul système
+centralisé. Cela nécessite que les structures de données utilisées
+aient une propriété dite de \textit{cohérence forte}.
+
+En conditions réelles, les serveurs peuvent avoir à supporter des
+conditions de fonctionnement très difficiles. Il est bien connu, à la
+fois des théoriciens et des praticiens, par le théorème CAP (Consistency, Availability, Partition tolerance) que des
+compromis de fonctionnement sont souvent nécessaires. En particulier,
+si c'est la cohérence forte qui est recherchée, le temps de calcul
+est proportionnel à la latence de \textbf{tout} le réseau. Ce qui diminue en
+pratique la disponibilité.
+
+Si l'on se réfère au théorème CAP, en appliquant la cohérence forte il 
+est impossible de mettre en place un système hautement résilient, tout 
+en fournissant une application hautement disponible. Ces deux points 
+pouvant néanmoins se retrouver être essentiels dans la réalisation 
+d’une application collaborative.
+
+L’approche pair-à-pair implique en effet une grande résistance du système
+face à la panne. Les répliques sont emmenées à se déconnecter les uns des 
+autres et à avoir des différences de latences importantes et inégales. 
+La non-maitrise du poste et de l’environnement d’exécution de l’application 
+nous pousse à imaginer des systèmes pouvant résister aux pires situations 
+possibles. 
+
+Dans le même temps, la nature de l’application recherchée, qui est la 
+collaboration en temps réel, est liée à la question de la 
+haute disponibilité. Le but étant de permettre à des répliques différentes 
+d’accéder à la même donnée partagée pour un travail en temps réel. Il ne 
+serait donc pas acceptable de proposer des temps de latences trop 
+conséquents entre deux modifications. 
+
+Etant donnée l’impossibilité de satisfaire ces deux aspects nous nous 
+tournons vers l’étude des cohérences faibles, et notamment de la convergence. 
+On peut ainsi définir comme convergent les systèmes respectant la propriété suivante : 
+
+Si les répliques arrêtent de proposer des modifications, alors ces mêmes répliques doivent éventuellement atteindre un état cohérent.
+
+La convergence (ou Eventual Consistency) est particulièrement étudiée. Ainsi 
+un certains nombres de structures de données distribuées proposant de respecter la convergence ont 
+vu le jour. Néanmoins à elles seules, celles-ci ne permettent pas de résoudre notre 
+problématique. En effet cette propriété n'offre pas de garantie sur les comportements durant 
+l’exécution, là exactement où l’incohérence au sein du système est permise 
+par la convergence. Or il ne suffit pas qu’un document converge à terme pour 
+en faire une application d’édition collaborative satisfaisante. Mais il faut aussi 
+proposer des mécanismes pour résoudre les conflits, qui sont inévitables 
+dans l'approche collaborative. Cette résolution doit être réalisée de la manière la 
+plus optimale pour maximiser la préservation du sens donné à chaque modification 
+par la réplique qui l’a émise.
+
+Ces questions ont bien entendu été très étudiées et les différentes solutions 
+proposées particulièrement adaptées dans notre contexte sont les
+\textit{types des données répliqués} (ou Replicated Data Type).
+Il en existe deux classes, les types de 
+données répliquées commutatives (CmRDT), dont les opérations donnent le 
+même résultat, peu importe leurs ordres d’exécutions locales. 
+Et les structures de données convergentes (CvRDT), par exemple un système où 
+la donnée viserait à croitre continuellement convergeant ainsi vers une 
+structure maximale. Ces deux classes sont regroupées sous la dénomination 
+de type de données sans conflit (CRDT) et sont en réalité équivalentes l’une 
+à l’autre \cite{ShapiroConflictFree2011}.
+
+\medskip
+
+En outre, pour proposer des solutions véritablement sécurisées dans un
+contexte zéro-trust, les conditions de fonctionnement les plus
+difficiles à considérer sont lorsque des serveurs ou des clients
+participants ont été compromis et ne respectent pas strictement le
+protocole. Dans la littérature, cela s'appelle un fonctionnement
+byzantin.
+
+Etant données ces contraintes difficiles de disponibilité et de sécurité,
+assurer une propriété
+de cohérence forte peut être très coûteux en calcul et en temps. Les
+exigences applicatives ne sont parfois pas compatibles avec de telles
+conditions de fonctionnement. On peut alors considérer des données
+avec des propriétés dites de \textit{cohérences faibles}.
+
+\section*{État de l'art}
+
+Le paysage des propriétés de \textit{cohérences faibles} est relativement
+complexe. On peut distinguer trois grandes familles de cohérences
+faibles \cite{Raynal18}, \cite{MPBook}:
+
+\begin{compactitem}
+\item la sérialisabilité
+\item la cohérence causale
+\item la cohérence éventuellement forte
+\end{compactitem}
+
+Si la cohérence éventuellement forte est en général recherchée pour
+les applications collaboratives, elle est particulièrement
+coûteuse. La sérialisabilité est plus simple à implémenter mais
+produit parfois des transactions qui ne terminent pas. Ces situations
+d'erreur doivent alors être gérées par l'application.
+La cohérence
+causale maintient l'ordre causal perçu par chaque processus et permet
+en général d'implémenter des structures de données de plus haut niveau 
+de manière efficace.
+Le lecteur pourra se référer à la cartographie assez exhaustive de
+M. Perrin \cite{MPBook}.
+
+\subsection*{Résultats Algorithmiques}
+
+Les premiers travaux sur des outils collaboratifs sécurisés dans un 
+contexte de haute disponibilité
+datent de 2009, cependant les recherches plus
+systématiques concernant la sécurité des cohérences dites faibles sont
+en fait très récentes.
+En 2009, Sing \textit{et al.} propose le système Zeno qui est le premier
+à proposer un algorithme byzantin qui privilégie la disponibilité sur 
+la cohérence (forte). Il offre une robustesse byzantine à la 
+cohérence éventuellement forte \cite{SinghZeno2009}. L'algorithme montre 
+de manière expérimentale de meilleures performances de disponibilité 
+que les algorithmes byzantins classiques.
+
+Il existe actuellement essentiellement des études et solutions
+partielles pour la cohérence causale \cite{TsengDistributed2019} et
+\cite{VanDerLindePractical2020}.  Tseng \textit{et al.} présentent des bornes
+exactes de calculabilité dans un cadre byzantin d'un côté et donnent
+un algorithme dont les performances sont comparées avec ceux de la
+plateforme Google Compute.  Van Der Linde \textit{et al.} présentent un
+système pair-à-pair résistant aux attaques byzantines qui offre des
+garanties de cohérence causale. Leur évaluation considère que malgré
+une architecture pair-à-pair, les performances, notamment en termes de
+latence sont très bonnes en comparaison avec une architecture
+client-serveur classique.
+
+En complément de ces algorithmes, Misra et Kshemkalyani ont montré
+dans \cite{MisraByzantine2021} que dans un contexte asynchrone, il n'est
+pas possible de proposer de la consistance causale même avec un seul
+participant byzantin.
+
+L'une des particularités de \cite{VanDerLindePractical2020} est de proposer
+également une réflexion sur les défaillances byzantines dans un
+contexte de cohérences faibles. Un système pair-à-pair tel que celui
+de \cite{MisraByzantine2021} justifie de proposer de nouvelles attaques où
+un participant exploite les informations des couches basses de
+réplication pour créer des attaques au niveau applicatif.
+
+L'application de critères de cohérences faibles ne suffit pas à
+satisfaire le cadre de notre problématique. Le contexte du cloud pose
+notamment de grande questions en termes de centralisation et de
+gouvernance des données, avec un marché dominé par quelques acteurs
+majeurs auxquels les utilisateurs doivent faire confiance de manière
+aveugle. Posant ainsi de grande question sur la confidentialité et la
+souveraineté de leurs informations.
+
+C'est dans ce contexte qu'intégrer la notion d'un cloud zero-trust est
+essentiel en ancrant nos réflexions dans une approche
+pertinente d'un point de vue industriel et réglementaire. Le zero-trust comme défini
+par le NIST dans la SP 800-207 \cite{RoseZero2020} est un modèle de sécurité qui ne fait
+confiance à aucun tiers, et qui ne fait aucune hypothèse sur la
+sécurité du réseau. Il permet ainsi de se préserver des comportements
+malveillants émis par les intermédiaires diminuant la surface
+d'attaque et limitant les comportements byzantins aux seuls clients
+qui eux ont accès aux données.
+
+Evidement ce dernier point est aussi à considérer. C'est pourquoi une
+approche de sécurité centrée sur la donnée en plus des communications
+peut aussi être envisagé en adoptant des approches dites "Data Centric". 
+C'est-à-dire de considérer la donnée elle-même comme un acteur vivant du 
+système en lui attribuant des processus de contrôle d'accès et de suivie 
+\cite{BayukDatacentric2009}. Ces questions représentent des enjeux grandissants et
+sont considérés par les acteurs étatique et inter-étatique à l'image de l'OTAN
+qui statut sur ces problématiques à travers les STANAG 4774 et 4778. Ces 
+questions sont largement étudiées depuis les années 2010 avec des travaux comme 
+\cite{GoyalAttributebased2006, MullerDistributed2009} qui définisse des solutions 
+pour mettre en place du chiffrement par attribut. Consistant à émettre des clés 
+de chiffrements dépendantes de droits, et donc de permettre de définir des 
+politiques de sécurité. Des travaux comme \cite{YanFlexible2017} propose des 
+solutions plus adaptées au cloud en se basant sur des architectures plus 
+flexibles et avec une plus grande granularité dans la définition des droits.
+
+Néanmoins sur les aspects du zero-trust et de la sécurité centrée sur
+la donnée, il n'existe pas encore de travaux académiques concernant
+une formalisation consensuelle de ces notions. Et ces termes sont
+soumis à de nombreuses interprétations. Il reste donc à spécifier
+formellement ces différents termes pour comprendre quelles propriétés
+sont à satisfaire pour réaliser de la cohérence faible dans un
+contexte zero-trust.
+
+\subsection*{Implémentations Existantes}
+
+Des projets actuels tentent d'implémenter des protocoles de cohérences faibles pour la mise en place d'applications collaboratives en temps réel. Parmi ces projets on peut citer yjs \cite{Yjs2023} qui implémente le protocole YATA \cite{NicolaescuRealTime2016} et qui permet d'assurer une convergence forte (ou SEC d'après le référentiel de Perrin) à travers un système de type CRDT. 
+D'autres projets plus anciens tel qu'Etherpad utilise des solutions plus simples à base de résolution de conflit continue, assurant aussi une convergence forte mais réalisant des opérations algorithmiques plus complexes en termes de mémoire et de temps de calcul vis-à-vis des CRDTs \cite{AppJetEtherpad2011}.
+
+\section*{Objectifs}
+
+Les objectifs de cette thèse sont à la fois d'étudier les trois types
+de cohérence faible en situation byzantine et de définir des
+algorithmes byzantins efficaces pour pouvoir les implémenter. Puisque
+la cohérence causale est déjà bien étudiée, ce sont les deux autres
+cohérences qui seront les principaux axes de recherche de cette thèse.
+
+La première étape (WP1) consistera à étudier des solutions byzantines
+sans primitives cryptographiques, ou avec des primitives
+raisonnablement coûteuses, c'est-à-dire notamment sans calcul
+homomorphe. Une étude des implémentations existantes sera réalisée
+pour notamment déterminer les garanties offertes par ces solutions
+dans le vocabulaire des cohérences faibles.
+
+La deuxième étape (WP2) consistera à produire des solutions plus efficaces
+mais qui utilisent des primitives cryptographiques nécessitant des
+primitives de partage de secret avancées et/ou de calcul homomorphe.
+
+Une dernière étape (WP3) consistera en la production d'une preuve de concept
+de solution de stockage \textit{clef/valeurs} utilisant les algorithmes
+retenus aux étapes précédentes.
+
+\section*{Méthodologie et Planning}
+
+Une revue précise des modèles de calcul distribué pour lesquels des
+solutions (principalement de consistance causale) ont été proposées
+sera établie dans le but de déterminer l'ensemble des hypothèses,
+théoriques et pratiques, de validité de ces solutions. En parallèle de
+cetté étude, en relation avec l'entreprise Scille, une liste
+d'attaques sur les architectures pair-à-pairs à cohérence faible sera
+établie.  L'accent sera mis sur la production de connaissances
+nouvelles (nouvelles solutions par rapport à l'état de l'art mais
+également nouvelles attaques).
+
+Les algorithmes seront tout d'abord validé de manière formelle
+avant de voir une preuve de concept développée.
+
+Le WP1 se déroulera en 2024, le WP2 en 2025, et le WP3 en ZO26.
+
+\section*{Modalités de Suivi et d'Échange}
+
+Le doctorant participe aux réunions hebdomadaires de suivi de
+l'entreprise Scille. Les partenaires se rencontreront tous les trois
+mois pour un point d'avancée sur les travaux.
+
+Il participera également aux réunions physiques de
+l'entreprise tous les 6 mois.
+
+\section*{Moyens Matériels}
+
+Le doctorant sera hébergé au Laboratoire d'Informatique et des
+Systèmes. Il bénéficiera de l'environnement scientifique et technique
+d'un laboratoire UMR CNRS de 800 personnes, dont environ 400 personnels permanents .
+
+Du côté de l'entreprise Scille, qui fonctionne en \textit{full remote}, le
+doctorant aura accès à un banc d'essai cloud hébergé par
+l'entreprise. 
+
+\section*{Retombées Attendues}
+
+Du côté du laboratoire LIS, les retombées attendues sont les publications scientifiques suivantes :
+
+\begin{compactitem}
+\item état de l'art et synthèse concernant les consistances faibles byzantines
+\item propositions et preuves de nouveaux algorithmes dans le contexte zéro-trust
+\end{compactitem}
+
+Du côté de l'entreprise Scille, il est attendu une mini-maquette de
+synchronisation et collaboration cloud, une preuve de concept des
+algorithmes sus-cités ainsi que du conseil et de l'expertise dans le
+domaine du "développement scientifique" des produits développés par Scille, notamment \texttt{parsec}.
+
+\section*{Équipe}
+
+\subsection*{Équipe  Algorithmique Distribuée (DALGO)}
+
+L'équipe Algorithmique Distribuée (responsable Arnaud Labourel) fait
+partie du Laboratoire d'Informatique et Systèmes (LIS CNRS UMR 7020).
+du Laboratoire d'Informatique et Systèmes (LIS CNRS UMR 7020).  C'est
+une équipe de recherche reconnue au plus haut niveau international,
+avec 8 membres permanents dont les centres d'intérêt vont des
+algorithmes distribués fiables, de la confidentialité dans les
+systèmes distribués aux réseaux de communication, ainsi qu'aux
+algorithmes de graphes, aux agents mobiles et à l'IoT,
+
+\subsection*{Encadrants}
+
+\textbf{Emmanuel Godard} est professeur à l'Université Aix-Marseille. Ses
+  intérêts de recherche portent principalement sur la compréhension et
+  la maximisation de la décentralisation (en un sens large) dans les
+  systèmes distribués. Il est expert en algorithmique et calculabilité distribuées.
+
+\textbf{Corentin Travers} est Maître de Conférences à l'Université
+  Aix-Marseille.  Ses intérêts de recherche portent sur les
+  algorithmes distributés robustes et efficaces pour les systèmes à
+  mémoire partagée ou les réseaux distribués. Il est expert en algorithmique et complexité distribuées.
+
+\textbf{Marcos Medrano} est ingénieur R\&D chez Scille. Diplômé d'un master de recherche en sciences 
+  de l'informatique et mathématique appliqué. Il est en charge de la stratégie de développement
+  du produit Parsec et réalise le lien entre les ingénieurs et les intervenants académiques.
+
+\subsection*{Choix du Candidat}
+
+L'équipe DALGO est partie prenante du Master "Fiabilité et Sécurité
+Informatique" de l'Université Aix-Marseille. Ce parcours de master est
+labellisé \textit{SecNumEdu} par l'ANSSI. À l'automne 2022, le sujet
+proposé avec l'entreprise Scille a été présenté à l'ensemble des
+étudiants de master. Suite à cet appel à candidature, M. Amaury Joly a
+été retenu pour un stage de recherche préliminaire de 6 mois sur le
+thème des consistances faibles au laboratoire LIS.
+
+Les notes de M. Amaury Joly sont très bonnes, il obtient une mention
+bien au master. Il présente en outre un très bon double profil à la
+fois théorique et technique, sa motivation pour les activités de
+recherche en lien avec la sécurité du Cloud est très forte, il est le
+candidat parfait pour un tel sujet de recherche.
+
+{\footnotesize
+  \nocite{*}
+
+  \bibliography{sujet-cifre.bib}
+  \bibliographystyle{alpha}
+}
+
+% LaTeX2e code generated by txt2tags 3.4 (http://txt2tags.org)
+% cmdline: txt2tags -t tex sujet-cifre.t2t
+\end{document}

Administration/Dossier demande CIFRE ANRT/sujet.tex

@@ -0,0 +1,110 @@
+\documentclass[11pt]{article}
+\usepackage{graphicx}
+\usepackage{paralist} %% needed for compact lists
+\usepackage[normalem]{ulem} %% needed by strike
+\usepackage[urlcolor=blue,colorlinks=true,breaklinks]{hyperref}
+%% 
+\usepackage[utf8x]{inputenc}  %% char encoding
+\usepackage{framed} %% frame multipages
+%% Autres Packages
+%%\usepackage{fullpage}
+\usepackage{a4wide}
+%% Palatino for rm and math | Helvetica for ss | Courier for tt
+\usepackage{mathpazo} %% math & rm
+\linespread{1.05}        %% Palatino needs more leading (space between lines)
+\usepackage[scaled]{helvet} %% ss
+\usepackage{courier} %% tt
+\normalfont
+\usepackage[T1]{fontenc}
+\usepackage[francais]{babel} %% en francais
+\usepackage{xspace} %% gestion des espaces après une macro
+%% code Java
+\usepackage{listings}
+\lstset{breaklines}
+\lstset{language=java}
+%% latex code in the listings
+\lstset{escapechar=§}
+%%\lstset{numbers=left}
+%%\lstset{frame=single}
+\usepackage{xcolor}
+%%
+
+
+%% \usepackage{etoolbox} %%%% toggle
+\usepackage{comment} %%%% comment env
+%% \newtoggle{corr}
+%% \toggleT2TMODE{corr}
+%% \iftoggle{corr}{%%%%
+%%   \newenvironment{corrige}{\comment}{\endcomment}
+%% }{%%%%
+%%   \newenvironment{corrige}{\begin{oframed}}{\end{oframed}}
+%% }
+
+%%%%%%%%%%%%%%
+%% fancy et brouillon
+%% Date en haut de page
+%% A commenter pour la version finale
+%%\usepackage[head=12pt,foot=36pt,voffset=-12pt]{geometry}
+\usepackage[margin=2.5cm]{geometry}
+\usepackage{fancyhdr}
+%% Header and footer
+\fancypagestyle{plain}{%%
+\fancyhf{} %%clear head and footer
+\fancyhead[C]{\thepage} %%draft
+%%\fancyfoot[L]{\textbf{LIF}}
+\fancyfoot[R]{\textbf{%(HEADER3)s}} %%except the page number
+\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
+\fancyfoot[C]{\textsc{SUJETCOURT}}
+}
+\fancypagestyle{premiere}{%% première page
+\fancyhf{} %%clear head and footer
+\fancyfoot[L]{\textbf{LIF}}
+\fancyfoot[R]{\textbf{%(HEADER3)s}} %%except the page number
+\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
+\fancyfoot[C]{\textsc{SUJETCOURT}}
+\fancyhead[C]{}%%\includegraphics[scale=0.25]{logo-lif.png}} %%UFR
+}
+\fancypagestyle{notete}{%% première page
+\fancyhf{} %%clear head and footer
+%%\fancyfoot[L]{\textbf{LIF}}
+\fancyfoot[R]{\textbf{%(HEADER3)s}} %%except the page number
+\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
+\fancyfoot[C]{\textsc{Sujet}}
+}
+
+\usepackage{%(STYLE)s}  %% user defined
+
+%%
+\newcommand{\myversion}{\textit{version du \today{}}}
+
+\title{%%\includegraphics[scale=0.25]{logo-lif.png}\\\vspace{1cm}
+%(HEADER1)s}
+\author{%(HEADER2)s}
+%%\date{%(HEADER3)s}
+
+\pagestyle{plain}
+
+\begin{document}
+
+%%\maketitle
+\begin{center}
+{\LARGE %(HEADER1)s}
+  \vspace{0.3cm}
+  
+  {\large \begin{minipage}{0.75\textwidth}
+      \begin{center}
+        %(HEADER2)s\\
+        %(HEADER3)s
+        \end{center}
+      \end{minipage}
+}
+\vspace{0.35cm}
+\end{center}
+%%\thispagestyle{premiere}
+\thispagestyle{empty}
+
+%%
+
+%(BODY)s
+
+\end{document}

README.md

@@ -1,7 +1,7 @@
 # Consistence Faible Byzantine Pour le Cloud
 
-Ce projet est hébergé ici: [https://amauryjoly.fr/gitea/amaury_joly/bwconsistency](https://amauryjoly.fr/gitea/amaury_joly/bwconsistency).  
-Un miror est disponible sur le gitlab du laboratoire du LIS: [https://gitlab.lis-lab.fr/amaury.joly/bwconsistency](https://gitlab.lis-lab.fr/amaury.joly/bwconsistency)
+Ce projet est hébergé ici: <https://amauryjoly.fr/gitea/amaury_joly/bwconsistency>.  
+Un miror est disponible sur le gitlab du laboratoire du LIS: <https://gitlab.lis-lab.fr/amaury.joly/bwconsistency>
 
 ## Introduction
 

Recherche/AC over Message-passing/readme.md

@@ -0,0 +1,212 @@
+## Allow List over PC
+
+### Modele
+
+**Base de Mathieu**
+
+Soit $\\Pi$ l'ensemble des processus $p_1, ... p_N$
+$\\Pi_M \\subseteq \\Pi$ les processus autorisés à $APPEND(x)$
+$\\Pi_V \\subseteq \\Pi$ les processus autorisés à $PROVE(x)$
+
+Chaque processus est séquentiel mais le système est asynchrone (le $\\Delta$ de vitesse d'horloge relative est inconnue par les processus) Le système est crash prône
+
+Tous les processus ont un identifiant et les IDs sont connues de tous les processus.
+
+**Spécificité Message-Passing**
+
+2 opérations possibles:
+
+- $send(O, p_i)$
+- $recv(O, p_i)$
+
+$H$ l'ensemble des séquences d'opérations $H|p_i$ les opérations relatives à $p_i$ $H|x$ l'ensemble des séquences d'opérations relatives à l'objet $x$ Les processus peuvent être byzantin en ne suivant pas le protocole définit. On admet que la transmission des message respecte les propriétés de reliable broadcast. C'est a dire que tous les messages envoyés sont reçu par tous. Et que pour deux message envoyé dans un ordre précis par un même processus ils seront reçu dans ce même ordre par tous les autres processus.
+
+### Problematique
+
+$O$ ensemble des types d'opérations :
+
+- $APPEND(x)$
+- $PROVE(x)$
+- $READ()$
+
+On veut remplir les propriétés suivantes :
+
+- Termination: toutes les opérations terminent par un "return"
+- APPEND validity: Un APPEND(x) est valide ssi $\\forall p_i$ t.q. $send(APPEND(x)) \\in H| p_i$. $p_i \\in \\Pi_M \\subseteq \\Pi$
+- PROVE validity: Un PROVE(x) est valide ssi $\\forall p_i$ t.q. $send(PROVE(x)) \\in H| p_i$. $p_i \\in \\Pi_V \\subseteq \\Pi$ ET un $APPEND(x)$ apparait dans $\\Pi_V$
+- Progress: si un $APPPEND(x)$ est valide alors il exist $\\forall p_i$ un point dans $H|p_i$ tel que tous les $PROVE(x)$ sont valident.
+- READ validity: $\\forall p_i$ l'opération $READ()$ doit retourner toutes les opérations $PROVE(...) \\in H|p_i$
+
+### Algo
+
+```
+appends a set of objetcs
+proves a set of tuples of (objetc, process id)
+
+recv(APPEND(x), p_j)
+  if p_j \in \Pi_M
+    appends += x
+  return
+
+recv(PROVE(x), p_j)
+  if p_j \in \Pi_V
+    if x \in appends
+      proves += (x, p_j)
+  return
+
+APPEND()
+  if p_i \in \Pi_V
+    appends += x
+    send(APPEND(x), p_i)
+  return
+  
+PROVE(x)
+  if p_i \in \Pi_M
+    if x \in appends
+        proves += (x, p_i)
+        send(PROVE(x), p_i)
+  return
+
+READ()
+  return proves
+```
+
+### Preuve
+
+**Termination**
+
+Toutes les fonctions sont séquentiels et synchrones. Il n'y a aucune boucle, les fonctions terminent forcements.
+
+**APPEND Validity**
+
+La condition `if p_j \in \Pi_M` dans la fonction APPEND(x) garantit qu'aucun processus légitime ne peut ajouter d’élément dans la whitelist si il n'est pas manageur. Cette même condition dans recv(APPEND(x)) garantit qu'aucun processus légitime n'acceptera d'ajout d'élément soumis par un processus non manageur. Cette garantit repose sur le fait que les identifiants sont infalsifiables.
+
+**PROVE Validity**
+
+La condition `if p_j \in \Pi_V` dans la fonction PROVE(x) garantit qu'aucun processus légitime ne peut ajouter d’élément dans la whitelist si il n'est pas validateur. Cette même condition dans recv(PROVE(x)) garantit qu'aucun processus légitime n'acceptera d'ajout d'élément soumis par un processus non validateur. Cette garantit repose sur le fait que les identifiants sont infalsifiables.
+
+De même la condition `if x \in appends` dans PROVE(x) assure que le processus courant a déjà reçu ou émis lui même un APPEND(x), puisque la seule manière d'ajouter un élément a l’ensemble `appends` est via les fonctions recv(APPEND(x)) et APPEND(x) une fois que les conditions de APPEND Validity sont respectés. De la même manière cette condition dans recv(PROVE(x)) assure qu'une requête PROVE(x) envoyé par un validateur malveillant ne faisant pas suite à un APPEND(x) ne soit pas considéré par les processus légitimes.
+
+**PROGRESS**
+
+Étant donné que tout message est eventually reçu. Tout APPEND(x) valide sera envoyé via la fonction `send` et sera reçu dans un temps $\\delta t$ par tous les processus. Avec $\\delta t$ étant le temps de transmission le plus long entre deux processus. Cette borne supérieur $\\delta t$ peut etre définit dans un système synchrone en admettant une borne maximal pour la transmission la plus lente entre deux `p`. Assurant ainsi que chaque APPEND(x) valide sera considéré par l'ensemble du système à $t + \\delta t$.  
+Cependant dans un système asynchrone ce $\\delta t$ est par définition non définit, rendent la propriété de PROGRESS insatisfaisable.
+
+**READ Validity**
+
+Pour ce point il convient de démontrer que tout tuple dans proves se trouve bien dans $\\forall PROVE(..) \\in H|p_i$ tel que $p_i$ le processus invoquant le READ. L'ajout a l'ensemble proves dépend des fonctions PROVE() et recv(PROVE()).  
+Dans ces deux fonctions on assure déjà la validité des PROVE pour $p_i$. Tout PROVE valide reçu ou émis par p_i est donc ajouté dans proves, ce qui correspond bien aux opérations proves de $H|p_i$.
+
+## Deny List over PC
+
+### Modele
+
+__Base de Mathieu__
+
+Soit $\\Pi$ l'ensemble des processus $p_1, ... p_N$
+$\\Pi_M \\subseteq \\Pi$ les processus autorisés à $APPEND(x)$
+$\\Pi_V \\subseteq \\Pi$ les processus autorisés à $PROVE(x)$
+
+Chaque processus est séquentiel mais le système est asynchrone (le $\\Delta$ de vitesse d'horloge relative est inconnue par les processus) Le système est crash prône
+
+Tous les processus ont un identifiant et les ids sont connues de tous les processus.
+
+**Spécificité Message-Passing**
+
+2 opérations possibles:
+
+- $send(O, p_i)$
+- $recv(O, p_i)$
+
+$H$ l'ensemble des séquences d'opérations $H|p_i$ les opérations relatives à $p_i$ $H|x$ l'ensemble des séquences d'opérations relatives à l'objet $x$ Les processus peuvent être byzantin en ne suivant pas le protocole définit. On admet que la transmission des message respecte les propriétés de reliable broadcast. C'est a dire que tous les messages envoyés sont reçu par tous. Et que pour deux message envoyé dans un ordre précis par un même processus ils seront reçu dans ce même ordre par tous les autres processus.
+
+### Problématique
+
+$O$ ensemble des types d'opérations :
+
+- $APPEND(x)$
+- $PROVE(x)$
+- $READ()$
+
+On veut remplir les propriétés suivantes :
+
+- Termination: toutes les opérations terminent par un "return"
+- APPEND validity: Un APPEND(x) est valide ssi $\\forall p_i$ t.q. $send(APPEND(x)) \\in H| p_i$. $p_i \\in \\Pi_M \\subseteq \\Pi$
+- PROVE validity: Un PROVE(x) est __invalid__ ssi $\\forall p_i$ t.q. $send(PROVE(x)) \\in H| p_i$. $p_i \\in \\Pi_V \\subseteq \\Pi$ ET un $APPEND(x)$ apparait dans $\\Pi_V$
+- PROVE Anti-Flickering: Si une opération PROVE(x) invalide est soumise ou recu par un processus alors toutes les opérations PROVE(x) futur seront invalides
+- READ validity: $\\forall p_i$ l'opération $READ()$ doit retourner toutes les opérations $PROVE(...) \\in H|p_i$
+
+### Algo
+
+```
+appends a set of objetcs
+proves a set of tuples of (objetc, process id)
+
+recv(APPEND(x), p_j)
+  if p_j \in \Pi_M
+    appends += x
+  return
+
+recv(PROVE(x), p_j)
+  if p_j \in \Pi_V
+    if x \neg\in appends
+      proves += (x, p_j)
+  return
+
+APPEND()
+  if p_i \in \Pi_V
+    appends += x
+    send(APPEND(x), p_i)
+  return
+  
+PROVE(x)
+  if p_i \in \Pi_M
+    if x \neg\in appends
+        proves += (x, p_i)
+        send(PROVE(x), p_i)
+  return
+
+READ()
+  return proves
+```
+
+### Preuve
+
+**Termination**
+
+Toutes les fonctions sont séquentiels et synchrones. Il n'y a aucune boucle, les fonctions terminent forcements.
+
+**APPEND Validity**
+
+La condition `if p_j \in \Pi_M` dans la fonction APPEND(x) garantit qu'aucun processus légitime ne peut ajouter d’élément dans la whitelist si il n'est pas manageur. Cette même condition dans recv(APPEND(x)) garantit qu'aucun processus légitime n'acceptera d'ajout d'élément soumis par un processus non manageur. Cette garantit repose sur le fait que les identifiants sont infalsifiables.
+
+**PROVE Validity**
+
+La condition `if p_j \in \Pi_V` dans la fonction PROVE(x) garantit qu'aucun processus légitime ne peut ajouter d’élément dans la whitelist si il n'est pas validateur. Cette même condition dans recv(PROVE(x)) garantit qu'aucun processus légitime n'acceptera d'ajout d'élément soumis par un processus non validateur. Cette garantit repose sur le fait que les identifiants sont infalsifiables.
+
+De même la condition `if x \neg\in appends` dans PROVE(x) assure que le processus courant n'a pas déjà reçu ou émis lui même un APPEND(x), puisque la seule manière d'ajouter un élément a l’ensemble `appends` est via les fonctions recv(APPEND(x)) et APPEND(x) une fois que les conditions de APPEND Validity sont respectés.  
+De la même manière cette condition dans recv(PROVE(x)) assure qu'une requête PROVE(x) envoyé par un validateur malveillant faisant suite à un APPEND(x) ne soit pas considéré par les processus legéitimes.
+
+**ANTI-FLICKERING**
+
+Étant donné que tout message est eventually reçu. Tout APPEND(x) valide sera envoyé via la fonction `send` et sera reçu dans un temps $\\delta t$ par tous les processus. Avec $\\delta t$ étant le temps de transmission le plus long entre deux processus. Cette borne supérieur $\\delta t$ peut etre définit dans un système synchrone en admettant une borne maximal pour la transmission la plus lente entre deux `p`. Assurant ainsi que chaque APPEND(x) valide sera considéré par l'ensemble du système à $t + \\delta t$.  
+Cependant dans un système asynchrone ce $\\delta t$ est par définition non définit, rendent la propriété d'anti-flickring insatisfaisable.
+
+__READ Validity__
+
+Pour ce point il convient de démontrer que tout tuple dans proves se trouve bien dans l'ensemble $E$, tel que $\\forall e \\in E$, $e = PROVE(x)$ et tel que $H'|p_i$ l'ensemble des opérations reçu et émise avant l'opération $e$, alors $\\nexists e' \\in H'|p_i$ t.q. $e' = APPEND(x)$  avec $p_i$ le processus invoquant le READ.  
+L'ajout a l'ensemble proves dépend des fonctions PROVE() et recv(PROVE()). Dans ces deux fonctions on assure déjà la validité des PROVE pour $p_i$. Tout PROVE valide reçu ou émis par p_i est donc ajouté dans proves, ce qui correspond bien aux opérations proves de $H|p_i$.
+
+## Discussion
+
+Il est impossible d’implémenter une AllowList ou DenyList dans un système asynchrone, ce qui conditionne déjà notre model sur ce point. Les propriétés de PROGRESS et d'ANTIFLICKERING étant directement lié à ce point.
+
+Les points facilitant la résolution de notre problème sont d'une part la présence du ReliableBroadcast et d'autre part d'un identifiant infalsifiable. Les deux points étant lié puisque nous pouvons admettre que le reliable broadcast peut aussi s'occuper de l'authentification des messages, et de leur non répudiabilité.
+
+Un axe d'amélioration est donc d'affaiblir le reliable broadcast pour ça il faut définir les propriétés essentiels a l’exécution de notre algorithme.
+
+### RB
+
+- Non répudiabilité (une fois que le message ets envoyé il est impossible pour un processus de le nier)
+- Tout message envoyé est recu par tout le monde(eventual delivery)
+- Immutabilité du message une fois qu'il est émis

Recherche/ALDLoverAB/algo/index.tex

@@ -0,0 +1,73 @@
+We consider a set of processes communicating asynchronously over reliable point-to-point channels. Each process maintains the following local or shared variables:
+
+\begin{itemize}
+  \item \textbf{\textit{received}}: the set of messages that have been received via the reliable broadcast primitive but not yet ordered.
+  \item \textbf{\textit{delivered}}: the set of messages that have been ordered.
+  \item \textbf{\textit{prop}[$r$][$j$]}: the proposal set announced by process $j$ at round $r$. It contains a set of messages that process $j$ claims to have received but not yet delivered.
+  \item \textbf{\textit{winner}$^r$}: the set of processes that have issued a valid \texttt{PROVE} for round $r$, as observed through the registry.
+  \item \textbf{\texttt{R-Broadcast}$(\texttt{PROP}, S, r, j)$}: a reliable broadcast invocation that disseminates the proposal $S$ from process $j$ for round $r$.
+  \item \textbf{\texttt{R-Delivered}$(\texttt{PROP}, S, r, j)$}: the handler invoked upon reception of a \texttt{RB-cast}, which stores the received proposal $S$ into $\textit{prop}[r][j]$.
+  \item \textbf{\texttt{READ}()} : returns the current view of all valid operations stored in the DenyList registry.
+  \item \textbf{\texttt{ordered}$(S)$}: returns a deterministic total order over a set $S$ of messages.
+  \item \textbf{\texttt{hash}$(T, r)$}: returns the identifier of the next round as a deterministic function of the delivered set $T$ and current round $r$.
+\end{itemize}
+
+\resetalgline
+\begin{algorithm}
+  \caption{Atomic Broadcast with DenyList}
+  \begin{algorithmic}[1]    
+    \State $\textit{received} \gets \emptyset$
+    \State $\textit{delivered} \gets \emptyset$
+    \State $r_1 \gets 0$
+
+    \vspace{1em}
+    % --- A-Broadcast ---
+    \State \nextalgline \textbf{A-Broadcast}$_j(m)$
+    \State \nextalgline \hspace{1em} $\texttt{R-Broadcast}_j(m)$
+
+    \vspace{1em}
+    % --- R-delivered ---
+    \State \nextalgline \textbf{R-Delivered}$_j(m)$
+    \State \nextalgline \hspace{1em} $\textit{received} \gets \textit{received} \cup \{m\}$
+    \State \nextalgline \hspace{1em} \textbf{repeat while} $\textit{received} \setminus \textit{delivered} \neq \emptyset$
+    \State \nextalgline \hspace{2em} $S \gets \textit{received} \setminus \textit{delivered}$
+    \State \nextalgline \hspace{2em} $\texttt{R-Broadcast}(\texttt{PROP}, S, r_1, j)$
+
+    \vspace{0.5em}
+    \State \nextalgline \hspace{2em} \textbf{wait until } $|\{j_1 : |\{i_1 : (i_1, \textit{PROVE}(<r_1, j_1>)) \in \texttt{READ}[i_1]()\}| \geq n - f\}| \geq n -f$
+    \State \nextalgline \hspace{2em} $\texttt{APPEND\_LINE}[j](r_1)$
+    \State \nextalgline \hspace{2em} $B[r_1] \gets {1, ..., n}$ 
+    \State \nextalgline \hspace{2em} \textbf{do}
+    \State \nextalgline \hspace{3em} \textbf{for each } $j_1 \in B[r_1]$
+    \State \nextalgline \hspace{4em} \textbf{if } $\nexists i_1 \text{ s.t. } \texttt{PROVE}[j_1](<r_1, i_1>) == \text{TRUE}$
+    \State \nextalgline \hspace{5em} $B[r_1] \gets B[r_1] \setminus \{j_1\}$
+    \State \nextalgline \hspace{2em} \textbf{while } $|B[r_1]| \geq f+1$
+    \State \nextalgline \hspace{2em} $\textit{winner}[r_1] \gets \{j_1 : |\{i_1 : (i_1, \textit{PROVE}(<r_1, j_1>)) \in \texttt{READ}[i_1]()\}| \geq n - f\}$
+
+    \vspace{0.5em}
+    \State \nextalgline \hspace{2em} \textbf{wait } $\forall j \in \textit{winner}[r_1],\ \textit{prop}[r_1][j] \neq \bot$
+    \State \nextalgline \hspace{2em} $M \gets \bigcup_{j \in \textit{winner}[r_1]} \textit{prop}[r_1][j] \setminus \textit{delivered}$
+    \State \nextalgline \hspace{2em} \textbf{for each } $m \in \texttt{ordered}(M)$
+    \State \nextalgline \hspace{3em} $\textit{delivered} \gets \textit{delivered} \cup \{m\}$
+    \State \nextalgline \hspace{3em} $\texttt{A-Delivered}_j(m)$
+    \State \nextalgline \hspace{2em} $r_1 \gets \textit{hash}(M, r_1)$
+
+    \vspace{1em}
+    % --- R-Delivered ---
+    \State \nextalgline \textbf{R-Delivered}$_j(PROP, S, r, j_j)$
+    \State \nextalgline \hspace{1em} $\textit{prop}[r][j_j] \gets S$
+    \State \nextalgline \hspace{1em} \texttt{PROVE}$[j](<r, j_1>)$ 
+
+    \vspace{1em}
+    % --- APPEND_LINE() ---
+    \State \nextalgline \textbf{APPEND\_LINE}$_j(r)$
+    \State \nextalgline \hspace{1em} \textbf{for each } $i_1 \in (1, ... , n)$
+    \State \nextalgline \hspace{2em} \texttt{APPEND}$[j](<r, i_1>)$
+
+  \end{algorithmic}  
+\end{algorithm}
+
+\subsection{Round mecansism}
+
+We assume that the hash function is deterministic and without collisions. Because we're sure that the round contains at least f + 1 processes as winners, the next round ID is unpredictable by a process who would not follow the protocol and would drop messages legally sent by non-byzantine process.
+Also, it ensures that if a byzantine process try to go faster than the others, he will at least wait the faster non-byzantine process to progress.

Recherche/ALDLoverAB/intro/index.tex

@@ -0,0 +1,85 @@
+
+\subsubsection{Model Properties}
+
+The system consists of \textit{n} asynchronous processes communicating via reliable point-to-point message passing. \\
+Each process has a unique, unforgeable identifier and knows the identifiers of all other processes. \\
+Up to $f<n$ processes may crash (fail-stop). \\
+The network is reliable: if a correct process sends a message to another correct process, it is eventually delivered. \\
+Messages are uniquely identifiable: two messages sent by distinct processes or at different rounds are distinguishable \\
+2 messages sent by the same processus in two differents rounds are differents \\
+
+\begin{property}[Message Uniqueness]
+  If two messages are sent by different processes, or by the same process in different rounds, then the messages are distinct. \\
+  Formally : \\
+  \[
+  \forall p_1, p_2,\ \forall r_1, r_2,\ \forall m_1, m_2,\ 
+  \left(
+  \begin{array}{l}
+  \text{send}(p_1, r_1, m_1) \land \text{send}(p_2, r_2, m_2) \\
+  \land\ (p_1 \ne p_2 \lor r_1 \ne r_2)
+  \end{array}
+  \right)
+  \Rightarrow m_1 \ne m_2
+  \]
+\end{property}
+
+
+\subsubsection{Reliable Broadcast Properties}
+
+Here are the properties of the reliable broadcast primitive:\cite{attiyaDistributedComputingFundamentals2004}
+
+\begin{property}{Integrity}
+  Every message received was previously sent. \\
+  Formally : \\
+  $\forall p_i : \text{bc-recv}_i(m) \Rightarrow \exists p_j : \text{bc-send}_j(m)$
+\end{property}
+
+\begin{property}{No Duplicates}
+  No message is received more than once at any single processor. \\
+  Formally : \\
+  $\forall m, \forall p_i: \text{bc-recv}_i(m) \text{ occurs at most once}$ \\
+\end{property}
+
+\begin{property}{Nonfaulty Liveness}
+  All messages broadcast by a nonfaulty processor is either received by all nonfaulty procssors. \\
+  Formally : \\
+  $\forall m, \forall p_i: \text{correct}(p_i) \wedge \text{bc-send}_i(m) => \forall p_j : \text{correct}(p_j) \Rightarrow \text{bc-recv}_j(m)$
+\end{property}
+
+\begin{property}{Faulty Liveness}
+  Every message sent by a faulty processor is either received by all nonfaulty processors or by none of them. \\
+  Formally : \\
+  $\forall m, \forall p_i: \neg\text{correct}(p_i) \wedge \text{bc-send}_i(m) \Rightarrow \forall p_j : \text{correct}(p_j) \Rightarrow \text{bc-recv}_j(m)$
+\end{property}
+
+\subsubsection{AtomicBroadcast Properties}
+
+\begin{property}{AB Totally ordered}
+  $\forall m_1, m_2, \forall p_i, p_j : \text{ab-recv}_{p_i}(m_1) < \text{ab-recv}_{p_i}(m_2) \Rightarrow \text{ab-recv}_{p_j}(m_1) < \text{ab-recv}_{p_j}(m_2)$
+\end{property}
+
+
+\subsubsection{DenyList Properties}
+
+Let $\Pi_M$ be the set of processes authorized to issue \texttt{APPEND} operations, 
+and $\Pi_V$ the set of processes authorized to issue \texttt{PROVE} operations. \\
+Let $S$ be the set of valid values that may be appended. Let $\texttt{Seq}$ be 
+the linearization of operations recorded in the DenyList.
+
+\begin{property}{APPEND Validity}
+  An operation $\texttt{APPEND}(x)$ is valid iff :
+  the issuing process $p \in \Pi_M$, and the value $x \in S$
+\end{property}
+
+\begin{property}{PROVE Validity}
+  An operation $\texttt{PROVE}(x)$ is valid iff:
+  the issuing process $p \in \Pi_V$, and there exists no $\texttt{APPEND}(x)$ that appears earlier in $\texttt{Seq}$.
+\end{property}
+
+\begin{property}{PROGRESS}
+  If an APPEND(x) is invoked by a correct process, then all correct processes will eventually be unable to PROVE(x).
+\end{property}
+
+\begin{property}{READ Validity}
+  READ() return a list of tuples who is a random permutation of all valids PROVE() associated to the identity of the emiter process. 
+\end{property}

Recherche/ALDLoverAB/main.tex

@@ -0,0 +1,623 @@
+\documentclass[11pt]{article}
+
+\usepackage[margin=1in]{geometry}
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage{lmodern}
+\usepackage{microtype}
+\usepackage{amsmath,amssymb,amsthm,mathtools}
+\usepackage{thmtools}
+\usepackage{enumitem}
+\usepackage{csquotes}
+\usepackage[hidelinks]{hyperref}
+\usepackage[nameinlink,noabbrev]{cleveref}
+\usepackage{algorithm}
+\usepackage{algpseudocode}
+% Line-number prefix configuration (A/B/C)
+\renewcommand{\thealgorithm}{\Alph{algorithm}} % Float labels: Algorithm A, B, C
+\newcommand{\algletter}{}
+\algrenewcommand\alglinenumber[1]{\scriptsize\textbf{\algletter}#1}
+\usepackage{tikz}
+\usepackage{xspace}
+
+\usepackage[fr-FR]{datetime2}
+
+\usepackage{fancyhdr}
+\pagestyle{fancy}
+\fancyhf{}
+\fancyfoot[L]{Compilé le \DTMnow}
+\fancyfoot[C]{\thepage}
+\renewcommand{\headrulewidth}{0pt}
+\renewcommand{\footrulewidth}{0pt}
+
+\theoremstyle{plain}
+\newtheorem{theorem}{Theorem}
+\newtheorem{lemma}[theorem]{Lemma}
+\newtheorem{corollary}[theorem]{Corollary}
+\theoremstyle{definition}
+\newtheorem{definition}{Definition}
+\theoremstyle{remark}
+\newtheorem{remark}{Remark}
+
+\newcommand{\RB}{\textsf{RB}\xspace}
+\newcommand{\res}{\mathsf{res}}
+\newcommand{\ARB}{\textsf{ARB}\xspace}
+\newcommand{\DL}{\textsf{DL}\xspace}
+\newcommand{\APPEND}{\textsf{APPEND}}
+\newcommand{\PROVE}{\textsf{PROVE}}
+\newcommand{\PROVEtrace}{\textsf{prove}}
+\newcommand{\READ}{\textsf{READ}}
+\newcommand{\ABbroadcast}{\textsf{AB-broadcast}}
+\newcommand{\ABdeliver}{\textsf{AB-deliver}}
+\newcommand{\RBcast}{\textsf{RB-cast}}
+\newcommand{\RBreceived}{\textsf{RB-received}}
+\newcommand{\ordered}{\textsf{ordered}}
+\newcommand{\Winners}{\mathsf{Winners}}
+\newcommand{\Messages}{\mathsf{Messages}}
+\newcommand{\ABlisten}{\textsf{AB-listen}}
+
+\newcommand{\delivered}{\mathsf{delivered}}
+\newcommand{\received}{\mathsf{received}}
+\newcommand{\prop}{\mathsf{prop}}
+\newcommand{\current}{\mathsf{current}}
+
+\newcommand{\Seq}{\mathsf{Seq}}
+
+\crefname{theorem}{Theorem}{Theorems}
+\crefname{lemma}{Lemma}{Lemmas}
+\crefname{definition}{Definition}{Definitions}
+\crefname{algorithm}{Algorithm}{Algorithms}
+
+\title{Upgrading Reliable Broadcast to Atomic Reliable Broadcast with a DenyList Primitive}
+\date{\vspace{-1ex}}
+
+\begin{document}
+% \maketitle
+
+\begin{abstract}
+We show how to upgrade a Reliable Broadcast (\RB) primitive to Atomic Reliable Broadcast (\ARB) by leveraging a synchronous DenyList (\DL) object. In a purely asynchronous message-passing model with crashes, \ARB is impossible without additional power. The \DL supplies this power by enabling round closing and agreement on a set of "+winners" for each round. We present the algorithm, its safety arguments, and discuss liveness and complexity under the assumed synchrony of \DL.
+\end{abstract}
+
+\paragraph{Keywords} Atomic broadcast, total order broadcast, reliable broadcast, consensus, synchrony, shared object, linearizability.
+
+\section{Introduction}
+Atomic Reliable Broadcast (\ARB)---a.k.a. total order broadcast---ensures that all processes deliver the same sequence of messages. In asynchronous message-passing systems with crashes, implementing \ARB is impossible without additional assumptions, as it enables consensus. We assume a synchronous DenyList (\DL) object and demonstrate how to combine \DL with an asynchronous \RB to realize \ARB.
+
+\section{Model}
+We consider a static set of $n$ processes with known identities, communicating by reliable point-to-point channels, in a complete graph. Messages are uniquely identifiable. 
+
+\paragraph{Synchrony.} The network is asynchronous. Processes may crash; at most $f$ crashes occur.
+
+\paragraph{Communication.} Processes can exchange through a Reliable Broadcast (\RB) primitive (defined below) which's invoked with the functions \RBcast$(m)$ and \RBreceived$(m)$. There exists a shared object called DenyList (\DL) (defined below) that is interfaced with the functions \APPEND$(x)$, \PROVE$(x)$ and \READ$()$. 
+
+\paragraph{Notation.} Let $\Pi$ be the finite set of process identifiers and let $n \triangleq |\Pi|$. Two authorization subsets are $\Pi_M \subseteq \Pi$ (processes allowed to issue \APPEND) and $\Pi_V \subseteq \Pi$ (processes allowed to issue \PROVE). Indices $i,j \in \Pi$ refer to processes, and $p_i$ denotes the process with identifier $i$. Let $\mathcal{M}$ denote the universe of uniquely identifiable messages, with $m \in \mathcal{M}$. Let $\mathcal{R} \subseteq \mathbb{N}$ be the set of round identifiers; we write $r \in \mathcal{R}$ for a round. We use the precedence relation $\prec$ for the \DL{} linearization: $x \prec y$ means that operation $x$ appears strictly before $y$ in the linearized history of \DL. For any finite set $A \subseteq \mathcal{M}$, \ordered$(A)$ returns a deterministic total order over $A$ (e.g., lexicographic order on $(\textit{senderId},\textit{messageId})$ or on message hashes). For any round $r \in \mathcal{R}$, define $\Winners_r \triangleq \{\, j \in \Pi \mid (j,\PROVEtrace(r)) \prec \APPEND(r) \,\}$, i.e., the set of processes whose $\PROVE(r)$ appears before the first $\APPEND(r)$ in the \DL{} linearization.
+We denoted by $\PROVE^{(j)}(r)$ or $\APPEND^{(j)}(r)$ the operation $\PROVE(r)$ or $\APPEND(r)$ invoked by process $j$.
+
+% ------------------------------------------------------------------------------
+\section{Primitives}
+\subsection{Reliable Broadcast (RB)}
+
+\RB provides the following properties in the model.
+\begin{itemize}[leftmargin=*]
+  \item \textbf{Integrity}: Every message received was previously sent. $\forall p_i:\ \RBreceived_i(m) \Rightarrow \exists p_j:\ \RBcast_j(m)$.
+  \item \textbf{No-duplicates}: No message is received more than once at any process.
+  \item \textbf{Validity}: If a correct process broadcasts $m$, every correct process eventually receives $m$.
+\end{itemize}
+
+\subsection{DenyList (DL)}
+We assume a synchronous DenyList (\DL) object with the following properties.
+
+The DenyList object type supports three operations: $\APPEND$, $\PROVE$, and $\READ$. These operations appear as if executed in a sequence $\Seq$ such that:
+\begin{itemize}
+  \item \textbf{Termination.} A $\PROVE$, an $\APPEND$, or a $\READ$ operation invoked by a correct process always returns.
+  \item \textbf{APPEND Validity.} The invocation of $\APPEND(x)$ by a process $p$ is valid if:
+  \begin{itemize}
+    \item $p \in \Pi_M \subseteq \Pi$; \textbf{and}
+    \item $x \in S$, where $S$ is a predefined set. 
+  \end{itemize} 
+  Otherwise, the operation is invalid.
+  \item \textbf{PROVE Validity.} If the invocation of a $op = \PROVE(x)$ by a correct process $p$ is not valid, then:  
+  \begin{itemize}
+    \item $p \not\in \Pi_V \subseteq \Pi$; \textbf{or}
+    \item A valid $\APPEND(x)$ appears before $op$ in $\Seq$. 
+  \end{itemize}
+  Otherwise, the operation is valid.
+  \item \textbf{PROVE Anti-Flickering.} If the invocation of a operation $op = \PROVE(x)$ by a correct process $p \in \Pi_V$ is invalid, then any $\PROVE(x)$ operation that appears after $op$ in $\Seq$ is invalid.
+  \item \textbf{READ Validity.} The invocation of $op = \READ()$ by a process $p \in \pi_V$ returns the list of valid invocations of $\PROVE$ that appears before $op$ in $\Seq$ along with the names of the processes that invoked each operation. 
+  \item \textbf{Anonymity.} Let us assume the process $p$ invokes a $\PROVE(v)$ operation. If the process $p'$ invokes a $\READ()$ operation, then $p'$ cannot learn the value $v$ unless $p$ leaks additional information.
+\end{itemize}
+
+% ------------------------------------------------------------------------------
+\section{Target Abstraction: Atomic Reliable Broadcast (ARB)}
+Processes export \ABbroadcast$(m)$ and \ABdeliver$(m)$. \ARB requires total order:
+\begin{equation*}
+  \forall m_1,m_2,\ \forall p_i,p_j:\ \ \ABdeliver_i(m_1) < \ABdeliver_i(m_2) \Rightarrow \ABdeliver_j(m_1) < \ABdeliver_j(m_2),
+\end{equation*}
+plus Integrity/No-duplicates/Validity (inherited from \RB and the construction).
+
+% ------------------------------------------------------------------------------
+
+\section{Algorithm}
+% granularité diff commentaire de code et paragraphe pre algo
+
+\begin{definition}[Closed round]\label{def:closed-round}
+  Given a \DL{} linearization $H$, a round $r\in\mathcal{R}$ is \emph{closed} in $H$ iff $H$ contains an operation $\APPEND(r)$.
+  Equivalently, there exists a time after which every $\PROVE(r)$ is invalid in $H$.
+\end{definition}
+
+\subsection{Variables}
+Each process $p_i$ maintains:
+
+%on met toutes les variables locales ici
+\begin{algorithmic}
+  \State $\received \gets \emptyset$ \Comment{Messages received via \RB but not yet delivered}
+  \State $\delivered \gets \emptyset$ \Comment{Messages already delivered}
+  \State $\prop[r][j] \gets \bot,\ \forall r,j$ \Comment{Proposal from process $j$ for round $r$}
+  \State $\current \gets 0$
+\end{algorithmic}
+
+\paragraph{DenyList.} The \DL is initialized empty. We assume $\Pi_M = \Pi_V = \Pi$ (all processes can invoke \APPEND and \PROVE).
+
+\subsection{Handlers and Procedures}
+
+\renewcommand{\algletter}{A}
+\begin{algorithm}[H]
+  \caption{\RB handler (at process $p_i$)}\label{alg:rb-handler}
+  \begin{algorithmic}[1]
+    \Function{RBreceived}{$S, r, j$}
+    % \State \textbf{on} $\RBreceived(S, r, j)$ \textbf{do}
+      \State $\received \leftarrow \received \cup \{S\}$
+      \State $\prop[r][j] \leftarrow S$ \Comment{Record sender $j$'s proposal $S$ for round $r$}
+    \EndFunction
+  \end{algorithmic}
+\end{algorithm}
+
+% \paragraph{} An \ABbroadcast$(m)$ chooses the next open round from the \DL view, proposes all pending messages together with the new $m$, disseminates this proposal via \RB, then executes $\PROVE(r)$ followed by $\APPEND(r)$ to freeze the winners of the round. The loop polls \DL until (i) some winner’s proposal includes $m$ in a \emph{closed} round and (ii) all winners' proposals for closed rounds are known locally, ensuring eventual inclusion and delivery.
+
+\renewcommand{\algletter}{B}
+\begin{algorithm}[H]
+  \caption{\ABbroadcast$(m)$ (at process $p_i$)}\label{alg:ab-bcast}
+  \begin{algorithmic}[1]
+    \Function{ABbroadcast}{$m$} 
+      \State $P \leftarrow \READ()$ \Comment{Fetch latest \DL state to learn recent $\PROVE$ operations}
+      \State $r_{max} \leftarrow \max(\{ r' : \exists j,\ (j,\PROVE(r')) \in P \})$ \Comment{Pick current open round}
+      \State $S \leftarrow (\received \setminus \delivered) \cup \{m\}$ \Comment{Propose all pending messages plus the new $m$}
+
+      \vspace{1em}
+
+      \For{\textbf{each}\ $r \in \{r_{max}, r_{max}+1, \cdots \}$} 
+        \State $\RBcast(S, r, i)$; $\PROVE(r)$; $\APPEND(r)$;
+        \State $P \leftarrow \READ()$ \Comment{Refresh local view of \DL}
+        \If{($\big((i, \PROVEtrace(r)) \in P\ \vee\ (\exists j, r': (j, \PROVEtrace(r')) \in P \wedge \ m \in \prop[r'][j]))$)} 
+          \State \textbf{break} \Comment{Exit loop once $m$ is included in some closed round}
+        \EndIf
+      \EndFor
+    \EndFunction
+  \end{algorithmic}
+\end{algorithm}
+
+\renewcommand{\algletter}{C}
+\begin{algorithm}[H]
+  \caption{\ABdeliver() at process $p_i$}\label{alg:delivery}
+  \begin{algorithmic}[1]
+    \Function{ABdeliver}{}
+      \State $r \gets \current$
+      \State $P \gets \READ()$ 
+      \If{$\forall j : (j, \PROVEtrace(r)) \not\in P$} 
+        \State \Return $\bot$
+      \EndIf
+      \State $\APPEND(r)$; $P \gets \READ()$
+      \State $W_r \gets \{ j : (j, \PROVEtrace(r)) \in P \}$
+      \If{$\exists j \in W_r,\ \prop[r][j] = \bot$} 
+        \State \Return $\bot$
+      \EndIf
+      \State $M_r \gets \bigcup_{j \in W_r} \prop[r][j]$
+      \State $m \gets \ordered(M_r \setminus \delivered)[0]$ \Comment{Set $m$ as the smaller message not already delivered}
+      \State $\delivered \leftarrow \delivered \cup \{m\}$
+      \If{$M_r \setminus \delivered = \emptyset$} \Comment{Check if all messages from round $r$ have been delivered}
+        \State $\current \leftarrow \current + 1$
+      \EndIf
+      \State \textbf{return} $m$
+    \EndFunction
+  \end{algorithmic}
+\end{algorithm}
+
+% ------------------------------------------------------------------------------
+\section{Correctness}
+
+\begin{lemma}[Stable round closure]\label{rem:closure-stable}
+If a round $r$ is closed, then there exists a linearization point $t_0$ of $\APPEND(r)$ in the \DL, and from that point on, no $\PROVE(r)$ can be valid.
+Once closed, a round never becomes open again.
+\end{lemma}
+
+\begin{proof}
+  By \Cref{def:closed-round}, some $\APPEND(r)$ occurs in the linearization $H$. \\
+  $H$ is a total order of operations, the set of $\APPEND(r)$ operations is totally ordered, and hence there exists a smallest $\APPEND(r)$ in $H$. We denote this operation $\APPEND^{(\star)}(r)$ and $t_0$ its linearization point. \\
+  By the validity property of \DL, a $\PROVE(r)$ is valid iff $\PROVE(r) \prec \APPEND^{(\star)}(r)$. Thus, after $t_0$, no $\PROVE(r)$ can be valid. \\
+  $H$ is a immutable grow-only history, and hence once closed, a round never becomes open again. \\
+  Hence there exists a linearization point $t_0$ of $\APPEND(r)$ in the \DL, and from that point on, no $\PROVE(r)$ can be valid and the closure is stable. 
+\end{proof}
+
+\begin{definition}[First APPEND]\label{def:first-append}
+  Given a \DL{} linearization $H$, for any closed round $r\in\mathcal{R}$, we denote by $\APPEND^{(\star)}(r)$ the earliest $\APPEND(r)$ in $H$.  
+\end{definition}
+
+\begin{lemma}[Across rounds]\label{lem:across}
+If there exists a $r$ such that $r$ is closed, $\forall r'$ such that $r' < r$, r' is also closed.
+\end{lemma}
+
+\begin{proof}
+  \emph{Base.} For a closed round $k=0$, the set $\{k' \in \mathcal{R},\ k' < k\}$ is empty, hence the lemma is true.
+
+  \emph{Induction.} Assume the lemma is true for round $k\geq 0$, we prove it for round $k+1$.
+  
+  \smallskip
+  Assume $k+1$ is closed and let $\APPEND^{(\star)}(k+1)$ be the earliest $\APPEND(k+1)$ in the DL linearization $H$.
+  By Lemma 1, after an $\APPEND(k)$ is in $H$, any later $\PROVE(k)$ is rejected also, a process’s program order is preserved in $H$.
+  
+  There are two possibilities for where $\APPEND^{(\star)}(k+1)$ is invoked.
+
+  \begin{itemize}
+    \item \textbf{Case (B6) :}
+    Some process $p^\star$ executes the loop (lines B5–B11) and invokes $\APPEND^{(\star)}(k+1)$ at line B6.
+    Immediately before line B6, line B5 sets $r\leftarrow r+1$, so the previous loop iteration (if any) targeted $k$. We consider two sub-cases.
+    
+    \begin{itemize}
+      \item \emph{(i) $p^\star$ is not in its first loop iteration.}
+      In the previous iteration, $p^\star$ executed $\PROVE^{(\star)}(k)$ at B6, followed (in program order) by $\APPEND^{(\star)}(k)$. 
+      If round $k$ wasn't closed when $p^\star$ execute $\PROVE^{(\star)}(k)$ at B9, then the condition at B8 would be true hence the tuple $(p^\star, \PROVEtrace(k))$ should be visible in P which implies that $p^\star$ should leave the loop at round $k$, contradicting the assumption that $p^\star$ is now executing another iteration.
+      Since the tuple is not visible, the $\PROVE^{(\star)}(k)$ was rejected by the DL which implies by definition an $\APPEND(k)$ already exists in $H$. Thus in this case $k$ is closed.
+    
+      \item \emph{(ii) $p^\star$ is in its first loop iteration.}
+      To compute the value $r_{max}$, $p^\star$ must have observed one or many $(\_ , \PROVEtrace(k+1))$ in $P$ at B2/B3, issued by some processes (possibly different from $p^\star$). Let's call $p_1$ the issuer of the first $\PROVE^{(1)}(k+1)$ in the linearization $H$. \\
+      When $p_1$ executed $P \gets \READ()$ at B2 and compute $r_{max}$ at B3, he observed no tuple $(\_,\PROVEtrace(k+1))$ in $P$ because he's the issuer of the first one. So when $p_1$ executed the loop (B5–B11), he run it for the round $k$, didn't seen any $(1,\PROVEtrace(k))$ in $P$ at B8, and then executed the first $\PROVE^{(1)}(k+1)$ at B6 in a second iteration. \\
+      If round $k$ wasn't closed when $p_1$ execute $\PROVE^{(1)}(k)$ at B6, then the condition at B8 should be true which implies that $p_1$ sould leave the loop at round $k$, contradicting the assumption that $p_1$ is now executing $\PROVE^{(1)}(r+1)$. In this case $k$ is closed.
+    \end{itemize}
+    
+    \item \textbf{Case (C8) :} 
+    Some process invokes $\APPEND(k+1)$ at C8. 
+    Line C8 is guarded by the presence of $\PROVE(\textit{next})$ in $P$ with $\textit{next}=k+1$ (C5). 
+    Moreover, the local pointer $\textit{next}$ grow by increment of 1 and only advances after finishing the current round (C17), so if a process can reach $\textit{next}=k+1$ it implies that he has completed round $k$, which includes closing $k$ at C8 when $\PROVE(k)$ is observed. 
+    Hence $\APPEND^\star(k+1)$ implies a prior $\APPEND(k)$ in $H$, so $k$ is closed.
+  \end{itemize}
+  
+  \smallskip
+  In all cases, $k+1$ closed implie $k$ closed. By induction on $k$, if the lemme is true for a closed $k$ then it is true for a closed $k+1$.
+  Therefore, the lemma is true for all closed rounds $r$.
+\end{proof}
+
+\begin{definition}[Winner Invariant]\label{def:winner-invariant}
+  For any closed round $r$, define
+  \[
+    \Winners_r \triangleq \{ j : \PROVE^{(j)}(r) \prec \APPEND^\star(r) \}
+  \] 
+  as the unique set of winners of round $r$.
+\end{definition}
+
+\begin{lemma}[Invariant view of closure]\label{lem:closure-view}
+  For any closed round $r$, all correct processes eventually observe the same set of valid tuples $(\_,\PROVEtrace(r))$ in their \DL view.
+\end{lemma}
+  
+\begin{proof}
+  Let's take a closed round $r$. By \Cref{def:first-append}, there exists a unique earliest $\APPEND(r)$ in the DL linearization, denoted $\APPEND^\star(r)$.
+
+  Consider any correct process $p$ that invokes $\READ()$ after $\APPEND^\star(r)$ in the DL linearization. Since $\APPEND^\star(r)$ invalidates all subsequent $\PROVE(r)$, the set of valid tuples $(\_,\PROVEtrace(r))$ observed by any correct process after $\APPEND^\star(r)$ is fixed and identical across all correct processes.
+
+  Therefore, for any closed round $r$, all correct processes eventually observe the same set of valid tuples $(\_,\PROVEtrace(r))$ in their \DL view.
+\end{proof}
+
+\begin{lemma}[Well-defined winners]\label{lem:winners}
+  For any correct process and round $r$, if the process computes $W_r$ at line C9, then :
+  \begin{itemize}
+    \item $\Winners_r$ is defined;
+    \item the computed $W_r$ is exactly $\Winners_r$.
+  \end{itemize}
+\end{lemma}
+
+\begin{proof}
+  Let take a correct process $p_i$ that reach line C9 to compute $W_r$. \\
+  By program order, $p_i$ must have executed $\APPEND^{(i)}(r)$ at C8 before, which implies by \Cref{def:closed-round} that round $r$ is closed. So by \Cref{def:winner-invariant}, $\Winners_r$ is defined. \\
+  By \Cref{lem:closure-view}, all correct processes eventually observe the same set of valid tuples $(\_,\PROVEtrace(r))$ in their \DL view. Hence, when $p_i$ executes the $\READ()$ at C8 after the $\APPEND^{(i)}(r)$, it observes a set $P$ that includes all valid tuples $(\_,\PROVEtrace(r))$ such that
+  \[
+    W_r = \{ j : (j,\PROVEtrace(r)) \in P \} = \{j : \PROVE^{(j)}(r) \prec \APPEND^\star(r) \} = \Winners_r
+  \]
+\end{proof}
+
+\begin{lemma}[No APPEND without PROVE]\label{lem:append-prove}
+If some process invokes $\APPEND(r)$, then at least a process must have previously invoked $\PROVE(r)$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Consider the round $r$ such that some process invokes $\APPEND(r)$. There are two possible cases
+  
+  \begin{itemize}
+    \item \textbf{Case (B6) :}
+    There exists a process $p^\star$ who's the issuer of the earliest $\APPEND^{(\star)}(r)$ in the DL linearization $H$. By program order, $p^\star$ must have previously invoked $\PROVE^{(\star)}(r)$ before invoking $\APPEND^{(\star)}(r)$ at B6. In this case, there is at least one $\PROVE(r)$ valid in $H$ issued by a correct process before $\APPEND^{(\star)}(r)$.
+    
+    \item \textbf{Case (C8) :}
+    There exist a process $p^\star$ invokes $\APPEND^{(\star)}(r)$ at C8. Line C8 is guarded by the condition at C5, which ensures that $p$ observed some $(\_,\PROVEtrace(r))$ in $P$. In this case, there is at least one $\PROVE(r)$ valid in $H$ issued by some process before $\APPEND^{(\star)}(r)$.
+  \end{itemize}
+    
+  In both cases, if some process invokes $\APPEND(r)$, then some process must have previously invoked $\PROVE(r)$.
+\end{proof}
+
+\begin{lemma}[No empty winners]\label{lem:nonempty}
+  Let $r$ be a round, if $\Winners_r$ is defined, then $\Winners_r \neq \emptyset$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  If $\Winners_r$ is defined, then by \Cref{def:winner-invariant}, round $r$ is closed. By \Cref{def:closed-round}, some $\APPEND(r)$ occurs in the DL linearization. \\
+  By \Cref{lem:append-prove}, at least a process must have invoked a valid $\PROVE(r)$ before $\APPEND^{(\star)}(r)$. Hence, there exists at least one $j$ such that $\{j: \PROVE^{(j)}(r) \prec \APPEND^\star(r)\}$, so $\Winners_r \neq \emptyset$.
+\end{proof}
+
+\begin{lemma}[Winners must propose]\label{lem:winners-propose}
+  For any closed round $r$, $\forall j \in \Winners_r$, process $j$ must have invoked a $\RBcast(S^{(j)}, r, j)$
+\end{lemma}
+
+\begin{proof}[Proof]
+  Fix a closed round $r$. By \Cref{def:winner-invariant}, for any $j \in \Winners_r$, there exist a valid $\PROVE^{(j)}(r)$ such that $\PROVE^{(j)}(r) \prec \APPEND^\star(r)$ in the DL linearization. By program order, if $j$ invoked a valid $\PROVE^{(j)}(r)$ at line B6 he must have invoked $\RBcast(S^{(j)}, r, j)$ directly before.
+\end{proof}
+
+\begin{definition}[Messages invariant]\label{def:messages-invariant}
+  For any closed round $r$ and any correct process $p_i$ such that $\nexists j \in \Winners_r : prop^{[i)}[r][j] = \bot$, define
+  \[
+    \Messages_r \triangleq \bigcup_{j\in\Winners_r} \prop^{(i)}[r][j]
+  \]
+  as the unique set of messages proposed by the winners of round $r$.
+\end{definition}
+
+\begin{lemma}[Non-empty winners proposal]\label{lem:winner-propose-nonbot}
+  For any closed round $r$, $\forall j \in \Winners_r$, for any correct process $p_i$, eventually $\prop^{(i)}[r][j] \neq \bot$.  
+\end{lemma}
+
+\begin{proof}[Proof]
+  Fix a closed round $r$. By \Cref{def:winner-invariant}, for any $j \in \Winners_r$, there exist a valid $\PROVE^{(j)}(r)$ such that $\PROVE^{(j)}(r) \prec \APPEND^\star(r)$ in the DL linearization. By \Cref{lem:winners-propose}, $j$ must have invoked $\RBcast(S^{(j)}, r, j)$.
+
+  Let take a process $p_i$, by \RB \emph{Validity}, every correct process eventually receives $j$'s \RB message for round $r$, which sets $\prop[r][j]$ to a non-$\bot$ value at line A3.
+\end{proof}
+
+\begin{lemma}[Eventual proposal closure]\label{lem:eventual-closure}
+  If a correct process $p_i$ define $M_r$ at line C13, then for every $j \in \Winners_r$, $\prop^{(i)}[r][j] \neq \bot$. 
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let take a correct process $p_i$ that computes $M_r$ at line C13. By \Cref{lem:winners}, $p_i$ computes the unique winner set $\Winners_r$.
+
+  By \Cref{lem:nonempty}, $\Winners_r \neq \emptyset$. The instruction at line C13 where $p_i$ computes $M_r$ is guarded by the condition at C10, which ensures that $p_i$ has received all \RB messages from every winner $j \in \Winners_r$. Hence, when $p_i$ computes $M_r = \bigcup_{j\in\Winners_r} \prop^{(i)}[r][j]$, we have $\prop^{(i)}[r][j] \neq \bot$ for all $j \in \Winners_r$.
+\end{proof}
+
+\begin{lemma}[Unique proposal per sender per round]\label{lem:unique-proposal}
+  For any round $r$ and any process $p_i$, $p_i$ invokes at most one $\RBcast(S, r, i)$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  By program order, any process $p_i$ invokes $\RBcast(S, r, i)$ at line B6 must be in the loop B5–B11. No matter the number of iterations of the loop, line B5 always uses the current value of $r$ which is incremented by 1 at each turn. Hence, in any execution, any process $p_i$ invokes $\RBcast(S, r, j)$ at most once for any round $r$.
+\end{proof}
+
+\begin{lemma}[Proposal convergence]\label{lem:convergence}
+  For any round $r$, for any correct processes $p_i$ that define $M_r$ at line C13, we have
+  \[
+    M_r^{(i)} = \Messages_r
+  \]
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let take a correct process $p_i$ that define $M_r$ at line C13. That implies that $p_i$ has defined $W_r$ at line C9. It implies that, by \Cref{lem:winners}, $r$ is closed and $W_r = \Winners_r$. \\
+  By \Cref{lem:eventual-closure}, for every $j \in \Winners_r$, $\prop^{(i)}[r][j] \neq \bot$. By \Cref{lem:unique-proposal}, each winner $j$ invokes at most one $\RBcast(S^{(j)}, r, j)$, so $\prop^{(i)}[r][j] = S^{(j)}$ is uniquely defined. Hence, when $p_i$ computes
+  \[
+    M_r^{(i)} = \bigcup_{j\in\Winners_r} \prop^{(i)}[r][j] = \bigcup_{j\in\Winners_r} S^{(j)} = \Messages_r.
+  \]
+\end{proof}
+
+\begin{lemma}[Inclusion]\label{lem:inclusion}
+  If some correct process invokes $\ABbroadcast(m)$, then there exist a round $r$ and a process $j\in\Winners_r$ such that $p_j$ invokes
+  \[
+  \RBcast(S, r, j)\quad\text{with}\quad m\in S.
+  \]
+\end{lemma}
+
+\begin{proof}
+  Fix a correct process $p_i$ that invokes $\ABbroadcast(m)$ and eventually exits the loop (B5–B11) at some round $r$. There are two possible cases.
+
+  \begin{itemize}
+    \item \textbf{Case 1:} $p_i$ exits the loop because $(i, \PROVEtrace(r)) \in P$. In this case, by \Cref{def:winner-invariant}, $p_i$ is a winner in round $r$. By program order, $p_i$ must have invoked $\RBcast(S, r, i)$ at B6 before invoking $\PROVE^{(i)}(r)$ at B7. By line B4, $m \in S$. Hence there exist a closed round $r$ and a correct process $j=i\in\Winners_r$ such that $j$ invokes $\RBcast(S, r, j)$ with $m\in S$.
+    
+    \item \textbf{Case 2:} $p_i$ exits the loop because $\exists j, r': (j, \PROVEtrace(r')) \in P \wedge m \in \prop[r'][j]$. In this case, by \Cref{lem:winners-propose} and \Cref{lem:unique-proposal} $j$ must have invoked a unique $\RBcast(S, r', j)$. Which set $\prop^{(i)}[r'][j] = S$ with $m \in S$.   
+  \end{itemize}
+    
+  In both cases, if some correct process invokes $\ABbroadcast(m)$, then there exist a round $r$ and a correct process $j\in\Winners_r$ such that $j$ invokes
+  \[
+    \RBcast(S, r, j)\quad\text{with}\quad m\in S.
+  \]
+\end{proof}
+
+\begin{lemma}[Broadcast Termination]\label{lem:bcast-termination}
+  If a correct process invokes $\ABbroadcast(m)$, then he eventually exit the function and returns.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let a correct process $p_i$ that invokes $\ABbroadcast(m)$. The lemma is true if $\exists r_1$ such that $r_1 \geq r_{max}$ and if $(i, \PROVEtrace(r_1)) \in P$; or if $\exists r_2$ such that $r_2 \geq r_{max}$ and if $\exists j: (j, \PROVEtrace(r_2)) \in P \wedge m \in \prop[r_2][j]$ (like guarded at B8).
+
+  Let admit that there exists no round $r_1$ such that $p_i$ invokes a valid $\PROVE(r_1)$. In this case $p_i$ invokes infinitely many $\RBcast(S, \_, i)$ at B6 with $m \in S$ (line B4).\\
+  The assumption that no $\PROVE(r_1)$ invoked by $p$ is valid implies by \DL \emph{Validity} that for every round $r' \geq r_{max}$, there exists at least one $\APPEND(r')$ in the DL linearization, hence by \Cref{lem:nonempty} for every possible round $r'$ there at least a winner. Because there is an infinite number of rounds, and a finite number of processes, there exists at least a correct process $p_k$ that invokes infinitely many valid $\PROVE(r')$ and by extension infinitely many $\ABbroadcast(\_)$. By \RB \emph{Validity}, $p_k$ eventually receives $p_i$ 's \RB messages. Let call $t_0$ the time when $p_k$ receives $p_i$ 's \RB message. \\
+  At $t_0$, $p_k$ execute \Cref{alg:rb-handler} and do $\received \leftarrow \received \cup \{S\}$ with $m \in S$ (line A2). 
+  For the first invocation of $\ABbroadcast(\_)$ by $p_k$ after the execution of \Cref{alg:rb-handler}, $p_k$ must include $m$ in his proposal $S$ at line B4 (because $m$ is pending in $j$'s $\received \setminus \delivered$ set). There exists a minimum round $r_2$ such that $p_k \in \Winners_{r_2}$ after $t_0$. By \Cref{lem:winner-propose-nonbot}, eventually $\prop^{(i)}[r_2][k] \neq \bot$. By \Cref{lem:unique-proposal}, $\prop^{(i)}[r_2][k]$ is uniquely defined as the set $S$ proposed by $p_k$ at B6, which by \Cref{lem:inclusion} includes $m$. Hence eventually $m \in \prop^{(i)}[r_2][k]$ and $k \in \Winners_{r_2}$. 
+
+  So if $p_i$ is a winner he cover the condition $(i, \PROVEtrace(r_1)) \in P$. And we show that if the first condition is never satisfied, the second one will eventually be satisfied. Hence either the first or the second condition will eventually be satisfied, and $p_i$ eventually exits the loop and returns from $\ABbroadcast(m)$.
+\end{proof}
+
+\begin{lemma}[Validity]\label{lem:validity}
+  If a correct process $p$ invokes $\ABbroadcast(m)$, then every correct process that invokes a infinitely often times $\ABdeliver()$ eventually delivers $m$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let $p_i$ a correct process that invokes $\ABbroadcast(m)$ and $p_q$ a correct process that infinitely invokes $\ABdeliver()$. By \Cref{lem:inclusion}, there exist a closed round $r$ and a correct process $j\in\Winners_r$ such that $p_j$ invokes
+  \[
+    \RBcast(S, r, j)\quad\text{with}\quad m\in S.
+  \]
+
+  By \Cref{lem:eventual-closure}, when $p_q$ computes $M_r$ at line C13, $\prop[r][j]$ is non-$\bot$ because $j \in \Winners_r$. By \Cref{lem:unique-proposal}, $p_j$ invokes at most one $\RBcast(S, r, j)$, so $\prop[r][j]$ is uniquely defined. Hence, when $p_q$ computes
+  \[
+    M_r = \bigcup_{k\in\Winners_r} \prop[r][k],
+  \]
+  we have $m \in \prop[r][j] = S$, so $m \in M_r$. By \Cref{lem:convergence}, $M_r$ is invariant so each computation of $M_r$ by any correct process that defines it includes $m$. At each invocation of $\ABdeliver()$ which deliver $m'$, $m'$ is add to $\delivered$ until $M_r \subseteq \delivered$. Once this append we're assured that there exist an invocation of $\ABdeliver()$ which return $m$. Hence $m$ is well delivered.
+\end{proof}
+
+\begin{lemma}[No duplication]\label{lem:no-duplication}
+  No correct process delivers the same message more than once.
+\end{lemma}
+
+\begin{proof}
+  Let consider two invokations of $\ABdeliver()$ made by the same correct process which returns $m$. Let call these two invocations respectively $\ABdeliver^{(A)}()$ and $\ABdeliver^{(B)}()$.
+
+  When $\ABdeliver^{(A)}()$ occur, by program order and because it reach line C19 to return $m$, the process must have add $m$ to $\delivered$. Hence when $\ABdeliver^{(B)}()$ reach line C14 to extract the next message to deliver, it can't be $m$ because $m \not\in (M_r \setminus \{..., m, ...\})$. So a $\ABdeliver^{(B)}()$ which deliver $m$ can't occur.
+\end{proof}
+
+\begin{lemma}[Total order]\label{lem:total-order}
+  For any two messages $m_1$ and $m_2$ delivered by correct processes, if a correct process $p_i$ delivers $m_1$ before $m_2$, then any correct process $p_j$ that delivers both $m_1$ and $m_2$ delivers $m_1$ before $m_2$.  
+\end{lemma}
+
+\begin{proof}
+  Consider any correct process that delivers both $m_1$ and $m_2$. By \Cref{lem:validity}, there exist closed rounds $r'_1$ and $r'_2$ and correct processes $k_1 \in \Winners_{r'_1}$ and $k_2 \in \Winners_{r'_2}$ such that
+  \[
+    \RBcast(S_1, r'_1, k_1)\quad\text{with}\quad m_1\in S_1,
+  \]
+  \[
+    \RBcast(S_2, r'_2, k_2)\quad\text{with}\quad m_2\in S_2.
+  \]
+
+  Let consider three cases :
+  \begin{itemize}
+    \item \textbf{Case 1:} $r_1 < r_2$. By program order, any correct process must have waited to append in $\delivered$ every messages in $M_{r_1}$ (which contains $m_1$) to increment $\current$ and eventually set $\current = r_2$ to compute $M_{r_2}$ and then invoke the $\ABdeliver()$ that returns $m_2$. Hence, for any correct process that delivers both $m_1$ and $m_2$, it delivers $m_1$ before $m_2$.
+    
+    \item \textbf{Case 2:} $r_1 = r_2$. By \Cref{lem:convergence}, any correct process that computes $M_{r_1}$ at line C13 computes the same set of messages $\Messages_{r_1}$. By line C14 the messages are pull in a deterministic order defined by $\ordered(\_)$. Hence, for any correct process that delivers both $m_1$ and $m_2$, it delivers $m_1$ and $m_2$ in the deterministic order defined by $\ordered(\_)$.
+  \end{itemize}
+
+  In all possible cases, any correct process that delivers both $m_1$ and $m_2$ delivers $m_1$ and $m_2$ in the same order.
+\end{proof}
+
+\begin{lemma}[Fifo Order]\label{lem:fifo-order}
+  For any two messages $m_1$ and $m_2$ broadcast by the same correct process $p_i$, if $p_i$ invokes $\ABbroadcast(m_1)$ before $\ABbroadcast(m_2)$, then any correct process $p_j$ that delivers both $m_1$ and $m_2$ delivers $m_1$ before $m_2$.
+\end{lemma}
+
+\begin{proof}
+  Let take two messages $m_1$ and $m_2$ broadcast by the same correct process $p_i$, with $p_i$ invoking $\ABbroadcast(m_1)$ before $\ABbroadcast(m_2)$. By \Cref{lem:validity}, there exist closed rounds $r_1$ and $r_2$ and correct processes $k_1 \in \Winners_{r_1}$ and $k_2 \in \Winners_{r_2}$ such that
+  \[
+    \RBcast(S_1, r_1, k_1)\quad\text{with}\quad m_1\in S_1,
+  \]
+  \[
+    \RBcast(S_2, r_2, k_2)\quad\text{with}\quad m_2\in S_2.
+  \]
+
+  By program order, $p_i$ must have invoked $\RBcast(S_1, r_1, i)$ before $\RBcast(S_2, r_2, i)$. By \Cref{lem:unique-proposal}, any process invokes at most one $\RBcast(S, r, i)$ per round, hence $r_1 < r_2$. By \Cref{lem:total-order}, any correct process that delivers both $m_1$ and $m_2$ delivers them in a deterministic order.
+  
+  In all possible cases, any correct process that delivers both $m_1$ and $m_2$ delivers $m_1$ before $m_2$.
+\end{proof}
+
+\begin{theorem}[FIFO-\ARB]
+Under the assumed \DL synchrony and \RB reliability, the algorithm implements FIFO Atomic Reliable Broadcast.
+\end{theorem}
+
+\begin{proof}
+  We show that the algorithm satisfies the properties of FIFO Atomic Reliable Broadcast under the assumed \DL synchrony and \RB reliability.
+
+  First, by \Cref{lem:bcast-termination}, if a correct process invokes \ABbroadcast$(m)$, then it eventually returns from this invocation.
+  Moreover, \Cref{lem:validity} states that if a correct process invokes \ABbroadcast$(m)$, then every correct process that invokes \ABdeliver() infinitely often eventually delivers $m$.
+  This gives the usual Validity property of \ARB.
+
+  Concerning Integrity and No-duplicates, the construction only ever delivers messages that have been obtained from the underlying \RB primitive.
+  By the Integrity property of \RB, every such message was previously \RBcast by some process, so no spurious messages are delivered.
+  In addition, \Cref{lem:no-duplication} states that no correct process delivers the same message more than once.
+  Together, these arguments yield the Integrity and No-duplicates properties required by \ARB.
+
+  For the ordering guarantees, \Cref{lem:total-order} shows that for any two messages $m_1$ and $m_2$ delivered by correct processes, every correct process that delivers both $m_1$ and $m_2$ delivers them in the same order.
+  Hence all correct processes share a common total order on delivered messages.
+  Furthermore, \Cref{lem:fifo-order} states that for any two messages $m_1$ and $m_2$ broadcast by the same correct process, any correct process that delivers both messages delivers $m_1$ before $m_2$ whenever $m_1$ was broadcast before $m_2$.
+  Thus the global total order extends the per-sender FIFO order of \ABbroadcast.
+
+  All the above lemmas are proved under the assumptions that \DL satisfies the required synchrony properties and that the underlying primitive is a Reliable Broadcast (\RB) with Integrity, No-duplicates and Validity.
+  Therefore, under these assumptions, the algorithm satisfies Validity, Integrity/No-duplicates, total order and per-sender FIFO order, and hence implements FIFO Atomic Reliable Broadcast, as claimed.
+\end{proof}
+
+\section{Reciprocity}
+% ------------------------------------------------------------------------------
+
+So far, we assumed the existence of a synchronous DenyList (\DL) object and
+showed how to upgrade a Reliable Broadcast (\RB) primitive into FIFO Atomic
+Reliable Broadcast (\ARB). We now briefly argue that, conversely, an \ARB{}
+primitive is strong enough to implement a synchronous \DL object (ignoring the
+anonymity property).
+
+\paragraph{DenyList as a deterministic state machine.}
+Without anonymity, the \DL specification defines a
+deterministic abstract object: given a sequence $\Seq$ of operations
+$\APPEND(x)$, $\PROVE(x)$, and $\READ()$, the resulting sequence of return
+values and the evolution of the abstract state (set of appended elements,
+history of operations) are uniquely determined.
+
+\paragraph{State machine replication over \ARB.}
+Assume a system that exports a FIFO-\ARB primitive with the guarantees that if a correct process invokes $\ABbroadcast(m)$, then every correct process eventually $\ABdeliver(m)$ and the invocation eventually returns.
+Following the classical \emph{state machine replication} approach
+such as described in Schneider~\cite{Schneider90}, we can implement a fault-tolerant service by ensuring the following properties:
+\begin{quote}
+  \textbf{Agreement.} Every nonfaulty state machine replica receives every request. \\
+  \textbf{Order.} Every nonfaulty state machine replica processes the requests it receives in
+  the same relative order.
+\end{quote}
+
+Which are cover by our FIFO-\ARB specification.
+
+\paragraph{Correctness.}
+
+
+\begin{theorem}[From \ARB to synchronous \DL]\label{thm:arb-to-dl}
+  In an asynchronous message-passing system with crash failures, assume a
+  FIFO Atomic Reliable Broadcast primitive with Integrity, No-duplicates,
+  Validity, and the liveness of $\ABbroadcast$. Then, ignoring anonymity, there
+  exists an implementation of a synchronous DenyList object that satisfies the
+  Termination, Validity, and Anti-flickering properties.
+\end{theorem}
+
+\begin{proof}
+  Because the \DL object is deterministic, all correct processes see the same
+  sequence of operations and compute the same sequence of states and return
+  values. We obtain:
+
+  \begin{itemize}[leftmargin=*]
+    \item \textbf{Termination.} The liveness of \ARB ensures that each
+          $\ABbroadcast$ invocation by a correct process eventually returns, and
+          the corresponding operation is eventually delivered and applied at all
+          correct processes. Thus every $\APPEND$, $\PROVE$, and $\READ$ operation invoked by a correct process
+          eventually returns.
+    \item \textbf{APPEND/PROVE/READ Validity.} The local code that forms
+          \ABbroadcast requests can achieve the same preconditions as in the
+          abstract \DL specification (e.g., $p\in\Pi_M$, $x\in S$ for
+          $\APPEND(x)$). Once an operation is delivered, its effect and return
+          value are exactly those of the sequential \DL specification applied in
+          the common order.
+    \item \textbf{PROVE Anti-Flickering.} In the sequential \DL specification,
+          once an element $x$ has been appended, all subsequent $\PROVE(x)$ are
+          invalid forever. Since all replicas apply operations in the same order,
+          this property holds in every execution of the replicated implementation:
+          after the first linearization point of $\APPEND(x)$, no later
+          $\PROVE(x)$ can return ``valid'' at any correct process.
+  \end{itemize}
+
+  Formally, we can describe the \DL object with the state machine approach for
+  crash-fault, asynchronous message-passing systems with a total order broadcast
+  layer~\cite{Schneider90}.
+\end{proof}
+
+
+
+\bibliographystyle{plain}
+\begin{thebibliography}{9}
+% (left intentionally blank)
+\bibitem{Schneider90}
+Fred B.~Schneider.
+\newblock Implementing fault-tolerant services using the state machine
+  approach: a tutorial.
+\newblock {\em ACM Computing Surveys}, 22(4):299--319, 1990.
+\end{thebibliography}
+
+\end{document}

Recherche/ALDLoverAB/proof/index.tex

@@ -0,0 +1,143 @@
+We define $W^t$ as the set of processes that are winners in round $r$ at time $t$.
+
+\begin{theorem}
+    $\forall j_1, j_2 \text{ corrects}, W_{j_1} = W_{j_2}$, where $W_j$ is the set of processes that are winners in round $r$.
+\end{theorem}
+
+\begin{proof}
+    \begin{align*}
+        J = \{j_1, ..., j_n\} & \text{(set of all processes)} \\
+        B \subseteq J, B = \{b_1, ..., b_f\} & \text{(set of faulty processes)} \\
+        C \subseteq J, C = \{c_1, ..., c_{n-f}\} & \text{(set of correct processes)} \\
+        \textbf{Let's assume } \exists b_1 \in B, \exists t_0 & \text{ such that } \texttt{R-Broadcast}_{b_1}(PROP, S, r, b_1) \text{ occurs} \\
+        \Rightarrow\; & \exists K^{t_0} \subseteq C \text{ such that } \forall k \in K^{t_0}, \texttt{R-Delivered}_k(PROP, S, r, b_1) \text{ occurs} \\
+        & \wedge |K^{t_0}| = n - 2f \\
+        \Rightarrow\; & \texttt{PROVE}_k[k](<r, b_1>) \text{ is valid for all } k \in K^{t_0} \\
+        \Rightarrow\; & b_1 \not\in W^{t_0} \text{ since } \texttt{PROVE}_k[k](<r, b_1>) \text{ is valid less than } n - f \text{ times} \\
+        \text{in the same way,} & \\
+        \textbf{Let's assume } \exists L^{t_0} \subseteq C \text{ such that } & \forall l \in L^{t_0}, \texttt{R-Broadcast}_{l}(PROP, \_, r, l) \text{ occurs} \\
+        \textbf{And } \exists M^{t_0} \subseteq C \text{ such that } & \forall m \in M^{t_0}, \texttt{R-Delivered}_m(PROP, \_, r, m) \text{ occurs} \\
+        & \text{with } |L^{t_0}| = n - f \text{ and } |M^{t_0}| = n - f \\
+        \Rightarrow\; & \forall m, l : \exists (m, PROVE(<r, l>)) \in \texttt{READ}[m]() \\
+        & \textbf{And because } |M^{t_0}| \geq n - f \\
+        \Rightarrow\; & \exists O^{t_0} \subseteq M^{t_0} \text{ such that } \forall o \in O^{t_0}, W^{t_0}_o \not\ni b_1 \\
+        & \exists t_1 \geq t_0 : \forall b \in B, \texttt{PROVE}_b[b](<r, b_1>) \text{ occurs} \\
+        \Rightarrow\; & \textbf{at time } t_1, \forall k \in K : \exists (k, \texttt{PROVE}(<r, b_1>)) \in \texttt{READ}[k]() \\
+        & \textbf{And } \forall b \in B, \exists (b, \texttt{PROVE}(<r, b_1>)) \in \texttt{READ}[b]() \\
+        \Rightarrow\; & \textbf{Because } |K| + |B| = n - 2f + f = n - f \text{ the condition is satisfied} \\
+        \Rightarrow\; & W^{t_1} \ni b_1 \\
+    \end{align*}
+\end{proof}
+
+\begin{theorem}
+    % $\exist j \text{ correct } W^{t_0}$
+\end{theorem}
+
+\begin{theorem}[Integrity]
+    If a message $m$ is delivered by any process, then it was previously broadcast by some process via the \texttt{AB-broadcast} primitive.
+\end{theorem}
+
+
+\begin{proof}
+    % Let $j$ be a process such that $\texttt{AB-deliver}_j(m)$ occurs.
+
+    % \begin{align*}
+    %     &\texttt{AB-deliver}_j(m) & \text{(line 18)} \\
+    %     \Rightarrow\; & m \in \texttt{ordered}(T),\ \text{with } T = \bigcup_{j' \in \textit{winner}^r} \textit{prop}[r][j'] \setminus \textit{delivered} & \text{(lines 16-17)} \\
+    %     \Rightarrow\; & \exists j_0,\ r_0 : m \in \textit{prop}[r_0][j_0] & \text{(line 16)} \\
+    %     \Rightarrow\; & \textit{prop}[r_0][j_0] = S,\ \text{with } \texttt{RB-delivered}_{j}(PROP, S, r_0, j_0) & \text{(line 22)} \\
+    %     \Rightarrow\; & S \text{ was sent in } \texttt{RB-cast}(PROP, S, r_0, j_0) & \text{(line 9)} \\
+    %     \Rightarrow\; & S = \textit{received}_{j_0} \setminus \textit{delivered}_{j_0} & \text{(line 6)} \\
+    %     \Rightarrow\; & m' \in \textit{received}_{j_0}\ \text{where } m' \text{ broadcast by } j_0 & \text{(line 4)} \\
+    %     \Rightarrow\; & \textbf{if } m = m' \\
+    %     & \quad \Rightarrow \texttt{RB-Broadcast}_{j_0}(m) \text{ occurred} & \text{(line 3)} \\
+    %     & \quad \Rightarrow \texttt{AB-Broadcast}_{j_0}(m) \text{ occurred} & \text{(line 1)} & \hspace{1em} \square \\
+    %     & \textbf{else: } m \in \textit{received}_{j_0} \setminus \textit{delivered}_{j_0} \\
+    %     & \quad \Rightarrow m \in \textit{received}_{j_0} & \text{(line 4)} \\
+    %     & \quad \Rightarrow \texttt{RB-delivered}_{j_0}(m) \text{ occurred} & \text{(line 3)} \\
+    %     & \quad \Rightarrow \exists j_1 : \texttt{RB-Broadcast}_{j_1}(m) \text{ occurred} & \text{(line 2)} \\
+    %     & \quad \Rightarrow \texttt{AB-Broadcast}_{j_1}(m) \text{ occurred} & \text{(line 1)} & \hspace{1em} \square
+    % \end{align*}
+
+    % Therefore, every delivered message $m$ must originate from some call to \texttt{AB-Broadcast}.
+\end{proof}
+
+
+\begin{theorem}[No Duplication]
+    No message is delivered more than once by any process.
+\end{theorem}
+
+\begin{proof}
+    % Assume by contradiction that a process $j$ delivers the same message $m$ more than once, i.e.,
+    % \[
+    % \texttt{AB-deliver}_j(m) \text{ occurs at least twice.}
+    % \]
+    
+    % \begin{align*}
+    %     &\texttt{AB-deliver}_j(m) \text{ occurs} & \text{(line 19)} \\
+    %     \Rightarrow\; & m \in \texttt{ordered}(T),\ \text{where } T = \bigcup_{j' \in \textit{winner}^r} \textit{prop}[r][j'] \setminus \textit{delivered} & \text{(lines 16-17)} \\
+    %     \Rightarrow\; & m \notin \textit{delivered} \text{ at that time} \\
+    %     \\
+    %     \text{However:} \\
+    %     & \texttt{delivered} \gets \texttt{delivered} \cup \{m\} & \text{(line 18)} \\
+    %     \Rightarrow\; & m \in \textit{delivered} \text{ permanently} \\
+    %     \Rightarrow\; & \text{In any future round, } m \notin T' \text{ since } T' = \bigcup_{j' \in \textit{winner}^r} \textit{prop}[r'][j'] \setminus \textit{delivered} \\
+    %     \Rightarrow\; & m \text{ will not be delivered again} \\
+    %     \Rightarrow\; & \text{Contradiction.}
+    % \end{align*}
+    
+    % Therefore, no message can be delivered more than once by the same process. $\square$
+\end{proof}
+
+\begin{theorem}[Validity]
+    If a correct process invokes $\texttt{AB-Broadcast}_j(m)$, then all correct processes eventually deliver $m$.
+\end{theorem}
+    
+\begin{proof}
+    % Let $j$ be a correct process such that $\texttt{AB-Broadcast}_j(m)$ occurs (line 5).
+    
+    % \begin{align*}
+    %     &\texttt{AB-Broadcast}_j(m) & \text{(line 1)}\\
+    %     \Rightarrow\; & \texttt{RB-Broadcast}_j(m) \text{ occurs} & \text{(line 2)} \\
+    %     \Rightarrow\; & \forall j_0 : \texttt{RB-delivered}_{j_0}(m) & \text{(line 3)} \\
+    %     \Rightarrow\; & m \in \textit{received}_{j_0} & \text{(line 4)} \\
+    %     \Rightarrow\; & \textbf{if } m \in \texttt{delivered}_{j_0} \\
+    %     & \quad \Rightarrow \textit{delivered}_{j_0} \gets textit{delivered}_{j_0} \cup \{m\} & \text{(line 18)} \\
+    %     & \quad \Rightarrow \texttt{AB-delivered}_{j_0}(m) & \text{(line 19)}  & \hspace{1em} \square \\
+    %     & \textbf{else } m \notin \textit{delivered}_{j_0} : \\
+    %     & \quad \Rightarrow m \in S_{j_0}\ \text{since } S_{j_0} = \textit{receieved}_{j_0} \setminus \textit{delivered}_{j_0} & \text{(line 6)} \\
+    %     & \quad \Rightarrow \exists r : \texttt{RB-cast}_{j_0}(texttt{PROP}, S_{j_0}, r, j_0) & \text{(line 9)} \\
+    %     & \quad \quad \Rightarrow \forall j_1 : \texttt{RB-Deliver}_{j_1}(\texttt{PROP}, S_{j_0}, r, j_0)\ \text{occurs} & \text{(line 21)} \\
+    %     & \quad \quad \Rightarrow \textit{prop}[r][j_0] = S_{j_0} & \text{(line 22)} \\
+    %     & \quad \Rightarrow \exists j_2 \in j_0 : \texttt{PROVE}_{j_2}(r)\ \text{is valid} & \text{(line 10)} \\
+    %     & \quad \Rightarrow j_2 \in textit{winner}^r & \text{(line 14)} \\
+    %     & \quad \Rightarrow T_{j_0} \ni \textit{prop}[r][j_2] \setminus \textit{delivered}_{j_0} & \text{(line 16)} \\
+    %     & \quad \Rightarrow T_{j_0} \ni S_{j_2} \setminus \textit{delivered}_{j_0} \ni m & \text{(line 16)} \\
+    %     & \quad \Rightarrow \texttt{AB-deliver}_{j_0}(m) & \text{(line 19)} & \hspace{1em} \square \\
+    % \end{align*}
+
+\end{proof}
+
+\begin{theorem}[Total Order]
+    If two correct processes deliver two messages $m_1$ and $m_2$, then they deliver them in the same order.
+\end{theorem}
+    
+\begin{proof}
+    
+    % \begin{align*}  
+    %     & \forall j_0 : \texttt{AB-Deliver}_{j_0}(m_0) \wedge \texttt{AB-Deliver}_{j_0}(m_1) & \text{(line 19)} \\
+    %     \Rightarrow\; & \exists r_0, r_1 : m_0 \in \texttt{ordered}(T^{r_0}) \wedge m_1 \in \texttt{ordered}(T^{r_1}) & \text{(line 17)} \\
+    %     \Rightarrow\; & T^{r_0} = \bigcup_{j' \in \textit{winner}^{r_0}} \textit{prop}[r_0][j'] \setminus \textit{delivered}\ \wedge \\
+    %     & T^{r_1} = \bigcup_{j' \in \textit{winner}^{r_1}} \textit{prop}[r_1][j'] \setminus \textit{delivered} & \text{(line 16)} \\
+    %     \Rightarrow\; & \textbf{if } r_0 = r_1 \\
+    %     & \quad \Rightarrow T^{r_0} = T^{r_1} \\
+    %     & \quad \Rightarrow m_0, m_1 \in \texttt{ordered}(T^{r_0})\ \text{since \texttt{ordered} is deterministic} \\
+    %     & \quad \Rightarrow \textbf{if } m_0 < m_1 : \\
+    %     & \quad \quad \Rightarrow \texttt{AB-Deliver}_{j_0}(m_0) < \texttt{AB-Deliver}_{j_0}(m_1) & & \hspace{1em} \square\\
+    %     & \textbf{else if } r_0 < r_1 \\
+    %     & \quad \Rightarrow \forall m \in T^{r_0}, \forall m' \in T^{r_1} : \texttt{AB-Deliver}(m) < \texttt{AB-Deliver}(m') & & \hspace{1em} \square\\
+    % \end{align*}
+    
+    % Therefore, for all correct processes, messages are delivered in the same total order.
+\end{proof}
+

Recherche/ALDLoverAB/sources.bib

@@ -0,0 +1,14 @@
+@book{attiyaDistributedComputingFundamentals2004,
+  title = {Distributed {{Computing}}: {{Fundamentals}}, {{Simulations}}, and {{Advanced Topics}}},
+  shorttitle = {Distributed {{Computing}}},
+  author = {Attiya, Hagit and Welch, Jennifer},
+  date = {2004-03-25},
+  eprint = {3xfhhRjLUJEC},
+  eprinttype = {googlebooks},
+  publisher = {John Wiley \& Sons},
+  abstract = {* Comprehensive introduction to the fundamental results in the mathematical foundations of distributed computing * Accompanied by supporting material, such as lecture notes and solutions for selected exercises * Each chapter ends with bibliographical notes and a set of exercises * Covers the fundamental models, issues and techniques, and features some of the more advanced topics},
+  isbn = {978-0-471-45324-6},
+  langid = {english},
+  pagetotal = {440},
+  keywords = {Computers / Computer Engineering,Computers / Computer Science,Computers / Networking / General}
+}

Recherche/Articles et biblio/all.bib

@@ -0,0 +1,258 @@
+
+@article{saito_optimistic_2005,
+	title = {Optimistic {Replication}},
+	volume = {37},
+	url = {https://inria.hal.science/hal-01248208},
+	doi = {10.1145/1057977.1057980},
+	abstract = {Data replication is a key technology in distributed systems that enables higher availability and performance. This article surveys optimistic replication algorithms. They allow replica contents to diverge in the short term to support concurrent work practices and tolerate failures in low-quality communication links. The importance of such techniques is increasing as collaboration through wide-area and mobile networks becomes popular.Optimistic replication deploys algorithms not seen in traditional “pessimistic” systems. Instead of synchronous replica coordination, an optimistic algorithm propagates changes in the background, discovers conflicts after they happen, and reaches agreement on the final contents incrementally.We explore the solution space for optimistic replication algorithms. This article identifies key challenges facing optimistic replication systems---ordering operations, detecting and resolving conflicts, propagating changes efficiently, and bounding replica divergence---and provides a comprehensive survey of techniques developed for addressing these challenges.},
+	language = {en},
+	number = {1},
+	urldate = {2023-06-09},
+	journal = {ACM Computing Surveys},
+	author = {Saito, Yasushi and Shapiro, Marc},
+	year = {2005},
+	pages = {42},
+	file = {Saito et Shapiro - 2005 - Optimistic Replication.pdf:/home/amaury/Zotero/storage/4WJX5IAN/Saito et Shapiro - 2005 - Optimistic Replication.pdf:application/pdf},
+}
+
+@article{singh_zeno_2009,
+	title = {Zeno: {Eventually} {Consistent} {Byzantine}-{Fault} {Tolerance}},
+	abstract = {Many distributed services are hosted at large, shared, geographically diverse data centers, and they use replication to achieve high availability despite the unreachability of an entire data center. Recent events show that non-crash faults occur in these services and may lead to long outages. While Byzantine-Fault Tolerance (BFT) could be used to withstand these faults, current BFT protocols can become unavailable if a small fraction of their replicas are unreachable. This is because existing BFT protocols favor strong safety guarantees (consistency) over liveness (availability).},
+	language = {en},
+	author = {Singh, Atul and Fonseca, Pedro and Kuznetsov, Petr and Rodrigues, Rodrigo and Maniatis, Petros},
+	year = {2009},
+	file = {Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:/home/amaury/Zotero/storage/K6J2UEBK/Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:application/pdf},
+}
+
+@inproceedings{shakarami_refresh_2019,
+	title = {Refresh {Instead} of {Revoke} {Enhances} {Safety} and {Availability}: {A} {Formal} {Analysis}},
+	volume = {LNCS-11559},
+	shorttitle = {Refresh {Instead} of {Revoke} {Enhances} {Safety} and {Availability}},
+	url = {https://inria.hal.science/hal-02384596},
+	doi = {10.1007/978-3-030-22479-0_16},
+	abstract = {Due to inherent delays and performance costs, the decision point in a distributed multi-authority Attribute-Based Access Control (ABAC) system is exposed to the risk of relying on outdated attribute values and policy; which is the safety and consistency problem. This paper formally characterizes three increasingly strong levels of consistency to restrict this exposure. Notably, we recognize the concept of refreshing attribute values rather than simply checking the revocation status, as in traditional approaches. Refresh replaces an older value with a newer one, while revoke simply invalidates the old value. Our lowest consistency level starts from the highest level in prior revocation-based work by Lee and Winslett (LW). Our two higher levels utilize the concept of request time which is absent in LW. For each of our levels we formally show that using refresh instead of revocation provides added safety and availability.},
+	language = {en},
+	urldate = {2023-06-09},
+	publisher = {Springer International Publishing},
+	author = {Shakarami, Mehrnoosh and Sandhu, Ravi},
+	month = jul,
+	year = {2019},
+	pages = {301},
+	file = {Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:/home/amaury/Zotero/storage/XQNWKF7H/Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:application/pdf},
+}
+
+@article{misra_axioms_1986,
+	title = {Axioms for memory access in asynchronous hardware systems},
+	volume = {8},
+	issn = {0164-0925, 1558-4593},
+	url = {https://dl.acm.org/doi/10.1145/5001.5007},
+	doi = {10.1145/5001.5007},
+	abstract = {The problem of concurrent accesses to registers by asynchronous components is considered. A set of axioms about the values in a register during concurrent accesses is proposed. It is shown that if these axioms are met by a register, then concurrent accesses to it may be viewed as nonconcurrent, thus making it possible to analyze asynchronous algorithms without elaborate timing analysis of operations. These axioms are shown, in a certain sense, to be the weakest. Motivation for this work came from analyzing low-level hardware components in a VLSI chip which concurrently accesses a flip-flop.},
+	language = {en},
+	number = {1},
+	urldate = {2023-06-08},
+	journal = {ACM Transactions on Programming Languages and Systems},
+	author = {Misra, J.},
+	month = jan,
+	year = {1986},
+	pages = {142--153},
+	file = {Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:/home/amaury/Zotero/storage/KZP2774N/Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:application/pdf},
+}
+
+@article{lamport_interprocess_1986,
+	title = {On interprocess communication},
+	volume = {1},
+	issn = {1432-0452},
+	url = {https://doi.org/10.1007/BF01786228},
+	doi = {10.1007/BF01786228},
+	abstract = {Interprocess communication is studied without assuming any lower-level communication primitives. Three classes of communication registers are considered, and several constructions are given for implementing one class of register with a weaker class. The formalism developed in Part I is used in proving the correctness of these constructions.},
+	language = {en},
+	number = {2},
+	urldate = {2023-06-08},
+	journal = {Distributed Computing},
+	author = {Lamport, Leslie},
+	month = jun,
+	year = {1986},
+	keywords = {Communication Network, Computer Hardware, Computer System, Operating System, System Organization},
+	pages = {86--101},
+	file = {Lamport - 1986 - On interprocess communication.pdf:/home/amaury/Zotero/storage/XV7AEARN/Lamport - 1986 - On interprocess communication.pdf:application/pdf},
+}
+
+@book{lipton_pram_1988,
+	title = {{PRAM}: {A} {Scalable} {Shared} {Memory}},
+	shorttitle = {{PRAM}},
+	language = {en},
+	publisher = {Princeton University, Department of Computer Science},
+	author = {Lipton, Richard J. and Sandberg, Jonathan S.},
+	year = {1988},
+	note = {Google-Books-ID: 962epwAACAAJ},
+	file = {Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:/home/amaury/Zotero/storage/3ZYT3WT4/Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:application/pdf},
+}
+
+@inproceedings{hutto_slow_1990,
+	title = {Slow memory: weakening consistency to enhance concurrency in distributed shared memories},
+	shorttitle = {Slow memory},
+	url = {https://www.computer.org/csdl/proceedings-article/icdcs/1990/00089297/12OmNvSKNPr},
+	doi = {10.1109/ICDCS.1990.89297},
+	abstract = {The use of weakly consistent memories in distributed shared memory systems to combat unacceptable network delay and to allow such systems to scale is proposed. Proposed memory correctness conditions are surveyed, and how they are related by a weakness hierarchy is demonstrated. Multiversion and messaging interpretations of memory are introduced as means of systematically exploring the space of possible memories. Slow memory is presented as a memory that allows the effects of writes to propagate slowly through the system, eliminating the need for costly consistency maintenance protocols that limit concurrency. Slow memory processes a valuable locality property and supports a reduction from traditional atomic memory. Thus slow memory is as expressive as atomic memory. This expressiveness is demonstrated by two exclusion algorithms and a solution to M.J. Fischer and A. Michael's (1982) dictionary problem on slow memory.},
+	language = {English},
+	urldate = {2023-06-06},
+	publisher = {IEEE Computer Society},
+	author = {Hutto, P. W. and Ahamad, M.},
+	month = jan,
+	year = {1990},
+	pages = {302,303,304,305,306,307,308,309--302,303,304,305,306,307,308,309},
+	file = {Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf:/home/amaury/Téléchargements/Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf:application/pdf},
+}
+
+@article{lamport_how_1979,
+	title = {How to {Make} a {Multiprocessor} {Computer} {That} {Correctly} {Executes} {Multiprocess} {Programs}},
+	volume = {C-28},
+	issn = {1557-9956},
+	doi = {10.1109/TC.1979.1675439},
+	abstract = {Many large sequential computers execute operations in a different order than is specified by the program. A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order. For a multiprocessor computer, such a correct execution by each processor does not guarantee the correct execution of the entire program. Additional conditions are given which do guarantee that a computer correctly executes multiprocess programs.},
+	number = {9},
+	journal = {IEEE Transactions on Computers},
+	author = {{Lamport}},
+	month = sep,
+	year = {1979},
+	note = {Conference Name: IEEE Transactions on Computers},
+	keywords = {Computer design, concurrent computing, hardware correctness, multiprocessing, parallel processing},
+	pages = {690--691},
+	file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/IVGSSPNE/1675439.html:text/html;Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:/home/amaury/Zotero/storage/GY8CWGUV/Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:application/pdf},
+}
+
+@article{mosberger_memory_1993,
+	title = {Memory consistency models},
+	volume = {27},
+	issn = {0163-5980},
+	url = {https://dl.acm.org/doi/10.1145/160551.160553},
+	doi = {10.1145/160551.160553},
+	abstract = {This paper discusses memory consistency models and their influence on software in the context of parallel machines. In the first part we review previous work on memory consistency models. The second part discusses the issues that arise due to weakening memory consistency. We are especially interested in the influence that weakened consistency models have on language, compiler, and runtime system design. We conclude that tighter interaction between those parts and the memory system might improve performance considerably.},
+	language = {en},
+	number = {1},
+	urldate = {2023-06-06},
+	journal = {ACM SIGOPS Operating Systems Review},
+	author = {Mosberger, David},
+	month = jan,
+	year = {1993},
+	pages = {18--26},
+	file = {Mosberger - 1993 - Memory consistency models.pdf:/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.pdf:application/pdf},
+}
+
+@incollection{goos_causal_1995,
+	address = {Berlin, Heidelberg},
+	title = {From causal consistency to sequential consistency in shared memory systems},
+	volume = {1026},
+	isbn = {978-3-540-60692-5 978-3-540-49263-4},
+	url = {http://link.springer.com/10.1007/3-540-60692-0_48},
+	language = {en},
+	urldate = {2023-06-06},
+	booktitle = {Foundations of {Software} {Technology} and {Theoretical} {Computer} {Science}},
+	publisher = {Springer Berlin Heidelberg},
+	author = {Raynal, Michel and Schiper, André},
+	editor = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan and Thiagarajan, P. S.},
+	year = {1995},
+	doi = {10.1007/3-540-60692-0_48},
+	note = {Series Title: Lecture Notes in Computer Science},
+	pages = {180--194},
+	file = {Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:/home/amaury/Zotero/storage/B8UNWUSA/Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:application/pdf},
+}
+
+@phdthesis{kumar_fault-tolerant_2019,
+	type = {{PhD} {Thesis}},
+	title = {Fault-{Tolerant} {Distributed} {Services} in {Message}-{Passing} {Systems}},
+	school = {Texas A\&M University},
+	author = {Kumar, Saptaparni},
+	year = {2019},
+	file = {Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:/home/amaury/Zotero/storage/Q9XK77W9/Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:application/pdf;Snapshot:/home/amaury/Zotero/storage/7JB26RAJ/1.html:text/html},
+}
+
+@article{somasekaram_high-availability_2022,
+	title = {High-{Availability} {Clusters}: {A} {Taxonomy}, {Survey}, and {Future} {Directions}},
+	volume = {187},
+	issn = {01641212},
+	shorttitle = {High-{Availability} {Clusters}},
+	url = {http://arxiv.org/abs/2109.15139},
+	doi = {10.1016/j.jss.2021.111208},
+	abstract = {The delivery of key services in domains ranging from finance and manufacturing to healthcare and transportation is underpinned by a rapidly growing number of mission-critical enterprise applications. Ensuring the continuity of these complex applications requires the use of software-managed infrastructures called high-availability clusters (HACs). HACs employ sophisticated techniques to monitor the health of key enterprise application layers and of the resources they use, and to seamlessly restart or relocate application components after failures. In this paper, we first describe the manifold uses of HACs to protect essential layers of a critical application and present the architecture of high availability clusters. We then propose a taxonomy that covers all key aspects of HACs -- deployment patterns, application areas, types of cluster, topology, cluster management, failure detection and recovery, consistency and integrity, and data synchronisation; and we use this taxonomy to provide a comprehensive survey of the end-to-end software solutions available for the HAC deployment of enterprise applications. Finally, we discuss the limitations and challenges of existing HAC solutions, and we identify opportunities for future research in the area.},
+	urldate = {2023-06-06},
+	journal = {Journal of Systems and Software},
+	author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
+	month = may,
+	year = {2022},
+	note = {arXiv:2109.15139 [cs, eess]},
+	keywords = {Computer Science - Distributed, Parallel, and Cluster Computing, Computer Science - Networking and Internet Architecture, Electrical Engineering and Systems Science - Systems and Control},
+	pages = {111208},
+	file = {arXiv.org Snapshot:/home/amaury/Zotero/storage/B4KCP9BG/2109.html:text/html;Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:/home/amaury/Zotero/storage/K3LQZLC8/Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:application/pdf},
+}
+
+@book{perrin_concurrence_2017,
+	title = {Concurrence et cohérence dans les systèmes répartis},
+	isbn = {978-1-78405-295-9},
+	abstract = {La société moderne est de plus en plus dominée par la société virtuelle, le nombre d’internautes dans le monde ayant dépassé les trois milliards en 2015. A la différence de leurs homologues séquentiels, les systèmes répartis sont beaucoup plus difficiles à concevoir, et sont donc sujets à de nombreux problèmes.La cohérence séquentielle fournit la même vue globale à tous les utilisateurs, mais le confort d\&\#39;utilisation qu\&\#39;elle apporte est trop coûteux, voire impossible, à mettre en oeuvre à grande échelle. Concurrence et cohérence dans les systèmes répartis examine les meilleures façons de spécifier les objets que l’on peut tout de même implémenter dans ces systèmes.Cet ouvrage explore la zone grise des systèmes répartis et dresse une carte des critères de cohérence faible, identifiant plusieurs familles et démontrant comment elles peuvent s’intégrer dans un langage de programmation.},
+	language = {fr},
+	publisher = {ISTE Group},
+	author = {Perrin, Matthieu},
+	month = sep,
+	year = {2017},
+	note = {Google-Books-ID: 6DRlDwAAQBAJ},
+	file = {Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:/home/amaury/Téléchargements/Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:application/pdf},
+}
+
+@article{van_der_linde_practical_2020,
+	title = {Practical client-side replication: weak consistency semantics for insecure settings},
+	volume = {13},
+	issn = {2150-8097},
+	shorttitle = {Practical client-side replication},
+	url = {https://dl.acm.org/doi/10.14778/3407790.3407847},
+	doi = {10.14778/3407790.3407847},
+	abstract = {Client-side replication and direct client-to-client synchronization can be used to create highly available, low-latency interactive applications. Causal consistency, the strongest available consistency model under network partitions, is an attractive consistency model for these applications.},
+	language = {en},
+	number = {12},
+	urldate = {2023-06-06},
+	journal = {Proceedings of the VLDB Endowment},
+	author = {Van Der Linde, Albert and Leitão, João and Preguiça, Nuno},
+	month = aug,
+	year = {2020},
+	pages = {2590--2605},
+	file = {Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:/home/amaury/Zotero/storage/5TJ3SA56/Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:application/pdf},
+}
+
+@article{decandia_dynamo_2007,
+	title = {Dynamo: {Amazon}’s {Highly} {Available} {Key}-value {Store}},
+	abstract = {Reliability at massive scale is one of the biggest challenges we face at Amazon.com, one of the largest e-commerce operations in the world; even the slightest outage has significant financial consequences and impacts customer trust. The Amazon.com platform, which provides services for many web sites worldwide, is implemented on top of an infrastructure of tens of thousands of servers and network components located in many datacenters around the world. At this scale, small and large components fail continuously and the way persistent state is managed in the face of these failures drives the reliability and scalability of the software systems.},
+	language = {en},
+	author = {DeCandia, Giuseppe and Hastorun, Deniz and Jampani, Madan and Kakulapati, Gunavardhan and Lakshman, Avinash and Pilchin, Alex and Sivasubramanian, Swaminathan and Vosshall, Peter and Vogels, Werner},
+	year = {2007},
+	file = {DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:/home/amaury/Zotero/storage/KDHRPBGR/DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:application/pdf},
+}
+
+@misc{misra_byzantine_2021,
+	title = {Byzantine {Fault} {Tolerant} {Causal} {Ordering}},
+	url = {http://arxiv.org/abs/2112.11337},
+	abstract = {Causal ordering in an asynchronous system has many applications in distributed computing, including in replicated databases and real-time collaborative software. Previous work in the area focused on ordering point-to-point messages in a fault-free setting, and on ordering broadcasts under various fault models. To the best of our knowledge, Byzantine faulttolerant causal ordering has not been attempted for point-topoint communication in an asynchronous setting. In this paper, we first show that existing algorithms for causal ordering of point-to-point communication fail under Byzantine faults. We then prove that it is impossible to causally order messages under point-to-point communication in an asynchronous system with one or more Byzantine failures. We then present two algorithms that can causally order messages under Byzantine failures, where the network provides an upper bound on the message transmission time. The proofs of correctness for these algorithms show that it is possible to achieve causal ordering for point-to-point communication under a stronger asynchrony model where the network provides an upper bound on message transmission time. We also give extensions of our two algorithms for Byzantine fault-tolerant causal ordering of multicasts.},
+	language = {en},
+	urldate = {2023-07-12},
+	publisher = {arXiv},
+	author = {Misra, Anshuman and Kshemkalyani, Ajay},
+	month = dec,
+	year = {2021},
+	note = {arXiv:2112.11337 [cs]},
+	keywords = {Computer Science - Distributed, Parallel, and Cluster Computing},
+	file = {Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:/home/amaury/Zotero/storage/P2R366US/Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:application/pdf},
+}
+
+@inproceedings{tseng_distributed_2019,
+	title = {Distributed {Causal} {Memory} in the {Presence} of {Byzantine} {Servers}},
+	doi = {10.1109/NCA.2019.8935059},
+	abstract = {We study distributed causal shared memory (or distributed read/write objects) in the client-server model over asynchronous message-passing networks in which some servers may suffer Byzantine failures. Since Ahamad et al. proposed causal memory in 1994, there have been abundant research on causal storage. Lately, there is a renewed interest in enforcing causal consistency in large-scale distributed storage systems (e.g., COPS, Eiger, Bolt-on). However, to the best of our knowledge, the fault-tolerance aspect of causal memory is not well studied, especially on the tight resilience bound. In our prior work, we showed that 2 f+1 servers is the tight bound to emulate crash-tolerant causal shared memory when up to f servers may crash. In this paper, we adopt a typical model considered in many prior works on Byzantine-tolerant storage algorithms and quorum systems. In the system, up to f servers may suffer Byzantine failures and any number of clients may crash. We constructively present an emulation algorithm for Byzantine causal memory using 3 f+1 servers. We also prove that 3 f+1 is necessary for tolerating up to f Byzantine servers. In other words, we show that 3 f+1 is a tight bound. For evaluation, we implement our algorithm in Golang and compare their performance with two state-of-the-art fault-tolerant algorithms that ensure atomicity in the Google Cloud Platform.},
+	booktitle = {2019 {IEEE} 18th {International} {Symposium} on {Network} {Computing} and {Applications} ({NCA})},
+	author = {Tseng, Lewis and Wang, Zezhi and Zhao, Yajie and Pan, Haochen},
+	month = sep,
+	year = {2019},
+	note = {ISSN: 2643-7929},
+	keywords = {asynchrony, Byzantine faults, causal memory, Computer crashes, Consensus protocol, distributed storage system, Emulation, evaluation, Fault tolerance, Fault tolerant systems, History, Servers, tight condition},
+	pages = {1--8},
+	file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/DDV34ULW/8935059.html:text/html},
+}

Recherche/Articles et biblio/liste_detaille.md

@@ -0,0 +1,49 @@
+# Enumération de la bibliographie étudié
+
+## Cohérence
+
+### Très pertinents
+
+__perrin_concurrence_2017__, "Concurrence et cohérence dans les systèmes répartis":  
+Etat de l'art sur la cohérence dans les systèmes repartis. Présentation d'une approche de modélisation des histoires concurentes. Formaisations de différents critères de cohérences. Comparaison et "hierarchisation" des différents critères de cohérences.
+
+### Intéressants mais redondants
+
+__lamport_interprocess_1986__, "On interprocess communication":  
+Formalisation d'une cohérence séquentiel "single writer"
+
+__misra_axioms_1986__, "Axioms for memory access in asynchronous hardware systems":  
+Exetnsion de lamport_interprocess_1986 dans une approche "multi-writer"
+
+__lipton_pram_1988__, "{PRAM}: A Scalable Shared Memory":  
+Definition de la mémoire PRAM (cohérence pipeline).
+
+## Cohérence en contextes byzantins
+
+### Algorithmes
+
+__van_der_linde_practical_2020__, "Practical client-side replication: weak consistency semantics for insecure settings":  
+Algorithme pour de la Cohérence causale BFT. (Reflexions sur des erreurs byzantines possible + algo et implé)
+
+__kumar_fault-tolerant_2019__, "Fault-Tolerant Distributed Services in Message-Passing Systems":  
+Pas spécifiquement à propos des fautes byzantines dans la cohérence faible mais fait un panorama des differentes fautes non-byzantine possibles dans les systèmes distribués.
+
+__singh_zeno_2009__, "Zeno: Eventually Consistent Byzantine-Fault Tolerance":  
+Algorithme pour de la convergence BFT. (Reflexions sur des erreurs byzanties possible + algo et implé)
+
+__tseng_distributed_2019__, "Algo BFT pour cohérence causale (preuve + experiences)"
+
+__misra_byzantine_2021__, "Preuve d'impossibilité de BFT dans un certain contexte pour de la cohérence causale + 2 algo pour de la cohérence causale BFT"4
+
+## YJS
+
+articles 
+
+- blog post: <https://blog.kevinjahns.de/are-crdts-suitable-for-shared-editing/>
+- A string-wise CRDT algorithm for smart and large-scale collaborative editing systems <https://www.sciencedirect.com/science/article/abs/pii/S1474034616301811>
+- Near Real-Time Peer-to-Peer Shared Editing on Extensible Data Types
+
+## Complexity and specification of collaborative text editing
+
+- Specification and space complexity of collaborative text editing Attiya et. all PODC/TCS
+- Replicated data types: specification, verification, optimality Gosman et. al POPL (2014)

Recherche/Articles et biblio/todo.md

@@ -0,0 +1,26 @@
+# Articles à traiter
+
+- [x] Tame the Wild with Byzantine Linearizability (DISC 2021)
+- [ ] Atomic Register Abstractions for Byzantine-Prone  
+  Distributed Systems, Extended Version  
+  <https://hal.science/hal-04213718/document>
+- [ ] <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf?TB_iframe=true&width=370.8&height=658.8>
+- [ ] [https://www.sciencedirect.com/science/article/abs/pii/S0167404821002601](https://www.sciencedirect.com/science/article/abs/pii/S0167404821002601/)
+- [ ] @ARTICLE{9585170,  
+    author={Shore, Malcolm and Zeadally, Sherali and Keshariya, Astha},  
+    journal={Computer},  
+    title={Zero Trust: The What, How, Why, and When},  
+    year={2021},  
+    volume={54},  
+    number={11},  
+    pages={26-35},  
+    doi={10.1109/MC.2021.3090018}}
+- [ ] @ARTICLE{9773102,  
+    author={Syed, Naeem Firdous and Shah, Syed W. and Shaghaghi, Arash and Anwar, Adnan and Baig, Zubair and Doss, Robin},  
+    journal={IEEE Access},  
+    title={Zero Trust Architecture (ZTA): A Comprehensive Survey},  
+    year={2022},  
+    volume={10},  
+    number={},  
+    pages={57143-57179},  
+    doi={10.1109/ACCESS.2022.3174679}}

Recherche/BFT-ARBover/.latexmkrc

@@ -0,0 +1,40 @@
+$pdf_mode = 1;                          # latexmk -pdf par défaut
+$pdflatex = 'pdflatex -interaction=nonstopmode -synctex=1 %O %S';
+
+# --- Config PlantUML ----------------------------------------------------
+# Si plantuml est dans le PATH :
+# $plantuml = 'plantuml';
+
+# Si tu utilises un JAR :
+$plantuml = 'java -jar -Djava.awt.headless=true /usr/share/plantuml/plantuml.jar';
+
+# Options PlantUML : sortie LaTeX/TikZ
+$plantuml_opts = '-tlatex:nopreamble';
+
+# --- Dépendance personnalisée .puml -> .tex -----------------------------
+# Quand latexmk a besoin de "truc.tex" et que "truc.puml" existe,
+# il appelle la fonction puml2tex pour le générer.
+
+add_cus_dep( 'puml', 'tex', 0, 'puml2tex' );
+
+sub puml2tex {
+    my ($base_name) = @_;   # base du fichier cible, sans extension
+
+    # Exemple : $base_name = 'diagrams/login'
+    my $puml = "$base_name.puml";
+    my $tex  = "$base_name.tex";
+
+    # Message dans le log latexmk
+    print "PlantUML: génération de $tex à partir de $puml\n";
+
+    # Commande PlantUML
+    my $cmd = "$plantuml $plantuml_opts $puml ";
+    my $ret = system($cmd);
+
+    # 0 = succès, 1 = erreur pour latexmk
+    return $ret ? 1 : 0;
+}
+
+# --- Confort ------------------------------------------------------------
+# Compilation continue (latexmk -pvc)
+$preview_continuous = 1;

Recherche/BFT-ARBover/2_Primitives/index.tex

@@ -0,0 +1,34 @@
+\subsection{Reliable Broadcast (RB)}
+
+\RB provides the following properties in the model.
+\begin{itemize}[leftmargin=*]
+  \item \textbf{Integrity}: Every message received was previously sent. $\forall p_i:\ m = \RBreceived_i() \Rightarrow \exists p_j:\ \RBcast_j(m)$.
+  \item \textbf{No-duplicates}: No message is received more than once at any process.
+  \item \textbf{Validity}: If a correct process broadcasts $m$, every correct process eventually receives $m$.
+\end{itemize}
+
+\subsection{DenyList Object}
+
+ We assume a linearizable DenyList (\DL) object as in~\cite{frey:disc23} with the following properties.
+  
+    The DenyList object type supports three operations: $\APPEND$, $\PROVE$, and $\READ$. These operations appear as if executed in a sequence $\Seq$ such that:
+    \begin{itemize}
+      \item \textbf{Termination.} A $\PROVE$, an $\APPEND$, or a $\READ$ operation invoked by a correct process always returns.
+      \item \textbf{APPEND Validity.} The invocation of $\APPEND(x)$ by a process $p$ is valid if:
+      \begin{itemize}
+        \item $p \in \Pi_M \subseteq \Pi$; \textbf{and}
+        \item $x \in S$, where $S$ denote the universe of valid entries to be appended to the DenyList.
+      \end{itemize} 
+      Otherwise, the operation is invalid.
+      \item \textbf{PROVE Validity.} Let $op$ the invocation of $\PROVE(x)$ by a process $p_i$. We said $op$ to be invalid, if and only if:  
+      \begin{itemize}
+        \item $p \not\in \Pi_V \subseteq \Pi$; \textbf{or}
+        \item A valid $\APPEND(x)$ appears before $op$ in $\Seq$. 
+      \end{itemize}
+      Otherwise, the operation is said to be valid.
+      \item \textbf{PROVE Anti-Flickering.} If the invocation of a operation $op = \PROVE(x)$ by a correct process $p \in \Pi_V$ is invalid, then any $\PROVE(x)$ operation that appears after $op$ in $\Seq$ is invalid.
+      \item \textbf{READ Validity.} The invocation of $op = \READ()$ by a process $p \in \pi_V$ returns the list of valid invocations of $\PROVE$ that appears before $op$ in $\Seq$ along with the names of the processes that invoked each operation. 
+      % \item \textbf{Anonymity.} Let us assume the process $p$ invokes a $\PROVE(v)$ operation. If the process $p'$ invokes a $\READ()$ operation, then $p'$ cannot learn the value $v$ unless $p$ leaks additional information.
+    \end{itemize}
+  
+    We assume that $\Pi_M = \Pi_V = \Pi$ (all processes can invoke $\APPEND$ and $\PROVE$).

Recherche/BFT-ARBover/3_ARB_Def/index.tex

@@ -0,0 +1,6 @@
+
+Processes export \ABbroadcast$(m)$ and $m = \ABdeliver()$. \ARB requires total order:
+\begin{equation*}
+  \forall m_1,m_2,\ \forall p_i,p_j:\ \ (m_1 = \ABdeliver_i()) \prec (m_2 = \ABdeliver_i()) \Rightarrow (m_1 = \ABdeliver_j()) \prec (m_2 = \ABdeliver_j())
+\end{equation*}
+plus Integrity/No-duplicates/Validity (inherited from \RB and the construction).

Recherche/BFT-ARBover/4_ARB_with_RB_DL/index.tex

@@ -0,0 +1,455 @@
+We present below an example of implementation of Atomic Reliable Broadcast (\ARB) using a Reliable Broadcast (\RB) primitive and a DenyList (\DL) object according to the model and notations defined in Section 2.
+
+\subsection{Algorithm}
+% granularité diff commentaire de code et paragraphe pre algo
+
+\begin{definition}[Closed round]\label{def:closed-round}
+  Given a \DL{} linearization $H$, a round $r\in\mathcal{R}$ is \emph{closed} in $H$ if $H$ contains an operation $\APPEND(r)$.
+  Equivalently, there exists a time after which every $\PROVE(r)$ is invalid in $H$.
+\end{definition}
+
+\subsubsection{Variables}
+Each process $p_i$ maintains:
+
+\LinesNotNumbered
+\begin{algorithm}
+  $\received \gets \emptyset$\; %\Comment{Messages received via \RB but not yet delivered}
+  $\delivered \gets \emptyset$\; %\Comment{Messages already delivered}
+  $\prop[r][j] \gets \bot,\ \forall r,j$\; %\Comment{Proposal from process $j$ for round $r$}
+  $\current \gets 0$\;
+\end{algorithm}
+
+% \paragraph{DenyList.} The \DL is initialized empty. We assume $\Pi_M = \Pi_V = \Pi$ (all processes can invoke \APPEND and \PROVE).
+
+\subsubsection{Handlers and Procedures}
+
+\LinesNumbered
+\begin{algorithm}[H]
+  \caption{\RB handler (at process $p_i$)}\label{alg:rb-handler}
+  \Fn{RBreceived($S, r, j$)}{
+    $\received \leftarrow \received \cup \{S\}$\;\nllabel{code:receivedConstruction}
+    $\prop[r][j] \leftarrow S$\;\nllabel{code:prop-set} % \Comment{Record sender $j$'s proposal $S$ for round $r$}
+  }
+\end{algorithm}
+
+% \paragraph{} An \ABbroadcast$(m)$ chooses the next open round from the \DL view, proposes all pending messages together with the new $m$, disseminates this proposal via \RB, then executes $\PROVE(r)$ followed by $\APPEND(r)$ to freeze the winners of the round. The loop polls \DL until (i) some winner’s proposal includes $m$ in a \emph{closed} round and (ii) all winners' proposals for closed rounds are known locally, ensuring eventual inclusion and delivery.
+
+\begin{algorithm}[H]\label{alg:ABroadcast}
+  \caption{\ABbroadcast$(m)$ (at process $p_i$)}\label{alg:ab-bcast}
+    \Fn{ABbroadcast($m$)}{
+      $P \leftarrow \READ()$\;\nllabel{code:set-up-read} %\Comment{Fetch latest \DL state to learn recent $\PROVE$ operations}
+      $r_{max} \leftarrow \max(\{ r' : \exists j,\ (j,r') \in P \})$\;\nllabel{code:rmax-compute} %\Comment{Pick current open round}
+      $S \leftarrow (\received \setminus \delivered) \cup \{m\}$\;\nllabel{code:Sconstruction} 
+      %\Comment{Propose all pending messages plus the new $m$}
+
+      \vspace{1em}
+
+      $r \gets r_{max} - 1$\;
+      \While{$((i, r) \not\in P\ \wedge (\nexists j, r': (j, r') \in P \wedge m \in \prop[r'][j]))$}{\nllabel{code:sumbited-check-loop}
+        $r \gets r + 1$\;\nllabel{code:round-increment}
+        $\RBcast(S, r, i)$; $\PROVE(r)$; $\APPEND(r)$;\;\nllabel{code:submit-proposition}
+        $P \leftarrow \READ()$\; % \Comment{Refresh local view of \DL}
+      }
+    }
+\end{algorithm}
+
+\begin{algorithm}[H]\label{alg:ADeliver}
+  \caption{\ABdeliver() at process $p_i$}\label{alg:delivery}
+    \Fn{ABdeliver($\bot$)}{
+      $r \gets \current$\;
+      $P_r \gets \{(j,r): (j,r) \in \READ()\}$ \;
+      \If{$P_r = \emptyset$}{\nllabel{code:check-if-winners}
+        \Return{$\bot$}
+      }
+      $\APPEND(r)$; $P \gets \READ()$\; \nllabel{code:append-read}
+      $W_r \gets \{ j : (j, \PROVEtrace(r)) \in P \}$\;\nllabel{code:Wcompute}
+      \If{$\exists j \in W_r,\ \prop[r][j] = \bot$}{ \nllabel{code:check-winners-ack}
+        \Return{$\bot$}
+      }
+      $M_r \gets \bigcup_{j \in W_r} \prop[r][j]$\;\nllabel{code:Mcompute}
+      $m \gets \ordered(M_r \setminus \delivered)[0]$\;\nllabel{code:next-msg-extraction}
+       %\Comment{Set $m$ as the smaller message not already delivered}
+      $\delivered \leftarrow \delivered \cup \{m\}$\;
+      \If{$M_r \setminus \delivered = \emptyset$}{ %\Comment{Check if all messages from round $r$ have been delivered}
+        $\current \leftarrow \current + 1$
+      }
+      \Return{$m$}
+    }
+\end{algorithm}
+
+% ------------------------------------------------------------------------------
+\subsection{Correctness}
+
+\begin{definition}[First APPEND]\label{def:first-append}
+  Given a \DL{} linearization $H$, for any closed round $r\in\mathcal{R}$, we denote by $\APPEND^{(\star)}(r)$ the earliest $\APPEND(r)$ in $H$.  
+\end{definition}
+
+\begin{remark}[Stable round closure]\label{rem:closure-stable}
+  If a round $r$ is closed, then there exists a linearization point $t_0$ of $\APPEND(r)$ in the \DL, and from that point on, no $\PROVE(r)$ can be valid.
+  Once closed, a round never becomes open again.
+\end{remark}
+
+\begin{proof}
+  By \Cref{def:closed-round}, some $\APPEND(r)$ occurs in the linearization $H$. \\
+  $H$ is a total order of operations, the set of $\APPEND(r)$ operations is totally ordered, and hence there exists a smallest $\APPEND(r)$ in $H$. We denote this operation $\APPEND^{(\star)}(r)$ and $t_0$ its linearization point. \\
+  By the validity property of \DL, a $\PROVE(r)$ is valid iff $\PROVE(r) \prec \APPEND^{(\star)}(r)$. Thus, after $t_0$, no $\PROVE(r)$ can be valid. \\
+  $H$ is a immutable grow-only history, and hence once closed, a round never becomes open again. \\
+  Hence there exists a linearization point $t_0$ of $\APPEND(r)$ in the \DL, and from that point on, no $\PROVE(r)$ can be valid and the closure is stable. 
+\end{proof}
+
+\begin{lemma}[Across rounds]\label{lem:across}
+  If there exists a $r$ such that $r$ is closed, $\forall r'$ such that $r' < r$, r' is also closed.
+\end{lemma}
+
+\begin{proof}
+  \emph{Base.} For a closed round $r=0$, the set $\{r' \in \mathcal{R},\ r' < r\}$ is empty, hence the lemma is true.
+
+  \emph{Induction.} Assume the lemma is true for round $r\geq 0$, we prove it for round $r+1$.
+  
+  \smallskip
+  Assume $r+1$ is closed and by \cref{def:first-append} $\APPEND^{(\star)}(r+1)$ be the earliest $\APPEND(r+1)$ in the DL linearization $H$.
+  By Lemma 1, after an $\APPEND(r)$ were in $H$, any later $\PROVE(r)$ will be invalid also, a process’s program order is preserved in $H$.
+  
+  There are two possibilities for where $\APPEND^{(\star)}(r+1)$ is invoked.
+
+  \begin{itemize}
+    \item \textbf{Case Algorithm \ref{alg:ABroadcast} :}
+    Some process executes the loop at \ref{code:sumbited-check-loop} and invokes $\PROVE(r+1);\APPEND^{(\star)}(r+1)$ at line~\ref{code:submit-proposition}. Let $p_i$ be this process.
+    Immediately before line~\ref{code:submit-proposition}, line~\ref{code:round-increment} sets $r\leftarrow r+1$, so the previous loop iteration targeted $r$. We consider two sub-cases.
+    
+    \begin{itemize}
+      \item \emph{(i) $p_i$ is not in its first loop iteration.}
+      In the previous iteration, $p_i$ executed $\PROVE_i(r)$ at \ref{code:submit-proposition}, followed (in program order) by $\APPEND_i(r)$. 
+      If round $r$ wasn't closed when $p_i$ execute $\PROVE_i(r)$ at \ref{code:submit-proposition}, then the condition at \ref{code:sumbited-check-loop} would be true hence the tuple $(i, r)$ should be visible in P which implies that $p_i$ should leave the loop at round $r$, contradicting the assumption that $p_i$ is now executing another iteration.
+      Since the tuple is not visible, the $\PROVE_i(r)$ was invalid which implies by definition that an $\APPEND(r)$ already exists in $H$. Thus in this case $r$ is closed.
+    
+      \item \emph{(ii) $p_i$ is in its first loop iteration.}
+      To compute the value $r_{max}$, $p_i$ must have observed one or many $(\_ , r+1)$ in $P$ at \ref{code:rmax-compute}, issued by some processes (possibly different from $p_i$). Let's call $p_j$ the issuer of the first $\PROVE_j(r+1)$ in the linearization $H$. \\
+      When $p_j$ executed $P \gets \READ()$ at \ref{code:set-up-read} and compute $r_{max}$ at \ref{code:rmax-compute}, he observed no tuple $(\_,r+1)$ in $P$ because he's the issuer of the first one. So when $p_j$ executed the loop (\ref{code:sumbited-check-loop}), he run it for the round $r$, didn't seen any $(j,r)$ in $P$ at B6, and then executed the first $\PROVE_j(r+1)$ at \ref{code:submit-proposition} in a second iteration. \\
+      If round $r$ wasn't closed when $p_j$ execute $\PROVE_j(r)$ at \ref{code:submit-proposition}, then the $(j, r)$ will be in $P$ and the condition at \ref{code:sumbited-check-loop} should be true which implies that $p_j$ sould leave the loop at round $r$, contradicting the assumption that $p_j$ is now executing $\PROVE_j(r+1)$. In this case $r$ is closed.
+    \end{itemize}
+    
+    \item \textbf{Case Algorithm \ref{alg:ADeliver} :} 
+    Some process invokes $\APPEND(r+1)$ at \ref{code:append-read}. Let $p_i$ be this process.  
+    Line~\ref{code:append-read} is guarded by the condition at \ref{code:check-if-winners}, which ensures that $p_i$ observed some $(\_,r+1)$ in $P$. Let $p_j$ be the issuer of the first $\PROVE_j(r+1)$ in the linearization $H$.
+    When $p_j$ executed $\PROVE_j(r+1)$ at \ref{code:submit-proposition}, he observed no tuple $(\_,r+1)$ in $P$ at \ref{code:check-if-winners} because he's the issuer of the first one. By the same reasoning as in the Case Algorithm \ref{alg:ABroadcast} (ii), $p_j$ must have observed that the round $r$ was closed. 
+    % Line C7 is guarded by the presence of $\PROVE(r)$ in $P$ with $r=r+1$ (C5). 
+    % Moreover, the local pointer $\textit{next}$ grow by increment of 1 and only advances after finishing the current round (C17), so if a process can reach $\textit{next}=r+1$ it implies that he has completed round $r$, which includes closing $r$ at C8 when $\PROVE(r)$ is observed. 
+    % Hence $\APPEND^\star(r+1)$ implies a prior $\APPEND(r)$ in $H$, so $r$ is closed.
+  \end{itemize}
+  
+  \smallskip
+  In all cases, $r+1$ closed implies $r$ closed. By induction on $r$, if the lemma is true for a closed $r$ then it is true for a closed $r+1$.
+  Therefore, the lemma is true for all closed rounds $r$.
+\end{proof}
+
+\begin{definition}[Winner Invariant]\label{def:winner-invariant}
+  For any closed round $r$, define
+  \[
+    \Winners_r \triangleq \{ j : \PROVE_j(r) \prec \APPEND^\star(r) \}
+  \] 
+  called the unique set of winners of round $r$.
+\end{definition}
+
+\begin{lemma}[Invariant view of closure]\label{lem:closure-view}
+  For any closed round $r$, all correct processes eventually observe the same set of valid tuples $(\_,\PROVEtrace(r))$ in their \DL view.
+\end{lemma}
+  
+\begin{proof}
+  Let's take a closed round $r$. By \Cref{def:first-append}, there exists $\APPEND^{(\star)}(r)$ the earliest $\APPEND(r)$ in the DL linearization.
+
+  Consider any correct process $p_i$ that invokes $\READ()$ after $\APPEND^\star(r)$ in the DL linearization. Since $\APPEND^\star(r)$ invalidates all subsequent $\PROVE(r)$, the set of valid tuples $(\_,r)$ retrieved by a $\READ()$ after $\APPEND^\star(r)$ is fixed and identical across all correct processes.
+
+  Therefore, for any closed round $r$, all correct processes eventually observe the same set of valid tuples $(\_,\PROVEtrace(r))$ in their \DL view.
+\end{proof}
+
+\begin{lemma}[Well-defined winners]\label{lem:winners}
+  For any correct process $p_i$ and round $r$, if $p_i$ computes $W_r$ at line~\ref{code:Wcompute}, then :
+  \begin{itemize}
+    \item $\Winners_r$ is defined;
+    \item the computed $W_r$ is exactly $\Winners_r$.
+  \end{itemize}
+\end{lemma}
+
+\begin{proof}
+  Lets consider a correct process $p_i$ that reach line~\ref{code:Wcompute} to compute $W_r$. \\
+  By program order, $p_i$ must have executed $\APPEND_i(r)$ at line~\ref{code:append-read} before, which implies by \Cref{def:closed-round} that round $r$ is closed at that point. So by \Cref{def:winner-invariant}, $\Winners_r$ is defined. \\
+  By \Cref{lem:closure-view}, all correct processes eventually observe the same set of valid tuples $(\_,r)$ in their \DL view. Hence, when $p_i$ executes the $\READ()$ at line~\ref{code:append-read} after the $\APPEND_i(r)$, it observes a set $P$ that includes all valid tuples $(\_,r)$ such that
+  \[
+    W_r = \{ j : (j,r) \in P \} = \{j : \PROVE_j(r) \prec \APPEND^{(\star)}(r) \} = \Winners_r
+  \]
+\end{proof}
+
+\begin{lemma}[No APPEND without PROVE]\label{lem:append-prove}
+If some process invokes $\APPEND(r)$, then at least a process must have previously invoked $\PROVE(r)$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Consider the round $r$ such that some process invokes $\APPEND(r)$. There are two possible cases
+  
+  \begin{itemize}
+    \item \textbf{Case (\ref{code:submit-proposition}) :}
+    There exists a process $p_i$ who's the issuer of the earliest $\APPEND^{(\star)}(r)$ in the DL linearization $H$. By program order, $p_i$ must have previously invoked $\PROVE_i(r)$ before invoking $\APPEND^{(\star)}(r)$ at line~\ref{code:submit-proposition}. In this case, there is at least one $\PROVE(r)$ valid in $H$ issued by a correct process before $\APPEND^{(\star)}(r)$.
+    
+    \item \textbf{Case (\ref{code:append-read}) :}
+    There exists a process $p_i$ that invoked $\APPEND^{(\star)}(r)$ at . Line~\ref{code:append-read} is guarded by the condition at \ref{code:check-if-winners}, which ensures that $p$ observed some $(\_,r)$ in $P$. In this case, there is at least one $\PROVE(r)$ valid in $H$ issued by some process before $\APPEND^{(\star)}(r)$.
+  \end{itemize}
+    
+  In both cases, if some process invokes $\APPEND(r)$, then some process must have previously invoked $\PROVE(r)$.
+\end{proof}
+
+\begin{lemma}[No empty winners]\label{lem:nonempty}
+  Let $r$ be a closed round, then $\Winners_r \neq \emptyset$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  By \Cref{def:closed-round}, some $\APPEND(r)$ occurs in the DL linearization. \\
+  By \Cref{lem:append-prove}, at least one process must have invoked a valid $\PROVE(r)$ before $\APPEND^{(\star)}(r)$. Hence, there exists at least one $p_j$ such that $p_j$ invoked $\PROVE_j(r) \prec \APPEND^\star(r)$, so $\Winners_r \neq \emptyset$.
+\end{proof}
+
+\begin{lemma}[Winners must propose]\label{lem:winners-propose}
+  For any closed round $r$, $\forall i \in \Winners_r$, process $p_i$ must have invoked a $\RBcast(S^{(i)}, r, i)$ and hence any correct will eventually set $\prop[r][i]$ to a non-$\bot$ value.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Fix a closed round $r$. By \Cref{def:winner-invariant}, for any $i \in \Winners_r$, there exist a valid $\PROVE_i(r)$ such that $\PROVE_i(r) \prec \APPEND^\star(r)$ in the DL linearization. By program order, if $i$ invoked a valid $\PROVE_i(r)$ at line~\ref{code:submit-proposition} he must have invoked $\RBcast(S^{(i)}, r, i)$ directly before.
+
+  Let take a correct process $p_j$, by \RB \emph{Validity}, every correct process eventually receives $i$'s \RB message for round $r$, which sets $\prop[r][i]$ to a non-$\bot$ value at line~\ref{code:prop-set}.
+\end{proof}
+
+\begin{definition}[Messages invariant]\label{def:messages-invariant}
+  For any closed round $r$ and any correct process $p_i$ such that $\forall j \in \Winners_r : prop^{[i)}[r][j] \neq \bot$, define
+  \[
+    \Messages_r \triangleq \bigcup_{j\in\Winners_r} \prop^{(i)}[r][j]
+  \]
+  as the set of messages proposed by the winners of round $r$.
+\end{definition}
+
+\begin{lemma}[Eventual proposal closure]\label{lem:eventual-closure}
+  If a correct process $p_i$ define $M_r$ at line~\ref{code:Mcompute}, then for every $j \in \Winners_r$, $\prop^{(i)}[r][j] \neq \bot$. 
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let take a correct process $p_i$ that computes $M_r$ at line~\ref{code:Mcompute}. By \Cref{lem:winners}, $p_i$ computation is the winner set $\Winners_r$.
+
+  By \Cref{lem:nonempty}, $\Winners_r \neq \emptyset$. The instruction at line~\ref{code:Mcompute} where $p_i$ computes $M_r$ is guarded by the condition at line~\ref{code:check-winners-ack}, which ensures that $p_i$ has received all \RB messages from every winner $j \in \Winners_r$. Hence, $M_r = \bigcup_{j\in\Winners_r} \prop^{(i)}[r][j]$, we have $\prop^{(i)}[r][j] \neq \bot$ for all $j \in \Winners_r$.
+\end{proof}
+
+\begin{lemma}[Unique proposal per sender per round]\label{lem:unique-proposal}
+  For any round $r$ and any process $p_i$, $p_i$ invokes at most one $\RBcast(S, r, i)$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  By program order, any process $p_i$ invokes $\RBcast(S, r, i)$ at line~\ref{code:submit-proposition} must be in the loop \ref{code:sumbited-check-loop}. No matter the number of iterations of the loop, line~\ref{code:sumbited-check-loop} always uses the current value of $r$ which is incremented by 1 at each turn. Hence, in any execution, any process $p_i$ invokes $\RBcast(S, r, j)$ at most once for any round $r$.
+\end{proof}
+
+\begin{lemma}[Proposal convergence]\label{lem:convergence}
+  For any round $r$, for any correct processes $p_i$ that execute line~\ref{code:Mcompute}, we have
+  \[
+    M_r^{(i)} = \Messages_r
+  \]
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let take a correct process $p_i$ that compute $M_r$ at line~\ref{code:Mcompute}. That implies that $p_i$ has defined $W_r$ at line~\ref{code:Wcompute}. It implies that, by \Cref{lem:winners}, $r$ is closed and $W_r = \Winners_r$. \\
+  By \Cref{lem:eventual-closure}, for every $j \in \Winners_r$, $\prop^{(i)}[r][j] \neq \bot$. By \Cref{lem:unique-proposal}, each winner $j$ invokes at most one $\RBcast(S^{(j)}, r, j)$, so $\prop^{(i)}[r][j] = S^{(j)}$ is uniquely defined. Hence, when $p_i$ computes
+  \[
+    M_r^{(i)} = \bigcup_{j\in\Winners_r} \prop^{(i)}[r][j] = \bigcup_{j\in\Winners_r} S^{(j)} = \Messages_r.
+  \]
+\end{proof}
+
+\begin{lemma}[Inclusion]\label{lem:inclusion}
+  If some correct process invokes $\ABbroadcast(m)$, then there exist a round $r$ and a process $j\in\Winners_r$ such that $p_j$ invokes
+  \[
+  \RBcast(S, r, j)\quad\text{for same S with}\quad m\in S.
+  \]
+\end{lemma}
+
+\begin{proof}
+  Fix a correct process $p_i$ that invokes $\ABbroadcast(m)$ and eventually exits the loop (\ref{code:sumbited-check-loop}) at some round $r$. There are two possible cases.
+
+  \begin{itemize}
+    \item \textbf{Case 1:} $p_i$ exits the loop because $(i, r) \in P$. In this case, by \Cref{def:winner-invariant}, $p_i$ is a winner in round $r$. By program order, $p_i$ must have invoked $\RBcast(S, r, i)$ at \ref{code:submit-proposition} before invoking $\PROVE_i(r)$. By line~\ref{code:Sconstruction}, $m \in S$. Hence there exist a closed round $r$ and $p_i$ is a correct process such that $i\in\Winners_r$. Hence, $i$ invokes $\RBcast(S, r, i)$ with $m\in S$.
+    
+    \item \textbf{Case 2:} $p_i$ exits the loop because $\exists j, r': (j, r') \in P \wedge m \in \prop[r'][j]$. In this case, by \Cref{lem:winners-propose} and \Cref{lem:unique-proposal} $p_j$ must have invoked a unique $\RBcast(S, r', j)$. Which set $\prop^{(i)}[r'][j] = S$ with $m \in S$.
+  \end{itemize}
+    
+  In both cases, if some correct process invokes $\ABbroadcast(m)$, then there exist a round $r$ and a correct process $j\in\Winners_r$ such that $j$ invokes
+  \[
+    \RBcast(S, r, j)\quad\text{with}\quad m\in S.
+  \]
+\end{proof}
+
+\begin{lemma}[Broadcast Termination]\label{lem:bcast-termination}
+  A correct process which invokes $\ABbroadcast(m)$, eventually exits the function and returns.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Consider a correct process $p_i$ that invokes $\ABbroadcast(m)$. The statement is true if $\exists r_1$ such that $r_1 \geq r_{max}$ and if $(i, r_1) \in P$; or if $\exists r_2$ such that $r_2 \geq r_{max}$ and if $\exists j: (j, r_2) \in P \wedge m \in \prop[r_2][j]$ (like guarded at B8).
+
+  Consider that there exists no round $r_1$ such that $p_i$ invokes a valid $\PROVE(r_1)$. In this case $p_i$ invokes infinitely many $\RBcast(S, \_, i)$ at line~\ref{code:submit-proposition} with $m \in S$ (line~\ref{code:Sconstruction}).\\
+  The assumption that no $\PROVE(r_1)$ invoked by $p$ is valid implies by \DL \emph{Validity} that for every round $r' \geq r_{max}$, there exists at least one $\APPEND(r')$ in the DL linearization, hence by \Cref{lem:nonempty} for every possible round $r'$ there at least a winner. Because there is an infinite number of rounds, and a finite number of processes, there exists at least one process $p_k$ that invokes infinitely many valid $\PROVE(r')$ and by extension infinitely many $\ABbroadcast(\_)$. By \RB \emph{Validity}, $p_k$ eventually receives $p_i$ 's \RB messages. Let call $t_0$ the time when $p_k$ receives $p_i$ 's \RB message. \\
+  At $t_0$, $p_k$ executes Algorithm \ref{alg:rb-handler} and sets $\received \leftarrow \received \cup \{S\}$ with $m \in S$ (line~\ref{code:receivedConstruction}). 
+  For the first invocation of $\ABbroadcast(\_)$ by $p_k$ after the execution of \texttt{RReceived()}, $p_k$ must include $m$ in his proposal $S$ at line~\ref{code:Sconstruction} (because $m$ is pending in $j$'s $\received \setminus \delivered$ set). There exists a minimum round $r_2$ such that $p_k \in \Winners_{r_2}$ after $t_0$. By \Cref{lem:winners-propose}, eventually $\prop^{(i)}[r_2][k] \neq \bot$. By \Cref{lem:unique-proposal}, $\prop^{(i)}[r_2][k]$ is uniquely defined as the set $S$ proposed by $p_k$ at B6, which by \Cref{lem:inclusion} includes $m$. Hence eventually $m \in \prop^{(i)}[r_2][k]$ and $k \in \Winners_{r_2}$. 
+
+  So if $p_i$ is a winner he satisfies the condition $(i, r_1) \in P$. And we show that if the first condition is never satisfied, the second one will eventually be satisfied. Hence either the first or the second condition will eventually be satisfied, and $p_i$ eventually exits the loop and returns from $\ABbroadcast(m)$.
+\end{proof}
+
+\begin{lemma}[Validity]\label{lem:validity}
+  If a correct process $p$ invokes $\ABbroadcast(m)$, then every correct process that invokes a infinitely many times $\ABdeliver()$ eventually delivers $m$.
+\end{lemma}
+
+\begin{proof}[Proof]
+  Let $p_i$ a correct process that invokes $\ABbroadcast(m)$ and $p_q$ a correct process that infinitely invokes $\ABdeliver()$. By \Cref{lem:inclusion}, there exist a closed round $r$ and a correct process $j\in\Winners_r$ such that $p_j$ invokes
+  \[
+    \RBcast(S, r, j)\quad\text{with}\quad m\in S.
+  \]
+
+  By \Cref{lem:eventual-closure}, when $p_q$ computes $M_r$ at line~\ref{code:Mcompute}, $\prop[r][j]$ is non-$\bot$ because $j \in \Winners_r$. By \Cref{lem:unique-proposal}, $p_j$ invokes at most one $\RBcast(S, r, j)$, so $\prop[r][j]$ is uniquely defined. Hence, when $p_q$ computes
+  \[
+    M_r = \bigcup_{k\in\Winners_r} \prop[r][k],
+  \]
+  we have $m \in \prop[r][j] = S$, so $m \in M_r$. By \Cref{lem:convergence}, $M_r$ is invariant so each computation of $M_r$ by a correct process includes $m$. At each invocation of $m' = \ABdeliver()$, $m'$ is added to $\delivered$ until $M_r \subseteq \delivered$. Once this happens we're assured that there exists an invocation of $\ABdeliver()$ which return $m$. Hence $m$ is well delivered.
+\end{proof}
+
+\begin{lemma}[No duplication]\label{lem:no-duplication}
+  No correct process delivers the same message more than once.
+\end{lemma}
+
+\begin{proof}
+  Let consider two invokations of $\ABdeliver()$ made by the same correct process which returns $m$. Let call these two invocations respectively $\ABdeliver^{(A)}()$ and $\ABdeliver^{(B)}()$.
+
+  When $\ABdeliver^{(A)}()$ occurs, by program order and because it reached line C18 to return $m$, the process must have add $m$ to $\delivered$. Hence when $\ABdeliver^{(B)}()$ reached line~\ref{code:next-msg-extraction} to extract the next message to deliver, it can't be $m$ because $m \not\in (M_r \setminus \{..., m, ...\})$. So a $\ABdeliver^{(B)}()$ which delivers $m$ can't occur.
+\end{proof}
+
+\begin{lemma}[Total order]\label{lem:total-order}
+  For any two messages $m_1$ and $m_2$ delivered by correct processes, if a correct process $p_i$ delivers $m_1$ before $m_2$, then any correct process $p_j$ that delivers both $m_1$ and $m_2$ delivers $m_1$ before $m_2$.  
+\end{lemma}
+
+\begin{proof}
+  Consider a correct process that delivers both $m_1$ and $m_2$. By \Cref{lem:validity}, there exists a closed rounds $r'_1$ and $r'_2$ and correct processes $k_1 \in \Winners_{r'_1}$ and $k_2 \in \Winners_{r'_2}$ such that
+  \[
+    \RBcast(S_1, r'_1, k_1)\quad\text{with}\quad m_1\in S_1,
+  \]
+  \[
+    \RBcast(S_2, r'_2, k_2)\quad\text{with}\quad m_2\in S_2.
+  \]
+
+  Let consider three cases :
+  \begin{itemize}
+    \item \textbf{Case 1:} $r_1 < r_2$. By program order, any correct process must have waited to append in $\delivered$ every messages in $M_{r_1}$ (which contains $m_1$) to increment $\current$ and eventually set $\current = r_2$ to compute $M_{r_2}$ and then invoke the $ m_2 = \ABdeliver()$. Hence, for any correct process that delivers both $m_1$ and $m_2$, it delivers $m_1$ before $m_2$.
+    
+    \item \textbf{Case 2:} $r_1 = r_2$. By \Cref{lem:convergence}, any correct process that computes $M_{r_1}$ at line~\ref{code:Mcompute} computes the same set of messages $\Messages_{r_1}$. By line~\ref{code:next-msg-extraction} the messages are pull in a deterministic order defined by $\ordered(\_)$. Hence, for any correct process that delivers both $m_1$ and $m_2$, it delivers $m_1$ and $m_2$ in the deterministic order defined by $\ordered(\_)$.
+  \end{itemize}
+
+  In all possible cases, any correct process that delivers both $m_1$ and $m_2$ delivers $m_1$ and $m_2$ in the same order.
+\end{proof}
+
+\begin{lemma}[Fifo Order]\label{lem:fifo-order}
+  For any two distints messages $m_1$ and $m_2$ broadcast by the same correct process $p_i$, if $p_i$ invokes $\ABbroadcast(m_1)$ before $\ABbroadcast(m_2)$, then any correct process $p_j$ that delivers both $m_1$ and $m_2$ delivers $m_1$ before $m_2$.
+\end{lemma}
+
+\begin{proof}
+  Let take $m_1$ and $m_2$ broadcast by the same correct process $p_i$, with $p_i$ invoking $\ABbroadcast(m_1)$ before $\ABbroadcast(m_2)$. By \Cref{lem:validity}, there exist closed rounds $r_1$ and $r_2$ such that $r_1 \leq r_2$ and correct processes $k_1 \in \Winners_{r_1}$ and $k_2 \in \Winners_{r_2}$ such that
+  \[
+    \RBcast(S_1, r_1, k_1)\quad\text{with}\quad m_1\in S_1,
+  \]
+  \[
+    \RBcast(S_2, r_2, k_2)\quad\text{with}\quad m_2\in S_2.
+  \]
+
+  By program order, $p_i$ must have invoked $\RBcast(S_1, r_1, i)$ before $\RBcast(S_2, r_2, i)$. By \Cref{lem:unique-proposal}, any process invokes at most one $\RBcast(S, r, i)$ per round, hence $r_1 < r_2$. By \Cref{lem:total-order}, any correct process that delivers both $m_1$ and $m_2$ delivers them in a deterministic order.
+  
+  In all possible cases, any correct process that delivers both $m_1$ and $m_2$ delivers $m_1$ before $m_2$.
+\end{proof}
+
+\begin{theorem}[FIFO-\ARB]
+Under the assumed $\DL$ synchrony and $\RB$ reliability, the algorithm implements FIFO Atomic Reliable Broadcast.
+\end{theorem}
+
+\begin{proof}
+  We show that the algorithm satisfies the properties of FIFO Atomic Reliable Broadcast under the assumed $\DL$ synchrony and $\RB$ reliability.
+
+  First, by \Cref{lem:bcast-termination}, if a correct process invokes $\ABbroadcast(m)$, then it eventually returns from this invocation.
+  Moreover, \Cref{lem:validity} states that if a correct process invokes $\ABbroadcast(m)$, then every correct process that invokes $\ABdeliver()$ infinitely often eventually delivers $m$.
+  This gives the usual Validity property of $\ARB$.
+
+  Concerning Integrity and No-duplicates, the construction only ever delivers messages that have been obtained from the underlying $\RB$ primitive.
+  By the Integrity property of $\RB$, every such message was previously $\RBcast$ by some process, so no spurious messages are delivered.
+  In addition, \Cref{lem:no-duplication} states that no correct process delivers the same message more than once.
+  Together, these arguments yield the Integrity and No-duplicates properties required by $\ARB$.
+
+  For the ordering guarantees, \Cref{lem:total-order} shows that for any two messages $m_1$ and $m_2$ delivered by correct processes, every correct process that delivers both $m_1$ and $m_2$ delivers them in the same order.
+  Hence all correct processes share a common total order on delivered messages.
+  Furthermore, \Cref{lem:fifo-order} states that for any two messages $m_1$ and $m_2$ broadcast by the same correct process, any correct process that delivers both messages delivers $m_1$ before $m_2$ whenever $m_1$ was broadcast before $m_2$.
+  Thus the global total order extends the per-sender FIFO order of $\ABbroadcast$.
+
+  All the above lemmas are proved under the assumptions that $\DL$ satisfies the required synchrony properties and that the underlying primitive is a Reliable Broadcast ($\RB$) with Integrity, No-duplicates and Validity.
+  Therefore, under these assumptions, the algorithm satisfies Validity, Integrity/No-duplicates, total order and per-sender FIFO order, and hence implements FIFO Atomic Reliable Broadcast, as claimed.
+\end{proof}
+
+\subsection{Reciprocity}
+% ------------------------------------------------------------------------------
+
+So far, we assumed the existence of a synchronous DenyList ($\DL$) object and showed how to upgrade a Reliable Broadcast ($\RB$) primitive into FIFO Atomic Reliable Broadcast ($\ARB$). We now briefly argue that, conversely, an $\ARB$ primitive is strong enough to implement a synchronous $\DL$ object.
+
+\xspace
+
+\paragraph{DenyList as a deterministic state machine.}
+Without anonymity, the \DL specification defines a
+deterministic abstract object: given a sequence $\Seq$ of operations
+$\APPEND(x)$, $\PROVE(x)$, and $\READ()$, the resulting sequence of return
+values and the evolution of the abstract state (set of appended elements,
+history of operations) are uniquely determined.
+
+\paragraph{State machine replication over \ARB.}
+Assume a system that exports a FIFO-\ARB primitive with the guarantees that if a correct process invokes $\ABbroadcast(m)$, then every correct process eventually $\ABdeliver(m)$ and the invocation eventually returns.
+Following the classical \emph{state machine replication} approach
+such as described in Schneider~\cite{Schneider90}, we can implement a fault-tolerant service by ensuring the following properties:
+\begin{quote}
+  \textbf{Agreement.} Every nonfaulty state machine replica receives every request. \\
+  \textbf{Order.} Every nonfaulty state machine replica processes the requests it receives in
+  the same relative order.
+\end{quote}
+
+Which are cover by our FIFO-\ARB specification.
+
+\paragraph{Correctness.}
+
+
+\begin{theorem}[From \ARB to synchronous \DL]\label{thm:arb-to-dl}
+  In an asynchronous message-passing system with crash failures, assume a FIFO Atomic Reliable Broadcast primitive with Integrity, No-duplicates,Validity, and the liveness of $\ABbroadcast$. Then there exists an implementation of a DenyList object that satisfies Termination, Validity, and Anti-flickering properties.
+\end{theorem}
+
+\begin{proof}
+  Because the \DL object is deterministic, all correct processes see the same sequence of operations and compute the same sequence of states and return values. We obtain:
+
+  \begin{itemize}[leftmargin=*]
+    \item \textbf{Termination.} The liveness of \ARB ensures that each $\ABbroadcast$ invocation by a correct process eventually returns, and the corresponding operation is eventually delivered and applied at all correct processes. Thus every $\APPEND$, $\PROVE$, and $\READ$ operation invoked by a correct process eventually returns.
+    \item \textbf{APPEND/PROVE/READ Validity.} The local code that forms \ABbroadcast requests can achieve the same preconditions as in the abstract \DL specification (e.g., $p\in\Pi_M$, $x\in S$ for $\APPEND(x)$). Once an operation is delivered, its effect and return value are exactly those of the sequential \DL specification applied in the common order.
+    \item \textbf{PROVE Anti-Flickering.} In the sequential \DL specification, once an element $x$ has been appended, all subsequent $\PROVE(x)$ are invalid forever. Since all replicas apply operations in the same order, this property holds in every execution of the replicated implementation: after the first linearization point of $\APPEND(x)$, no later $\PROVE(x)$ can return ``valid'' at any correct process.
+  \end{itemize}
+
+  Formally, we can describe the \DL object with the state machine approach for
+  crash-fault, asynchronous message-passing systems with a total order broadcast
+  layer~\cite{Schneider90}.
+\end{proof}
+
+\subsubsection{Example executions}
+
+\begin{figure}
+  \centering
+  \resizebox{0.4\textwidth}{!}{
+    \input{diagrams/nonBFT_behaviour.tex}
+  }
+  \caption{Example execution of the ARB algorithm in a non-BFT setting}
+\end{figure}
+
+
+\begin{figure}
+  \centering
+  \resizebox{0.4\textwidth}{!}{
+    \input{diagrams/BFT_behaviour.tex}
+  }
+  \caption{Example execution of the ARB algorithm with a byzantine process}
+\end{figure}

Recherche/BFT-ARBover/5_BFT_ARB/index.tex

@@ -0,0 +1,428 @@
+
+\subsection{Model extension}
+We consider a static set $\Pi$ of $n$ processes with known identities, communicating by reliable point-to-point channels, in a complete graph. Messages are uniquely identifiable. At most $f$ processes may be Byzantine, and we assume $n > 3f$.
+
+\paragraph{Synchrony.} The network is asynchronous.
+
+\paragraph{Communication.} Processes can exchange through a Reliable Broadcast ($\RB$) primitive (defined below) which is invoked with the functions $\RBcast(m)$ and $m = \RBreceived()$. There exists a shared object called DenyList ($\DL$) (defined below) that is interfaced with a set $O$ of operations. There exist three types of these operations: $\APPEND(x)$, $\PROVE(x)$ and $\READ()$.
+
+\paragraph{Byzantine behaviour}
+A process is said to exhibit Byzantine behaviour if it deviates arbitrarily from the prescribed algorithm. Such deviations may, for instance, consist in invoking primitives ($\RBcast$, $\APPEND$, $\PROVE$, etc.) with invalid inputs or inputs crafted maliciously, colluding with other Byzantine processes in an attempt to manipulate the system state or violate its guarantees, deliberately delaying or accelerating the delivery of messages to selected nodes so as to disrupt the expected timing of operations, or withholding messages and responses in order to induce inconsistencies in the system state.
+
+Byzantine processes are constrained by the following. They cannot forge valid cryptographic signatures or threshold shares without access to the corresponding private keys. They cannot violate the termination, validity, or anti-flickering properties of the $\DL$ object. They also cannot break the integrity, no-duplicates, or validity properties of the $\RB$ primitive.
+
+
+\paragraph{Notation.} For any indice $k$ we defined by $\DL[k]$ as the $k$-th DenyList object. For a given $\DL[k]$ and any indice $x$ we defined by $\Pi_x^k$ a subset of $\Pi$. Still for a given $k$ we consider $\Pi_M^k \subseteq \Pi$ and $\Pi_V^k \subseteq \Pi$ two authorization subsets for $\DL[k]$. Indice $i \in \Pi$ refer to processes, and $p_i$ denotes the process with identifier $i$. Let $\mathcal{M}$ denote the universe of uniquely identifiable messages, with $m \in \mathcal{M}$. Let $\mathcal{R} \subseteq \mathbb{N}$ be the set of round identifiers; we write $r \in \mathcal{R}$ for a round. We use the precedence relation $\prec_k$ for the $\DL[k]$ linearization: $x \prec_k y$ means that operation $x$ appears strictly before $y$ in the linearized history of $\DL[k]$. For any finite set $A \subseteq \mathcal{M}$, \ordered$(A)$ returns a deterministic total order over $A$ (e.g., lexicographic order on $(\textit{senderId},\textit{messageId})$ or on message hashes).
+For any operation $F \in O$,$F_i(...)$ denotes that the operation $F$ is invoked by process $p_i$, and by $F_i^k(...)$ the same operation invoked on the $\DL[k]$ object.
+
+% ------------------------------------------------------------------------------
+\subsection{Primitives}
+
+\subsubsection{t-BFT-DL}
+
+We consider a t-Byzantine Fault Tolerant DenyList (t-$\BFTDL$) with the following properties.
+There are 3 operations : $\BFTPROVE(x), \BFTAPPEND(x), \BFTREAD()$ such that :
+
+\paragraph{Termination.} Every operation $\BFTAPPEND(x)$, $\BFTPROVE(x)$, and $\BFTREAD()$ invoked by a correct process always returns.
+
+\paragraph{PROVE Validity.} The invocation of $op = \BFTPROVE(x)$ by a correct process is valid iff there exist a set of correct process $C$ such that $\forall c \in C$, $c$ invoke $op_2 = \BFTAPPEND(x)$ with $op_2 \prec op_1$ and $|C| \leq t$
+
+\paragraph{PROVE Anti-Flickering.} If the invocation of a operation $op = \BFTPROVE(x)$ by a correct process $p \in \Pi_V$ is invalid, then any $\BFTPROVE(x)$ operation that appears after $op$ in $\Seq$ is invalid.
+
+\paragraph{READ Liveness.} Let $op = \BFTREAD()$ invoke by a correct process such that $R$ is the result of $op$. For all $(i, \PROVEtrace(x)) \in R$ there exist a valid invocation of $\BFTPROVE(x)$ by $p_i$.
+
+\paragraph{READ Anti-Flickering.} Let $op_1, op_2$ two $\BFTREAD()$ operations that returns respectively $R_1, R_2$. Iff $op_1 \prec op_2$ then $R_2 \subseteq R_1$. Otherwise $R_1 \subseteq R_2$.
+
+\paragraph{READ Safety.} Let $op_1, op_2$ respectively a valid $\BFTPROVE(x)$ operation submited by the process $p_i$ and a $\BFTREAD()$ operation submited by any correct process such that $op_1 \prec op_2$. Let $R$ the result of $op_2$ then $R \ni (i, x)$
+
+\subsection{DL $\Rightarrow$ t-BFT-DL}
+
+
+Fix $3t < |M|$. Let
+\[
+\mathcal{U} = \{\, U \subseteq M \mid |U| = |M| - t \,\}.
+\]
+For each $U \in \mathcal{U}$, we instantiate one DenyList object $DL_U$ whose authorization sets are
+\[
+\Pi_M(DL_T) = S_T = U
+\qquad\text{and}\qquad
+\Pi_V(DL_T) = V.
+\]
+
+\[
+|\mathcal{U}| = \binom{|M|}{|M| - t}.
+\]
+
+\begin{algorithm}
+    \caption{t-BFT-DL implementation using multiple DL objects}
+
+    \Fn{$\BFTAPPEND(x)$}{
+        \For{\textbf{each } $U \in \mathcal{U}$ st $i \in U$}{
+            $DL_U.\APPEND(x)$\;
+        }
+    }
+
+    \vspace{1em}
+
+    \Fn{$\BFTPROVE(x)$}{
+        $state \gets false$\;
+        \For{\textbf{each } $U \in \mathcal{U}$}{
+            $state \gets state \textbf{ OR } DL_U.\PROVE(x)$\;\nllabel{code:prove-or}
+        }
+        \Return{$state$}\;
+    }
+
+    \vspace{1em}
+
+    \Fn{$\BFTREAD()$}{
+        $results \gets \emptyset$\;
+        \For{\textbf{each } $U \in \mathcal{U}$}{
+            $results \gets results \cup DL_U.\READ()$\;
+        }
+        \Return{$results$}\;
+    }
+\end{algorithm}
+
+\begin{lemma}[BFT-PROVE Validity]\label{lem:bft-prove-validity}
+    The invocation of $op = \BFTPROVE(x)$ by a correct process is invalid iff there exist at least $t+1$ distinct processes in $M$ that invoked a valid $\BFTAPPEND(x)$ before $op$ in $\Seq$.
+\end{lemma}
+
+\begin{proof}
+    Let $op=\BFTPROVE(x)$ be an invocation by a correct process $p_i$. Let $A\subseteq M$ be the set of distinct issuers that invoked $\BFTAPPEND(x)$ before $op$ in $\Seq$.
+
+    \begin{itemize}
+        \item \textbf{Case (i): $|A|\ge t+1$.}
+        Fix any $U\in\mathcal{U}$. $A\cap U\neq\emptyset$. Pick $j\in A\cap U$. Since $j\in U$, the call $\BFTAPPEND_j(x)$ triggers $DL_U.\APPEND(x)$, and because $\BFTAPPEND_j(x)\prec op$ in $\Seq$, this induces a valid $DL_U.\APPEND(x)$ that appears before the induced $DL_U.\PROVE(x)$ by $p_i$. By \textbf{PROVE Validity} of $\DL$, the induced $DL_U.\PROVE(x)$ is invalid. As this holds for every $U\in\mathcal{U}$, there is \emph{no} component $DL_U$ where $\PROVE(x)$ is valid, so the field $state$ at line~\ref{code:prove-or} is never becoming true, and $op$ return false.
+
+        \item \textbf{Case (ii): $|A|\le t$.}
+        There exists $U^\star\in\mathcal{U}$ such that $A\cap U^\star=\emptyset$. For any $j\in A$, we have $j\notin U^\star$, so $\BFTAPPEND_j(x)$ does \emph{not} call $DL_{U^\star}.\APPEND(x)$. Hence no valid $DL_{U^\star}.\APPEND(x)$ appears before the induced $DL_{U^\star}.\PROVE(x)$. Since also $i\in \Pi_V(DL_{U^\star})$, by \textbf{PROVE Validity} of $\DL$ the induced $DL_{U^\star}.\PROVE(x)$ is valid. Therefore, there exists a component with a valid $\PROVE(x)$, so $op$ is valid.
+    \end{itemize}
+
+    \smallskip
+    Combining the cases yields the claimed characterization of invalidity.
+\end{proof}
+
+\begin{lemma}[BFT-PROVE Anti-Flickering]
+    If the invocation of a operation $op = \BFTPROVE(x)$ by a correct process $p \in \Pi_V$ is invalid, then any $\BFTPROVE(x)$ operation that appears after $op$ in $\Seq$ is invalid.
+\end{lemma}
+
+\begin{proof}
+    Let $op=\BFTPROVE(x)$ be an invocation by a correct process $p_i$ that is \emph{invalid} in $\Seq$.
+    By BFT-PROVE Validity, this implies that there exist at least $t+1$ \emph{distinct} processes in $M$ that invoked a \emph{valid} $\BFTAPPEND(x)$ before $op$ in $\Seq$. Let $A\subseteq M$ denote that set, with $|A|\ge t+1$.
+
+    Fix any $U\in\mathcal{U}$. We have $A\cap U\neq\emptyset$. Pick $j\in A\cap U$. Since $j\in U$, the call $\BFTAPPEND_j(x)$ triggers a call $DL_U.\APPEND(x)$. Moreover, because $\BFTAPPEND_j(x)\prec op$ in $\Seq$, the induced $DL_U.\APPEND(x)$ appears before the induced $DL_U.\PROVE(x)$ of $op$ in the projection $\Seq_U$.
+
+    Hence, in $\Seq_U$, there exists a \emph{valid} $DL_U.\APPEND(x)$ that appears before the $DL_U.\PROVE(x)$ induced by $op$. By \textbf{PROVE Validity} the base $\DL$ object, the induced $DL_U.\PROVE(x)$ is therefore \emph{invalid} in $\Seq_U$.
+
+    Let $op'=\BFTPROVE(x)$ be any invocation such that $op\prec op'$ in $\Seq$. Fix again any $U\in\mathcal{U}$. Hence, the $DL_U.\PROVE(x)$ induced by $op'$ appears after the $DL_U.\PROVE(x)$ induced by $op$ in $\Seq_U$. Since the induced $DL_U.\PROVE(x)$ of $op$ is invalid, by \textbf{PROVE Anti-Flickering} of $\DL$, \emph{every} subsequent $DL_U.\PROVE(x)$ in $\Seq_U$ is invalid.
+
+    As this holds for every $U\in\mathcal{U}$, there is no component $DL_U$ in which the induced $\PROVE(x)$ of $op'$ is valid.
+\end{proof}
+
+\begin{lemma}[BFT-READ Liveness]
+    Let $op = \BFTREAD()$ invoke by a correct process such that $R$ is the result of $op$. For all $(i, x) \in R$ there exist a valid invocation of $\BFTPROVE(x)$ by $p_i$.
+\end{lemma}
+
+\begin{proof}
+    Let $R$ the result of a $READ()$ operation submit by any correct process. $(i, \PROVEtrace(x)) \in R$ implie that $\exists U^\star \in \mathcal{U}$ such that $(i, x) \in R^{U^\star}$ with $R^{U^\star}$ the result of $DL_{U^\star}.\READ()$. By \textbf{READ Validity} $(i, x) \in R^{U^\star}$ implie that there exist a valid  $DL_{U^\star}.\PROVE_i(x)$. The for loop in the $\BFTPROVE(x)$ implementation return true iff there at least one valid $DL_{U}.\PROVE_i(x)$ for any $U \in \mathcal{U}$.
+
+    Hence because there exist a $U^\star$ such that $DL_{U^\star}.\PROVE_i(x)$, there exist a valid $\BFTPROVE_i(x)$.
+
+     $(i, x) \in R \implies \exists \BFTPROVE_i(x)$
+\end{proof}
+
+\begin{lemma}[BFT-READ Anti-Flickering]
+    Let $op_1, op_2$ two $\BFTREAD()$ operations that returns respectively $R_1, R_2$. Iff $op_1 \prec op_2$ then $R_2 \subseteq R_1$. Otherwise $R_1 \subseteq R_2$.
+\end{lemma}
+
+\begin{proof}
+    Let $R_1, R_2$ respectively the output of two $\BFTREAD()$ operations $op_1, op_2$ such that $op_1 \prec op_2$.
+    By the implementation of $\BFTREAD$, $R_k = \bigcup_{U \in \mathcal{U}} R_k^U$ where $R_k^U$ is the result of $DL_U.\READ()$ during $op_k$.
+
+    Because $op_1 \prec op_2$ for any $U \in \mathcal{U}$, the $DL_U.\READ()$ induced by $op_1$ happen before the $DL_U.\READ()$ induced by $op_2$. Hence we have for all $U, R_2^U \subseteq R_1^U$.
+    Therefore
+    \[
+    \bigcup_U R_2^U \subseteq \bigcup_U R_1^U \implies
+    R_2 \subseteq R_1
+    \]
+\end{proof}
+
+\begin{lemma}[BFT-READ Safety]\label{lem:bft-read-safety}
+    Let $op_1, op_2$ respectively a valid $\BFTPROVE(x)$ operation submited by the process $p_i$ and a $\BFTREAD()$ operation submited by any correct process such that $op_1 \prec op_2$. Let $R$ the result of $op_2$ then $R \ni (i, x)$
+\end{lemma}
+
+\begin{proof}
+    Let $op_1 = \BFTPROVE_i(x)$ be a valid operation by a correct process $p_i$ and $op_2 = \BFTREAD()$ be any $\BFTREAD()$ operation such that $op_1 \prec op_2$ in $\Seq$.
+    By BFT-PROVE Validity, there exist at most $t$ distinct processes in $M$ that invoked a valid $\BFTAPPEND(x)$ before $op_1$ in $\Seq$. Let $A\subseteq M$ denote that set, with $|A|\le t$.
+
+    There exists $U^\star\in\mathcal{U}$ such that $A\cap U^\star=\emptyset$. For any $j\in A$, we have $j\notin U^\star$, so $\BFTAPPEND^{(j)}(x)$ does \emph{not} call $DL_{U^\star}.\APPEND(x)$. Hence no valid $DL_{U^\star}.\APPEND(x)$ appears before the induced $DL_{U^\star}.\PROVE(x)$ of $op_1$. Since also $i\in \Pi_V(DL_{U^\star})$, by \textbf{PROVE Validity} of $\DL$ the induced $DL_{U^\star}.\PROVE_i(x)$ is valid.
+
+    Now, because $op_1 \prec op_2$ in $\Seq$, the induced $DL_{U^\star}.\PROVE_i(x)$ appears before the induced $DL_{U^\star}.\READ()$ of $op_2$ in $\Seq_{U^\star}$. By \textbf{READ Safety} of $\DL$, the result $R^{U^\star}$ of the induced $DL_{U^\star}.\READ()$ contains $(i, x)$.
+
+    Finally, by the implementation of $\BFTREAD()$, we have $R = \bigcup_{U \in \mathcal{U}} R^U$, so $(i, x) \in R$.
+\end{proof}
+
+\begin{theorem}
+    For any fixed value $t$ such that $3t < |M|$, multiple DenyList Object can be used to implement a t-Byzantine Fault Tolerant DenyList Object.
+\end{theorem}
+
+\begin{proof}
+    Follows directly from the previous lemmas.
+\end{proof}
+
+\subsection{Algorithm}
+
+\subsubsection{Variables}
+Each process $p_i$ maintains the following local variables:
+\LinesNotNumbered
+\begin{algorithm}
+    $\texttt{last\_commited} \gets 0$\;
+    $\texttt{last\_delivered} \gets 0$\;
+    $\received \gets \emptyset$\;
+    $\delivered \gets \emptyset$\;
+    $\prop[r][j] \gets \bot, \forall r, j$\;
+    $W[r] \gets \bot, \forall r$; this is the set of the winners for the round $r$\\
+    $B[r] \gets \bot, \forall r$; this is the set of processes who have bahaved maliciously for round $r$\\
+    $\resolved[r] \gets \bot, \forall r$\;
+    $Y$ a $\BFTDL$ such that the value space is $\mathcal{R} \times \Pi$\;
+    $V$ a $\BFTDL$ such that the value space is $(\mathcal{R} \times \mathcal{M} \times \Pi)$\;
+\end{algorithm}
+
+\LinesNumbered
+\begin{algorithm}[H]
+    \caption{$\ABbroadcast(m)$ at process $p_i$}\label{alg:broadcast-bft}
+    \SetAlgoLined
+    \Fn{ABroadcast($m$)}{
+        $\received \gets \received \cup \{m\}$\;
+        Propose()\;
+    }
+\end{algorithm}
+
+
+\begin{algorithm}[H]
+    \caption{Propose($\bot$) at process $p_i$}\label{alg:propose-bft}
+    \SetAlgoLined
+    % \Statex \textbf{Proposer Job}
+    \Fn{Propose($\bot$)}{
+        $r \gets \texttt{last\_commited}$\;
+        \While{$S \neq \emptyset$ with $S \gets \received \setminus (\delivered \cup (\bigcup_{r' < r} \bigcup_{\substack{(j,S')\in W[r']\\ j\notin B[r']\\ S' \in \prop[r'][j]}} S'))$}{
+            % \Comment{PROP PHASE}\;
+            \tcc*[f]{PROP PHASE}\\
+            $V.\BFTPROVE((r, S, i))$\;
+            $\RBcast(i, \texttt{PROP}, S, r)$\;
+            \textbf{wait} until $|\{j: \exists S, |\{k: (k,(r, S, j)) \in V.\BFTREAD()\}| \geq t+1\}| \geq n - t$\;
+            % \Comment{COMMIT PHASE}
+            \tcc*[f]{COMMIT PHASE}\\
+            \For{\textbf{each} $j \in \Pi$}{
+                % $Y[j].\BFTAPPEND(r)$\;
+                $V.\BFTAPPEND((r, S, j))$\;
+                $Y.\BFTAPPEND((r, j))$\;
+            }
+            $\RBcast(i, \texttt{COMMIT}, r)$\;
+            \textbf{wait} until $|\resolved[r]| \geq n - t$\;
+            % \Comment*{X PHASE}
+            % \tcc*[f]{X PHASE}\\
+            \BlankLine
+            $W[r] \gets \{(j, S): |\{k: (k, (r, S, j)) \in V.\BFTREAD()\}| \geq t+1\}$\;
+            $B[r] \gets \{j: |\{k: (k, (r, j)) \in Y.\BFTREAD()\}| \geq t+1\}$\;
+            $r \gets r + 1$\;
+        }
+        $\texttt{last\_commited} \gets r$\;
+    }
+\end{algorithm}
+
+\begin{algorithm}[H]
+    \caption{$\ABdeliver()$ at process $p_i$}\label{alg:deliver-bft}
+    \SetAlgoLined
+    \Fn{ADeliver($\bot$)}{
+        $r \gets \texttt{last\_delivered}$\;
+        \If{$|\resolved[r]| < n - t$}{
+            \Return{$\bot$}
+        }
+        $W \gets \{(j, S): |\{k: (k, (r, S, j)) \in V.\BFTREAD()\}| \geq t+1\}$\;
+        $B \gets \{j: |\{k: (k, (r, j)) \in Y.\BFTREAD()\}| \geq t+1\}$\;
+
+        \If{$\exists (j, S) \in W, j \notin B, S \notin \prop[r][j]$}{
+            \Return{$\bot$}
+        }
+        \BlankLine
+        $M \gets \bigcup_{\substack{(j,S)\in W\\ j\notin B\\ S \in prop[r][j]}} S$\;\nllabel{code:Mcompute}
+        $m \gets \ordered(M \setminus \delivered)[0]$\;
+        % \Comment*{Set $m$ as the smaller message not already delivered}
+        $\delivered \leftarrow \delivered \cup \{m\}$\;
+        \If{$M \setminus \delivered = \emptyset$}{
+            $\texttt{last\_delivered} \gets \texttt{last\_delivered} + 1$\;
+        }
+        % \Comment*{Check if all messages from round $r$ have been delivered}
+        \Return{$m$}
+    }
+\end{algorithm}
+
+\begin{algorithm}[H]
+    \caption{RB handler at process $p_i$}\label{alg:rb-handler-bft}
+    \SetAlgoLined
+    \Upon{$Rdeliver(j, \texttt{PROP}, S, r)$}{
+        $\received \gets \received \cup \{S\}$\;
+        \uIf{$\prop[r][j] = \bot \vee (\{S' : (j, (r, S', j)) \in V.\BFTREAD()\} = \{S\})$}{
+            $V.\BFTPROVE((r, S, j))$\;
+        }
+        \Else{
+            $Y.\BFTPROVE((r, j))$\;
+        }
+        $\prop[r][j] \gets \prop[r][j] \cup S$\;
+        Propose()\;
+    }
+
+    \vspace{1em}
+
+    \Upon{$Rdeliver(j, \texttt{COMMIT}, r)$}{
+        $\resolved[r] \gets \resolved[r] \cup \{j\}$\;
+    }
+\end{algorithm}
+
+\textbf{Everything below has to be updated}
+
+\begin{definition}[BFT Closed round for $k$]
+    Given $Seq^{k}$ the linearization of the $\BFTDL$ $Y[k]$, a round $r \in \mathcal{R}$ is \emph{closed} in $\Seq$ iff there exist at least $n - f$ distinct processes $j \in \Pi$ such that $\BFTAPPEND_j(r)$ appears in $\Seq^k$. Let call $\BFTAPPEND(r)^\star$ the $(n-f)^{th}$ $\BFTAPPEND(r)$.
+\end{definition}
+
+\begin{definition}[BFT Closed round]\label{def:bft-closed-round}
+    A round $r \in \mathcal{R}$ is \emph{closed} iff for all $\DL[k]$, $r$ is closed in $\Seq^k$.
+\end{definition}
+
+\subsection{Proof of correctness}
+
+\begin{remark}[BFT Stable round closure]\label{rem:bft-stable-round-closure}
+    If a round $r$ is closed, no more $\BFTPROVE(r)$ can be valid and thus linearized. In other words, once $\BFTAPPEND(r)^\star$ is linearized, no more process can make a proof on round $r$, and the set of valid proofs for round $r$ is fixed. Therefore $\Winners_r$ is fixed.
+\end{remark}
+
+\begin{proof}
+    By definition $r$ closed means that for all process $p_i$, there exist at least $n - f$ distinct processes $j \in \Pi$ such that $\BFTAPPEND_j(r)$ appears in $\Seq^k$. By BFT-PROVE Validity, any subsequent $\BFTPROVE(r)$ is invalid because at least $n - f$ processes already invoked a valid $\BFTAPPEND(r)$ before it. Thus no new valid $\BFTPROVE(r)$ can be linearized after $\BFTAPPEND(r)^\star$. Hence the set of valid proofs for round $r$ is fixed, and so is $\Winners_r$.
+\end{proof}
+
+\begin{lemma}[BFT Across rounds]\label{lem:bft-across-rounds}
+    For any $r, r'$ such that $r < r'$, if $r'$ is closed, $r$ is also closed.
+\end{lemma}
+
+\begin{proof}
+    Let $r \in \mathcal{R}$. By \cref{def:bft-closed-round}, if $r + 1$ is closed, then for all $\DL[k]$, $r + 1$ is closed in $\Seq^k$. By the implementation, a process can only invoke $\BFTAPPEND(r + 1)$ after observing at least $n - f$ valid $\BFTPROVE(r)$, which means that for all $\DL[k]$, $r$ is closed in $\Seq^k$. Hence by \cref{def:bft-closed-round}, $r$ is closed.
+
+    Because $r$ is monotonically increasing, we can reccursively apply the same argument to conclude that for any $r, r'$ such that $r < r'$, if $r'$ is closed, $r$ is also closed.
+\end{proof}
+
+\begin{lemma}[BFT Progress]\label{lem:bft_progress}
+    For any correct process $p_i$ such that
+    \[
+    \received \setminus (\delivered \cup (\cup_{r' < r} \cup_{j \in W[r'] \prop[r'][j]})) \neq \emptyset
+    \]
+    with $r$ the highest closed round in the $\DL$ linearization. Eventually $r+1$ will be closed.
+\end{lemma}
+
+\begin{lemma}[BFT Winners invariant]\label{lem:bft-winners-invariant}
+    For any closed round $r$, define
+    \[
+    \Winners_r = \{j: \BFTPROVE_j(r) \prec \BFTAPPEND^\star(r)\}
+    \]
+    called the unique set of winners of round $r$.
+\end{lemma}
+
+\begin{lemma}[BFT n-f lower-bounded Winners]
+    Let $r$ a closed round, $|W[r]| \geq n-f$.
+\end{lemma}
+
+\begin{remark}\label{rem:correct-in-winners}
+    Because we assume $n \geq 2f+ 1$, if $|W[r]| \geq n-f$ at least 1 correct have to be in $W[r]$ to progress.
+\end{remark}
+
+\begin{lemma}[BFT Winners must purpose]\label{lem:bft-winners-purpose}
+    Let $r$ a closed round, for all process $p_j$ such that $j \in W[r]$, $p_j$ must have executed $\RBcast(j, PROP, \_, r)$ and hence any correct will eventually set $\prop[r][j]$ to a non-$\bot$ value.
+\end{lemma}
+
+\begin{lemma}[BFT Messages Incariant]\label{lem:bft-messages-invariant}
+    For any closed round $r$ and any correct process $p_i$ such that $\forall j \in \Winners_r$: $\prop^{(i)}[r][j] \neq \bot$ define
+    \[
+        \Messages_r = \cup_{j \in \Winners_r} prop^{(i)}[r][j]
+    \]
+    as the set of messages proposed by the winners of round $r$
+\end{lemma}
+
+\begin{lemma}[BFT EVentual proposal closure]\label{lem:bft-eventual-proposal-closure}
+    If a correct process $p_i$ define $M$ at line~\ref{code:Mcompute}, then for every $j \in \Winners_r$, $\prop^{(i)}[r][j] \neq \bot$.
+\end{lemma}
+
+\begin{lemma}[BFT Unique proposal per sender per round]\label{lem:bft-unique-proposal}
+    For any round $r$ and any process $p_i$, if $p_i$ invokes two $\RBcast$ call for the same round, such that $\RBcast(i, PROP, S, r) \prec \RBcast(i, PROP, S', r)$. Then for any correct process $p_j$, $\prop^{(j)}[r][i] \in \{\bot, S\}$
+\end{lemma}
+
+
+
+
+
+
+
+% \begin{lemma}[BFT $W_r$ as grow only set]\label{lem:bft-wr-grow-only}
+%     For any correct process $p_i$. If $p_i$ computes $W_r$ at two different times $t_1$ and $t_2$ with $t_1 < t_2$, then $W_r^{t_1} \subseteq W_r^{t_2}$.
+% \end{lemma}
+
+% \begin{proof}
+%     By the implementation, $W_r$ is computed exclusively from the results of $\{j: (j, \PROVEtrace(r)) \in \bigcup_{k \in \Pi} Y[k].\BFTREAD()\}$.
+
+%     We know by BFT-READ Anti-Flickering that for any two $\BFTREAD()$ operations $op_1, op_2$ such that $op_1 \prec op_2$, the result of $op_2$ is included in the result of $op_1$. Therefore, if $p_i$ computes $W_r$ at two different times $t_1$ and $t_2$ with $t_1 < t_2$, then $W_r^{t_1} \subseteq W_r^{t_2}$.
+% \end{proof}
+
+% \begin{lemma}[BFT well defined winners]\label{lem:bft-well-defined-winners}
+%     For any closed round $r$, if a correct process $p_i$ compute $W_r$, then $W_r = \Winners_r$ with $|W_r| \geq n - f$.
+% \end{lemma}
+
+% \begin{proof}
+%     By \Cref{lem:bft-read-safety}, any correct process $p_i$ computing $W_r$ after round $r$ is closed includes all valid $\BFTPROVE(r)$ in its computation of $W_r$. Therefore $W_r = \Winners_r$.
+
+%     By \Cref{def:bft-closed-round}, at least $n - f$ distinct processes invoked a valid $\BFTAPPEND(r)$ before $\BFTAPPEND(r)^\star$. By the implementation in algorithm D, if a process correct $j$ invoked a valid $\BFTAPPEND(r)$, thats means that he observed at least $n - f$ valid $\BFTPROVE(r)$ submitted by distinct processes. By \Cref{lem:bft-wr-grow-only}, once $p_j$ observed $n - f$ valid $\BFTPROVE(r)$, any correct process computing $W_r$ will eventually observe at least these $n - f$ valid $\BFTPROVE(r)$. By \Cref{lem:bft-stable-round-closure}, no more valid $\BFTPROVE(r)$ can be linearized after round $r$ is closed, so any correct process computing the same fixed set $W_r$ of at least $n - f$ distinct processes.
+% \end{proof}
+
+% \begin{lemma}[BFT Non-empty winners proposal]\label{lem:bft-non-empty-winners-proposal}
+%     For every process $p_i$ such as $i \in W_r$, eventually $\prop[r][i] \neq \bot$.
+% \end{lemma}
+
+% \begin{proof}
+%     By the implementation, if $i \in W_r$, then $(i, \PROVEtrace(r))$ is included in the result of at least one $\BFTREAD()$ operation. Hence there exist a valid $\BFTPROVE(r)$ operation.
+%     By \Cref{lem:bft-prove-validity}, this implies that there exist at least $f + 1$ valid $\PROVE(r)$ operation invoked by processes. At least one of these processes is correct, say $p_j$. By the implementation, $p_j$ invoked $\BFTPROVE(r)$ after receiving a $Rdeliver(j, \texttt{PROP}, S, r)$ message from $p_i$. Therefore, by the reliable broadcast properties, the message will eventually be delivered to every correct process, hence eventually for any correct process $\prop[r][i] \neq \bot$.
+% \end{proof}
+
+% \begin{definition}[BFT Message invariant]\label{def:bft-message-invariant}
+%     For any closed round $r$, for any correct process $p_i$, such that $\nexists j \in W_r : \prop[r][j] = \bot$, twe define the set
+%     \[
+%     \Messages_r = \bigcup_{j \in \Winners_r} \prop[r][j]
+%     \]
+%     as the unique set of messages proposed during round $r$.
+% \end{definition}
+
+% \begin{lemma}[BFT Proposal convergence]\label{lem:bft-proposal-convergence}
+%     For any closed round $r$, for any correct process $p_i$, that define $M_r$ at line B10, we have $M_r = \Messages_r$.
+% \end{lemma}
+
+% \begin{proof}
+%     By \Cref{lem:bft-well-defined-winners}, any correct process $p_i$ computing $W_r$ after round $r$ is closed has $W_r = \Winners_r$.
+%     By \Cref{lem:bft-non-empty-winners-proposal}, for any correct process $p_i$, such as $i \in W_r$, eventually $\prop[r][i] \neq \bot$.
+
+%     Therefore, eventually for any correct process $p_i$, at line B10 we have
+%     \[
+%     M_r = \bigcup_{j \in W_r} \prop[r][j] = \bigcup_{j \in \Winners_r} \prop[r][j] = \Messages_r
+%     \]
+% \end{proof}
+
+% \begin{lemma}[BFT Inclusion]\label{proof:bft-inclusion}
+%     If a correct process $p_i$ ABroadcasts a message $m$, then eventually any correct process $p_j$ ADelivers $m$.
+% \end{lemma}
+
+% \begin{proof}
+%     Let $m$ be a message ABroadcast by a correct process $p_i$ and eventually exit the \texttt{ABroadcast} function at line A10.
+
+%     By the implementation, if $p_i$ exits the \texttt{ABroadcast} function at line A10, then there exists a round $r'$ such that $m \in \prop[r'][j]$ for some $j \in W_{r'}$.
+
+%     Since $p_i$ is correct, seeing that $m \in \prop[r'][j]$ for some $j \in W_{r'}$ implies that $p_i$ received a $Rdeliver(j, \texttt{PROP}, S, r')$ message from $p_j$ such that $m \in S$. And because $p_j$ is in $W_{r'}$, at least $n - f$ correct processes invoked a valid $Y[j].\BFTPROVE(r')$ before the round $r'$ were closed. By the reliable broadcast properties, the $Rdeliver(j, \texttt{PROP}, S, r')$ message will eventually be delivered to every correct process, hence eventually for any correct process $m \in \prop[r'][j]$ with $j \in W_{r'}$. Hence $m$ will eventually be included in the set $\Messages_{r'}$ defined in \Cref{def:bft-message-invariant} and thus eventually be ADelivered by any correct process.
+% \end{proof}
+
+\begin{theorem}
+    The algorithm implements a BFT Atomic Reliable Broadcast.
+\end{theorem}

Recherche/BFT-ARBover/diagrams/BFT_behaviour.puml

@@ -0,0 +1,54 @@
+@startuml
+!pragma teoz true
+
+database DL
+actor P1
+actor P2
+P1 -> DL : <latex>READ()</latex>
+DL --> P1 : <latex>P</latex>
+P1 -> P1 : <latex>r_{max} = max\{r : (\_, prove(r)) \in P\}</latex>
+
+loop <latex>\textbf{foreach } r \in \{r_{max} + 1, \dots\}</latex>
+
+    ' P1 ->(05) P2 : <latex>RBcast(prop, S, r, 1)</latex>
+
+    P1 -> DL : <latex>PROVE(r)</latex>
+    P1 -> DL : <latex>APPEND(r)</latex>
+
+    P1 -> DL : <latex>READ()</latex>
+    DL --> P1 : <latex>P</latex>
+
+    alt <latex>(1, \text{prove(}r\text{)}) \in P</latex>
+        note over P1 : break
+    end
+end
+
+P2 -> P2 : <latex>ABdeliver()</latex>
+P2 -> DL : <latex>READ()</latex>
+DL --> P2 : <latex>P</latex>
+note over P2
+    line(C4)
+    process P2 check locally if 
+    <latex>\forall j : (j, prove(r)) \not\in P</latex>
+    which is false since P1 correctly 
+    PROVE(r) and APPEND(r)
+
+    <latex>\text{P1 is next include in } W_r</latex>
+end note
+
+P2 -> DL : <latex>APPEND(r)</latex>
+P2 -> DL : <latex>READ()</latex>
+DL --> P2 : <latex>P</latex>
+
+note over P2
+    line(C9)
+    process P2 check locally if
+    <latex>\forall j \in W_r : prop[r][j] = \bot</latex>
+    which can't be false since P1 didn't
+    execute <latex>RBcast(prop, S, r, 1)</latex>
+
+    P2 will never progress and
+    deliver any futur messages
+end note
+hide footbox
+@enduml

Recherche/BFT-ARBover/diagrams/BFT_behaviour.tex

@@ -0,0 +1,113 @@
+% generated by Plantuml 1.2025.10      
+\definecolor{plantucolor0000}{RGB}{255,255,255}
+\definecolor{plantucolor0001}{RGB}{24,24,24}
+\definecolor{plantucolor0002}{RGB}{0,0,0}
+\definecolor{plantucolor0003}{RGB}{226,226,240}
+\definecolor{plantucolor0004}{RGB}{238,238,238}
+\definecolor{plantucolor0005}{RGB}{254,255,221}
+\begin{tikzpicture}[yscale=-1
+,pstyle0/.style={color=plantucolor0000,line width=0.0pt}
+,pstyle1/.style={color=plantucolor0001,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
+,pstyle2/.style={color=plantucolor0001,fill=plantucolor0003,line width=0.5pt}
+,pstyle3/.style={color=plantucolor0001,line width=0.5pt}
+,pstyle4/.style={color=plantucolor0001,fill=plantucolor0001,line width=1.0pt}
+,pstyle5/.style={color=plantucolor0001,line width=1.0pt}
+,pstyle6/.style={color=plantucolor0001,line width=1.0pt,dash pattern=on 2.0pt off 2.0pt}
+,pstyle7/.style={color=black,fill=plantucolor0004,line width=1.5pt}
+,pstyle8/.style={color=black,line width=1.5pt}
+,pstyle9/.style={color=plantucolor0001,fill=plantucolor0005,line width=0.5pt}
+]
+\draw[pstyle0] (20.5pt,75pt) rectangle (28.5pt,722.6982pt);
+\draw[pstyle1] (24pt,75pt) -- (24pt,722.6982pt);
+\draw[pstyle0] (105.8255pt,75pt) rectangle (113.8255pt,722.6982pt);
+\draw[pstyle1] (109.3255pt,75pt) -- (109.3255pt,722.6982pt);
+\draw[pstyle0] (273.8933pt,75pt) rectangle (281.8933pt,722.6982pt);
+\draw[pstyle1] (277.3933pt,75pt) -- (277.3933pt,722.6982pt);
+\node at (14.055pt,65pt)[below right,color=black,inner sep=0]{DL};
+\draw[pstyle2] (6pt,29pt) ..controls (6pt,19pt) and (24pt,19pt) .. (24pt,19pt) ..controls (24pt,19pt) and (42pt,19pt) .. (42pt,29pt) -- (42pt,55pt) ..controls (42pt,65pt) and (24pt,65pt) .. (24pt,65pt) ..controls (24pt,65pt) and (6pt,65pt) .. (6pt,55pt) -- (6pt,29pt);
+\draw[pstyle3] (6pt,29pt) ..controls (6pt,39pt) and (24pt,39pt) .. (24pt,39pt) ..controls (24pt,39pt) and (42pt,39pt) .. (42pt,29pt);
+\node at (100.4205pt,65pt)[below right,color=black,inner sep=0]{P1};
+\draw[pstyle2] (109.3255pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle3] (109.3255pt,21.5pt) -- (109.3255pt,48.5pt)(96.3255pt,29.5pt) -- (122.3255pt,29.5pt)(109.3255pt,48.5pt) -- (96.3255pt,63.5pt)(109.3255pt,48.5pt) -- (122.3255pt,63.5pt);
+\node at (268.4883pt,65pt)[below right,color=black,inner sep=0]{P2};
+\draw[pstyle2] (277.3933pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle3] (277.3933pt,21.5pt) -- (277.3933pt,48.5pt)(264.3933pt,29.5pt) -- (290.3933pt,29.5pt)(277.3933pt,48.5pt) -- (264.3933pt,63.5pt)(277.3933pt,48.5pt) -- (290.3933pt,63.5pt);
+\draw[pstyle4] (35pt,95pt) -- (25pt,99pt) -- (35pt,103pt) -- (31pt,99pt) -- cycle;
+\draw[pstyle5] (29pt,99pt) -- (108.3255pt,99pt);
+\node at (41pt,87pt)[below right,inner sep=0]{$READ()$};
+\draw[pstyle4] (97.3255pt,115.8333pt) -- (107.3255pt,119.8333pt) -- (97.3255pt,123.8333pt) -- (101.3255pt,119.8333pt) -- cycle;
+\draw[pstyle6] (24pt,119.8333pt) -- (103.3255pt,119.8333pt);
+\node at (31pt,111pt)[below right,inner sep=0]{$P$};
+\draw[pstyle5] (109.3255pt,143.8333pt) -- (151.3255pt,143.8333pt);
+\draw[pstyle5] (151.3255pt,143.8333pt) -- (151.3255pt,156.8333pt);
+\draw[pstyle5] (110.3255pt,156.8333pt) -- (151.3255pt,156.8333pt);
+\draw[pstyle4] (120.3255pt,152.8333pt) -- (110.3255pt,156.8333pt) -- (120.3255pt,160.8333pt) -- (116.3255pt,156.8333pt) -- cycle;
+\node at (116.3255pt,131.8333pt)[below right,inner sep=0]{$r_{max} = max\{r : (\_, prove(r)) \in P\}$};
+\draw[pstyle7] (8pt,168.8333pt) -- (74.4pt,168.8333pt) -- (74.4pt,170.8333pt) -- (64.4pt,180.8333pt) -- (8pt,180.8333pt) -- (8pt,168.8333pt);
+\draw[pstyle8] (8pt,168.8333pt) rectangle (259.8182pt,353.6666pt);
+\node at (23pt,169.8333pt)[below right,color=black,inner sep=0]{\textbf{loop}};
+\node at (89.4pt,172.0833pt)[below right,color=black,inner sep=0]{\textbf{[}};
+\node at (92.59pt,170.8333pt)[below right,inner sep=0]{$\textbf{foreach } r \in \{r_{max} + 1, \dots\}$};
+\node at (215.4514pt,172.0833pt)[below right,color=black,inner sep=0]{\textbf{]}};
+\draw[pstyle4] (35pt,202.8333pt) -- (25pt,206.8333pt) -- (35pt,210.8333pt) -- (31pt,206.8333pt) -- cycle;
+\draw[pstyle5] (29pt,206.8333pt) -- (108.3255pt,206.8333pt);
+\node at (41pt,194.8333pt)[below right,inner sep=0]{$PROVE(r)$};
+\draw[pstyle4] (35pt,226.8333pt) -- (25pt,230.8333pt) -- (35pt,234.8333pt) -- (31pt,230.8333pt) -- cycle;
+\draw[pstyle5] (29pt,230.8333pt) -- (108.3255pt,230.8333pt);
+\node at (41pt,218.8333pt)[below right,inner sep=0]{$APPEND(r)$};
+\draw[pstyle4] (35pt,250.8333pt) -- (25pt,254.8333pt) -- (35pt,258.8333pt) -- (31pt,254.8333pt) -- cycle;
+\draw[pstyle5] (29pt,254.8333pt) -- (108.3255pt,254.8333pt);
+\node at (41pt,242.8333pt)[below right,inner sep=0]{$READ()$};
+\draw[pstyle4] (97.3255pt,271.6666pt) -- (107.3255pt,275.6666pt) -- (97.3255pt,279.6666pt) -- (101.3255pt,275.6666pt) -- cycle;
+\draw[pstyle6] (24pt,275.6666pt) -- (103.3255pt,275.6666pt);
+\node at (31pt,266.8333pt)[below right,inner sep=0]{$P$};
+\draw[pstyle7] (65.7255pt,287.6666pt) -- (123.9755pt,287.6666pt) -- (123.9755pt,289.6666pt) -- (113.9755pt,299.6666pt) -- (65.7255pt,299.6666pt) -- (65.7255pt,287.6666pt);
+\draw[pstyle8] (65.7255pt,287.6666pt) rectangle (234.8182pt,339.6666pt);
+\node at (80.7255pt,288.6666pt)[below right,color=black,inner sep=0]{\textbf{alt}};
+\node at (138.9755pt,290.9166pt)[below right,color=black,inner sep=0]{\textbf{[}};
+\node at (142.1655pt,289.6666pt)[below right,inner sep=0]{$(1, \text{prove(}r\text{)}) \in P$};
+\node at (215.6282pt,290.9166pt)[below right,color=black,inner sep=0]{\textbf{]}};
+\draw[pstyle9] (86.7255pt,314.6666pt) -- (86.7255pt,334.6666pt) -- (131.7255pt,334.6666pt) -- (131.7255pt,324.6666pt) -- (121.7255pt,314.6666pt) -- (86.7255pt,314.6666pt);
+\draw[pstyle9] (121.7255pt,314.6666pt) -- (121.7255pt,324.6666pt) -- (131.7255pt,324.6666pt) -- (121.7255pt,314.6666pt);
+\node at (92.7255pt,319.6666pt)[below right,color=black,inner sep=0]{break};
+\draw[pstyle5] (277.3933pt,383.6666pt) -- (319.3933pt,383.6666pt);
+\draw[pstyle5] (319.3933pt,383.6666pt) -- (319.3933pt,396.6666pt);
+\draw[pstyle5] (278.3933pt,396.6666pt) -- (319.3933pt,396.6666pt);
+\draw[pstyle4] (288.3933pt,392.6666pt) -- (278.3933pt,396.6666pt) -- (288.3933pt,400.6666pt) -- (284.3933pt,396.6666pt) -- cycle;
+\node at (284.3933pt,371.6666pt)[below right,inner sep=0]{$ABdeliver()$};
+\draw[pstyle4] (35pt,416.6666pt) -- (25pt,420.6666pt) -- (35pt,424.6666pt) -- (31pt,420.6666pt) -- cycle;
+\draw[pstyle5] (29pt,420.6666pt) -- (276.3933pt,420.6666pt);
+\node at (41pt,408.6666pt)[below right,inner sep=0]{$READ()$};
+\draw[pstyle4] (265.3933pt,437.4999pt) -- (275.3933pt,441.4999pt) -- (265.3933pt,445.4999pt) -- (269.3933pt,441.4999pt) -- cycle;
+\draw[pstyle6] (24pt,441.4999pt) -- (271.3933pt,441.4999pt);
+\node at (31pt,432.6666pt)[below right,inner sep=0]{$P$};
+\draw[pstyle9] (195.7533pt,454.4999pt) -- (195.7533pt,534.4999pt) -- (358.7533pt,534.4999pt) -- (358.7533pt,464.4999pt) -- (348.7533pt,454.4999pt) -- (195.7533pt,454.4999pt);
+\draw[pstyle9] (348.7533pt,454.4999pt) -- (348.7533pt,464.4999pt) -- (358.7533pt,464.4999pt) -- (348.7533pt,454.4999pt);
+\node at (201.7533pt,459.4999pt)[below right,color=black,inner sep=0]{line(C4)};
+\node at (201.7533pt,470.4999pt)[below right,color=black,inner sep=0]{process P2 check locally if~};
+\node at (201.7533pt,480.4999pt)[below right,inner sep=0]{$\forall j : (j, prove(r)) \not\in P$};
+\node at (201.7533pt,491.4999pt)[below right,color=black,inner sep=0]{which is false since P1 correctly~};
+\node at (201.7533pt,501.4999pt)[below right,color=black,inner sep=0]{PROVE(r) and APPEND(r)};
+\node at (201.7533pt,511.4999pt)[below right,color=black,inner sep=0]{~};
+\node at (201.7533pt,521.4999pt)[below right,inner sep=0]{$\text{P1 is next include in } W_r$};
+\draw[pstyle4] (35pt,551.9399pt) -- (25pt,555.9399pt) -- (35pt,559.9399pt) -- (31pt,555.9399pt) -- cycle;
+\draw[pstyle5] (29pt,555.9399pt) -- (276.3933pt,555.9399pt);
+\node at (41pt,543.9399pt)[below right,inner sep=0]{$APPEND(r)$};
+\draw[pstyle4] (35pt,575.9399pt) -- (25pt,579.9399pt) -- (35pt,583.9399pt) -- (31pt,579.9399pt) -- cycle;
+\draw[pstyle5] (29pt,579.9399pt) -- (276.3933pt,579.9399pt);
+\node at (41pt,567.9399pt)[below right,inner sep=0]{$READ()$};
+\draw[pstyle4] (265.3933pt,596.7732pt) -- (275.3933pt,600.7732pt) -- (265.3933pt,604.7732pt) -- (269.3933pt,600.7732pt) -- cycle;
+\draw[pstyle6] (24pt,600.7732pt) -- (271.3933pt,600.7732pt);
+\node at (31pt,591.9399pt)[below right,inner sep=0]{$P$};
+\draw[pstyle9] (189.1283pt,613.7732pt) -- (189.1283pt,706.7732pt) -- (365.1283pt,706.7732pt) -- (365.1283pt,623.7732pt) -- (355.1283pt,613.7732pt) -- (189.1283pt,613.7732pt);
+\draw[pstyle9] (355.1283pt,613.7732pt) -- (355.1283pt,623.7732pt) -- (365.1283pt,623.7732pt) -- (355.1283pt,613.7732pt);
+\node at (195.1283pt,618.7732pt)[below right,color=black,inner sep=0]{line(C9)};
+\node at (195.1283pt,629.7732pt)[below right,color=black,inner sep=0]{process P2 check locally if};
+\node at (195.1283pt,639.7732pt)[below right,inner sep=0]{$\forall j \in W_r : prop[r][j] = \bot$};
+\node at (195.1283pt,650.7732pt)[below right,color=black,inner sep=0]{which can't be false since P1 didn't};
+\node at (195.1283pt,662.6982pt)[below right,color=black,inner sep=0]{execute~};
+\node at (230.9483pt,660.7732pt)[below right,inner sep=0]{$RBcast(prop, S, r, 1)$};
+\node at (195.1283pt,672.6982pt)[below right,color=black,inner sep=0]{~};
+\node at (195.1283pt,682.6982pt)[below right,color=black,inner sep=0]{P2 will never progress and};
+\node at (195.1283pt,692.6982pt)[below right,color=black,inner sep=0]{deliver any futur messages};
+\end{tikzpicture}

Recherche/BFT-ARBover/diagrams/classic_seq.puml

@@ -0,0 +1,37 @@
+@startuml
+!pragma teoz true
+
+database DL
+actor P1
+actor P2
+actor Pt
+actor Pn
+
+P1 ->(05) P2: <latex>RBcast(prop, S, r, 1)</latex>
+& P1 ->(25) Pt : <latex>RBcast(prop, S, r, 1)</latex>
+& P1 ->(50) Pn : <latex>RBcast(prop, S, r, 1)</latex>
+P2 -> P2 : <latex>S'(sk_2, r)</latex>
+P2 -> P1 : <latex>send(\sigma_2)</latex>
+... <latex>\text{Wait until P1 received }\sigma \text{ t times}</latex> ...
+Pt -> Pt : <latex>S'(sk_t, r)</latex>
+Pt -> P1 : <latex>send(\sigma_t)</latex>
+
+P1 -> P1 : <latex>C'(pkc, r, J, \{\sigma_r^j\}_{j\in J})</latex>
+
+P1 -> DL : <latex>PROVE(\sigma)</latex>
+P1 -> DL : <latex>APPEND(\sigma)</latex>
+P2 -> Pt
+
+P1 ->(05) P2: <latex>RBcast(submit, S, r, 1, \sigma)</latex>
+& P1 ->(25) Pt : <latex>RBcast(submit, S, r, 1, \sigma)</latex>
+& P1 ->(50) Pn : <latex>RBcast(submit, S, r, 1, \sigma)</latex>
+
+P2 -> DL : <latex>P \gets READ()</latex>
+& Pt -> DL
+& Pn -> DL
+P2 -> P2 : <latex>V'(pk, r, \sigma)</latex>
+& Pt -> Pt : <latex>V'(pk, r, \sigma)</latex>
+& Pn -> Pn : <latex>V'(pk, r, \sigma)</latex>
+
+hide footbox
+@enduml

Recherche/BFT-ARBover/diagrams/classic_seq.tex

@@ -0,0 +1,127 @@
+% generated by Plantuml 1.2025.10      
+\definecolor{plantucolor0000}{RGB}{255,255,255}
+\definecolor{plantucolor0001}{RGB}{24,24,24}
+\definecolor{plantucolor0002}{RGB}{0,0,0}
+\definecolor{plantucolor0003}{RGB}{226,226,240}
+\begin{tikzpicture}[yscale=-1
+,pstyle0/.style={color=plantucolor0000,line width=0.0pt}
+,pstyle1/.style={color=plantucolor0001,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
+,pstyle2/.style={color=plantucolor0001,line width=0.5pt,dash pattern=on 1.0pt off 4.0pt}
+,pstyle3/.style={color=plantucolor0001,fill=plantucolor0003,line width=0.5pt}
+,pstyle4/.style={color=plantucolor0001,line width=0.5pt}
+,pstyle5/.style={color=plantucolor0001,fill=plantucolor0001,line width=1.0pt}
+,pstyle6/.style={color=plantucolor0001,line width=1.0pt}
+]
+\draw[pstyle0] (19.5pt,75pt) rectangle (27.5pt,218.0178pt);
+\draw[pstyle1] (23pt,75pt) -- (23pt,218.0178pt);
+\draw[pstyle2] (23pt,218.0178pt) -- (23pt,256.0178pt);
+\draw[pstyle0] (19.5pt,256.0178pt) rectangle (27.5pt,562.1754pt);
+\draw[pstyle1] (23pt,256.0178pt) -- (23pt,562.1754pt);
+\draw[pstyle0] (106.109pt,75pt) rectangle (114.109pt,218.0178pt);
+\draw[pstyle1] (109.609pt,75pt) -- (109.609pt,218.0178pt);
+\draw[pstyle2] (109.609pt,218.0178pt) -- (109.609pt,256.0178pt);
+\draw[pstyle0] (106.109pt,256.0178pt) rectangle (114.109pt,562.1754pt);
+\draw[pstyle1] (109.609pt,256.0178pt) -- (109.609pt,562.1754pt);
+\draw[pstyle0] (241.3331pt,75pt) rectangle (249.3331pt,218.0178pt);
+\draw[pstyle1] (244.8331pt,75pt) -- (244.8331pt,218.0178pt);
+\draw[pstyle2] (244.8331pt,218.0178pt) -- (244.8331pt,256.0178pt);
+\draw[pstyle0] (241.3331pt,256.0178pt) rectangle (249.3331pt,562.1754pt);
+\draw[pstyle1] (244.8331pt,256.0178pt) -- (244.8331pt,562.1754pt);
+\draw[pstyle0] (303.7197pt,75pt) rectangle (311.7197pt,218.0178pt);
+\draw[pstyle1] (307.2197pt,75pt) -- (307.2197pt,218.0178pt);
+\draw[pstyle2] (307.2197pt,218.0178pt) -- (307.2197pt,256.0178pt);
+\draw[pstyle0] (303.7197pt,256.0178pt) rectangle (311.7197pt,562.1754pt);
+\draw[pstyle1] (307.2197pt,256.0178pt) -- (307.2197pt,562.1754pt);
+\draw[pstyle0] (366.1062pt,75pt) rectangle (374.1062pt,218.0178pt);
+\draw[pstyle1] (369.6062pt,75pt) -- (369.6062pt,218.0178pt);
+\draw[pstyle2] (369.6062pt,218.0178pt) -- (369.6062pt,256.0178pt);
+\draw[pstyle0] (366.1062pt,256.0178pt) rectangle (374.1062pt,562.1754pt);
+\draw[pstyle1] (369.6062pt,256.0178pt) -- (369.6062pt,562.1754pt);
+\node at (13.055pt,65pt)[below right,color=black,inner sep=0]{DL};
+\draw[pstyle3] (5pt,29pt) ..controls (5pt,19pt) and (23pt,19pt) .. (23pt,19pt) ..controls (23pt,19pt) and (41pt,19pt) .. (41pt,29pt) -- (41pt,55pt) ..controls (41pt,65pt) and (23pt,65pt) .. (23pt,65pt) ..controls (23pt,65pt) and (5pt,65pt) .. (5pt,55pt) -- (5pt,29pt);
+\draw[pstyle4] (5pt,29pt) ..controls (5pt,39pt) and (23pt,39pt) .. (23pt,39pt) ..controls (23pt,39pt) and (41pt,39pt) .. (41pt,29pt);
+\node at (100.704pt,65pt)[below right,color=black,inner sep=0]{P1};
+\draw[pstyle3] (109.609pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle4] (109.609pt,21.5pt) -- (109.609pt,48.5pt)(96.609pt,29.5pt) -- (122.609pt,29.5pt)(109.609pt,48.5pt) -- (96.609pt,63.5pt)(109.609pt,48.5pt) -- (122.609pt,63.5pt);
+\node at (235.9281pt,65pt)[below right,color=black,inner sep=0]{P2};
+\draw[pstyle3] (244.8331pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle4] (244.8331pt,21.5pt) -- (244.8331pt,48.5pt)(231.8331pt,29.5pt) -- (257.8331pt,29.5pt)(244.8331pt,48.5pt) -- (231.8331pt,63.5pt)(244.8331pt,48.5pt) -- (257.8331pt,63.5pt);
+\node at (298.8697pt,65pt)[below right,color=black,inner sep=0]{Pt};
+\draw[pstyle3] (307.2197pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle4] (307.2197pt,21.5pt) -- (307.2197pt,48.5pt)(294.2197pt,29.5pt) -- (320.2197pt,29.5pt)(307.2197pt,48.5pt) -- (294.2197pt,63.5pt)(307.2197pt,48.5pt) -- (320.2197pt,63.5pt);
+\node at (360.4212pt,65pt)[below right,color=black,inner sep=0]{Pn};
+\draw[pstyle3] (369.6062pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle4] (369.6062pt,21.5pt) -- (369.6062pt,48.5pt)(356.6062pt,29.5pt) -- (382.6062pt,29.5pt)(369.6062pt,48.5pt) -- (356.6062pt,63.5pt)(369.6062pt,48.5pt) -- (382.6062pt,63.5pt);
+\draw[pstyle5] (232.9877pt,99.6332pt) -- (242.8331pt,104pt) -- (232.6921pt,107.6278pt) -- (236.8372pt,103.7783pt) -- cycle;
+\draw[pstyle6] (109.609pt,99pt) -- (242.8331pt,104pt);
+\node at (116.609pt,87pt)[below right,inner sep=0]{$RBcast(prop, S, r, 1)$};
+\draw[pstyle5] (295.8008pt,118.7765pt) -- (305.2197pt,124pt) -- (294.7967pt,126.7133pt) -- (299.2671pt,123.2469pt) -- cycle;
+\draw[pstyle6] (109.609pt,99pt) -- (305.2197pt,124pt);
+\node at (116.609pt,87pt)[below right,inner sep=0]{$RBcast(prop, S, r, 1)$};
+\draw[pstyle5] (358.5415pt,143.1835pt) -- (367.6062pt,149pt) -- (357.0307pt,151.0395pt) -- (361.7142pt,147.8669pt) -- cycle;
+\draw[pstyle6] (109.609pt,99pt) -- (367.6062pt,149pt);
+\node at (116.609pt,87pt)[below right,inner sep=0]{$RBcast(prop, S, r, 1)$};
+\draw[pstyle6] (244.8331pt,173.0178pt) -- (286.8331pt,173.0178pt);
+\draw[pstyle6] (286.8331pt,173.0178pt) -- (286.8331pt,186.0178pt);
+\draw[pstyle6] (245.8331pt,186.0178pt) -- (286.8331pt,186.0178pt);
+\draw[pstyle5] (255.8331pt,182.0178pt) -- (245.8331pt,186.0178pt) -- (255.8331pt,190.0178pt) -- (251.8331pt,186.0178pt) -- cycle;
+\node at (251.8331pt,161pt)[below right,inner sep=0]{$S'(sk_2, r)$};
+\draw[pstyle5] (120.609pt,206.0178pt) -- (110.609pt,210.0178pt) -- (120.609pt,214.0178pt) -- (116.609pt,210.0178pt) -- cycle;
+\draw[pstyle6] (114.609pt,210.0178pt) -- (243.8331pt,210.0178pt);
+\node at (126.609pt,198.0178pt)[below right,inner sep=0]{$send(\sigma_2)$};
+\node at (122.1916pt,232.0178pt)[below right,color=black,inner sep=0]{~};
+\node at (125.5216pt,234.8578pt)[below right,inner sep=0]{$\text{Wait until P1 received }\sigma \text{ t times}$};
+\node at (267.0846pt,232.0178pt)[below right,color=black,inner sep=0]{~};
+\draw[pstyle6] (307.2197pt,272.0356pt) -- (349.2197pt,272.0356pt);
+\draw[pstyle6] (349.2197pt,272.0356pt) -- (349.2197pt,285.0356pt);
+\draw[pstyle6] (308.2197pt,285.0356pt) -- (349.2197pt,285.0356pt);
+\draw[pstyle5] (318.2197pt,281.0356pt) -- (308.2197pt,285.0356pt) -- (318.2197pt,289.0356pt) -- (314.2197pt,285.0356pt) -- cycle;
+\node at (314.2197pt,260.0178pt)[below right,inner sep=0]{$S'(sk_t, r)$};
+\draw[pstyle5] (120.609pt,305.0356pt) -- (110.609pt,309.0356pt) -- (120.609pt,313.0356pt) -- (116.609pt,309.0356pt) -- cycle;
+\draw[pstyle6] (114.609pt,309.0356pt) -- (306.2197pt,309.0356pt);
+\node at (126.609pt,297.0356pt)[below right,inner sep=0]{$send(\sigma_t)$};
+\draw[pstyle6] (109.609pt,334.1576pt) -- (151.609pt,334.1576pt);
+\draw[pstyle6] (151.609pt,334.1576pt) -- (151.609pt,347.1576pt);
+\draw[pstyle6] (110.609pt,347.1576pt) -- (151.609pt,347.1576pt);
+\draw[pstyle5] (120.609pt,343.1576pt) -- (110.609pt,347.1576pt) -- (120.609pt,351.1576pt) -- (116.609pt,347.1576pt) -- cycle;
+\node at (116.609pt,321.0356pt)[below right,inner sep=0]{$C'(pkc, r, J, \{\sigma_r^j\}_{j\in J})$};
+\draw[pstyle5] (34pt,367.1576pt) -- (24pt,371.1576pt) -- (34pt,375.1576pt) -- (30pt,371.1576pt) -- cycle;
+\draw[pstyle6] (28pt,371.1576pt) -- (108.609pt,371.1576pt);
+\node at (40pt,359.1576pt)[below right,inner sep=0]{$PROVE(\sigma)$};
+\draw[pstyle5] (34pt,391.1576pt) -- (24pt,395.1576pt) -- (34pt,399.1576pt) -- (30pt,395.1576pt) -- cycle;
+\draw[pstyle6] (28pt,395.1576pt) -- (108.609pt,395.1576pt);
+\node at (40pt,383.1576pt)[below right,inner sep=0]{$APPEND(\sigma)$};
+\draw[pstyle5] (295.2197pt,405.1576pt) -- (305.2197pt,409.1576pt) -- (295.2197pt,413.1576pt) -- (299.2197pt,409.1576pt) -- cycle;
+\draw[pstyle6] (244.8331pt,409.1576pt) -- (301.2197pt,409.1576pt);
+\draw[pstyle5] (232.9877pt,433.7908pt) -- (242.8331pt,438.1576pt) -- (232.6921pt,441.7853pt) -- (236.8372pt,437.9359pt) -- cycle;
+\draw[pstyle6] (109.609pt,433.1576pt) -- (242.8331pt,438.1576pt);
+\node at (116.609pt,421.1576pt)[below right,inner sep=0]{$RBcast(submit, S, r, 1, \sigma)$};
+\draw[pstyle5] (295.8008pt,452.9341pt) -- (305.2197pt,458.1576pt) -- (294.7967pt,460.8708pt) -- (299.2671pt,457.4045pt) -- cycle;
+\draw[pstyle6] (109.609pt,433.1576pt) -- (305.2197pt,458.1576pt);
+\node at (116.609pt,421.1576pt)[below right,inner sep=0]{$RBcast(submit, S, r, 1, \sigma)$};
+\draw[pstyle5] (358.5415pt,477.3411pt) -- (367.6062pt,483.1576pt) -- (357.0307pt,485.1971pt) -- (361.7142pt,482.0245pt) -- cycle;
+\draw[pstyle6] (109.609pt,433.1576pt) -- (367.6062pt,483.1576pt);
+\node at (116.609pt,421.1576pt)[below right,inner sep=0]{$RBcast(submit, S, r, 1, \sigma)$};
+\draw[pstyle5] (34pt,503.1576pt) -- (24pt,507.1576pt) -- (34pt,511.1576pt) -- (30pt,507.1576pt) -- cycle;
+\draw[pstyle6] (28pt,507.1576pt) -- (243.8331pt,507.1576pt);
+\node at (40pt,495.1576pt)[below right,inner sep=0]{$P \gets READ()$};
+\draw[pstyle5] (34pt,503.1576pt) -- (24pt,507.1576pt) -- (34pt,511.1576pt) -- (30pt,507.1576pt) -- cycle;
+\draw[pstyle6] (28pt,507.1576pt) -- (306.2197pt,507.1576pt);
+\draw[pstyle5] (34pt,503.1576pt) -- (24pt,507.1576pt) -- (34pt,511.1576pt) -- (30pt,507.1576pt) -- cycle;
+\draw[pstyle6] (28pt,507.1576pt) -- (368.6062pt,507.1576pt);
+\draw[pstyle6] (244.8331pt,531.1754pt) -- (286.8331pt,531.1754pt);
+\draw[pstyle6] (286.8331pt,531.1754pt) -- (286.8331pt,544.1754pt);
+\draw[pstyle6] (245.8331pt,544.1754pt) -- (286.8331pt,544.1754pt);
+\draw[pstyle5] (255.8331pt,540.1754pt) -- (245.8331pt,544.1754pt) -- (255.8331pt,548.1754pt) -- (251.8331pt,544.1754pt) -- cycle;
+\node at (251.8331pt,519.1576pt)[below right,inner sep=0]{$V'(pk, r, \sigma)$};
+\draw[pstyle6] (307.2197pt,531.1754pt) -- (349.2197pt,531.1754pt);
+\draw[pstyle6] (349.2197pt,531.1754pt) -- (349.2197pt,544.1754pt);
+\draw[pstyle6] (308.2197pt,544.1754pt) -- (349.2197pt,544.1754pt);
+\draw[pstyle5] (318.2197pt,540.1754pt) -- (308.2197pt,544.1754pt) -- (318.2197pt,548.1754pt) -- (314.2197pt,544.1754pt) -- cycle;
+\node at (314.2197pt,519.1576pt)[below right,inner sep=0]{$V'(pk, r, \sigma)$};
+\draw[pstyle6] (369.6062pt,531.1754pt) -- (411.6062pt,531.1754pt);
+\draw[pstyle6] (411.6062pt,531.1754pt) -- (411.6062pt,544.1754pt);
+\draw[pstyle6] (370.6062pt,544.1754pt) -- (411.6062pt,544.1754pt);
+\draw[pstyle5] (380.6062pt,540.1754pt) -- (370.6062pt,544.1754pt) -- (380.6062pt,548.1754pt) -- (376.6062pt,544.1754pt) -- cycle;
+\node at (376.6062pt,519.1576pt)[below right,inner sep=0]{$V'(pk, r, \sigma)$};
+\end{tikzpicture}

Recherche/BFT-ARBover/diagrams/nonBFT_behaviour.puml

@@ -0,0 +1,32 @@
+@startuml
+!pragma teoz true
+
+database DL
+actor P1
+actor Pi
+
+P1 -> P1 : <latex>ABcast(m)</latex>
+P1 -> P1 : <latex>m \in S</latex>
+
+P1 -> DL : <latex>READ()</latex>
+DL --> P1 : <latex>P</latex>
+P1 -> P1 : <latex>r_{max} = max\{r : (\_, prove(r)) \in P\}</latex>
+
+loop <latex>\textbf{foreach } r \in \{r_{max} + 1, \dots\}</latex>
+    
+    P1 ->(05) Pi : <latex>RBcast(prop, S, r, 1)</latex>
+
+    P1 -> DL : <latex>PROVE(r)</latex>
+    P1 -> DL : <latex>APPEND(r)</latex>
+
+    P1 -> DL : <latex>READ()</latex>
+    DL --> P1 : <latex>P</latex>
+
+    alt <latex>(1, \text{prove(}r\text{)}) \in P</latex>
+        note over P1 : break
+    else <latex>(\exists j, r' : (j, prove(r')) \in P \land m \in prop[r'][j])</latex>
+        note over P1 : break
+    end
+end
+hide footbox
+@enduml

Recherche/BFT-ARBover/diagrams/nonBFT_behaviour.tex

@@ -0,0 +1,93 @@
+% generated by Plantuml 1.2025.10      
+\definecolor{plantucolor0000}{RGB}{255,255,255}
+\definecolor{plantucolor0001}{RGB}{24,24,24}
+\definecolor{plantucolor0002}{RGB}{0,0,0}
+\definecolor{plantucolor0003}{RGB}{226,226,240}
+\definecolor{plantucolor0004}{RGB}{238,238,238}
+\definecolor{plantucolor0005}{RGB}{254,255,221}
+\begin{tikzpicture}[yscale=-1
+,pstyle0/.style={color=plantucolor0000,line width=0.0pt}
+,pstyle1/.style={color=plantucolor0001,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
+,pstyle2/.style={color=plantucolor0001,fill=plantucolor0003,line width=0.5pt}
+,pstyle3/.style={color=plantucolor0001,line width=0.5pt}
+,pstyle4/.style={color=plantucolor0001,line width=1.0pt}
+,pstyle5/.style={color=plantucolor0001,fill=plantucolor0001,line width=1.0pt}
+,pstyle6/.style={color=plantucolor0001,line width=1.0pt,dash pattern=on 2.0pt off 2.0pt}
+,pstyle7/.style={color=black,fill=plantucolor0004,line width=1.5pt}
+,pstyle8/.style={color=black,line width=1.5pt}
+,pstyle10/.style={color=plantucolor0001,fill=plantucolor0005,line width=0.5pt}
+]
+\draw[pstyle0] (20.5pt,75pt) rectangle (28.5pt,537.1498pt);
+\draw[pstyle1] (24pt,75pt) -- (24pt,537.1498pt);
+\draw[pstyle0] (105.8255pt,75pt) rectangle (113.8255pt,537.1498pt);
+\draw[pstyle1] (109.3255pt,75pt) -- (109.3255pt,537.1498pt);
+\draw[pstyle0] (273.8933pt,75pt) rectangle (281.8933pt,537.1498pt);
+\draw[pstyle1] (277.3933pt,75pt) -- (277.3933pt,537.1498pt);
+\node at (14.055pt,65pt)[below right,color=black,inner sep=0]{DL};
+\draw[pstyle2] (6pt,29pt) ..controls (6pt,19pt) and (24pt,19pt) .. (24pt,19pt) ..controls (24pt,19pt) and (42pt,19pt) .. (42pt,29pt) -- (42pt,55pt) ..controls (42pt,65pt) and (24pt,65pt) .. (24pt,65pt) ..controls (24pt,65pt) and (6pt,65pt) .. (6pt,55pt) -- (6pt,29pt);
+\draw[pstyle3] (6pt,29pt) ..controls (6pt,39pt) and (24pt,39pt) .. (24pt,39pt) ..controls (24pt,39pt) and (42pt,39pt) .. (42pt,29pt);
+\node at (100.4205pt,65pt)[below right,color=black,inner sep=0]{P1};
+\draw[pstyle2] (109.3255pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle3] (109.3255pt,21.5pt) -- (109.3255pt,48.5pt)(96.3255pt,29.5pt) -- (122.3255pt,29.5pt)(109.3255pt,48.5pt) -- (96.3255pt,63.5pt)(109.3255pt,48.5pt) -- (122.3255pt,63.5pt);
+\node at (269.5983pt,65pt)[below right,color=black,inner sep=0]{Pi};
+\draw[pstyle2] (277.3933pt,13.5pt) ellipse (8pt and 8pt);
+\draw[pstyle3] (277.3933pt,21.5pt) -- (277.3933pt,48.5pt)(264.3933pt,29.5pt) -- (290.3933pt,29.5pt)(277.3933pt,48.5pt) -- (264.3933pt,63.5pt)(277.3933pt,48.5pt) -- (290.3933pt,63.5pt);
+\draw[pstyle4] (109.3255pt,99pt) -- (151.3255pt,99pt);
+\draw[pstyle4] (151.3255pt,99pt) -- (151.3255pt,112pt);
+\draw[pstyle4] (110.3255pt,112pt) -- (151.3255pt,112pt);
+\draw[pstyle5] (120.3255pt,108pt) -- (110.3255pt,112pt) -- (120.3255pt,116pt) -- (116.3255pt,112pt) -- cycle;
+\node at (116.3255pt,87pt)[below right,inner sep=0]{$ABcast(m)$};
+\draw[pstyle4] (109.3255pt,133.2243pt) -- (151.3255pt,133.2243pt);
+\draw[pstyle4] (151.3255pt,133.2243pt) -- (151.3255pt,146.2243pt);
+\draw[pstyle4] (110.3255pt,146.2243pt) -- (151.3255pt,146.2243pt);
+\draw[pstyle5] (120.3255pt,142.2243pt) -- (110.3255pt,146.2243pt) -- (120.3255pt,150.2243pt) -- (116.3255pt,146.2243pt) -- cycle;
+\node at (116.3255pt,124pt)[below right,inner sep=0]{$m \in S$};
+\draw[pstyle5] (35pt,166.2243pt) -- (25pt,170.2243pt) -- (35pt,174.2243pt) -- (31pt,170.2243pt) -- cycle;
+\draw[pstyle4] (29pt,170.2243pt) -- (108.3255pt,170.2243pt);
+\node at (41pt,158.2243pt)[below right,inner sep=0]{$READ()$};
+\draw[pstyle5] (97.3255pt,187.0576pt) -- (107.3255pt,191.0576pt) -- (97.3255pt,195.0576pt) -- (101.3255pt,191.0576pt) -- cycle;
+\draw[pstyle6] (24pt,191.0576pt) -- (103.3255pt,191.0576pt);
+\node at (31pt,182.2243pt)[below right,inner sep=0]{$P$};
+\draw[pstyle4] (109.3255pt,215.0576pt) -- (151.3255pt,215.0576pt);
+\draw[pstyle4] (151.3255pt,215.0576pt) -- (151.3255pt,228.0576pt);
+\draw[pstyle4] (110.3255pt,228.0576pt) -- (151.3255pt,228.0576pt);
+\draw[pstyle5] (120.3255pt,224.0576pt) -- (110.3255pt,228.0576pt) -- (120.3255pt,232.0576pt) -- (116.3255pt,228.0576pt) -- cycle;
+\node at (116.3255pt,203.0576pt)[below right,inner sep=0]{$r_{max} = max\{r : (\_, prove(r)) \in P\}$};
+\draw[pstyle7] (8pt,240.0576pt) -- (74.4pt,240.0576pt) -- (74.4pt,242.0576pt) -- (64.4pt,252.0576pt) -- (8pt,252.0576pt) -- (8pt,240.0576pt);
+\draw[pstyle8] (8pt,240.0576pt) rectangle (293.4464pt,513.1498pt);
+\node at (23pt,241.0576pt)[below right,color=black,inner sep=0]{\textbf{loop}};
+\node at (89.4pt,243.3076pt)[below right,color=black,inner sep=0]{\textbf{[}};
+\node at (92.59pt,242.0576pt)[below right,inner sep=0]{$\textbf{foreach } r \in \{r_{max} + 1, \dots\}$};
+\node at (215.4514pt,243.3076pt)[below right,color=black,inner sep=0]{\textbf{]}};
+\draw[pstyle5] (265.5167pt,278.762pt) -- (275.3933pt,283.0576pt) -- (265.2788pt,286.7585pt) -- (269.396pt,282.8792pt) -- cycle;
+\draw[pstyle4] (109.3255pt,278.0576pt) -- (275.3933pt,283.0576pt);
+\node at (116.3255pt,266.0576pt)[below right,inner sep=0]{$RBcast(prop, S, r, 1)$};
+\draw[pstyle5] (35pt,303.0576pt) -- (25pt,307.0576pt) -- (35pt,311.0576pt) -- (31pt,307.0576pt) -- cycle;
+\draw[pstyle4] (29pt,307.0576pt) -- (108.3255pt,307.0576pt);
+\node at (41pt,295.0576pt)[below right,inner sep=0]{$PROVE(r)$};
+\draw[pstyle5] (35pt,327.0576pt) -- (25pt,331.0576pt) -- (35pt,335.0576pt) -- (31pt,331.0576pt) -- cycle;
+\draw[pstyle4] (29pt,331.0576pt) -- (108.3255pt,331.0576pt);
+\node at (41pt,319.0576pt)[below right,inner sep=0]{$APPEND(r)$};
+\draw[pstyle5] (35pt,351.0576pt) -- (25pt,355.0576pt) -- (35pt,359.0576pt) -- (31pt,355.0576pt) -- cycle;
+\draw[pstyle4] (29pt,355.0576pt) -- (108.3255pt,355.0576pt);
+\node at (41pt,343.0576pt)[below right,inner sep=0]{$READ()$};
+\draw[pstyle5] (97.3255pt,371.8909pt) -- (107.3255pt,375.8909pt) -- (97.3255pt,379.8909pt) -- (101.3255pt,375.8909pt) -- cycle;
+\draw[pstyle6] (24pt,375.8909pt) -- (103.3255pt,375.8909pt);
+\node at (31pt,367.0576pt)[below right,inner sep=0]{$P$};
+\draw[pstyle7] (65.7255pt,387.8909pt) -- (123.9755pt,387.8909pt) -- (123.9755pt,389.8909pt) -- (113.9755pt,399.8909pt) -- (65.7255pt,399.8909pt) -- (65.7255pt,387.8909pt);
+\draw[pstyle8] (65.7255pt,387.8909pt) rectangle (268.4464pt,499.1498pt);
+\node at (80.7255pt,388.8909pt)[below right,color=black,inner sep=0]{\textbf{alt}};
+\node at (138.9755pt,391.1409pt)[below right,color=black,inner sep=0]{\textbf{[}};
+\node at (142.1655pt,389.8909pt)[below right,inner sep=0]{$(1, \text{prove(}r\text{)}) \in P$};
+\node at (215.6282pt,391.1409pt)[below right,color=black,inner sep=0]{\textbf{]}};
+\draw[color=black,line width=1.0pt,dash pattern=on 2.0pt off 2.0pt] (65.7255pt,450.8909pt) -- (268.4464pt,450.8909pt);
+\node at (70.7255pt,454.1498pt)[below right,color=black,inner sep=0]{\textbf{[}};
+\node at (73.9155pt,452.8909pt)[below right,inner sep=0]{$(\exists j, r' : (j, prove(r')) \in P \land m \in prop[r'][j])$};
+\node at (263.2564pt,454.1498pt)[below right,color=black,inner sep=0]{\textbf{]}};
+\draw[pstyle10] (86.7255pt,414.8909pt) -- (86.7255pt,434.8909pt) -- (131.7255pt,434.8909pt) -- (131.7255pt,424.8909pt) -- (121.7255pt,414.8909pt) -- (86.7255pt,414.8909pt);
+\draw[pstyle10] (121.7255pt,414.8909pt) -- (121.7255pt,424.8909pt) -- (131.7255pt,424.8909pt) -- (121.7255pt,414.8909pt);
+\node at (92.7255pt,419.8909pt)[below right,color=black,inner sep=0]{break};
+\draw[pstyle10] (86.7255pt,474.1498pt) -- (86.7255pt,494.1498pt) -- (131.7255pt,494.1498pt) -- (131.7255pt,484.1498pt) -- (121.7255pt,474.1498pt) -- (86.7255pt,474.1498pt);
+\draw[pstyle10] (121.7255pt,474.1498pt) -- (121.7255pt,484.1498pt) -- (131.7255pt,484.1498pt) -- (121.7255pt,474.1498pt);
+\node at (92.7255pt,479.1498pt)[below right,color=black,inner sep=0]{break};
+\end{tikzpicture}

Recherche/BFT-ARBover/main.tex

@@ -0,0 +1,303 @@
+\documentclass[11pt]{article}
+
+\usepackage[margin=1in]{geometry}
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage{lmodern}
+\usepackage{microtype}
+\usepackage{amsmath,amssymb,amsthm,mathtools}
+\usepackage{thmtools}
+\usepackage{enumitem}
+\usepackage{csquotes}
+\usepackage[hidelinks]{hyperref}
+\usepackage[nameinlink,noabbrev]{cleveref}
+\usepackage[ruled, vlined, linesnumbered, algonl, titlenumbered]{algorithm2e}
+\usepackage{graphicx}
+
+\SetKwProg{Fn}{Function}{}{EndFunction}
+\SetKwFunction{Wait}{Wait Until}
+\SetKwProg{Upon}{Upon}{}{EndUpon}
+\SetKwComment{Comment}{}{}
+
+\usepackage{tikz}
+\graphicspath{{diagrams/out}}
+\usepackage{xspace}
+% \usepackage{plantuml}
+
+\usepackage[fr-FR]{datetime2}
+
+\usepackage{fancyhdr}
+\pagestyle{fancy}
+\fancyhf{}
+\fancyfoot[L]{Compilé le \DTMnow}
+\fancyfoot[C]{\thepage}
+\renewcommand{\headrulewidth}{0pt}
+\renewcommand{\footrulewidth}{0pt}
+
+\theoremstyle{plain}
+\newtheorem{theorem}{Theorem}
+\newtheorem{lemma}[theorem]{Lemma}
+\newtheorem{corollary}[theorem]{Corollary}
+\theoremstyle{definition}
+\newtheorem{definition}{Definition}
+\theoremstyle{remark}
+\newtheorem{remark}{Remark}
+
+\newcommand{\RB}{\textsf{RB}\xspace}
+\newcommand{\res}{\mathsf{res}}
+\newcommand{\ARB}{\textsf{ARB}\xspace}
+\newcommand{\DL}{\textsf{DL}}
+\newcommand{\APPEND}{\textsf{APPEND}}
+\newcommand{\PROVE}{\textsf{PROVE}}
+\newcommand{\PROVEtrace}{\textsf{prove}}
+\newcommand{\READ}{\textsf{READ}}
+
+\newcommand{\BFTAPPEND}{\textsf{BFT\text{-}APPEND}}
+\newcommand{\BFTPROVE}{\textsf{BFT\text{-}PROVE}}
+\newcommand{\BFTREAD}{\textsf{BFT\text{-}READ}}
+
+
+\newcommand{\ABbroadcast}{\textsf{ABroadcast}}
+\newcommand{\ABdeliver}{\textsf{ADeliver}}
+\newcommand{\RBcast}{\textsf{RBroadcast}}
+\newcommand{\RBreceived}{\textsf{RReceived}}
+\newcommand{\ordered}{\textsf{ordered}}
+\newcommand{\Winners}{\mathsf{Winners}}
+\newcommand{\Messages}{\mathsf{Messages}}
+\newcommand{\ABlisten}{\textsf{AB-listen}}
+
+\newcommand{\CANDIDATE}{\textsf{VOTE}}
+\newcommand{\CLOSE}{\textsf{COMMIT}}
+\newcommand{\READGE}{\textsf{RESULT}}
+
+\newcommand{\SHARE}{\mathsf{SHARE}}
+\newcommand{\COMBINE}{\mathsf{COMBINE}}
+\newcommand{\VERIFY}{\mathsf{VERIFY}}
+
+\newcommand{\RETRIEVE}{\mathsf{RETRIEVE}}
+\newcommand{\SUBMIT}{\mathsf{SUBMIT}}
+
+\newcommand{\delivered}{\mathsf{delivered}}
+\newcommand{\received}{\mathsf{received}}
+\newcommand{\prop}{\mathsf{prop}}
+\newcommand{\resolved}{\mathsf{resolved}}
+\newcommand{\current}{\mathsf{current}}
+
+\newcommand{\Seq}{\mathsf{Seq}}
+\newcommand{\GE}{\mathsf{GE}}
+\newcommand{\BFTDL}{\textsf{BFT\text{-}DL}}
+
+\newcommand{\BFTGE}{\textsf{BFT\text{-}GE}}
+\newcommand{\BFTVOTE}{\textsf{BFT\text{-}VOTE}}
+\newcommand{\BFTCOMMIT}{\textsf{BFT\text{-}COMMIT}}
+\newcommand{\BFTRESULT}{\textsf{BFT\text{-}RESULT}}
+
+
+\crefname{theorem}{Theorem}{Theorems}
+\crefname{lemma}{Lemma}{Lemmas}
+\crefname{definition}{Definition}{Definitions}
+\crefname{algorithm}{Algorithm}{Algorithms}
+
+% Pour pouvoir referencer des lignes dans le pseudocode
+% \crefname{ALC@Line}{Lignes}{Lignes}
+% \Crefname{ALC@Line}{Ligne}{Lignes}
+\crefname{AlgoLine}{ligne}{lignes}
+\Crefname{AlgoLine}{Ligne}{Lignes}
+% Code exécuté par tout processus p_i
+
+\begin{document}
+
+\section{Model 1: Crash}
+We consider a static set $\Pi$ of $n$ processes with known identities, communicating by reliable point-to-point channels, in a complete graph. Messages are uniquely identifiable. At most $f$ processes can crash, with $n \geq f$.
+
+\paragraph{Synchrony.} The network is asynchronous.
+
+\paragraph{Communication.} Processes can exchange through a Reliable Broadcast ($\RB$) primitive (defined below) which is invoked with the functions $\RBcast(m)$ and $m = \RBreceived()$. There exists a shared object called DenyList ($\DL$) (defined below) that is interfaced with a set $O$ of operations. There exist three types of these operations: $\APPEND(x)$, $\PROVE(x)$ and $\READ()$.   
+
+\paragraph{Notation.} For any indice $x$ we defined by $\Pi_x$ a subset of $\Pi$. We consider two subsets $\Pi_M$ and $\Pi_V$ two authorization subsets. Indices $i \in \Pi$ refer to processes, and $p_i$ denotes the process with identifier $i$. Let $\mathcal{M}$ denote the universe of uniquely identifiable messages, with $m \in \mathcal{M}$. Let $\mathcal{R} \subseteq \mathbb{N}$ be the set of round identifiers; we write $r \in \mathcal{R}$ for a round. We use the precedence relation $\prec$ for the \DL{} linearization: $x \prec y$ means that operation $x$ appears strictly before $y$ in the linearized history of \DL. For any finite set $A \subseteq \mathcal{M}$, \ordered$(A)$ returns a deterministic total order over $A$ (e.g., lexicographic order on $(\textit{senderId},\textit{messageId})$ or on message hashes).
+For any operation $F \in O$,$F_i(...)$ denotes that the operation $F$ is invoked by process $p_i$.
+%For any round $r \in \mathcal{R}$, define $\Winners_r \triangleq \{\, j \in \Pi \mid (j,\PROVEtrace(r)) \prec \APPEND(r) \,\}$, i.e., the set of processes whose $\PROVE(r)$ appears before the first $\APPEND(r)$ in the \DL{} linearization.
+%We denoted by $\PROVE^{(j)}(r)$ or $\APPEND^{(j)}(r)$ the operation $\PROVE(r)$ or $\APPEND(r)$ invoked by process $j$.
+
+\section{Primitives}
+
+\input{2_Primitives/index.tex}
+
+\section{Atomic Reliable Broadcast (ARB)}
+
+\input{3_ARB_Def/index.tex}
+
+\section{ARB over RB and DL}
+
+\input{4_ARB_with_RB_DL/index.tex}
+
+\section{BFT-ARB over RB and DL}
+
+\input{5_BFT_ARB/index.tex}
+
+
+
+
+\section{Implementation of BFT-DenyList and Threshold Cryptography}
+
+\subsection{DenyList}
+
+\paragraph{BFT-DenyList}
+In our algorithm we use multiple DenyList as follows:
+
+\begin{itemize}
+  \item Let $\mathcal{DL} = \{DL_1, \dots, DL_k\}$ be the set of DenyList used by the algorithm.
+  \item We set $k = \binom{n}{f}$.
+  \item For each $i \in \{1,\dots,k\}$, let $M_i$ be the set of moderators associated with $DL_i$ according to the DenyList definition, so that $|M_i| = n-f$.
+  \item Let $\mathcal{M} = \{M_1, \dots, M_k\}$. We require that the $M_i$ are pairwise distinct:
+        \[
+          \forall i,j \in \{1,\dots,k\},\ i \neq j \implies M_i \neq M_j.
+        \]
+\end{itemize}
+
+
+\begin{lemma}
+  $\exists M_i \in M :  \forall p \in M_i$ $p$ is correct.
+\end{lemma}
+
+\begin{proof}
+  Let consider the set $F$ of faulty processes, with $|F| = f$. We can construct the set $M_i = \Pi \setminus F$ such that $|M_i| = n - |F| = n - f$. By construction, $\forall p \in M_i$ $p$ is correct.
+\end{proof}
+
+\begin{lemma}
+  $\forall M_i \in M, \exists p \in M_i$ such that $p$ is correct.  
+\end{lemma}
+
+\begin{proof}
+  $\forall i \in \{1, \dots, k\}, |M_i| = n-f$ with $n \geq 2f+1$. We can say that $|M_i| \geq 2f+1-f = f+1 > f$
+\end{proof}
+
+Each process can invoke the following functions :
+
+\begin{itemize}
+  \item $\READ' : () \rightarrow \mathcal{L}(\mathbb{R} \times \PROVEtrace(\mathbb{R}))$
+  \item $\APPEND' : \mathbb{R} \rightarrow ()$
+  \item $\PROVE' : \mathbb{R} \rightarrow \{0, 1\}$
+\end{itemize}
+
+Such that :
+
+% \begin{algorithm}[H]
+%   \caption{$\READ'() \rightarrow \mathcal{L}(\mathbb{R} \times \PROVEtrace(\mathbb{R}))$}
+%   \begin{algorithmic}
+%     \Function{READ'}{}
+%     \State $j \gets$ the process invoking $\READ'()$
+%     \State $res \gets \emptyset$
+%     \ForAll{$i \in \{1, \dots, k\}$}
+%       \State $res \gets res \cup DL_i.\READ()$
+%     \EndFor
+%     \State \Return $res$
+%     \EndFunction
+%   \end{algorithmic}
+% \end{algorithm}
+
+% \begin{algorithm}[H]
+%   \caption{$\APPEND'(\sigma) \rightarrow ()$}
+%   \begin{algorithmic}
+%     \Function{APPEND'}{$\sigma$}
+%     \State $j \gets$ the process invoking $\APPEND'(\sigma)$
+%     \ForAll{$M_i \in \{M_k \in  M : j \in M_k\}$}
+%       \State $DL_i.\APPEND(\sigma)$
+%     \EndFor
+%     \EndFunction
+%   \end{algorithmic}
+% \end{algorithm}
+
+% \begin{algorithm}[H]
+%   \caption{$\PROVE'(\sigma) \rightarrow \{0, 1\}$}
+%   \begin{algorithmic}
+%     \Function{PROVE'}{$\sigma$}
+%     \State $j \gets$ the process invoking $\PROVE'(\sigma)$
+%     \State $flag \gets false$
+%     \ForAll{$i \in \{1, \dots, k\}$}
+%       \State $flag \gets flag$ OR $DL_i.\PROVE(\sigma)$
+%     \EndFor
+%     \State \Return $flag$
+%     \EndFunction
+%   \end{algorithmic}
+% \end{algorithm}
+
+\begin{algorithm}[H]
+  \caption{$\READ'() \rightarrow \mathcal{L}(\mathbb{R} \times \PROVEtrace(\mathbb{R}))$}
+    $j \gets$ the process invoking $\READ'()$\;
+    $res \gets \emptyset$\;
+    \ForAll{$i \in \{1, \dots, k\}$}{
+      $res \gets res \cup DL_i.\READ()$\;
+    }
+    \Return{$res$}\;
+ \end{algorithm}
+
+  \begin{algorithm}[H]
+    \caption{$\APPEND'(\sigma) \rightarrow ()$}
+      $j \gets$ the process invoking $\APPEND'(\sigma)$\;
+      \ForAll{$M_i \in \{M_k \in  M : j \in M_k\}$}{
+        $DL_i.\APPEND(\sigma)$\;
+      }
+  \end{algorithm}
+
+  \begin{algorithm}[H]
+    \caption{$\PROVE'(\sigma) \rightarrow \{0, 1\}$}
+      $j \gets$ the process invoking $\PROVE'(\sigma)$\;
+      $flag \gets false$\;
+      \ForAll{$i \in \{1, \dots, k\}$}{
+        $flag \gets flag$ OR $DL_i.\PROVE(\sigma)$\;
+      }
+      \Return{$flag$}\;
+  \end{algorithm}
+
+\subsection{Threshold Cryptography}
+
+We are using the Boneh-Lynn-Shacham scheme as cryptography primitive to our threshold signature scheme.
+With :
+
+\begin{itemize}
+  \item $G : \mathbb{R} \rightarrow \mathbb{R} \times \mathbb{R} $
+  \item $S : \mathbb{R} \times \mathcal{R} \rightarrow \mathbb{R} $
+  \item $V : \mathbb{R} \times \mathcal{R} \times \mathbb{R} \rightarrow \{0, 1\} $
+\end{itemize}
+
+Such that :
+
+\begin{itemize}
+  \item $G(x) \rightarrow (pk, sk)$ : where $x$ is a random value such that $\nexists x_1, x_2: x_1 \neq x_2, G(x_1) = G(x_2)$
+  \item $S(sk, m) \rightarrow \sigma_m$
+  \item $V(pk, m_1, \sigma_{m_2}) \rightarrow k$ : with $k = 1$ iff $m_1 == m_2$ and $\exists x \in \mathbb{R}$ such that $G(x) \rightarrow (pk, sk)$; otherwise $k = 0$
+\end{itemize}
+
+\paragraph{threshold Scheme}
+
+In our algorithm we are only using the following functions :
+
+\begin{itemize}
+  \item $G' : \mathbb{R} \times \mathbb{N} \times \mathbb{N} \rightarrow \mathbb{R} \times (\mathbb{R} \times \mathbb{R})^n$ : with $n \triangleq |\Pi|$
+  \item $S' : \mathbb{R} \times \mathcal{R} \rightarrow \mathbb{R}$
+  \item $C' : \mathbb{R}^n \times \mathcal{R} \times \mathbb{R} \times \mathbb{R}^t \rightarrow \{\mathbb{R}, \bot\}$ : with $t \leq n$
+  \item $V' : \mathbb{R} \times \mathcal{R} \times \mathbb{R} \rightarrow \{0, 1\}$
+\end{itemize}
+
+Such that :
+
+\begin{itemize}
+  \item $G'(x, n, t) \rightarrow (pk, pk_1, sk_1, \dots, pk_n, sk_n)$ : let define $pkc = {pk_1, \dots, pk_n}$
+  \item $S'(sk_i, m) \rightarrow \sigma_m^i$
+  \item $C'(pkc, m_1, J, \{\sigma_{m_2}^j\}_{j \in J}) \rightarrow \sigma$ : with $J \subseteq \Pi$; and $\sigma = \sigma_{m_1}$ iff $|J| \geq t, \forall j \in J: V(pk_j, m_1, \sigma_{m_2}^j) == 1$; otherwise $\sigma = \bot$.
+  \item $V'(pk, m_1, \sigma_{m_2}) \rightarrow V(pk, m_1, \sigma_{m_2})$
+\end{itemize}
+
+
+\bibliographystyle{plain}
+\begin{thebibliography}{9}
+% (left intentionally blank)
+\bibitem{Schneider90}
+Fred B.~Schneider.
+\newblock Implementing fault-tolerant services using the state machine
+  approach: a tutorial.
+\newblock {\em ACM Computing Surveys}, 22(4):299--319, 1990.
+\end{thebibliography}
+
+\end{document}

Recherche/yaoLatticeAgreement/main.tex

@@ -0,0 +1,105 @@
+\documentclass[11pt]{article}
+
+\usepackage[margin=1in]{geometry}
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage{lmodern}
+\usepackage{microtype}
+\usepackage{amsmath,amssymb,amsthm,mathtools}
+\usepackage{thmtools}
+\usepackage{enumitem}
+\usepackage{csquotes}
+\usepackage[hidelinks]{hyperref}
+\usepackage[nameinlink,noabbrev]{cleveref}
+\usepackage{algorithm}
+\usepackage{algpseudocode}
+% Line-number prefix configuration (A/B/C)
+\renewcommand{\thealgorithm}{\Alph{algorithm}} % Float labels: Algorithm A, B, C
+\newcommand{\algletter}{}
+\algrenewcommand\alglinenumber[1]{\scriptsize\textbf{\algletter}#1}
+\usepackage{tikz}
+\usepackage{xspace}
+
+\usepackage[fr-FR]{datetime2}
+
+\usepackage{fancyhdr}
+\pagestyle{fancy}
+\fancyhf{}
+\fancyfoot[L]{Compilé le \DTMnow}
+\fancyfoot[C]{\thepage}
+\renewcommand{\headrulewidth}{0pt}
+\renewcommand{\footrulewidth}{0pt}
+
+\theoremstyle{plain}
+\newtheorem{theorem}{Theorem}
+\newtheorem{lemma}[theorem]{Lemma}
+\newtheorem{corollary}[theorem]{Corollary}
+\theoremstyle{definition}
+\newtheorem{definition}{Definition}
+\theoremstyle{remark}
+\newtheorem{remark}{Remark}
+
+\newcommand{\send}{\textsf{send}}
+\newcommand{\recv}{\textsf{recv}}
+\newcommand{\hash}{\textsf{hash}}
+\newcommand{\procQueue}{\textsf{processQueue}}
+\newcommand{\RBcast}{\textsf{RB-cast}}
+\newcommand{\RBreceived}{\textsf{RB-received}}
+
+\newcommand{\queue}{\mathsf{queue}}
+
+\crefname{theorem}{Theorem}{Theorems}
+\crefname{lemma}{Lemma}{Lemmas}
+\crefname{definition}{Definition}{Definitions}
+\crefname{algorithm}{Algorithm}{Algorithms}
+
+% \title{Upgrading Reliable Broadcast to Atomic Reliable Broadcast with a DenyList Primitive}
+\date{\vspace{-1ex}}
+
+\begin{document}
+% \maketitle
+
+\section*{Algorithm}
+
+\renewcommand{\algletter}{A}
+\begin{algorithm}
+  \begin{algorithmic}[1]    
+    \Function{send}{m} 
+      \State \RBcast$(self, m, \hash(H))$
+    \EndFunction
+    \vspace{1em}
+
+    \Function{\RBreceived}{$j, m, h$} 
+    \State $\queue[j] \gets \queue[j].push(\{(m, h)\})$
+      \If{$|\queue[j]| = 1$} \Comment{If this is the first message in the queue, process it}
+        \State \procQueue()
+      \EndIf
+    \EndFunction
+    \vspace{1em}
+
+    \Function{processQueue}{}
+      \For{$j$ such that $\queue[j] \neq \emptyset$}
+        \State $\{(m, h)\} \gets \queue[j].pop()$
+          % \If{$m$ is a singleton}
+          %   \State $H \gets H \cup \{m\}$; \recv$(m)$; $\queue[j] \gets \queue[j] \setminus \{(m, h)\}$
+          % \ElsIf{$\exists A : A \subseteq H\ \wedge\ \hash(A) = h$}
+          %   \State $H \gets H \cup \{m\}$; \recv$(m)$; $\queue[j] \gets \queue[j] \setminus \{(m, h)\}$
+          % \Else
+          %   \State \textbf{break}
+          % \EndIf
+        \If{$\exists A : A \subseteq H\ \wedge\ \hash(A) = h$}
+          \State $H \gets H \cup \{m\}$; \recv$(m)$; $\queue[j] \gets \queue[j] \setminus \{(m, h)\}$
+          \State \procQueue();
+          \Return;
+        \EndIf
+      \EndFor
+    \EndFunction
+  \end{algorithmic}
+\end{algorithm}
+
+% \bibliographystyle{plain}
+% \begin{thebibliography}{9}
+% % (left intentionally blank)
+% \end{thebibliography}
+
+\end{document}

docs/presentations/LIS/CSI2025/main.tex

@@ -0,0 +1,252 @@
+\documentclass[aspectratio=169]{beamer}
+
+\usetheme{Madrid}
+\usefonttheme{professionalfonts}
+
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage[french]{babel}
+\usepackage{mathtools,amssymb}
+\usepackage{microtype}
+\usepackage{pgfgantt}
+\usepackage{adjustbox}
+% Réduire la densité verticale par défaut
+% \ganttset{y unit chart=0.45cm, y unit title=0.6cm, bar height=0.35}
+
+% Acronymes utiles
+\newcommand{\EC}{\textsc{EC}}
+\newcommand{\CRDT}{\textsc{CRDT}}
+\newcommand{\PCDO}{\textsc{PCDO}}
+\newcommand{\RB}{\textsc{RB}}
+\newcommand{\ARB}{\textsc{ARB}}
+\newcommand{\BFT}{\textsc{BFT}}
+\newcommand{\DL}{\textsc{DL}}
+\newcommand{\AL}{\textsc{AL}}
+\newcommand{\ZT}{\textsc{ZT}}
+
+
+% =====================
+% Paramétrage générique et macros d'usage
+% ---------------------
+% Définir la fenêtre temporelle du diagramme (ISO 8601)
+\newcommand{\GanttSetup}[2]{% #1 = YYYY-MM-DD (début), #2 = YYYY-MM-DD (fin)
+  \def\GanttStart{#1}%
+  \def\GanttEnd{#2}%
+}
+% Evénement sur période
+% Usage : \Period[<opts pgfgantt>]{<label>}{<YYYY-MM-DD>}{<YYYY-MM-DD>}
+\newcommand{\Period}[4][]{\ganttbar[#1]{#2}{#3}{#4}}
+% Evénement ponctuel (jalon)
+% Usage : \Event[<opts pgfgantt>]{<label>}{<YYYY-MM-DD>}
+\newcommand{\Event}[3][]{\ganttmilestone[#1]{#2}{#3}}
+% Groupe (optionnel)
+% Usage : \Block[<opts>]{<label>}{<YYYY-MM-DD>}{<YYYY-MM-DD>}
+\newcommand{\Block}[4][]{\ganttgroup[#1]{#2}{#3}{#4}}
+
+% Style par défaut (sobre, lisible en salle)
+\ganttset{
+  calendar week text={},
+  time slot format=isodate,
+  vgrid, hgrid,
+  x unit=0.42cm,    % densité horizontale
+  y unit chart=0.45cm, y unit title=0.6cm, bar height=0.35,
+  bar/.append style={fill=blue!35},
+  group/.append style={fill=black!10},
+  milestone/.append style={fill=red!60},
+  bar label font=\scriptsize, group label font=\scriptsize, milestone label font=\scriptsize,
+  title label font=\footnotesize, title/.style={fill=black!5}
+}
+
+\title{2ème Comité de Suivi Individuel 2024-2025}
+\subtitle{Thèse CIFRE - Cohérence Faible pour le cloud zero-trust}
+\institute[AMU - LIS - Scille]{Université Aix-Marseille - LIS \and Scille} 
+% \logo{\includegraphics[height=0.5cm]{logo-lis.png} \hspace{2em} \includegraphics[height=0.5cm]{parsec.png}}
+\author[Amaury JOLY]{Amaury JOLY \\ \vspace{1em} \textbf{Encadrement :} Emmanuel GODARD, Corentin TRAVERS \\ \vspace{1em} \textbf{Comité de suivi :} Arnaud LABOUREL, Achour MOSTEFAOUI}
+\date{\today}
+
+\begin{document}
+
+\begin{frame}
+  \titlepage
+\end{frame}
+
+% Rajouter nombre d'heure recherche industrielle formation OK
+% Dire que le model CRDT et PCDO implique du RB OK
+% Usage de RB+DL=>ARB dans le cloud zero-trust
+% Etre plus claire sur les missions en cours avec Scille OK
+
+% Se renseigner sur l'état de l'art sur RB+DL=>ARB et PCDO
+
+% Voir avce Scille pour la poursuite de these
+
+% =======================
+\begin{frame}{Contexte de thèse (CIFRE)}
+  \begin{itemize}
+    \item Démarrage administratif : \textbf{janvier 2024}.
+    \item Sujet : \emph{Cohérence Faible pour le cloud zero-trust}.
+    \item Cadre : thèse \textbf{CIFRE} avec l’entreprise \textbf{Scille} (logiciel \texttt{parsec.cloud}).
+    \item Répartition d’activités : \textbf{70\% recherche} / \textbf{30\% entreprise}.
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{Contexte industriel — partage de fichiers \ZT{}}
+  \begin{itemize}
+    \item Produit : logiciel de partage de fichiers \textbf{zero-trust}.
+    \item Modèle \ZT{} : le \textbf{serveur ne voit que des données chiffrées} et ne connaît pas l’identité des utilisateurs.
+    \item Model de communication : \textbf{serveur centralisé unique} pour tous les clients.
+    \item Hypothèses : confiance pour la \textbf{redistribution des messages} et la \textbf{disponibilité} ; serveur \textbf{honnête mais curieux}.
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{Bilan des formations et divers (oct. 2024 — oct. 2025)}
+  \begin{itemize}
+    \item \textbf{REDOCS 2024} : 14 au 19 octobre 2024
+    \item \textbf{PEPR Trust in Cloud 2024} (Grenoble) : novembre 2024.
+    \item \textbf{PEPR Trust in Cloud 2025} (Massy) : octobre 2025.
+    \item \textbf{Séminaires entreprise} : 3 séances en présentiel.
+    \item \textbf{Reunion avancement produit et R\&D} : toutes les 2 semaines.
+    \item \textbf{Enseignement} : 30 h en M1 (24h TP + 6h TD) + Soutenances de stage M2 FSI
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{Missions en entreprise (résumé)}
+  \begin{itemize}
+    \item \textbf{Document BPI} : état de l’art et \textbf{valeur ajoutée} des fonctionnalités d’\emph{édition collaborative} de l’équipe R\&D Parsec.
+    \item \textbf{État de l’art} sur \textbf{\ZT{}} et \textbf{Data-Centric Security} pour une réponse à appel d’offres \textbf{OTAN}.
+    \item \textbf{Conseil} : stratégie de \textbf{sauvegarde} dans un contexte \textbf{pair-à-pair distribué} pour l’édition collaborative.
+    \item \textbf{CIR} : rédaction en cours d’un \textbf{document consolidé} couvrant les projets R\&D (état de l’art, besoins spécifiques, caractère innovant, avancées annuelles).
+    \vspace{1em}
+    \item Développement de \textbf{fonctionnalités} experimentales dans \texttt{parsec}
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{CRDT (Shapiro et al., 2011) - Rappel}
+  \begin{itemize}
+    \item Un \CRDT{} est une \textbf{spécification de type de donnée répliqué} qui permet d’\textbf{atteindre la cohérence éventuelle} (\EC) \textbf{sans imposer d’ordre total} entre les opérations (sous hypothèse de \textbf{Reliable Broadcast} (RB)).
+    \item L’idée clé est de \textbf{converger par construction} : les opérations (ou les jointures d’états) sont \textbf{commutatives} (souvent aussi associatives et idempotentes), garantissant que tout ordre de livraison mène au même état.
+    \pause
+    \item \textbf{Contrepartie} : la \textbf{structure commutative} restreint les usages aux applications dont les mises à jour sont naturellement commutatives; elle est moins adaptée lorsque des \textbf{invariants globaux non commutatifs} ou des \textbf{contraintes d’ordre} sont requis.
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{PCDO (Frey et al., 2023)}
+  \begin{itemize}
+    \item Les \PCDO{} étendent les \CRDT{} mais \textbf{ajoute une notion de légalité d’état} : un prédicat caractérise quels états sont \emph{légaux}.
+    \item Alors que, dans les \CRDT, \textbf{toutes les opérations sont éventuellement traitées par tous les nœuds} (sans ordre global), un \PCDO{} autorise d’\textbf{exiger un ordre pour certaines opérations}.
+    \pause
+    \item Pour \textbf{atteindre} cela sans sacrifier l’asynchronisme, la \textbf{contrainte d’ordre est restreinte \emph{par processus}} : seules les opérations \textbf{émises par le même processus} doivent être \textbf{émises et exécutées dans un certain ordre}.
+    \item Les opérations inter-processus restent commutatives (au sens requis par le prédicat de légalité), préservant la \EC{}.
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{\PCDO{} ?= \RB{} \BFT{}}
+  \begin{itemize}
+    \item \textbf{Question de recherche} : une implémentation \BFT{} d’un \PCDO{} est-elle \textbf{équivalente} à l’implémentation \BFT{} d’un \textbf{Reliable Broadcast} (\RB)?
+    \item Intuition : si un \PCDO{} impose un \textbf{ordre par émetteur}, et que \RB{}-BFT assure \textbf{livraison fiable/consistante}, peut-on \textbf{réduire} l’un à l’autre~?
+    \item \textbf{Travail en cours} : exploration d’algorithmes visant à \textbf{montrer l’équivalence} (ou une réduction bidirectionnelle). \textbf{À ce stade}, pas de résultat concluant.
+    \item Points de blocage actuels : \textbf{interaction entre la légalité d’état locale au processus} et les \textbf{garanties globales} de \RB{}-\BFT{} (accord, intégrité, terminaison).
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{AllowList et DenyList (Frey et al., 2023)}
+  \begin{itemize}
+    \item Présentation de travaux de \textbf{Mathieu Gestin} : spécification d’\AL{} et de \DL{} comme \textbf{registre partagé} dans un système \textbf{asynchrone} sujet aux \textbf{crashs}.
+    \item Interface fondée sur \textbf{trois primitives} :
+    \begin{itemize}
+      \item \texttt{APPEND(x)} : ajout d’un élément à l'\AL{}/\DL{}.
+      \item \texttt{PROVE(x)} : fournir une \textbf{preuve vérifiable} de présence/absence.
+      \item \texttt{READ()} : obtenir une \textbf{vue cohérente} du registre.
+    \end{itemize}
+    \item L’objectif est d’\textbf{atteindre les garanties attendues} d’une \AL{}/\DL{} distribuée (sécurité, auditabilité, progression sous asynchronisme avec crashs).
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{\RB{} + \DL{} $\Rightarrow$ \ARB{} (intuition)}
+  \begin{itemize}
+    \item Idée : utiliser la \textbf{\DL{} comme mécanisme de verrou/élection} pour \textbf{ordonner} des messages livrés via \RB{}, et ainsi passer à l’\textbf{Atomic Reliable Broadcast} (\ARB{}).
+    \item \textbf{Par rounds} :
+    \begin{enumerate}
+      \item À chaque round, un \textbf{ensemble non vide de vainqueurs} est sélectionné (via \DL{}) et \textbf{détient le droit d’émettre}.
+      \item Quand le round est \textbf{fermé}, les autres processus tentent d’être élus au \textbf{round suivant}.
+    \end{enumerate}
+    \item \textbf{Processus lents} : un mécanisme de \textbf{dissémination des messages en attente} force les nœuds corrects à \textbf{relayer/émettre} pour leur compte afin d’éviter les blocages.
+    \item L’ordonnancement par rounds permet d’\textbf{établir un ordre total} entre les messages.
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{\RB{} + \DL{} $\Rightarrow$ \ARB{} (contexte industriel \& ZT)}
+  \begin{itemize}
+    \item \textbf{Contraintes industrielles (CIFRE)} : les \CRDT{}\ \PCDO{} ne couvrent pas tous les cas d’usage — certaines applications requièrent un \textbf{ordre total} global malgré l’asynchronisme.
+    \item \textbf{Hypothèse architecturale} : un \textbf{serveur « proxy » ZT} ne voyant que des \textbf{chiffrés}, chargé de \textbf{dispatcher} et de \textbf{synchroniser} les messages; aucune logique métier ni accès au clair.
+    \item \textbf{Levier} : combiner \RB{} avec \DL{} pour sérialiser les tours d’émission; le proxy n’est qu’un \textbf{médiateur d’ordonnancement}, pas une source de confiance.
+    \item \textbf{Pertinence} : solution adaptée aux environnements contraints où la \textbf{centralisation de l’ordonnancement} est acceptable mais où la \textbf{confiance} reste minimisée.
+  \end{itemize}
+  \end{frame}
+  
+  % =======================
+  \begin{frame}{\RB{} + \DL{} $\Rightarrow$ \ARB{} (état d’avancement)}
+  \begin{itemize}
+    \item \textbf{Algorithme} : spécifié et en cours de \textbf{finalisation de la preuve} dans un \textbf{modèle crash}.
+    \item \textbf{Propriété visée} : \ARB{} (accord, validité, intégrité, \textbf{ordre total}).
+    \item \textbf{Perspectives} : extension au \textbf{modèle byzantin} (\BFT{}). Implémentation d'une \DL{} \ZT{} (e.g. calcul homomorphe).
+    \item \textbf{Implémentation} : prototype intégré à \texttt{parsec} pour la fonctionnalités de chat collaboratif (en cours).
+  \end{itemize}
+  \end{frame}
+
+% =====================
+
+  \begin{frame}[t]{Gantt 2024-2025}
+    \scriptsize
+    % Fenêtre temporelle
+    \GanttSetup{2024-10-01}{2025-10-15}
+    
+    % Limiter à la largeur et à 80% de la hauteur de la slide
+    \begin{adjustbox}{max totalsize={\textwidth}{0.8\textheight},center}
+      \begin{ganttchart}[
+          expand chart=\textwidth,
+          y unit chart=0.45cm,
+          y unit title=0.6cm,
+          bar height=0.35,
+      ]{\GanttStart}{\GanttEnd}
+        \gantttitlecalendar{year, month}\\
+    
+        \Period{REDOCS}{2024-10-14}{2024-10-18}\\
+        % Plusieurs jalons sur une même ligne pour gagner de la place
+        \Event{Séminaire Parsec}{2024-11-19}\ \Event{}{2025-03-20}\ \Event{}{2025-07-12}\\
+        \Event{PEPR TrustInCloud}{2024-12-05}\ \Event{}{2025-10-07}\\
+    
+        \Period[bar/.append style={fill=green!40}]{Livrable BPI}{2025-01-01}{2025-02-01}\\
+        \Period[bar/.append style={fill=green!40}]{État de l'art OTAN}{2025-04-01}{2025-04-30}\\
+        \Period[bar/.append style={fill=green!40}]{Conseil sauvegarde P2P}{2025-08-01}{2025-08-15}\\
+        \Period[bar/.append style={fill=green!40}]{Rédaction CIR}{2025-09-01}{2025-10-15}\\
+    
+        \Period[bar/.append style={fill=orange!70}]{Cours M1}{2024-10-01}{2024-12-31}\\
+    
+        \Period[bar/.append style={fill=blue!35}]{PCDO BFT vs RB BFT}{2024-10-01}{2025-01-01}\\
+        \Period[bar/.append style={fill=blue!35}]{Spécification RB+DL=>ARB (crash)}{2025-02-01}{2025-10-15}\\
+      \end{ganttchart}
+    \end{adjustbox}
+    \end{frame}
+
+  % =======================
+  \begin{frame}{Perspectives Académiques 2025-2026}
+    \begin{itemize}
+      \item \textbf{Publication} : soumission d’un article sur \RB{} + \DL{} $\Rightarrow$ \ARB{} en modèle \BFT{} (\textbf{printemps 2026}).
+      \item \textbf{Soumission de la thèse} : rédaction \textbf{fin 2026}, soutenance \textbf{1er semestre 2027}.
+      \begin{itemize}
+        \item Implique une 4ème année de thèse (financement à confirmer avec Scille).
+      \end{itemize}
+    \end{itemize} 
+  \end{frame}
+
+  \end{document}
+  

docs/presentations/LIS/CSI2025/rapport/main.tex

@@ -0,0 +1,222 @@
+
+\documentclass[11pt,a4paper]{article}
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage[french]{babel}
+\usepackage{geometry}
+\geometry{margin=2.2cm}
+\usepackage{graphicx}
+\usepackage{array}
+\usepackage{tabularx}
+\usepackage{longtable}
+\usepackage{booktabs}
+\usepackage{multirow}
+\usepackage{enumitem}
+\usepackage{amssymb}
+\usepackage{fancyhdr}
+\usepackage{pgfgantt}
+\usepackage{hyperref}
+\usepackage{xcolor}
+
+% ---------- Header / Footer with logo top-left on every page ----------
+\pagestyle{fancy}
+\fancyhf{} % clear
+% Replace 'logo_header.pdf' with your actual logo file (AMU/LIS or Scille). Height can be adjusted.
+\fancyhead[L]{\includegraphics[height=12mm]{logo_header.pdf}}
+\fancyfoot[C]{\thepage}
+
+% Avoid underlines for empty fields — we will leave space or boxes instead.
+
+% Table helpers
+\setlength{\extrarowheight}{1pt}
+\renewcommand{\arraystretch}{1.18}
+\newcolumntype{L}[1]{>{\raggedright\arraybackslash}p{#1}}
+\newcolumntype{C}[1]{>{\centering\arraybackslash}p{#1}}
+\newcolumntype{R}[1]{>{\raggedleft\arraybackslash}p{#1}}
+\setlist[itemize]{topsep=2pt,partopsep=0pt,itemsep=2pt,parsep=0pt}
+\setlist[enumerate]{topsep=2pt,partopsep=0pt,itemsep=2pt,parsep=0pt}
+
+% Checkboxes
+\newcommand{\cb}{\(\square\)}
+\newcommand{\cbdone}{\(\blacksquare\)} % when needed
+
+% Title info
+\title{\vspace{-1.5cm}\textbf{Rapport d'activité — 2\`eme Comité de Suivi Individuel (CSI) 2024--2025}\\[2mm]
+\large Thèse CIFRE --- Édition collaborative appliquée au cloud zero-trust}
+\author{Doctorant : Amaury JOLY \\
+Encadrement : Emmanuel GODARD, Corentin TRAVERS \\
+Comité de suivi : Arnaud LABOUREL, Achour MOSTEFAOUI \\
+Affiliations : Université Aix-Marseille (LIS), Scille}
+\date{14 octobre 2025}
+
+\begin{document}
+% ---------- Title page with logo top-left ----------
+\thispagestyle{fancy}
+\maketitle
+\vspace{-8mm}
+\begin{center}
+\includegraphics[height=18mm]{logo_header.pdf}
+\end{center}
+\vspace{4mm}
+\hrule
+\vspace{2mm}
+
+\section*{Résumé}
+Ce rapport présente les activités menées entre octobre 2024 et octobre 2025 dans le cadre de la thèse CIFRE d'Amaury JOLY, portant sur l'édition collaborative appliquée au cloud \emph{zero-trust}. Il reprend la structure et le style du rapport précédent tout en intégrant les éléments académiques, industriels et de recherche de l'année écoulée.\\[2mm]
+
+\section{Informations générales}
+\begin{tabularx}{\textwidth}{L{4.5cm}X}
+\toprule
+\textbf{Doctorant} & Amaury JOLY \\
+\textbf{Encadrants universitaires} & Emmanuel GODARD, Corentin TRAVERS \\
+\textbf{Entreprise (CIFRE)} & Scille (produit: \texttt{parsec.cloud}) \\
+\textbf{Comité de suivi (CSI)} & Arnaud LABOUREL, Achour MOSTEFAOUI \\
+\textbf{Démarrage administratif} & Janvier 2023 \\
+\textbf{Répartition d'activités} & 70\% recherche / 30\% entreprise \\
+\bottomrule
+\end{tabularx}
+
+\section{Contexte de thèse et industriel}
+\subsection{Sujet et cadre}
+Thèse CIFRE sur l'édition collaborative appliquée au cloud \emph{zero-trust} (ZT).
+
+\subsection{Contexte industriel --- partage de fichiers ZT}
+Produit visé : logiciel de partage de fichiers ZT. Hypothèses~: le serveur ne voit que des données chiffrées, ne connaît pas l'identité des utilisateurs ; modèle de communication centralisé (un serveur pour tous les clients) ; hypothèses de confiance limitées pour la redistribution et la disponibilité, serveur honnête mais curieux.
+
+\section{Bilan des formations, enseignement et diverses activités (oct. 2024 --- oct. 2025)}
+\subsection{Formations / événements}
+\begin{itemize}
+  \item \textbf{REDOCS 2024} : 14--19 octobre 2024.
+  \item \textbf{PEPR Trust in Cloud 2024 (Grenoble)} : novembre 2024.
+  \item \textbf{PEPR Trust in Cloud 2025 (Massy)} : octobre 2025.
+  \item \textbf{Séminaires entreprise} : 3 séances en présentiel.
+  \item \textbf{Réunions produit \& R\&D} : toutes les deux semaines.
+\end{itemize}
+
+\subsection{Enseignement}
+\begin{itemize}
+  \item \textbf{M1} : 30 h (24 h TP + 6 h TD).
+\end{itemize}
+
+\section{Missions en entreprise (synthèse)}
+\begin{itemize}
+  \item Document \textbf{BPI} : état de l’art et valeur ajoutée des fonctionnalités d’édition collaborative (équipe R\&D Parsec).
+  \item \textbf{ZT \& Data-Centric Security} : état de l’art pour une réponse à appel d’offres OTAN.
+  \item \textbf{Conseil} : stratégie de sauvegarde dans un contexte pair-à-pair distribué pour l’édition collaborative.
+  \item \textbf{CIR} : rédaction d’un document consolidé couvrant les projets R\&D (état de l’art, besoins spécifiques, caractère innovant, avancées annuelles).
+  \item \textbf{Développement} : fonctionnalités expérimentales dans \texttt{parsec}.
+\end{itemize}
+
+\section{Avancement scientifique}
+\subsection{Rappels : CRDT}
+Les CRDT (Shapiro \emph{et al.}, 2011) spécifient des types de données répliqués atteignant la \emph{cohérence éventuelle} (EC) sans ordre total global, sous hypothèse de \emph{Reliable Broadcast} (RB). L’idée clé est la convergence par construction grâce à la commutativité (souvent associativité et idempotence) des opérations ou jointures d’états. Limites : moins adapté quand des invariants globaux non commutatifs ou des contraintes d’ordre sont requis.
+
+\subsection{PCDO (Frey \emph{et al.}, 2023)}
+Les PCDO étendent les CRDT avec un prédicat de \emph{légalité} d’état. Ils autorisent d’exiger un ordre \emph{par processus} pour certaines opérations, tout en préservant l’asynchronisme et la EC pour les opérations inter-processus (commutatives au sens du prédicat de légalité).
+
+\subsection{Question en cours : \textit{PCDO ?= RB BFT}}
+Question : une implémentation BFT d’un PCDO est-elle équivalente à une implémentation BFT d’un RB ? Travail en cours (pas de résultat concluant à ce jour) : exploration d’algorithmes et des interactions entre légalité locale (par processus) et garanties globales de RB-BFT (accord, intégrité, terminaison).
+
+\subsection{AllowList / DenyList (travaux récents)}
+Spécification d’AllowList (AL) et DenyList (DL) comme registre partagé en système asynchrone avec crashs ; interface fondée sur \texttt{APPEND(x)}, \texttt{PROVE(x)} et \texttt{READ()} ; objectifs : sécurité, auditabilité, progression.
+
+\subsection{Vers ARB avec \textbf{RB + DL} : intuition et contexte ZT}
+\paragraph{Intuition.} Utiliser DL comme mécanisme de verrou/élection pour ordonner les messages livrés via RB et obtenir un \emph{Atomic Reliable Broadcast} (ARB). Fonctionnement par \emph{rounds} :\\[-5pt]
+\begin{enumerate}
+  \item À chaque round, un ensemble non vide de vainqueurs est élu (via DL) et détient le droit d’émettre.
+  \item À la fermeture du round, les autres processus tentent d’être élus au round suivant.
+\end{enumerate}
+Pour les processus lents, un mécanisme de dissémination force le relais/émission afin d’éviter les blocages, et l’ordonnancement par rounds induit un ordre total.
+
+\paragraph{Contexte industriel ZT.} Dans certains usages, les CRDT/PCDO ne suffisent pas : un ordre total global est nécessaire malgré l’asynchronisme. Hypothèse architecturale : un serveur \emph{proxy} ZT (médiateur d’ordonnancement, sans logique métier ni accès en clair) qui \emph{dispatch} et synchronise des messages chiffrés. L’objectif est de rester \emph{zero-trust} tout en centralisant l’ordonnancement au strict nécessaire.
+
+\subsection{État d’avancement (RB + DL $\Rightarrow$ ARB)}
+\begin{itemize}
+  \item \textbf{Algorithme} : spécifié ; preuve en cours de finalisation dans un modèle crash.
+  \item \textbf{Propriété visée} : ARB (accord, validité, intégrité, ordre total).
+  \item \textbf{Perspectives} : extension au modèle byzantin (BFT) ; implémentation d’une DL ZT (p.~ex. calcul homomorphe).
+  \item \textbf{Implémentation} : prototype intégré à \texttt{parsec} pour la fonctionnalité de \emph{chat} collaboratif (en cours).
+\end{itemize}
+
+\section{Planification --- Gantt 2024--2025}
+\begin{center}
+\resizebox{\textwidth}{!}{%
+\begin{ganttchart}[
+  time slot format=isodate,
+  y unit chart=0.7cm,
+  vgrid,
+  hgrid
+]{2024-10-01}{2025-10-01}
+\gantttitlecalendar{year, month=name} \\
+\ganttbar{REDOCS}{2024-10-14}{2024-10-19} \\
+\ganttbar{Séminaires Parsec}{2024-10-01}{2025-10-01} \\
+\ganttbar{PEPR TrustInCloud (Grenoble)}{2024-11-01}{2024-11-30} \\
+\ganttbar{Livrable BPI}{2024-12-01}{2025-01-31} \\
+\ganttbar{État de l'art OTAN}{2025-01-01}{2025-02-28} \\
+\ganttbar{Conseil sauvegarde P2P}{2025-02-01}{2025-03-31} \\
+\ganttbar{Rédaction CIR}{2025-03-01}{2025-05-31} \\
+\ganttbar{Cours M1}{2025-09-01}{2025-10-01} \\
+\ganttbar{PCDO BFT vs RB BFT}{2024-10-01}{2025-06-30} \\
+\ganttbar{Spécif. RB+DL $\Rightarrow$ ARB (crash)}{2025-04-01}{2025-10-01}
+\end{ganttchart}
+}
+\end{center}
+
+\section{Production scientifique, valorisation, expérience internationale}
+% Two-column checkboxes layout + single cell for Avis / Points / Reco
+\begin{longtable}{L{0.35\textwidth}L{0.3\textwidth}L{0.3\textwidth}}
+\toprule
+\textbf{Catégorie} & \textbf{Activités (cases à cocher)} & \textbf{Détails (si applicable)}\\
+\midrule
+\endfirsthead
+\toprule
+\textbf{Catégorie} & \textbf{Activités (cases à cocher)} & \textbf{Détails (si applicable)}\\
+\midrule
+\endhead
+\textbf{Production scientifique} & \cb~Article journal \quad \cb~Conf. int. \quad \cb~Conf. nat. \quad \cb~Préprint & \\[2mm]
+\textbf{Valorisation / Transfert} & \cb~Livrable \quad \cb~Logiciel (OSS) \quad \cb~Démonstrateur & \\[2mm]
+\textbf{Expérience internationale} & \cb~Séjour (dates:\hspace{1.5cm}) \quad \cb~Collab. int. & \\
+\bottomrule
+\end{longtable}
+
+\vspace{1mm}
+\noindent\textbf{Avis, Points de vigilance, Recommandations}\\[1mm]
+\begin{tabularx}{\textwidth}{|X|}
+\hline
+\vspace{0pt}\textbf{Avis} : \vspace{20mm}\\
+\textbf{Points de vigilance} : \vspace{20mm}\\
+\textbf{Recommandations} : \vspace{25mm}\\ \\
+\hline
+\end{tabularx}
+
+\section{Conditions de la formation doctorale (alignement amélioré)}
+\begin{tabularx}{\textwidth}{L{0.45\textwidth}X}
+\toprule
+\textbf{Sujet de thèse} & Édition collaborative appliquée au cloud zero-trust \\
+\textbf{École doctorale} & (à compléter) \\
+\textbf{Laboratoire} & LIS (AMU) \\
+\textbf{Financement} & CIFRE (Scille) \\
+\textbf{Formations suivies} & REDOCS 2024 ; PEPR Trust in Cloud 2024/2025 \\
+\textbf{Enseignement} & M1 : 30 h (24 h TP + 6 h TD) \\
+\textbf{Autres} & Séminaires entreprise (3) ; réunions produit/R\&D bi-hebdo \\
+\bottomrule
+\end{tabularx}
+
+\section{Perspectives académiques 2025--2026}
+\begin{itemize}
+  \item \textbf{Publication} : soumission d’un article \emph{RB + DL $\Rightarrow$ ARB} en modèle BFT (printemps 2026).
+  \item \textbf{Thèse} : début de rédaction fin 2026 ; soutenance visée au 1\textsuperscript{er} semestre 2027 (implique une 4\`eme année --- financement à confirmer avec Scille).
+\end{itemize}
+
+\section*{Espace réservé au compte rendu du CSI (à remplir le jour J)}
+\begin{tabularx}{\textwidth}{|L{0.22\textwidth}|X|}
+\hline
+\textbf{Participants} & \\[10mm]\hline
+\textbf{Synthèse des échanges} & \\[30mm]\hline
+\textbf{Décisions / Actions} & \\[20mm]\hline
+\end{tabularx}
+
+\vfill
+\noindent\footnotesize{Remarques de mise en page : (i) logo en haut à gauche sur toutes les pages ; (ii) pas de soulignement des champs vides ; (iii) listes en tableaux alignées en haut des cellules ; (iv) structure fidèle au rapport précédent ; (v) sections \og Avis, Points de vigilance, Recommandations\fg{} regroupées en une même cellule.}
+
+\end{document}

docs/presentations/autre/WinterSchoolGDRCyber2026/convergence_hc.tex

@@ -0,0 +1,41 @@
+\resizebox{\columnwidth}{!}{
+    \begin{tikzpicture}[
+        roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,},
+        ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,},
+        arrow/.style={|->, thick,},
+        message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}},
+        ]
+
+        \node[roundnode] (11) {};
+        \node[left] at (11.west) {$p_0$};
+        \node[above] at (11.north) {$w(1)$};
+        \node[roundnode] (12) [right=of 11] {};
+        \node[above] at (12.north) {$I(a)$};
+        \node[roundnode] (13) [right=of 12] {};
+        \node[above] at (13.north) {$r/(0,1)$};
+        \node[roundnode] (14) [right=35pt of 13] {};
+        \node[above] at (14.north) {$r/(1,2)^w$};
+
+        \draw[arrow] (11) -- (12);
+        \draw[arrow] (12) -- (13);
+        \draw[arrow] (13) -- (14);
+
+        \node[roundnode] (21) [below=of 11] {};
+        \node[left] at (21.west) {$p_1$};
+        \node[below] at (21.south) {$w(2)$};
+        \node[roundnode] (22) [right=of 21] {};
+        \node[below] at (22.south) {$R/\emptyset$};
+        \node[roundnode] (23) [right=of 22] {};
+        \node[below] at (23.south) {$r/(0,2)$};
+        \node[roundnode] (24) [right=35pt of 23] {};
+        \node[below] at (24.south) {$r/(1,2)^w$};
+
+        \draw[arrow] (21) -- (22);
+        \draw[arrow] (22) -- (23);
+        \draw[arrow] (23) -- (24);
+
+        \draw (24) -- (14);
+
+        \draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -3.5);
+    \end{tikzpicture}
+}

docs/presentations/autre/WinterSchoolGDRCyber2026/images/logo-amu.svg

@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg id="Calque_2" data-name="Calque 2" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 272.51 118.06">
+  <defs>
+    <style>
+      .cls-1 {
+        fill: #fff;
+        stroke-width: 0px;
+      }
+    </style>
+  </defs>
+  <g id="Calque_1-2" data-name="Calque 1-2">
+    <g>
+      <path class="cls-1" d="M66.58,96.69c-2.35.41-4.83.55-7.73.55-7.6,0-11.74-3.59-12.43-10.77-3.87,7.87-11.6,11.88-23.2,11.88S0,91.57,0,78.45c0-14.23,11.05-18.79,23.48-21.13l22.79-4.42c0-6.77-.28-9.94-2.35-12.57-1.8-2.76-6.49-4.56-12.57-4.56-12.02,0-16.85,4.42-16.85,14.92l-12.15-1.66c.41-8.29,3.18-14.5,8.56-17.96,4.97-3.31,12.29-5.11,21.13-5.11,17.27,0,26.24,7.73,26.24,22.79v33.01c0,4.01.14,5.25,4.01,5.25,1.1,0,2.49-.14,4.01-.55l.28,10.22h0ZM46.28,62.16l-20.86,4.56c-8.01,1.79-12.71,4.01-12.71,11.6,0,6.22,5.39,10.08,12.43,10.08,14.36,0,21.13-7.18,21.13-17.82v-8.43h0Z"/>
+      <path class="cls-1" d="M180.52,96.69h-12.71v-40.61c0-8.15-.14-11.88-4.14-16.02-3.32-3.32-7.32-3.87-11.6-3.87-4.01,0-7.46,1.24-10.22,3.73-4.01,3.45-6.35,8.56-6.35,18.65v38.12h-12.71v-40.61c0-8.15-.14-11.88-4.14-16.02-3.31-3.32-7.6-3.87-11.6-3.87s-7.32,1.24-10.22,3.73c-3.87,3.45-6.35,8.56-6.35,18.65v38.12h-12.29V27.62h12.29v10.5c.97-2.62,2.76-4.97,5.11-6.91,4.28-3.45,9.67-5.25,16.16-5.25,10.91,0,18.78,5.25,22.1,14.64,1.52-3.73,3.45-6.49,6.63-9.39,3.87-3.32,8.43-5.25,16.16-5.25,15.47,0,23.89,8.84,23.89,25.97v44.75h0Z"/>
+      <path class="cls-1" d="M196.96,0h12.57v64.78c0,14.92,11.33,22.51,25.14,22.51s25.28-7.6,25.28-22.51V0h12.57v64.78c0,21.69-13.4,33.56-37.85,33.56s-37.71-11.88-37.71-33.56V0h0Z"/>
+    </g>
+    <g>
+      <path class="cls-1" d="M10,114.14h-5.27l-1.37,3.71h-1.7l4.86-12.42h1.7l4.84,12.42h-1.69l-1.38-3.71h0ZM9.47,112.72l-1.4-3.74c-.28-.75-.51-1.42-.71-2h-.02c-.16.51-.39,1.17-.69,2l-1.38,3.74h4.21-.01Z"/>
+      <path class="cls-1" d="M14.29,105.43h1.6v1.88h-1.6v-1.88ZM14.29,108.98h1.6v8.87h-1.6v-8.87Z"/>
+      <path class="cls-1" d="M25.45,117.85h-1.72l-1.47-2.09c-.25-.37-.5-.76-.76-1.21l-.2-.3c-.41.66-.73,1.17-.98,1.51l-1.47,2.09h-1.72l3.32-4.63-3.05-4.24h1.72l1.44,2,.75,1.15.16-.23c.14-.23.34-.53.6-.92l1.4-2h1.74l-3.09,4.24,3.34,4.63h-.01Z"/>
+      <path class="cls-1" d="M78.17,105.43h2.32l2.63,7.03c.51,1.37.94,2.55,1.28,3.6h.02c.39-1.19.82-2.38,1.26-3.6l2.63-7.03h2.32v12.42h-1.58v-7.51c0-.3,0-.75.02-1.29l.07-1.54h-.02c-.46,1.33-.8,2.29-1.01,2.84l-2.89,7.51h-1.63l-2.89-7.51c-.16-.41-.5-1.35-1.01-2.84h-.02l.05,1.54c.02.55.04.99.04,1.29v7.51h-1.58v-12.42h0Z"/>
+      <path class="cls-1" d="M101.14,117.85c-.3.05-.62.07-.99.07-.98,0-1.51-.46-1.6-1.38-.5,1.01-1.49,1.53-2.98,1.53s-2.98-.87-2.98-2.56c0-1.83,1.42-2.41,3.02-2.71l2.93-.57c0-.87-.04-1.28-.3-1.62-.23-.36-.83-.59-1.61-.59-1.54,0-2.17.57-2.17,1.92l-1.56-.21c.05-1.07.41-1.86,1.1-2.31.64-.43,1.58-.66,2.71-.66,2.22,0,3.37.99,3.37,2.93v4.24c0,.51.02.67.51.67.14,0,.32-.02.51-.07l.04,1.31h0ZM98.53,113.41l-2.68.59c-1.03.23-1.63.51-1.63,1.49,0,.8.69,1.3,1.6,1.3,1.85,0,2.72-.92,2.72-2.29v-1.08h-.01Z"/>
+      <path class="cls-1" d="M107.55,110.27c-.07-.02-.21-.02-.41-.02-1.81,0-2.91.62-2.91,3.39v4.21h-1.6v-8.87h1.6v1.56c.25-.87,1.35-1.65,2.77-1.76.09-.02.28-.02.59-.02l-.04,1.51h0Z"/>
+      <path class="cls-1" d="M109.5,114.8c0,1.24.87,2.01,2.27,2.01,1.47,0,2.18-.5,2.18-1.44-.07-.82-.8-.98-2.15-1.3l-.71-.16c-1.76-.48-2.77-.85-2.86-2.56,0-1.77,1.62-2.59,3.28-2.59,2.06,0,3.55.87,3.71,2.91l-1.49.23c-.02-1.21-.82-1.88-2.24-1.88-.89,0-1.77.44-1.77,1.22.09.78.8.98,2.13,1.28l.21.05c.76.16,1.35.32,1.79.48.91.3,1.6.96,1.6,2.22,0,.99-.35,1.7-1.05,2.15-.69.43-1.56.64-2.61.64-2.08,0-3.76-.98-3.76-3.12l1.46-.14h.01Z"/>
+      <path class="cls-1" d="M125.2,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.32-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37ZM118.49,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58Z"/>
+      <path class="cls-1" d="M127.01,105.43h1.6v1.88h-1.6v-1.88ZM127.01,108.98h1.6v8.87h-1.6v-8.87Z"/>
+      <path class="cls-1" d="M130.94,105.43h1.6v12.42h-1.6v-12.42Z"/>
+      <path class="cls-1" d="M134.88,105.43h1.6v12.42h-1.6v-12.42Z"/>
+      <path class="cls-1" d="M146.77,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.32-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37h0ZM140.06,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58h0Z"/>
+      <path class="cls-1" d="M196.95,105.43h1.62v8.32c0,1.92,1.46,2.89,3.23,2.89s3.25-.98,3.25-2.89v-8.32h1.61v8.32c0,2.79-1.72,4.31-4.86,4.31s-4.84-1.53-4.84-4.31v-8.32h0Z"/>
+      <path class="cls-1" d="M216.59,117.85h-1.65v-5.18c0-1.06-.02-1.49-.53-2.06-.44-.44-.92-.51-1.58-.51-.59,0-1.12.2-1.6.6-.48.39-.71,1.14-.71,2.25v4.9h-1.6v-8.87h1.6v1.37c.46-1.05,1.37-1.58,2.73-1.58,1.15,0,2,.3,2.64.99.66.76.69,1.61.69,2.82v5.27h.01Z"/>
+      <path class="cls-1" d="M218.84,105.43h1.6v1.88h-1.6v-1.88ZM218.84,108.98h1.6v8.87h-1.6v-8.87Z"/>
+      <path class="cls-1" d="M221.74,108.98h1.7l1.58,4.6c.2.51.48,1.46.89,2.8.32-1.07.62-2.01.91-2.8l1.6-4.6h1.67l-3.32,8.87h-1.7l-3.32-8.87h0Z"/>
+      <path class="cls-1" d="M238.96,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.33-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37h0ZM232.25,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58h0Z"/>
+      <path class="cls-1" d="M245.69,110.27c-.07-.02-.21-.02-.41-.02-1.81,0-2.91.62-2.91,3.39v4.21h-1.6v-8.87h1.6v1.56c.25-.87,1.35-1.65,2.77-1.76.09-.02.28-.02.59-.02l-.04,1.51Z"/>
+      <path class="cls-1" d="M247.64,114.8c0,1.24.87,2.01,2.27,2.01,1.47,0,2.18-.5,2.18-1.44-.07-.82-.8-.98-2.15-1.3l-.71-.16c-1.76-.48-2.77-.85-2.86-2.56,0-1.77,1.62-2.59,3.28-2.59,2.06,0,3.55.87,3.71,2.91l-1.49.23c-.02-1.21-.82-1.88-2.24-1.88-.89,0-1.78.44-1.78,1.22.09.78.8.98,2.13,1.28l.21.05c.76.16,1.35.32,1.79.48.91.3,1.6.96,1.6,2.22,0,.99-.35,1.7-1.05,2.15-.69.43-1.56.64-2.61.64-2.08,0-3.76-.98-3.76-3.12l1.46-.14h.02Z"/>
+      <path class="cls-1" d="M255.39,105.43h1.6v1.88h-1.6v-1.88h0ZM255.39,108.98h1.6v8.87h-1.6v-8.87h0Z"/>
+      <path class="cls-1" d="M259.82,110.31h-1.28v-1.33h1.28v-2.47h1.58v2.47h1.81v1.33h-1.81v5.5c0,.57.23.69.92.69.21,0,.48-.04.82-.09l.04,1.44c-.39.05-.71.09-.98.09-1.65,0-2.38-.64-2.38-2.08v-5.55Z"/>
+      <path class="cls-1" d="M272.47,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.32-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37h0ZM265.76,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58ZM268.63,105.42h1.79l-1.63,2.25h-1.31l1.15-2.25Z"/>
+    </g>
+  </g>
+</svg>

docs/presentations/autre/WinterSchoolGDRCyber2026/images/logo-lis-2024.svg

@@ -0,0 +1,37 @@
+<?xml version="1.0"?>
+<svg width="660" height="510" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMid meet" version="1.0">
+ <defs id="defs939">
+  <rect height="39.84" id="rect1474" width="107.41" x="416.03" y="533.27"/>
+ </defs>
+ <metadata id="metadata887">Created by potrace 1.16, written by Peter Selinger 2001-2019image/svg+xml</metadata>
+ <g class="layer">
+  <title>Layer 1</title>
+  <g fill="#000000" id="g933" transform="matrix(0.1, 0, 0, -0.1, -2.91941e-08, 784)">
+   <path d="m80,6590l0,-1190l735,0l735,0l0,225l0,225l-510,0l-510,0l0,965l0,965l-225,0l-225,0l0,-1190z" id="path889"/>
+   <path d="m4780,7270l0,-510l220,0l220,0l0,290l0,290l515,0l515,0l0,220l0,220l-735,0l-735,0l0,-510z" id="path891"/>
+   <path d="m2940,6085l0,-685l225,0l225,0l0,685l0,685l-225,0l-225,0l0,-685z" id="path893"/>
+   <path d="m5800,6310l0,-460l-510,0l-510,0l0,-225l0,-225l735,0l735,0l0,685l0,685l-225,0l-225,0l0,-460z" id="path895"/>
+   <path d="m6410,2980l0,-70l-135,0l-135,0l0,-60l0,-60l195,0l195,0l0,130l0,130l-60,0l-60,0l0,-70z" id="path931"/>
+  </g>
+  <text fill="#000000" font-family="sans-serif" font-size="30px" font-style="normal" font-weight="normal" id="text1544" stroke-width="0.75" x="359.79" xml:space="preserve" y="543.86"/>
+  <g id="g1632">
+   <text fill="#73c6cb" font-family="sans-serif" font-size="30px" font-style="normal" font-weight="normal" id="text1540" letter-spacing="12.58px" stroke-width="0.75" x="288.59" xml:space="preserve" y="339.91">
+    <tspan dx="0 0 0 2.8299999 1.16 0 -1.11 0.51999998 0 0.73000008 -2.25" fill="#73c6cb" font-family="&#x27;Avenir Next&#x27;, &#x27;Avenir Next LT Pro&#x27;, sans-serif" font-style="normal" font-weight="bold" id="tspan1538" stroke-width="0.75" x="288.59" y="339.91">LABORATOIRE</tspan>
+   </text>
+   <rect fill="#73c6cb" height="60.02" id="rect1534" opacity="1" stroke-linejoin="round" stroke-width="0.31" width="45.01" x="293.36" y="6.69"/>
+   <rect fill="#73c6cb" height="12.87" id="rect1536" opacity="1" stroke-linejoin="round" stroke-width="0.29" width="12" x="641" y="468.13"/>
+   <text fill="#888888" fill-opacity="0.97" font-family="sans-serif" font-size="24.2px" font-style="normal" font-weight="normal" id="text1578" stroke-width="0.6" x="479.48" xml:space="preserve" y="506.07">
+    <tspan dx="0 1.62 1.84 0 -1.1900001 0 0.20999999 -0.19" fill="#888888" fill-opacity="0.97" id="tspan1576" stroke-width="0.6" x="479.48" y="506.07">UMR 7020</tspan>
+   </text>
+   <g id="g877" transform="translate(6)">
+    <text fill="#000000" font-family="sans-serif" font-size="30px" font-style="normal" font-weight="normal" id="text1572" letter-spacing="10.99px" stroke-width="0.77" transform="translate(449.685, -4.02411) scale(0.97553, 1.02508)" x="-106.04" xml:space="preserve" y="434.98">
+     <tspan dx="-101 0 0 0 0 0 0 3.6500001 2.2551844 1.2095989" fill="#000000" font-family="&#x27;Avenir Next&#x27;, &#x27;Avenir Next LT Pro&#x27;, sans-serif" font-size="30px" id="tspan1570" stroke-width="0.77" x="-114.04" y="434.98">&amp; DES SYSTÈMES</tspan>
+    </text>
+    <text fill="#000000" font-family="sans-serif" font-size="30.3px" font-style="normal" font-weight="normal" id="text1540-5" letter-spacing="11.23px" stroke-width="0.77" transform="translate(449.685, -4.02411) scale(0.975654, 1.02495)" x="-248.22" xml:space="preserve" y="386.02">
+     <tspan dx="0 1.25 0 0.15000001 2.3599999 3.6400001 2.6099999 1.1799999 3.26 0 0 -0.46000001 3.27 0.94" fill="#000000" font-family="&#x27;Avenir Next&#x27;, &#x27;Avenir Next LT Pro&#x27;, sans-serif" font-size="30.3px" font-style="normal" font-weight="normal" id="tspan1538-1" stroke-width="0.77" x="-248.22" y="386.02">D&#x27;INFORMATIQUE</tspan>
+    </text>
+   </g>
+   <text font-family="sans-serif" font-size="30px" id="text1472" letter-spacing="9.19px" x="289.68" xml:space="preserve" y="-139.02"/>
+  </g>
+ </g>
+</svg>

docs/presentations/autre/WinterSchoolGDRCyber2026/images/logo_AMU.svg

@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg id="Calque_2" data-name="Calque 2" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 272.51 118.06">
+  <defs>
+    <style>
+      .cls-1 {
+        fill: #1e64de;
+        stroke-width: 0px;
+      }
+    </style>
+  </defs>
+  <g id="Calque_1-2" data-name="Calque 1-2">
+    <g>
+      <path class="cls-1" d="M66.58,96.69c-2.35.41-4.83.55-7.73.55-7.6,0-11.74-3.59-12.43-10.77-3.87,7.87-11.6,11.88-23.2,11.88S0,91.57,0,78.45c0-14.23,11.05-18.79,23.48-21.13l22.79-4.42c0-6.77-.28-9.94-2.35-12.57-1.8-2.76-6.49-4.56-12.57-4.56-12.02,0-16.85,4.42-16.85,14.92l-12.15-1.66c.41-8.29,3.18-14.5,8.56-17.96,4.97-3.31,12.29-5.11,21.13-5.11,17.27,0,26.24,7.73,26.24,22.79v33.01c0,4.01.14,5.25,4.01,5.25,1.1,0,2.49-.14,4.01-.55l.28,10.22h0ZM46.28,62.16l-20.86,4.56c-8.01,1.79-12.71,4.01-12.71,11.6,0,6.22,5.39,10.08,12.43,10.08,14.36,0,21.13-7.18,21.13-17.82v-8.43h0Z"/>
+      <path class="cls-1" d="M180.52,96.69h-12.71v-40.61c0-8.15-.14-11.88-4.14-16.02-3.32-3.32-7.32-3.87-11.6-3.87-4.01,0-7.46,1.24-10.22,3.73-4.01,3.45-6.35,8.56-6.35,18.65v38.12h-12.71v-40.61c0-8.15-.14-11.88-4.14-16.02-3.31-3.32-7.6-3.87-11.6-3.87s-7.32,1.24-10.22,3.73c-3.87,3.45-6.35,8.56-6.35,18.65v38.12h-12.29V27.62h12.29v10.5c.97-2.62,2.76-4.97,5.11-6.91,4.28-3.45,9.67-5.25,16.16-5.25,10.91,0,18.78,5.25,22.1,14.64,1.52-3.73,3.45-6.49,6.63-9.39,3.87-3.32,8.43-5.25,16.16-5.25,15.47,0,23.89,8.84,23.89,25.97v44.75h0Z"/>
+      <path class="cls-1" d="M196.96,0h12.57v64.78c0,14.92,11.33,22.51,25.14,22.51s25.28-7.6,25.28-22.51V0h12.57v64.78c0,21.69-13.4,33.56-37.85,33.56s-37.71-11.88-37.71-33.56V0h0Z"/>
+    </g>
+    <g>
+      <path class="cls-1" d="M10,114.14h-5.27l-1.37,3.71h-1.7l4.86-12.42h1.7l4.84,12.42h-1.69l-1.38-3.71h0ZM9.47,112.72l-1.4-3.74c-.28-.75-.51-1.42-.71-2h-.02c-.16.51-.39,1.17-.69,2l-1.38,3.74h4.21-.01Z"/>
+      <path class="cls-1" d="M14.29,105.43h1.6v1.88h-1.6v-1.88ZM14.29,108.98h1.6v8.87h-1.6v-8.87Z"/>
+      <path class="cls-1" d="M25.45,117.85h-1.72l-1.47-2.09c-.25-.37-.5-.76-.76-1.21l-.2-.3c-.41.66-.73,1.17-.98,1.51l-1.47,2.09h-1.72l3.32-4.63-3.05-4.24h1.72l1.44,2,.75,1.15.16-.23c.14-.23.34-.53.6-.92l1.4-2h1.74l-3.09,4.24,3.34,4.63h-.01Z"/>
+      <path class="cls-1" d="M78.17,105.43h2.32l2.63,7.03c.51,1.37.94,2.55,1.28,3.6h.02c.39-1.19.82-2.38,1.26-3.6l2.63-7.03h2.32v12.42h-1.58v-7.51c0-.3,0-.75.02-1.29l.07-1.54h-.02c-.46,1.33-.8,2.29-1.01,2.84l-2.89,7.51h-1.63l-2.89-7.51c-.16-.41-.5-1.35-1.01-2.84h-.02l.05,1.54c.02.55.04.99.04,1.29v7.51h-1.58v-12.42h0Z"/>
+      <path class="cls-1" d="M101.14,117.85c-.3.05-.62.07-.99.07-.98,0-1.51-.46-1.6-1.38-.5,1.01-1.49,1.53-2.98,1.53s-2.98-.87-2.98-2.56c0-1.83,1.42-2.41,3.02-2.71l2.93-.57c0-.87-.04-1.28-.3-1.62-.23-.36-.83-.59-1.61-.59-1.54,0-2.17.57-2.17,1.92l-1.56-.21c.05-1.07.41-1.86,1.1-2.31.64-.43,1.58-.66,2.71-.66,2.22,0,3.37.99,3.37,2.93v4.24c0,.51.02.67.51.67.14,0,.32-.02.51-.07l.04,1.31h0ZM98.53,113.41l-2.68.59c-1.03.23-1.63.51-1.63,1.49,0,.8.69,1.3,1.6,1.3,1.85,0,2.72-.92,2.72-2.29v-1.08h-.01Z"/>
+      <path class="cls-1" d="M107.55,110.27c-.07-.02-.21-.02-.41-.02-1.81,0-2.91.62-2.91,3.39v4.21h-1.6v-8.87h1.6v1.56c.25-.87,1.35-1.65,2.77-1.76.09-.02.28-.02.59-.02l-.04,1.51h0Z"/>
+      <path class="cls-1" d="M109.5,114.8c0,1.24.87,2.01,2.27,2.01,1.47,0,2.18-.5,2.18-1.44-.07-.82-.8-.98-2.15-1.3l-.71-.16c-1.76-.48-2.77-.85-2.86-2.56,0-1.77,1.62-2.59,3.28-2.59,2.06,0,3.55.87,3.71,2.91l-1.49.23c-.02-1.21-.82-1.88-2.24-1.88-.89,0-1.77.44-1.77,1.22.09.78.8.98,2.13,1.28l.21.05c.76.16,1.35.32,1.79.48.91.3,1.6.96,1.6,2.22,0,.99-.35,1.7-1.05,2.15-.69.43-1.56.64-2.61.64-2.08,0-3.76-.98-3.76-3.12l1.46-.14h.01Z"/>
+      <path class="cls-1" d="M125.2,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.32-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37ZM118.49,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58Z"/>
+      <path class="cls-1" d="M127.01,105.43h1.6v1.88h-1.6v-1.88ZM127.01,108.98h1.6v8.87h-1.6v-8.87Z"/>
+      <path class="cls-1" d="M130.94,105.43h1.6v12.42h-1.6v-12.42Z"/>
+      <path class="cls-1" d="M134.88,105.43h1.6v12.42h-1.6v-12.42Z"/>
+      <path class="cls-1" d="M146.77,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.32-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37h0ZM140.06,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58h0Z"/>
+      <path class="cls-1" d="M196.95,105.43h1.62v8.32c0,1.92,1.46,2.89,3.23,2.89s3.25-.98,3.25-2.89v-8.32h1.61v8.32c0,2.79-1.72,4.31-4.86,4.31s-4.84-1.53-4.84-4.31v-8.32h0Z"/>
+      <path class="cls-1" d="M216.59,117.85h-1.65v-5.18c0-1.06-.02-1.49-.53-2.06-.44-.44-.92-.51-1.58-.51-.59,0-1.12.2-1.6.6-.48.39-.71,1.14-.71,2.25v4.9h-1.6v-8.87h1.6v1.37c.46-1.05,1.37-1.58,2.73-1.58,1.15,0,2,.3,2.64.99.66.76.69,1.61.69,2.82v5.27h.01Z"/>
+      <path class="cls-1" d="M218.84,105.43h1.6v1.88h-1.6v-1.88ZM218.84,108.98h1.6v8.87h-1.6v-8.87Z"/>
+      <path class="cls-1" d="M221.74,108.98h1.7l1.58,4.6c.2.51.48,1.46.89,2.8.32-1.07.62-2.01.91-2.8l1.6-4.6h1.67l-3.32,8.87h-1.7l-3.32-8.87h0Z"/>
+      <path class="cls-1" d="M238.96,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.33-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37h0ZM232.25,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58h0Z"/>
+      <path class="cls-1" d="M245.69,110.27c-.07-.02-.21-.02-.41-.02-1.81,0-2.91.62-2.91,3.39v4.21h-1.6v-8.87h1.6v1.56c.25-.87,1.35-1.65,2.77-1.76.09-.02.28-.02.59-.02l-.04,1.51Z"/>
+      <path class="cls-1" d="M247.64,114.8c0,1.24.87,2.01,2.27,2.01,1.47,0,2.18-.5,2.18-1.44-.07-.82-.8-.98-2.15-1.3l-.71-.16c-1.76-.48-2.77-.85-2.86-2.56,0-1.77,1.62-2.59,3.28-2.59,2.06,0,3.55.87,3.71,2.91l-1.49.23c-.02-1.21-.82-1.88-2.24-1.88-.89,0-1.78.44-1.78,1.22.09.78.8.98,2.13,1.28l.21.05c.76.16,1.35.32,1.79.48.91.3,1.6.96,1.6,2.22,0,.99-.35,1.7-1.05,2.15-.69.43-1.56.64-2.61.64-2.08,0-3.76-.98-3.76-3.12l1.46-.14h.02Z"/>
+      <path class="cls-1" d="M255.39,105.43h1.6v1.88h-1.6v-1.88h0ZM255.39,108.98h1.6v8.87h-1.6v-8.87h0Z"/>
+      <path class="cls-1" d="M259.82,110.31h-1.28v-1.33h1.28v-2.47h1.58v2.47h1.81v1.33h-1.81v5.5c0,.57.23.69.92.69.21,0,.48-.04.82-.09l.04,1.44c-.39.05-.71.09-.98.09-1.65,0-2.38-.64-2.38-2.08v-5.55Z"/>
+      <path class="cls-1" d="M272.47,113.89h-6.73c.05,1.97.87,2.89,2.52,2.89,1.51,0,2.32-.64,2.54-1.99l1.54.12c-.41,2.06-1.79,3.14-4.06,3.14-1.38,0-2.45-.43-3.19-1.29-.73-.8-1.08-1.93-1.08-3.37,0-1.33.39-2.47,1.12-3.3.78-.87,1.86-1.33,3.14-1.33,1.42,0,2.75.62,3.46,1.76.48.76.76,1.86.76,3,0,.16,0,.28-.02.37h0ZM265.76,112.59h5.08c-.02-.5-.2-1.17-.48-1.58-.44-.66-1.1-.96-2.08-.96s-1.74.37-2.09.96c-.28.5-.41,1.06-.43,1.58ZM268.63,105.42h1.79l-1.63,2.25h-1.31l1.15-2.25Z"/>
+    </g>
+  </g>
+</svg>

docs/presentations/autre/WinterSchoolGDRCyber2026/images/logo_dalgo.svg

@@ -0,0 +1,128 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="71pt" height="19pt" viewBox="0 0 71 19" version="1.1">
+<defs>
+<g>
+<symbol overflow="visible" id="glyph0-0">
+<path style="stroke:none;" d="M 0.75 0 L 4.46875 0 L 4.46875 -5.3125 L 0.75 -5.3125 Z M 4.078125 -4.90625 L 4.078125 -0.703125 L 1.375 -4.90625 Z M 1.140625 -4.59375 L 3.84375 -0.390625 L 1.140625 -0.390625 Z M 1.140625 -4.59375 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-1">
+<path style="stroke:none;" d="M 1.3125 0 L 1.3125 -3.875 L 0.640625 -3.875 L 0.640625 0 Z M 1.3125 -4.5 L 1.3125 -5.46875 L 0.640625 -5.46875 L 0.640625 -4.5 Z M 1.3125 -4.5 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-2">
+<path style="stroke:none;" d="M 3.046875 -1.046875 C 3.046875 -1.8125 2.96875 -1.953125 1.84375 -2.234375 C 1.1875 -2.390625 1.1875 -2.46875 1.1875 -2.90625 C 1.1875 -3.25 1.265625 -3.390625 1.84375 -3.390625 C 2.15625 -3.390625 2.59375 -3.34375 2.921875 -3.28125 L 2.96875 -3.828125 C 2.640625 -3.90625 2.234375 -3.953125 1.859375 -3.953125 C 0.84375 -3.953125 0.53125 -3.640625 0.53125 -2.921875 C 0.53125 -2.109375 0.609375 -1.90625 1.578125 -1.671875 C 2.359375 -1.484375 2.390625 -1.4375 2.390625 -1.015625 C 2.390625 -0.609375 2.28125 -0.5 1.671875 -0.5 C 1.34375 -0.5 0.90625 -0.5625 0.5625 -0.65625 L 0.484375 -0.125 C 0.78125 -0.015625 1.3125 0.078125 1.71875 0.078125 C 2.828125 0.078125 3.046875 -0.28125 3.046875 -1.046875 Z M 3.046875 -1.046875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-3">
+<path style="stroke:none;" d="M 2.578125 -0.578125 C 2.328125 -0.515625 2.140625 -0.484375 1.953125 -0.484375 C 1.59375 -0.484375 1.546875 -0.625 1.546875 -0.921875 L 1.546875 -3.328125 L 2.59375 -3.328125 L 2.65625 -3.875 L 1.546875 -3.875 L 1.546875 -4.9375 L 0.890625 -4.84375 L 0.890625 -3.875 L 0.203125 -3.875 L 0.203125 -3.328125 L 0.890625 -3.328125 L 0.890625 -0.8125 C 0.890625 -0.15625 1.1875 0.078125 1.84375 0.078125 C 2.140625 0.078125 2.421875 0.03125 2.65625 -0.0625 Z M 2.578125 -0.578125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-4">
+<path style="stroke:none;" d="M 2.328125 -3.953125 C 1.9375 -3.796875 1.546875 -3.5625 1.265625 -3.34375 L 1.21875 -3.875 L 0.640625 -3.875 L 0.640625 0 L 1.3125 0 L 1.3125 -2.671875 C 1.625 -2.90625 2.046875 -3.171875 2.421875 -3.34375 Z M 2.328125 -3.953125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-5">
+<path style="stroke:none;" d="M 3.671875 -2.75 C 3.671875 -3.484375 3.34375 -3.953125 2.53125 -3.953125 C 2.046875 -3.953125 1.578125 -3.828125 1.3125 -3.6875 L 1.3125 -5.5625 L 0.640625 -5.46875 L 0.640625 -0.078125 C 1.078125 0.03125 1.671875 0.078125 2.03125 0.078125 C 3.359375 0.078125 3.671875 -0.484375 3.671875 -1.375 Z M 1.3125 -3.078125 C 1.5625 -3.203125 2.03125 -3.375 2.375 -3.375 C 2.828125 -3.375 3 -3.171875 3 -2.765625 L 3 -1.34375 C 3 -0.828125 2.859375 -0.515625 2.078125 -0.515625 C 1.828125 -0.515625 1.5625 -0.53125 1.3125 -0.5625 Z M 1.3125 -3.078125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-6">
+<path style="stroke:none;" d="M 0.59375 -3.875 L 0.59375 -0.90625 C 0.59375 -0.3125 0.828125 0.078125 1.4375 0.078125 C 1.90625 0.078125 2.578125 -0.125 3 -0.328125 L 3.0625 0 L 3.609375 0 L 3.609375 -3.875 L 2.9375 -3.875 L 2.9375 -0.953125 C 2.53125 -0.734375 1.921875 -0.5625 1.640625 -0.5625 C 1.390625 -0.5625 1.265625 -0.65625 1.265625 -0.921875 L 1.265625 -3.875 Z M 0.59375 -3.875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-7">
+<path style="stroke:none;" d="M 1.109375 -1.359375 L 1.109375 -1.6875 L 3.421875 -1.6875 L 3.421875 -2.5 C 3.421875 -3.296875 3.109375 -3.953125 1.953125 -3.953125 C 0.8125 -3.953125 0.4375 -3.3125 0.4375 -2.515625 L 0.4375 -1.34375 C 0.4375 -0.46875 0.828125 0.078125 1.96875 0.078125 C 2.46875 0.078125 2.984375 -0.015625 3.34375 -0.140625 L 3.265625 -0.671875 C 2.84375 -0.5625 2.421875 -0.5 2.03125 -0.5 C 1.28125 -0.5 1.109375 -0.734375 1.109375 -1.359375 Z M 1.109375 -2.5625 C 1.109375 -3.09375 1.328125 -3.40625 1.953125 -3.40625 C 2.59375 -3.40625 2.765625 -3.09375 2.765625 -2.5625 L 2.765625 -2.234375 L 1.109375 -2.234375 Z M 1.109375 -2.5625 "/>
+</symbol>
+<symbol overflow="visible" id="glyph0-8">
+<path style="stroke:none;" d="M 0.5 -1.109375 C 0.5 -0.328125 0.859375 0.078125 1.625 0.078125 C 2.140625 0.078125 2.59375 -0.09375 2.90625 -0.34375 L 2.96875 0 L 3.53125 0 L 3.53125 -5.5625 L 2.859375 -5.46875 L 2.859375 -3.84375 C 2.546875 -3.90625 2.09375 -3.953125 1.75 -3.953125 C 0.84375 -3.953125 0.5 -3.46875 0.5 -2.6875 Z M 2.859375 -0.96875 C 2.578125 -0.71875 2.140625 -0.515625 1.765625 -0.515625 C 1.296875 -0.515625 1.15625 -0.703125 1.15625 -1.109375 L 1.15625 -2.6875 C 1.15625 -3.15625 1.34375 -3.375 1.796875 -3.375 C 2.0625 -3.375 2.5 -3.328125 2.859375 -3.25 Z M 2.859375 -0.96875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph1-0">
+<path style="stroke:none;" d="M 1.359375 0 L 8.046875 0 L 8.046875 -9.546875 L 1.359375 -9.546875 Z M 7.34375 -8.828125 L 7.34375 -1.28125 L 2.46875 -8.828125 Z M 2.0625 -8.265625 L 6.921875 -0.703125 L 2.0625 -0.703125 Z M 2.0625 -8.265625 "/>
+</symbol>
+<symbol overflow="visible" id="glyph1-1">
+<path style="stroke:none;" d="M 5.296875 -9.546875 L 3.625 -9.546875 L 0.40625 0 L 1.65625 0 L 2.421875 -2.296875 L 6.484375 -2.296875 L 7.265625 0 L 8.515625 0 Z M 6.171875 -3.375 L 2.75 -3.375 L 4.453125 -8.65625 Z M 6.171875 -3.375 "/>
+</symbol>
+<symbol overflow="visible" id="glyph1-2">
+<path style="stroke:none;" d="M 2.453125 -9.546875 L 1.21875 -9.546875 L 1.21875 0 L 6.59375 0 L 6.59375 -1.109375 L 2.453125 -1.109375 Z M 2.453125 -9.546875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph1-3">
+<path style="stroke:none;" d="M 2.234375 -6.8125 C 2.234375 -8.109375 2.71875 -8.578125 4.28125 -8.578125 C 5.078125 -8.578125 5.9375 -8.484375 6.859375 -8.328125 L 7 -9.390625 C 6.109375 -9.59375 5.15625 -9.703125 4.34375 -9.703125 C 1.96875 -9.703125 1 -8.8125 1 -6.875 L 1 -2.671875 C 1 -0.90625 1.75 0.140625 4.1875 0.140625 C 5.171875 0.140625 6.28125 0 7.21875 -0.265625 L 7.21875 -4.390625 L 6.03125 -4.390625 L 6.03125 -1.140625 C 5.359375 -1.015625 4.734375 -0.96875 4.234375 -0.96875 C 2.59375 -0.96875 2.234375 -1.515625 2.234375 -2.734375 Z M 2.234375 -6.8125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph1-4">
+<path style="stroke:none;" d="M 7.921875 -6.796875 C 7.921875 -8.390625 6.921875 -9.703125 4.453125 -9.703125 C 2 -9.703125 1 -8.390625 1 -6.796875 L 1 -2.75 C 1 -1.15625 2 0.140625 4.453125 0.140625 C 6.921875 0.140625 7.921875 -1.15625 7.921875 -2.75 Z M 2.234375 -6.765625 C 2.234375 -7.953125 2.953125 -8.609375 4.453125 -8.609375 C 5.96875 -8.609375 6.6875 -7.953125 6.6875 -6.765625 L 6.6875 -2.78125 C 6.6875 -1.609375 5.96875 -0.953125 4.453125 -0.953125 C 2.953125 -0.953125 2.234375 -1.609375 2.234375 -2.78125 Z M 2.234375 -6.765625 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-0">
+<path style="stroke:none;" d="M 0.75 0 L 4.46875 0 L 4.46875 -5.3125 L 0.75 -5.3125 Z M 4.078125 -4.90625 L 4.078125 -0.703125 L 1.375 -4.90625 Z M 1.140625 -4.59375 L 3.84375 -0.390625 L 1.140625 -0.390625 Z M 1.140625 -4.59375 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-1">
+<path style="stroke:none;" d="M 2.328125 -3.953125 C 1.9375 -3.796875 1.546875 -3.5625 1.265625 -3.34375 L 1.21875 -3.875 L 0.640625 -3.875 L 0.640625 0 L 1.3125 0 L 1.3125 -2.671875 C 1.625 -2.90625 2.046875 -3.171875 2.421875 -3.34375 Z M 2.328125 -3.953125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-2">
+<path style="stroke:none;" d="M 1.3125 0 L 1.3125 -3.875 L 0.640625 -3.875 L 0.640625 0 Z M 1.3125 -4.5 L 1.3125 -5.46875 L 0.640625 -5.46875 L 0.640625 -4.5 Z M 1.3125 -4.5 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-3">
+<path style="stroke:none;" d="M 2.578125 -0.578125 C 2.328125 -0.515625 2.140625 -0.484375 1.953125 -0.484375 C 1.59375 -0.484375 1.546875 -0.625 1.546875 -0.921875 L 1.546875 -3.328125 L 2.59375 -3.328125 L 2.65625 -3.875 L 1.546875 -3.875 L 1.546875 -4.9375 L 0.890625 -4.84375 L 0.890625 -3.875 L 0.203125 -3.875 L 0.203125 -3.328125 L 0.890625 -3.328125 L 0.890625 -0.8125 C 0.890625 -0.15625 1.1875 0.078125 1.84375 0.078125 C 2.140625 0.078125 2.421875 0.03125 2.65625 -0.0625 Z M 2.578125 -0.578125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-4">
+<path style="stroke:none;" d="M 3.65625 0 L 3.65625 -2.96875 C 3.65625 -3.5625 3.421875 -3.953125 2.8125 -3.953125 C 2.34375 -3.953125 1.734375 -3.765625 1.3125 -3.546875 L 1.3125 -5.5625 L 0.640625 -5.46875 L 0.640625 0 L 1.3125 0 L 1.3125 -2.921875 C 1.71875 -3.140625 2.3125 -3.328125 2.609375 -3.328125 C 2.859375 -3.328125 2.984375 -3.21875 2.984375 -2.96875 L 2.984375 0 Z M 3.65625 0 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-5">
+<path style="stroke:none;" d="M 6 0 L 6 -2.96875 C 6 -3.5625 5.765625 -3.953125 5.140625 -3.953125 C 4.65625 -3.953125 4.015625 -3.765625 3.546875 -3.546875 C 3.4375 -3.8125 3.203125 -3.953125 2.8125 -3.953125 C 2.34375 -3.953125 1.671875 -3.75 1.25 -3.546875 L 1.171875 -3.875 L 0.640625 -3.875 L 0.640625 0 L 1.3125 0 L 1.3125 -2.9375 C 1.71875 -3.140625 2.3125 -3.328125 2.609375 -3.328125 C 2.859375 -3.328125 2.984375 -3.21875 2.984375 -2.96875 L 2.984375 0 L 3.65625 0 L 3.65625 -2.9375 C 4.0625 -3.140625 4.625 -3.328125 4.953125 -3.328125 C 5.203125 -3.328125 5.328125 -3.21875 5.328125 -2.96875 L 5.328125 0 Z M 6 0 "/>
+</symbol>
+<symbol overflow="visible" id="glyph2-6">
+<path style="stroke:none;" d="M 3.046875 -1.046875 C 3.046875 -1.8125 2.96875 -1.953125 1.84375 -2.234375 C 1.1875 -2.390625 1.1875 -2.46875 1.1875 -2.90625 C 1.1875 -3.25 1.265625 -3.390625 1.84375 -3.390625 C 2.15625 -3.390625 2.59375 -3.34375 2.921875 -3.28125 L 2.96875 -3.828125 C 2.640625 -3.90625 2.234375 -3.953125 1.859375 -3.953125 C 0.84375 -3.953125 0.53125 -3.640625 0.53125 -2.921875 C 0.53125 -2.109375 0.609375 -1.90625 1.578125 -1.671875 C 2.359375 -1.484375 2.390625 -1.4375 2.390625 -1.015625 C 2.390625 -0.609375 2.28125 -0.5 1.671875 -0.5 C 1.34375 -0.5 0.90625 -0.5625 0.5625 -0.65625 L 0.484375 -0.125 C 0.78125 -0.015625 1.3125 0.078125 1.71875 0.078125 C 2.828125 0.078125 3.046875 -0.28125 3.046875 -1.046875 Z M 3.046875 -1.046875 "/>
+</symbol>
+<symbol overflow="visible" id="glyph3-0">
+<path style="stroke:none;" d="M 2.359375 0 L 13.90625 0 L 13.90625 -16.5 L 2.359375 -16.5 Z M 12.6875 -15.265625 L 12.6875 -2.203125 L 4.265625 -15.265625 Z M 3.5625 -14.28125 L 11.96875 -1.21875 L 3.5625 -1.21875 Z M 3.5625 -14.28125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph3-1">
+<path style="stroke:none;" d="M 2.109375 -16.5 L 2.109375 0 L 7.875 0 C 11.921875 0 13.1875 -2.109375 13.1875 -4.734375 L 13.1875 -11.765625 C 13.1875 -14.390625 11.921875 -16.5 7.875 -16.5 Z M 4.234375 -14.59375 L 7.8125 -14.59375 C 10.3125 -14.59375 11.046875 -13.5625 11.046875 -11.625 L 11.046875 -4.875 C 11.046875 -2.953125 10.3125 -1.90625 7.8125 -1.90625 L 4.234375 -1.90625 Z M 4.234375 -14.59375 "/>
+</symbol>
+<symbol overflow="visible" id="glyph4-0">
+<path style="stroke:none;" d="M 0.75 0 L 4.46875 0 L 4.46875 -5.3125 L 0.75 -5.3125 Z M 4.078125 -4.90625 L 4.078125 -0.703125 L 1.375 -4.90625 Z M 1.140625 -4.59375 L 3.84375 -0.390625 L 1.140625 -0.390625 Z M 1.140625 -4.59375 "/>
+</symbol>
+<symbol overflow="visible" id="glyph4-1">
+<path style="stroke:none;" d="M 2.578125 -0.578125 C 2.328125 -0.515625 2.140625 -0.484375 1.953125 -0.484375 C 1.59375 -0.484375 1.546875 -0.625 1.546875 -0.921875 L 1.546875 -3.328125 L 2.59375 -3.328125 L 2.65625 -3.875 L 1.546875 -3.875 L 1.546875 -4.9375 L 0.890625 -4.84375 L 0.890625 -3.875 L 0.203125 -3.875 L 0.203125 -3.328125 L 0.890625 -3.328125 L 0.890625 -0.8125 C 0.890625 -0.15625 1.1875 0.078125 1.84375 0.078125 C 2.140625 0.078125 2.421875 0.03125 2.65625 -0.0625 Z M 2.578125 -0.578125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph4-2">
+<path style="stroke:none;" d="M 1.109375 -1.359375 L 1.109375 -1.6875 L 3.421875 -1.6875 L 3.421875 -2.5 C 3.421875 -3.296875 3.109375 -3.953125 1.953125 -3.953125 C 0.8125 -3.953125 0.4375 -3.3125 0.4375 -2.515625 L 0.4375 -1.34375 C 0.4375 -0.46875 0.828125 0.078125 1.96875 0.078125 C 2.46875 0.078125 2.984375 -0.015625 3.34375 -0.140625 L 3.265625 -0.671875 C 2.84375 -0.5625 2.421875 -0.5 2.03125 -0.5 C 1.28125 -0.5 1.109375 -0.734375 1.109375 -1.359375 Z M 1.109375 -2.5625 C 1.109375 -3.09375 1.328125 -3.40625 1.953125 -3.40625 C 2.59375 -3.40625 2.765625 -3.09375 2.765625 -2.5625 L 2.765625 -2.234375 L 1.109375 -2.234375 Z M 1.109375 -2.5625 "/>
+</symbol>
+<symbol overflow="visible" id="glyph4-3">
+<path style="stroke:none;" d="M 3.390625 -2.703125 C 3.390625 -3.53125 3.015625 -3.953125 1.90625 -3.953125 C 1.5 -3.953125 1 -3.890625 0.640625 -3.796875 L 0.703125 -3.265625 C 1.015625 -3.328125 1.5 -3.390625 1.875 -3.390625 C 2.5 -3.390625 2.71875 -3.21875 2.71875 -2.734375 L 2.71875 -2.125 L 1.6875 -2.125 C 0.90625 -2.125 0.5 -1.84375 0.5 -1.03125 C 0.5 -0.34375 0.796875 0.078125 1.515625 0.078125 C 1.984375 0.078125 2.4375 -0.046875 2.78125 -0.28125 L 2.828125 0 L 3.390625 0 Z M 2.71875 -0.8125 C 2.421875 -0.625 2.046875 -0.5 1.71875 -0.5 C 1.234375 -0.5 1.15625 -0.65625 1.15625 -1.046875 C 1.15625 -1.4375 1.3125 -1.5625 1.734375 -1.5625 L 2.71875 -1.5625 Z M 2.71875 -0.8125 "/>
+</symbol>
+<symbol overflow="visible" id="glyph4-4">
+<path style="stroke:none;" d="M 6 0 L 6 -2.96875 C 6 -3.5625 5.765625 -3.953125 5.140625 -3.953125 C 4.65625 -3.953125 4.015625 -3.765625 3.546875 -3.546875 C 3.4375 -3.8125 3.203125 -3.953125 2.8125 -3.953125 C 2.34375 -3.953125 1.671875 -3.75 1.25 -3.546875 L 1.171875 -3.875 L 0.640625 -3.875 L 0.640625 0 L 1.3125 0 L 1.3125 -2.9375 C 1.71875 -3.140625 2.3125 -3.328125 2.609375 -3.328125 C 2.859375 -3.328125 2.984375 -3.21875 2.984375 -2.96875 L 2.984375 0 L 3.65625 0 L 3.65625 -2.9375 C 4.0625 -3.140625 4.625 -3.328125 4.953125 -3.328125 C 5.203125 -3.328125 5.328125 -3.21875 5.328125 -2.96875 L 5.328125 0 Z M 6 0 "/>
+</symbol>
+</g>
+</defs>
+<g id="surface425">
+<g style="fill:rgb(100%,0%,0%);fill-opacity:1;">
+  <use xlink:href="#glyph0-1" x="15.8132" y="7.6061"/>
+  <use xlink:href="#glyph0-2" x="17.757904" y="7.6061"/>
+  <use xlink:href="#glyph0-3" x="21.256778" y="7.6061"/>
+  <use xlink:href="#glyph0-4" x="24.197745" y="7.6061"/>
+  <use xlink:href="#glyph0-1" x="26.652536" y="7.6061"/>
+  <use xlink:href="#glyph0-5" x="28.59724" y="7.6061"/>
+  <use xlink:href="#glyph0-6" x="32.733722" y="7.6061"/>
+  <use xlink:href="#glyph0-3" x="36.981786" y="7.6061"/>
+  <use xlink:href="#glyph0-7" x="39.922752" y="7.6061"/>
+  <use xlink:href="#glyph0-8" x="43.756371" y="7.6061"/>
+</g>
+<g style="fill:rgb(0%,0%,100%);fill-opacity:1;">
+  <use xlink:href="#glyph1-1" x="14.9753" y="17.8972"/>
+  <use xlink:href="#glyph1-2" x="23.898636" y="17.8972"/>
+  <use xlink:href="#glyph1-3" x="30.856543" y="17.8972"/>
+  <use xlink:href="#glyph1-4" x="39.148647" y="17.8972"/>
+</g>
+<g style="fill:rgb(0%,0%,100%);fill-opacity:1;">
+  <use xlink:href="#glyph2-1" x="47.41309" y="17.9683"/>
+  <use xlink:href="#glyph2-2" x="49.867881" y="17.9683"/>
+  <use xlink:href="#glyph2-3" x="51.812585" y="17.9683"/>
+  <use xlink:href="#glyph2-4" x="54.753552" y="17.9683"/>
+  <use xlink:href="#glyph2-5" x="59.001615" y="17.9683"/>
+  <use xlink:href="#glyph2-6" x="65.592888" y="17.9683"/>
+</g>
+<g style="fill:rgb(100%,0%,0%);fill-opacity:1;">
+  <use xlink:href="#glyph3-1" x="1.0542" y="18.4178"/>
+</g>
+<g style="fill:rgb(62.7%,12.5%,94.1%);fill-opacity:1;">
+  <use xlink:href="#glyph4-1" x="50.36293" y="9.6069"/>
+  <use xlink:href="#glyph4-2" x="53.303897" y="9.6069"/>
+  <use xlink:href="#glyph4-3" x="57.121575" y="9.6069"/>
+  <use xlink:href="#glyph4-4" x="61.050834" y="9.6069"/>
+</g>
+</g>
+</svg>

docs/presentations/autre/WinterSchoolGDRCyber2026/localiteetat_hc.tex

@@ -0,0 +1,34 @@
+\resizebox{\columnwidth}{!}{%
+    \begin{tikzpicture}[
+        roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,},
+        ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,},
+        arrow/.style={|->, thick,},
+        message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}},
+        ]
+
+        \node[roundnode, draw=red, fill=red] (11) {};
+        \node[left] at (11.west) {$p_0$};
+        \node[above] at (11.north) {$w(1)$};
+        \node[roundnode, draw=blue, fill=blue] (12) [right=of 11] {};
+        \node[above] at (12.north) {$r/(0,0)$};
+        \node[roundnode, draw=blue, fill=blue] (13) [right=of 12] {};
+        \node[above] at (13.north) {$r/(0,2)^w$};
+
+        \draw[arrow] (11) -- (12);
+        \draw[arrow] (12) -- (13);
+
+        \node[roundnode, draw=blue, fill=blue] (21) [below=of 11] {};
+        \node[left] at (21.west) {$p_1$};
+        \node[below] at (21.south) {$w(2)$};
+        \node[roundnode, draw=red, fill=red] (22) [right=of 21] {};
+        \node[below] at (22.south) {$r/(0,0)$};
+        \node[roundnode, draw=red, fill=red] (23) [right=of 22] {};
+        \node[below] at (23.south) {$r/(0,1)^w$};
+
+        \draw[arrow] (21) -- (22);
+        \draw[arrow] (22) -- (23);
+
+        \draw[message] (11) -- ($(22)!0.5!(23)$);
+        \draw[message] (21) -- ($(12)!0.5!(13)$);
+    \end{tikzpicture}
+}

docs/presentations/autre/WinterSchoolGDRCyber2026/main.tex

@@ -0,0 +1,265 @@
+\documentclass{beamer}
+\usetheme{Boadilla}
+\usecolortheme{orchid}
+
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage[french]{babel}
+\usepackage{stackengine}
+
+\addtobeamertemplate{navigation symbols}{}{%
+    \usebeamerfont{footline}%
+    \usebeamercolor[fg]{footline}%
+    \hspace{1em}%
+    \insertframenumber/\inserttotalframenumber
+}
+\usepackage{ulem}
+\usepackage{tkz-tab}
+\setbeamertemplate{blocks}[rounded]%
+[shadow=true]
+\AtBeginSection{%
+    \begin{frame}
+        \tableofcontents[sections=\value{section}]
+    \end{frame}
+}
+
+\usepackage{tikz}
+\usetikzlibrary{positioning}
+\usetikzlibrary{calc}
+\usetikzlibrary{arrows.meta}
+
+\title{Amaury JOLY - Winter School GDR Cybersécurité}
+\author{Amaury JOLY}
+\institute{Université Aix-Marseille \\ Laboratoire d'Informatique et Systèmes (LIS)}
+\date{Janvier 2026}
+
+\begin{document}
+
+\begin{frame}
+    \titlepage 
+    \vspace{-1.2em}
+
+    \begin{center}
+      \includegraphics[height=1cm]{images/logoamu}\hspace{1cm}%
+      \includegraphics[height=1.5cm]{images/logolis}\hspace{1cm}
+      \includegraphics[height=0.9cm]{images/logodalgo}\hspace{1cm}%
+      \includegraphics[height=0.6cm]{images/logoparsec}
+    \end{center}
+\end{frame}
+
+
+\begin{frame}{Who am I?}
+  \begin{itemize}
+    \item \textbf{Amaury JOLY}
+    \item 3rd-year PhD candidate at the \textbf{Laboratory of Informatics and Systems (LIS)}
+    \item \textbf{Distributed Algorithms} team
+    \item Supervised by \textbf{Emmanuel GODARD} and \textbf{Corentin TRAVERS}
+    \item \textbf{CIFRE} PhD with the company \textbf{Parsec}
+  \end{itemize}
+\end{frame}
+
+%------------------------------------------------------------
+\begin{frame}{Parsec: company \& product}
+  \begin{itemize}
+    \item \textbf{Parsec} develops an end-to-end encrypted file sharing platform
+    \item Client--server solution: users collaborate through shared workspaces
+    \item \textbf{End-to-end encryption}: the server only sees \emph{ciphertexts}
+    \item \textbf{Distributed PKI management among clients} (keys/identities handled at the edge)
+    \item \alert{one central server stores encrypted data and redistributes it to clients}
+  \end{itemize}
+\end{frame}
+
+%------------------------------------------------------------
+\begin{frame}{My topic (high level)}
+  \begin{block}{Problem statement}
+    \textit{``Weak consistency in a zero-trust cloud for real-time collaborative applications.''}
+  \end{block}
+
+  \vspace{0.4em}
+  \begin{itemize}
+    \item Real-time collaboration: concurrent updates, low latency, intermittent connectivity
+    \item We want \textbf{weak consistency} (e.g., eventual / causal behaviors) with clear semantics under concurrency
+    \item \textbf{Zero-trust cloud} (Parsec-like setting):
+      \begin{itemize}
+        \item central server trusted for \textbf{availability} only
+        \item server can be \textbf{honest-but-curious} (observes metadata, stores/forwards ciphertexts)
+        \item \textbf{no trust assumptions on clients} (they may be compromised or mutually distrustful)
+      \end{itemize}
+  \end{itemize}
+\end{frame}
+
+\begin{frame}
+    \frametitle{Our Model}
+        \begin{block}{Assumptions}
+            \begin{itemize}
+                \item The system is highly connected
+                \item The system is not partitionable
+                \item The system is asynchronous (i.e., no assumption on message delays or relative process speeds)
+                \item Nodes can fail by \textbf{crash} (i.e., stop functioning)
+                \item Nodes can be \textbf{Byzantine} (i.e., arbitrary behavior)
+                \item The communication network is reliable but byzantine nodes can delay or reorder messages
+                \item There is a Reliable Broadcast abstraction available
+            \end{itemize}
+        \end{block}
+\end{frame}
+
+\begin{frame}
+    \frametitle{Consistency classes}
+    \begin{columns}
+        \column{0.5\textwidth}
+        \resizebox{\columnwidth}{!}{
+            \includegraphics{images/carte_criteres.png}
+        }
+
+        \column{0.5\textwidth}
+        One approach to define the consistency of an algorithm is to place the concurrent history it produces into a consistency class. \\
+        We can define 3 consistency classes:
+        \begin{itemize}
+            \item \textbf{State Locality} (LS)
+            \item \textbf{Validity} (V)
+            \item \textbf{Eventual Consistency} (EC)
+        \end{itemize}
+    \end{columns}
+\end{frame}
+
+\begin{frame}
+    \frametitle{State Locality (LS)}
+
+    \begin{columns}
+        \column{0.4\textwidth}
+        \include{localiteetat_hc}
+        \column{0.6\textwidth}
+        \begin{block}{Definition}
+            For every process $p$, there exists a linearization containing all of $p$'s read operations. \\
+        \end{block}
+        \begin{math}
+            \begin{array}{ll}
+                e.g.: & \textcolor{blue}{C_{p_1} = \{r/(0,0), r/(0,2)^w, w(2)\}}, \\
+                      & \textcolor{red}{C_{p_2} = \{r/(0,0), r/(0,1)^w, w(1)\}},  \\
+                      & \textcolor{blue}{r/(0,0) \bullet w(2) \bullet r/(0,2)^w}  \\
+                      & \textcolor{red}{r/(0,0) \bullet w(1) \bullet r/(0,1)^w}   \\
+            \end{array}
+        \end{math}
+    \end{columns}
+
+
+    \begin{flushright}
+        \begin{math}
+            LS = \left\{
+            \begin{array}{l}
+                \mathcal{T} \rightarrow \mathcal{P}(\mathcal{H}) \\
+                T \rightarrow \left\{
+                \begin{tabular}{lll}
+                    $H \in \mathcal{H}:$ & \multicolumn{2}{l}{$\forall p \in \mathcal{P}_H, \exists C_p \subset E_H,$}                                                       \\
+                                         &                                                                             & $\hat{Q}_{T,H} \subset C_p$                         \\
+                                         & $\land$                                                                     & $lin(H[p \cap C_p / C_p]) \cap L(T) \neq \emptyset$ \\
+                \end{tabular}
+                \right.                                          \\
+            \end{array}
+            \right.
+        \end{math}
+    \end{flushright}
+\end{frame}
+
+
+\begin{frame}
+    \frametitle{Validity (V)}
+
+    \begin{columns}
+        \column{0.4\textwidth}
+        \include{validite_hc}
+        \column{0.6\textwidth}
+        \begin{block}{Definition}
+            There exists a co-finite set of events such that for each of them, a linearization of all write operations justifies them. \\
+        \end{block}
+        \begin{math}
+            \begin{array}{ll}
+                e.g.: & E' = \{r/(2,1)^w, r/(1,2)^w\}                        \\
+                      & w(2) \bullet w(1) \bullet \textcolor{red}{r/(2,1)^w} \\
+                      & w(1) \bullet w(2) \bullet \textcolor{red}{r/(1,2)^w} \\
+            \end{array}
+        \end{math}
+    \end{columns}
+
+
+    \begin{flushright}
+        \begin{math}
+            V = \left\{
+            \begin{array}{l}
+                \mathcal{T} \rightarrow \mathcal{P}(\mathcal{H}) \\
+                T \rightarrow \left\{
+                \begin{array}{lll}
+                    H \in \mathcal{H}: & \multicolumn{2}{l}{|U_{T,H}| = \infty}                                                                       \\
+                                       & \lor                                   & \exists E' \subset E_H, (|E_H \setminus E'| < \infty                \\
+                                       &                                        & \land \forall e \in E', lin(H[E_H / {e}]) \cap L(T) \neq \emptyset) \\
+                \end{array}
+                \right.                                          \\
+            \end{array}
+            \right.
+        \end{math}
+    \end{flushright}
+\end{frame}
+
+
+\begin{frame}
+    \frametitle{Eventual Consistency (EC)}
+
+    \begin{columns}
+        \column{0.4\textwidth}
+        \include{convergence_hc}%
+        \column{0.5\textwidth}
+        \begin{block}{Definition}
+            There exists a co-finite set of events such that for each of them, a single linearization justifies them. \\
+        \end{block}
+        \begin{math}
+            \begin{array}{ll}
+                e.g.: & E' = \{r/(1,2)^w, r/(1,2)^w\}                        \\
+                      & w(1) \bullet w(2) \bullet \textcolor{red}{r/(1,2)^w} \\
+            \end{array}
+        \end{math}
+    \end{columns}
+
+
+    \begin{flushright}
+        \begin{math}
+            EC = \left\{
+            \begin{array}{l}
+                \mathcal{T} \rightarrow \mathcal{P}(\mathcal{H}) \\
+                T \rightarrow \left\{
+                \begin{array}{lll}
+                    H \in \mathcal{H}: & \multicolumn{2}{l}{|U_{T,H}| = \infty}                                                                                  \\
+                                       & \lor                                   & \exists E' \subset E_H, |E_H \setminus E'| < \infty                            \\
+                                       &                                        & \land \displaystyle\bigcap_{e \in E'} \delta_T^{-1}(\lambda(e)) \neq \emptyset \\
+                \end{array}
+                \right.                                          \\
+            \end{array}
+            \right.
+        \end{math}
+    \end{flushright}
+\end{frame}
+
+\begin{frame}{Main Work}
+    \begin{itemize}
+        \item We designed a distributed algorithm that use a \textbf{byzantine-tolerant eventually consistent register} in our model to achieve Agreement with $t < n/3$ Byzantine nodes.
+        \item I'm working on a framework using this algorithm to build collaborative applications for the context of a zero-trust cloud. 
+    \end{itemize}
+\end{frame}
+
+\begin{frame}
+    \frametitle{Thank you for your attention!}
+    \vfill
+    \begin{center}
+        \includegraphics[height=1cm]{images/logoamu}\hspace{1cm}%
+        \vspace{1em}
+
+        \includegraphics[height=1.5cm]{images/logolis}\hspace{1cm}%
+        \vspace{1em}
+
+        \includegraphics[height=0.9cm]{images/logodalgo}\hspace{1cm}%
+        \vspace{1em}
+
+        \includegraphics[height=0.6cm]{images/logoparsec}
+    \end{center}
+\end{frame}
+
+\end{document}

docs/presentations/autre/WinterSchoolGDRCyber2026/validite_hc.tex

@@ -0,0 +1,31 @@
+\resizebox{\columnwidth}{!}{%
+    \begin{tikzpicture}[
+        roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,},
+        ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,},
+        arrow/.style={|->, thick,},
+        message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}},
+        ]
+
+        \node[roundnode] (11) {};
+        \node[left] at (11.west) {$p_0$};
+        \node[above] at (11.north) {$w(1)$};
+        \node[roundnode] (12) [right=of 11] {};
+        \node[above] at (12.north) {$r/(0,1)$};
+        \node[roundnode] (13) [right=of 12] {};
+        \node[above] at (13.north) {$r/(2,1)^w$};
+
+        \draw[arrow] (11) -- (12);
+        \draw[arrow] (12) -- (13);
+
+        \node[roundnode] (21) [below=of 11] {};
+        \node[left] at (21.west) {$p_1$};
+        \node[below] at (21.south) {$w(2)$};
+        \node[roundnode] (22) [right=of 21] {};
+        \node[below] at (22.south) {$r/(0,2)$};
+        \node[roundnode] (23) [right=of 22] {};
+        \node[below] at (23.south) {$r/(1,2)^w$};
+
+        \draw[arrow] (21) -- (22);
+        \draw[arrow] (22) -- (23);
+    \end{tikzpicture}
+}

docs/presentations/autre/capitoledulibre/main.tex

@@ -0,0 +1,647 @@
+\documentclass[aspectratio=43]{beamer}
+
+\usetheme{Berlin}
+%\usefonttheme{professionalfonts}
+
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage[french]{babel}
+\usepackage{mathtools,amssymb}
+\usepackage{microtype}
+\usepackage{pgfgantt}
+\usepackage{adjustbox}
+\usetikzlibrary{positioning}
+% \usepackage{qrcode}
+
+\title[]{Systèmes centralisés, fédérés et pair à pair : vu par la théorie des graphs}
+\author{Amaury JOLY}
+\institute[AMU - Skeptikon - Parsec]{Aix-Marseille université, Skeptikon, Parsec.cloud}
+
+\begin{document}
+
+\begin{frame}{}
+    \titlepage
+\end{frame}
+
+\note{test}
+\begin{frame}{Qui suis-je}
+    \begin{itemize}
+        \item \textbf{Doctorant} en informatique distribué
+        \begin{itemize}
+            \item \textit{Étude de la cohérence des données dans les systèmes distribués}
+        \end{itemize}
+        \item Ingénieur R\&D chez \textbf{Parsec.cloud}
+        \item Membre de l'association \textbf{Skeptikon}
+    \end{itemize}
+\end{frame}
+
+\section{Introduction a l'algorithmie distribué}
+
+\begin{frame}{Un système distribué c'est quoi}
+    \begin{quote}
+        On définit un système comme un ensemble de processus. On considère qu'un système est dit distribué lorsque plusieurs processus distincts travail à la réalisation d'une tâche commune.
+    \end{quote}
+
+    \vspace{1em}
+    Par exemple la rédaction de documents collaboratifs (ex: cryptpad, grist, colabora), le chat (ex: matrix, signal, XMPP, IRC, IMAP), le partage d'annuaire de vidéo (ex: PeerTube), la résolution des noms de domaines (DNS).
+\end{frame}
+
+\begin{frame}{Définir un système distribué: le modèle de communication}
+    La recherche traite globalement deux modèles de communication 
+    \begin{itemize}
+        \item Shared-Register
+
+        \pause
+        
+        \resizebox{0.5\linewidth}{!}{%
+          \begin{tikzpicture}[
+            node distance=1.8cm and 2.4cm,
+            process/.style={draw, circle, thick, minimum size=1cm, font=\small},
+            mem/.style={draw, thick, rounded corners, minimum width=5cm, minimum height=1.8cm, fill=gray!10},
+            reg/.style={draw, thin, minimum width=1.1cm, minimum height=0.7cm, font=\scriptsize},
+            arrow/.style={-Latex, thick}
+          ]
+        
+          % --- Mémoire partagée (abstraction) ---
+          \node[mem] (mem) {};
+        
+          % Quelques registres logiques dans la mémoire
+          \node[reg] (r1) at ($(mem.west)!0.2!(mem.east)$) {$R_1$};
+          \node[reg] (r2) at ($(mem.west)!0.5!(mem.east)$) {$R_\dots$};
+          \node[reg] (r3) at ($(mem.west)!0.8!(mem.east)$) {$R_n$};
+        
+          \node[font=\scriptsize, below=0.15cm of mem]{Tous les processus voient la même mémoire logique};
+        
+          % --- Processus concurrents ---
+          \node[process] (p1) [left=of p2] {$P_1$};
+          \node[process] (p2) [above=1.8cm of mem] {$P_\dots$};
+          \node[process] (p3) [right=of p2] {$P_n$};
+        
+          % --- Accès mémoire : opérations read/write ---
+          \draw[arrow] (p1.south) -- (r1.north);
+          \draw[arrow] (p1.south) -- (r2.north);
+          \draw[arrow] (p1.south) -- (r3.north);
+          \draw[arrow] (p2.south) -- (r2.north);
+          \draw[arrow] (p2.south) -- (r1.north);
+          \draw[arrow] (p2.south) -- (r3.north);
+          \draw[arrow] (p3.south) -- (r1.north);
+          \draw[arrow] (p3.south) -- (r2.north);
+          \draw[arrow] (p3.south) -- (r3.north);
+        
+          \end{tikzpicture}
+        }
+    \end{itemize}
+\end{frame}
+
+\begin{frame}{Définir un système distribué: le modèle de communication}
+    \begin{itemize}
+        \item Shared-Register
+        \item \textbf{Message-passing}
+
+        \centering
+        \resizebox{0.2\linewidth}{!}{%
+          \begin{tikzpicture}[
+            node distance=2.2cm and 1.4cm,
+            process/.style={draw, circle, thick, minimum size=1cm, font=\small},
+            state/.style={draw, thin, rounded corners, minimum width=1.6cm, 
+                          minimum height=0.7cm, font=\scriptsize, fill=gray!10},
+            msg/.style={-Latex, thick},
+            netbox/.style={draw, dashed, rounded corners, thick, inner sep=0.4cm}
+          ]
+        
+          % --- Processus avec état local ---
+          \node[process] (p1) {$P_1$};
+          \node[process] (p2) [above=of p1] {$P_2$};
+          \node[process] (p3) [right=of p1] {$P_3$};
+        
+          \node[state] (s1) [below=0.7cm of p1] {état local $S_1$};
+          \node[state] (s2) [above=0.7cm of p2] {état local $S_2$};
+          \node[state] (s3) [below=0.7cm of p3] {état local $S_3$};
+        
+          % --- Messages entre processus ---
+          \draw[msg] (p1) to[bend left=15] node[above, font=\scriptsize]{message $m_1$} (p2);
+          \draw[msg] (p2) to[bend left=15] node[above, font=\scriptsize]{message $m_2$} (p3);
+          \draw[msg] (p3) to[bend left=15] node[above, font=\scriptsize]{message $m_3$} (p1);
+                
+          \end{tikzpicture}
+        }%
+        
+    \end{itemize}
+\end{frame}
+
+\begin{frame}{Définir un système distribué: le modèle de synchronisme}
+    La recherche distingue deux grandes hypothèses de synchronisme :
+    \begin{itemize}
+        \item \textbf{Synchrone} (temps découpé en tours / rounds)
+
+        \pause
+        
+        \centering
+        \resizebox{0.7\linewidth}{!}{%
+          \begin{tikzpicture}[
+            x=1.4cm, y=0.9cm,
+            msg/.style={-Latex, thick},
+            proc/.style={font=\small},
+            roundline/.style={thick},
+            sep/.style={dashed, gray}
+          ]
+          
+          % --- Processus ---
+          \node[proc, anchor=east] at (0,0)   {$P_1$};
+          \node[proc, anchor=east] at (0,-1)  {$P_2$};
+          \node[proc, anchor=east] at (0,-2)  {$P_3$};
+
+          % --- Lignes de temps pour chaque processus ---
+          \foreach \y in {0,-1,-2}{
+            \draw[roundline] (0.2,\y) -- (3.0,\y);
+          }
+
+          % --- Séparation en tours synchrones ---
+          \foreach \x/\t in {0.8/1,1.6/2,2.4/3}{
+            \draw[sep] (\x,0.3) -- (\x,-2.3);
+            \node[font=\scriptsize] at (\x+0.35,0.35) {tour \t};
+          }
+
+          % --- Messages livrés dans le tour suivant ---
+          \draw[msg] (0.35,0)   .. controls (0.55,-0.2) .. (0.75,-1);   % P1 -> P2 dans le tour 1
+          \draw[msg] (1.0,-1)   .. controls (1.2,-1.8) .. (1.4,-2);     % P2 -> P3 dans le tour 2
+          \draw[msg] (1.7,-2)   .. controls (1.9,-1.2) .. (2.1,0);      % P3 -> P1 dans le tour 3
+
+          % --- Légende ---
+          \node[font=\scriptsize, align=center] at (1.6,-2.6){Bornes connues sur les durées de calcul et de communication,\\
+             tous les processus avancent par tours synchrones};
+          
+          \end{tikzpicture}
+        }
+    \end{itemize}
+\end{frame}
+
+\begin{frame}{Définir un système distribué: les modèles de synchronisme}
+    \begin{itemize}
+        \item Synchrone
+        \item \textbf{Asynchrone}
+    \end{itemize}
+
+    \pause
+
+    \centering
+    \resizebox{0.7\linewidth}{!}{%
+      \begin{tikzpicture}[
+        x=1.4cm, y=0.9cm,
+        msg/.style={-Latex, thick},
+        proc/.style={font=\small},
+        opbox/.style={draw, rounded corners, thick}
+      ]
+      
+        % --- Processus ---
+        \node[proc, anchor=east] at (0,0)   {$P_1$};
+        \node[proc, anchor=east] at (0,-1)  {$P_2$};
+        \node[proc, anchor=east] at (0,-2)  {$P_3$};
+
+        \pause
+
+        % --- Lignes de temps pour chaque processus ---
+        \foreach \y in {0,-1,-2}{
+          \draw[thick] (0.2,\y) -- (3.0,\y);
+        }
+
+        \pause
+
+        % --- "Ticks" locaux non alignés (horloges indépendantes) ---
+        \foreach \x in {0.5,1.2,2.3}{
+          \draw (\x,0.1) -- (\x,-0.1);       % P1
+        }
+        \foreach \x in {0.4,1.5,2.6}{
+          \draw (\x,-0.9) -- (\x,-1.1);      % P2
+        }
+        \foreach \x in {0.7,1.8,2.1}{
+          \draw (\x,-1.9) -- (\x,-2.1);      % P3
+        }
+
+        \pause
+
+        % --- Messages ---
+        \draw[msg] (0.35,0) -- (0.8,-1);
+        \draw[msg] (0.35,0) -- (2.5,-2);
+
+        \pause
+
+        \draw[msg] (1.0,-1) -- (1.8,0);
+        \draw[msg] (1.0,-1) -- (2.2,-2);
+
+        \pause
+
+        \draw[msg] (1.4,-2) -- (2.1,0);
+        \draw[msg] (1.4,-2) -- (2.5,-1);
+
+        \pause
+        % op_1 : diffusion de P1
+        % commence à x = 0.35 (émission) et finit à x = 2.5 (dernier reçu : P3)
+        \draw[opbox,densely dotted] (0.35,0.25) rectangle (2.5,-0.25);
+        % ligne de vie de P1 en pointillé dans l'intervalle de op_1
+        \draw[thick,densely dotted] (0.35,0) -- (2.5,0);
+        \node[font=\scriptsize, anchor=west] at (2.55,-0.2) {$op_1$};
+
+        \pause
+        % op_2 : diffusion de P2
+        % commence à x = 1.0 (émission) et finit à x = 2.2 (dernier reçu : P3)
+        \draw[opbox,densely dotted] (1.0,-0.75) rectangle (2.2,-1.25);
+        % ligne de vie de P2 en pointillé dans l'intervalle de op_2
+        \draw[thick,densely dotted] (1.0,-1) -- (2.2,-1);
+        \node[font=\scriptsize, anchor=west] at (2.25,-1.2) {$op_2$};
+        
+        \pause
+        % op_3 : diffusion de P3
+        % commence à x = 1.4 (émission) et finit à x = 2.5 (dernier reçu : P2)
+        \draw[opbox,densely dotted] (1.4,-1.75) rectangle (2.5,-2.25);
+        % ligne de vie de P3 en pointillé dans l'intervalle de op_3
+        \draw[thick,densely dotted] (1.4,-2) -- (2.5,-2);
+        \node[font=\scriptsize, anchor=west] at (2.55,-2.2) {$op_3$};
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+\begin{frame}{Définir un système distribué: les modèles de synchronisme}
+    \begin{itemize}
+        \item Synchrone
+        \item \textbf{Asynchrone}
+    \end{itemize}
+
+    \centering
+    \resizebox{0.7\linewidth}{!}{%
+      \begin{tikzpicture}[
+        x=1.4cm, y=0.9cm,
+        msg/.style={-Latex, thick},
+        proc/.style={font=\small},
+        opbox/.style={draw, rounded corners, thick}
+      ]
+      
+        % --- Processus ---
+        \node[proc, anchor=east] at (0,0)   {$P_1$};
+        \node[proc, anchor=east] at (0,-1)  {$P_2$};
+        \node[proc, anchor=east] at (0,-2)  {$P_3$};
+
+        % --- Lignes de temps pour chaque processus ---
+        \foreach \y in {0,-1,-2}{
+          \draw[thick] (0.2,\y) -- (3.0,\y);
+        }
+
+        % op_1 : diffusion de P1
+        % commence à x = 0.35 (émission) et finit à x = 2.5 (dernier reçu : P3)
+        \draw[opbox,densely dotted] (0.35,0.25) rectangle (2.5,-0.25);
+        % ligne de vie de P1 en pointillé dans l'intervalle de op_1
+        \draw[thick,densely dotted] (0.35,0) -- (2.5,0);
+        \node[font=\scriptsize, anchor=west] at (2.55,-0.2) {$op_1$};
+
+        % op_2 : diffusion de P2
+        % commence à x = 1.0 (émission) et finit à x = 2.2 (dernier reçu : P3)
+        \draw[opbox,densely dotted] (1.0,-0.75) rectangle (2.2,-1.25);
+        % ligne de vie de P2 en pointillé dans l'intervalle de op_2
+        \draw[thick,densely dotted] (1.0,-1) -- (2.2,-1);
+        \node[font=\scriptsize, anchor=west] at (2.25,-1.2) {$op_2$};
+        
+        % op_3 : diffusion de P3
+        % commence à x = 1.4 (émission) et finit à x = 2.5 (dernier reçu : P2)
+        \draw[opbox,densely dotted] (1.4,-1.75) rectangle (2.5,-2.25);
+        % ligne de vie de P3 en pointillé dans l'intervalle de op_3
+        \draw[thick,densely dotted] (1.4,-2) -- (2.5,-2);
+        \node[font=\scriptsize, anchor=west] at (2.55,-2.2) {$op_3$};
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+\section{Les différentes architectures de systèmes}
+
+\subsection{Les systèmes centralisés}
+
+\begin{frame}{Système centralisé}
+    \begin{itemize}
+        \item Architecture client--serveur
+        \item Un seul serveur central maintient l'état
+    \end{itemize}
+
+    \vspace{0.3cm}
+    \centering
+    \resizebox{0.6\linewidth}{!}{%
+      \begin{tikzpicture}[
+        node distance=1.8cm and 2.5cm,
+        client/.style={draw, circle, thick, minimum size=1cm, font=\small},
+        server/.style={draw, thick, rounded corners, minimum width=2.8cm, 
+                       minimum height=1.2cm, font=\small, fill=gray!10},
+        msg/.style={-Latex, thick},
+        resp/.style={Latex-, thick, dashed}
+      ]
+
+        % --- Serveur central ---
+        \node[server] (srv) at (0,0) {Serveur central};
+
+        % --- Clients ---
+        \node[client] (c1) at (-3,0) {$P_1$};
+        \node[client] (c2) at (0,-2) {$P_2$};
+        \node[client] (c3) at (3,-0) {$P_3$};
+
+        % --- Messages requête / réponse ---
+        \draw[msg]  (c1.east) -- (srv.west);
+        \draw[msg]  (c2.north) -- (srv.south);
+        \draw[msg]  (c3.west) -- (srv.east);
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+
+\begin{frame}{Système centralisé : exécution parallèle des clients}
+    \begin{itemize}
+        \item Requêtes concurrentes côté clients
+        \item Traitement séquentiel côté serveur (ordre total)
+    \end{itemize}
+
+    \vspace{0.3cm}
+    \centering
+    \resizebox{0.6\linewidth}{!}{%
+      \begin{tikzpicture}[
+        x=1.4cm, y=0.9cm,
+        msg/.style={-Latex, thick},
+        proc/.style={font=\small},
+        opbox/.style={draw, rounded corners, thick, fill=gray!10}
+      ]
+
+        % --- Processus : serveur + clients (lignes de vie) ---
+        \node[proc, anchor=east] at (0,0)    {$Serveur$};
+        \node[proc, anchor=east] at (0,-1)   {$P_1$};
+        \node[proc, anchor=east] at (0,-2)   {$P_2$};
+        \node[proc, anchor=east] at (0,-3)   {$P_3$};
+
+        \pause
+
+        % --- Lignes de temps ---
+        \foreach \y in {0,-1,-2,-3}{
+          \draw[thick] (0.2,\y) -- (4.0,\y);
+        }
+
+        \pause
+        % --- Requêtes des clients vers le serveur (légèrement décalées) ---
+        \draw[msg] (0.8,-1) -- (1.2,0)
+           node[midway, left, font=\scriptsize] {$op_1$};
+        \draw[msg] (0.9,-2) -- (1.3,0)
+           node[midway, left, font=\scriptsize] {$op_2$};
+        \draw[msg] (1.0,-3) -- (1.4,0)
+           node[midway, left, font=\scriptsize] {$op_3$};
+
+        % (On suggère qu'elles sont émises "en parallèle" côté clients.)
+
+        \pause
+        % --- Traitement séquentiel au serveur : op_1, op_2, op_3 ---
+        % op_1
+        \node[opbox, minimum width=0.2cm, minimum height=0.5cm] (o1) at (1.8,0) {$op_1$};
+        % op_2
+        \node[opbox, minimum width=0.2cm, minimum height=0.5cm, right=0.2cm of o1] (o2) {$op_2$};
+        % op_3
+        \node[opbox, minimum width=0.2cm, minimum height=0.5cm, right=0.2cm of o2] (o3) {$op_3$};
+
+        % Relier dans l'ordre pour bien montrer la séquentialisation
+        \draw[->, thick] (o1.east) -- (o2.west);
+        \draw[->, thick] (o2.east) -- (o3.west);
+
+        % --- Réponses (optionnelles, pour fermer la boucle) ---
+        \pause
+        \draw[msg] (o1.south) -- (2,-1);
+        \draw[msg] (o1.south) -- (2,-2);
+        \draw[msg] (o1.south) -- (2,-3);
+        \draw[msg] (o2.south) -- (2.8,-1);
+        \draw[msg] (o2.south) -- (2.8,-2);
+        \draw[msg] (o2.south) -- (2.8,-3);
+        \draw[msg] (o3.south) -- (3.8,-1);
+        \draw[msg] (o3.south) -- (3.8,-2);
+        \draw[msg] (o3.south) -- (3.8,-3);
+
+        % --- Évolution de l'état (optionnel mais parlant) ---
+        \node[font=\scriptsize, align=left] at (2.7,0.9)
+           {$S_0 \xrightarrow{op_1} S_1 \xrightarrow{op_2} S_2 \xrightarrow{op_3} S_3$};
+      \end{tikzpicture}
+    }
+\end{frame}
+
+\subsection{Les systèmes pair à pair}
+
+\begin{frame}{Système pair à pair}
+    \begin{itemize}
+        \item Pas de serveur central
+        \item Chaque processus entretient son état local en fonction des messages recu.
+    \end{itemize}
+
+    \vspace{0.3cm}
+    \centering
+    \resizebox{0.6\linewidth}{!}{%
+      \begin{tikzpicture}[
+        node distance=1.8cm and 2.5cm,
+        peer/.style={draw, circle, thick, minimum size=1cm, font=\small},
+        link/.style={<->, thick}
+      ]
+
+        % --- Pairs ---
+        \node[peer] (p1) at (-2,0) {$P_1$};
+        \node[peer] (p2) at ( 2,0) {$P_2$};
+        \node[peer] (p3) at ( 0,-2) {$P_3$};
+
+        % --- Connexions pair à pair ---
+        \draw[link] (p1) -- (p2);
+        \draw[link] (p1) -- (p3);
+        \draw[link] (p2) -- (p3);
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+\begin{frame}{Système pair à pair : exécution parallèle}
+    \begin{itemize}
+        \item Chaque pair exécute des opérations concurrentes
+        \item Pas de serveur central pour imposer un ordre total
+    \end{itemize}
+
+    \centering
+    \resizebox{0.7\linewidth}{!}{%
+      \begin{tikzpicture}[
+        x=1.4cm, y=0.9cm,
+        proc/.style={font=\small},
+        opbox/.style={draw, rounded corners, thick}
+      ]
+      
+        % --- Processus ---
+        \node[proc, anchor=east] at (0,0)   {$P_1$};
+        \node[proc, anchor=east] at (0,-1)  {$P_2$};
+        \node[proc, anchor=east] at (0,-2)  {$P_3$};
+
+        % --- Lignes de temps pour chaque processus ---
+        \foreach \y in {0,-1,-2}{
+          \draw[thick] (0.2,\y) -- (3.0,\y);
+        }
+
+        % op_1 : opération de P1
+        % commence à x = 0.35 et finit à x = 2.5
+        \draw[opbox,densely dotted] (0.35,0.25) rectangle (2.5,-0.25);
+        % ligne de vie de P_1 en pointillé dans l'intervalle de op_1
+        \draw[thick,densely dotted] (0.35,0) -- (2.5,0);
+        \node[font=\scriptsize, anchor=west] at (2.55,-0.2) {$op_1$};
+
+        % op_2 : opération de P2
+        % commence à x = 1.0 et finit à x = 2.2
+        \draw[opbox,densely dotted] (0.45,-0.75) rectangle (1.2,-1.25);
+        % ligne de vie de P_2 en pointillé dans l'intervalle de op_2
+        \draw[thick,densely dotted] (1.0,-1) -- (2.2,-1);
+        \node[font=\scriptsize, anchor=west] at (2.25,-1.2) {$op_2$};
+        
+        % op_3 : opération de P3
+        % commence à x = 1.4 et finit à x = 2.5
+        \draw[opbox,densely dotted] (1.4,-1.75) rectangle (2.5,-2.25);
+        % ligne de vie de P_3 en pointillé dans l'intervalle de op_3
+        \draw[thick,densely dotted] (1.4,-2) -- (2.5,-2);
+        \node[font=\scriptsize, anchor=west] at (2.55,-2.2) {$op_3$};
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+\subsection{Les systèmes fédérés}
+
+\begin{frame}{Système fédéré}
+    \begin{itemize}
+        \item Plusieurs serveurs, chacun gère un sous-ensemble de processus
+        \item Les serveurs se synchronisent entre eux (fédération)
+    \end{itemize}
+
+    \vspace{0.3cm}
+    \centering
+    \resizebox{0.4\linewidth}{!}{%
+      \begin{tikzpicture}[
+        node distance=1.8cm and 2.5cm,
+        server/.style={draw, thick, rounded corners, minimum width=2.8cm,
+                       minimum height=1.2cm, font=\small, fill=gray!10},
+        client/.style={draw, circle, thick, minimum size=0.9cm, font=\scriptsize},
+        srvlink/.style={<->, thick}
+      ]
+
+        % --- Serveurs fédérés ---
+        \node[server] (s1) at (0,1.5)  {Serveur $S_1$};
+        \node[server] (s2) at (-3,-0.5){Serveur $S_2$};
+        \node[server] (s3) at ( 3,-0.5){Serveur $S_3$};
+
+        % --- Processus locaux à chaque serveur ---
+        \node[client] (p1) at (0,3)  {$P_1$};
+        \node[client] (p2) at (-3,-2.5) {$P_2$};
+        \node[client] (p3) at ( 3,-2.5) {$P_3$};
+
+        % --- Liens client -- serveur local ---
+        \draw[-Latex, thick] (p1.south) -- (s1.north);
+        \draw[-Latex, thick] (p2.north) -- (s2.south);
+        \draw[-Latex, thick] (p3.north) -- (s3.south);
+
+        % --- Fédération entre serveurs ---
+        \draw[srvlink] (s1) -- (s2);
+        \draw[srvlink] (s1) -- (s3);
+        \draw[srvlink] (s2) -- (s3);
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+\begin{frame}{Système fédéré : exécution parallèle des serveurs}
+    \begin{itemize}
+        \item Chaque serveur impose un ordre total local sur ses opérations
+        \item Globalement, les opérations sur différents serveurs sont concurrentes
+    \end{itemize}
+
+    \centering
+    \resizebox{0.7\linewidth}{!}{%
+      \begin{tikzpicture}[
+        x=1.4cm, y=0.9cm,
+        proc/.style={font=\small},
+        opbox/.style={draw, rounded corners, thick}
+      ]
+      
+        % --- Processus (serveurs fédérés) ---
+        \node[proc, anchor=east] at (0,0)   {$S_1$};
+        \node[proc, anchor=east] at (0,-1)  {$S_2$};
+        \node[proc, anchor=east] at (0,-2)  {$S_3$};
+
+        % --- Lignes de temps pour chaque serveur ---
+        \foreach \y in {0,-1,-2}{
+          \draw[thick] (0.2,\y) -- (3.2,\y);
+        }
+
+        % op_1 : opération sur S_1 (longue)
+        \draw[opbox,densely dotted] (0.35,0.25) rectangle (2.3,-0.25);
+        \draw[thick,densely dotted] (0.35,0) -- (2.3,0);
+        \node[font=\scriptsize, anchor=west] at (2.35,-0.2) {$op_1$};
+
+        % op_2 : opération sur S_2 (décalée, plus courte)
+        \draw[opbox,densely dotted] (0.8,-0.75) rectangle (2.0,-1.25);
+        \draw[thick,densely dotted] (0.8,-1) -- (2.0,-1);
+        \node[font=\scriptsize, anchor=west] at (2.05,-1.2) {$op_2$};
+        
+        % op_3 : opération sur S_3 (commence plus tard, finit après op_2)
+        \draw[opbox,densely dotted] (1.3,-1.75) rectangle (2.8,-2.25);
+        \draw[thick,densely dotted] (1.3,-2) -- (2.8,-2);
+        \node[font=\scriptsize, anchor=west] at (2.85,-2.2) {$op_3$};
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+
+
+\begin{frame}{Jeu : placer les applications dans les architectures}
+    \begin{itemize}
+        \item À quel type d'architecture appartient chaque application ?
+    \end{itemize}
+
+    \vspace{0.3cm}
+    \centering
+    \resizebox{0.95\linewidth}{!}{%
+      \begin{tikzpicture}[
+        archibox/.style={draw, rounded corners, thick,
+                         minimum width=3.5cm, minimum height=1.6cm,
+                         font=\small, align=center, fill=gray!10},
+        app/.style={draw, rounded corners, thick,
+                    minimum width=2.0cm, minimum height=0.8cm,
+                    font=\scriptsize, align=center}
+      ]
+
+        % --- Zones d'architecture ---
+        \node[archibox] (central)   at (-4, 1.5) {Centralisé};
+        \node[archibox] (p2p)       at ( 0, 1.5) {Pair à pair};
+        \node[archibox] (federated) at ( 4, 1.5) {Fédéré};
+
+        % --- Jetons d'applications à placer ---
+        \node[app] at (-5, -0.2) {cryptpad};
+        \node[app] at (-2.5,-0.2) {grist};
+        \node[app] at ( 0, -0.2) {colabora};
+        \node[app] at ( 2.5,-0.2) {matrix};
+        \node[app] at ( 5, -0.2) {signal};
+
+        \node[app] at (-5, -1.8) {XMPP};
+        \node[app] at (-2.5,-1.8) {IRC};
+        \node[app] at ( 0, -1.8) {IMAP};
+        \node[app] at ( 2.5,-1.8) {PeerTube};
+        \node[app] at ( 5, -1.8) {DNS};
+
+      \end{tikzpicture}
+    }
+\end{frame}
+
+
+\begin{frame}{Un petit Quizz}
+    % \qrcode{partici.fi/38956702}
+\end{frame}
+
+\begin{frame}
+    \frametitle{MERCI !}
+
+    
+
+\end{frame}
+    
+
+\end{document}