Merge branch 'presentation_cenralisé' into 'develop'

Presentation cenralisé

See merge request v18003685/pfe-blockchain!13

docs/presentation_17_03_23/centralisation/attaques.tex

@@ -0,0 +1,132 @@
+% Auteur : Romain TESTUD
+\begin{frame}{Les attaques}
+    \begin{itemize}
+        \item De nombreux cas d'attaque sur des CEX\footnotemark.
+        \item Des sommes importantes sont concernés.
+    \end{itemize}
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.45]{img/attaques.png}
+        \label{fig:my_label2}
+        %\caption{caption}
+    \end{figure}
+    \footnotetext{Centralised EXchange}
+\end{frame}
+
+\begin{frame}{Wormhole}
+    Attaque sur le bridge entre Solana et Ethereum :
+    \begin{itemize}
+        \item Quelques heures après un correctif non déployé.
+        \item Exploitation d'un défaut d'implémentation.
+        \item La transaction de l'attaquant est signée par les gardiens.
+        
+    \end{itemize}
+\end{frame}
+\begin{frame}{Wormhole}
+    \begin{block}{Fonctionnement du dépôt de jeton}
+        \begin{itemize}
+            \item Appel de plusieurs fonctions de vérification lors du dépôt.
+            \begin{itemize}
+                \item $complete\_wrapped$ $\Rightarrow$ 
+                 $transfer\_message$
+                 $\Rightarrow$  $post\_vaa$
+                 $\Rightarrow$  $verify\_signature$
+            \end{itemize}
+            %\item Fonction complete\_wrapped appellée lors du mint de Wormhole ETH sur Solana
+            %\item transfer\_message en paramètre : spécifie le token et combien doit être mint, signé par les gardiens
+            %\item Contrat sur Solana, créé en utilisant la fonction post\_vaa qui vérifie la signature des gardiens
+            %\item Appel a verify\_signature qui utilise un programme de Solana pour verifier les signatures
+        \end{itemize}
+        Erreur d'implémentation dans $verify\_signature$.
+    \end{block}
+\end{frame}
+
+\begin{frame}
+    \begin{block}{$verify\_signature$ appelle un programme de vérification}
+        \begin{itemize}
+            \item $Sysvar: Instructions$ : Alias du programme.
+            \item Vérification des signatures des gardiens.
+            \item Il est possible d'utiliser d'une adresse différente.
+        \end{itemize}  
+    \end{block}
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.3]{img/wormhole_img1.png}
+    \end{figure}
+\end{frame}
+
+\begin{frame}{Wormhole}
+    \begin{itemize}
+        \item Adresse tierce entrée par l'attaquant.
+        \item Validation de la transaction sans signature.
+    \end{itemize}
+        \begin{figure}
+        \centering
+        \includegraphics[scale = 0.7]{img/wormhole_img2.png}
+    \end{figure}
+\end{frame}
+
+
+
+\begin{frame}{Nomad}
+    \begin{itemize}
+        \item Protocole d'échange entre blockchains.
+        \item Utilisation de smart contracts.
+        \item Erreur d'implémentation dans le contrat Réplica.
+    \end{itemize}
+    $\Rightarrow$ Possibilité de passer la vérification des messages.
+\end{frame}
+
+\begin{frame}{Nomad}
+    \begin{block}{Fonctionnement de Nomad}
+        \begin{itemize}
+            \item Les messages ont des racines.
+            \item Vérification de la racine lors de l'émission du message.
+            \item Appel de la fonction process pour vérifier et envoyer le message.
+        \end{itemize}
+    \end{block}
+    \pause
+    \begin{block}{Vérification}
+        \begin{itemize}
+            \item $acceptableRoot$ : vérification de la validité de la racine du contrat.
+        \end{itemize}
+    \end{block}
+\end{frame}
+
+\begin{frame}{Nomad}
+    \begin{block}{Défaut d'implémentation}
+        \begin{itemize}
+            \item La racine $0x00$ est valide.
+            \item La racine par défaut des messages est $0x0$
+        \end{itemize}
+        $\Rightarrow$ Un message avec une racine nulle est donc par défaut valide.
+    \end{block}
+\end{frame}
+
+\begin{frame}{Nomad}
+    \begin{itemize}
+        \item $\_committedRoot$ innitialisé à $0x0$.
+        \item Contrat valide si sa racine est $0x0$
+    \end{itemize}
+    \begin{figure}
+        \centering
+        \includegraphics[scale = 0.3]{img/nomad_img1.png}
+        %\label{fig:my_label}
+        %\caption{figure}
+    \end{figure}
+\end{frame}
+
+\begin{frame}{Nomad}
+    \begin{itemize}
+        \item Création d'un message avec une racine nulle.
+        \item Appel à la fonction 
+    \end{itemize}
+\end{frame}
+
+\begin{frame}{Des solutions ?}
+    \begin{itemize}
+        \item Etablir des standards ?
+        \item Supprimer le tiers de confiance ?
+    \end{itemize}
+    $\Rightarrow$ Vers le décentralisé
+\end{frame}

docs/presentation_17_03_23/centralisation/bridges.tex

@@ -0,0 +1,86 @@
+\begin{frame}{Les types de bridges}
+ Protocoles de communication et d'échanges entre différentes blockchains.
+ 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:
+ \begin{itemize}
+     \item Lock and Mint
+     \item Burnt and Mint
+     \item Atomic Swaps
+ \end{itemize}
+\end{frame}
+
+\begin{frame}{Trusted Blockchain Bridge}
+    Basés sur une entité centrale en tant que tiers de confiance.
+Des informations clés: 
+    \begin{itemize}
+        \item Facilite les transferts.
+        \item Utilisation simple.
+        \item Échanges sécurisés.
+        \item Possible remboursement en cas de cyberattaque.
+        \item Cible facile.
+    \end{itemize}
+    $\Rightarrow$ MAIS l'utilisateur donne le contrôle de ses actifs 
+Exemple de Trusted Bridge : Binance Bridge.
+\end{frame}
+
+\begin{frame}{Trustless Blockchain Bridge}
+Basés sur un réseau décentralisé 
+Des informations clés: 
+\begin{itemize}
+    \item Aucune présence d'un tiers de confiance.
+    \item Sécurité du bridge égale à celle de la chaîne sous-jacente.
+    \item Permettent aux utilisateurs de contrôler leurs actifs.
+    \item Aucune garantie en cas de hack.
+\end{itemize}
+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}
+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}{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 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
+\end{itemize}
+\end{frame}

docs/presentation_17_03_23/centralisation/failles.tex

@@ -1,3 +0,0 @@
-\begin{frame}
-    \frametitle{Failles}
-\end{frame}

docs/presentation_17_03_23/centralisation/index.tex

@@ -1,5 +1,14 @@
-\subsection{Systèmes Existants}
+\subsection{Introduction}
-\input{centralisation/sys_existants.tex}
+\input{centralisation/introduction.tex}
 
-\subsection{Exemples de Failles}
+\subsection{Les plate-formes d'échanges centralisés}
-\input{centralisation/failles.tex}
+\input{centralisation/plateformes.tex}
+
+\subsection{Les bridges}
+\input{centralisation/bridges.tex}
+
+\subsection{Wormhole}
+\input{centralisation/wormhole.tex}
+
+\subsection{Les attaques}
+\input{centralisation/attaques.tex}

docs/presentation_17_03_23/centralisation/introduction.tex

@@ -0,0 +1,17 @@
+\begin{frame}{Introduction}
+\begin{block}{Réponse à un besoin}
+    \begin{itemize}
+    \item Bitcoin première cryptomonnaie avec 40,5\% du marché.
+    \item Ethereum en deuxième avec 19,5\%.
+    \item 40\% restants de cryptomonnaies avec leur propre chaîne.
+\end{itemize}
+\end{block}
+\pause
+\begin{block}{Nécessité de solutions d'échange inter-blockchains}
+    \begin{itemize}
+        \item Sécurisés
+        \item Fiables
+        \item Rapides
+    \end{itemize}
+\end{block}
+\end{frame}

docs/presentation_17_03_23/centralisation/plateformes.tex

@@ -0,0 +1,51 @@
+% Auteur : Romain TESTUD
+\begin{frame}{Plate-formes d'échanges Centralisés}
+    \begin{block}{Plate-formes privées d'échanges de données sur blockchain}
+        \begin{itemize}
+            \item Possibilité d'échanges inter-blockchains par l'utilisation de bridges.
+            \item Présence d'un intermédiaire entre les utilisateurs.
+        \end{itemize}
+    \end{block}
+\pause
+    \begin{block}{Méthode de l'Order Book}
+        \begin{itemize}
+            \item Dépôt des fonds dans un porte monnaie de la plate-forme. 
+            \item Émission d'IOU\footnotemark.
+            \item Échange des IOU contre les token demandés.
+        \end{itemize}
+    \end{block}
+    \footnotetext{IOU (I Owe You) : Reconnaissance de dette de la plate-forme envers l'utilisateur}
+    %L'utilisateur place un ordre d'achat, la plateforme trouve un vendeur, l'échange s'effectue
+\end{frame}
+
+\begin{frame}{Avantages et inconvénients}
+    \begin{block}{Avantages}
+        \begin{itemize}
+            \item Facile d'utilisation
+            \item Fiable
+        \end{itemize}
+    \end{block}
+\pause
+\begin{block}{Inconvénients}
+    \begin{itemize}
+        \item Sécurité de la plate-forme.
+        \item L'utilisateur cède la gestion de ses données.
+        \item Fonctionnement interne opaque.
+    \end{itemize}
+    $\Rightarrow$ Confiance utilisateur/plate-forme.
+\end{block}
+\end{frame}
+
+\begin{frame}{Fonctionnement opaque}
+    \begin{itemize}
+        \item Pas ou peu de documentation technique.
+        \item Code inaccessible.
+    \end{itemize}
+    \pause
+    \begin{block}{Ce que l'on sait}
+        \begin{itemize}
+            \item Fonctionnement en Order Book.
+            \item utilisation de bridges inter-blockchains.
+        \end{itemize}
+    \end{block}
+\end{frame}

docs/presentation_17_03_23/centralisation/sys_existants.tex

@@ -1,3 +0,0 @@
-\begin{frame}
-    \frametitle{Systèmes existants}
-\end{frame}

docs/presentation_17_03_23/centralisation/wormhole.tex

@@ -0,0 +1,107 @@
+% Auteur : Louis de Campou
+\begin{frame}{Wormhole}
+Protocole générique de passage de messages qui connecte 13 chaînes dont Ethereum et Solana.
+\newline
+
+Wormhole émet un message à partir d'une chaîne qui sont observés et vérifiés par un réseau de nœuds "Guardian". Après vérification, ce message est soumis à la chaîne cible pour traitement.
+\newline 
+
+\begin{itemize}
+    \item Verified Action Approval (VAA)
+    \item Gardiens
+    \item Payloads
+    \item Relayer
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Wormhole : Verified Action Approval (VAA)}
+
+Primitive de messagerie de base de Wormhole
+\newline
+
+En-tête :
+\begin{itemize}
+    \item Version VAA (version, byte)
+    \item Index de l'ensemble des gardiens (guardian\_set\_index, u32)
+    \item Nombre de signatures stockées (len\_signatures, u8)
+    \item Collection des signatures ECSDA/secp256k1 (signatures, [][66]byte)
+\end{itemize}
+
+Corps : 
+\begin{itemize}
+    \item Horadatage du bloc (timestamp, u32)
+    %\item Nombre pseudo-aléatoire (nonce, u32)
+    \item L'ID de la chaîne Wormhole du contrat émetteur (emitter\_chain, u16)
+    \item L'adresse du contrat émetteur (emitter\_address, [32]byte)
+    \item Le numéro de séquence lié à la chaîne et à l'adresse émetteur (sequence, u64)
+    %\item Le niveau de cohérence (consistency\_level, u8)
+    \item La charge utile, le contenu du message VAA (payload, []byte)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Wormhole : Gardiens}
+«Un ensemble de noeuds distribués qui surveillent l'état de plusieurs blockchains»
+\newline
+
+19 gardiens à parts égales définis comme «les sociétés de validation les plus importantes et les plus connues dans le domaine des crypto-monnaies».
+\newline
+
+«Décentralisation : le contrôle du réseau doit être réparti entre plusieurs parties»
+\end{frame}
+
+\begin{frame}{Wormhole : Gardiens}
+Rôle : observer des messages (format VAA) puis signer le corps du message contenant le payload.\newline
+
+La signature du gardien correspondant est ensuite ajouté dans l'en-tête du VAA avec incrémentation de len\_signatures\newline
+
+Chaque gardien travaille individuellement («isolation») puis mise en commun des signatures (=> multisig) qui forme une preuve qu'un état a été observé et validé par une majorité du réseau Wormhole.\newline
+
+Mécanisme de consensus : Proof of Authority (2/3 des signatures nécessaires pour parvenir au consensus)\newline
+
+1 charge utile par VAA => 13 signatures + 13 vérifications pour 1 charge utile
+\end{frame}
+
+\begin{frame}{Wormhole : Payloads}
+
+Charges utiles spécifiques attachées à un VAA depuis une chaîne source pour indiquer à la chaîne cible comment traiter le message Wormhole après vérification.\newline
+
+5 payloads au total :
+\begin{itemize}
+    \item Transfer (déclenche la libération de jetons verrouillés) 
+    \item TransferWithPayload
+    \item AssetMeta (atteste les méta-données de l'actif, obligatoire avant un premier transfert)
+    \item RegisterChain (enregistre le contrat bridge pour une chaîne étrangère)
+    \item UpgradeContract
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Wormhole : Payload - Transfer}
+
+Pour transférer des jetons des chaînes A à B, il y a verrouillage des jetons sur la chaîne A puis on frappe ("mint") sur la chaîne B.\newline
+
+\begin{itemize}
+    \item ID de la charge utile (payload\_id, u8)
+    \item Montant du transfert (amount, u256)
+    \item L'adresse sur la chaîne d'origine (token\_address, u8[32])
+    \item ID de la chaîne d'origine (token\_chain, u16)
+    \item L'adresse sur la chaîne de destination (to, u8[32])
+    \item ID de la chaîne de destination (to\_chain, u16)
+    \item Une taxe payée au relayer (fee, u256)
+\end{itemize} 
+\end{frame}
+
+\begin{frame}{Wormhole : Relayer}
+ «Un processus qui délivre un ou plusieurs VAA(s) à une destination»
+
+ \begin{itemize}
+    \item Sans confiance
+    \item Sans privilèges
+\end{itemize}
+
+\begin{enumerate}
+    \item Un VAA est émis depuis la chaîne source indiquant que tant de jetons ont été verrouillés
+    \item VAA transmis aux gardiens
+    \item Signature de 2/3 des gardiens
+    \item Transmission du VAA signé à la chaîne cible
+\end{enumerate}
+\end{frame}