mirror of
https://etulab.univ-amu.fr/v18003685/pfe-blockchain.git
synced 2024-02-26 02:14:01 +01:00
Presentation cenralisé
This commit is contained in:
TESTUD Romain
committed by
JOLY Amaury
JOLY Amaury
parent
d83bedc02c
commit
0806ca4bef
132
docs/presentation_17_03_23/centralisation/attaques.tex
Normal file
132
docs/presentation_17_03_23/centralisation/attaques.tex
Normal file
@ -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}
|
||||
86
docs/presentation_17_03_23/centralisation/bridges.tex
Normal file
86
docs/presentation_17_03_23/centralisation/bridges.tex
Normal file
@ -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}
|
||||
@ -1,3 +0,0 @@
|
||||
\begin{frame}
|
||||
\frametitle{Failles}
|
||||
\end{frame}
|
||||
@ -1,5 +1,14 @@
|
||||
\subsection{Systèmes Existants}
|
||||
\input{centralisation/sys_existants.tex}
|
||||
\subsection{Introduction}
|
||||
\input{centralisation/introduction.tex}
|
||||
|
||||
\subsection{Exemples de Failles}
|
||||
\input{centralisation/failles.tex}
|
||||
\subsection{Les plate-formes d'échanges centralisés}
|
||||
\input{centralisation/plateformes.tex}
|
||||
|
||||
\subsection{Les bridges}
|
||||
\input{centralisation/bridges.tex}
|
||||
|
||||
\subsection{Wormhole}
|
||||
\input{centralisation/wormhole.tex}
|
||||
|
||||
\subsection{Les attaques}
|
||||
\input{centralisation/attaques.tex}
|
||||
17
docs/presentation_17_03_23/centralisation/introduction.tex
Normal file
17
docs/presentation_17_03_23/centralisation/introduction.tex
Normal file
@ -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}
|
||||
51
docs/presentation_17_03_23/centralisation/plateformes.tex
Normal file
51
docs/presentation_17_03_23/centralisation/plateformes.tex
Normal file
@ -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}
|
||||
@ -1,3 +0,0 @@
|
||||
\begin{frame}
|
||||
\frametitle{Systèmes existants}
|
||||
\end{frame}
|
||||
107
docs/presentation_17_03_23/centralisation/wormhole.tex
Normal file
107
docs/presentation_17_03_23/centralisation/wormhole.tex
Normal file
@ -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}
|
||||
Reference in New Issue
Block a user