mirror of
https://etulab.univ-amu.fr/v18003685/pfe-blockchain.git
synced 2024-02-26 02:14:01 +01:00
Présentation finale
This commit is contained in:
VOLPE Dorian
committed by
TESTUD Romain
TESTUD Romain
parent
6faa176e69
commit
3a7a65cb75
@ -1,112 +1,148 @@
|
||||
% Auteur : Romain TESTUD
|
||||
\begin{frame}{Les attaques}
|
||||
\begin{itemize}
|
||||
\item De nombreux cas d'attaque sur des CEX\footnotemark.
|
||||
\item De nombreux cas d'attaque sur des CEX.
|
||||
\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}{Wormhole}
|
||||
\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}
|
||||
\includegraphics[scale = 0.45]{centralisation/img_attaques/rekt.png}
|
||||
\label{fig:rekt}
|
||||
\caption{Classement des attaques par Rekt.news}
|
||||
\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{frame}{Les attaques}
|
||||
\begin{block}{Différentes cibles d'attaques}
|
||||
\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.
|
||||
\item Plate-formes.
|
||||
\item Bridges.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\pause
|
||||
\begin{block}{Vérification}
|
||||
\begin{block}{Surface d'attaque}
|
||||
\begin{itemize}
|
||||
\item $acceptableRoot$ : vérification de la validité de la racine du contrat.
|
||||
\item Ingénierie sociale.
|
||||
\item Erreurs d'implémentations.
|
||||
\item Fonctions dépréciées.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Nomad}
|
||||
\begin{block}{Défaut d'implémentation}
|
||||
\begin{frame}{Des raisons }%(???)
|
||||
\begin{block}{Marché évolutif}
|
||||
\begin{itemize}
|
||||
\item La racine $0x00$ est valide.
|
||||
\item La racine par défaut des messages est $0x0$
|
||||
\item Evolution rapide.
|
||||
\item De nombreuses innovations.
|
||||
\item Manque de sensibilisation.
|
||||
\end{itemize}
|
||||
$\Rightarrow$ Un message avec une racine nulle est donc par défaut valide.
|
||||
\end{block}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Des Solutions ?}
|
||||
\begin{block}{Contre-mesures}
|
||||
\begin{itemize}
|
||||
\item Établir des standards.
|
||||
\item Réaliser des audits.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\pause
|
||||
\begin{block}{Vers le décentralisé}
|
||||
Suppression du tiers de confiance.
|
||||
\end{block}
|
||||
\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}
|
||||
%\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}{Wormhole}
|
||||
% \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}
|
||||
%
|
||||
|
||||
|
||||
BIN
docs/presentation_17_03_23/centralisation/img_attaques/rekt.png
Normal file
BIN
docs/presentation_17_03_23/centralisation/img_attaques/rekt.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
@ -11,4 +11,7 @@
|
||||
\input{centralisation/wormhole.tex}
|
||||
|
||||
\subsection{Les attaques}
|
||||
\input{centralisation/attaques.tex}
|
||||
\input{centralisation/attaques.tex}
|
||||
|
||||
\subsection{Les limites du centralisé}
|
||||
\input{centralisation/limites.tex}
|
||||
16
docs/presentation_17_03_23/centralisation/limites.tex
Normal file
16
docs/presentation_17_03_23/centralisation/limites.tex
Normal file
@ -0,0 +1,16 @@
|
||||
% Auteur : Romain TESTUD
|
||||
\begin{frame}{Les limites du centralisé}
|
||||
\begin{itemize}
|
||||
\item Manque de transparence.
|
||||
\item Manque de maturité en matière de sécurité.
|
||||
\item Questionnement sur le tiers de confiance
|
||||
\end{itemize}
|
||||
\pause
|
||||
\begin{block}{Le tiers de confiance}
|
||||
\begin{itemize}
|
||||
\item Source d'attaques.
|
||||
\item Point critique des CEX.
|
||||
\end{itemize}
|
||||
$\rightarrow$ Volonté de se passer d'un tiers de confiance.
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@ -1,12 +1,21 @@
|
||||
% 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{frame}{Les plate-formes d'échanges centralisés}
|
||||
\begin{block}{La solution la plus répandue}
|
||||
\begin{itemize}
|
||||
\item Possibilité d'échanges inter-blockchains par l'utilisation de bridges.
|
||||
\item Présence d'un intermédiaire entre les utilisateurs.
|
||||
\item Achat / Vente / Échange de crypto-actifs.
|
||||
\item Intermédiaire entre les utilisateurs.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\pause
|
||||
\pause
|
||||
\begin{block}{Interopérabilité ?}
|
||||
\begin{itemize}
|
||||
\item Utilisation de bridges inter-blockchains.
|
||||
\item Possibilité d'échanges entre tokens.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Fonctionnement}
|
||||
\begin{block}{Méthode de l'Order Book}
|
||||
\begin{itemize}
|
||||
\item Dépôt des fonds dans un porte monnaie de la plate-forme.
|
||||
@ -14,38 +23,42 @@
|
||||
\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
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[scale = 0.45]{centralisation/img_plateformes/achat-vente.png}
|
||||
\label{fig:Order}
|
||||
\caption{Modélisation d'un Achat-Vente}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Avantages et inconvénients}
|
||||
\begin{block}{Avantages}
|
||||
\begin{itemize}
|
||||
\item Facile d'utilisation
|
||||
\item Fiable
|
||||
\item Diverses fonctionnalités.
|
||||
\item Utilisation simplifiée.
|
||||
\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}
|
||||
\pause
|
||||
\begin{block}{Inconvénients}
|
||||
\begin{itemize}
|
||||
\item Sécurité et fiabilité relative au tiers.
|
||||
\item Gestion des données utilisateurs par le tiers.
|
||||
\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}
|
||||
%\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}
|
||||
@ -1,79 +1,82 @@
|
||||
% Auteur : Louis de Campou
|
||||
\begin{frame}{Wormhole}
|
||||
Protocole de passage de messages qui connecte 22 blockchains dont Ethereum et Solana.
|
||||
\newline
|
||||
|
||||
\begin{itemize}
|
||||
\item Gardiens
|
||||
\item Verified Action Approval (VAA)
|
||||
\item Payloads
|
||||
\end{itemize}
|
||||
Version 1 : \textit{Bridge} entre Ethereum et Solana
|
||||
\newline
|
||||
\newline
|
||||
Version 2 : Protocole générique de passage de messages qui connecte 22 \textit{blockchains}.
|
||||
\newline
|
||||
|
||||
\begin{itemize}
|
||||
\item Gardiens
|
||||
\item VAA (\textit{verified action approval})
|
||||
\item \textit{Payloads}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}{Wormhole : Gardiens}
|
||||
|
||||
Un gardien est une autorité de confiance qui a comme rôle d'observer et de signer un message.\newline
|
||||
|
||||
\begin{block}{Caractéristiques du réseau de gardiens}
|
||||
\begin{itemize}
|
||||
\item Sans leader
|
||||
\item 19 gardiens à parts égales
|
||||
\item Preuve d'autorité (PoA)
|
||||
\item Multisignature (m/n)
|
||||
\item Le consensus est atteint lorsque 2/3 des gardiens ont signé le message
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
|
||||
Un gardien est une autorité de confiance qui a comme rôle de valider un message.\newline
|
||||
|
||||
\begin{block}{Caractéristiques du réseau de gardiens}
|
||||
\begin{itemize}
|
||||
\item Sans leader
|
||||
\item 19 gardiens à parts égales
|
||||
\item Preuve d'autorité (PoA)
|
||||
\item \textit{Multisignature} (M/N)
|
||||
\item Le consensus est atteint lorsque 2/3 des gardiens ont signé le message
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Wormhole : Verified Action Approval (VAA)}
|
||||
|
||||
Primitive de messagerie de base de Wormhole
|
||||
\newline
|
||||
|
||||
En-tête :
|
||||
\begin{itemize}
|
||||
\item Index de l'ensemble des gardiens
|
||||
\item Nombre de signatures stockées
|
||||
\item Collection des signatures ECSDA (secp256k1)
|
||||
\end{itemize}
|
||||
|
||||
Corps :
|
||||
\begin{itemize}
|
||||
\item L'ID de la chaîne Wormhole du contrat émetteur
|
||||
\item L'adresse du contrat émetteur
|
||||
\item Le payload
|
||||
\end{itemize}
|
||||
|
||||
\begin{frame}{Wormhole : VAA}
|
||||
|
||||
Primitive de messagerie de base de Wormhole
|
||||
\newline
|
||||
|
||||
En-tête :
|
||||
\begin{itemize}
|
||||
\item Index de l'ensemble des gardiens
|
||||
\item Nombre de signatures stockées
|
||||
\item Collection des signatures ECSDA (secp256k1)
|
||||
\end{itemize}
|
||||
|
||||
Corps :
|
||||
\begin{itemize}
|
||||
\item L'ID de la chaîne Wormhole du contrat émetteur
|
||||
\item L'adresse du contrat émetteur
|
||||
\item Le \textit{payload}
|
||||
\end{itemize}
|
||||
\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 dont :
|
||||
\begin{itemize}
|
||||
\item Transfer (déclenche la libération de jetons verrouillés)
|
||||
\item AssetMeta (atteste les méta-données de l'actif, obligatoire avant un premier transfert)
|
||||
\end{itemize}
|
||||
|
||||
\begin{frame}{Wormhole : \textit{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 dont :
|
||||
\begin{itemize}
|
||||
\item \textit{AssetMeta} : informe des méta-données de l'actif verrouillé, obligatoire avant un premier transfert
|
||||
\item \textit{Transfer} : déclenche la libération de jetons verrouillés
|
||||
\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
|
||||
\item Montant du transfert
|
||||
\item L'adresse sur la chaîne d'origine
|
||||
\item ID de la chaîne d'origine
|
||||
\item L'adresse sur la chaîne de destination
|
||||
\item ID de la chaîne de destination
|
||||
\end{itemize}
|
||||
|
||||
\begin{frame}{Wormhole : \textit{Payload} - \textit{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 les jetons sur la chaîne B.\newline
|
||||
|
||||
\begin{itemize}
|
||||
\item ID du \textit{payload}
|
||||
\item Montant du transfert
|
||||
\item L'adresse sur la chaîne d'origine
|
||||
\item ID de la chaîne d'origine
|
||||
\item L'adresse sur la chaîne de destination
|
||||
\item ID de la chaîne de destination
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}{Wormhole : Conclusion}
|
||||
|
||||
\begin{itemize}
|
||||
\item Le réseau de gardiens est l'élement le plus critique de l'écosystème mais aussi le plus opaque
|
||||
\item Wormhole se dit décentralisé mais ne l'est pas selon notre définition
|
||||
\end{itemize}
|
||||
|
||||
\begin{itemize}
|
||||
\item Le réseau de gardiens est l'élement le plus critique de l'écosystème mais aussi le plus opaque
|
||||
\item Wormhole justifie sa décentralisation par la présence de plusieurs parties dans le contrôle du réseau
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
54
docs/presentation_17_03_23/conclusion/index.tex
Normal file
54
docs/presentation_17_03_23/conclusion/index.tex
Normal file
@ -0,0 +1,54 @@
|
||||
\begin{frame}{Centralisé}
|
||||
\begin{block}{Le centralisé offre\dots}
|
||||
\begin{itemize}
|
||||
\item Diversité d'acteurs.
|
||||
\item Accessibilité.
|
||||
\item Multiples fonctionnalités.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\pause
|
||||
\begin{block}{Mais\dots}
|
||||
\begin{itemize}
|
||||
\item Opacité des protocoles.
|
||||
\item Failles de sécurité.
|
||||
\item Collecte des données.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}{Décantralisé}
|
||||
\begin{block}{Le décentralisé offre\dots\dots}
|
||||
\begin{itemize}
|
||||
\item Pas de tiers de confiance.
|
||||
\item Transparence.
|
||||
\item Fiabilité accrue.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\pause
|
||||
\begin{block}{Mais\dots}
|
||||
\begin{itemize}
|
||||
\item Difficiles d'accès.
|
||||
\item Intérêt économique faible.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Conclusion générale}
|
||||
\begin{itemize}
|
||||
\item Flou entre centralisé/décentralisé.
|
||||
\item Définition variable.
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\begin{figure}
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[scale = 0.2]{conclusion/tableau.png}
|
||||
\label{fig:recap}
|
||||
\caption{Tableau récapitulatif}
|
||||
\end{figure}
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
BIN
docs/presentation_17_03_23/conclusion/tableau.png
Normal file
BIN
docs/presentation_17_03_23/conclusion/tableau.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
BIN
docs/presentation_17_03_23/decentralisation/atomicSwap.png
Normal file
BIN
docs/presentation_17_03_23/decentralisation/atomicSwap.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 123 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
@ -1,158 +1,72 @@
|
||||
% auteur: Dorian VOLPE
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Hashed Timelock Contract (HTLC)}
|
||||
\begin{itemize}
|
||||
\item Ne nécessite pas de de tiers de confiance
|
||||
\item Réduit le risque de perte si l'on suit le protocole
|
||||
\item Verrouille les fonds dans un portefeuille qui peut être révoqué en cas de problème
|
||||
\end{itemize}
|
||||
\frametitle{\textit{Hashed Timelock Contract} (HTLC)}
|
||||
\begin{itemize}
|
||||
\item Ne nécessite pas de de tiers de confiance
|
||||
\item Se base sur deux primitives
|
||||
\begin{itemize}
|
||||
\item Un verrou temporel
|
||||
\item Un verrou de hachage
|
||||
\end{itemize}
|
||||
\item Verrouille les fonds dans un portefeuille qui peut être révoqué en cas de problème
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{HTLC fonctionnement - 1/2}
|
||||
\begin{itemize}
|
||||
\item Alice génère un hachage à partir de sa clé privée et l’envoie à Bob
|
||||
\item Elle génère également une pré-image du hachage en créant une transaction
|
||||
\item Bob génère également un hachage à partir de sa clé et l’envoie à Alice
|
||||
\item Une fois que Bob reçoit la transaction d’Alice, il signe la transaction en utilisant la clé originale qui est déjà disponible avec lui dans la pré-image
|
||||
\item Si Bob ne signe pas la transaction dans le temps imparti, la transaction est annulée et les fonds sont retournés à Alice
|
||||
\end{itemize}
|
||||
\frametitle{HTLC fonctionnement - 1/2}
|
||||
\begin{itemize}
|
||||
\item La modification du contrat peut être effectué uniquement avec l'accord des deux parties
|
||||
\item Renouvellement du timer à chaque modification
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{HTLC fonctionnement - 2/2}
|
||||
\begin{figure}
|
||||
\includegraphics[scale = 0.4]{decentralisation/aliceBob.jpg}
|
||||
\caption[short]{Zoom sur les HTLC}
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
\frametitle{HTLC fonctionnement - 2/2}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomic Swaps}
|
||||
Un swap atomique permet un échange de cryptomonnaies de blockchains séparées.
|
||||
\newline
|
||||
\begin{itemize}
|
||||
\item Effectué entre deux entités sans l’intervention d’un tiers.
|
||||
\item L’idée est de supprimer les intermédiaires centralisés comme les échanges réglementés et de donner aux propriétaires de jetons un contrôle total.
|
||||
\item Utilise les HTLC. \newline
|
||||
\end{itemize}
|
||||
Deux propriétaires de cryptoactifs acceptent d’échanger leurs jetons pour une quantité donnée
|
||||
$\Rightarrow$ notion de connecteur publique.
|
||||
\end{frame}
|
||||
\begin{figure}[h!]
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomic Swaps - Exemple}
|
||||
\begin{figure}
|
||||
\includegraphics[scale = 0.35]{decentralisation/atomicswap.png}
|
||||
\caption{Processus d'échange atomique avec HTLC}
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomic Swaps - Avantages}
|
||||
\subtitle{Avantages}
|
||||
\begin{itemize}
|
||||
\item Réduction des couts de transaction.
|
||||
\item Échange pair à pair sans tiers de confiance $\Rightarrow$ réellement décentralisé.
|
||||
\item Protection des échanges:
|
||||
\begin{itemize}
|
||||
\item Si un tiers suit le protocole il est assuré de ne pas perdre d'argent.
|
||||
\item Si jamais il ne suit pas le protocole il perd sa mise.
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Le réseau Lightning (Lightning Network)}
|
||||
\begin{itemize}
|
||||
\item Couche secondaire de la blockchain Bitcoin \newline
|
||||
\item Permet de faire des transactions en dehors de la blockchain principale $\Rightarrow$ off-chain
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Le réseau Lightning (Lightning Network) - Fonctionnement 1/2}
|
||||
Grâce à une transaction Bitcoin, deux noeuds du réseau peuvent construire un canal bidirectionnel sur lequel ils déposent une certaine quantité de bitcoins.
|
||||
\newline
|
||||
Les deux parties peuvent effectuer des transactions entre elles sans les diffuser sur le réseau Bitcoin.
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Le réseau Lightning (Lightning Network) - Fonctionnement 2/2}
|
||||
\centering
|
||||
\begin{figure}
|
||||
\includegraphics[scale = 0.24]{decentralisation/lightning.jpg}
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Le réseau Lightning (Lightning Network) - Avantages}
|
||||
\begin{itemize}
|
||||
\item Aucune limite sur le nombre de transactions par seconde sur le réseau.
|
||||
\newline
|
||||
\item Des transactions instantanées. Plus d’attente de confirmation par les mineurs.
|
||||
\newline
|
||||
\item Des frais de transaction extrêmement faibles ouvrant la voie aux micro-transactions.
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT}
|
||||
Implémentaion des swaps atomiques sur le réseau Lightning par le MIT. Les objectifs sont :
|
||||
\newline
|
||||
\begin{itemize}
|
||||
\item Permettre d'utiliser le réseau Lightning sur des blockchains différentes.
|
||||
\item Permettre des échanges sur des blockchains non monétaires \footnote{blockchains d'informations, de données,etc...}.
|
||||
\item Proposer une interface pour des échanges cross-chain.
|
||||
\end{itemize}
|
||||
\stackunder{
|
||||
\includegraphics[scale=0.35]{decentralisation/Timed-HashLocks-Diagram-Image.png}}
|
||||
{\scriptsize
|
||||
Source: \url{https://blog.scottlogic.com/2016/06/16/bitcoin-redeem-scripts.html}}
|
||||
\caption[short]{Utilisation d'un HTLC}
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT - Nouvelles commandes 1/3}
|
||||
\begin{block}{Price}
|
||||
Commande de canal simple qui permet aux utilisateurs de rechercher la valeur marchande actuelle en USD de toute crypto-monnaie.
|
||||
\end{block}
|
||||
\begin{block}{Compare}
|
||||
Récupère la valeur marchande actuelle de chaque devise souhaitée et effectue une
|
||||
simple opération arithmétique pour retourner la valeur comparée entre elles.
|
||||
\end{block}
|
||||
|
||||
\frametitle{Atomic Swaps}
|
||||
Un swap atomique permet un échange de cryptomonnaies de blockchains séparées
|
||||
\begin{itemize}
|
||||
\item Effectué entre deux entités sans l’intervention d’un tiers
|
||||
\item L’idée est de supprimer les intermédiaires centralisés comme les échanges réglementés et de donner aux propriétaires de jetons un contrôle total
|
||||
\item Utilise les HTLC. \newline
|
||||
\end{itemize}
|
||||
Deux propriétaires de cryptoactifs acceptent d’échanger leurs jetons pour une quantité donnée
|
||||
$\Rightarrow$ notion de connecteur publique.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT - Nouvelles commandes 2/3}
|
||||
\begin{block}{Exchange}
|
||||
Demande aux acteurs de la transaction d'alimenter un canal avec les montants souhaités. AVant de procéder à l'échange lui même.
|
||||
\end{block}
|
||||
\centering
|
||||
\includegraphics[scale = 0.6]{decentralisation/exchange.png}
|
||||
\frametitle{Atomic Swaps - Exemple}
|
||||
\begin{figure}
|
||||
\includegraphics[scale = 0.10]{decentralisation/atomicSwap.png}
|
||||
\caption{Processus d'échange atomique avec HTLC}
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT - Nouvelles commandes 3/3}
|
||||
\begin{block}{Respond}
|
||||
À ce stade de l'échange, Bob a une minute pour décider d'une action vis-à-vis de 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 en "time out".
|
||||
\end{block}
|
||||
$\Rightarrow$ On retrouve ici le principe des HTLC
|
||||
\frametitle{Atomic Swaps - Avantages}
|
||||
\subtitle{Avantages}
|
||||
\begin{itemize}
|
||||
\item Réduction des coûts de transaction
|
||||
\item Échange pair à pair sans tiers de confiance $\Rightarrow$ réellement décentralisé
|
||||
\item Protection des échanges:
|
||||
\begin{itemize}
|
||||
\item Si un tiers suit le protocole il est assuré de ne pas perdre d'argent
|
||||
\item Si jamais il ne suit pas le protocole il perd sa mise
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT - Limitations}
|
||||
|
||||
Il y a plusieurs limitation a cette Implémentaion:
|
||||
\newline
|
||||
\begin{itemize}
|
||||
\item Il n'y a pas de support de channel hopping \footnote{Transitivité des échanges entres plusieurs participants.} malgrès l'utilisation du réseau Lightning.
|
||||
\begin{itemize}
|
||||
\item Cela implique des problème de mise a l'échelle.
|
||||
\end{itemize}
|
||||
\item Il n'y a pas de vérification sur les valeurs inscrites sur les chaines non monétaires.
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
@ -4,3 +4,6 @@
|
||||
\input{decentralisation/sidechains.tex}
|
||||
\subsection[HLTC]{Hash Lock Time Contract}
|
||||
\input{decentralisation/htlc.tex}
|
||||
|
||||
\subsection[offChain]{Échanges \textit{off chain}}
|
||||
\input{decentralisation/offChain.tex}
|
||||
|
||||
93
docs/presentation_17_03_23/decentralisation/offChain.tex
Normal file
93
docs/presentation_17_03_23/decentralisation/offChain.tex
Normal file
@ -0,0 +1,93 @@
|
||||
\begin{frame}
|
||||
\frametitle{Les échanges \textit{off chain}}
|
||||
\begin{itemize}
|
||||
\item Ils s'effectuent en dehors de la blockchain principale $\Rightarrow$ \textit{layer 2}
|
||||
\item Permettent d'avoir un compromis avec la blockchain principale
|
||||
\item Les chaines ne sont pas voués à être fusionner avec la blockchain mère
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Les échanges \textit{off chain}: Visualisation}
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\stackunder{\includegraphics[scale=0.35]{decentralisation/offchain.png}}
|
||||
{\scriptsize Source: \url{www.cryptoencyclopedie.com}}
|
||||
\caption{Architecture \textit{off-chain}}
|
||||
\label{fig:offchain}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Exemple d'échange \textit{off chain}: Le réseau Lightning}
|
||||
\begin{itemize}
|
||||
\item Couche secondaire de la blockchain Bitcoin \newline
|
||||
\item Permet de faire des transactions en dehors de la blockchain principale $\Rightarrow$ off-chain \newline
|
||||
\item Échanges par canaux bidirectionnel
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Le réseau Lightning (Lightning Network) - Fonctionnement 2/2}
|
||||
\begin{figure}[h!]
|
||||
\stackunder{
|
||||
\includegraphics[scale = 0.3 ]{decentralisation/Procedures-of-Lightning-network.png} }
|
||||
{\scriptsize Source: \url{https://issam.ma/jekyll/update/2022/03/01/bitcoin-must-die-5.html}}
|
||||
|
||||
\caption{Le réseau Lightning par rapport a la \textit{blockchain} Bitcoin principale}
|
||||
|
||||
\end{figure}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Le réseau Lightning (Lightning Network) - Avantages}
|
||||
\begin{itemize}
|
||||
\item Aucune limite sur le nombre de transactions par seconde sur le réseau
|
||||
\newline
|
||||
\item Des transactions instantanées. Plus d’attente de confirmation par les mineurs
|
||||
\newline
|
||||
\item Des frais de transaction extrêmement faibles ouvrant la voie aux micro-transactions
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT}
|
||||
Implémentaion des swaps atomiques sur le réseau Lightning par le MIT. Les objectifs sont :
|
||||
\newline
|
||||
\begin{itemize}
|
||||
\item Permettre d'utiliser le réseau Lightning sur des blockchains différentes.
|
||||
\item Permettre des échanges sur des blockchains non monétaires \footnote{blockchains d'informations, de données,etc...}.
|
||||
\item Proposer une interface pour des échanges cross-chain.
|
||||
\end{itemize}
|
||||
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT - Nouvelles commandes}
|
||||
Dans le but de faciliter les échanges des commandes ont été crée:
|
||||
\newline
|
||||
\begin{itemize}
|
||||
\item \textit{Price}
|
||||
\item \textit{Compare}
|
||||
\item \textit{Exchange}
|
||||
\item \textit{Respond}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Implémentation du MIT - Limitations}
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item Il n'y a pas de support de channel hopping \footnote{Transitivité des échanges entres plusieurs participants.} malgré l'utilisation du réseau Lightning.
|
||||
\begin{itemize}
|
||||
\item Cela implique des problème de mise a l'échelle.
|
||||
\end{itemize}
|
||||
\item Il n'y a pas de vérification sur les valeurs inscrites sur les chaines non monétaires.
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
BIN
docs/presentation_17_03_23/decentralisation/offchain.png
Normal file
BIN
docs/presentation_17_03_23/decentralisation/offchain.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
@ -5,6 +5,7 @@
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[french]{babel}
|
||||
\usepackage{stackengine}
|
||||
|
||||
\addtobeamertemplate{navigation symbols}{}{%
|
||||
\usebeamerfont{footline}%
|
||||
@ -33,7 +34,7 @@
|
||||
\subtitle{Projet de fin d'études: Master 2 Informatique Option Fiabilité et sécurité informatique 2022-2023}
|
||||
\author[M2 FSI]{VOLPE Dorian, ROTONDO Eloïse, TESTUD Romain,\\DE CAMPOU Louis, JOLY Amaury \\ \textbf{Encadrants :} TRAVERS Corentin, LABOUREL Arnaud \\[2ex] \includegraphics[scale=0.1]{./img/amu.png}}
|
||||
\institute[Aix-Marseille Université]{M2 Fiabilité et sécurité informatique}
|
||||
\date{17 Mars 2023}
|
||||
\date{\today}
|
||||
|
||||
\begin{document}
|
||||
|
||||
@ -56,5 +57,7 @@
|
||||
\input{centralisation/index.tex}
|
||||
\section{Décentralisation}
|
||||
\input{decentralisation/index.tex}
|
||||
\section{Conclusion}
|
||||
\input{conclusion/index.tex}
|
||||
|
||||
\end{document}
|
||||
Reference in New Issue
Block a user