Merge branch '14-glossaire' into 'develop'

Resolve "Glossaire"

Closes #14

See merge request v18003685/pfe-blockchain!39

docs/rapportFinal/centralisation/Plate-formes.tex

@@ -1,6 +1,6 @@
 \subsubsection{Définition}
 Nous avons commencé nos recherches en nous intéressant en premier lieu aux moyens d'échanges les plus répandus. 
-Cela nous a mené vers les plate-formes d'échanges centralisé. 
+Cela nous a mené vers les plate-formes d'échanges centralisé ou \acrshort{cex}. 
 Ce sont des plate-formes, pouvant prendre la forme d'applications web, qui permettent aux utilisateurs d'acheter, de vendre ou d'échanger des \gls{actif}s numériques contre d'autres \gls{actif}s numériques ou en monnaies fiduciaires. 
 Ces plate-formes peuvent opérer sur des \textit{\gls{blockchain}s} publiques ou être dédiées à une utilisation en interne. 
 Elles sont dites centralisées car elles sont gérées par une entreprise ou une organisation hiérarchisée qui contrôle les transactions et les fonds des utilisateurs.
@@ -28,7 +28,7 @@ Ces plate-formes fonctionnent sur le principe de l'\textit{order book method} (m
 Un ordre étant une demande d'un utilisateur visant à réaliser une opération à un prix et une quantité donnée. 
 Cette méthode comprend deux parties: l'offre et la demande. L'offre regroupe les ordres d'achats émis par des utilisateurs sur la plate-forme et la demande, les ordres de vente.
 Lors d'un dépôt, l'utilisateur s'étant au préalable enregistré sur la plate-forme, il va déposer les fonds souhaités dans un porte monnaie. 
