Compare commits
92 Commits
71296deb95
...
main_old
| Author | SHA1 | Date | |
|---|---|---|---|
|
18448b481e | ||
|
|
94b22408e5 | ||
|
|
8f51a7eed6 | ||
|
|
cc22c9d7f3 | ||
|
|
268c30a112 | ||
|
|
921dd502e3 | ||
|
|
8ae05ff173 | ||
|
|
945d830e89 | ||
|
|
ea8826c4f5 | ||
|
|
3e8aec36a2 | ||
|
|
d5a865dd0a | ||
|
|
f2cc294232 | ||
|
|
f5e0d90fb4 | ||
|
|
1acb408d01 | ||
|
|
106bc70056 | ||
|
|
e89e0e8d2a | ||
|
|
926c3fdc51 | ||
|
|
679e6e949c | ||
|
|
6ffb074956 | ||
|
|
bce3b5cb3a | ||
|
|
9475510cdb | ||
|
|
ed3a31e66a | ||
|
|
6fdcdadfd2 | ||
|
|
3c90fdc774 | ||
|
|
e6865efc53 | ||
|
|
2194f699d6 | ||
|
|
3ea8de6388 | ||
|
|
35a9d91779 | ||
|
|
b5719a7d6b | ||
|
|
d1caa2e54a | ||
|
|
0da5a47d47 | ||
|
|
c3694aff50 | ||
|
|
c5d71235d5 | ||
|
|
5adbb82d71 | ||
|
|
d81a1e232a | ||
|
|
2c04ad710e | ||
|
|
39707197ef | ||
|
|
01f1e546d4 | ||
|
|
7133b37da2 | ||
|
|
790ab5828f | ||
|
|
29a2223ed0 | ||
|
|
61d7f9a8f4 | ||
|
|
c9e3b8a751 | ||
|
|
a09f223b46 | ||
|
|
0a3fb33f63 | ||
|
|
028ef5f9f2 | ||
|
|
ef0e2b3e45 | ||
|
|
e27c7dea04 | ||
|
|
6d37e433ef | ||
|
|
7c080a146d | ||
|
|
6a75aa7ebf | ||
|
8bf0a343fa | ||
|
|
dc7c4f0290 | ||
|
|
3437a6751b | ||
|
|
66aeded3d1 | ||
| fa7e0ac5c1 | |||
|
|
f4fe573079 | ||
|
|
3a3f759070 | ||
|
|
77d7d734fe | ||
|
|
8b65ea242a | ||
|
|
fee42383f4 | ||
|
|
82f0f8c92c | ||
|
|
3f4ec11b0a | ||
|
|
506bcb6415 | ||
|
|
658ba1c6c7 | ||
|
|
999511988d | ||
|
|
ee359083fd | ||
|
|
23b4126f7e | ||
|
|
aefa847e9b | ||
|
|
87ef596364 | ||
|
|
ab70a09cbf | ||
|
|
e51d7de452 | ||
|
|
25bcd0cc27 | ||
|
|
8199d8d9e2 | ||
|
|
4d216f8338 | ||
|
|
9c0f14255d | ||
|
|
b1ae7f3821 | ||
|
|
74cd55be4b | ||
|
|
9130472a12 | ||
|
|
b00fc6acbe | ||
|
|
f1b1dc40ca | ||
|
|
e080a1d53a | ||
|
|
5b2ad4ab99 | ||
|
|
a44d8f8ebb | ||
|
|
0e3463f97d | ||
|
|
5fd2cd1273 | ||
| 84867740de | |||
|
|
b0695ae27e | ||
|
|
8763cc6413 | ||
|
|
18373a46df | ||
|
|
6300aba265 | ||
|
|
6c15a5bf15 |
33
.devcontainer/devcontainer.json
Normal file
33
.devcontainer/devcontainer.json
Normal file
@@ -0,0 +1,33 @@
|
||||
// Add you DevContainer configuration in this file
|
||||
// See: https://containers.dev/ for the "official" DevContainer specifications
|
||||
{
|
||||
"name": "latex-default", //Add the name your DevContainer Here,
|
||||
"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": ["--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
|
||||
// },
|
||||
// "forwardPorts": [], //Add your port forwarding from inside/oustide here
|
||||
"workspaceMount": "source=${localWorkspaceFolder},target=/workspaces/containers,type=bind", //Add your local mounting inside the DevContainer here
|
||||
"workspaceFolder": "/workspaces/containers", //Add your workspace folder here
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
"extensions": [
|
||||
"james-yu.latex-workshop",
|
||||
"eamodio.gitlens",
|
||||
"jenselme.grammalecte",
|
||||
"jebbs.plantuml"
|
||||
],
|
||||
"settings": {
|
||||
"grammalecte.allowedExtension": ".md,.rst,.adoc,.asciidoc,.creole,.t2t,.tex",
|
||||
}
|
||||
}
|
||||
},
|
||||
"features": {
|
||||
"ghcr.io/devcontainers/features/git:1": {},
|
||||
}
|
||||
}
|
||||
21
.devcontainer/install-tools.sh
Executable file
21
.devcontainer/install-tools.sh
Executable file
@@ -0,0 +1,21 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Update package lists
|
||||
apt update
|
||||
|
||||
# Install Git
|
||||
# apt install -y git
|
||||
tlmgr install preprint
|
||||
|
||||
# installation de grammalecte
|
||||
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
|
||||
|
||||
#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
|
||||
50
.gitignore
vendored
Normal file
50
.gitignore
vendored
Normal file
@@ -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
|
||||
@@ -12,3 +12,4 @@
|
||||
]*.vrb
|
||||
]_build/
|
||||
]build/
|
||||
].git/
|
||||
Binary file not shown.
Binary file not shown.
13
.vscode/ltex.dictionary.fr.txt
vendored
Executable file
13
.vscode/ltex.dictionary.fr.txt
vendored
Executable file
@@ -0,0 +1,13 @@
|
||||
partitionnable
|
||||
Jimmy-3
|
||||
Jimmy-5
|
||||
cofini
|
||||
Serialisabilité
|
||||
Broadcast
|
||||
FIFO
|
||||
décomposabilité
|
||||
composabilité
|
||||
Composabilité
|
||||
Lamport
|
||||
Sérialisabilité
|
||||
sérialisabilité
|
||||
10
.vscode/ltex.hiddenFalsePositives.fr.txt
vendored
Executable file
10
.vscode/ltex.hiddenFalsePositives.fr.txt
vendored
Executable file
@@ -0,0 +1,10 @@
|
||||
{"rule":"WHITESPACE_RULE","sentence":"^\\Q0.6 !\\E$"}
|
||||
{"rule":"WHITESPACE_RULE","sentence":"^\\QLes classes de cohérence 0.5 !\\E$"}
|
||||
{"rule":"FR_SPELLING_RULE","sentence":"^\\QNous pouvons définir 3 classes de cohérence : La Localité d'état (LS) La Validité (V) La Convergence (EC)\\E$"}
|
||||
{"rule":"FRENCH_WHITESPACE","sentence":"^\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q:\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q, \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q .\\E$"}
|
||||
{"rule":"COMMA_PARENTHESIS_WHITESPACE","sentence":"^\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q:\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q, \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q .\\E$"}
|
||||
{"rule":"COMMA_PARENTHESIS_WHITESPACE","sentence":"^\\Q.\\E$"}
|
||||
{"rule":"FLECHES","sentence":"^\\Qnotions : respect de l'ordre, atomicité, isolation\nIntroduire le concept de cohérence faible\nexemple : application distribuée décentralisée\nDéfinir les propriétés d'un système réparti\nDéfinir les différents modèles de cohérence faible (des plus trivial aux moins)\nCohérence Séquentielle (SC)\nLinéarisabilité -> Serialisabilité\nConvergence/Convergence Forte\nDéfinit le concept de convergence\nPourquoi ?\\E$"}
|
||||
{"rule":"FR_SPELLING_RULE","sentence":"^\\QBroadcast (diffusion fiable):\nValidité: tout message reçu est émis par un processus\nUniformité: tout message reçu par un processus est recu par tout les autres processus\nFIFO Broadcast (idem Broadcast):\nRéception FIFO: tout message reçu par un processus est reçu dans l'ordre d'émission\nCausal Broadcast (idem FIFO Broadcast):\nRéception causale: Tout message m' envoyé par un processus après reception d'un message m est aussi reçu après m chez tout les autres processus\\E$"}
|
||||
{"rule":"FR_SPELLING_RULE","sentence":"^\\QBroadcast (diffusion fiable) :\nValidité: tout message reçu est émis par un processus\nUniformité: tout message reçu par un processus est recu par tout les autres processus\nFIFO Broadcast (idem Broadcast):\nRéception FIFO: tout message reçu par un processus est reçu dans l'ordre d'émission\nCausal Broadcast (idem FIFO Broadcast):\nRéception causale: Tout message m' envoyé par un processus après reception d'un message m est aussi reçu après m chez tout les autres processus\\E$"}
|
||||
{"rule":"FR_SPELLING_RULE","sentence":"^\\QACID: Atomicité (une transaction est soit completement acceptée soit completement avortée), Cohérence (Un transaction éxécutée dans un état correct emmène vers un état correct), Isolation (Les transactions n'interferent pas entre elles), Durabilité (une transaction accepté n'est pas remise en cause).\\E$"}
|
||||
25
.vscode/settings.json
vendored
Executable file
25
.vscode/settings.json
vendored
Executable file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"spellright.language": [
|
||||
"French",
|
||||
"English"
|
||||
],
|
||||
"spellright.documentTypes": [
|
||||
"markdown",
|
||||
"latex",
|
||||
"plaintext"
|
||||
],
|
||||
"ltex.additionalRules.motherTongue": "fr",
|
||||
"ltex.language": "fr",
|
||||
"grammarly.selectors": [
|
||||
{
|
||||
"language": "latex",
|
||||
"scheme": "file"
|
||||
}
|
||||
],
|
||||
"grammarly.files.include": [
|
||||
"**/readme.md",
|
||||
"**/README.md",
|
||||
"**/*.txt",
|
||||
"**/*.tex"
|
||||
]
|
||||
}
|
||||
2
.vscode/spellright.dict
vendored
Executable file
2
.vscode/spellright.dict
vendored
Executable file
@@ -0,0 +1,2 @@
|
||||
partitionnable
|
||||
LS
|
||||
16
README.md
Executable file
16
README.md
Executable file
@@ -0,0 +1,16 @@
|
||||
# Consistence Faible Byzantine Pour le Cloud
|
||||
|
||||
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
|
||||
|
||||
Ce dépot compile mes recherches et travaux autour du sujet de la Consistence Faible Byzantine Pour le Cloud. (cf. [sujet de stage](./bwconsistency-stage.pdf))
|
||||
|
||||
## Membres
|
||||
|
||||
Ce projet est réalisé par Amaury JOLY, et encadré par Emmanuel GODARD et Corentin TRAVERS. Ainsi que dans une collaboration étroite avec l'entreprise [Scille](https://scille.eu/).
|
||||
|
||||
## Architecture
|
||||
|
||||
Le dossier `./recherches` contient les resumés des différents documents que j'ai pu consulter durant mes recherches.
|
||||
19
Readme.md
19
Readme.md
@@ -1,19 +0,0 @@
|
||||
# Readme
|
||||
|
||||
## Liens utiles
|
||||
|
||||
### Git
|
||||
|
||||
Dépot git: <https://amauryjoly.fr/gitea/amaury_joly/bwconsistency>
|
||||
|
||||
Miror: <https://gitlab.lis-lab.fr/amaury.joly/bwconsistency>
|
||||
|
||||
# Readme
|
||||
|
||||
## Liens utiles
|
||||
|
||||
### Git
|
||||
|
||||
Dépot git: <https://amauryjoly.fr/gitea/amaury_joly/bwconsistency>
|
||||
|
||||
Miror: <https://gitlab.lis-lab.fr/amaury.joly/bwconsistency>
|
||||
73
Recherche/ALDLoverAB/algo/index.tex
Normal file
73
Recherche/ALDLoverAB/algo/index.tex
Normal file
@@ -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.
|
||||
@@ -26,6 +26,8 @@ Messages are uniquely identifiable: two messages sent by distinct processes or a
|
||||
|
||||
\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 : \\
|
||||
@@ -38,12 +40,18 @@ Messages are uniquely identifiable: two messages sent by distinct processes or a
|
||||
$\forall m, \forall p_i: \text{bc-recv}_i(m) \text{ occurs at most once}$ \\
|
||||
\end{property}
|
||||
|
||||
\begin{property}{Validity}
|
||||
All messages broadcast by a correct process are eventually received by all non faulty processors. \\
|
||||
\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}
|
||||
BIN
Recherche/ALDLoverAB/main.pdf
Normal file
BIN
Recherche/ALDLoverAB/main.pdf
Normal file
Binary file not shown.
623
Recherche/ALDLoverAB/main.tex
Normal file
623
Recherche/ALDLoverAB/main.tex
Normal file
@@ -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}
|
||||
143
Recherche/ALDLoverAB/proof/index.tex
Normal file
143
Recherche/ALDLoverAB/proof/index.tex
Normal file
@@ -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}
|
||||
|
||||
14
Recherche/ALDLoverAB/sources.bib
Normal file
14
Recherche/ALDLoverAB/sources.bib
Normal file
@@ -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}
|
||||
}
|
||||
@@ -1,60 +0,0 @@
|
||||
We consider a set of processes communicating asynchronously over reliable point-to-point channels. Each process maintains the following shared variables:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{received}: the set of messages received (but not yet delivered).
|
||||
\item \textbf{delivered}: the set of messages that have been received, ordered, and delivered.
|
||||
\item \textbf{prop[$r$][$j$]}: the proposal set of process $j$ at round $r$. It contains the set of messages that process $j$ claims to have received but not yet delivered at round $r$, concatenated with its newly broadcast message.
|
||||
\item \textbf{proves}: the current content of the \texttt{DenyList} registry, accessible via the operation \texttt{READ()}. It returns a list of tuples $(j, \texttt{PROVE}(r))$, each indicating that process $j$ has issued a valid \texttt{PROVE} for round $r$.
|
||||
\item \textbf{winner$^r$}: the set of processes that have issued a valid \texttt{PROVE} operation for round $r$.
|
||||
\item \textbf{RB-cast}: a reliable broadcast primitive that satisfies the properties defined in Section~1.1.2.
|
||||
\item \textbf{APPEND$(r)$}, \textbf{PROVE$(r)$}: operations that respectively insert (APPEND) and attest (PROVE) the participation of a process in round $r$ in the DenyList registry.
|
||||
\item \textbf{READ()}: retrieves the current local view of valid operations (APPENDs and PROVEs) from the DenyList.
|
||||
\item \textbf{ordered$(S)$}: returns a deterministic total order over a set $S$ of messages (e.g., via hash or lexicographic order).
|
||||
\end{itemize}
|
||||
|
||||
\resetalgline
|
||||
\begin{algorithm}
|
||||
|
||||
\vspace{1em}
|
||||
\textbf{RB-received$(m, S, r_0, j_0)$}
|
||||
\begin{algorithmic}[1]
|
||||
\State \nextalgline $\textit{received} \gets \textit{received} \cup \{m\}$
|
||||
\State \nextalgline $\textit{prop}[r_0][j_0] \gets S$
|
||||
\end{algorithmic}
|
||||
|
||||
\vspace{1em}
|
||||
\textbf{AB-broadcast$(m, j_0)$}
|
||||
\begin{algorithmic}[1]
|
||||
\State \nextalgline $\textit{proves} \gets \texttt{READ}()$
|
||||
\State \nextalgline $r_0 \gets \max\{r : \exists j,\ (j, \texttt{PROVE}(r)) \in \textit{proves}\} + 1$
|
||||
\State \nextalgline $\texttt{RB-cast}(m, (\textit{received} \setminus \textit{delivered}) \cup \{m\}, r_0, j_0)$
|
||||
\State \nextalgline \texttt{PROVE}$(r_0)$
|
||||
\State \nextalgline \texttt{APPEND}$(r_0)$
|
||||
\Repeat
|
||||
\State \nextalgline $\textit{proves} \gets \texttt{READ}()$
|
||||
\State \nextalgline $r_1 \gets \max\{r : \exists j,\ (j, \texttt{PROVE}(r)) \in \textit{proves}\} - 1$
|
||||
\State \nextalgline $\textit{winner}^{r_1} \gets \{j : (j, \texttt{PROVE}(r_1)) \in \textit{proves}\}$
|
||||
\State \nextalgline \textbf{wait} $\forall j \in \textit{winner}^{r_1},\ \textit{prop}[r_1][j] \neq \bot$
|
||||
\Until{\nextalgline $\exists r_2,\ \exists j_2 \in \textit{winner}^{r_2},\ m \in \textit{prop}[r_2][j_2]$} \nextalgline
|
||||
\end{algorithmic}
|
||||
|
||||
\vspace{1em}
|
||||
\textbf{AB-listen}
|
||||
\begin{algorithmic}[1]
|
||||
\While{true}
|
||||
\State \nextalgline $\textit{proves} \gets \texttt{READ}()$
|
||||
\State \nextalgline $r_1 \gets \max\{r : \exists j,\ (j, \texttt{PROVE}(r)) \in \textit{proves}\} - 1$
|
||||
\For{$r_2 \in [r_0, \dots, r_1]$} \nextalgline
|
||||
\State \nextalgline \texttt{APPEND}$(r_2)$
|
||||
\State \nextalgline $\textit{proves} \gets \texttt{READ}()$
|
||||
\State \nextalgline $\textit{winner}^{r_2} \gets \{j : (i, \texttt{PROVE}(r_2)) \in \textit{proves}\}$
|
||||
\State \nextalgline \textbf{wait} $\forall j \in \textit{winner}^{r_2},\ \textit{prop}[r_2][j] \neq \bot$
|
||||
\State \nextalgline $M^{r_2} \gets \bigcup_{j \in \textit{winner}^{r_2}} \textit{prop}[r_2][j]$
|
||||
\ForAll{$m \in \texttt{ordered}(M^{r_2})$} \nextalgline
|
||||
\State \nextalgline $\textit{delivered} \gets \textit{delivered} \cup \{m\}$
|
||||
\State \nextalgline \texttt{AB-deliver}$(m)$
|
||||
\EndFor
|
||||
\EndFor
|
||||
\EndWhile
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
@@ -1,20 +0,0 @@
|
||||
\relax
|
||||
\providecommand \babel@aux [2]{\global \let \babel@toc \@gobbletwo }
|
||||
\@nameuse{bbl@beforestart}
|
||||
\catcode `:\active
|
||||
\catcode `;\active
|
||||
\catcode `!\active
|
||||
\catcode `?\active
|
||||
\abx@aux@refcontext{nty/global//global/global/global}
|
||||
\providecommand \oddpage@label [2]{}
|
||||
\babel@aux{french}{}
|
||||
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Model}{1}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.1}Model Properties}{1}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.2}AtomicBroadcast Properties}{1}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsubsection}{\numberline {1.1.3}DenyList Properties}{1}{}\protected@file@percent }
|
||||
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Algo}{1}{}\protected@file@percent }
|
||||
\@writefile{loa}{\contentsline {algocf}{\numberline {1}{\ignorespaces AB\_Broadcast}}{2}{}\protected@file@percent }
|
||||
\@writefile{loa}{\contentsline {algocf}{\numberline {2}{\ignorespaces AB\_Listen}}{2}{}\protected@file@percent }
|
||||
\abx@aux@read@bbl@mdfivesum{76D65A242EC496C9B4361AF646FF12CB}
|
||||
\gdef \@abspage@last{3}
|
||||
@@ -1,20 +0,0 @@
|
||||
% $ biblatex auxiliary file $
|
||||
% $ biblatex bbl format version 3.3 $
|
||||
% Do not modify the above lines!
|
||||
%
|
||||
% This is an auxiliary file used by the 'biblatex' package.
|
||||
% This file may safely be deleted. It will be recreated by
|
||||
% biber as required.
|
||||
%
|
||||
\begingroup
|
||||
\makeatletter
|
||||
\@ifundefined{ver@biblatex.sty}
|
||||
{\@latex@error
|
||||
{Missing 'biblatex' package}
|
||||
{The bibliography requires the 'biblatex' package.}
|
||||
\aftergroup\endinput}
|
||||
{}
|
||||
\endgroup
|
||||
|
||||
\endinput
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
[0] Config.pm:308> INFO - This is Biber 2.20
|
||||
[1] Config.pm:311> INFO - Logfile is 'main.blg'
|
||||
[69] biber:340> INFO - === Thu Apr 24, 2025, 18:19:12
|
||||
[87] Biber.pm:420> INFO - Reading 'main.bcf'
|
||||
[141] Biber.pm:994> INFO - Found 0 citekeys in bib section 0
|
||||
[155] bbl.pm:676> INFO - Writing 'main.bbl' with encoding 'UTF-8'
|
||||
[156] bbl.pm:779> INFO - Output to main.bbl
|
||||
[157] Biber.pm:131> WARN - The file 'main.bcf' does not contain any citations!
|
||||
[158] Biber.pm:133> INFO - WARNINGS: 1
|
||||
@@ -1,95 +0,0 @@
|
||||
# Fdb version 4
|
||||
["biber main"] 1745518751.69811 "main.bcf" "main.bbl" "main" 1745518755.47995 0
|
||||
"main.bcf" 1745518755.26652 108486 d8549f9e7d9f09af6a94b466d27b9f55 "pdflatex"
|
||||
(generated)
|
||||
"main.bbl"
|
||||
"main.blg"
|
||||
(rewritten before read)
|
||||
["pdflatex"] 1745518754.18166 "/workspaces/containers/recherches/AllowListDenyList/main.tex" "main.pdf" "main" 1745518755.48238 0
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/cm-super/cm-super-t1.enc" 1136849721 2971 def0b6c1f0b107b3b936def894055589 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/map/fontname/texfonts.map" 1577235249 3524 cb3e574dea2d1052e39280babc910dc8 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx0700.tfm" 1136768653 3584 ca0c423beaacd28d53ddce5a826cd558 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx1000.tfm" 1136768653 3584 2d666ecf6d466d8b007246bc2f94d9da ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx1200.tfm" 1136768653 3584 402da0b29eafbad07963b1224b222f18 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx1440.tfm" 1136768653 3584 13049b61b922a28b158a38aeff75ee9b ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1000.tfm" 1136768653 3584 adb004a0c8e7c46ee66cad73671f37b4 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1200.tfm" 1136768653 3584 f80ddd985bd00e29e9a6047ebd9d4781 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1440.tfm" 1136768653 3584 3169d30142b88a27d4ab0e3468e963a2 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1728.tfm" 1136768653 3584 3c76ccb63eda935a68ba65ba9da29f1a ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecti1000.tfm" 1136768653 3072 3bce340d4c075dffe6d4ec732b4c32fe ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecti1200.tfm" 1136768653 3072 8b5a64dc91775463bc95e2d818524028 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb" 1248133631 36299 5f9df58c2139e7edcf37c8fca4bd384d ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb" 1248133631 36281 c355509802a035cadc5f15869451dcee ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb" 1248133631 35752 024fb6c41858982481f6968b5fc26508 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb" 1248133631 32569 5e5ddc8df908dea60932f3c484a54c0d ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx0700.pfb" 1215737283 144215 c89c56d5c5b828c5c1657b4326c29df7 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1000.pfb" 1215737283 145408 43d44302ca7d82d487f511f83e309505 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1200.pfb" 1215737283 140176 d4962f948b4cc0adf4d3dde77a128c95 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1440.pfb" 1215737283 135942 859a90cad7494a1e79c94baf546d7de5 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1000.pfb" 1215737283 138258 6525c253f16cededa14c7fd0da7f67b2 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1200.pfb" 1215737283 136101 f533469f523533d38317ab5729d00c8a ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1728.pfb" 1215737283 131438 3aa300b3e40e5c8ba7b4e5c6cebc5dd6 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfti1000.pfb" 1215737283 186554 e8f0fa8ca05e038f257a06405232745f ""
|
||||
"/usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfti1200.pfb" 1215737283 198221 ca5aa71411090ef358a6cc78b7458365 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/babel-french/french.ldf" 1722030099 66864 5ea28be04c8922f57dc437cc5c1c2c31 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/babel/babel.sty" 1743197512 144118 8a0145ee10f36c9987d52d114dccd1b1 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-fr.ini" 1733001190 6315 3c384dcbb287e14a2e736eeb5010b67f ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex" 1711748144 2142 2e5ecc022cd62b6d520b9630cf893dfe ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/babel/txtbabel.def" 1741723514 6833 ef397c732d8c72f527b197aa1623476d ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/iftex/iftex.sty" 1734129479 7984 7dbb9280f03c0a315425f1b4f35d43ee ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/infwarerr/infwarerr.sty" 1575499628 8356 7bbb2c2373aa810be568c29e333da8ed ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty" 1701727651 17865 1a9bd36b4f98178fa551aca822290953 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty" 1593379760 20089 80423eac55aa175305d35b49e04fe23b ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/algorithm2e/algorithm2e.sty" 1500498588 167160 d91cee26d3ef5727644d2110445741dd ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/base/article.cls" 1738182759 20144 63d8bacaf52e5abf4db3bc322373e1d4 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/base/fontenc.sty" 1738182759 5275 0d62fb62162c7ab056e941ef18c5076d ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/base/ifthen.sty" 1738182759 5525 9dced5929f36b19fa837947f5175b331 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/base/inputenc.sty" 1738182759 5048 0270515b828149155424600fd2d58ac5 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/base/size10.clo" 1738182759 8448 5cf247d4bd0c7d5d711bbbdf111fae2e ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/numeric.bbx" 1609451401 1818 9ed166ac0a9204a8ebe450ca09db5dde ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/standard.bbx" 1609451401 25680 409c3f3d570418bc545e8065bebd0688 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.cfg" 1342308459 69 249fa6df04d948e51b6d5c67bea30c42 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.def" 1711143581 96838 228f189cb4020ea9f6d467af8aa859c2 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.sty" 1711143581 533961 a8d65602d822bf3d3c823e6dc4922bbc ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-case-expl3.sty" 1711143581 9961 107fdb78f652fccae7bce0d23bdc19cd ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-compat.def" 1643926307 13919 5426dbe90e723f089052b4e908b56ef9 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-dm.def" 1711143581 32761 18d14e3b502c120f79b2184de4e21d14 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/cbx/numeric.cbx" 1678141846 4629 cda468e8a0b1cfa0f61872e171037a4b ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/lbx/french.lbx" 1711143581 35297 433adeecf04fccba5dc7668ba5058972 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/carlisle/scalefnt.sty" 1137109962 1360 df2086bf924b14b72d6121fe9502fcdb ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.cfg" 1429144587 7068 06f8d141725d114847527a66439066b6 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.def" 1712263026 22135 0975a49eeaed232aa861e9425ffb2e7c ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.sty" 1712263026 62767 e79d6d7a989e7da62dcf3d0a65c1faee ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/etoolbox/etoolbox.sty" 1739306980 46850 d87daedc2abdc653769a6f1067849fe0 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/graphics/keyval.sty" 1717359999 2671 70891d50dac933918b827d326687c6e8 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/ifoddpage/ifoddpage.sty" 1666126449 2142 eae42205b97b7a3ad0e58db5fe99e3e6 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/kvoptions/kvoptions.sty" 1655478651 22555 6d8e155cfef6d82c3d5c742fea7c992e ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty" 1665067230 13815 760b0c02f691ea230f5359c4e1de23a7 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def" 1716410060 29785 9f93ab201fe5dd053afcc6c1bcf7d266 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty" 1738271527 6565 f51d809db6193fae7b06c1bc26ca8f75 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/l3packages/xparse/xparse.sty" 1724879202 9783 ab4bee47700c04aadedb8da27591b0ab ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.def" 1284153563 1620 fb1c32b818f2058eca187e5c41dfae77 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.sty" 1284153563 6187 b27afc771af565d3a9ff1ca7d16d0d46 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/preprint/authblk.sty" 1368488610 7016 985a983ce041cc8959cd31133cba0244 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/preprint/fullpage.sty" 1137110595 2789 05b418f78b224ec872f5b11081138605 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/relsize/relsize.sty" 1369619135 15542 c4cc3164fe24f2f2fbb06eb71b1da4c4 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/tools/xspace.sty" 1717359999 4545 e3f4de576c914e2000f07f69a891c071 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/tex/latex/url/url.sty" 1388531844 12796 8edb7d69a20b857904dd0ea757c14ec9 ""
|
||||
"/usr/local/texlive/2025/texmf-dist/web2c/texmf.cnf" 1739380943 42148 61becc7c670cd061bb319c643c27fdd4 ""
|
||||
"/usr/local/texlive/2025/texmf-var/fonts/map/pdftex/updmap/pdftex.map" 1743313660 5501089 f2ffe622267f7d8bfaba0244ab87ba6f ""
|
||||
"/usr/local/texlive/2025/texmf-var/web2c/pdftex/pdflatex.fmt" 1743313810 3345755 ba2ca5aadbc395a8eb3e969a7d392ec2 ""
|
||||
"/usr/local/texlive/2025/texmf.cnf" 1743313649 455 5b996dcaa0eb4ef14a83b026bc0a008c ""
|
||||
"/workspaces/containers/recherches/AllowListDenyList/main.tex" 1745515390.16057 722 34633c768624cc239eef0942b140dea1 ""
|
||||
"algo/index.tex" 1745516699.00079 1166 3401d17da50a7f871b536483996a0462 ""
|
||||
"intro/index.tex" 1745518750.07112 2222 96d5bf33e15e2d99900cb9bb0955e210 ""
|
||||
"main.aux" 1745518755.25965 1261 7295b00608a538129f1f3d8e1e94b611 "pdflatex"
|
||||
"main.bbl" 1745518752.8063 466 76d65a242ec496c9b4361af646ff12cb "biber main"
|
||||
"main.run.xml" 1745518755.27359 2301 7adc9b5a22e7927ebfdd8580ad5d647d "pdflatex"
|
||||
"main.tex" 1745515390.16057 722 34633c768624cc239eef0942b140dea1 ""
|
||||
(generated)
|
||||
"main.aux"
|
||||
"main.bcf"
|
||||
"main.log"
|
||||
"main.pdf"
|
||||
"main.run.xml"
|
||||
(rewritten before read)
|
||||
@@ -1,152 +0,0 @@
|
||||
PWD /workspaces/containers/recherches/AllowListDenyList
|
||||
INPUT /usr/local/texlive/2025/texmf.cnf
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/web2c/texmf.cnf
|
||||
INPUT /usr/local/texlive/2025/texmf-var/web2c/pdftex/pdflatex.fmt
|
||||
INPUT /workspaces/containers/recherches/AllowListDenyList/main.tex
|
||||
OUTPUT main.log
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/article.cls
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/article.cls
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/size10.clo
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/size10.clo
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/size10.clo
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/fontenc.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/fontenc.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/map/fontname/texfonts.map
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1000.tfm
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/inputenc.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/inputenc.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/etoolbox/etoolbox.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/etoolbox/etoolbox.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/graphics/keyval.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/graphics/keyval.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.cfg
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.cfg
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.cfg
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/babel.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/babel.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/txtbabel.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel-french/french.ldf
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel-french/french.ldf
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel-french/french.ldf
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-fr.ini
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/carlisle/scalefnt.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/carlisle/scalefnt.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/preprint/authblk.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/preprint/authblk.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/preprint/fullpage.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/preprint/fullpage.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/infwarerr/infwarerr.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/infwarerr/infwarerr.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/iftex/iftex.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/iftex/iftex.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/kvoptions/kvoptions.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/kvoptions/kvoptions.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/ifthen.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/base/ifthen.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/url/url.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/url/url.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-dm.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-dm.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-dm.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-compat.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-compat.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-compat.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/numeric.bbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/numeric.bbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/numeric.bbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/standard.bbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/standard.bbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/standard.bbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/cbx/numeric.cbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/cbx/numeric.cbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/cbx/numeric.cbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.cfg
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.cfg
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.cfg
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-case-expl3.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-case-expl3.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/algorithm2e/algorithm2e.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/algorithm2e/algorithm2e.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/ifoddpage/ifoddpage.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/ifoddpage/ifoddpage.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/tools/xspace.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/tools/xspace.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/relsize/relsize.sty
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/relsize/relsize.sty
|
||||
INPUT ./main.aux
|
||||
INPUT ./main.aux
|
||||
INPUT main.aux
|
||||
OUTPUT main.aux
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/lbx/french.lbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/lbx/french.lbx
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/lbx/french.lbx
|
||||
OUTPUT main.bcf
|
||||
INPUT main.bbl
|
||||
INPUT ./main.bbl
|
||||
INPUT ./main.bbl
|
||||
INPUT ./main.bbl
|
||||
INPUT main.bbl
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1728.tfm
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1200.tfm
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx1200.tfm
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecti1200.tfm
|
||||
OUTPUT main.pdf
|
||||
INPUT /usr/local/texlive/2025/texmf-var/fonts/map/pdftex/updmap/pdftex.map
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/cm-super/cm-super-t1.enc
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecrm1440.tfm
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx1440.tfm
|
||||
INPUT ./intro/index.tex
|
||||
INPUT ./intro/index.tex
|
||||
INPUT intro/index.tex
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx1000.tfm
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecti1000.tfm
|
||||
INPUT ./algo/index.tex
|
||||
INPUT ./algo/index.tex
|
||||
INPUT algo/index.tex
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/jknappen/ec/ecbx0700.tfm
|
||||
INPUT main.aux
|
||||
INPUT main.run.xml
|
||||
OUTPUT main.run.xml
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx0700.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1000.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1200.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1440.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1000.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1200.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1728.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfti1000.pfb
|
||||
INPUT /usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfti1200.pfb
|
||||
@@ -1,491 +0,0 @@
|
||||
This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.3.30) 24 APR 2025 18:19
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
file:line:error style messages enabled.
|
||||
%&-line parsing enabled.
|
||||
**/workspaces/containers/recherches/AllowListDenyList/main.tex
|
||||
(/workspaces/containers/recherches/AllowListDenyList/main.tex
|
||||
LaTeX2e <2024-11-01> patch level 2
|
||||
L3 programming layer <2025-01-18>
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/base/article.cls
|
||||
Document Class: article 2024/06/29 v1.4n Standard LaTeX document class
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/base/size10.clo
|
||||
File: size10.clo 2024/06/29 v1.4n Standard LaTeX file (size option)
|
||||
)
|
||||
\c@part=\count196
|
||||
\c@section=\count197
|
||||
\c@subsection=\count198
|
||||
\c@subsubsection=\count199
|
||||
\c@paragraph=\count266
|
||||
\c@subparagraph=\count267
|
||||
\c@figure=\count268
|
||||
\c@table=\count269
|
||||
\abovecaptionskip=\skip49
|
||||
\belowcaptionskip=\skip50
|
||||
\bibindent=\dimen141
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/base/fontenc.sty
|
||||
Package: fontenc 2021/04/29 v2.0v Standard LaTeX package
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/base/inputenc.sty
|
||||
Package: inputenc 2024/02/08 v1.3d Input encoding file
|
||||
\inpenc@prehook=\toks17
|
||||
\inpenc@posthook=\toks18
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.sty
|
||||
Package: csquotes 2024-04-04 v5.2o context-sensitive quotations (JAW)
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/etoolbox/etoolbox.sty
|
||||
Package: etoolbox 2025/02/11 v2.5l e-TeX tools for LaTeX (JAW)
|
||||
\etb@tempcnta=\count270
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/graphics/keyval.sty
|
||||
Package: keyval 2022/05/29 v1.15 key=value parser (DPC)
|
||||
\KV@toks@=\toks19
|
||||
)
|
||||
\csq@reset=\count271
|
||||
\csq@gtype=\count272
|
||||
\csq@glevel=\count273
|
||||
\csq@qlevel=\count274
|
||||
\csq@maxlvl=\count275
|
||||
\csq@tshold=\count276
|
||||
\csq@ltx@everypar=\toks20
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.def
|
||||
File: csquotes.def 2024-04-04 v5.2o csquotes generic definitions (JAW)
|
||||
)
|
||||
Package csquotes Info: Trying to load configuration file 'csquotes.cfg'...
|
||||
Package csquotes Info: ... configuration file loaded successfully.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/csquotes/csquotes.cfg
|
||||
File: csquotes.cfg
|
||||
)) (/usr/local/texlive/2025/texmf-dist/tex/generic/babel/babel.sty
|
||||
Package: babel 2025/03/27 v25.6 The multilingual framework for pdfLaTeX, LuaLaTeX and XeLaTeX
|
||||
\babel@savecnt=\count277
|
||||
\U@D=\dimen142
|
||||
\l@unhyphenated=\language90
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/generic/babel/txtbabel.def)
|
||||
\bbl@readstream=\read2
|
||||
\bbl@dirlevel=\count278
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/generic/babel-french/french.ldf
|
||||
Language: french 2024-07-25 v3.6c French support from the babel system
|
||||
Package babel Info: Hyphen rules for 'acadian' set to \l@french
|
||||
(babel) (\language30). Reported on input line 91.
|
||||
Package babel Info: Hyphen rules for 'canadien' set to \l@french
|
||||
(babel) (\language30). Reported on input line 92.
|
||||
\FB@stdchar=\count279
|
||||
Package babel Info: Making : an active character on input line 421.
|
||||
Package babel Info: Making ; an active character on input line 422.
|
||||
Package babel Info: Making ! an active character on input line 423.
|
||||
Package babel Info: Making ? an active character on input line 424.
|
||||
\FBguill@level=\count280
|
||||
\FBold@everypar=\toks21
|
||||
\FB@Mht=\dimen143
|
||||
\mc@charclass=\count281
|
||||
\mc@charfam=\count282
|
||||
\mc@charslot=\count283
|
||||
\std@mcc=\count284
|
||||
\dec@mcc=\count285
|
||||
\FB@parskip=\dimen144
|
||||
\listindentFB=\dimen145
|
||||
\descindentFB=\dimen146
|
||||
\labelindentFB=\dimen147
|
||||
\labelwidthFB=\dimen148
|
||||
\leftmarginFB=\dimen149
|
||||
\parindentFFN=\dimen150
|
||||
\FBfnindent=\dimen151
|
||||
)) (/usr/local/texlive/2025/texmf-dist/tex/generic/babel/locale/fr/babel-french.tex
|
||||
Package babel Info: Importing font and identification data for french
|
||||
(babel) from babel-fr.ini. Reported on input line 11.
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/carlisle/scalefnt.sty) (/usr/local/texlive/2025/texmf-dist/tex/latex/preprint/authblk.sty
|
||||
Package: authblk 2001/02/27 1.3 (PWD)
|
||||
\affilsep=\skip51
|
||||
\@affilsep=\skip52
|
||||
\c@Maxaffil=\count286
|
||||
\c@authors=\count287
|
||||
\c@affil=\count288
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/preprint/fullpage.sty
|
||||
Package: fullpage 1999/02/23 1.1 (PWD)
|
||||
\FP@margin=\skip53
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.sty
|
||||
Package: biblatex 2024/03/21 v3.20 programmable bibliographies (PK/MW)
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
|
||||
Package: pdftexcmds 2020-06-27 v0.33 Utility functions of pdfTeX for LuaTeX (HO)
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/generic/infwarerr/infwarerr.sty
|
||||
Package: infwarerr 2019/12/03 v1.5 Providing info/warning/error messages (HO)
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/generic/iftex/iftex.sty
|
||||
Package: iftex 2024/12/12 v1.0g TeX engine tests
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
|
||||
Package: ltxcmds 2023-12-04 v1.26 LaTeX kernel commands for general use (HO)
|
||||
)
|
||||
Package pdftexcmds Info: \pdf@primitive is available.
|
||||
Package pdftexcmds Info: \pdf@ifprimitive is available.
|
||||
Package pdftexcmds Info: \pdfdraftmode found.
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/kvoptions/kvoptions.sty
|
||||
Package: kvoptions 2022-06-15 v3.15 Key value format for package options (HO)
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
|
||||
Package: kvsetkeys 2022-10-05 v1.19 Key value parser (HO)
|
||||
)) (/usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.sty
|
||||
Package: logreq 2010/08/04 v1.0 xml request logger
|
||||
\lrq@indent=\count289
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/logreq/logreq.def
|
||||
File: logreq.def 2010/08/04 v1.0 logreq spec v1.0
|
||||
)) (/usr/local/texlive/2025/texmf-dist/tex/latex/base/ifthen.sty
|
||||
Package: ifthen 2024/03/16 v1.1e Standard LaTeX ifthen package (DPC)
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/url/url.sty
|
||||
\Urlmuskip=\muskip17
|
||||
Package: url 2013/09/16 ver 3.4 Verb mode for urls, etc.
|
||||
)
|
||||
\c@tabx@nest=\count290
|
||||
\c@listtotal=\count291
|
||||
\c@listcount=\count292
|
||||
\c@liststart=\count293
|
||||
\c@liststop=\count294
|
||||
\c@citecount=\count295
|
||||
\c@citetotal=\count296
|
||||
\c@multicitecount=\count297
|
||||
\c@multicitetotal=\count298
|
||||
\c@instcount=\count299
|
||||
\c@maxnames=\count300
|
||||
\c@minnames=\count301
|
||||
\c@maxitems=\count302
|
||||
\c@minitems=\count303
|
||||
\c@citecounter=\count304
|
||||
\c@maxcitecounter=\count305
|
||||
\c@savedcitecounter=\count306
|
||||
\c@uniquelist=\count307
|
||||
\c@uniquename=\count308
|
||||
\c@refsection=\count309
|
||||
\c@refsegment=\count310
|
||||
\c@maxextratitle=\count311
|
||||
\c@maxextratitleyear=\count312
|
||||
\c@maxextraname=\count313
|
||||
\c@maxextradate=\count314
|
||||
\c@maxextraalpha=\count315
|
||||
\c@abbrvpenalty=\count316
|
||||
\c@highnamepenalty=\count317
|
||||
\c@lownamepenalty=\count318
|
||||
\c@maxparens=\count319
|
||||
\c@parenlevel=\count320
|
||||
\blx@tempcnta=\count321
|
||||
\blx@tempcntb=\count322
|
||||
\blx@tempcntc=\count323
|
||||
\c@blx@maxsection=\count324
|
||||
\blx@maxsegment@0=\count325
|
||||
\blx@notetype=\count326
|
||||
\blx@parenlevel@text=\count327
|
||||
\blx@parenlevel@foot=\count328
|
||||
\blx@sectionciteorder@0=\count329
|
||||
\blx@sectionciteorderinternal@0=\count330
|
||||
\blx@entrysetcounter=\count331
|
||||
\blx@biblioinstance=\count332
|
||||
\labelnumberwidth=\skip54
|
||||
\labelalphawidth=\skip55
|
||||
\biblabelsep=\skip56
|
||||
\bibitemsep=\skip57
|
||||
\bibnamesep=\skip58
|
||||
\bibinitsep=\skip59
|
||||
\bibparsep=\skip60
|
||||
\bibhang=\skip61
|
||||
\blx@bcfin=\read3
|
||||
\blx@bcfout=\write3
|
||||
\blx@langwohyphens=\language91
|
||||
\c@mincomprange=\count333
|
||||
\c@maxcomprange=\count334
|
||||
\c@mincompwidth=\count335
|
||||
Package biblatex Info: Trying to load biblatex default data model...
|
||||
Package biblatex Info: ... file 'blx-dm.def' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-dm.def
|
||||
File: blx-dm.def 2024/03/21 v3.20 biblatex datamodel (PK/MW)
|
||||
)
|
||||
Package biblatex Info: Trying to load biblatex custom data model...
|
||||
Package biblatex Info: ... file 'biblatex-dm.cfg' not found.
|
||||
\c@afterword=\count336
|
||||
\c@savedafterword=\count337
|
||||
\c@annotator=\count338
|
||||
\c@savedannotator=\count339
|
||||
\c@author=\count340
|
||||
\c@savedauthor=\count341
|
||||
\c@bookauthor=\count342
|
||||
\c@savedbookauthor=\count343
|
||||
\c@commentator=\count344
|
||||
\c@savedcommentator=\count345
|
||||
\c@editor=\count346
|
||||
\c@savededitor=\count347
|
||||
\c@editora=\count348
|
||||
\c@savededitora=\count349
|
||||
\c@editorb=\count350
|
||||
\c@savededitorb=\count351
|
||||
\c@editorc=\count352
|
||||
\c@savededitorc=\count353
|
||||
\c@foreword=\count354
|
||||
\c@savedforeword=\count355
|
||||
\c@holder=\count356
|
||||
\c@savedholder=\count357
|
||||
\c@introduction=\count358
|
||||
\c@savedintroduction=\count359
|
||||
\c@namea=\count360
|
||||
\c@savednamea=\count361
|
||||
\c@nameb=\count362
|
||||
\c@savednameb=\count363
|
||||
\c@namec=\count364
|
||||
\c@savednamec=\count365
|
||||
\c@translator=\count366
|
||||
\c@savedtranslator=\count367
|
||||
\c@shortauthor=\count368
|
||||
\c@savedshortauthor=\count369
|
||||
\c@shorteditor=\count370
|
||||
\c@savedshorteditor=\count371
|
||||
\c@labelname=\count372
|
||||
\c@savedlabelname=\count373
|
||||
\c@institution=\count374
|
||||
\c@savedinstitution=\count375
|
||||
\c@lista=\count376
|
||||
\c@savedlista=\count377
|
||||
\c@listb=\count378
|
||||
\c@savedlistb=\count379
|
||||
\c@listc=\count380
|
||||
\c@savedlistc=\count381
|
||||
\c@listd=\count382
|
||||
\c@savedlistd=\count383
|
||||
\c@liste=\count384
|
||||
\c@savedliste=\count385
|
||||
\c@listf=\count386
|
||||
\c@savedlistf=\count387
|
||||
\c@location=\count388
|
||||
\c@savedlocation=\count389
|
||||
\c@organization=\count390
|
||||
\c@savedorganization=\count391
|
||||
\c@origlocation=\count392
|
||||
\c@savedoriglocation=\count393
|
||||
\c@origpublisher=\count394
|
||||
\c@savedorigpublisher=\count395
|
||||
\c@publisher=\count396
|
||||
\c@savedpublisher=\count397
|
||||
\c@language=\count398
|
||||
\c@savedlanguage=\count399
|
||||
\c@origlanguage=\count400
|
||||
\c@savedoriglanguage=\count401
|
||||
\c@pageref=\count402
|
||||
\c@savedpageref=\count403
|
||||
\shorthandwidth=\skip62
|
||||
\shortjournalwidth=\skip63
|
||||
\shortserieswidth=\skip64
|
||||
\shorttitlewidth=\skip65
|
||||
\shortauthorwidth=\skip66
|
||||
\shorteditorwidth=\skip67
|
||||
\locallabelnumberwidth=\skip68
|
||||
\locallabelalphawidth=\skip69
|
||||
\localshorthandwidth=\skip70
|
||||
\localshortjournalwidth=\skip71
|
||||
\localshortserieswidth=\skip72
|
||||
\localshorttitlewidth=\skip73
|
||||
\localshortauthorwidth=\skip74
|
||||
\localshorteditorwidth=\skip75
|
||||
Package biblatex Info: Trying to load compatibility code...
|
||||
Package biblatex Info: ... file 'blx-compat.def' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-compat.def
|
||||
File: blx-compat.def 2024/03/21 v3.20 biblatex compatibility (PK/MW)
|
||||
)
|
||||
Package biblatex Info: Trying to load generic definitions...
|
||||
Package biblatex Info: ... file 'biblatex.def' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.def
|
||||
File: biblatex.def 2024/03/21 v3.20 biblatex compatibility (PK/MW)
|
||||
\c@textcitecount=\count404
|
||||
\c@textcitetotal=\count405
|
||||
\c@textcitemaxnames=\count406
|
||||
\c@biburlbigbreakpenalty=\count407
|
||||
\c@biburlbreakpenalty=\count408
|
||||
\c@biburlnumpenalty=\count409
|
||||
\c@biburlucpenalty=\count410
|
||||
\c@biburllcpenalty=\count411
|
||||
\biburlbigskip=\muskip18
|
||||
\biburlnumskip=\muskip19
|
||||
\biburlucskip=\muskip20
|
||||
\biburllcskip=\muskip21
|
||||
\c@smartand=\count412
|
||||
)
|
||||
Package biblatex Info: Trying to load bibliography style 'numeric'...
|
||||
Package biblatex Info: ... file 'numeric.bbx' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/numeric.bbx
|
||||
File: numeric.bbx 2024/03/21 v3.20 biblatex bibliography style (PK/MW)
|
||||
Package biblatex Info: Trying to load bibliography style 'standard'...
|
||||
Package biblatex Info: ... file 'standard.bbx' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/bbx/standard.bbx
|
||||
File: standard.bbx 2024/03/21 v3.20 biblatex bibliography style (PK/MW)
|
||||
\c@bbx:relatedcount=\count413
|
||||
\c@bbx:relatedtotal=\count414
|
||||
))
|
||||
Package biblatex Info: Trying to load citation style 'numeric'...
|
||||
Package biblatex Info: ... file 'numeric.cbx' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/cbx/numeric.cbx
|
||||
File: numeric.cbx 2024/03/21 v3.20 biblatex citation style (PK/MW)
|
||||
Package biblatex Info: Redefining '\cite'.
|
||||
Package biblatex Info: Redefining '\parencite'.
|
||||
Package biblatex Info: Redefining '\footcite'.
|
||||
Package biblatex Info: Redefining '\footcitetext'.
|
||||
Package biblatex Info: Redefining '\smartcite'.
|
||||
Package biblatex Info: Redefining '\supercite'.
|
||||
Package biblatex Info: Redefining '\textcite'.
|
||||
Package biblatex Info: Redefining '\textcites'.
|
||||
Package biblatex Info: Redefining '\cites'.
|
||||
Package biblatex Info: Redefining '\parencites'.
|
||||
Package biblatex Info: Redefining '\smartcites'.
|
||||
)
|
||||
Package biblatex Info: Trying to load configuration file...
|
||||
Package biblatex Info: ... file 'biblatex.cfg' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/biblatex.cfg
|
||||
File: biblatex.cfg
|
||||
)
|
||||
Package biblatex Info: Input encoding 'utf8' detected.
|
||||
Package biblatex Info: Document encoding is UTF8 ....
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/l3kernel/expl3.sty
|
||||
Package: expl3 2025-01-18 L3 programming layer (loader)
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
|
||||
File: l3backend-pdftex.def 2024-05-08 L3 backend support: PDF output (pdfTeX)
|
||||
\l__color_backend_stack_int=\count415
|
||||
\l__pdf_internal_box=\box52
|
||||
))
|
||||
Package biblatex Info: ... and expl3
|
||||
(biblatex) 2025-01-18 L3 programming layer (loader)
|
||||
(biblatex) is new enough (at least 2020/04/06),
|
||||
(biblatex) setting 'casechanger=expl3'.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/blx-case-expl3.sty (/usr/local/texlive/2025/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
|
||||
Package: xparse 2024-08-16 L3 Experimental document command parser
|
||||
)
|
||||
Package: blx-case-expl3 2024/03/21 v3.20 expl3 case changing code for biblatex
|
||||
)) (/usr/local/texlive/2025/texmf-dist/tex/latex/algorithm2e/algorithm2e.sty
|
||||
Package: algorithm2e 2017/07/18 v5.2 algorithms environments
|
||||
\c@AlgoLine=\count416
|
||||
\algocf@hangindent=\skip76
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/ifoddpage/ifoddpage.sty
|
||||
Package: ifoddpage 2022/10/18 v1.2 Conditionals for odd/even page detection
|
||||
\c@checkoddpage=\count417
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/tools/xspace.sty
|
||||
Package: xspace 2014/10/28 v1.13 Space after command names (DPC,MH)
|
||||
) (/usr/local/texlive/2025/texmf-dist/tex/latex/relsize/relsize.sty
|
||||
Package: relsize 2013/03/29 ver 4.1
|
||||
)
|
||||
\skiptotal=\skip77
|
||||
\skiplinenumber=\skip78
|
||||
\skiprule=\skip79
|
||||
\skiphlne=\skip80
|
||||
\skiptext=\skip81
|
||||
\skiplength=\skip82
|
||||
\algomargin=\skip83
|
||||
\skipalgocfslide=\skip84
|
||||
\algowidth=\dimen152
|
||||
\inoutsize=\dimen153
|
||||
\inoutindent=\dimen154
|
||||
\interspacetitleruled=\dimen155
|
||||
\interspacealgoruled=\dimen156
|
||||
\interspacetitleboxruled=\dimen157
|
||||
\algocf@ruledwidth=\skip85
|
||||
\algocf@inoutbox=\box53
|
||||
\algocf@inputbox=\box54
|
||||
\AlCapSkip=\skip86
|
||||
\AlCapHSkip=\skip87
|
||||
\algoskipindent=\skip88
|
||||
\algocf@nlbox=\box55
|
||||
\algocf@hangingbox=\box56
|
||||
\algocf@untilbox=\box57
|
||||
\algocf@skipuntil=\skip89
|
||||
\algocf@capbox=\box58
|
||||
\algocf@lcaptionbox=\skip90
|
||||
\algoheightruledefault=\skip91
|
||||
\algoheightrule=\skip92
|
||||
\algotitleheightruledefault=\skip93
|
||||
\algotitleheightrule=\skip94
|
||||
\c@algocfline=\count418
|
||||
\c@algocfproc=\count419
|
||||
\c@algocf=\count420
|
||||
\algocf@algoframe=\box59
|
||||
\algocf@algobox=\box60
|
||||
)
|
||||
\c@theorem=\count421
|
||||
Package csquotes Info: Checking for multilingual support...
|
||||
Package csquotes Info: ... found 'babel' package.
|
||||
Package csquotes Info: Adjusting default style.
|
||||
Package csquotes Info: Redefining alias 'default' -> 'french'.
|
||||
(./main.aux
|
||||
Package babel Info: 'french' activates 'french' shorthands.
|
||||
(babel) Reported on input line 10.
|
||||
)
|
||||
\openout1 = `main.aux'.
|
||||
|
||||
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 18.
|
||||
LaTeX Font Info: ... okay on input line 18.
|
||||
LaTeX Info: Redefining \degres on input line 18.
|
||||
LaTeX Info: Redefining \up on input line 18.
|
||||
Package biblatex Info: Trying to load language 'french'...
|
||||
Package biblatex Info: ... file 'french.lbx' found.
|
||||
(/usr/local/texlive/2025/texmf-dist/tex/latex/biblatex/lbx/french.lbx
|
||||
File: french.lbx 2024/03/21 v3.20 biblatex localization (PK/MW)
|
||||
)
|
||||
Package biblatex Info: Input encoding 'utf8' detected.
|
||||
Package biblatex Info: Automatic encoding selection.
|
||||
(biblatex) Assuming data encoding 'utf8'.
|
||||
\openout3 = `main.bcf'.
|
||||
|
||||
Package biblatex Info: Trying to load bibliographic data...
|
||||
Package biblatex Info: ... file 'main.bbl' found.
|
||||
(./main.bbl)
|
||||
Package biblatex Info: Reference section=0 on input line 18.
|
||||
Package biblatex Info: Reference segment=0 on input line 18.
|
||||
|
||||
|
||||
[1
|
||||
|
||||
{/usr/local/texlive/2025/texmf-var/fonts/map/pdftex/updmap/pdftex.map}{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/cm-super/cm-super-t1.enc}] (./intro/index.tex
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <7> on input line 5.
|
||||
LaTeX Font Info: External font `cmex10' loaded for size
|
||||
(Font) <5> on input line 5.
|
||||
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 12--14
|
||||
|
||||
[]
|
||||
|
||||
) (./algo/index.tex
|
||||
|
||||
[1]
|
||||
Underfull \hbox (badness 10000) in paragraph at lines 21--26
|
||||
|
||||
[]
|
||||
|
||||
)
|
||||
|
||||
LaTeX Warning: Empty bibliography on input line 38.
|
||||
|
||||
|
||||
|
||||
[2] (./main.aux)
|
||||
***********
|
||||
LaTeX2e <2024-11-01> patch level 2
|
||||
L3 programming layer <2025-01-18>
|
||||
***********
|
||||
Package logreq Info: Writing requests to 'main.run.xml'.
|
||||
\openout1 = `main.run.xml'.
|
||||
|
||||
)
|
||||
Here is how much of TeX's memory you used:
|
||||
12402 strings out of 473190
|
||||
235027 string characters out of 5715806
|
||||
1085239 words of memory out of 5000000
|
||||
35573 multiletter control sequences out of 15000+600000
|
||||
566378 words of font info for 46 fonts, out of 8000000 for 9000
|
||||
1141 hyphenation exceptions out of 8191
|
||||
66i,18n,81p,745b,1731s stack positions out of 10000i,1000n,20000p,200000b,200000s
|
||||
</usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx0700.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1000.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1200.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfbx1440.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1000.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1200.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfrm1728.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfti1000.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/cm-super/sfti1200.pfb>
|
||||
Output written on main.pdf (3 pages, 194797 bytes).
|
||||
PDF statistics:
|
||||
80 PDF objects out of 1000 (max. 8388607)
|
||||
48 compressed objects within 1 object stream
|
||||
0 named destinations out of 1000 (max. 500000)
|
||||
1 words of extra memory for PDF output out of 10000 (max. 10000000)
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@@ -1,63 +0,0 @@
|
||||
\documentclass{article}
|
||||
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{csquotes}
|
||||
\usepackage[french]{babel}
|
||||
\usepackage[affil-it]{authblk}
|
||||
\usepackage{fullpage}
|
||||
|
||||
\usepackage{amsmath}
|
||||
\usepackage{amssymb}
|
||||
|
||||
\usepackage{biblatex}
|
||||
|
||||
% \usepackage[linesnumbered,ruled,vlined]{algorithm2e}
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algorithmicx}
|
||||
\usepackage[noend]{algpseudocode}
|
||||
\algrenewcommand\alglinenumber[1]{\tiny #1}
|
||||
|
||||
\usepackage{etoolbox}
|
||||
|
||||
% --- Partage du compteur de lignes entre plusieurs algorithmes
|
||||
\makeatletter
|
||||
\newcounter{algoLine}
|
||||
\renewcommand{\alglinenumber}[1]{\arabic{algoLine}}
|
||||
\newcommand{\nextalgline}{\stepcounter{algoLine}}
|
||||
\newcommand{\resetalgline}{\setcounter{algoLine}{1}}
|
||||
\makeatother
|
||||
|
||||
\newtheorem{property}{Property}
|
||||
\newtheorem{theorem}{Theorem}
|
||||
\newtheorem{proof}{Proof}
|
||||
|
||||
\addbibresource{sources.bib}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{???}
|
||||
\author{JOLY Amaury \\ \textbf{Encadrants :} GODARD Emmanuel, TRAVERS Corentin}
|
||||
\affil{Aix-Marseille Université, Scille}
|
||||
\date{\today}
|
||||
|
||||
\begin{titlepage}
|
||||
\maketitle
|
||||
\end{titlepage}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
\subsection{Model}
|
||||
\input{intro/index.tex}
|
||||
|
||||
\subsection{Algorithms}
|
||||
\input{algo/index.tex}
|
||||
|
||||
\subsection{proof}
|
||||
\input{proof/index.tex}
|
||||
|
||||
\printbibliography
|
||||
|
||||
|
||||
\end{document}
|
||||
@@ -1,121 +0,0 @@
|
||||
\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 $\text{AB-deliver}_j(m)$ occurs.
|
||||
|
||||
\begin{align*}
|
||||
&\text{AB-deliver}_j(m) & \text{(line 24)} \\
|
||||
\Rightarrow\; &\exists r_0 : m \in \texttt{ordered}(M^{r_0}) & \text{(line 22)} \\
|
||||
\Rightarrow\; &\exists j_0 : j_0 \in \textit{winner}^{r_0} \land m \in \textit{prop}[r_0][j_0] & \text{(line 21)} \\
|
||||
\Rightarrow\; &\exists m_0, S_0 : \text{RB-received}_{j_0}(m_0, S_0, r_0, j_0) \land m \in S_0 & \text{(line 2)} \\
|
||||
\Rightarrow\; &S_0 = (\textit{received}_{j_0} \setminus \textit{delivered}_{j_0}) \cup \{m_1\} & \text{(line 5)} \\
|
||||
\Rightarrow\; &\textbf{if } m_1 = m: \exists\, \text{AB-broadcast}_{j_0}(m) \hspace{1em} \square \\
|
||||
&\textbf{else if } m_1 \neq m: \\
|
||||
&\quad m \in \textit{received}_{j_0} \setminus \textit{delivered}_{j_0} \Rightarrow m \in \textit{received}_{j_0} \land m \notin \textit{delivered}_{j_0} \\
|
||||
&\quad \exists j_1, S_1, r_1 : \text{RB-received}_{j_1}(m, S_1, r_1, j_1) & \text{(line 1)} \\
|
||||
&\quad \Rightarrow \exists\, \text{AB-broadcast}_{j_1}(m) \hspace{1em} \square & \text{(line 5)}
|
||||
\end{align*}
|
||||
\end{proof}
|
||||
|
||||
|
||||
|
||||
|
||||
\begin{theorem}[No Duplication]
|
||||
No message is delivered more than once by any process.
|
||||
\end{theorem}
|
||||
|
||||
\begin{proof}
|
||||
Let $j$ be a process such that both $\text{AB-deliver}_j(m_0)$ and $\text{AB-deliver}_j(m_1)$ occur, with $m_0 = m_1$.
|
||||
|
||||
\begin{align*}
|
||||
&\text{AB-deliver}_j(m_0) \wedge \text{AB-deliver}_j(m_1) & \text{(line 24)} \\
|
||||
\Rightarrow\; & m_0, m_1 \in \textit{delivered}_j & \text{(line 23)} \\
|
||||
\Rightarrow\; &\exists r_0, r_1 : m_0 \in M^{r_0} \wedge m_1 \in M^{r_1} & \text{(line 22)} \\
|
||||
\Rightarrow\; &\exists j_0, j_1 : m_0 \in \textit{prop}[r_0][j_0] \wedge m_1 \in \textit{prop}[r_1][j_1] \\
|
||||
&\hspace{2.5em} \wedge\ j_0 \in \textit{winner}^{r_0},\ j_1 \in \textit{winner}^{r_1} & \text{(line 21)}
|
||||
\end{align*}
|
||||
|
||||
We now distinguish two cases:
|
||||
|
||||
\vspace{0.5em}
|
||||
\noindent\textbf{Case 1:} $r_0 = r_1$:
|
||||
\begin{itemize}
|
||||
\item If $j_0 \neq j_1$: this contradicts message uniqueness, since two different processes would include the same message in round $r_0$.
|
||||
\item If $j_0 = j_1$:
|
||||
\begin{align*}
|
||||
\Rightarrow & |{(j_0, \texttt{PROVE}(r_0)) \in proves}| \geq 2 & \text{(line 19)}\\
|
||||
\Rightarrow &\texttt{PROVE}_{j_0}(r_0) \text{ occurs 2 times} & \text{(line 6)}\\
|
||||
\Rightarrow &\texttt{AB-Broadcast}_{j_0}(m_0) \text{ were invoked two times} \\
|
||||
\Rightarrow &(max\{r: \exists j, (j, \texttt{PROVE}(r)) \in proves\} + 1) & \text{(line 4)}\\
|
||||
&\text{ returned the same value in two differents invokations of \texttt{AB-Broadcast}} \\
|
||||
&\textbf{But } \texttt{PROVE}(r_0) \Rightarrow \texttt{max}\{r: \exists j, (j, \texttt{PROVE}(r)) \in proves\} + 1 > r_0 \\
|
||||
&\text{It's impossible for a single process to submit two messages in the same round} \hspace{1em} \\
|
||||
\end{align*}
|
||||
\end{itemize}
|
||||
|
||||
% \vspace{0.5em}
|
||||
\noindent\textbf{Case 2:} $r_0 \ne r_1$:
|
||||
\begin{itemize}
|
||||
\item If $j_0 \neq j_1$: again, message uniqueness prohibits two different processes from broadcasting the same message in different rounds.
|
||||
\item If $j_0 = j_1$: message uniqueness also prohibits the same process from broadcasting the same message in two different rounds.
|
||||
\end{itemize}
|
||||
|
||||
In all cases, we reach a contradiction. Therefore, it is impossible for a process to deliver the same message more than once. $\square$
|
||||
\end{proof}
|
||||
|
||||
% \subsubsection{No Duplication}
|
||||
|
||||
% $M = (\bigcup_{i \rightarrow |P|} AB\_receieved_{i}(m)), \not\exists m_0 m_1 \in M \text{s.t. } m_1 = m_2$
|
||||
% \\
|
||||
% Proof \\
|
||||
% \begin{align*}
|
||||
% &\text{Soit } i, m_0, m_1 \text{ tels que } m_0 = m_1 \\
|
||||
% &\exists r_0,\ m_0 \in M^{r_0} \\
|
||||
% &\exists r_1,\ m_1 \in M^{r_1} \\
|
||||
% &\text{if } r_0 = r_1 \\
|
||||
% &\quad \exists j_0, j_1,\ \text{prop tq } \text{prop}[r_0][j_0] = m_0,\ \text{prop}[r_0][j_1] = m_1 \quad j_0, j_1 \in \text{winnner}^{r_0} \\
|
||||
% &\quad \text{if} j_0 \neq j_1 \\
|
||||
% &\quad\quad \text{On admet qu'il est impossible pour un processus de soumettre le même msg qu'un autre} \\
|
||||
% &\quad \text{if } j_0 = j_1 \\
|
||||
% &\quad\quad j_0 \text{ a émis son } \text{PROVE}(r_0) \text{ valide 2 fois}\\
|
||||
% &\quad\quad \text{Impossible si } j_0 \text{ correct} \\
|
||||
% &\text{else} \\
|
||||
% &\quad \exists j_0, j_1,\ \text{prop tq } \text{prop}[r_0][j_0] = m_0,\ \text{prop}[r_0][j_1] = m_1 \quad j_0, j_1 \in \text{winnner}^{r_0} \\
|
||||
% &\quad \text{if } j_0 \neq j_1 \\
|
||||
% &\quad\quad \text{On admet qu'il est impossible pour un processus de soumettre le même msg qu'un autre} \\
|
||||
% &\quad \text{if } j_0 = j_1 \\
|
||||
% &j_0 \text{ à emis et validé 2 fois le même messages a des rounds différents.}\\
|
||||
% &\text{On admet que deux message identiques soumis a des rounds différents ne peuvent être identiques}
|
||||
% \end{align*}
|
||||
|
||||
\subsubsection{Broadcast Validity}
|
||||
$\exists j_0, m_0 \quad AB\_broadcast_{j_0}(m_0) \Rightarrow \forall j_1 \quad AB\_received_{j_1}(m_0)$ \\
|
||||
|
||||
Proof:
|
||||
\begin{align*}
|
||||
&\exists j_0, m_0 \quad AB\_broadcast_{j_0}(m_0) \\
|
||||
&\forall j_1, \exists r_1 \quad RB\_deliver_{j_1}^{r_1}(m_0) \\
|
||||
&\exists receieved : m_0 \in receieved_{j_1} \\
|
||||
&\exists r_0 : RB\_deliver(PROP, r_0, m_0) & LOOP\\
|
||||
&\exists prop: \text{prop}[r_0][j_0] = m_0 \\
|
||||
&\text{if } \not\exists (j_0, PROVE(r_0)) \in \text{proves} \\
|
||||
&\quad r_0 += 1 \\
|
||||
&\quad \text{jump to LOOP} \\
|
||||
&\text{else} \\
|
||||
&\quad \exists \text{winner}, \text{winner}^{r_0} \ni j_0 \\
|
||||
&\quad \exists M^{r_0} \ni (\text{prop}[r_0][j_0] = m_0) \\
|
||||
&\quad \forall j_1, \quad AB\_deliver_{j_1}(m_0)
|
||||
\end{align*}
|
||||
|
||||
\subsubsection*{AB receive width}
|
||||
\[
|
||||
\exists j_0, m_0 \quad AB\_deliver_{j_0}(m_0) \Rightarrow \forall j_1\ AB\_deliver_{j_1}
|
||||
\]
|
||||
|
||||
Proof:
|
||||
\begin{align*}
|
||||
&\forall j_0, m_0\ AB\_deliver_{j_0}(m_0) \Rightarrow \exists j_1 \text{ correct }, AB\_broadcast(m_0) \\
|
||||
&\exists j_0, m_0 \quad AB\_broadcast_{j_0}(m_0) \Rightarrow \forall j_1,\ AB\_deliver_{j_1}(m_0)
|
||||
\end{align*}
|
||||
40
Recherche/BFT-ARBover/.latexmkrc
Normal file
40
Recherche/BFT-ARBover/.latexmkrc
Normal file
@@ -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;
|
||||
34
Recherche/BFT-ARBover/2_Primitives/index.tex
Normal file
34
Recherche/BFT-ARBover/2_Primitives/index.tex
Normal file
@@ -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$).
|
||||
6
Recherche/BFT-ARBover/3_ARB_Def/index.tex
Normal file
6
Recherche/BFT-ARBover/3_ARB_Def/index.tex
Normal file
@@ -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).
|
||||
455
Recherche/BFT-ARBover/4_ARB_with_RB_DL/index.tex
Normal file
455
Recherche/BFT-ARBover/4_ARB_with_RB_DL/index.tex
Normal file
@@ -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}
|
||||
428
Recherche/BFT-ARBover/5_BFT_ARB/index.tex
Normal file
428
Recherche/BFT-ARBover/5_BFT_ARB/index.tex
Normal file
@@ -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}
|
||||
54
Recherche/BFT-ARBover/diagrams/BFT_behaviour.puml
Normal file
54
Recherche/BFT-ARBover/diagrams/BFT_behaviour.puml
Normal file
@@ -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
|
||||
113
Recherche/BFT-ARBover/diagrams/BFT_behaviour.tex
Normal file
113
Recherche/BFT-ARBover/diagrams/BFT_behaviour.tex
Normal file
@@ -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}
|
||||
37
Recherche/BFT-ARBover/diagrams/classic_seq.puml
Normal file
37
Recherche/BFT-ARBover/diagrams/classic_seq.puml
Normal file
@@ -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
|
||||
127
Recherche/BFT-ARBover/diagrams/classic_seq.tex
Normal file
127
Recherche/BFT-ARBover/diagrams/classic_seq.tex
Normal file
@@ -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}
|
||||
32
Recherche/BFT-ARBover/diagrams/nonBFT_behaviour.puml
Normal file
32
Recherche/BFT-ARBover/diagrams/nonBFT_behaviour.puml
Normal file
@@ -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
|
||||
93
Recherche/BFT-ARBover/diagrams/nonBFT_behaviour.tex
Normal file
93
Recherche/BFT-ARBover/diagrams/nonBFT_behaviour.tex
Normal file
@@ -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}
|
||||
BIN
Recherche/BFT-ARBover/dlarb.pdf
Normal file
BIN
Recherche/BFT-ARBover/dlarb.pdf
Normal file
Binary file not shown.
BIN
Recherche/BFT-ARBover/main.pdf
Normal file
BIN
Recherche/BFT-ARBover/main.pdf
Normal file
Binary file not shown.
303
Recherche/BFT-ARBover/main.tex
Normal file
303
Recherche/BFT-ARBover/main.tex
Normal file
@@ -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}
|
||||
79
Recherche/Raynal18.md
Executable file
79
Recherche/Raynal18.md
Executable file
@@ -0,0 +1,79 @@
|
||||
# Michel Raynal - FAULT-TOLERANT DISTRIBUTED SERVICES IN MESSAGE-PASSING SYSTEMS
|
||||
|
||||
## Connexes
|
||||
|
||||
Comprendre la théorie derrière le Failure Detector. __T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,” J. ACM, vol. 43, no. 2, pp. 225–267, 1996.__
|
||||
|
||||
## Definition
|
||||
|
||||
Fault-Tolerence: The service remains uninterrupted even if some component in the network fail.
|
||||
Distributed System: A collection of computers (or nodes) that communicate amongst themselves [...] to perform a given task.
|
||||
Distributed Computing: The use of a Distributed System to solve a computational problems.
|
||||
Static system: The system composition is fixed.
|
||||
Dynamic system: nodes may enter, leave or move in the system with time.
|
||||
FLP impossibility result: It is impossible to design a distributed system that is both asynchronous and fault-tolerant.
|
||||
|
||||
ADD (Average Delayed/Dropped): model used to describe realisticly the network.
|
||||
|
||||
Data-Strcutures:
|
||||
|
||||
- linearizability: a data structure is said to be linearizable if it guarantees that all operations appear to happen at a single pointin time between the invocation and response of the operation.
|
||||
- Shared Register: [a data strcuture] that stores a value and has two opérations: read [...] and write.
|
||||
- Fault-Tolerent Register: Linearizable (atomic) Shared register.
|
||||
|
||||
Attacks:
|
||||
|
||||
- crash: a node halts, but was working correctly until it halts.
|
||||
- omission: a node fails to receive incoming messages or send outgoing messages.
|
||||
- timing: a node's message delivery lies outside of the specified delivery time interval.
|
||||
- Byzantine: Malicious attacks, operator mistake, software errors and conventional crash faults.
|
||||
- churn: change in system composition due to nodes entering and leaving.
|
||||
|
||||
Usefull terms:
|
||||
|
||||
- shared memory/message-passing model
|
||||
- synchronous/asynchronous systems
|
||||
- static/dynamic systems
|
||||
|
||||
|
||||
algorithms of sharded registers:
|
||||
- RAMBO
|
||||
- DynaStore
|
||||
- Baldoni et Al.
|
||||
|
||||
## Chapter 1
|
||||
|
||||
He's began to define the terms of distributed systemsn and the possibles uses cases.
|
||||
He define synchronous message-passing systems as giving the best guarantees. Opposite to asynchronous message-passing systems.
|
||||
|
||||
### Failure Detectors
|
||||
|
||||
He's defining te concept of Failure Detectors as an oracle able to identify the failed nodes. And how they can be used to circumvent the FLP impossibility result.
|
||||
Actually the Failure Detectors needs a certain level of synchronicity to work. And two lines of research are proposed to solve this problem: The first one is to implement the Failure Detector on a increasingly weaker system model. And the second one is to find the weakest Failure Detector.
|
||||
|
||||
### Fault-Tolerant Register
|
||||
|
||||
He defined a "shared register" and explained how it's complicated to implementing them due to the possibility of faulty nodes. And he present the solution who's the Fault-Tolerant Register. He also present the "linearizability" property and how it's used to define the Fault-Tolerant Register.
|
||||
Finally he introduce two implementation of the Fault-Tolerant Register: one who's crash-tolerent and the other one who's Byzantine-tolerent.
|
||||
|
||||
## Chapter 2
|
||||
|
||||
He precised the context of the implementation. We are on an arbitrary, partitionnable network composed of Average Delayed/Dropped channels (ADD).
|
||||
The failure detectors can be defined by their accuracy and completness tel que:
|
||||
|
||||
- Strong completeness is satisfied if the failure detector of each node eventually suspects all nodes that are crashed.
|
||||
- Eventual strong accuracy is satisfied if the failure detector of every node eventually stops suspecting all nodes that are correct.
|
||||
|
||||
He described he's algorithm.
|
||||
|
||||
## Chapter 3.1
|
||||
|
||||
He purposed a new Fault-Tolerant Register who's crash-tolerent and churn proof.
|
||||
The algorithm is tolerent of node who could crash or leave the system.
|
||||
There is no hierarchy between the nodes. And the algorithm emulated a shared memory using the message-passing model.
|
||||
|
||||
## Chapter 3.2
|
||||
|
||||
He purposed a new Fault-Tolerant Register who's crash-tolerent and churn and Byzantin proof.
|
||||
The model add a notion of server in the previous model (where we had only clients). And a system of asymetric signature.
|
||||
Also he proved than it's impossible with thiss model to determine the number of Byzantin server as a fraction of the total number of servers.
|
||||
405
Recherche/Stage.bib
Executable file
405
Recherche/Stage.bib
Executable file
@@ -0,0 +1,405 @@
|
||||
|
||||
@article{van_der_linde_practical_2020,
|
||||
title = {Practical client-side replication: weak consistency semantics for insecure settings},
|
||||
volume = {13},
|
||||
issn = {2150-8097},
|
||||
url = {https://dl.acm.org/doi/10.14778/3407790.3407847},
|
||||
doi = {10.14778/3407790.3407847},
|
||||
shorttitle = {Practical client-side replication},
|
||||
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.},
|
||||
pages = {2590--2605},
|
||||
number = {12},
|
||||
journaltitle = {Proceedings of the {VLDB} Endowment},
|
||||
shortjournal = {Proc. {VLDB} Endow.},
|
||||
author = {Van Der Linde, Albert and Leitão, João and Preguiça, Nuno},
|
||||
urldate = {2023-06-06},
|
||||
date = {2020-08},
|
||||
langid = {english},
|
||||
annotation = {Fiche Lecture
|
||||
Résumé:
|
||||
Le papier spécifie une amélioration de la cohérence causale, rajoutant des propriétés en renforçant la sécurité. Ils comparent ensuite différentes implémentations de leurs solutions en axant sur le besoin d'une faible latence pour privilégier l'interactivité.
|
||||
Plan:
|
||||
|
||||
|
||||
Présente les attaques possibles sur la cohérence causale. \$3
|
||||
|
||||
|
||||
Définissent les propriétés d'une cohérence causale sécurisée répondant aux attaques. \$4
|
||||
|
||||
|
||||
Définit de nouvelles classes de cohérence étendant la cohérence causale. \$5
|
||||
|
||||
|
||||
Définit des algorithmes pour implémenter ces classes de cohérence. \$5
|
||||
|
||||
|
||||
Présente des résultats de performance de ces algorithmes. \$6
|
||||
|
||||
|
||||
Détails du document
|
||||
Types d'attaques
|
||||
|
||||
|
||||
Tempering: un nœud soumet une opération pour anticiper une opération en attente qui n'a pas encore été exécutée par le système.
|
||||
|
||||
|
||||
Omitting dependencies: un nœud n'utilise qu'un sous-ensemble des opérations dans la dépendance. Il sera en mesure de soumettre une tâche concurrente au système.
|
||||
|
||||
|
||||
Unseen dependencies (également appelé add): un nœud soumet une opération qui dépend d'une opération qu'il n'a pas vue. Il permet à l'attaquant d'anticiper une opération. (C'est différent du tempering car dans ce cas l'opération n'existe pas encore).
|
||||
|
||||
|
||||
Combining omitting and unseen: un nœud peut omettre une dépendance et soumettre une opération qui dépend d'une opération qu'il n'a pas vue.
|
||||
|
||||
|
||||
Sibbling generation: créer deux opérations différentes avec le même id. L'attaquant pourrait créer une divergence permanente entre les nœuds.
|
||||
|
||||
|
||||
Propriétés d'une cohérence causale sécurisée
|
||||
|
||||
|
||||
Immutable History: Chaque opération est envoyée avec son passé causal à chaque nœud valide. (Contrecarre le tempering)
|
||||
|
||||
|
||||
No Future Dependencies Chaque opération est envoyée avec son état de connaissance de l'état des nœuds du système. (Contrecarre l'unseen dependencies puisque l'opération sera considérée par l'ensemble du système comme "en retard" et sera donc ignorée)
|
||||
|
||||
|
||||
Causal Execution: Toute opération \$o\_i\$ appartenant au passé causal d'une opération \$o\$ doit être sérialisable t.q. : \$o\_i {\textless} o\$. (Force une sorte de synchronisation entre les nœuds)
|
||||
|
||||
|
||||
Eventual Sibling Detection: Chaque opération doit être considérée comme une faute éventuelle et doit donc avoir la possibilité d'être révoqué. La révocation ne peut se produire qu'après l'exécution de l'opération. (Assure que si deux opérations sont créées avec un même identifiant et crée une divergence, alors les nœuds auront toujours un moyen de retourner à un état convergent. Contrecarre **en partie** le sibling generation)
|
||||
|
||||
|
||||
Limitted Omission:
|
||||
|
||||
|
||||
{\textless}!-- {OLD}
|
||||
\# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
|
||||
\#\# Authors: van der Linde, Leitao, Preguica
|
||||
\#\# Definition
|
||||
causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
|
||||
Attacks on causal consistency:
|
||||
- Tempering: a node submit an operation to anticipate a pending operation actually not yet executed by the system.
|
||||
- Omitting dependencies: a node used only a subset of the operations in the dependency. He will be able to submit a concurrent task to the system.
|
||||
- Unseen dependencies (also called add): a node submit an operation that depends on an operation that he didn't see. It can be usefull for the attacker to anticipate the operation. (This is different from tempering because in this case the operation does not exist yet).
|
||||
- Combining omitting and unseen: a node can omit a dependency and submit an operation that depends on an operation that he didn't see.
|
||||
- Sibbling generation: creating two differents operations with the same id. The attacker could create a permanent state divergence between the nodes.
|
||||
\#\# Summary
|
||||
\#\#\# Solutions used in the paper
|
||||
\#\#\#\# Secure Causal Consistency
|
||||
Autors defined the properties of a secure causal consistency: Immutable History, No Future Dependencies, Causal Executions, Limitted Omission, and Eventual Sibling Detection.
|
||||
The algorithms they propose used the following solutions for each property:
|
||||
- Immutable History: The nodes sign the operations and the dependencies. The nodes can't temper the history because they can't sign the operation.
|
||||
- No Future Dependencies: Each operations includes a hash of all direct causal dependencies. The nodes can't omit dependencies because they can't sign the operation.
|
||||
- Causal Executions: The nodes need to verify, before executing an operation, that all the dependencies are executed.
|
||||
- Limitted Omission: It's by design impossible due to the metadata (hash of the dependencies).
|
||||
- Eventual Sibling Detection: Many mechanism are used:
|
||||
- a node is able to detect when two operations with the same id are send from differents paths.
|
||||
- a node is able than the hash of the dependencies is different with the hash provide by the operation.
|
||||
- the nodes are comparing the dependencies of the operation between them. If they are different, they are able to detect the sibbling generation.
|
||||
\#\#\#\# Secure Strict Causal Consistency
|
||||
The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel {SGX}. Thus the usage of a hash of the dependencies is unnecessary.
|
||||
An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow.
|
||||
This sollution was not explored in the paper due to this issue. --{\textgreater}
|
||||
|
||||
},
|
||||
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},
|
||||
}
|
||||
|
||||
@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.},
|
||||
pagetotal = {194},
|
||||
publisher = {{ISTE} Group},
|
||||
author = {Perrin, Matthieu},
|
||||
date = {2017-09-01},
|
||||
langid = {french},
|
||||
note = {Google-Books-{ID}: 6DRlDwAAQBAJ},
|
||||
annotation = {Fiche Lecture
|
||||
Réflexions
|
||||
Un peu de mal à comprendre les bornes de cohérence.
|
||||
Ça veut dire quoi composable ?
|
||||
Définitions
|
||||
Système réparti : Collection d'entités de calcul autonomes connectées en vue d'accomplir une tâche commune.
|
||||
Entités de calcul : (ou processus). Entité d'un réseau capable de décision en fonction de stimuli.
|
||||
Cohérence forte : Les objets ciblés cachent la concurrence et se comportent comme si tous les accès était séquentiels.
|
||||
Introduction
|
||||
Un système réparti est caractérisé par :
|
||||
|
||||
|
||||
L'échelle du système
|
||||
|
||||
|
||||
Les moyens d'interactions
|
||||
|
||||
|
||||
Gestion des fautes (c.f. : reynal18 attacks) (et nombre de fautes acceptables)
|
||||
|
||||
|
||||
Rapport au temps (y a-t-il une horloge partagée ?)
|
||||
|
||||
|
||||
Les histoires concurrentes
|
||||
Une histoire concurrente est un ensemble d'événements partiellement ordonnés par un ordre de processus et étiquetés par des opérations.
|
||||
3 primitives possibles :
|
||||
|
||||
|
||||
Broadcast (diffusion fiable) :
|
||||
|
||||
|
||||
Validité : tout message reçu est émis par un processus
|
||||
|
||||
|
||||
Uniformité : tout message reçu par un processus est reçu par tous les autres processus
|
||||
|
||||
|
||||
{FIFO} Broadcast (idem Broadcast) :
|
||||
|
||||
|
||||
Réception {FIFO} : tout message reçu par un processus est reçu dans l'ordre d'émission
|
||||
|
||||
|
||||
Causal Broadcast (idem {FIFO} Broadcast) :
|
||||
|
||||
|
||||
Réception causale : Tout message \$m'\$ envoyé par un processus après réception d'un message \$m\$ est aussi reçu après \$m\$ chez tous les autres processus
|
||||
|
||||
|
||||
|
||||
|
||||
Composabilité
|
||||
La compossibilité définit la possibilité pour deux types de données abstraits différents, cohérente pris de manière unitaire, de pouvoir être combinés tout en gardant leurs cohérences.
|
||||
Décomposable
|
||||
La décomposabilité définit la possibilité pour deux types de données abstraits différents cohérents si considérés "ensemble" de rester cohérent si considérés séparément.
|
||||
Localité
|
||||
La localité est le respect simultané de la composabilité et de la décomposabilité.
|
||||
Modèles
|
||||
Cohérence forte impossible dans des environnements crédibles de cloud. (Trop de risques de déni de services)
|
||||
Ci-dessous une liste des différents paradigmes de modélisation de système répartis :
|
||||
Cohérence Séquentiel (Décomposable, Fort)
|
||||
Cohérence Séquentiel ({SC}) : Les objets ciblés cachent la concurrence et se comportent comme si tous les accès était séquentiels.
|
||||
Le but est de mimer le comportement "comme si" un serveur centralisait et ordonnait l'information. (Ça peut être le cas ou non, il faut juste que la propriété soit respectée).
|
||||
Il y a un débat sur une notion de la cohérence séquentielle. La première formalisation de ce type de cohérence formulé par Lamport oublie de mentionner la notion de "synchronisation". Ce qui peut conduire a des comportements non cohérents. Elle permet par exemple l'existence d'histoires infinies qui viennent s'ajouter les unes derrières les autres. Ce qui serait absurde dans un système réel. (Exemple : infinité de lectures suivie d'une infinité d'écritures).
|
||||
Il y a donc débat sur la notion de cohérence séquentielle avec une école qui considère ce cas comme plausible et une autre qui souhaite rajouter une notion de synchronisation.
|
||||
Linéarisabilité ()
|
||||
Il y a ici un lien fort entre l'ordre d'action du processus et son intégration au système. Il y a une synchronicité plus forte.
|
||||
Ici lorsqu'un processus souhaite accéder à un objet, s'il ne rentre pas en conflit avec aucune action d'écriture, il récupère la valeur antérieure à son exécution. (propriété : Registre Sûr).
|
||||
Si plusieurs processus veulent accéder à un objet, et entrent en concurrence avec une écriture, alors ils ne peuvent retourner seulement la valeur avant ou après l'écriture (propriété : Registre Régulier).
|
||||
Si deux lectures ne sont pas concurrentes, alors elles doivent retourner une valeur au moins aussi récente que la lecture antérieure. (propriété : Registre Atomique).
|
||||
Sérialisabilité (Décomposable, Faible)
|
||||
{ACID} : Atomicité (une transaction est soit complètement acceptée soit complètement avortée), Cohérence (Une transaction exécutée dans un état correct emmène vers un état correct), Isolation (Les transactions n'interfèrent pas entre elles), Durabilité (une transaction acceptée n'est pas remise en cause).
|
||||
La sérialisabilité est similaire à la linéarisabilité, à la différence que des transactions peuvent être avortés. Cela à pour effet de rendre le système moins "fort" en termes de consistance.
|
||||
Convergence (Composable, Faible)
|
||||
La convergence est une notion de cohérence faible. Elle définit un système qui peut à un instant \$t\$ être divergent, mais qui finira sur un temps infini à converger vers un état commun.
|
||||
Convergence forte (Composable, Faible)
|
||||
La convergence forte est une extension de la convergence où notre histoire est divisée en plusieurs états. Chaque transaction se trouve dans un état avec d'autres transactions avec qui elle partage un "passé commun". On définit le passé commun comme la base de connaissance antérieur à l'exécution de la transaction.
|
||||
Data type pour la convergence
|
||||
Les types de données vues pour les autres modèles sont peu adapté pour modéliser les interactions dans le cas de la convergence. On privilégie plutôt des types de données qui permettent de définir des états (ex : {OR}-{SET}).
|
||||
Intention
|
||||
L'intention est une notion qui tend à appliquer la cohérence en fonction de l'intention des utilisateurs. Elle trouve son sens particulièrement dans l'édition collaborative lors d'écritures concurrentes. Mais sa spécification reste floue et c'est un concept qui semble difficile à appliquer.
|
||||
Cohérence pipeline (Décomposable, Faible)
|
||||
La cohérence pipeline consiste une cohérence ne garantissant pas l'ordre des états finaux. C'est donc une cohérence faible. La chose la plus notable est que le résultat n'est pas garantit pour deux histoires concurrentes équivalentes.
|
||||
Cohérence de Cache (Composable, Décomposable, Fort)
|
||||
On imagine que chaque type de donnée abstraite utilise une seule et même mémoire qu'il partage avec tous les processus de l'histoire concurrente. Chaque mémoire respecte une cohérence séquentielle.
|
||||
Cohérence d'écriture (Faible)
|
||||
Un aspect manquant de la convergence est l'absence de cohérence d'écriture. C'est-à-dire que rien ne garantit que les données écrites par un processus soient bien celles lue à la fin par les lectures infinies.
|
||||
Le concept de cohérence d'écriture vise donc à spécifier cette propriété.
|
||||
Cohérence d'écriture forte (Faible)
|
||||
La cohérence d'écriture forte est une extension de la cohérence d'écriture qui rajoute un ordre dans les opérations d'écriture. Ceci permet d'assurer que chaque opération soit faites dans le même état et assure donc une convergence plus "rapide".
|
||||
Cohérence causale
|
||||
Cohérence Causale Faible
|
||||
Cohérence directe avec son passé local et respect de cette cohérence avec les autres processus par transitivité. Aucune préservation de l'ordre des opérations.
|
||||
Résultat potentiellement divergent ?
|
||||
Convergence Causale
|
||||
Rajout de la notion d'ordre totale. Qui permet de garantir la convergence du résultat.
|
||||
Cohérence Causale
|
||||
Cohérence avec les écritures du passé causal et des lectures du passé local.
|
||||
},
|
||||
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{somasekaram_high-availability_2022,
|
||||
title = {High-Availability Clusters: A Taxonomy, Survey, and Future Directions},
|
||||
volume = {187},
|
||||
issn = {01641212},
|
||||
url = {http://arxiv.org/abs/2109.15139},
|
||||
doi = {10.1016/j.jss.2021.111208},
|
||||
shorttitle = {High-Availability Clusters},
|
||||
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.},
|
||||
pages = {111208},
|
||||
journaltitle = {Journal of Systems and Software},
|
||||
shortjournal = {Journal of Systems and Software},
|
||||
author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
|
||||
urldate = {2023-06-06},
|
||||
date = {2022-05},
|
||||
eprinttype = {arxiv},
|
||||
eprint = {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},
|
||||
annotation = {Interet du papier
|
||||
Pas sur que ce soit dans le sujet. Ca semble prendre le sujet plus largement sans parler de la cohérence.
|
||||
},
|
||||
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},
|
||||
}
|
||||
|
||||
@thesis{kumar_fault-tolerant_2019,
|
||||
title = {Fault-Tolerant Distributed Services in Message-Passing Systems},
|
||||
institution = {Texas A\&M University},
|
||||
type = {phdthesis},
|
||||
author = {Kumar, Saptaparni},
|
||||
date = {2019},
|
||||
annotation = {Fiche Lecture
|
||||
Connexes
|
||||
Comprendre la théorie derrière le Failure Detector. \_\_T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,” J. {ACM}, vol. 43, no. 2, pp. 225–267, 1996.\_\_
|
||||
Definition
|
||||
Fault-Tolerence: The service remains uninterrupted even if some component in the network fail.
|
||||
Distributed System: A collection of computers (or nodes) that communicate amongst themselves [...] to perform a given task.
|
||||
Distributed Computing: The use of a Distributed System to solve a computational problems.
|
||||
Static system: The system composition is fixed.
|
||||
Dynamic system: nodes may enter, leave or move in the system with time.
|
||||
{FLP} impossibility result: It is impossible to design a distributed system that is both asynchronous and fault-tolerant.
|
||||
{ADD} (Average Delayed/Dropped): model used to describe realisticly the network.
|
||||
Data-Strcutures:
|
||||
|
||||
|
||||
linearizability: a data structure is said to be linearizable if it guarantees that all operations appear to happen at a single pointin time between the invocation and response of the operation.
|
||||
|
||||
|
||||
Shared Register: [a data strcuture] that stores a value and has two opérations: read [...] and write.
|
||||
|
||||
|
||||
Fault-Tolerent Register: Linearizable (atomic) Shared register.
|
||||
|
||||
|
||||
Attacks:
|
||||
|
||||
|
||||
crash: a node halts, but was working correctly until it halts.
|
||||
|
||||
|
||||
omission: a node fails to receive incoming messages or send outgoing messages.
|
||||
|
||||
|
||||
timing: a node's message delivery lies outside of the specified delivery time interval.
|
||||
|
||||
|
||||
Byzantine: Malicious attacks, operator mistake, software errors and conventional crash faults.
|
||||
|
||||
|
||||
churn: change in system composition due to nodes entering and leaving.
|
||||
|
||||
|
||||
Usefull terms:
|
||||
|
||||
|
||||
shared memory/message-passing model
|
||||
|
||||
|
||||
synchronous/asynchronous systems
|
||||
|
||||
|
||||
static/dynamic systems
|
||||
|
||||
|
||||
Algorithms of sharded registers:
|
||||
|
||||
|
||||
{RAMBO}
|
||||
|
||||
|
||||
{DynaStore}
|
||||
|
||||
|
||||
Baldoni et Al.
|
||||
|
||||
|
||||
Chapter 1
|
||||
He's began to define the terms of distributed systemsn and the possibles uses cases.
|
||||
He define synchronous message-passing systems as giving the best guarantees. Opposite to asynchronous message-passing systems.
|
||||
Failure Detectors
|
||||
He's defining te concept of Failure Detectors as an oracle able to identify the failed nodes. And how they can be used to circumvent the {FLP} impossibility result.
|
||||
Actually the Failure Detectors needs a certain level of synchronicity to work. And two lines of research are proposed to solve this problem: The first one is to implement the Failure Detector on a increasingly weaker system model. And the second one is to find the weakest Failure Detector.
|
||||
Fault-Tolerant Register
|
||||
He defined a "shared register" and explained how it's complicated to implementing them due to the possibility of faulty nodes. And he present the solution who's the Fault-Tolerant Register. He also present the "linearizability" property and how it's used to define the Fault-Tolerant Register.
|
||||
Finally he introduce two implementation of the Fault-Tolerant Register: one who's crash-tolerent and the other one who's Byzantine-tolerent.
|
||||
Chapter 2
|
||||
He precised the context of the implementation. We are on an arbitrary, partitionnable network composed of Average Delayed/Dropped channels ({ADD}).
|
||||
The failure detectors can be defined by their accuracy and completness tel que:
|
||||
|
||||
|
||||
Strong completeness is satisfied if the failure detector of each node eventually suspects all nodes that are crashed.
|
||||
|
||||
|
||||
Eventual strong accuracy is satisfied if the failure detector of every node eventually stops suspecting all nodes that are correct.
|
||||
|
||||
|
||||
He described he's algorithm.
|
||||
Chapter 3.1
|
||||
He purposed a new Fault-Tolerant Register who's crash-tolerent and churn proof.
|
||||
The algorithm is tolerent of node who could crash or leave the system.
|
||||
There is no hierarchy between the nodes. And the algorithm emulated a shared memory using the message-passing model.
|
||||
Chapter 3.2
|
||||
He purposed a new Fault-Tolerant Register who's crash-tolerent and churn and Byzantin proof.
|
||||
The model add a notion of server in the previous model (where we had only clients). And a system of asymetric signature.
|
||||
Also he proved than it's impossible with thiss model to determine the number of Byzantin server as a fraction of the total number of servers.
|
||||
},
|
||||
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},
|
||||
}
|
||||
|
||||
@incollection{goos_causal_1995,
|
||||
location = {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},
|
||||
pages = {180--194},
|
||||
booktitle = {Foundations of Software Technology and Theoretical Computer Science},
|
||||
publisher = {Springer Berlin Heidelberg},
|
||||
author = {Raynal, Michel and Schiper, André},
|
||||
editor = {Thiagarajan, P. S.},
|
||||
editorb = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan},
|
||||
editorbtype = {redactor},
|
||||
urldate = {2023-06-06},
|
||||
date = {1995},
|
||||
langid = {english},
|
||||
doi = {10.1007/3-540-60692-0_48},
|
||||
note = {Series Title: Lecture Notes in Computer Science},
|
||||
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},
|
||||
}
|
||||
|
||||
@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.},
|
||||
pages = {18--26},
|
||||
number = {1},
|
||||
journaltitle = {{ACM} {SIGOPS} Operating Systems Review},
|
||||
shortjournal = {{SIGOPS} Oper. Syst. Rev.},
|
||||
author = {Mosberger, David},
|
||||
urldate = {2023-06-06},
|
||||
date = {1993-01},
|
||||
langid = {english},
|
||||
file = {Mosberger - 1993 - Memory consistency models.pdf:/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.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.},
|
||||
pages = {690--691},
|
||||
number = {9},
|
||||
journaltitle = {{IEEE} Transactions on Computers},
|
||||
author = {{Lamport}},
|
||||
date = {1979-09},
|
||||
note = {Conference Name: {IEEE} Transactions on Computers},
|
||||
keywords = {Computer design, concurrent computing, hardware correctness, multiprocessing, parallel processing},
|
||||
annotation = {Annotations
|
||||
« A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order » (Lamport, 1979, p. 1) Première définition de "coherence séquentiel"
|
||||
},
|
||||
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},
|
||||
}
|
||||
125
Recherche/perrin.md
Executable file
125
Recherche/perrin.md
Executable file
@@ -0,0 +1,125 @@
|
||||
# Concurrence et cohérence dans les systèmes répartis
|
||||
|
||||
## Auteur: Matthieu Perrin
|
||||
|
||||
## Réflexions
|
||||
|
||||
Un peu de mal à comprendre les bornes de cohérence.
|
||||
Ça veut dire quoi composable ?
|
||||
|
||||
## Définitions
|
||||
|
||||
Système réparti : Collection d'entités de calcul autonomes connectées en vue d'accomplir une tâche commune.
|
||||
|
||||
Entités de calcul : (ou processus). Entité d'un réseau capable de décision en fonction de stimuli.
|
||||
|
||||
Cohérence forte : Les objets ciblés cachent la concurrence et se comportent comme si tous les accès était séquentiels.
|
||||
|
||||
## Introduction
|
||||
|
||||
Un système réparti est caractérisé par :
|
||||
|
||||
- L'échelle du système
|
||||
- Les moyens d'interactions
|
||||
- Gestion des fautes (c.f. : reynal18 attacks) (et nombre de fautes acceptables)
|
||||
- Rapport au temps (y a-t-il une horloge partagée ?)
|
||||
|
||||
## Les histoires concurrentes
|
||||
|
||||
Une histoire concurrente est un ensemble d'événements partiellement ordonnés par un ordre de processus et étiquetés par des opérations.
|
||||
|
||||
3 primitives possibles :
|
||||
|
||||
- Broadcast (diffusion fiable) :
|
||||
- Validité : tout message reçu est émis par un processus
|
||||
- Uniformité : tout message reçu par un processus est reçu par tous les autres processus
|
||||
- FIFO Broadcast (idem Broadcast) :
|
||||
- Réception FIFO : tout message reçu par un processus est reçu dans l'ordre d'émission
|
||||
- Causal Broadcast (idem FIFO Broadcast) :
|
||||
- Réception causale : Tout message $m'$ envoyé par un processus après réception d'un message $m$ est aussi reçu après $m$ chez tous les autres processus
|
||||
|
||||
### Composabilité
|
||||
|
||||
La compossibilité définit la possibilité pour deux types de données abstraits différents, cohérente pris de manière unitaire, de pouvoir être combinés tout en gardant leurs cohérences.
|
||||
|
||||
### Décomposable
|
||||
|
||||
La décomposabilité définit la possibilité pour deux types de données abstraits différents cohérents si considérés "ensemble" de rester cohérent si considérés séparément.
|
||||
|
||||
### Localité
|
||||
|
||||
La localité est le respect simultané de la composabilité et de la décomposabilité.
|
||||
|
||||
## Modèles
|
||||
|
||||
Cohérence forte impossible dans des environnements crédibles de cloud. (Trop de risques de déni de services)
|
||||
|
||||
Ci-dessous une liste des différents paradigmes de modélisation de système répartis :
|
||||
|
||||
### Cohérence Séquentiel (Décomposable, Fort)
|
||||
|
||||
Cohérence Séquentiel (SC) : Les objets ciblés cachent la concurrence et se comportent comme si tous les accès était séquentiels.
|
||||
Le but est de mimer le comportement "comme si" un serveur centralisait et ordonnait l'information. (Ça peut être le cas ou non, il faut juste que la propriété soit respectée).
|
||||
Il y a un débat sur une notion de la cohérence séquentielle. La première formalisation de ce type de cohérence formulé par Lamport oublie de mentionner la notion de "synchronisation". Ce qui peut conduire a des comportements non cohérents. Elle permet par exemple l'existence d'histoires infinies qui viennent s'ajouter les unes derrières les autres. Ce qui serait absurde dans un système réel. (Exemple : infinité de lectures suivie d'une infinité d'écritures).
|
||||
Il y a donc débat sur la notion de cohérence séquentielle avec une école qui considère ce cas comme plausible et une autre qui souhaite rajouter une notion de synchronisation.
|
||||
|
||||
### Linéarisabilité ()
|
||||
|
||||
Il y a ici un lien fort entre l'ordre d'action du processus et son intégration au système. Il y a une synchronicité plus forte.
|
||||
Ici lorsqu'un processus souhaite accéder à un objet, s'il ne rentre pas en conflit avec aucune action d'écriture, il récupère la valeur antérieure à son exécution. (propriété : Registre Sûr).
|
||||
Si plusieurs processus veulent accéder à un objet, et entrent en concurrence avec une écriture, alors ils ne peuvent retourner seulement la valeur avant ou après l'écriture (propriété : Registre Régulier).
|
||||
Si deux lectures ne sont pas concurrentes, alors elles doivent retourner une valeur au moins aussi récente que la lecture antérieure. (propriété : Registre Atomique).
|
||||
|
||||
### Sérialisabilité (Décomposable, Faible)
|
||||
|
||||
ACID : Atomicité (une transaction est soit complètement acceptée soit complètement avortée), Cohérence (Une transaction exécutée dans un état correct emmène vers un état correct), Isolation (Les transactions n'interfèrent pas entre elles), Durabilité (une transaction acceptée n'est pas remise en cause).
|
||||
|
||||
La sérialisabilité est similaire à la linéarisabilité, à la différence que des transactions peuvent être avortés. Cela à pour effet de rendre le système moins "fort" en termes de consistance.
|
||||
|
||||
### Convergence (Composable, Faible)
|
||||
|
||||
La convergence est une notion de cohérence faible. Elle définit un système qui peut à un instant $t$ être divergent, mais qui finira sur un temps infini à converger vers un état commun.
|
||||
|
||||
### Convergence forte (Composable, Faible)
|
||||
|
||||
La convergence forte est une extension de la convergence où notre histoire est divisée en plusieurs états. Chaque transaction se trouve dans un état avec d'autres transactions avec qui elle partage un "passé commun". On définit le passé commun comme la base de connaissance antérieur à l'exécution de la transaction.
|
||||
|
||||
#### Data type pour la convergence
|
||||
|
||||
Les types de données vues pour les autres modèles sont peu adapté pour modéliser les interactions dans le cas de la convergence. On privilégie plutôt des types de données qui permettent de définir des états (ex : OR-SET).
|
||||
|
||||
### Intention
|
||||
|
||||
L'intention est une notion qui tend à appliquer la cohérence en fonction de l'intention des utilisateurs. Elle trouve son sens particulièrement dans l'édition collaborative lors d'écritures concurrentes. Mais sa spécification reste floue et c'est un concept qui semble difficile à appliquer.
|
||||
|
||||
### Cohérence pipeline (Décomposable, Faible)
|
||||
|
||||
La cohérence pipeline consiste une cohérence ne garantissant pas l'ordre des états finaux. C'est donc une cohérence faible. La chose la plus notable est que le résultat n'est pas garantit pour deux histoires concurrentes équivalentes.
|
||||
|
||||
### Cohérence de Cache (Composable, Décomposable, Fort)
|
||||
|
||||
On imagine que chaque type de donnée abstraite utilise une seule et même mémoire qu'il partage avec tous les processus de l'histoire concurrente. Chaque mémoire respecte une cohérence séquentielle.
|
||||
|
||||
### Cohérence d'écriture (Faible)
|
||||
|
||||
Un aspect manquant de la convergence est l'absence de cohérence d'écriture. C'est-à-dire que rien ne garantit que les données écrites par un processus soient bien celles lue à la fin par les lectures infinies.
|
||||
Le concept de cohérence d'écriture vise donc à spécifier cette propriété.
|
||||
|
||||
### Cohérence d'écriture forte (Faible)
|
||||
|
||||
La cohérence d'écriture forte est une extension de la cohérence d'écriture qui rajoute un ordre dans les opérations d'écriture. Ceci permet d'assurer que chaque opération soit faites dans le même état et assure donc une convergence plus "rapide".
|
||||
|
||||
## Cohérence causale
|
||||
|
||||
### Cohérence Causale Faible
|
||||
|
||||
Cohérence directe avec son passé local et respect de cette cohérence avec les autres processus par transitivité. Aucune préservation de l'ordre des opérations.
|
||||
Résultat potentiellement divergent ?
|
||||
|
||||
### Convergence Causale
|
||||
|
||||
Rajout de la notion d'ordre totale. Qui permet de garantir la convergence du résultat.
|
||||
|
||||
### Cohérence Causale
|
||||
|
||||
Cohérence avec les écritures du passé causal et des lectures du passé local.
|
||||
74
Recherche/vanDerLindeLeitaoPreguica.md
Executable file
74
Recherche/vanDerLindeLeitaoPreguica.md
Executable file
@@ -0,0 +1,74 @@
|
||||
# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
|
||||
|
||||
## Authors: van der Linde, Leitao, Preguica
|
||||
|
||||
## Résumé:
|
||||
|
||||
Le papier spécifie une amélioration de la cohérence causale, rajoutant des propriétés en renforçant la sécurité. Ils comparent ensuite différentes implémentations de leurs solutions en axant sur le besoin d'une faible latence pour privilégier l'interactivité.
|
||||
|
||||
## Plan:
|
||||
|
||||
1. Présente les attaques possibles sur la cohérence causale. $3
|
||||
2. Définissent les propriétés d'une cohérence causale sécurisée répondant aux attaques. $4
|
||||
3. Définit de nouvelles classes de cohérence étendant la cohérence causale. $5
|
||||
4. Définit des algorithmes pour implémenter ces classes de cohérence. $5
|
||||
5. Présente des résultats de performance de ces algorithmes. $6
|
||||
|
||||
## Détails du document
|
||||
|
||||
### Types d'attaques
|
||||
|
||||
- Tempering: un nœud soumet une opération pour anticiper une opération en attente qui n'a pas encore été exécutée par le système.
|
||||
- Omitting dependencies: un nœud n'utilise qu'un sous-ensemble des opérations dans la dépendance. Il sera en mesure de soumettre une tâche concurrente au système.
|
||||
- Unseen dependencies (également appelé add): un nœud soumet une opération qui dépend d'une opération qu'il n'a pas vue. Il permet à l'attaquant d'anticiper une opération. (C'est différent du tempering car dans ce cas l'opération n'existe pas encore).
|
||||
- Combining omitting and unseen: un nœud peut omettre une dépendance et soumettre une opération qui dépend d'une opération qu'il n'a pas vue.
|
||||
- Sibbling generation: créer deux opérations différentes avec le même id. L'attaquant pourrait créer une divergence permanente entre les nœuds.
|
||||
|
||||
### Propriétés d'une cohérence causale sécurisée
|
||||
|
||||
- **Immutable History**: Chaque opération est envoyée avec son passé causal à chaque nœud valide. (Contrecarre le tempering)
|
||||
- **No Future Dependencies**: Chaque opération est envoyée avec son état de connaissance de l'état des nœuds du système. (Contrecarre l'unseen dependencies puisque l'opération sera considérée par l'ensemble du système comme "en retard" et sera donc ignorée)
|
||||
- **Causal Execution**: Toute opération $o_i$ appartenant au passé causal d'une opération $o$ doit être sérialisable t.q. : $o_i < o$. (Force une sorte de synchronisation entre les nœuds)
|
||||
- **Eventual Sibling Detection**: Chaque opération doit être considérée comme une faute éventuelle et doit donc avoir la possibilité d'être révoqué. La révocation ne peut se produire qu'après l'exécution de l'opération. (Assure que si deux opérations sont créées avec un même identifiant et crée une divergence, alors les nœuds auront toujours un moyen de retourner à un état convergent. Contrecarre **en partie** le sibling generation)
|
||||
- **Limitted Omission**:
|
||||
|
||||
<!-- OLD
|
||||
# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
|
||||
|
||||
## Authors: van der Linde, Leitao, Preguica
|
||||
|
||||
## Definition
|
||||
|
||||
causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
|
||||
|
||||
Attacks on causal consistency:
|
||||
|
||||
- Tempering: a node submit an operation to anticipate a pending operation actually not yet executed by the system.
|
||||
- Omitting dependencies: a node used only a subset of the operations in the dependency. He will be able to submit a concurrent task to the system.
|
||||
- Unseen dependencies (also called add): a node submit an operation that depends on an operation that he didn't see. It can be usefull for the attacker to anticipate the operation. (This is different from tempering because in this case the operation does not exist yet).
|
||||
- Combining omitting and unseen: a node can omit a dependency and submit an operation that depends on an operation that he didn't see.
|
||||
- Sibbling generation: creating two differents operations with the same id. The attacker could create a permanent state divergence between the nodes.
|
||||
|
||||
## Summary
|
||||
|
||||
### Solutions used in the paper
|
||||
|
||||
#### Secure Causal Consistency
|
||||
Autors defined the properties of a secure causal consistency: Immutable History, No Future Dependencies, Causal Executions, Limitted Omission, and Eventual Sibling Detection.
|
||||
|
||||
The algorithms they propose used the following solutions for each property:
|
||||
|
||||
- Immutable History: The nodes sign the operations and the dependencies. The nodes can't temper the history because they can't sign the operation.
|
||||
- No Future Dependencies: Each operations includes a hash of all direct causal dependencies. The nodes can't omit dependencies because they can't sign the operation.
|
||||
- Causal Executions: The nodes need to verify, before executing an operation, that all the dependencies are executed.
|
||||
- Limitted Omission: It's by design impossible due to the metadata (hash of the dependencies).
|
||||
- Eventual Sibling Detection: Many mechanism are used:
|
||||
- a node is able to detect when two operations with the same id are send from differents paths.
|
||||
- a node is able than the hash of the dependencies is different with the hash provide by the operation.
|
||||
- the nodes are comparing the dependencies of the operation between them. If they are different, they are able to detect the sibbling generation.
|
||||
|
||||
#### Secure Strict Causal Consistency
|
||||
|
||||
The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel SGX. Thus the usage of a hash of the dependencies is unnecessary.
|
||||
An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow.
|
||||
This sollution was not explored in the paper due to this issue. -->
|
||||
BIN
Recherche/yaoLatticeAgreement/main.pdf
Normal file
BIN
Recherche/yaoLatticeAgreement/main.pdf
Normal file
Binary file not shown.
105
Recherche/yaoLatticeAgreement/main.tex
Normal file
105
Recherche/yaoLatticeAgreement/main.tex
Normal file
@@ -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}
|
||||
BIN
bwconsistency-stage.pdf
Executable file
BIN
bwconsistency-stage.pdf
Executable file
Binary file not shown.
290
docs/.gitignore
vendored
Executable file
290
docs/.gitignore
vendored
Executable file
@@ -0,0 +1,290 @@
|
||||
## Core latex/pdflatex auxiliary files:
|
||||
*.aux
|
||||
*.lof
|
||||
*.log
|
||||
*.lot
|
||||
*.fls
|
||||
*.out
|
||||
*.toc
|
||||
*.fmt
|
||||
*.fot
|
||||
*.cb
|
||||
*.cb2
|
||||
.*.lb
|
||||
|
||||
## Intermediate documents:
|
||||
*.dvi
|
||||
*.xdv
|
||||
*-converted-to.*
|
||||
# these rules might exclude image files for figures etc.
|
||||
# *.ps
|
||||
# *.eps
|
||||
*.pdf
|
||||
|
||||
## Generated if empty string is given at "Please type another file name for output:"
|
||||
.pdf
|
||||
|
||||
## Bibliography auxiliary files (bibtex/biblatex/biber):
|
||||
*.bbl
|
||||
*.bcf
|
||||
*.blg
|
||||
*-blx.aux
|
||||
*-blx.bib
|
||||
*.run.xml
|
||||
|
||||
## Build tool auxiliary files:
|
||||
*.fdb_latexmk
|
||||
*.synctex
|
||||
*.synctex(busy)
|
||||
*.synctex.gz
|
||||
*.synctex.gz(busy)
|
||||
*.pdfsync
|
||||
|
||||
## Build tool directories for auxiliary files
|
||||
# latexrun
|
||||
latex.out/
|
||||
|
||||
## Auxiliary and intermediate files from other packages:
|
||||
# algorithms
|
||||
*.alg
|
||||
*.loa
|
||||
|
||||
# achemso
|
||||
acs-*.bib
|
||||
|
||||
# amsthm
|
||||
*.thm
|
||||
|
||||
# beamer
|
||||
*.nav
|
||||
*.pre
|
||||
*.snm
|
||||
*.vrb
|
||||
|
||||
# changes
|
||||
*.soc
|
||||
|
||||
# comment
|
||||
*.cut
|
||||
|
||||
# cprotect
|
||||
*.cpt
|
||||
|
||||
# elsarticle (documentclass of Elsevier journals)
|
||||
*.spl
|
||||
|
||||
# endnotes
|
||||
*.ent
|
||||
|
||||
# fixme
|
||||
*.lox
|
||||
|
||||
# feynmf/feynmp
|
||||
*.mf
|
||||
*.mp
|
||||
*.t[1-9]
|
||||
*.t[1-9][0-9]
|
||||
*.tfm
|
||||
|
||||
#(r)(e)ledmac/(r)(e)ledpar
|
||||
*.end
|
||||
*.?end
|
||||
*.[1-9]
|
||||
*.[1-9][0-9]
|
||||
*.[1-9][0-9][0-9]
|
||||
*.[1-9]R
|
||||
*.[1-9][0-9]R
|
||||
*.[1-9][0-9][0-9]R
|
||||
*.eledsec[1-9]
|
||||
*.eledsec[1-9]R
|
||||
*.eledsec[1-9][0-9]
|
||||
*.eledsec[1-9][0-9]R
|
||||
*.eledsec[1-9][0-9][0-9]
|
||||
*.eledsec[1-9][0-9][0-9]R
|
||||
|
||||
# glossaries
|
||||
*.acn
|
||||
*.acr
|
||||
*.glg
|
||||
*.glo
|
||||
*.gls
|
||||
*.glsdefs
|
||||
*.lzo
|
||||
*.lzs
|
||||
|
||||
# uncomment this for glossaries-extra (will ignore makeindex's style files!)
|
||||
# *.ist
|
||||
|
||||
# gnuplottex
|
||||
*-gnuplottex-*
|
||||
|
||||
# gregoriotex
|
||||
*.gaux
|
||||
*.glog
|
||||
*.gtex
|
||||
|
||||
# htlatex
|
||||
*.4ct
|
||||
*.4tc
|
||||
*.idv
|
||||
*.lg
|
||||
*.trc
|
||||
*.xref
|
||||
|
||||
# hyperref
|
||||
*.brf
|
||||
|
||||
# knitr
|
||||
*-concordance.tex
|
||||
# TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files
|
||||
# *.tikz
|
||||
*-tikzDictionary
|
||||
|
||||
# listings
|
||||
*.lol
|
||||
|
||||
# luatexja-ruby
|
||||
*.ltjruby
|
||||
|
||||
# makeidx
|
||||
*.idx
|
||||
*.ilg
|
||||
*.ind
|
||||
|
||||
# minitoc
|
||||
*.maf
|
||||
*.mlf
|
||||
*.mlt
|
||||
*.mtc[0-9]*
|
||||
*.slf[0-9]*
|
||||
*.slt[0-9]*
|
||||
*.stc[0-9]*
|
||||
|
||||
# minted
|
||||
_minted*
|
||||
*.pyg
|
||||
|
||||
# morewrites
|
||||
*.mw
|
||||
|
||||
# newpax
|
||||
*.newpax
|
||||
|
||||
# nomencl
|
||||
*.nlg
|
||||
*.nlo
|
||||
*.nls
|
||||
|
||||
# pax
|
||||
*.pax
|
||||
|
||||
# pdfpcnotes
|
||||
*.pdfpc
|
||||
|
||||
# sagetex
|
||||
*.sagetex.sage
|
||||
*.sagetex.py
|
||||
*.sagetex.scmd
|
||||
|
||||
# scrwfile
|
||||
*.wrt
|
||||
|
||||
# sympy
|
||||
*.sout
|
||||
*.sympy
|
||||
sympy-plots-for-*.tex/
|
||||
|
||||
# pdfcomment
|
||||
*.upa
|
||||
*.upb
|
||||
|
||||
# pythontex
|
||||
*.pytxcode
|
||||
pythontex-files-*/
|
||||
|
||||
# tcolorbox
|
||||
*.listing
|
||||
|
||||
# thmtools
|
||||
*.loe
|
||||
|
||||
# TikZ & PGF
|
||||
*.dpth
|
||||
*.md5
|
||||
*.auxlock
|
||||
|
||||
# todonotes
|
||||
*.tdo
|
||||
|
||||
# vhistory
|
||||
*.hst
|
||||
*.ver
|
||||
|
||||
# easy-todo
|
||||
*.lod
|
||||
|
||||
# xcolor
|
||||
*.xcp
|
||||
|
||||
# xmpincl
|
||||
*.xmpi
|
||||
|
||||
# xindy
|
||||
*.xdy
|
||||
|
||||
# xypic precompiled matrices and outlines
|
||||
*.xyc
|
||||
*.xyd
|
||||
|
||||
# endfloat
|
||||
*.ttt
|
||||
*.fff
|
||||
|
||||
# Latexian
|
||||
TSWLatexianTemp*
|
||||
|
||||
## Editors:
|
||||
# WinEdt
|
||||
*.bak
|
||||
*.sav
|
||||
|
||||
# Texpad
|
||||
.texpadtmp
|
||||
|
||||
# LyX
|
||||
*.lyx~
|
||||
|
||||
# Kile
|
||||
*.backup
|
||||
|
||||
# gummi
|
||||
.*.swp
|
||||
|
||||
# KBibTeX
|
||||
*~[0-9]*
|
||||
|
||||
# TeXnicCenter
|
||||
*.tps
|
||||
|
||||
# auto folder when using emacs and auctex
|
||||
./auto/*
|
||||
*.el
|
||||
|
||||
# expex forward references with \gathertags
|
||||
*-tags.tex
|
||||
|
||||
# standalone packages
|
||||
*.sta
|
||||
|
||||
# Makeindex log files
|
||||
*.lpz
|
||||
|
||||
# xwatermark package
|
||||
*.xwm
|
||||
|
||||
# REVTeX puts footnotes in the bibliography by default, unless the nofootinbib
|
||||
# option is specified. Footnotes are the stored in a file with suffix Notes.bib.
|
||||
# Uncomment the next line to have this generated file ignored.
|
||||
#*Notes.bib
|
||||
|
||||
# End of https://mrkandreev.name/snippets/gitignore-generator/#LaTeX
|
||||
258
docs/bibliographie/My Library.bib
Normal file
258
docs/bibliographie/My Library.bib
Normal file
@@ -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},
|
||||
}
|
||||
32
docs/bibliographie/liste_detaille.md
Normal file
32
docs/bibliographie/liste_detaille.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# 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
|
||||
@@ -0,0 +1,15 @@
|
||||
\begin{frame}
|
||||
\frametitle{My work}
|
||||
|
||||
\begin{block}{What's next ?}
|
||||
\begin{itemize}
|
||||
\item Study and formalize some "in-prod" algorithms using weak consistency in byzantine contexts.
|
||||
\item Continue the collaboration with Parsec:
|
||||
\begin{itemize}
|
||||
\item formalize a list of properties
|
||||
\end{itemize}
|
||||
\item identifies which applications are suitable for each class of weak consistency.
|
||||
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@@ -0,0 +1,14 @@
|
||||
\begin{frame}
|
||||
\frametitle{The Byzantine context associated with the weak consistency}
|
||||
|
||||
\begin{block}{Some questions about:}
|
||||
\begin{itemize}
|
||||
\item is the weak consistency introduces more or less possibility of malicious behaviors.
|
||||
\item is the cost to make a system Byzantine Fault Tolerant is higher or lower with weak consistency.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
|
||||
The state of the art is poor about these questions and few formalized algorithms are available.
|
||||
|
||||
|
||||
\end{frame}
|
||||
122
docs/presentations/LIS/Anglais_avril_2024/consistency/faible.tex
Normal file
122
docs/presentations/LIS/Anglais_avril_2024/consistency/faible.tex
Normal file
@@ -0,0 +1,122 @@
|
||||
\begin{frame}
|
||||
\frametitle{The models of consistency}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.6\textwidth}
|
||||
\footnote{Perrin, \emph{Concurrence et cohérence dans les systèmes répartis}, 2017}
|
||||
\resizebox{\columnwidth}{!}{
|
||||
\includegraphics{images/carte_criteres.png}
|
||||
}
|
||||
|
||||
\column{0.4\columnwidth}
|
||||
\begin{block}{Les classes de cohérences}
|
||||
2 big family :
|
||||
\begin{itemize}
|
||||
\item Strong Consistency
|
||||
\item Weak Consistency :
|
||||
\begin{itemize}
|
||||
\item Eventual Consistency (EC)
|
||||
\item State Locality (SL)
|
||||
\item Validity (V)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Eventual Consistency (EC)}
|
||||
|
||||
\begin{block}{Definition}
|
||||
There exists a set of cofinite operations where each one must be justified with the same state.
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/convergence_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(1,2)^\omega, r/(1,2)^\omega\}$ \newline
|
||||
$\delta = ((1,2), \emptyset)$ is a valid state justifying $E'$.
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/convergence_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(1,2)^\omega, r/(2,1)^\omega\}$. \newline
|
||||
There exists no state able to justify $E'$ because the two infinite reads are not consistent.
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{State Locality}
|
||||
|
||||
\begin{block}{Definition}
|
||||
For all $p$, there exists one linearization that includes all the read operations of $p$. According to the local order of these reads. \\
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/localiteetat_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
\begin{math}
|
||||
\begin{array}{l}
|
||||
\textcolor{blue}{C_{p_0} = \{r/(0,0), r/(0,2)^\omega, w(2)\}}, \\
|
||||
\textcolor{red}{C_{p_1} = \{r/(0,0), r/(0,1)^\omega, w(1)\}}, \\
|
||||
\textcolor{blue}{r/(0,0) \bullet w(2) \bullet r/(0,2)^\omega} \\
|
||||
\textcolor{red}{r/(0,0) \bullet w(1) \bullet r/(0,1)^\omega} \\
|
||||
\end{array}
|
||||
\end{math}
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/localiteetat_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E'_{p_0} = \{r/(0,0), r/(2,1)^\omega\},$ \newline
|
||||
$r/(0,0) \bullet w(2) \bullet w(1) \bullet r/(2,1)^\omega$ \newline
|
||||
$E'_{p_1} = \{r/(0,1), r/(2,1)^\omega\}$. \newline
|
||||
There exists no linearization of $p_1$ satisfying the definition of state locality
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Validity (V)}
|
||||
|
||||
\begin{block}{Definition}
|
||||
There exists a cofinite set of operations such as each of them must be justified by a linearization of all the write operations.
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/validite_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
\begin{math}
|
||||
\begin{array}{ll}
|
||||
E' = & \{r/(2,1)^\omega, r/(1,2)^\omega\} \\
|
||||
& w(2) \bullet w(1) \bullet \textcolor{red}{r/(2,1)^\omega} \\
|
||||
& w(1) \bullet w(2) \bullet \textcolor{red}{r/(1,2)^\omega} \\
|
||||
\end{array}
|
||||
\end{math}
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/validite_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(0,1)^\omega, r/(1,2)^\omega\}$. \\
|
||||
There is no linearization of the write operation able to justify $r/(0,1)^\omega$.
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
@@ -0,0 +1,45 @@
|
||||
\begin{frame}
|
||||
\frametitle{Safety}
|
||||
\begin{block}{Definition}
|
||||
Each \textbf{read} operation made in the same \textbf{non-competitor} context provides the same result.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_surete_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Regularity}
|
||||
\begin{block}{Definition}
|
||||
An \textbf{reading operation concurrent with a writing operation} must provide the value \textbf{before or after the write}.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_regularite_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomicity}
|
||||
\begin{block}{Definition}
|
||||
If \textbf{two readings are non-competitor}, the second one must provide a value \textbf{at least as recent as} the previous one.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_atomicite_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomic Consistency ($C_\top$)}
|
||||
|
||||
\begin{block}{Définition}
|
||||
Atomic consistency is the stronger consistency class.
|
||||
\begin{itemize}
|
||||
\item Provide an awful interactivity.
|
||||
\item Need a strong synchronization between each operation.
|
||||
\begin{itemize}
|
||||
\item Each read or write operation locks the others and needs to wait for the release from the previous one.
|
||||
\end{itemize}
|
||||
\item He's used as a reference for the other consistency class.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@@ -0,0 +1,8 @@
|
||||
\subsection{Strong consistency}
|
||||
\include{consistency/forte.tex}
|
||||
|
||||
\subsection{The compromises of the strong consistency}
|
||||
\include{consistency/faible.tex}
|
||||
|
||||
\subsection{In a malicious context ?}
|
||||
\include{consistency/byzantin.tex}
|
||||
@@ -0,0 +1,32 @@
|
||||
\begin{frame}
|
||||
\frametitle{A distributed system}
|
||||
|
||||
\begin{block}{Definition}
|
||||
A distributed system is a group of \textbf{actors} able to communicate \textbf{each-other} working together to \textbf{complete a common task}.
|
||||
\end{block}
|
||||
|
||||
% Schéma d'un système distribué
|
||||
|
||||
The system we consider in this presentation is a \textbf{asynchronous message-passing} system.
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{A distributed system is a living system}
|
||||
|
||||
A distributed system changes over time.
|
||||
|
||||
There are some ways to study these changes :
|
||||
\begin{itemize}
|
||||
\item focus on the \textbf{churn} (node addition and removal).
|
||||
\item focus on the \textbf{messages}.
|
||||
\item focus on the \textbf{connectedness}.
|
||||
\item focus on the \textbf{states}. $\Leftarrow$
|
||||
\item probably more... ?
|
||||
\end{itemize}
|
||||
|
||||
The study of the state changes is also called the study of \textbf{consistency}.
|
||||
|
||||
\textbf{A small exemple}: A peer-to-peer discussion
|
||||
|
||||
\end{frame}
|
||||
@@ -0,0 +1,2 @@
|
||||
\subsection{Définition}
|
||||
\include{distr_sys/bases}
|
||||
BIN
docs/presentations/LIS/Anglais_avril_2024/images/carte_criteres.png
Executable file
BIN
docs/presentations/LIS/Anglais_avril_2024/images/carte_criteres.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
@@ -0,0 +1,4 @@
|
||||
|
||||
|
||||
\subsection{My Thesis}
|
||||
\include{intro/suite.tex}
|
||||
17
docs/presentations/LIS/Anglais_avril_2024/intro/suite.tex
Normal file
17
docs/presentations/LIS/Anglais_avril_2024/intro/suite.tex
Normal file
@@ -0,0 +1,17 @@
|
||||
\begin{frame}
|
||||
\frametitle{My Thesis}
|
||||
|
||||
\begin{itemize}
|
||||
\item Collaboration between Parsec and LIS-LAB
|
||||
\begin{itemize}
|
||||
\item Parsec is a for-profit organization working on an open-source software named Parsec
|
||||
\item It's a software architecture for file sharing with E2EE in a zero-trust approach
|
||||
\end{itemize}
|
||||
\item Parsec wants to add Collaborative Editing on their products:
|
||||
\begin{itemize}
|
||||
\item With a zero-trust approach (so probably decentralized)
|
||||
\item With a high availability and low latency approach
|
||||
\end{itemize}
|
||||
\item Subject is \textit{Weak Consistency Byzantine Fault Tolerent}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
60
docs/presentations/LIS/Anglais_avril_2024/main.tex
Executable file
60
docs/presentations/LIS/Anglais_avril_2024/main.tex
Executable file
@@ -0,0 +1,60 @@
|
||||
\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}
|
||||
|
||||
\usepackage{tcolorbox}
|
||||
|
||||
\title[bwconsistency]{Weak consistency application to zero-trust cloud}
|
||||
\subtitle{English Courses}
|
||||
\author[JOLY Amaury]{JOLY Amaury\\ \textbf{Encadrants :} GODARD Emmanuel, TRAVERS Corentin }
|
||||
% \\[2ex] \includegraphics[scale=0.1]{./img/amu.png}
|
||||
\institute[LIS, Scille]{LIS-LAB, Scille}
|
||||
\date{04 April 2024}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{frame}{Summary}
|
||||
\tableofcontents
|
||||
\end{frame}
|
||||
|
||||
\section{Introduction}
|
||||
\input{intro/index.tex}
|
||||
|
||||
\section{Distributed systems and consistency}
|
||||
\input{distr_sys/index.tex}
|
||||
|
||||
\section{The compromises of consistency}
|
||||
\input{consistency/index.tex}
|
||||
|
||||
\section{What's next ?}
|
||||
\input{conclusion/index.tex}
|
||||
|
||||
\end{document}
|
||||
BIN
docs/presentations/LIS/Anglais_avril_2024/schemas/ccv_hc_1.png
Executable file
BIN
docs/presentations/LIS/Anglais_avril_2024/schemas/ccv_hc_1.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_1.tex
Executable file
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_1.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
\draw[arrow] (13) -- (14);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\draw[arrow] (23) -- (24);
|
||||
|
||||
\draw (24) -- (14);
|
||||
|
||||
\draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -2.9);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_2.tex
Executable file
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_2.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
\draw[arrow] (13) -- (14);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\draw[arrow] (23) -- (24);
|
||||
|
||||
\draw (24) -- (14);
|
||||
|
||||
\draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -2.9);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red}{$r/(1)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red}{$r/(1)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red!50!blue}{$r/(27)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
34
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_1.tex
Executable file
34
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_1.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, draw=blue, fill=blue] (21) [below=10pt 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
|
||||
\draw[message] (11) -- ($(22)!0.5!(23)$);
|
||||
\draw[message] (21) -- ($(12)!0.5!(13)$);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
32
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_2.tex
Executable file
32
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_2.tex
Executable file
@@ -0,0 +1,32 @@
|
||||
\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,0)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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,1)$};
|
||||
\node[roundnode] (23) [right=of 22] {};
|
||||
\node[below] at (23.south) {$r/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
|
||||
\end{tikzpicture}
|
||||
}
|
||||
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_1.tex
Executable file
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_1.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_2.tex
Executable file
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_2.tex
Executable file
@@ -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/(0,1)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=10ptof 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
42
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_1.tex
Executable file
42
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_1.tex
Executable file
@@ -0,0 +1,42 @@
|
||||
\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, color=red] (11) {};
|
||||
\node[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode, color=red!50] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(0,1)$};
|
||||
\node[roundnode, color=red!25] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(3,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, color=green!75!black] (21) [below=20pt of 11] {};
|
||||
\node[left] at (21.west) {$r/(3,1)$};
|
||||
\node[roundnode, color=green!95!black] (22) [right=of 21] {};
|
||||
\node[right] at (22.east) {$w(2)$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
|
||||
\node[roundnode, color=blue] (31) [below=20pt of 21] {};
|
||||
\node[below] at (31.south) {$w(3)$};
|
||||
\node[roundnode, color=blue!50] (32) [right=of 31] {};
|
||||
\node[below] at (32.south) {$r/(3,1)$};
|
||||
\node[roundnode, color=blue!25] (33) [right=of 32] {};
|
||||
\node[below] at (33.south) {$r/(3,2)^\omega$};
|
||||
|
||||
\draw[arrow] (31) -- (32);
|
||||
\draw[arrow] (32) -- (33);
|
||||
|
||||
\draw[message] (11) -- (21);
|
||||
\draw[message] (31) -- (21);
|
||||
\draw[message] (21) -- (32);
|
||||
\draw[message] (22) -- (13);
|
||||
\draw[message] (22) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
29
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_2.tex
Executable file
29
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_2.tex
Executable file
@@ -0,0 +1,29 @@
|
||||
\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[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(2,1)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=20pt of 11] {};
|
||||
\node[left] at (21.west) {$r/(0,1)$};
|
||||
\node[roundnode] (22) [right=of 21] {};
|
||||
\node[right] at (22.east) {$w(2)$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
|
||||
\draw[message] (11) -- (21);
|
||||
\draw[message] (22) -- (12);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
41
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_3.tex
Executable file
41
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_3.tex
Executable file
@@ -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, color=red] (11) {};
|
||||
\node[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode, color=red!50] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(3,1)$};
|
||||
\node[roundnode, color=red!25] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(1,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, color=green!75!black] (21) [below=20pt of 11] {};
|
||||
\node[left] at (21.west) {$r/(0,0)$};
|
||||
\node[roundnode, color=green!95!black] (22) [right=of 21] {};
|
||||
\node[right] at (22.east) {$w(2)$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
|
||||
\node[roundnode, color=blue] (31) [below=20pt of 21] {};
|
||||
\node[below] at (31.south) {$w(3)$};
|
||||
\node[roundnode, color=blue!50] (32) [right=of 31] {};
|
||||
\node[below] at (32.south) {$r/(1,3)$};
|
||||
\node[roundnode, color=blue!25] (33) [right=of 32] {};
|
||||
\node[below] at (33.south) {$r/(3,2)^\omega$};
|
||||
|
||||
\draw[arrow] (31) -- (32);
|
||||
\draw[arrow] (32) -- (33);
|
||||
|
||||
\draw[message] (11) -- (31);
|
||||
\draw[message] (31) -- (12);
|
||||
\draw[message] (22) -- (13);
|
||||
\draw[message] (22) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
252
docs/presentations/LIS/CSI2025/main.tex
Normal file
252
docs/presentations/LIS/CSI2025/main.tex
Normal file
@@ -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}
|
||||
|
||||
222
docs/presentations/LIS/CSI2025/rapport/main.tex
Normal file
222
docs/presentations/LIS/CSI2025/rapport/main.tex
Normal file
@@ -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}
|
||||
@@ -0,0 +1,15 @@
|
||||
\begin{frame}
|
||||
\frametitle{Conclusion}
|
||||
|
||||
\begin{block}{What's next ?}
|
||||
\begin{itemize}
|
||||
\item Study and formalize some "in-prod" algoritms using weak consistency in byzantin contexts.
|
||||
\item Continue the colaboration with Parsec:
|
||||
\begin{itemize}
|
||||
\item formalize a list of properties
|
||||
\item provide a proof of concept of a colaborative editor
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@@ -0,0 +1,14 @@
|
||||
\begin{frame}
|
||||
\frametitle{The Byzantin context associate to the weak consistency}
|
||||
|
||||
\begin{block}{Some questions about:}
|
||||
\begin{itemize}
|
||||
\item is the weak consistency introduce new possibility of malicious behaviours.
|
||||
\item is the weak consistency reduce by design the field of milicious behaviours.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
|
||||
The state of the art is poor about these questions and few formalized algoritms are avaible.
|
||||
|
||||
|
||||
\end{frame}
|
||||
@@ -0,0 +1,122 @@
|
||||
\begin{frame}
|
||||
\frametitle{The models of consistency}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.6\textwidth}
|
||||
\footnote{Perrin, \emph{Concurrence et cohérence dans les systèmes répartis}, 2017}
|
||||
\resizebox{\columnwidth}{!}{
|
||||
\includegraphics{images/carte_criteres.png}
|
||||
}
|
||||
|
||||
\column{0.4\columnwidth}
|
||||
\begin{block}{Les classes de cohérences}
|
||||
2 big family :
|
||||
\begin{itemize}
|
||||
\item Strong Consistency
|
||||
\item Weak Consistency :
|
||||
\begin{itemize}
|
||||
\item Eventual Consistency (EC)
|
||||
\item State Locality (SL)
|
||||
\item Validity (V)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Eventual Consistency (EC)}
|
||||
|
||||
\begin{block}{Definition}
|
||||
There exist a set of confinite operations where each one must be justify with the same state.
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/convergence_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(1,2)^\omega, r/(1,2)^\omega\}$ \newline
|
||||
$\delta = ((1,2), \emptyset)$ is a valid state justifying $E'$.
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/convergence_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(1,2)^\omega, r/(2,1)^\omega\}$. \newline
|
||||
There exist no state able to justify $E'$ because the two infinite read are not consistent.
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{State Locality}
|
||||
|
||||
\begin{block}{Definition}
|
||||
For all $p$, there exist one linearization who include all the read operations of $p$. According to the local order of these reads. \\
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/localiteetat_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
\begin{math}
|
||||
\begin{array}{l}
|
||||
\textcolor{blue}{C_{p_0} = \{r/(0,0), r/(0,2)^\omega, w(2)\}}, \\
|
||||
\textcolor{red}{C_{p_1} = \{r/(0,0), r/(0,1)^\omega, w(1)\}}, \\
|
||||
\textcolor{blue}{r/(0,0) \bullet w(2) \bullet r/(0,2)^\omega} \\
|
||||
\textcolor{red}{r/(0,0) \bullet w(1) \bullet r/(0,1)^\omega} \\
|
||||
\end{array}
|
||||
\end{math}
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/localiteetat_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E'_{p_0} = \{r/(0,0), r/(2,1)^\omega\},$ \newline
|
||||
$r/(0,0) \bullet w(2) \bullet w(1) \bullet r/(2,1)^\omega$ \newline
|
||||
$E'_{p_1} = \{r/(0,1), r/(2,1)^\omega\}$. \newline
|
||||
There exist no linearization of $p_1$ satisfying the definition of state locality
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Validity (V)}
|
||||
|
||||
\begin{block}{Definition}
|
||||
There exist a cofinite set of operations such as for each of them must be justified by a linearization of all the write operation.
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/validite_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
\begin{math}
|
||||
\begin{array}{ll}
|
||||
E' = & \{r/(2,1)^\omega, r/(1,2)^\omega\} \\
|
||||
& w(2) \bullet w(1) \bullet \textcolor{red}{r/(2,1)^\omega} \\
|
||||
& w(1) \bullet w(2) \bullet \textcolor{red}{r/(1,2)^\omega} \\
|
||||
\end{array}
|
||||
\end{math}
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/validite_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(0,1)^\omega, r/(1,2)^\omega\}$. \\
|
||||
There is no linearization of the write operation able to justify $r/(0,1)^\omega$.
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
@@ -0,0 +1,45 @@
|
||||
\begin{frame}
|
||||
\frametitle{Safety}
|
||||
\begin{block}{Definition}
|
||||
Each \textbf{read} operation made in the same \textbf{non-competitor} context provide the same result.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_surete_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Regularity}
|
||||
\begin{block}{Definition}
|
||||
An \textbf{reading operation concurrent with a writing operation} must provide the value \textbf{before or after the write}.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_regularite_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomicity}
|
||||
\begin{block}{Definition}
|
||||
If \textbf{two reading are non-competitor}, the second one must provide a value \textbf{at least as recent as} the previous one.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_atomicite_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomic Consistency ($C_\top$)}
|
||||
|
||||
\begin{block}{Définition}
|
||||
Atomic consistency is the stronger consistency class.
|
||||
\begin{itemize}
|
||||
\item Provide an awful interactivity.
|
||||
\item Need a strong synchronization between each operation.
|
||||
\begin{itemize}
|
||||
\item Each read or write operation lock the others and need to wait the realease from the previous one.
|
||||
\end{itemize}
|
||||
\item He's used as a reference for the other consistency class.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@@ -0,0 +1,8 @@
|
||||
\subsection{Strong consistency}
|
||||
\include{consistency/forte.tex}
|
||||
|
||||
\subsection{The compromises of the strong consistency}
|
||||
\include{consistency/faible.tex}
|
||||
|
||||
\subsection{In a malicious context ?}
|
||||
\include{consistency/byzantin.tex}
|
||||
@@ -0,0 +1,32 @@
|
||||
\begin{frame}
|
||||
\frametitle{A distributed system}
|
||||
|
||||
\begin{block}{Definition}
|
||||
A distributed system is a group of \textbf{actors} able to comunicate \textbf{each-other} working together to \textbf{complete a common task}.
|
||||
\end{block}
|
||||
|
||||
% Schéma d'un système distribué
|
||||
|
||||
The system we consider on this presentation is a \textbf{asynchronous message-passing} system.
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{A distributed system is a living system}
|
||||
|
||||
A distributed system changes over time.
|
||||
|
||||
There's some way to study these changes :
|
||||
\begin{itemize}
|
||||
\item focus on the \textbf{churn} (node addition and removal).
|
||||
\item focus on the \textbf{messages}.
|
||||
\item focus on the \textbf{connectedness}.
|
||||
\item focus on the \textbf{states}. $\Leftarrow$
|
||||
\item probably more... ?
|
||||
\end{itemize}
|
||||
|
||||
The study of the state changes is also called the study of \textbf{consistency}.
|
||||
|
||||
\textbf{A small exemple}: A peer-to-peer discussion
|
||||
|
||||
\end{frame}
|
||||
@@ -0,0 +1,2 @@
|
||||
\subsection{Définition}
|
||||
\include{distr_sys/bases}
|
||||
BIN
docs/presentations/LIS/DALGO_6_juillet_2023/images/carte_criteres.png
Executable file
BIN
docs/presentations/LIS/DALGO_6_juillet_2023/images/carte_criteres.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
@@ -0,0 +1,5 @@
|
||||
\subsection{Introduction}
|
||||
\include{intro/presentation.tex}
|
||||
|
||||
\subsection{My internship}
|
||||
\include{intro/suite.tex}
|
||||
@@ -0,0 +1,16 @@
|
||||
\begin{frame}
|
||||
\frametitle{Présentation}
|
||||
|
||||
\begin{itemize}
|
||||
\item Amaury JOLY
|
||||
\item Master Informatique
|
||||
\begin{itemize}
|
||||
\item Option Fiabilité Sécurité Informatique (FSI)
|
||||
\end{itemize}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
|
||||
\end{frame}
|
||||
18
docs/presentations/LIS/DALGO_6_juillet_2023/intro/suite.tex
Normal file
18
docs/presentations/LIS/DALGO_6_juillet_2023/intro/suite.tex
Normal file
@@ -0,0 +1,18 @@
|
||||
\begin{frame}
|
||||
\frametitle{My Internship}
|
||||
|
||||
\begin{itemize}
|
||||
\item Begin in april
|
||||
\item Collaboration between Parsec and LIS-LAB
|
||||
\begin{itemize}
|
||||
\item Parsec is a for-profit organization working on an open-source software named Parsec
|
||||
\item It's a software architecture to file sharing with E2EE in a zero-trust approach
|
||||
\end{itemize}
|
||||
\item Parsec want to add Collaborative Editing on their products:
|
||||
\begin{itemize}
|
||||
\item With a zero-trust approach (so probably decentralized)
|
||||
\item With a high avaibility and low latency approach
|
||||
\end{itemize}
|
||||
\item Subject is \textit{Weak Consistency Byzantin Fault Tolerent}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
60
docs/presentations/LIS/DALGO_6_juillet_2023/main.tex
Executable file
60
docs/presentations/LIS/DALGO_6_juillet_2023/main.tex
Executable file
@@ -0,0 +1,60 @@
|
||||
\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}
|
||||
&
|
||||
\usepackage{tcolorbox}
|
||||
|
||||
\title[bwconsistency]{Étude de la cohérence dans les systèmes distribués}
|
||||
\subtitle{Journée DALGO}
|
||||
\author[JOLY Amaury]{JOLY Amaury\\ \textbf{Encadrants :} GODARD Emmanuel, TRAVERS Corentin }
|
||||
% \\[2ex] \includegraphics[scale=0.1]{./img/amu.png}
|
||||
\institute[LIS, Scille]{LIS-LAB, Scille}
|
||||
\date{6 juillet 2023}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{frame}{Table des matières}
|
||||
\tableofcontents
|
||||
\end{frame}
|
||||
|
||||
\section{Introduction}
|
||||
\input{intro/index.tex}
|
||||
|
||||
\section{Distributed systems and consistency}
|
||||
\input{distr_sys/index.tex}
|
||||
|
||||
\section{The compromises of consistency}
|
||||
\input{consistency/index.tex}
|
||||
|
||||
\section{What's next ?}
|
||||
\input{conclusion/index.tex}
|
||||
|
||||
\end{document}
|
||||
BIN
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/ccv_hc_1.png
Executable file
BIN
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/ccv_hc_1.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
41
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/convergence_hc_1.tex
Executable file
41
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/convergence_hc_1.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
\draw[arrow] (13) -- (14);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\draw[arrow] (23) -- (24);
|
||||
|
||||
\draw (24) -- (14);
|
||||
|
||||
\draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -2.9);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
41
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/convergence_hc_2.tex
Executable file
41
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/convergence_hc_2.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
\draw[arrow] (13) -- (14);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\draw[arrow] (23) -- (24);
|
||||
|
||||
\draw (24) -- (14);
|
||||
|
||||
\draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -2.9);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red}{$r/(1)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red}{$r/(1)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red!50!blue}{$r/(27)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
34
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/localiteetat_hc_1.tex
Executable file
34
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/localiteetat_hc_1.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, draw=blue, fill=blue] (21) [below=10pt 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
|
||||
\draw[message] (11) -- ($(22)!0.5!(23)$);
|
||||
\draw[message] (21) -- ($(12)!0.5!(13)$);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
32
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/localiteetat_hc_2.tex
Executable file
32
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/localiteetat_hc_2.tex
Executable file
@@ -0,0 +1,32 @@
|
||||
\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,0)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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,1)$};
|
||||
\node[roundnode] (23) [right=of 22] {};
|
||||
\node[below] at (23.south) {$r/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
|
||||
\end{tikzpicture}
|
||||
}
|
||||
31
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/validite_hc_1.tex
Executable file
31
docs/presentations/LIS/DALGO_6_juillet_2023/schemas/validite_hc_1.tex
Executable file
@@ -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)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=10pt 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)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user