Merge branch 'presentation_bridges' into 'develop'

Presentation bridges

See merge request v18003685/pfe-blockchain!34

docs/presentation_17_03_23/centralisation/bridges.tex

@@ -3,12 +3,10 @@
  Echange de données / d'actifs \newline \newline
  Plusieurs types de bridges :
  \begin{itemize}
-     \item Uni-directionnel
-     \item Bi-directionnel 
      \item Trusted
      \item Trustless
  \end{itemize} 
- Différentes manières de déplacer les actifs:
+ Différentes manières d'échanger les actifs:
  \begin{itemize}
      \item Lock and Mint
      \item Burnt and Mint
@@ -26,7 +24,7 @@ Des informations clés:
         \item Possible remboursement en cas de cyberattaque.
         \item Cible facile.
     \end{itemize}
-    $\Rightarrow$ MAIS l'utilisateur donne le contrôle de ses actifs 
+    $\Rightarrow$ MAIS l'utilisateur donne le contrôle de ses actifs.\\ 
 Exemple de Trusted Bridge : Binance Bridge.
 \end{frame}
 
@@ -42,45 +40,80 @@ Des informations clés:
 Exemple de trustless bridge : Polygon Bridge.
 \end{frame}
 
-\begin{frame}{Le trilemme de l’interopérabilité}
-Repose sur 3 notions: 
-\begin{itemize}
-    \item Trustless
-    \item Extensible
-    \item Generalizable
-\end{itemize}
-Protocoles intéropérables actuels respectent deux notions sur trois.
-\end{frame}
-
-\begin{frame}{Mécanisme de vérification des Trustless Bridges}
+\begin{frame}{Mécanisme de vérification}
 Les mécanismes de vérification des bridges peuvent être classés en trois types:
 \begin{itemize}
     \item Locale (ex: Hop/Connext legacy)
     \item Extérieure (ex: Avalanche Bridge)
     \item Native (ex: The NEAR Rainbow Bridge)
 \end{itemize}
-Respecte les notions extensible et generalizable : vérification extérieure et native. \newline
-Respecte les notions trustless et extensible : vérification locale.  
 \end{frame}
 
+
+\begin{frame}{Vérification Externe}
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.5]{img/DiagrammeVerifExterne.png}
+    \end{figure}
+\end{frame}
+
+\begin{frame}{Vérification Native}
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.5]{img/DiagrammeVerifNative.png}
+    \end{figure}
+\end{frame}
+
+\begin{frame}{Vérification Locale}
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.5]{img/DiagrammeVerifLocale.png}
+    \end{figure}
+\end{frame}
+
+\begin{frame}{Le trilemme de l’interopérabilité}
+    Repose sur 3 notions: 
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.7]{img/3notions.png}
+    \end{figure}
+    \end{frame}
+
 \begin{frame}{Solution optimiste}
 Bridge optimiste avec de l'importance sur la sécurité plutôt que sur la vivacité.
 Déroulement : \newline
 \begin{itemize}
     \item Envoie de données vers une fonction contrat.
-    \item Signature la racine d'un arbre de Merkle par un updater et envoie sur la chaîne d'origine. 
-    \item Envoie sur une chaîne destination. 
+    \item Validation de la transaction par un vérificateur. 
+    \item Ajout d'un collatéral de la part du vérificateur. 
+    \item Envoie sur une chaîne destination par un \textit{relayer}. 
     \item 30 minutes de latence pour prouver une fraude.
     \item Les données sont passées à la chaîne destination puis traitées.
 \end{itemize}
-    
 \end{frame}
 
 \begin{frame}{Possibles faiblesses et leurs solutions}
 \begin{itemize}
-    \item Updater DoS $\Rightarrow$ multiple updaters/fileover/slashing
-    \item Updater Fraud $\Rightarrow$ slashing 
-    \item Watcher DoS $\Rightarrow$ tax de submission/slashing
-    \item Chain Liveness Failures $\Rightarrow$ long temps d'attente/ralentissement
+    \item \textit{Updater DoS}
+        \begin{itemize}
+            \item Mécanisme de substitution.
+            \item Perte du collatéral.
+        \end{itemize}
+    \item \textit{Updater Fraud} \begin{itemize} \item Perte du collatéral. \end{itemize}
+    \item \textit{Watcher DoS} 
+        \begin{itemize}
+            \item Signalement de fraude payant.
+            \item Perte du collatéral.
+            \item Vérificateurs approuvés.
+        \end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Les faiblesses des bridges}
+\begin{itemize}
+    \item \textit{Trustless Bridges} : Les \textit{smart contracts} et l'erreur humaine.
+    \item \textit{Trusted Bridges} : Les fraudes \textit{rug pull}.
+    \item Une technologie récente.
+    \item L'\textit{open source}.
 \end{itemize}
 \end{frame}

docs/rapportFinal/centralisation/bridge.tex

@@ -10,13 +10,13 @@ Il existe trois différentes manières de déplacer les actifs en tant que \text
 
 \subsubsection{Mécanisme de vérification}
 