-La plate-forme va ensuite crée un \textit{IOU}\footnote{I Owe You, c'est la dette de la plate-forme envers l'utilisateur permettant de bloquer la valeur de la monnaie déposée par l'utilisateur\cite{IOU}} 
+La plate-forme va ensuite crée un \textit{\acrshort{iou}}\footnote{I Owe You, c'est la dette de la plate-forme envers l'utilisateur permettant de bloquer la valeur de la monnaie déposée par l'utilisateur\cite{IOU}} 
 ce dernier sera échangé contre le crypto-\gls{actif} souhaité lors d'un échange ou d'une vente. \\ 
 
 Dans le cadre des échanges inter-\gls{blockchain}s, les plate-formes d'échanges utilisent des \textit{bridges} reliant les différentes \textit{\gls{blockchain}s}. 

docs/rapportFinal/centralisation/attaques.tex

@@ -3,17 +3,17 @@
 Les \textit{\gls{blockchain}s} et leurs protocoles d'échanges ne sont pas exemptes d'attaques informatiques ou bien de défaillances.
 Ces attaques peuvent cibler des portefeuilles (attaques sur des \textit{hot wallets}\footnote{portefeuille de cryptomonnaies en ligne, à différencier des \textit{Cold Wallets}, des portefeuilles hors lignes}) ou encore des \textit{bridges}. 
 Ce sont ces dernières qui nous ont intéressées dans le cadre de ce projet de recherche sur les échanges inter-\gls{blockchain}s. 
-Les bridges, comme explicité dans la partie dédiée du rapport, sont des protocoles permettant la circulation de données entre deux \textit{\gls{blockchain}s} différentes.\\
+Les \gls{bridge}s, comme explicité dans la partie dédiée du rapport, sont des protocoles permettant la circulation de données entre deux \textit{\gls{blockchain}s} différentes.\\
 Nous avons, au cours de nos recherches, trouvés de nombreux cas d'attaques sur des protocoles d'échanges inter-\gls{blockchain}s. 
-De manière à illustrer les types d'attaques possibles et les points critiques de ces systèmes nous allons décrire deux attaques parmi les plus importantes : \textit{Wormhole} et \textit{Nomad}.
+De manière à illustrer les types d'attaques possibles et les points critiques de ces systèmes nous allons décrire deux attaques parmi les plus importantes : \gls{Wormhole} et \gls{Nomad}.
 
-\subsubsection{Le cas Wormhole}
+\subsubsection{Le cas \gls{Wormhole}}
-Nous vous avons présenté le protocole \textit{Wormhole} dans la partie précédente. 
+Nous vous avons présenté le protocole \textit{\gls{Wormhole}} dans la partie précédente. 
-Le 2 Février 2022, une attaque exploite une erreur d'implémentation dans une \textit{\gls{dApp}} sur la chaîne Solana \cite{SolMed} \cite{SolRekt}. 
+Le 2 Février 2022, une attaque exploite une erreur d'implémentation dans une \textit{\gls{dApp}} sur la chaîne \gls{Solana} \cite{SolMed} \cite{SolRekt}. 
 Pour se faire l'attaquant à réussi à contourner la vérification des signatures des gardiens en exploitant
 une correction de bug ayant été publié sur le code source du projet mais n'étant pas encore effective en production.
-Ainsi il à réussi à récupérer l'équivalent de 120 000 \textit{ETH} en \textit{whETH} (\textit{Wormhole ETH}). 
+Ainsi il à réussi à récupérer l'équivalent de 120 000 \textit{ETH} en \textit{whETH} (\textit{\gls{Wormhole} ETH}). 
-Lors d'un transfert de jetons d'une chaîne à une autre, plusieurs étapes sont réalisées par différentes fonctions.
+Lors d'un transfert d'\gls{actif} d'une chaîne à une autre, plusieurs étapes sont réalisées par différentes fonctions.
 Après la formulation de la transaction, une fonction va se charger de récupérer les signatures des gardiens dans un \textit{SignatureSet}\footnote{Ensemble de signatures de gardiens}, ces dernières sont ensuite vérifiées. 
 Pour cela, une fonction nommée \texttt{verify\_signature} va appeler un programme de vérification de Solana permettant l'analyse du \textit{SignatureSet}. 
 L'appel à ce programme se fait de la manière suivante, en utilisant le nom \texttt{sysvarinstruction} \cite{SolGitError} dans la transaction. 
@@ -24,11 +24,11 @@ Seulement, n'étant pas pour la bonne opération cet ensemble ne peut pas être
 C'est ici que l'attaquant à utilisé un défaut d'implémentation pour valider son \textit{SignatureSet}. 
 Comme décrit précédemment, la fonction \texttt{verify\_signature} appelle un programme pour effectuer la vérification des signatures. 
 Cependant il n'y à pas de vérification faites sur le programme appelé, l'attaquant à pu donc utiliser une adresse différente lui permettant de valider sa transaction. 
-Avec le  \texttt{SignatureSet} ainsi validé, l'attaquant a pu générer un \textit{VAA} valide et pu déclencher une frappe de jeton vers son propre compte sans en avoir déposé au préalable. 
+Avec le  \texttt{SignatureSet} ainsi validé, l'attaquant a pu générer un \textit{VAA} valide et pu déclencher une création d'\gls{actif} vers son propre compte sans en avoir déposé au préalable. 
 La correction de cette faille était contenue dans la mise à jour évoquée en début de paragraphe\cite{SolGitFixed}, permettant la vérification du programme appelé pour la vérification. 
 
 \subsubsection{Le cas Nomad}
-Nomad est un protocole d'interopérabilité entre chaînes permettant de passer des \gls{actif}s entre deux \textit{\gls{blockchain}s} différentes. 
+\gls{Nomad} est un protocole d'interopérabilité entre chaînes permettant de passer des \gls{actif}s entre deux \textit{\gls{blockchain}s} différentes. 
 Pour fonctionner, ce protocole fait appel à des applications décentralisées opérant sur les chaînes du réseau. 
 Une première \textit{\gls{dApp}} appelée \textit{réplica} est déployée sur les \textit{\gls{blockchain}s} recevant les messages, elle fait office de "boite de réception". 
 Une seconde \textit{\gls{dApp}} appelée \textit{home} est déployé sur les \textit{\gls{blockchain}s} émettrices de message. \\
@@ -58,7 +58,7 @@ Cette fonction est utilisée pour approuver le premier message lors du déploiem
 Or ici, la valeur de la racine à été initialisée a $0$, donc cette racine devient une racine valide pour la fonction de vérification des messages. 
 Seulement comme nous l'avons énoncé précédemment, $0$ est la valeur par défaut pour un message n'ayant pas encore été vérifié. 
 Ainsi, lors de l'émission d'un message par la fonction \texttt{process}, tout message non vérifié sera envoyé. 
-Cette erreur d'implémentation a permis à des pirates d'effectuer plusieurs transactions frauduleuses et de retirer l'équivalent de 190 Millions de dollars dans la réserve de liquidité du bridge de Nomad. 
+Cette erreur d'implémentation a permis à des pirates d'effectuer plusieurs transactions frauduleuses et de retirer l'équivalent de 190 Millions de dollars dans la réserve de liquidité du bridge de \gls{Nomad}. 
 Le contrat à été corrigé, dans une mise en ligne datant du 3 Septembre 2022, tel que la racine $0$ n'est plus pré-approuvée. 
 
 \begin{lstlisting}[caption={Fonction corrigée de l'application \textit{Réplica} \cite{NomadGitFixed}}]

docs/rapportFinal/centralisation/bridge.tex

@@ -4,7 +4,7 @@
 
 Comme son nom l’indique, un \textit{\gls{blockchain} bridge} également appelé \textit{\gls{cross-chain} bridge} est un protocole reliant deux \textit{\gls{blockchain}s} entre elles de manière unilatérale ou bilatérale dans une optique d’interopérabilité.\\
 
-Dans la but de comprendre la popularité des \textit{bridges} en tant que protocole d’interopéralité, il faut en premier lieu s’intéresser au marché de la cryptomonnaie. Actuellement Bitcoin domine en représentant 40,5\% de ce dernier, suivie ensuite par Ethereum avec 19,5\%. Cela laisse donc 40\% du marché formé de nombreuses crytomonnaies plus petites et plus indépendantes. C’est donc naturellement, qu’une forte demande de possibilité d’échanges entre les \textit{\gls{blockchain}s} ait vu le jour de la part des utilisateurs ayant plusieurs cryptomonnaies\cite{NgraveNumbers}.\\
+Dans la but de comprendre la popularité des \textit{bridges} en tant que protocole d’interopéralité, il faut en premier lieu s’intéresser au marché de la cryptomonnaie. Actuellement \gls{Bitcoin} domine en représentant 40,5\% de ce dernier, suivie ensuite par \gls{Ethereum} avec 19,5\%. Cela laisse donc 40\% du marché formé de nombreuses crytomonnaies plus petites et plus indépendantes. C’est donc naturellement, qu’une forte demande de possibilité d’échanges entre les \textit{\gls{blockchain}s} ait vu le jour de la part des utilisateurs ayant plusieurs cryptomonnaies\cite{NgraveNumbers}.\\
 
 Il existe trois différentes manières de déplacer les \gls{actif}s en tant que \textit{bridge}. Tout d’abord, le mécanisme de \textit{Lock and Mint} signifiant Verrouiller et Frapper, les \gls{actif}s se trouvant sur la chaîne de départ sont verrouillés sur celle-ci pour être ensuite créés sur la chaîne destinataire. Un autre mode d'échange est celui du \textit{Burnt and Mint}, ce dernier est très similaire à celui déjà présenté, la seule différence étant que les \gls{actif}s sont directement effacés plutôt que verrouillés. Pour finir, les échanges atomiques entre chaînes (Atomic Swaps) permettent un échange direct en pair-à-pair d'\gls{actif}s entre la chaîne d’origine et la chaîne de destinataire.\cite{EthereumMechanism}
 
@@ -25,7 +25,7 @@ Les \textit{Trustless Bridges} sont désignés comme \textit{trustless} car ils
  Les \textit{bridges} peuvent également être distingués en fonction de leur type de vérification. Les plus connus sont la vérification native, externe et locale.\cite{InteroperabilityBhuptani} \\
 
 La vérification native commence par l’utilisation d’un \textit{light client}\cite{NomadDocsNative}. Un client léger est un logiciel permettant de connecter les noeuds des \textit{\gls{blockchain}s} entre elles. Il est codé comme un \textit{\gls{smart contract}} puis est employé de la chaîne de l'expéditeur vers la machine virtuelle de la chaîne destinataire. Si les vérificateurs de données de la chaîne de l'expéditeur sont honnêtes (c’est-à-dire qu’ils n’agissent pas de manière malveillant) alors le client léger est vu comme véridique par la chaîne réceptionnant les \gls{actif}s ou données et peut être utilisé de manière bilatérale.
- Un avantage de cette solution est qu’elle est reconnue comme étant celle reposant le moins sur la confiance parmi celles existantes car les chaînes ne se fient qu’à leurs propres vérificateurs pour effectuer le \textit{bridge}. Un autre bénéfice de ce mécanisme est le fait qu’il n’utilise pas de vérificateurs tiers entre les deux \textit{\gls{blockchain}s} et donc la sécurité dépend de la sécurité des \textit{\gls{blockchain}s} elles-même (ce qui est avantageux si elles sont forcément sécurisées comme la chaîne d’Ethereum par exemple).
+ Un avantage de cette solution est qu’elle est reconnue comme étant celle reposant le moins sur la confiance parmi celles existantes car les chaînes ne se fient qu’à leurs propres vérificateurs pour effectuer le \textit{bridge}. Un autre bénéfice de ce mécanisme est le fait qu’il n’utilise pas de vérificateurs tiers entre les deux \textit{\gls{blockchain}s} et donc la sécurité dépend de la sécurité des \textit{\gls{blockchain}s} elles-même (ce qui est avantageux si elles sont forcément sécurisées comme la chaîne d’\gls{Ethereum} par exemple).
  Un désavantage de cette méthode est que le client léger doit être adapté aux consensus des chaînes auquelles il est attaché ce qui le rend inutilisable avec des chaînes différentes. Le client léger nécessite également de la maintenance en cas de changement des règles consensus (utilisées pour valider les transactions). Un autre inconvénient découlant du fait que le client léger est programmé de manière spécifique est que ce dernier n’est donc pas réutilisable. \\
  \begin{figure}[h!]
     \centering
@@ -36,7 +36,7 @@ La vérification native commence par l’utilisation d’un \textit{light client
 
 \pagebreak
 
-La vérification externe consiste en un ensemble de vérificateurs n’appartenant pas aux \textit{\gls{blockchain}s} relayant les données entre les deux extrémités du \textit{bridge}. Pour se faire, un certains nombre de vérificateurs doivent signer un message provenant de la chaîne d’envoi pour que le chaîne destinataire le reconnaisse comme valide. Par exemple, pour le \textit{bridge} Wormhole 13 vérificateurs sur 19 doivent avoir signé\cite{NomadDocsExternal}. Ce concept est une primitive cryptographique (algorithme cryptographique de bas niveau servant de base à un système de sécurité informatique) nommée système de signature à seuil (désignée par TSS pour \textit{Threshold Signature Scheme})\cite{BinanceTSS}. 
+La vérification externe consiste en un ensemble de vérificateurs n’appartenant pas aux \textit{\gls{blockchain}s} relayant les données entre les deux extrémités du \textit{bridge}. Pour se faire, un certains nombre de vérificateurs doivent signer un message provenant de la chaîne d’envoi pour que le chaîne destinataire le reconnaisse comme valide. Par exemple, pour le \textit{bridge} \gls{Wormhole} 13 vérificateurs sur 19 doivent avoir signé\cite{NomadDocsExternal}. Ce concept est une primitive cryptographique (algorithme cryptographique de bas niveau servant de base à un système de sécurité informatique) nommée le système de signature à seuil (désignée par TSS pour \textit{Threshold Signature Scheme})\cite{BinanceTSS}. 
 Contrairement à la vérifications native, les \textit{bridges} vérifiés de manière externe sont faciles à développer, peuvent être réutilisés sans problèmes et leur maintenance coûte peu. Le désavantage conséquent de cette méthode est que la sécurité dépend des vérificateurs tiers du pont ce qui peut fragiliser le système car ils sont généralement moins sécurisés que ceux des \textit{\gls{blockchain}s}. \\
 \begin{figure}[h!]
     \centering
@@ -88,9 +88,9 @@ Une faiblesse spécifique des \textit{bridges trusted} repose sur le fait que le
 
 Comme vu dans la section présentant les différentes méthodes d’échange des \textit{bridges}, ces derniers frappent les \gls{actif}s désirés sur la chaîne destinataire. Certains attaquants peuvent profiter de ce mécanisme de frappe pour effectuer ce qu’on appelle une \textit{Infinite Mint Attack}.\cite{ChainLinkRisks} Cette attaque peut se résumer à un \textit{hacker} générant un nombre élevé d’\gls{actif}s en utilisant une faille d’un \textit{bridge} sans verrouiller ou brûler d’\gls{actif}s sur sa \textit{\gls{blockchain}}. Suite à cela, l’individu réintroduit ces \gls{actif}s sur le marché ce qui fait violemment baisser leur coût ce qui engendre un risque financier systémique.\\
 
-Les \textit{\gls{blockchain} Bridges} sont très rapidement devenus un outil indispensable des échanges centralisés, mais il ne faut pas oublier que ces protocoles sont relativement récents. Créés par de petites \gls{blockchain}s comme Syscoin et NEAR Protocol dans le but de rentre leurs chaînes interopérables avec les applications décentralisées d’Ethereum, les premiers bridges datent de 2020\cite{Bitstamp}. Par conséquent, nous ne connaissons pas encore le comportement des \textit{bridges} lorsqu’ils font face à des scénarios sortants de la norme comme des attaques réseaux, un retour en arrière sur les transactions d’une \gls{blockchain} (souvent désigné par le terme \textit{rollback}) ou bien pendant une congestion du réseau. Ces zones d’incertitudes peuvent donc être une source de risques. \\
+Les \textit{\gls{blockchain} Bridges} sont devenus un outil indispensable des échanges centralisés très rapidement, mais il ne faut pas oublier que ces protocoles sont relativement récents. Créés par de petites \gls{blockchain}s comme Syscoin et NEAR Protocol dans le but de rentre leurs chaînes interopérables avec les applications décentralisées d’\gls{Ethereum}, les premiers bridges datent de 2020\cite{Bitstamp}. Par conséquent, nous ne connaissons pas encore le comportement des \textit{bridges} lorsqu’ils font face à des scénarios sortants de la norme comme des attaques réseaux, un retour en arrière sur les transactions d’une \gls{blockchain} (souvent désigné par le terme \textit{rollback}) ou bien pendant une congestion du réseau. Ces zones d’incertitudes peuvent donc être une source de risques. \\
 
-Un autre facteur portant atteinte à la sécurité des \textit{bridges} est le fait que certains ont leur code en \textit{open source} dans une démarche de transparence et d’envie d’instaurer une relation de confiance avec les utilisateurs. Malheureusement cela donne l’occasion aux personnes malveillantes de mieux comprendre le fonctionnement du \textit{bridge} et donc de pouvoir l’attaquer. L’attaque Wormhole est un exemple connu d’attaque exploitant cette faiblesse.
+Un autre facteur portant atteinte à la sécurité des \textit{bridges} est le fait que certains ont leur code en \textit{open source} dans une démarche de transparence et d’envie d’instaurer une relation de confiance avec les utilisateurs. Malheureusement cela donne l’occasion aux personnes malveillantes de mieux comprendre le fonctionnement du \textit{bridge} et donc de pouvoir l’attaquer. L’attaque \gls{Wormhole} est un exemple connu d’attaque exploitant cette faiblesse.
 
 \begin{figure}[h!]
     \centering
@@ -140,6 +140,6 @@ Maintenant que les possibles obstacles au bon fonctionnement du \textit{bridge}
 
 La faculté de l’observateur à pouvoir couper la connexion s’il conteste la transaction lui permet d’effectuer un déni de service appelé \textit{Watcher DoS}. C’est pourquoi il lui ait possible de fermer définitivement la connexion d’une transaction si ce dernier continue sans cesse de couper le processus sans raison valable. Heureusement, la fermeture ne concerne que la connexion et n’impacte en aucun cas le système du \textit{bridge}. Cependant cette attaque semble irrationnelle en terme de ressources et de temps car l’observateur effectuant le déni de service ne gagne rien financièrement contrairement au processus habituel. En effet, si un observateur prouve une fraude correctement, ce dernier peut récupérer le collatéral du vérificateur. Mais ici puisqu’aucune fraude n’est prouvée les données se trouvant sur la chaîne d’origine sont conservées et sécurisés. Cela cause seulement une perte de temps pour l’utilisateur ou l’application décentralisée voulant effectuer l'échange d’une \textit{\gls{blockchain}} à une autre.
 
-Une réponse à ce problème actuellement mise en œuvre par le \textit{bridge} de Nomad est la présence d’un groupe restreint d’observateurs autorisés à contester, de cette manière il est facile de connaître les observateurs malveillants. Chaque observateur possède une clé permettant de signer une attestation confirmant la présence d’une fraude dans la transaction, chaque \textit{bridge} stocke un ensemble contenant les adresses des attestations appartenant aux observateurs autorisés. Si l’attestation reçue par le \textit{bridge} est présente dans l’ensemble alors la connexion est rompue\cite{NomadDocsWatcher}.
+Une réponse à ce problème actuellement mise en œuvre par le \textit{bridge} de \gls{Nomad} est la présence d’un groupe restreint d’observateurs autorisés à contester, de cette manière il est facile de connaître les observateurs malveillants. Chaque observateur possède une clé permettant de signer une attestation confirmant la présence d’une fraude dans la transaction, chaque \textit{bridge} stocke un ensemble contenant les adresses des attestations appartenant aux observateurs autorisés. Si l’attestation reçue par le \textit{bridge} est présente dans l’ensemble alors la connexion est rompue\cite{NomadDocsWatcher}.
 Sur le long terme, une proposition consistant à la mise en place de frais si l’on souhaite contester est en train d’être étudiée. Le montant doit répondre à deux contraintes: ce dernier doit être assez haut pour dissuader les observateurs malhonnêtes mais assez bas pour que ceux ayant réellement l’envie de prouver de manière valide une fraude existante puissent le faire. Dans la continuité de cette solution, il serait également possible de récupérer la signature de la déconnexion générée par l’observateur sur la chaîne originale et de le pénaliser en lui retirant les frais qu’il a payé tel une garantie\cite{OptimisticBhuptani}.
 

docs/rapportFinal/centralisation/limites.tex

@@ -3,7 +3,7 @@ Pour conclure sur les échanges centralisés, nous avons pu voir que le fonction
 En effet, les protocoles employés ne sont pas ou peu explicités, nous avons trouvé peu de documentation technique au cours de nos recherches. 
 La majeure partie de la documentation que nous avons pu trouver concernant les plate-formes d'échanges centralisé sont à destination des utilisateurs de ces plate-formes, donc à des personnes n'ayant pas forcément un bagage de connaissance dans les \textit{\gls{blockchain}s}. 
 C'est pour cela que nombreuses de nos sources concernant les plate-formes centralisés sont issues de réseaux sociaux ou d'articles web à destination de lecteurs spécialisés dans le domaine. 
-La solution centralisée au fonctionnement le plus ouvert au public que nous avons trouvé est \textit{Wormhole}, il s'avère que ce protocole à aussi été victime d'une attaque de grande envergure. \\
+La solution centralisée au fonctionnement le plus ouvert au public que nous avons trouvé est \textit{\gls{Wormhole}}, il s'avère que ce protocole à aussi été victime d'une attaque de grande envergure. \\
 Nous pouvons ainsi nous questionner sur la présence de l'intermédiaire de confiance dans l'échange centralisé. 
 En effet, la majeure partie des attaques observés sur des \textit{Bridges} ou plus généralement sur des protocoles d'échanges centralisés, résultent de problèmes d'implémentation dans le code de ces protocoles. 
 Le tiers de confiance est donc un point d'entrée pour les pirates vers les \gls{actif}s des utilisateurs. 

docs/rapportFinal/centralisation/wormhole.tex

@@ -1,14 +1,14 @@
 En 2017, une cryptomonnaie adossée à la \textit{\gls{blockchain}} Solana a émergée avec des caractéristiques
-similaires à Ethereum : \textit{\gls{blockchain}} publique, \textit{\gls{smart contract}s}.\\
+similaires à \gls{Ethereum} : \textit{\gls{blockchain}} publique, \textit{\gls{smart contract}s}.\\
-Solana est devenue de facto une \textit{\gls{blockchain}} concurrente à Ethereum et est aujourd'hui 
+Solana est devenue de facto une \textit{\gls{blockchain}} concurrente à \gls{Ethereum} et est aujourd'hui 
 la onzième \textit{\gls{blockchain}} en terme de capitalisation selon l'aggrégateur de marché Coinmarketcap.\\
-Un besoin d'échanger des \gls{actif}s entre les \textit{\gls{blockchain}s} Ethereum et Solana est apparu, 
+Un besoin d'échanger des \gls{actif}s entre les \textit{\gls{blockchain}s} \gls{Ethereum} et Solana est apparu, 
-d'où l'introduction en 2020 de la première version de Wormhole.
+d'où l'introduction en 2020 de la première version de \gls{Wormhole}.
-Initialement, Wormhole v1 a été concu comme un \textit{bridge} entre Ethereum et Solana.
+Initialement, \gls{Wormhole} v1 a été concu comme un \textit{bridge} entre \gls{Ethereum} et Solana.
-Depuis, Wormhole s'est développé au-delà de Solana avec le lancement d'une deuxième version en 2021 
+Depuis, \gls{Wormhole} s'est développé au-delà de Solana avec le lancement d'une deuxième version en 2021 
 en tant que protocole générique de passage de messages.\\
-À l'écriture de ce rapport, 22 \cite{wormholeNetwork} \textit{\gls{blockchain}s} sont compatibles avec Wormhole 
+À l'écriture de ce rapport, 22 \cite{wormholeNetwork} \textit{\gls{blockchain}s} sont compatibles avec \gls{Wormhole} 
-dont : BNBChain, Ethereum, Moonbeam, Polygon, Solana...\\
+dont : BNBChain, \gls{Ethereum}, Moonbeam, Polygon, Solana...\\
 Le protocole émet un message à partir d'une \textit{\gls{blockchain}} source qui est validé par un réseau de 
 gardiens.\\ 
 Le message est ensuite envoyé à la \textit{\gls{blockchain}} cible pour être traité.
@@ -19,19 +19,19 @@ Lorsqu'un \textit{\gls{smart contract}} envoie un message \textit{crosschain} co
 de jetons sur une \textit{\gls{blockchain}} source et une demande de frappe de jetons sur une 
 \textit{\gls{blockchain}} cible, celui-ci interargit avec un \textit{core contract} \cite{wormholeCoreContract}.
 Un \textit{core contract} est déployé sur toutes les \textit{\gls{blockchain}s} compatibles avec le protocole 
-Wormhole. Tout \textit{core contract} est observé par le réseau de gardiens.
+\gls{Wormhole}. Tout \textit{core contract} est observé par le réseau de gardiens.
-Un message Wormhole est émis grâce à la fonction \textit{publishMessage()} prenant en entrée le \textit{payload}.
+Un message \gls{Wormhole} est émis grâce à la fonction \textit{publishMessage()} prenant en entrée le \textit{payload}.
 La sortie de cette fonction est un \textit{sequence number}, un numéro d'index unique pour le message.
 Combiné à l'adresse du contrat de l'émetteur et à l'identifiant de la chaîne de l'émetteur, le message 
 correspondant peut être récupéré auprès d'un nœud du réseau de gardiens.\\
-Un message Wormhole est vérifié grâce à la fonction \textit{parseAndVerifyVAA()} prenant en entrée le message.
+Un message \gls{Wormhole} est vérifié grâce à la fonction \textit{parseAndVerifyVAA()} prenant en entrée le message.
 Selon la validité de l'entrée, la fonction retourne en sortie le \textit{payload} ou une exception.
 
-VAA \cite{wormholeVAA} est la primitive de messagerie de base de Wormhole. Un VAA contient une en-tête 
+\acrshort{vaa} \cite{wormholeVAA} est la primitive de messagerie de base de \gls{Wormhole}. Un VAA contient une en-tête 
 ainsi qu'un \textit{body}. L'en-tête contient l'index des gardiens ayant signés le message et la collection des signatures.
 L'en-tête permet au \textit{core contract} de vérifier l'authenticité du VAA.
 Quant au \textit{body}, il contient des informations comme le numéro d'identification de la chaîne 
-Wormhole du contrat émetteur, l'adresse du contrat émetteur, le \textit{sequence number} 
+\gls{Wormhole} du contrat émetteur, l'adresse du contrat émetteur, le \textit{sequence number} 
 et le \textit{payload}.\\ 5 \textit{payloads} peuvent être utilisés dont \textit{Transfer} et 
 \textit{AssetMeta}, attestant les méta-données du jeton.\\
 Le \textit{payload AssetMeta} est obligatoire avant un premier transfert.
@@ -55,21 +55,21 @@ Un gardien \cite{wormholeGuardian} est une autorité de confiance qui a comme r
 Comme évoqué précédemment, le réseau de gardiens observe tous les messages \textit{crosschain} via la 
 surveillance des \textit{core contracts}.
 Le réseau de gardiens est composé de 19 gardiens à parts égales sans chef (\textit{leaderless}).
-Il est conçu pour servir d'oracle à Wormhole et est l'élement le plus critique de l'écosystème.
+Il est conçu pour servir d'oracle à \gls{Wormhole} et est l'élement le plus critique de l'écosystème.
 Si une majorité de deux tiers ou plus des gardiens signent le même VAA, alors le consensus est atteint : 
-le VAA est automatiquement considéré valide par  tous les contrats Wormhole sur toutes les 
+le VAA est automatiquement considéré valide par  tous les contrats \gls{Wormhole} sur toutes les 
 \textit{\gls{blockchain}s} et le \textit{payload} est actionné. 
 Chaque gardien utilise un algorithme de signature à courbe elliptique : ECSDA pour 
 \textit{Elliptic Curve Signature Digital Algorithm}.
 Plus précisément, chaque gardien se réfère à «secp256k1» comme paramètres de la courbe elliptique, 
-aussi utilisé par les \textit{\gls{blockchain}s} Bitcoin et Ethereum.\\
+aussi utilisé par les \textit{\gls{blockchain}s} \gls{Bitcoin} et \gls{Ethereum}.\\
 Le modèle de consensus utilisé est une \textit{Proof of Authority} (PoA) avec un système de 
 \textit{multisignature} M/N \cite{wormholeChainswap}, c'est à dire que M clefs parmi N sont nécessaires 
 pour signer un VAA. Ce modèle permet un traitement rapide des transactions et une dispense de participation monétaire, par rapport à la preuve de travail (PoW) et la preuve 
 de participation (PoS). Cependant, il présente également des désavantages : le système est par 
 \textit{design} centralisé et dépend d'un petit groupe de nœuds pouvant créer un point de 
 défaillance unique par l'utilisation commune d'une fonction vulnérable. Il est questionnable de restaurer des tiers de confiance dans le cadre d'un système 
-devenu populaire grâce à l'absence de tels autorités. Wormhole justifie la décentralisation de leur 
+devenu populaire grâce à l'absence de tels autorités. \gls{Wormhole} justifie la décentralisation de leur 
 système \cite{wormholeGuardian} par la présence de plusieurs parties (et non d'un seul) dans le contrôle du réseau.
 Selon notre analyse, la décentralisation résulte de l'absence d'un ou plusieurs tier(s) de confiance lorsque deux parties 
 souhaitent réaliser une transaction.
@@ -87,7 +87,7 @@ d'héberger soi-même ces relais pour supporter son application.
     \centering
     \includegraphics[scale=0.5]{centralisation/uml_design_v2.png}
     \label{fig:wormholeDesign}
-    \caption{Architecture Wormhole \cite{wormholeArch}}
+    \caption{Architecture \gls{Wormhole} \cite{wormholeArch}}
   \end{figure}
 
 % @startuml

docs/rapportFinal/decentralisation/atomic_swaps_htlc.tex

@@ -1,7 +1,7 @@
 %author: Dorian VOLPE
 \subsubsection{HTLC}
 
-Un HTLC est un type de \textit{\gls{smart contract}} utilisé dans les applications \textit{\gls{blockchain}} qui réduit le risque de contrepartie en créant une garantie basée sur le temps et une autre sur un verrou cryptographique\cite{narayanam2022generalized}.
+Un \acrshort{htlc} est un type de \textit{\gls{smart contract}} utilisé dans les applications \textit{\gls{blockchain}} qui réduit le risque de contrepartie en créant une garantie basée sur le temps et une autre sur un verrou cryptographique\cite{narayanam2022generalized}.
 Ils reposent sur deux primitives fondamentales: le verrou de hachage et le verrou temporel.\\
 Premièrement le verrou de hachage (ou bien \textit{hashlock}): Ce dernier va fonctionner comme une assurance qui va couvrir les parties participantes à la transaction, en leur garantissant que chaque modification de l'échange soit réalisée d'un commun accord de toutes les parties.
 Cela est mis en place grâce à un partage du hachage de la clef privée de la transaction, ce partage va donc impliquer que le canal de paiement mis en place ne puisse être ouvert ou fermé qu'avec l'accord de tous les participants.\\
@@ -20,13 +20,13 @@ L’intérêt principal de ce type de contrat est qu'il permet d'effectuer facil
     \label{fig:HTLC}
 \end{figure}
 \subsubsection{Atomic swaps}
-Les \textit{atomics swaps} ou bien échanges atomiques sont des échanges effectués entre deux \textit{\gls{blockchain}s}\cite{herlihy2018atomic}. On les appelle "atomiques" car il respecte une primitive essentielle à leur fonctionnement et à leur principe d'utilisation: 
+Les \textit{atomics swaps} ou bien \glspl{atomic swap} sont des échanges effectués entre deux \textit{\gls{blockchain}s}\cite{herlihy2018atomic}. On les appelle "atomiques" car il respecte une primitive essentielle à leur fonctionnement et à leur principe d'utilisation: 
 l'échange est insécable, c'est-à-dire qu'a son issue, soit il s'est pleinement exécuté, soit l'état antérieur à l'échange est préservé.
 Cette primitive permet de garantir que les participants ne seront jamais dans des états jugés "inacceptables". \\
 En effet les échanges atomiques partent du postulat que si une partie suit le protocole à la lettre alors, 
 il ne sera jamais perdant. A contrario les partis ne suivant pas le protocole par malveillance ou par erreur, prennent le risque de perdre leurs mises de départ.\\ \\
-Lors d'un échange atomique les HTLC vont être utilisés de manière centrale car ils vont permettre d'apporter les garanties que nous avons vue dans la partie précédente. Il faut voir les échanges atomiques comme une généralisation de l'utilisation des HTLC. Lors d'un échange atomique les deux \textit{\gls{blockchain}s} mises en relation doivent pouvoir communiquer et échanger sur une interface commune comme un portefeuille multi signature ou un canal d'échange mis en place spécialement pour cette transaction. \\ \\
+Lors d'un \gls{atomic swap} les HTLC vont être utilisés de manière centrale car ils vont permettre d'apporter les garanties que nous avons vue dans la partie précédente. Il faut voir les échanges atomiques comme une généralisation de l'utilisation des HTLC. Lors d'un \gls{atomic swap} les deux \textit{\gls{blockchain}s} mises en relation doivent pouvoir communiquer et échanger sur une interface commune comme un portefeuille multi signature ou un canal d'échange mis en place spécialement pour cette transaction. \\ \\
-Si nous nous penchons sur le déroulement d'un échange atomique à deux parties nous pouvons déduire les étapes suivantes: 
+Si nous nous penchons sur le déroulement d'un \gls{atomic swap} à deux parties nous pouvons déduire les étapes suivantes: 
 \begin{enumerate}
     \item Les deux parties participent à l'échange, créant un HTLC (sur chaque \textit{\gls{blockchain}}) dans lequel les fonds sont bloqués. 
     \item Ils échangent les informations nécessaires pour effectuer une transaction sur la \textit{\gls{blockchain}} de l'autre partie. 
@@ -38,7 +38,7 @@ Si nous nous penchons sur le déroulement d'un échange atomique à deux parties
 \begin{figure}[h!]
     \centering
     \includegraphics[scale=0.15]{decentralisation/atomicSwap.png}
-    \caption{Déroulement simplifié d'un échange atomique}
+    \caption{Déroulement simplifié d'un \gls{atomic swap}}
     \label{fig:atomicSwap}
 \end{figure}
 

docs/rapportFinal/decentralisation/index.tex

@@ -13,5 +13,5 @@
 \subsection[Atomic swaps et HTLC]{Atomic swaps et HTLC}
 \input{decentralisation/atomic_swaps_htlc.tex}
 
-\subsection[Échanges "off-chain"]{Les échanges \textit{off-chain}}
+\subsection[Échanges "off chain"]{Les échanges \textit{off chain}}
 \input{decentralisation/lightning.tex}

docs/rapportFinal/decentralisation/lightning.tex

@@ -1,22 +1,22 @@
 %author: Dorian VOLPE
-\subsubsection{Fonctionnement des échanges \textit{off-chain}}
+\subsubsection{Fonctionnement des échanges \textit{\gls{off chain}}}
-Les échanges \textit{off-chain} sont des transactions de crypto-\gls{actif} dont on déplace la valeur en dehors de la \textit{\gls{blockchain}} mère. En d’autres termes, il s’agit de la négociation de la valeur d’un \gls{actif} crypto en dehors de la \textit{\gls{blockchain}} source. Les transactions \textit{on-chain} sont les échanges d'\gls{actif}s qui ont lieu sur la \textit{\gls{blockchain}} elle-même.
+Les échanges \textit{\gls{off chain}} sont des transactions de crypto-\gls{actif} dont on déplace la valeur en dehors de la \textit{\gls{blockchain}} mère. En d’autres termes, il s’agit de la négociation de la valeur d’un \gls{actif} crypto en dehors de la \textit{\gls{blockchain}} source. Les transactions \textit{on-chain} sont les échanges d'\gls{actif}s qui ont lieu sur la \textit{\gls{blockchain}} elle-même.
 Ils sont des échanges d’\gls{actif}s internes au réseau et ont donc leurs propres grands livres, authentification et coûts qui ont lieu parmi la \textit{\gls{blockchain}}.
 \begin{figure}[h!]
     \centering
     \stackunder{\includegraphics[scale=0.3]{decentralisation/offchain.png}}
-    {\scriptsize Source: \url{https://www.cryptoencyclopedie.com/single-post/\gls{blockchain}-comprendre-distinction-on-chain-off-chain}}
+    {\scriptsize Source: \url{https://www.cryptoencyclopedie.com/single-post/\gls{blockchain}-comprendre-distinction-on-chain-\gls{off chain}}}
-    \caption{Architecture \textit{off-chain}}
+    \caption{Architecture \textit{\gls{off chain}}}
     \label{fig:offchain}
 \end{figure}
-Les transactions \textit{off-chain} sont confirmées en dehors du réseau principal de la \textit{\gls{blockchain}}, ce qui entraîne souvent un processus moins cher et plus rapide pour l’utilisateur. 
+Les transactions \textit{\gls{off chain}} sont confirmées en dehors du réseau principal de la \textit{\gls{blockchain}}, ce qui entraîne souvent un processus moins cher et plus rapide pour l’utilisateur. 
 Tout cela se fait dans un objectif bien précis qui est de garder le maximum de sécurité et de fiabilité de la \textit{\gls{blockchain}} mère tout en essayant d'améliorer la vitesse d'échange et les frais de transaction.
-Afin d'illustrer comment fonctionne les échanges \textit{off-chain} nous allons nous concentrer sur une implémentation en particulier: le réseau Lightning. 
+Afin d'illustrer comment fonctionne les échanges \textit{\gls{off chain}} nous allons nous concentrer sur une implémentation en particulier: le réseau Lightning. 
 
 \subsubsection{Le réseau lightning}
 
-Le réseau lightning (provenant de l'anglais \textit{Lightning Network} et abrégé par LN) fait partie des processus d'échanges que l'on qualifie d'\textit{off-chain} car il se déroule en dehors de leur \textit{\gls{blockchain}s} principale, ce protocole est un cas concret de cette famille.
+Le réseau lightning (provenant de l'anglais \textit{Lightning Network} et abrégé par LN) fait partie des processus d'échanges que l'on qualifie d'\textit{\gls{off chain}} car il se déroule en dehors de leur \textit{\gls{blockchain}s} principale, ce protocole est un cas concret de cette famille.
-Ce réseau est une couche de protocole de paiement construite au-dessus de la \textit{\gls{blockchain}} Bitcoin qui vise à accélérer les transactions  Bitcoin, à réduire les coûts et à améliorer la mise a l'échelle \cite{poon2016bitcoin}.
+Ce réseau est une couche de protocole de paiement construite au-dessus de la \textit{\gls{blockchain}} \gls{Bitcoin} qui vise à accélérer les transactions  \gls{Bitcoin}, à réduire les coûts et à améliorer la mise a l'échelle \cite{poon2016bitcoin}.
 Il permet aux utilisateurs de créer des canaux de paiement peer-to-peer bidirectionnels  pour effectuer des transactions en dehors de la \textit{\gls{blockchain}} principale (voir Figure \ref{fig:lightningCouche}), permettant des transactions plus rapides, moins chères et plus privées.\\
 Les transactions sur le réseau lightning sont effectuées avec des \gls{smart contract}s qui permettent aux utilisateurs de transférer des fonds à des tiers sans l'approbation de la \textit{\gls{blockchain}} principale ou bien d'un tiers de confiance. 
 Les canaux de paiement flash sont créés en verrouillant temporairement des fonds sur une adresse multi-signature (voir Figure \ref{fig:lightningNetwork}), qui est ensuite utilisée pour envoyer des transactions à d'autres participants du réseau.\\ 
@@ -28,7 +28,7 @@ Les frais d'utilisation de ce réseau sont généralement bien inférieurs aux f
     \centering
     \stackunder{    \includegraphics[scale = 0.3 ]{decentralisation/lightningCouche.png}  }
     {\scriptsize Source: \url{https://www.bitpanda.com/academy/fr/lecons/quel-est-le-role-du-lightning-network-pour-bitcoin/}}
-        \caption{Le réseau Lightning par rapport a la \textit{\gls{blockchain}} Bitcoin principale}
+        \caption{Le réseau Lightning par rapport a la \textit{\gls{blockchain}} \gls{Bitcoin} principale}
         \label{fig:lightningCouche}
     \end{figure}
 
@@ -43,7 +43,7 @@ Les frais d'utilisation de ce réseau sont généralement bien inférieurs aux f
 Voici le déroulement classique d'un échange sur le réseau Lightning:\\ Alice veut échanger avec Bob à travers le réseau Lightning (sur la même ou bien sur des \textit{\gls{blockchain}s} différentes). 
 Alice va donc ouvrir un portefeuille multi-signature\footnote{Portefeuille qui nécessite plusieurs signatures pour effectuer une transaction} avec Bob. Ils vont mettre une "mise de départ" qu'ils vont déposer dans le portefeuille mentionné précédemment (le canal d'échange aura donc la taille des deux mises de départ cumulées).
 Ensuite ils vont effectuer leurs transactions dans ce portefeuille qui va être mis à jour à chaque transaction.\\ \\ 
-Il est fondamental de noter que chaque transaction invalide les précédentes (à l'exception de la toute première). Lorsque l'un des participants souhaite terminer l'échange il va publier sur la \textit{\gls{blockchain}} Bitcoin la dernière transaction effectuée.
+Il est fondamental de noter que chaque transaction invalide les précédentes (à l'exception de la toute première). Lorsque l'un des participants souhaite terminer l'échange il va publier sur la \textit{\gls{blockchain}} \gls{Bitcoin} la dernière transaction effectuée.
 Ce mécanisme de transaction intermédiaire est mis en place afin d'éviter qu'un des deux acteurs de l'échange ne puisse "s'échapper" de l'échange, car chacune des parties va signer avec sa clef privée la dernière transaction. \\
 Aussi tous ces échanges se passent à l'intérieur du réseau Lightning, la \textit{\gls{blockchain}} principale n'a donc aucune idée du nombre exact de transactions intermédiaires effectuées puisque seule une transaction sera envoyée sur la \textit{\gls{blockchain}} principale. 
 Cela permet d'éviter d'engendrer des frais de transactions inutiles ou bien de congestionner la \textit{\gls{blockchain}} principale.\\ \\
@@ -62,7 +62,7 @@ Leur programme rajoute 4 commandes au réseau Lightning mentionné précédemmen
 \begin{itemize}
     \item \textit{Price}: Commande qui permet aux utilisateurs de rechercher la valeur marchande actuelle en USD de toute crypto-monnaie disponible sur le site \textit{coinranking.com}.\\
     \item \textit{Compare}: Permet de comparer la valeur en USD de deux cryptomonnaies différente et de faire l'équivalent d'une cryptomonnaie à une autre. Cette commande utilise la commande \textit{Price} mentionnée au-dessus.\\
-    \item \textit{Exchange} : La commande \textit{Exchange} est la première des deux commandes développées pour effectuer des échanges inter-chaînes. Elle permet de spécifier les montants mis en jeu lors de l'échange. Si Alice veut échanger 20 Bitcoin (à travers le canal 1) pour 10 Litecoin (à travers le canal 2) avec Bob, elle entrerait "Exchange 1 20 2 10 ».\\
+    \item \textit{Exchange} : La commande \textit{Exchange} est la première des deux commandes développées pour effectuer des échanges inter-chaînes. Elle permet de spécifier les montants mis en jeu lors de l'échange. Si Alice veut échanger 20 \gls{Bitcoin} (à travers le canal 1) pour 10 Litecoin (à travers le canal 2) avec Bob, elle entrerait "Exchange 1 20 2 10 ».\\
     \item \textit{Respond} : À ce stade, Bob a une minute pour décider si pour accepter la demande d'échange d'Alice. Il peut faire l'une des trois choses suivantes : répondre oui et accepter l'échange, répondre non et le refuser, ou laisser la demande \textit{timeout}.\\
 \end{itemize}
 

docs/rapportFinal/decentralisation/pools.tex

@@ -1,7 +1,7 @@
 % Autheur: Amaury JOlY
 
 \subsubsection{Definition}
-Les réserves de liquidité sont des marchés automatisés qui permettent aux utilisateurs de fournir des liquidités pour les échangeurs décentralisés (DEX) et de 
+Les réserves de liquidité sont des marchés automatisés qui permettent aux utilisateurs de fournir des liquidités pour les échangeurs décentralisés (\acrshort{dex}) et de 
 remporter une comission à chaque transaction \cite{jensen2021introduction, belchior2022survey, augustin2022yield}. 
 Les fournisseurs de liquidités déposent des fonds dans une réserve de liquidité et reçoivent des jetons 
 LP\footnote{Liquidity Provider Token} en retour. Les jetons LP représentent une part de propriété dans la réserve de liquidité et peuvent être utilisés pour 
@@ -38,5 +38,5 @@ utilisateurs d’acheter ou de vendre des actifs sur la plateforme. Enfin, les r
 une réserve de liquidités est compromise, les utilisateurs peuvent perdre leurs fonds. \\
 Un exemple d'attaque sur une réserve de liquidité est la CVE-2021-3006 \cite{nvd2021-3006,blocksec2021Seal}. La CVE-2021-3006 est une vulnérabilité de sécurité qui a été exploitée en décembre 
 2020 et janvier 2021. Elle concerne un manquement de controle d'accès dans l’implémentation du \textit{\gls{smart contract}} pour une réserve de liquidité en lien avec 
-Seal Finance (Seal), un jeton Ethereum. Cette vulnérabilité permet une manipulation des prix ayant permis à l'attaquant de réaliser une plus-value artificiel 
+Seal Finance (Seal), un jeton \gls{Ethereum}. Cette vulnérabilité permet une manipulation des prix ayant permis à l'attaquant de réaliser une plus-value artificiel 
-sur ses jetons.
+sur ses jetons.

docs/rapportFinal/decentralisation/relay.tex

@@ -1,18 +1,18 @@
 %auteur: Amaury JOLY
 \subsubsection{Définition}
-Les relays décentralisés sont des applications décentralisés permettant une intéropérabilités entre les \textit{\gls{blockchain}s} \cite{qin2018overview, westerkamp2022verilay,belchior2022survey}.
+Les \gls{relay}s décentralisés sont des applications décentralisés permettant une intéropérabilités entre les \textit{\gls{blockchain}s} \cite{qin2018overview, westerkamp2022verilay,belchior2022survey}.
-Leur but est de transmettre des informations entre des \textit{\gls{blockchain}s} distinctes (par exemple, Bitcoin et Ethereum). 
+Leur but est de transmettre des informations entre des \textit{\gls{blockchain}s} distinctes (par exemple, \gls{Bitcoin} et \gls{Ethereum}). 
-Les relays suivent une partie de l’état de leurs chaînes connectées afin de prouver l’existence de transactions d’une chaîne à l’autre.
+Les \gls{relay}s suivent une partie de l’état de leurs chaînes connectées afin de prouver l’existence de transactions d’une chaîne à l’autre.
 
 \subsubsection{BTCRelay}
-BTCRelay est un \textit{smart contract} qui stocke les en-têtes de blocs Bitcoin sur la \textit{\gls{blockchain}} Ethereum. \cite{qin2018overview,belchior2022survey,btcrelay2022web,btcrelay2022git}
+BTCRelay est un \textit{\gls{smart contract}} qui stocke les en-têtes de blocs \gls{Bitcoin} sur la \textit{\gls{blockchain}} \gls{Ethereum}. \cite{qin2018overview,belchior2022survey,btcrelay2022web,btcrelay2022git}
-BTCRelay utilise ces en-têtes de blocs pour construire une mini-version de la \textit{\gls{blockchain}} Bitcoin: une méthode utilisée par les 
+BTCRelay utilise ces en-têtes de blocs pour construire une mini-version de la \textit{\gls{blockchain}} \gls{Bitcoin}: une méthode utilisée par les 
-portefeuilles légers Bitcoin SPV. \footnote{Bitcoin SPV signifie Simplified Payment Verification et c’est un moyen pour Bitcoin de se 
+portefeuilles légers \gls{Bitcoin} SPV. \footnote{\gls{Bitcoin} SPV signifie Simplified Payment Verification et c’est un moyen pour \gls{Bitcoin} de se 
 développer et de se propager en fonctionnant sur des petits appareils, comme les téléphones portables et les ordinateurs portables.}
-BTCRelay est open source, sans confiance et décentralisé. Il permet aux contrats Ethereum de vérifier les transactions Bitcoin sans aucun 
+BTCRelay est open source, sans confiance et décentralisé. Il permet aux contrats \gls{Ethereum} de vérifier les transactions \gls{Bitcoin} sans aucun 
-intermédiaire: en d’autres termes, les utilisateurs peuvent payer avec Bitcoin pour utiliser les DAPPs Ethereum. Il offre également la 
+intermédiaire: en d’autres termes, les utilisateurs peuvent payer avec \gls{Bitcoin} pour utiliser les \gls{dApp}s \gls{Ethereum}. Il offre également la 
-possibilité de relayer la transaction Bitcoin à n’importe quel contrat Ethereum et d’inspecter le dernier en-tête de bloc Bitcoin stocké 
+possibilité de relayer la transaction \gls{Bitcoin} à n’importe quel contrat \gls{Ethereum} et d’inspecter le dernier en-tête de bloc \gls{Bitcoin} stocké 
-dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle de Bitcoin vers Ethereum.\\
+dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle de \gls{Bitcoin} vers \gls{Ethereum}.\\
 
 \begin{figure}[h!]
   \centering
@@ -25,16 +25,16 @@ dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle
 Un exemple d'usage de BTCrelay pour de l'echange \gls{cross-chain} est le projet tBTC, qui permet aux utilisateurs d’échanger des bitcoins contre des 
 tokens ERC-20 représentant des bitcoins sur la \textit{\gls{blockchain}} Ethereum \cite{hildebrandt2020tokenization,lan2021horizon}. tBTC utilise un contrat intelligent 
 appelé Deposit qui interagit avec un ensemble de signataires qui détiennent les bitcoins en garantie. 
-Le contrat Deposit utilise BTCRelay pour vérifier les preuves SPV des transactions Bitcoin et émettre ou 
+Le contrat Deposit utilise BTCRelay pour vérifier les preuves SPV des transactions \gls{Bitcoin} et émettre ou 
-brûler des tokens tBTC en conséquence. Ainsi, les utilisateurs peuvent profiter des avantages de la liquidité 
+brûler des \gls{actif} tBTC en conséquence. Ainsi, les utilisateurs peuvent profiter des avantages de la liquidité 
-et de la programmabilité d’Ethereum tout en conservant l’exposition au bitcoin. \\
+et de la programmabilité d’\gls{Ethereum} tout en conservant l’exposition au \gls{Bitcoin}. \\
-Bien que tBTC se présente comme une solution décentralisée et sans confiance pour échanger des bitcoins contre 
+Bien que tBTC se présente comme une solution décentralisée et sans confiance pour échanger des \gls{Bitcoin}s contre 
 des tokens ERC-20, il existe certains défis et limites à son fonctionnement. 
-Par exemple, tBTC repose sur un ensemble de signataires qui doivent déposer une garantie pour sécuriser les bitcoins
+Par exemple, tBTC repose sur un ensemble de signataires qui doivent déposer une garantie pour sécuriser les \gls{Bitcoin}s
 verrouillés dans le contrat Deposit. Ceci expose les signataires à un risque financier permettant de limitter les risques de malveillance. 
 De plus, tBTC nécessite que les signataires soient en ligne et disponibles pour répondre aux demandes de rachat des 
 utilisateurs dans un délai donné. Si les signataires sont hors ligne ou malhonnêtes, les utilisateurs peuvent 
-perdre l’accès à leurs bitcoins ou être obligés d’attendre une longue période avant de pouvoir les récupérer. 
+perdre l’accès à leurs \gls{Bitcoin}s ou être obligés d’attendre une longue période avant de pouvoir les récupérer. 
 Les signataires sont choisis aléatoirement par un mécanisme appelé \textit{random beacon}, qui pondère la sélection en 
 fonction du montant misé par les signataires potentiels. Cela vise à éviter la collusion ou la censure entre les 
 signataires, mais cela n’exclut pas complètement la possibilité d’attaques sybil \footnote{Une attaque sybil est 

docs/rapportFinal/decentralisation/sidechain.tex

@@ -1,12 +1,12 @@
 %auteur: Amaury JOLY
 \subsubsection{Définition}
-Les sidechains sont des \textit{\gls{blockchain}s} secondaires qui fonctionnent en parallèle d'une \textit{\gls{blockchain}} principale \cite{jensen2021introduction,qin2018overview,belchior2022survey}. Elles possèdent leurs propres 
+Les \gls{sidechain}s sont des \textit{\gls{blockchain}s} secondaires qui fonctionnent en parallèle d'une \textit{\gls{blockchain}} principale \cite{jensen2021introduction,qin2018overview,belchior2022survey}. Elles possèdent leurs propres 
 caractéristiques, mais bénéficient de la communauté et de la sécurité inhérente au réseau principal pour les transactions finales qui seront inscrites sur 
 la \textit{\gls{blockchain}} principale. Les sidechains permettent de réaliser des opérations en marge de la chaîne principale, apportant ainsi plus de scalabilité 
-et de fonctionnalités. Par exemple, certaines sidechains sont compatibles avec l'Ethereum Virtual Machine (EVM) et peuvent donc porter des applications Ethereum.
+et de fonctionnalités. Par exemple, certaines \gls{sidechain}s sont compatibles avec l'\gls{Ethereum} Virtual Machine (EVM) et peuvent donc porter des applications \gls{Ethereum}.
 
 \subsubsection{Zendoo}
-Zendoo est une plateforme de création de sidechains interopérables avec la \textit{\gls{blockchain}} Horizen \cite{garoffolo2020zendoo,belchior2022survey}. Elle utilise un protocole 
+Zendoo est une plateforme de création de \gls{sidechain}s interopérables avec la \textit{\gls{blockchain}} Horizen \cite{garoffolo2020zendoo,belchior2022survey}. Elle utilise un protocole 
 de transfert cross-chain vérifiable par zk-SNARK \footnote{zk-SNARK est un acronyme qui signifie « Zero-Knowledge Succinct Non-Interactive Argument of Knowledge ». 
 Il s'agit d'une preuve cryptographique qui permet à une partie, le prouveur, de prouver à une autre partie, le vérificateur, qu'une affirmation sur des informations 
 détenues secrètement est vraie sans révéler les informations elles-mêmes.}, qui permet de garantir la sécurité et la décentralisation des communications entre 
@@ -18,9 +18,9 @@ De ce fait, Zendoo facilite l'échange de jetons entre différentes chaînes de
 Les utilisateurs peuvent ainsi bénéficier d'une plus grande liquidité et d'une meilleure efficacité dans leurs transactions cross-chain.
 
 \subsubsection{Contrainte technique des sidechains}
-La mise en place de sidechains implique une contrainte technique majeure : la création d'un pont bidirectionnel (\textit{two-way bridge}) entre la chaîne 
+La mise en place de \gls{sidechain}s implique une contrainte technique majeure : la création d'un pont bidirectionnel (\textit{two-way bridge}) entre la chaîne 
-principale et la sidechain. Ce pont permet de transférer des \gls{actif}s entre les deux chaînes, en respectant un taux de change prédéfini et en garantissant la 
+principale et la \gls{sidechain}. Ce pont permet de transférer des \gls{actif}s entre les deux chaînes, en respectant un taux de change prédéfini et en garantissant la 
 conservation du nombre total d'\gls{actif}s. Cependant, ce pont nécessite une coordination entre les deux chaînes, ce qui peut poser des problèmes de sécurité, de 
-performance ou de compatibilité. Par exemple, il est difficile d'utiliser des sidechains avec des \textit{\gls{blockchain}s} comme Ethereum ou Bitcoin, car elles n'ont 
+performance ou de compatibilité. Par exemple, il est difficile d'utiliser des \gls{sidechain}s avec des \textit{\gls{blockchain}s} comme \gls{Ethereum} ou \gls{Bitcoin}, car elles n'ont 
-pas le même algorithme de consensus, le même modèle comptable ou la même structure de données que les sidechains. Il faudrait donc adapter ces \textit{\gls{blockchain}s} 
+pas le même algorithme de consensus, le même modèle comptable ou la même structure de données que les \gls{sidechain}s. Il faudrait donc adapter ces \textit{\gls{blockchain}s} 
-pour qu'elles puissent communiquer avec les sidechains, ce qui impliquerait des modifications importantes dans leur protocole.
+pour qu'elles puissent communiquer avec les \gls{sidechain}s, ce qui impliquerait des modifications importantes dans leur protocole.

docs/rapportFinal/glossaire/glossaire.tex

@@ -27,11 +27,91 @@
 }
 
 \newglossaryentry{fonction de hachage cryptographique}{
-    name = fonction de hachage cryptographique, 
+    name = fonction de hachage cryptographique,
-    description = {Une fonction de hachage cryptographique est une primitive cryptographique qui transforme un message de taille arbitraire en un 
+    description = {Une fonction de hachage cryptographique est une primitive cryptographique qui transforme un message de taille arbitraire en un
-    message de taille fixe, appelé un haché. Une fonction de hachage cryptographique robuste doit être rapide à calculer et difficile à inverser, il doit être 
+            message de taille fixe, appelé un haché. Une fonction de hachage cryptographique robuste doit être rapide à calculer et difficile à inverser, il doit être
-    facile pour une fonction de hachage f de calculer une image f(x) à partir de x mais il doit être difficile de calculer une pré-image f\^-1(y) 
+            facile pour une fonction de hachage f de calculer une image $f(x)$ à partir de $x$ mais il doit être difficile de calculer une pré-image $f^{-1}(y)$
-    à partir de y. Cette fonction doit aussi être déterministe et résistante aux collisions, deux messages différents ne doivent pas produire le même haché.}
+            à partir de $y$. Cette fonction doit aussi être déterministe et résistante aux collisions, deux messages différents ne doivent pas produire le même haché.}
 }
 
+\newglossaryentry{off chain}{
+    name = off chain,
+    description= {On déclare qu'une blockchain est \textit{off chain} lorsqu'elle est une surcouche de la blockchain principale (on parle de blockchain de niveau supérieur).
+            La blockchain fille n'est pas vouée à être fusionner avec la blockchain mère mais juste à stocker temporairement les transactions avant de les envoyer sur la blockchain principale.}
+}
+
+\newglossaryentry{Nomad}{
+    name = Nomad,
+    description= {Nomad est un protocole de communication inter-chaines qui permet aux utilisateurs de transférer des actifs numériques en toute sécurité entre différentes blockchains.}
+}
+
+\newglossaryentry{Wormhole}{
+    name = Wormhole,
+    description= {Wormhole est un protocole de communication inter-chaines basé sur les bridges et utilisant de la vérification par un réseau de guardien.}
+}
+
+\newglossaryentry{Ethereum}{
+    name = Ethereum,
+    description= {Ethereum est un protocole d’échanges décentralisés permettant la création par les utilisateurs de contrats intelligents. Il fourni des transactions beaucoup plus rapide que Bitcoin ce qui lui donne un intérêt particulier pour la finance décentralisée.}
+}
+\newglossaryentry{Solana}{
+    name = Solana,
+    description = {Solana est une blockchain avec des fonctionnalités de contrats intelligents qui vise à augmenter le débit au-delà de ce qui est couramment réalisé par les blockchains populaires tout en maintenant des coûts bas.}
+}
+\newglossaryentry{Bitcoin}{
+    name = Bitcoin,
+    description= {Le Bitcoin est considéré comme la première preuve de concept de la blockchain. 
+    C'est un système décentralisé de paiement et d’échange de valeur basé sur cette technologie. }
+}
+
+\newglossaryentry{atomic swap}{
+    name = échange atomique,
+    description= {Les atomic swaps (échanges atomiques) sont des transactions entre deux parties qui permettent l’échange sur deux blockchains différentes sans avoir besoin d’un tiers de confiance. 
+    Ils sont considérés comme une méthode sûre et rapide pour échanger des cryptomonnaies. }
+}
+
+\newglossaryentry{validateur}{
+    name = vérificateur,
+    description= {Un vérificateur est une entité connectée en tant que noeud au réseau de la \textit{blockchain}. Ce dernier agit comme autorité de confiance, vérifiant et validant les transactions sur cette dernière.  }
+}
+
+\newglossaryentry{bridge}{
+    name = bridge,
+    description= { Un \textit{blockchain bridge} également appelé \textit{cross-chain bridge} est un protocole reliant deux \textit{blockchains} entre elles de manière unilatérale ou bilatérale dans une optique d’interopérabilité. }
+}
+
+\newglossaryentry{noeud}{
+    name = noeud,
+    description= {Un noeud d'une \textit{blockchain} est un ordinateur connecté au réseau de cette dernière.  }
+}
+
+
+\newglossaryentry{client}{
+    name = client,
+    description= { Un \textit{client} est un logiciel permettant de transformer un ordinateur en noeud.}
+}
+
+\newglossaryentry{noeud léger}{
+    name = noeud léger,
+    description= {Un noeud léger est un logiciel permettant de connecter les noeuds des \textit{blockchains} entre elles. }
+}
+
+\newglossaryentry{sidechain}{
+    name = sidechain,
+    description= {Une sidechain est une blockchain secondaire qui fonctionne en parallèle d'une blockchain principale.
+    Elles permettent de réaliser des opérations en marge de la chaîne principale, apportant ainsi plus de scalabilité et de fonctionnalités. }
+}
+
+\newglossaryentry{relay}{
+    name = relay,
+    description= {Les relays sont des applications décentralisées qui permettent la transmission d'informations de manière unilatéral entre deux blockchains distinctes }
+}
+
+\newacronym{htlc}{HTLC}{Hashed Time Locked Contract}
+\newacronym{cex}{CEX}{Centralized EXchange}
+\newacronym{dex}{DEX}{Decentralized EXchange}
+\newacronym{iou}{IOU}{I Owe You}
+\newacronym{vaa}{VAA}{Verified Action Approval}
+
+
 \printglossaries