mirror of
https://etulab.univ-amu.fr/v18003685/pfe-blockchain.git
synced 2024-02-26 02:14:01 +01:00
Resolve "Glossaire"
This commit is contained in:
@ -1,7 +1,7 @@
|
||||
%author: Dorian VOLPE
|
||||
\subsubsection{HTLC}
|
||||
|
||||
Un HTLC est un type de \textit{\gls{smart contract}} utilisé dans les applications \textit{\gls{blockchain}} qui réduit le risque de contrepartie en créant une garantie basée sur le temps et une autre sur un verrou cryptographique\cite{narayanam2022generalized}.
|
||||
Un \acrshort{htlc} est un type de \textit{\gls{smart contract}} utilisé dans les applications \textit{\gls{blockchain}} qui réduit le risque de contrepartie en créant une garantie basée sur le temps et une autre sur un verrou cryptographique\cite{narayanam2022generalized}.
|
||||
Ils reposent sur deux primitives fondamentales: le verrou de hachage et le verrou temporel.\\
|
||||
Premièrement le verrou de hachage (ou bien \textit{hashlock}): Ce dernier va fonctionner comme une assurance qui va couvrir les parties participantes à la transaction, en leur garantissant que chaque modification de l'échange soit réalisée d'un commun accord de toutes les parties.
|
||||
Cela est mis en place grâce à un partage du hachage de la clef privée de la transaction, ce partage va donc impliquer que le canal de paiement mis en place ne puisse être ouvert ou fermé qu'avec l'accord de tous les participants.\\
|
||||
@ -20,13 +20,13 @@ L’intérêt principal de ce type de contrat est qu'il permet d'effectuer facil
|
||||
\label{fig:HTLC}
|
||||
\end{figure}
|
||||
\subsubsection{Atomic swaps}
|
||||
Les \textit{atomics swaps} ou bien échanges atomiques sont des échanges effectués entre deux \textit{\gls{blockchain}s}\cite{herlihy2018atomic}. On les appelle "atomiques" car il respecte une primitive essentielle à leur fonctionnement et à leur principe d'utilisation:
|
||||
Les \textit{atomics swaps} ou bien \glspl{atomic swap} sont des échanges effectués entre deux \textit{\gls{blockchain}s}\cite{herlihy2018atomic}. On les appelle "atomiques" car il respecte une primitive essentielle à leur fonctionnement et à leur principe d'utilisation:
|
||||
l'échange est insécable, c'est-à-dire qu'a son issue, soit il s'est pleinement exécuté, soit l'état antérieur à l'échange est préservé.
|
||||
Cette primitive permet de garantir que les participants ne seront jamais dans des états jugés "inacceptables". \\
|
||||
En effet les échanges atomiques partent du postulat que si une partie suit le protocole à la lettre alors,
|
||||
il ne sera jamais perdant. A contrario les partis ne suivant pas le protocole par malveillance ou par erreur, prennent le risque de perdre leurs mises de départ.\\ \\
|
||||
Lors d'un échange atomique les HTLC vont être utilisés de manière centrale car ils vont permettre d'apporter les garanties que nous avons vue dans la partie précédente. Il faut voir les échanges atomiques comme une généralisation de l'utilisation des HTLC. Lors d'un échange atomique les deux \textit{\gls{blockchain}s} mises en relation doivent pouvoir communiquer et échanger sur une interface commune comme un portefeuille multi signature ou un canal d'échange mis en place spécialement pour cette transaction. \\ \\
|
||||
Si nous nous penchons sur le déroulement d'un échange atomique à deux parties nous pouvons déduire les étapes suivantes:
|
||||
Lors d'un \gls{atomic swap} les HTLC vont être utilisés de manière centrale car ils vont permettre d'apporter les garanties que nous avons vue dans la partie précédente. Il faut voir les échanges atomiques comme une généralisation de l'utilisation des HTLC. Lors d'un \gls{atomic swap} les deux \textit{\gls{blockchain}s} mises en relation doivent pouvoir communiquer et échanger sur une interface commune comme un portefeuille multi signature ou un canal d'échange mis en place spécialement pour cette transaction. \\ \\
|
||||
Si nous nous penchons sur le déroulement d'un \gls{atomic swap} à deux parties nous pouvons déduire les étapes suivantes:
|
||||
\begin{enumerate}
|
||||
\item Les deux parties participent à l'échange, créant un HTLC (sur chaque \textit{\gls{blockchain}}) dans lequel les fonds sont bloqués.
|
||||
\item Ils échangent les informations nécessaires pour effectuer une transaction sur la \textit{\gls{blockchain}} de l'autre partie.
|
||||
@ -38,7 +38,7 @@ Si nous nous penchons sur le déroulement d'un échange atomique à deux parties
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[scale=0.15]{decentralisation/atomicSwap.png}
|
||||
\caption{Déroulement simplifié d'un échange atomique}
|
||||
\caption{Déroulement simplifié d'un \gls{atomic swap}}
|
||||
\label{fig:atomicSwap}
|
||||
\end{figure}
|
||||
|
||||
|
@ -13,5 +13,5 @@
|
||||
\subsection[Atomic swaps et HTLC]{Atomic swaps et HTLC}
|
||||
\input{decentralisation/atomic_swaps_htlc.tex}
|
||||
|
||||
\subsection[Échanges "off-chain"]{Les échanges \textit{off-chain}}
|
||||
\subsection[Échanges "off chain"]{Les échanges \textit{off chain}}
|
||||
\input{decentralisation/lightning.tex}
|
@ -1,22 +1,22 @@
|
||||
%author: Dorian VOLPE
|
||||
\subsubsection{Fonctionnement des échanges \textit{off-chain}}
|
||||
Les échanges \textit{off-chain} sont des transactions de crypto-\gls{actif} dont on déplace la valeur en dehors de la \textit{\gls{blockchain}} mère. En d’autres termes, il s’agit de la négociation de la valeur d’un \gls{actif} crypto en dehors de la \textit{\gls{blockchain}} source. Les transactions \textit{on-chain} sont les échanges d'\gls{actif}s qui ont lieu sur la \textit{\gls{blockchain}} elle-même.
|
||||
\subsubsection{Fonctionnement des échanges \textit{\gls{off chain}}}
|
||||
Les échanges \textit{\gls{off chain}} sont des transactions de crypto-\gls{actif} dont on déplace la valeur en dehors de la \textit{\gls{blockchain}} mère. En d’autres termes, il s’agit de la négociation de la valeur d’un \gls{actif} crypto en dehors de la \textit{\gls{blockchain}} source. Les transactions \textit{on-chain} sont les échanges d'\gls{actif}s qui ont lieu sur la \textit{\gls{blockchain}} elle-même.
|
||||
Ils sont des échanges d’\gls{actif}s internes au réseau et ont donc leurs propres grands livres, authentification et coûts qui ont lieu parmi la \textit{\gls{blockchain}}.
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\stackunder{\includegraphics[scale=0.3]{decentralisation/offchain.png}}
|
||||
{\scriptsize Source: \url{https://www.cryptoencyclopedie.com/single-post/\gls{blockchain}-comprendre-distinction-on-chain-off-chain}}
|
||||
\caption{Architecture \textit{off-chain}}
|
||||
{\scriptsize Source: \url{https://www.cryptoencyclopedie.com/single-post/\gls{blockchain}-comprendre-distinction-on-chain-\gls{off chain}}}
|
||||
\caption{Architecture \textit{\gls{off chain}}}
|
||||
\label{fig:offchain}
|
||||
\end{figure}
|
||||
Les transactions \textit{off-chain} sont confirmées en dehors du réseau principal de la \textit{\gls{blockchain}}, ce qui entraîne souvent un processus moins cher et plus rapide pour l’utilisateur.
|
||||
Les transactions \textit{\gls{off chain}} sont confirmées en dehors du réseau principal de la \textit{\gls{blockchain}}, ce qui entraîne souvent un processus moins cher et plus rapide pour l’utilisateur.
|
||||
Tout cela se fait dans un objectif bien précis qui est de garder le maximum de sécurité et de fiabilité de la \textit{\gls{blockchain}} mère tout en essayant d'améliorer la vitesse d'échange et les frais de transaction.
|
||||
Afin d'illustrer comment fonctionne les échanges \textit{off-chain} nous allons nous concentrer sur une implémentation en particulier: le réseau Lightning.
|
||||
Afin d'illustrer comment fonctionne les échanges \textit{\gls{off chain}} nous allons nous concentrer sur une implémentation en particulier: le réseau Lightning.
|
||||
|
||||
\subsubsection{Le réseau lightning}
|
||||
|
||||
Le réseau lightning (provenant de l'anglais \textit{Lightning Network} et abrégé par LN) fait partie des processus d'échanges que l'on qualifie d'\textit{off-chain} car il se déroule en dehors de leur \textit{\gls{blockchain}s} principale, ce protocole est un cas concret de cette famille.
|
||||
Ce réseau est une couche de protocole de paiement construite au-dessus de la \textit{\gls{blockchain}} Bitcoin qui vise à accélérer les transactions Bitcoin, à réduire les coûts et à améliorer la mise a l'échelle \cite{poon2016bitcoin}.
|
||||
Le réseau lightning (provenant de l'anglais \textit{Lightning Network} et abrégé par LN) fait partie des processus d'échanges que l'on qualifie d'\textit{\gls{off chain}} car il se déroule en dehors de leur \textit{\gls{blockchain}s} principale, ce protocole est un cas concret de cette famille.
|
||||
Ce réseau est une couche de protocole de paiement construite au-dessus de la \textit{\gls{blockchain}} \gls{Bitcoin} qui vise à accélérer les transactions \gls{Bitcoin}, à réduire les coûts et à améliorer la mise a l'échelle \cite{poon2016bitcoin}.
|
||||
Il permet aux utilisateurs de créer des canaux de paiement peer-to-peer bidirectionnels pour effectuer des transactions en dehors de la \textit{\gls{blockchain}} principale (voir Figure \ref{fig:lightningCouche}), permettant des transactions plus rapides, moins chères et plus privées.\\
|
||||
Les transactions sur le réseau lightning sont effectuées avec des \gls{smart contract}s qui permettent aux utilisateurs de transférer des fonds à des tiers sans l'approbation de la \textit{\gls{blockchain}} principale ou bien d'un tiers de confiance.
|
||||
Les canaux de paiement flash sont créés en verrouillant temporairement des fonds sur une adresse multi-signature (voir Figure \ref{fig:lightningNetwork}), qui est ensuite utilisée pour envoyer des transactions à d'autres participants du réseau.\\
|
||||
@ -28,7 +28,7 @@ Les frais d'utilisation de ce réseau sont généralement bien inférieurs aux f
|
||||
\centering
|
||||
\stackunder{ \includegraphics[scale = 0.3 ]{decentralisation/lightningCouche.png} }
|
||||
{\scriptsize Source: \url{https://www.bitpanda.com/academy/fr/lecons/quel-est-le-role-du-lightning-network-pour-bitcoin/}}
|
||||
\caption{Le réseau Lightning par rapport a la \textit{\gls{blockchain}} Bitcoin principale}
|
||||
\caption{Le réseau Lightning par rapport a la \textit{\gls{blockchain}} \gls{Bitcoin} principale}
|
||||
\label{fig:lightningCouche}
|
||||
\end{figure}
|
||||
|
||||
@ -43,7 +43,7 @@ Les frais d'utilisation de ce réseau sont généralement bien inférieurs aux f
|
||||
Voici le déroulement classique d'un échange sur le réseau Lightning:\\ Alice veut échanger avec Bob à travers le réseau Lightning (sur la même ou bien sur des \textit{\gls{blockchain}s} différentes).
|
||||
Alice va donc ouvrir un portefeuille multi-signature\footnote{Portefeuille qui nécessite plusieurs signatures pour effectuer une transaction} avec Bob. Ils vont mettre une "mise de départ" qu'ils vont déposer dans le portefeuille mentionné précédemment (le canal d'échange aura donc la taille des deux mises de départ cumulées).
|
||||
Ensuite ils vont effectuer leurs transactions dans ce portefeuille qui va être mis à jour à chaque transaction.\\ \\
|
||||
Il est fondamental de noter que chaque transaction invalide les précédentes (à l'exception de la toute première). Lorsque l'un des participants souhaite terminer l'échange il va publier sur la \textit{\gls{blockchain}} Bitcoin la dernière transaction effectuée.
|
||||
Il est fondamental de noter que chaque transaction invalide les précédentes (à l'exception de la toute première). Lorsque l'un des participants souhaite terminer l'échange il va publier sur la \textit{\gls{blockchain}} \gls{Bitcoin} la dernière transaction effectuée.
|
||||
Ce mécanisme de transaction intermédiaire est mis en place afin d'éviter qu'un des deux acteurs de l'échange ne puisse "s'échapper" de l'échange, car chacune des parties va signer avec sa clef privée la dernière transaction. \\
|
||||
Aussi tous ces échanges se passent à l'intérieur du réseau Lightning, la \textit{\gls{blockchain}} principale n'a donc aucune idée du nombre exact de transactions intermédiaires effectuées puisque seule une transaction sera envoyée sur la \textit{\gls{blockchain}} principale.
|
||||
Cela permet d'éviter d'engendrer des frais de transactions inutiles ou bien de congestionner la \textit{\gls{blockchain}} principale.\\ \\
|
||||
@ -62,7 +62,7 @@ Leur programme rajoute 4 commandes au réseau Lightning mentionné précédemmen
|
||||
\begin{itemize}
|
||||
\item \textit{Price}: Commande qui permet aux utilisateurs de rechercher la valeur marchande actuelle en USD de toute crypto-monnaie disponible sur le site \textit{coinranking.com}.\\
|
||||
\item \textit{Compare}: Permet de comparer la valeur en USD de deux cryptomonnaies différente et de faire l'équivalent d'une cryptomonnaie à une autre. Cette commande utilise la commande \textit{Price} mentionnée au-dessus.\\
|
||||
\item \textit{Exchange} : La commande \textit{Exchange} est la première des deux commandes développées pour effectuer des échanges inter-chaînes. Elle permet de spécifier les montants mis en jeu lors de l'échange. Si Alice veut échanger 20 Bitcoin (à travers le canal 1) pour 10 Litecoin (à travers le canal 2) avec Bob, elle entrerait "Exchange 1 20 2 10 ».\\
|
||||
\item \textit{Exchange} : La commande \textit{Exchange} est la première des deux commandes développées pour effectuer des échanges inter-chaînes. Elle permet de spécifier les montants mis en jeu lors de l'échange. Si Alice veut échanger 20 \gls{Bitcoin} (à travers le canal 1) pour 10 Litecoin (à travers le canal 2) avec Bob, elle entrerait "Exchange 1 20 2 10 ».\\
|
||||
\item \textit{Respond} : À ce stade, Bob a une minute pour décider si pour accepter 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 \textit{timeout}.\\
|
||||
\end{itemize}
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
% Autheur: Amaury JOlY
|
||||
|
||||
\subsubsection{Definition}
|
||||
Les réserves de liquidité sont des marchés automatisés qui permettent aux utilisateurs de fournir des liquidités pour les échangeurs décentralisés (DEX) et de
|
||||
Les réserves de liquidité sont des marchés automatisés qui permettent aux utilisateurs de fournir des liquidités pour les échangeurs décentralisés (\acrshort{dex}) et de
|
||||
remporter une comission à chaque transaction \cite{jensen2021introduction, belchior2022survey, augustin2022yield}.
|
||||
Les fournisseurs de liquidités déposent des fonds dans une réserve de liquidité et reçoivent des jetons
|
||||
LP\footnote{Liquidity Provider Token} en retour. Les jetons LP représentent une part de propriété dans la réserve de liquidité et peuvent être utilisés pour
|
||||
@ -38,5 +38,5 @@ utilisateurs d’acheter ou de vendre des actifs sur la plateforme. Enfin, les r
|
||||
une réserve de liquidités est compromise, les utilisateurs peuvent perdre leurs fonds. \\
|
||||
Un exemple d'attaque sur une réserve de liquidité est la CVE-2021-3006 \cite{nvd2021-3006,blocksec2021Seal}. La CVE-2021-3006 est une vulnérabilité de sécurité qui a été exploitée en décembre
|
||||
2020 et janvier 2021. Elle concerne un manquement de controle d'accès dans l’implémentation du \textit{\gls{smart contract}} pour une réserve de liquidité en lien avec
|
||||
Seal Finance (Seal), un jeton Ethereum. Cette vulnérabilité permet une manipulation des prix ayant permis à l'attaquant de réaliser une plus-value artificiel
|
||||
sur ses jetons.
|
||||
Seal Finance (Seal), un jeton \gls{Ethereum}. Cette vulnérabilité permet une manipulation des prix ayant permis à l'attaquant de réaliser une plus-value artificiel
|
||||
sur ses jetons.
|
||||
|
@ -1,18 +1,18 @@
|
||||
%auteur: Amaury JOLY
|
||||
\subsubsection{Définition}
|
||||
Les relays décentralisés sont des applications décentralisés permettant une intéropérabilités entre les \textit{\gls{blockchain}s} \cite{qin2018overview, westerkamp2022verilay,belchior2022survey}.
|
||||
Leur but est de transmettre des informations entre des \textit{\gls{blockchain}s} 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.
|
||||
Les \gls{relay}s décentralisés sont des applications décentralisés permettant une intéropérabilités entre les \textit{\gls{blockchain}s} \cite{qin2018overview, westerkamp2022verilay,belchior2022survey}.
|
||||
Leur but est de transmettre des informations entre des \textit{\gls{blockchain}s} distinctes (par exemple, \gls{Bitcoin} et \gls{Ethereum}).
|
||||
Les \gls{relay}s 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 \textit{smart contract} qui stocke les en-têtes de blocs Bitcoin sur la \textit{\gls{blockchain}} Ethereum. \cite{qin2018overview,belchior2022survey,btcrelay2022web,btcrelay2022git}
|
||||
BTCRelay utilise ces en-têtes de blocs pour construire une mini-version de la \textit{\gls{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
|
||||
BTCRelay est un \textit{\gls{smart contract}} qui stocke les en-têtes de blocs \gls{Bitcoin} sur la \textit{\gls{blockchain}} \gls{Ethereum}. \cite{qin2018overview,belchior2022survey,btcrelay2022web,btcrelay2022git}
|
||||
BTCRelay utilise ces en-têtes de blocs pour construire une mini-version de la \textit{\gls{blockchain}} \gls{Bitcoin}: une méthode utilisée par les
|
||||
portefeuilles légers \gls{Bitcoin} SPV. \footnote{\gls{Bitcoin} SPV signifie Simplified Payment Verification et c’est un moyen pour \gls{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.\\
|
||||
BTCRelay est open source, sans confiance et décentralisé. Il permet aux contrats \gls{Ethereum} de vérifier les transactions \gls{Bitcoin} sans aucun
|
||||
intermédiaire: en d’autres termes, les utilisateurs peuvent payer avec \gls{Bitcoin} pour utiliser les \gls{dApp}s \gls{Ethereum}. Il offre également la
|
||||
possibilité de relayer la transaction \gls{Bitcoin} à n’importe quel contrat \gls{Ethereum} et d’inspecter le dernier en-tête de bloc \gls{Bitcoin} stocké
|
||||
dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle de \gls{Bitcoin} vers \gls{Ethereum}.\\
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
@ -25,16 +25,16 @@ dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle
|
||||
Un exemple d'usage de BTCrelay pour de l'echange \gls{cross-chain} est le projet tBTC, qui permet aux utilisateurs d’échanger des bitcoins contre des
|
||||
tokens ERC-20 représentant des bitcoins sur la \textit{\gls{blockchain}} Ethereum \cite{hildebrandt2020tokenization,lan2021horizon}. 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
|
||||
Le contrat Deposit utilise BTCRelay pour vérifier les preuves SPV des transactions \gls{Bitcoin} et émettre ou
|
||||
brûler des \gls{actif} tBTC en conséquence. Ainsi, les utilisateurs peuvent profiter des avantages de la liquidité
|
||||
et de la programmabilité d’\gls{Ethereum} tout en conservant l’exposition au \gls{Bitcoin}. \\
|
||||
Bien que tBTC se présente comme une solution décentralisée et sans confiance pour échanger des \gls{Bitcoin}s 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
|
||||
Par exemple, tBTC repose sur un ensemble de signataires qui doivent déposer une garantie pour sécuriser les \gls{Bitcoin}s
|
||||
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.
|
||||
perdre l’accès à leurs \gls{Bitcoin}s 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é \textit{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
|
||||
|
@ -1,12 +1,12 @@
|
||||
%auteur: Amaury JOLY
|
||||
\subsubsection{Définition}
|
||||
Les sidechains sont des \textit{\gls{blockchain}s} secondaires qui fonctionnent en parallèle d'une \textit{\gls{blockchain}} principale \cite{jensen2021introduction,qin2018overview,belchior2022survey}. Elles possèdent leurs propres
|
||||
Les \gls{sidechain}s sont des \textit{\gls{blockchain}s} secondaires qui fonctionnent en parallèle d'une \textit{\gls{blockchain}} principale \cite{jensen2021introduction,qin2018overview,belchior2022survey}. 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 \textit{\gls{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.
|
||||
et de fonctionnalités. Par exemple, certaines \gls{sidechain}s sont compatibles avec l'\gls{Ethereum} Virtual Machine (EVM) et peuvent donc porter des applications \gls{Ethereum}.
|
||||
|
||||
\subsubsection{Zendoo}
|
||||
Zendoo est une plateforme de création de sidechains interopérables avec la \textit{\gls{blockchain}} Horizen \cite{garoffolo2020zendoo,belchior2022survey}. Elle utilise un protocole
|
||||
Zendoo est une plateforme de création de \gls{sidechain}s interopérables avec la \textit{\gls{blockchain}} Horizen \cite{garoffolo2020zendoo,belchior2022survey}. 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
|
||||
@ -18,9 +18,9 @@ De ce fait, Zendoo facilite l'échange de jetons entre différentes chaînes de
|
||||
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 (\textit{two-way bridge}) entre la chaîne
|
||||
principale et la sidechain. Ce pont permet de transférer des \gls{actif}s entre les deux chaînes, en respectant un taux de change prédéfini et en garantissant la
|
||||
La mise en place de \gls{sidechain}s implique une contrainte technique majeure : la création d'un pont bidirectionnel (\textit{two-way bridge}) entre la chaîne
|
||||
principale et la \gls{sidechain}. Ce pont permet de transférer des \gls{actif}s entre les deux chaînes, en respectant un taux de change prédéfini et en garantissant la
|
||||
conservation du nombre total d'\gls{actif}s. 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 \textit{\gls{blockchain}s} 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 \textit{\gls{blockchain}s}
|
||||
pour qu'elles puissent communiquer avec les sidechains, ce qui impliquerait des modifications importantes dans leur protocole.
|
||||
performance ou de compatibilité. Par exemple, il est difficile d'utiliser des \gls{sidechain}s avec des \textit{\gls{blockchain}s} comme \gls{Ethereum} ou \gls{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 \gls{sidechain}s. Il faudrait donc adapter ces \textit{\gls{blockchain}s}
|
||||
pour qu'elles puissent communiquer avec les \gls{sidechain}s, ce qui impliquerait des modifications importantes dans leur protocole.
|
||||
|
Reference in New Issue
Block a user