-Comme évoqué précédemment, deux \textit{blockchains} ne peuvent pas communiquer directement entre elles, par conséquent lors de l’utilisation d’un \textit{bridge} les deux chaînes ne se connaissent pas et ont seulement connaissance des évènements se produisant sur leur chaîne respectives. Il est donc nécessaire d’établir une relation de confiance entre les deux chaînes pour qu’elles puissent accepter de communiquer. Pour cela, les \textit{bridges} emploient un mécanisme de vérification utilisant des \textit{verifiers} (vérificateurs). \\
+Comme évoqué précédemment, deux \textit{blockchains} ne peuvent pas communiquer directement entre elles, par conséquent lors de l’utilisation d’un \textit{bridge} les deux chaînes ne se connaissent pas et ont seulement connaissance des évènements se produisant sur leur chaîne respectives. Il est donc nécessaire d’établir une relation de confiance entre les deux chaînes pour qu’elles puissent accepter de communiquer. Pour cela, les \textit{bridges} emploient un mécanisme utilisant des vérificateurs. Un vérificateur est une autorité de confiance qui vérifie et valide les transactions sur une \textit{blockchain}. \\
 
 
 Il existe un grand nombre de \textit{bridges}, chacun avec leurs propres spécificités mais ils peuvent généralement être séparés en deux catégories les \textit{Trusted Blockchain Bridge} et les \textit{Trustless Blockchain Bridge}. \\
 
 
-Les \textit{Trusted Bridges} sont vérifiés de manière externe car ils utilisent un ensemble de vérificateur tiers pour transmettre des données entre les chaînes. Ils ont pour avantage leur rapidité, leur moindre coût et la facilité d'échange avec tous les types de données acceptés par les \textit{blockchains}. Cependant cela est au détriment de la sécurité puisqu'elle dépend ici des vérificateurs du \textit{bridge} en perdant la meilleure sécurisation des vérificateurs de la chaîne.\cite{EthereumBridges}
+Les \textit{Trusted Bridges} sont vérifiés de manière externe car ils utilisent un ensemble de vérificateurs tiers pour transmettre des données entre les chaînes. Ils ont pour avantage leur rapidité, leur moindre coût et la facilité d'échange avec tous les types de données acceptés par les \textit{blockchains}. Cependant cela est au détriment de la sécurité puisqu'elle dépend ici des vérificateurs du \textit{bridge} en perdant la meilleure sécurisation des vérificateurs de la chaîne.\cite{EthereumBridges}
 
 Les \textit{Trustless Bridges} sont désignés comme \textit{trustless} car ils dépendent des chaînes dont ils font l’intermédiaire pour transférer des données ou des actifs. Par conséquent leur niveau de sécurité est égal à celui des \textit{blockchains} et il n’est pas nécessaire de faire confiance à un ensemble de vérificateurs tiers (contrairement aux autres \textit{bridges}). Pour cette raison, ils sont reconnus comme étant plus fiables que les \textit{trusted bridges}.\cite{EthereumBridges}\\
 
@@ -74,7 +74,7 @@ Pour minimiser ce type de risques, il est recommandé d’effectuer des audits s
 
 Une faiblesse spécifique des \textit{bridges trusted} repose sur le fait que les utilisateurs doivent léguer le contrôle de leurs actifs et faire confiance aux vérificateurs externes aux blockchains. Sauf que dans certains cas, ces derniers peuvent coopérer pour tromper les utilisateurs en récupérant leurs actifs puis en disparaissant comme dans les \textit{rug pull}\cite{EthereumRisks}. Ce modèle d’escroquerie peut être scindé en deux catégorie : les \textit{hard rug pull} et les \textit{soft rug pull}\cite{Hacken}. Le premier cas est basé sur un piège présent dans le code d’un \textit{smart contract} empêchant les utilisateurs d’utiliser ou revendre les actifs frappés, seul le fraudeur en a le droit. Il peut donc en toute tranquillité revendre les actifs et récupérer l’argent. En revanche, pour les \textit{soft rug pull}, les utilisateurs ne sont pas coincés avec des actifs verrouillés mais les fraudeurs utilisent des techniques psychologiques. En effet, les escrocs rendent attirant leur projet pour que les clients investissent et hésitent à se retirer par peur de perte leur investissent (souvent de taille conséquent) puis les créateurs de la fraude disparaissent avec leurs actifs.\\
 
-Comme vu dans la section présentant les différentes méthodes d’échange des \textit{bridges}, ces derniers frappent les actifs 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’actifs en utilisant une faille d’un \textit{bridge} sans verrouiller ou brûler d’actifs sur sa \textit{blockchain}. Suite à cela, l’individu réintroduit ces actifs sur le marché ce qui fait violemment baiser leur coût ce qui peut engendrer un risque financier systémique.\\
+Comme vu dans la section présentant les différentes méthodes d’échange des \textit{bridges}, ces derniers frappent les actifs 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’actifs en utilisant une faille d’un \textit{bridge} sans verrouiller ou brûler d’actifs sur sa \textit{blockchain}. Suite à cela, l’individu réintroduit ces actifs sur le marché ce qui fait violemment baisser leur coût ce qui engendre un risque financier systémique.\\
 
 Les \textit{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 blockchains 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 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. \\