mirror of
https://etulab.univ-amu.fr/v18003685/pfe-blockchain.git
synced 2024-02-26 02:14:01 +01:00
Merge branch 'presentation_decentralisé' into 'develop'
squelette presentation decentralisé See merge request v18003685/pfe-blockchain!12
This commit is contained in:
BIN
docs/presentation_17_03_23/decentralisation/aliceBob.jpg
Normal file
BIN
docs/presentation_17_03_23/decentralisation/aliceBob.jpg
Normal file
Binary file not shown.
After 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: 82 KiB |
BIN
docs/presentation_17_03_23/decentralisation/btcRelay.png
Normal file
BIN
docs/presentation_17_03_23/decentralisation/btcRelay.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 42 KiB |
BIN
docs/presentation_17_03_23/decentralisation/exchange.png
Normal file
BIN
docs/presentation_17_03_23/decentralisation/exchange.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 25 KiB |
158
docs/presentation_17_03_23/decentralisation/hltc.tex
Normal file
158
docs/presentation_17_03_23/decentralisation/hltc.tex
Normal file
@ -0,0 +1,158 @@
|
||||
% 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}
|
||||
\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}
|
||||
\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}
|
||||
|
||||
\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{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}
|
||||
|
||||
\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}
|
||||
|
||||
\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}
|
||||
|
||||
\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
|
||||
\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}
|
@ -1,2 +1,10 @@
|
||||
\subsection{Etat de l'art}
|
||||
\input{decentralisation/etat_art.tex}
|
||||
\subsection[Introduction]{Définition et contextualisation}
|
||||
\input{decentralisation/intro.tex}
|
||||
\subsection[Relay]{Relay}
|
||||
\input{decentralisation/relay.tex}
|
||||
\subsection[Sidechains]{Sidechains}
|
||||
\input{decentralisation/sidechains.tex}
|
||||
\subsection[HLTC]{Hash Lock Time Contract}
|
||||
\input{decentralisation/hltc.tex}
|
||||
\subsection[Usages Concrets]{Les diifferentes implémentations du swap décentralisé}
|
||||
\input{decentralisation/usages.tex}
|
3
docs/presentation_17_03_23/decentralisation/intro.tex
Normal file
3
docs/presentation_17_03_23/decentralisation/intro.tex
Normal file
@ -0,0 +1,3 @@
|
||||
\begin{frame}
|
||||
\frametitle{Définition et contextualisation}
|
||||
\end{frame}
|
BIN
docs/presentation_17_03_23/decentralisation/lightning.jpg
Normal file
BIN
docs/presentation_17_03_23/decentralisation/lightning.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 580 KiB |
41
docs/presentation_17_03_23/decentralisation/relay.tex
Normal file
41
docs/presentation_17_03_23/decentralisation/relay.tex
Normal file
@ -0,0 +1,41 @@
|
||||
%auteur: Amaury JOLY
|
||||
\begin{frame}
|
||||
\frametitle{Relay}
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Qu’est-ce qu’un relay ?}
|
||||
\begin{itemize}
|
||||
\item Un contrat intelligent sur Ethereum
|
||||
\item Un transmetteur d’informations entre blockchains
|
||||
\item Un suiveur d’état de chaînes connectées
|
||||
\item Un prouveur de transactions cross-chain
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Qu’est-ce que BTCRelay ?}
|
||||
\begin{itemize}
|
||||
\item Un contrat intelligent qui stocke les en-têtes de blocs Bitcoin
|
||||
\item Un constructeur d’une mini-version de la blockchain Bitcoin
|
||||
\item Un outil open source, sans confiance et décentralisé
|
||||
\item Un vérificateur de transactions Bitcoin pour les contrats Ethereum
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Qu’est-ce que BTCRelay ?}
|
||||
\centering
|
||||
\includegraphics[scale = 0.5]{decentralisation/btcRelay.png}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Qu’est-ce que tBTC ?}
|
||||
\begin{itemize}
|
||||
\item Un projet de relay entre Bitcoin et Ethereum
|
||||
\item Un échangeur de bitcoins contre des tokens ERC-20
|
||||
\item Un contrat Deposit qui interagit avec des signataires
|
||||
\item Un utilisateur de BTCRelay pour vérifier les transactions Bitcoin
|
||||
\end{itemize}
|
||||
\end{frame}
|
30
docs/presentation_17_03_23/decentralisation/sidechains.tex
Normal file
30
docs/presentation_17_03_23/decentralisation/sidechains.tex
Normal file
@ -0,0 +1,30 @@
|
||||
%auteur: Amaury JOLY
|
||||
\begin{frame}
|
||||
\frametitle{Qu’est-ce qu’une sidechain ?}
|
||||
\begin{itemize}
|
||||
\item Une blockchain secondaire
|
||||
\item Parallèle à une blockchain principale
|
||||
\item Propres caractéristiques
|
||||
\item Sécurité et communauté du réseau principal
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Qu’est-ce que Zendoo ?}
|
||||
\begin{itemize}
|
||||
\item Une plateforme de création de sidechains
|
||||
\item Interopérables avec la blockchain Horizen
|
||||
\item Protocole de transfert cross-chain vérifiable par zk-SNARK \footnote{Preuve cryptographique sans révélation d’informations}
|
||||
\item Sécurité et décentralisation des communications
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Quelle sont les contraintes techniques des sidechains ?}
|
||||
\begin{itemize}
|
||||
\item La création d’un pont bidirectionnel
|
||||
\item Le transfert d’actifs entre les deux chaînes
|
||||
\item La coordination entre les deux chaînes
|
||||
\item Les problèmes de sécurité, de performance ou de compatibilité
|
||||
\end{itemize}
|
||||
\end{frame}
|
BIN
docs/rapportFinal/decentralisation/btcRelay.png
Normal file
BIN
docs/rapportFinal/decentralisation/btcRelay.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 42 KiB |
@ -1,2 +1,8 @@
|
||||
\subsection{Etat de l'art}
|
||||
\input{decentralisation/etat_art.tex}
|
||||
\input{decentralisation/etat_art.tex}
|
||||
|
||||
\subsection[Relay]{Relay}
|
||||
\input{decentralisation/relay.tex}
|
||||
|
||||
\subsection[Relay]{Sidechains}
|
||||
\input{decentralisation/sidechain.tex}
|
42
docs/rapportFinal/decentralisation/relay.tex
Normal file
42
docs/rapportFinal/decentralisation/relay.tex
Normal file
@ -0,0 +1,42 @@
|
||||
%auteur: Amaury JOLY
|
||||
\subsubsection{Définition}
|
||||
|
||||
Les relays sont des contrats intelligents qui existent sur la blockchain Ethereum.
|
||||
Leur but est de transmettre des informations entre des blockchains distinctes (par exemple, Bitcoin et 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.
|
||||
|
||||
\subsubsection{BTCRelay}
|
||||
|
||||
BTCRelay est un contrat intelligent qui stocke les en-têtes de blocs Bitcoin sur la blockchain Ethereum.
|
||||
BTCRelay utilise ces en-têtes de blocs pour construire une mini-version de la blockchain 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 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 intermédiaire: en d’autres termes,
|
||||
les utilisateurs peuvent payer avec Bitcoin pour utiliser les DAPPs 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é dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle de Bitcoin vers Ethereum.\\
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[scale=0.5]{decentralisation/btcRelay.png}
|
||||
\label{fig:btcRelay}
|
||||
\caption{BTCRelay}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{tBTC}
|
||||
|
||||
Un exemple de relay est le projet tBTC, qui permet aux utilisateurs d’échanger des bitcoins contre des
|
||||
tokens ERC-20 représentant des bitcoins sur la blockchain Ethereum. 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
|
||||
brûler des tokens 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. \\
|
||||
Bien que tBTC se présente comme une solution décentralisée et sans confiance pour échanger des bitcoins 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
|
||||
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.
|
||||
Les signataires sont choisis aléatoirement par un mécanisme appelé 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
|
||||
un type d’attaque sur un réseau pair à pair dans laquelle un attaquant crée un grand nombre d’identités fausses
|
||||
et les utilise pour gagner une influence disproportionnée sur le réseau} ou de corruption.
|
13
docs/rapportFinal/decentralisation/sidechain.tex
Normal file
13
docs/rapportFinal/decentralisation/sidechain.tex
Normal file
@ -0,0 +1,13 @@
|
||||
%auteur: Amaury JOLY
|
||||
\subsubsection{Définition}
|
||||
|
||||
Les sidechains sont des blockchains secondaires qui fonctionnent en parallèle d'une blockchain principale. 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 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.
|
||||
|
||||
\subsubsection{Zendoo}
|
||||
|
||||
Zendoo est une plateforme de création de sidechains interopérables avec la blockchain Horizen. 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 la chaîne principale et les sidechains. Les sidechains Zendoo peuvent avoir des caractéristiques différentes de la chaîne principale, comme le mécanisme de consensus, le modèle comptable ou la structure des données. Elles peuvent même ne pas être des blockchains du tout, tant qu'elles respectent le protocole de transfert cross-chain. Zendoo offre ainsi une grande liberté aux développeurs pour créer des applications sur mesure sans compromettre la scalabilité ou la sécurité du réseau Horizen.\\
|
||||
De ce fait, Zendoo facilite l'échange de jetons entre différentes chaînes de blocs, sans passer par des intermédiaires centralisés qui perçoivent des commissions. 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 (two-way bridge) entre la chaîne principale et la sidechain. Ce pont permet de transférer des actifs entre les deux chaînes, en respectant un taux de change prédéfini et en garantissant la conservation du nombre total d'actifs. 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 blockchains comme Ethereum ou 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 blockchains pour qu'elles puissent communiquer avec les sidechains, ce qui impliquerait des modifications importantes dans leur protocole.
|
@ -14,7 +14,6 @@
|
||||
\end{abstract}
|
||||
}
|
||||
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{Echange de jetons inter-blockchains}
|
||||
|
Reference in New Issue
Block a user