mirror of
https://etulab.univ-amu.fr/v18003685/pfe-blockchain.git
synced 2024-02-26 02:14:01 +01:00
abstract
This commit is contained in:
JOLY Amaury
@ -1,17 +1,17 @@
|
||||
\subsubsection{Définition}
|
||||
Nous avons commencé nos recherches en nous intéressant en premier lieu aux moyens d'échanges les plus répandus.
|
||||
Cela nous a mené vers les plate-formes d'échanges centralisé.
|
||||
Ce sont des plate-formes, pouvant prendre la forme d'applications web, qui permettent aux utilisateurs d'acheter, de vendre ou d'échanger des \gls{actif}s numériques contre d'autres \gls{actif}s numériques ou contre d'autres monnaies fiduciaires.
|
||||
Ce sont des plate-formes, pouvant prendre la forme d'applications web, qui permettent aux utilisateurs d'acheter, de vendre ou d'échanger des \gls{actif}s numériques contre d'autres \gls{actif}s numériques ou en monnaies fiduciaires.
|
||||
Ces plate-formes peuvent opérer sur des \textit{\gls{blockchain}s} publiques ou être dédiées à une utilisation en interne.
|
||||
Elles sont dites centralisées car elles sont gérées par une entreprise ou une organisation hiérarchique qui contrôle les transactions et les fonds des utilisateurs.
|
||||
Elles sont dites centralisées car elles sont gérées par une entreprise ou une organisation hiérarchisée qui contrôle les transactions et les fonds des utilisateurs.
|
||||
Ces plate-formes sont donc considérées comme des tiers de confiance et agissent en tant qu'intermédiaires entre les acheteurs et les vendeurs en assurant la sécurité, la liquidité et la rapidité des transactions.
|
||||
C'est la solution la plus utilisée dans le secteur des \gls{actif}s numériques, elles offrent très souvent une certaine variété de services tels que le prêt, le \textit{stacking} \footnote{Stacking : Action de verrouiller des jetons en vue de recevoir des récompenses \cite{defStack}}.
|
||||
C'est la solution la plus utilisée dans le secteur des \gls{actif}s numériques, elles offrent très souvent une certaine variété de services tels que le prêt et/ou le \textit{stacking} \footnote{Stacking : Action de verrouiller des jetons en vue de recevoir des récompenses \cite{defStack}}.
|
||||
Elles proposent également un large éventail de cryptomonnaies disponibles.
|
||||
|
||||
\subsubsection{Inconvénients et risques}
|
||||
Nous avons pu tout de même relever certains inconvénients et certains risques pour les utilisateurs liés à l'utilisation de ces plate-formes.
|
||||
Tout d'abords, les utilisateurs doivent confier leurs fonds et leurs données à un tier en qui ils doivent avoir confiance.
|
||||
Cela peut exposer les utilisateurs à de la fraude, du vol ou encore du piratage si les plate-formes présentent des failles de sécurité.
|
||||
Cela peut exposer les utilisateurs à de la fraude, du vol ou encore du piratage si les plate-formes présentent des failles de sécurité. \\
|
||||
Ensuite, ces plate-formes peuvent être victimes de pannes ou de saturation du réseau pouvant entraîner des retards, des pertes de transactions ou encore du déni de service bloquant ainsi l'accès aux \gls{actif}s des utilisateurs.
|
||||
Finalement, ces plate-formes sont soumises à la réglementation et à la surveillance des autorités financières, limitant leur accessibilité dans certains pays ou régions.
|
||||
Ce point signifie aussi que les \gls{actif}s de l'utilisateurs sont traçables par les autorités.
|
||||
@ -20,8 +20,8 @@ Ce point signifie aussi que les \gls{actif}s de l'utilisateurs sont traçables p
|
||||
\subsubsection{Fonctionnement}
|
||||
Ces plate-formes fonctionnent sur le principe de l'\textit{order book method} (méthode du carnet d'ordre\cite{orderBook}), une modélisation des ordres d'achats et de vente des jetons.
|
||||
Un ordre étant une demande d'un utilisateur visant à réaliser une opération à un prix et une quantité donnée.
|
||||
Cette méthode comprend deux parties,: l'offre et la demande. L'offre regroupe les ordres d'achats émis par des utilisateurs sur la plate-forme et la demande, les ordres de vente.
|
||||
Lors d'un dépôt, l'utilisateur s'étant au préalable enregistré sur la plate-forme, l'utilisateur va déposer les fonds souhaités dans un porte monnaie.
|
||||
Cette méthode comprend deux parties: l'offre et la demande. L'offre regroupe les ordres d'achats émis par des utilisateurs sur la plate-forme et la demande, les ordres de vente.
|
||||
Lors d'un dépôt, l'utilisateur s'étant au préalable enregistré sur la plate-forme, il va déposer les fonds souhaités dans un porte monnaie.
|
||||
La plate-forme va ensuite crée un \textit{IOU}\footnote{I Owe You, c'est la dette de la plate-forme envers l'utilisateur permettant de bloquer la valeur de la monnaie déposée par l'utilisateur\cite{IOU}}
|
||||
ce dernier sera échangé contre le crypto-\gls{actif} souhaité lors d'un échange ou d'une vente. \\
|
||||
\begin{figure}[h!]
|
||||
|
||||
@ -96,7 +96,7 @@ Dans la plupart des cas, elles résultent de problèmes d'implémentations et au
|
||||
Cela peut être expliqué par le fait que la \textit{\gls{blockchain}} est un domaine qui évolue très vite et chaque innovation technique peut rapporter des parts de marché importantes au premier arrivé.
|
||||
De plus, de nombreux acteurs se spécialisent dans ce domaine sans nécessairement avoir une grande culture de la cybersécurité.
|
||||
Il se peut donc que des erreurs d'implémentations paraissant évidentes ne soient pas relevés lors de la mise en production. \\
|
||||
Des moyens de limiter le plus possible l'apparition de tels événements sont néanmoins possibles.
|
||||
Des moyens de limiter l'apparition de tels événements sont néanmoins possibles.
|
||||
Tout d'abord des standards de sécurité pourraient être mis en place afin de déterminer un socle minimal à atteindre.
|
||||
Des audits et des analyses de sécurité peuvent être mis en place pendant la production ou après la publication des protocoles, en respectant un cycle de développement "classique".
|
||||
%Nous pouvons aussi nous questionner quant à l'implication du tier de confiance dans l'apparition de ces failles.
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
Comme son nom l’indique, un \textit{\gls{blockchain} bridge} également appelé \textit{\gls{cross-chain} bridge} est un protocole reliant deux \textit{\gls{blockchain}s} entre elles de manière unilatérale ou bilatérale dans une optique d’interopérabilité.\\
|
||||
|
||||
Dans la but de comprendre la popularité des \textit{bridges} en tant que protocole d’interopéralité, il faut en premier lieu s’intéresser au marché de la cryptomonnaie. Actuellement Bitcoin domine en représentant 40,5\% de ce dernier, suivie ensuite par Ethereum avec 19,5\%. Cela laisse donc 40\% du \textit{cryptomarket} formé de nombreuses crytomonnaies plus petites et plus indépendantes. C’est donc naturellement, qu’une forte demande de possibilité d’échanges entre les \textit{\gls{blockchain}s} ait vu le jour de la part des utilisateurs ayant plusieurs cryptomonnaies\cite{NgraveNumbers}.\\
|
||||
Dans la but de comprendre la popularité des \textit{bridges} en tant que protocole d’interopéralité, il faut en premier lieu s’intéresser au marché de la cryptomonnaie. Actuellement Bitcoin domine en représentant 40,5\% de ce dernier, suivie ensuite par Ethereum avec 19,5\%. Cela laisse donc 40\% du marché formé de nombreuses crytomonnaies plus petites et plus indépendantes. C’est donc naturellement, qu’une forte demande de possibilité d’échanges entre les \textit{\gls{blockchain}s} ait vu le jour de la part des utilisateurs ayant plusieurs cryptomonnaies\cite{NgraveNumbers}.\\
|
||||
|
||||
Il existe trois différentes manières de déplacer les \gls{actif}s en tant que \textit{bridge}. Tout d’abord, le mécanisme de \textit{Lock and Mint} signifiant Verrouiller et Frapper, les \gls{actif}s se trouvant sur la chaîne de départ sont verrouillés sur celle-ci pour être ensuite créés sur la chaîne destinataire. Un autre mode d'échange est celui du \textit{Burnt and Mint}, ce dernier est très similaire à celui déjà présenté, la seule différence étant que les \gls{actif}s sont directement effacés plutôt que verrouillés. Pour finir, les échanges atomiques entre chaînes (Atomic Swaps) permettent un échange direct en pair-à-pair d'\gls{actif}s entre la chaîne d’origine et la chaîne de destinataire.\cite{EthereumMechanism}
|
||||
|
||||
@ -17,13 +17,14 @@ Il existe un grand nombre de \textit{bridges}, chacun avec leurs propres spécif
|
||||
|
||||
|
||||
Les \textit{Trusted Bridges} sont vérifiés de manière externe car ils utilisent un ensemble de vérificateurs tiers pour transmettre des données entre les chaînes. Ils ont pour avantage leur rapidité, leur moindre coût et la facilité d'échange avec tous les types de données acceptés par les \textit{\gls{blockchain}s}. Cependant cela est au détriment de la sécurité puisqu'elle dépend ici des vérificateurs du \textit{bridge} en perdant la meilleure sécurisation des vérificateurs de la chaîne.\cite{EthereumBridges}
|
||||
% Les \textit{Trusted Bridges} sont vérifiés de manière externe car ils utilisent un ensemble de vérificateurs tiers pour transmettre des données entre les chaînes. Ils ont pour avantage leur rapidité, leur moindre coût et la facilité d'échange avec tous les types de données acceptés par les \textit{blockchains}. Cependant cela est au détriment de la sécurité puisqu'elle dépend ici des vérificateurs du \textit{bridge} en perdant la meilleure sécurisation de la chaîne source.\cite{EthereumBridges}
|
||||
|
||||
Les \textit{Trustless Bridges} sont désignés comme \textit{trustless} car ils dépendent des chaînes dont ils font l’intermédiaire pour transférer des données ou des \gls{actif}s. Par conséquent leur niveau de sécurité est égal à celui des \textit{\gls{blockchain}s} et il n’est pas nécessaire de faire confiance à un ensemble de vérificateurs tiers (contrairement aux autres \textit{bridges}). Pour cette raison, ils sont reconnus comme étant plus fiables que les \textit{trusted bridges}.\cite{EthereumBridges}\\
|
||||
|
||||
|
||||
Les \textit{bridges} peuvent également être distingués en fonction de leur type de vérification. Les plus connus sont la vérification native, externe et locale.\cite{InteroperabilityBhuptani} \\
|
||||
|
||||
La vérification native commence par l’utilisation d’un \textit{light client}\cite{NomadDocsNative}. Un client léger est un logiciel permettant de connecter les noeuds des \textit{\gls{blockchain}s} entre elles. Il est codé comme un \textit{\gls{smart contract}} puis est employé de la chaîne de l'expéditeur vers la machine virtuelle de la chaîne destinataire. Si les vérificateurs de données de la chaîne de l'expéditeur sont honnêtes (c’est-à-dire qu’ils n’agissent pas de manière malveillant en laissant passer une quelconque erreur ou fraude) alors le client léger est vu comme véridique par la chaîne réceptionnant les \gls{actif}s ou données et peut être utilisé de manière bilatérale.
|
||||
La vérification native commence par l’utilisation d’un \textit{light client}\cite{NomadDocsNative}. Un client léger est un logiciel permettant de connecter les noeuds des \textit{\gls{blockchain}s} entre elles. Il est codé comme un \textit{\gls{smart contract}} puis est employé de la chaîne de l'expéditeur vers la machine virtuelle de la chaîne destinataire. Si les vérificateurs de données de la chaîne de l'expéditeur sont honnêtes (c’est-à-dire qu’ils n’agissent pas de manière malveillant) alors le client léger est vu comme véridique par la chaîne réceptionnant les \gls{actif}s ou données et peut être utilisé de manière bilatérale.
|
||||
Un avantage de cette solution est qu’elle est reconnue comme étant celle reposant le moins sur la confiance parmi celles existantes car les chaînes ne se fient qu’à leurs propres vérificateurs pour effectuer le \textit{bridge}. Un autre bénéfice de ce mécanisme est le fait qu’il n’utilise pas de vérificateurs tiers entre les deux \textit{\gls{blockchain}s} et donc la sécurité dépend de la sécurité des \textit{\gls{blockchain}s} elles-même (ce qui est avantageux si elles sont forcément sécurisées comme la chaîne d’Ethereum par exemple).
|
||||
Un désavantage de cette méthode est que le client léger doit être adapté aux consensus des chaînes auquelles il est attaché ce qui le rend inutilisable avec des chaînes différentes. Le client léger nécessite également de la maintenance en cas de changement des règles consensus (utilisées pour valider les transactions). Un autre inconvénient découlant du fait que le client léger est programmé de manière spécifique est que ce dernier n’est donc pas réutilisable. \\
|
||||
\begin{figure}[h!]
|
||||
@ -33,6 +34,17 @@ La vérification native commence par l’utilisation d’un \textit{light client
|
||||
\label{fig:NativeVerif}
|
||||
\end{figure}
|
||||
|
||||
\pagebreak
|
||||
|
||||
La vérification externe consiste en un ensemble de vérificateurs n’appartenant pas aux \textit{\gls{blockchain}s} relayant les données entre les deux extrémités du \textit{bridge}. Pour se faire, un certains nombre de vérificateurs doivent signer un message provenant de la chaîne d’envoi pour que le chaîne destinataire le reconnaisse comme valide. Par exemple, pour le \textit{bridge} Wormhole 13 vérificateurs sur 19 doivent avoir signé\cite{NomadDocsExternal}. Ce concept est une primitive cryptographique (algorithme cryptographique de bas niveau servant de base à un système de sécurité informatique) nommée système de signature à seuil (désignée par TSS pour \textit{Threshold Signature Scheme})\cite{BinanceTSS}.
|
||||
Contrairement à la vérifications native, les \textit{bridges} vérifiés de manière externe sont faciles à développer, peuvent être réutilisés sans problèmes et leur maintenance coûte peu. Le désavantage conséquent de cette méthode est que la sécurité dépend des vérificateurs tiers du pont ce qui peut fragiliser le système car ils sont généralement moins sécurisés que ceux des \textit{\gls{blockchain}s}. \\
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[scale=0.50]{centralisation/imagesBridges/DiagrammeVerifExterne.png}
|
||||
\caption{Représentation de la vérification externe.}
|
||||
\label{fig:ExternalVerif}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\stackunder{
|
||||
@ -72,11 +84,11 @@ Les \textit{bridges trustless} utilisent des \textit{\gls{smart contract}s} lors
|
||||
Un \textit{\gls{smart contract}} étant un script écrit par un développeur, il est possible que certaines erreurs puissent s’être glissées dans le code par inadvertance ou bien qu’il existe des failles dans le programme permettant aux attaquants de le détourner pour un profit personnel.
|
||||
Pour minimiser ce type de risques, il est recommandé d’effectuer des audits sur les \textit{bridges.} \\
|
||||
|
||||
Une faiblesse spécifique des \textit{bridges trusted} repose sur le fait que les utilisateurs doivent léguer le contrôle de leurs \gls{actif}s et faire confiance aux vérificateurs externes aux \gls{blockchain}s. Sauf que dans certains cas, ces derniers peuvent coopérer pour tromper les utilisateurs en récupérant leurs \gls{actif}s puis en disparaissant comme dans les \textit{rug pull}\cite{EthereumRisks}. Ce modèle d’escroquerie peut être scindé en deux catégorie : les \textit{hard rug pull} et les \textit{soft rug pull}\cite{Hacken}. Le premier cas est basé sur un piège présent dans le code d’un \textit{\gls{smart contract}} empêchant les utilisateurs d’utiliser ou revendre les \gls{actif}s frappés, seul le fraudeur en a le droit. Il peut donc en toute tranquillité revendre les \gls{actif}s et récupérer l’argent. En revanche, pour les \textit{soft rug pull}, les utilisateurs ne sont pas coincés avec des \gls{actif}s verrouillés mais les fraudeurs utilisent des techniques psychologiques. En effet, les escrocs rendent attirant leur projet pour que les clients investissent et hésitent à se retirer par peur de perte leur investissent (souvent de taille conséquent) puis les créateurs de la fraude disparaissent avec leurs \gls{actif}s.\\
|
||||
Une faiblesse spécifique des \textit{bridges trusted} repose sur le fait que les utilisateurs doivent léguer le contrôle de leurs \gls{actif}s et faire confiance aux vérificateurs externes aux \gls{blockchain}s. Sauf que dans certains cas, ces derniers peuvent coopérer pour tromper les utilisateurs en récupérant leurs \gls{actif}s puis en disparaissant comme dans les \textit{rug pull}\cite{EthereumRisks}. Ce modèle d’escroquerie peut être scindé en deux catégorie : les \textit{hard rug pull} et les \textit{soft rug pull}\cite{Hacken}. Le premier cas est basé sur un piège présent dans le code d’un \textit{\gls{smart contract}} empêchant les utilisateurs d’utiliser ou revendre les \gls{actif}s frappés, seul le fraudeur en a le droit. Il peut donc en toute tranquillité revendre les \gls{actif}s et récupérer l’argent. En revanche, pour les \textit{soft rug pull}, les utilisateurs ne sont pas coincés avec des \gls{actif}s verrouillés mais les fraudeurs utilisent des techniques psychologiques. En effet, les escrocs rendent attirant leur projet pour que les clients investissent et hésitent à se retirer par peur de perdre leur investissent (souvent de taille conséquent) puis les créateurs de la fraude disparaissent avec leurs \gls{actif}s.\\
|
||||
|
||||
Comme vu dans la section présentant les différentes méthodes d’échange des \textit{bridges}, ces derniers frappent les \gls{actif}s désirés sur la chaîne destinataire. Certains attaquants peuvent profiter de ce mécanisme de frappe pour effectuer ce qu’on appelle une \textit{Infinite Mint Attack}.\cite{ChainLinkRisks} Cette attaque peut se résumer à un \textit{hacker} générant un nombre élevé d’\gls{actif}s en utilisant une faille d’un \textit{bridge} sans verrouiller ou brûler d’\gls{actif}s sur sa \textit{\gls{blockchain}}. Suite à cela, l’individu réintroduit ces \gls{actif}s sur le marché ce qui fait violemment baisser leur coût ce qui engendre un risque financier systémique.\\
|
||||
|
||||
Les \textit{\gls{blockchain} Bridges} sont devenus un outil indispensable des échanges centralisés très rapidement, mais il ne faut pas oublier que ces protocoles sont relativement récents. Créés par de petites \gls{blockchain}s comme Syscoin et NEAR Protocol dans le but de rentre leurs chaînes interopérables avec les applications décentralisées d’Ethereum, les premiers bridges datent de 2020\cite{Bitstamp}. Par conséquent, nous ne connaissons pas encore le comportement des \textit{bridges} lorsqu’ils font face à des scénarios sortants de la norme comme des attaques réseaux, un retour en arrière sur les transactions d’une \gls{blockchain} (souvent désigné par le terme \textit{rollback}) ou bien pendant une congestion du réseau. Ces zones d’incertitudes peuvent donc être une source de risques. \\
|
||||
Les \textit{\gls{blockchain} Bridges} sont très rapidement devenus un outil indispensable des échanges centralisés, mais il ne faut pas oublier que ces protocoles sont relativement récents. Créés par de petites \gls{blockchain}s comme Syscoin et NEAR Protocol dans le but de rentre leurs chaînes interopérables avec les applications décentralisées d’Ethereum, les premiers bridges datent de 2020\cite{Bitstamp}. Par conséquent, nous ne connaissons pas encore le comportement des \textit{bridges} lorsqu’ils font face à des scénarios sortants de la norme comme des attaques réseaux, un retour en arrière sur les transactions d’une \gls{blockchain} (souvent désigné par le terme \textit{rollback}) ou bien pendant une congestion du réseau. Ces zones d’incertitudes peuvent donc être une source de risques. \\
|
||||
|
||||
Un autre facteur portant atteinte à la sécurité des \textit{bridges} est le fait que certains ont leur code en \textit{open source} dans une démarche de transparence et d’envie d’instaurer une relation de confiance avec les utilisateurs. Malheureusement cela donne l’occasion aux personnes malveillantes de mieux comprendre le fonctionnement du \textit{bridge} et donc de pouvoir l’attaquer. L’attaque Wormhole est un exemple connu d’attaque exploitant cette faiblesse.
|
||||
|
||||
@ -91,9 +103,9 @@ Un autre facteur portant atteinte à la sécurité des \textit{bridges} est le f
|
||||
|
||||
\subsection{Le trilemme de l’interopérabilité}
|
||||
|
||||
Malgré l’existence de plus d’une centaine de \textit{bridges} différents, les développeurs et les utilisateurs voulant utiliser un \textit{bridge} doivent faire des concessions lors de leur choix vis-à-vis des trois notions de \textit{trustless}, d’extensibilité (\textit{extensible}) et généralisation (\textit{generalizable}).\\
|
||||
Malgré l’existence de plus d’une centaine de \textit{bridges} différents, les développeurs et les utilisateurs voulant utiliser un \textit{bridge} doivent faire des concessions lors de leur choix vis-à-vis des trois notions de \textit{trustless}, d’extensibilité (\textit{extensible}) et de généralisation (\textit{generalizable}).\\
|
||||
|
||||
Le mot trustless peut être traduit par «sans confiance» faisant allusion à la sécurité. Si un \textit{bridge} est caractérisé comme \textit{trustless}, cela signifie que celui-ci possède un niveau équivalent à celui d’une ou des chaînes sous-jacentes. La notion d’extensibilité signifie que le \textit{bridge} est compatible un grand nombre de chaînes.
|
||||
Le mot trustless peut être traduit par «sans confiance» faisant allusion à la sécurité. Si un \textit{bridge} est caractérisé comme \textit{trustless}, cela signifie que celui-ci possède un niveau équivalent à celui d’une ou des chaînes sous-jacentes. La notion d’extensibilité signifie que le \textit{bridge} est compatible avec un grand nombre de chaînes.
|
||||
Un \textit{bridge} respecte la notion de généralisation s’il est capable d'échanger n’importe quel type de données accepté par les deux chaînes.\\
|
||||
|
||||
Pour illustrer ces termes, il est possible de les appliquer aux types de vérification appartenant aux \textit{bridges}. La vérification locale respecte les notions d’extensibilité et de \textit{trustless} puisque qu'elle est applicable sur tous les \textit{bridges} peu importe les chaînes reliées et la sécurité dépend de la chaîne la plus faible donc la sécurité du \textit{bridge} est bien équivalente à l’une des chaînes.
|
||||
@ -104,14 +116,14 @@ La vérification externe ne respecte pas la notion de \textit{trustless} cependa
|
||||
|
||||
\subsubsection{Une solution optimiste}
|
||||
|
||||
Une solution proposée pour résoudre ce trilemme est un \textit{optimistic bridge}(\textit{bridge} optimiste) nommé vis-à-vis de sa vérification pourtant le même nom\cite{OptimisticBhuptani}. En effet, contrairement aux \textit{bridges} vérifiés de manière native, locale ou externe, la vérification optimiste dépend de l’utilisation d’une latence lors de la confirmation du transfert des \gls{actif}s entre les \textit{\gls{blockchain}s}. Cela priorise donc la sécurité au détriment de la vivacité, puisque les transactions sont par conséquent plus lentes mais sécurisées car le \textit{bridge} est \textit{trustless}. \\
|
||||
Une solution proposée pour résoudre ce trilemme est un \textit{optimistic bridge}(\textit{bridge} optimiste) nommé vis-à-vis de sa vérification portant le même nom\cite{OptimisticBhuptani}. En effet, contrairement aux \textit{bridges} vérifiés de manière native, locale ou externe, la vérification optimiste dépend de l’utilisation d’une latence lors de la confirmation du transfert des \gls{actif}s entre les \textit{\gls{blockchain}s}. Cela priorise donc la sécurité au détriment de la vivacité, puisque les transactions sont par conséquent plus lentes mais sécurisées car le \textit{bridge} est \textit{trustless}. \\
|
||||
|
||||
Voici plus en détails le déroulement du processus de vérification optimiste d’un \textit{bridge}.
|
||||
Ceci commence par l’envoi de données de la part d’un utilisateur ou d’une application décentralisée vers la \textit{\gls{blockchain}} native par le biais d’une fonction contrat.
|
||||
Ensuite un agent (une node) appelé \textit{updater} (vérificateur en français) a pour rôle de vérifier la transaction puis de l’inscrire dans la \textit{\gls{blockchain}} initiale. Pour cela, le vérificateur signe la racine d’un arbre de Merkle contenant les données envoyées précédemment et l’intègre à la chaîne. Il relie également son collatéral (fonds servant de garantie en cas de fraude) à cette dernière.
|
||||
Suite à cela, n’importe quel système de relais peut lire la racine signée sur la chaîne originelle et l’inscrire sur une ou plusieurs chaînes destinataire. Cette action déclenche alors une latence de trente minutes pendant laquelle un observateur peut signaler et prouver une fraude effectuée par la chaîne native ce qui déconnectera la communication avec la chaîne destinataire.
|
||||
|
||||
Deux scénarios sont alors possibles. Premier cas, si aucun observateur ne se manifeste, les données de la transaction sont finalisées et alors traitées par une application. Cela est généralement réalisé par un fournisseur de services (ayant le rôle de processeur) inscrivant une preuve de Merkle des données dans le \textit{bridge} puis les données servent à appeler une fonction contrat sur la chaîne destinataire. Deuxième cas, un observateur prouve une fraude pendant les trente minutes accordées. Le vérificateur ayant fraudé est pénalisé par la perte de son collatéral et l’observateur le reçoit.
|
||||
Deux scénarios sont alors possibles. Premier cas, si aucun observateur ne se manifeste, les données de la transaction sont finalisées et alors traitées par une application. Cela est généralement réalisé par un fournisseur de services (ayant le rôle de processeur) inscrivant une preuve de Merkle des données dans le \textit{bridge}. Puis les données sont appelées dans une fonction contrat sur la chaîne destinataire. Deuxième cas, un observateur prouve une fraude pendant les trente minutes accordées. Le vérificateur ayant fraudé est pénalisé par la perte de son collatéral et l’observateur le reçoit.
|
||||
|
||||
\subsubsection{Possibles faiblesses de l’optimisme et leurs solutions}
|
||||
|
||||
@ -121,7 +133,7 @@ Les deux acteurs principaux ayant les moyens de nuire au bon fonctionnement du \
|
||||
|
||||
Le premier cas impliquant le vérificateur se nommant \textit{Updater Fraud} (Fraude du vérificateur) fut déjà mentionné lors de la présentation du fonctionnement du \textit{bridge} optimiste. Ce dernier repose sur le fait que toute transaction doit passer par le vérificateur et que par conséquent toute fraude est originaire de ce dernier. Sinon si cela venait d’un autre participant, le vérificateur n’aurait alors pas accepté la transaction. C’est pourquoi, lors de l’intervention d’un observateur prouvant une fraude, le vérificateur est sanctionné par la perte de son collatéral. \\
|
||||
|
||||
La seconde faiblesse liée aux vérificateurs est un \textit{Updater DoS} ou déni de services de la part du vérificateur. En effet, il est possible que le processus soit interrompu si un valide arrête de signer les racines des arbres de Merkle empêchant l'échange inter-chaînes de se produire.
|
||||
La seconde faiblesse liée aux vérificateurs est un \textit{Updater DoS} ou déni de services de la part du vérificateur. En effet, il est possible que le processus soit interrompu si un validateur arrête de signer les racines des arbres de Merkle empêchant l'échange inter-chaînes de se produire.
|
||||
Une solution a été implémentée pour palier à cela comme la mise en place d’un système de basculement (failover) avec la présence de plusieurs vérificateurs sur une même chaîne afin de pouvoir prendre le relai en cas de manque de réponse de la part de celui étant rattaché au transfert. Pour éviter que ce scénario se reproduise fréquemment le vérificateur ayant manqué son tour lors de la signature (que cela soit accidentel ou voulu) est pénalisé par le retrait de son collatéral. \\
|
||||
|
||||
Maintenant que les possibles obstacles au bon fonctionnement du \textit{bridge} liés au vérificateur ont été mis en lumière, il est également possible que l’observateur ait un comportement malveillant. Effectivement, malgré l’absence de tromperie (puisque le vérificateur remplit son rôle), l’observateur peut abuser du mécanisme de déclaration de fraude pour impacter le bon déroulement du procédé. \\
|
||||
|
||||
@ -3,7 +3,7 @@ Pour conclure sur les échanges centralisés, nous avons pu voir que le fonction
|
||||
En effet, les protocoles employés ne sont pas ou peu explicités, nous avons trouvé peu de documentation technique au cours de nos recherches.
|
||||
La majeure partie de la documentation que nous avons pu trouver concernant les plate-formes d'échanges centralisé sont à destination des utilisateurs de ces plate-formes, donc à des personnes n'ayant pas forcément un bagage de connaissance dans les \textit{\gls{blockchain}s}.
|
||||
C'est pour cela que nombreuses de nos sources concernant les plate-formes centralisés sont issues de réseaux sociaux ou d'articles web à destination de lecteurs spécialisés dans le domaine.
|
||||
La solution centralisée au fonctionnement le plus ouvert au public que nous avons trouvé est \textit{Wormhole}, il s'avère que ce protocole à aussi été victime d'une attaque de grande envergure.
|
||||
La solution centralisée au fonctionnement le plus ouvert au public que nous avons trouvé est \textit{Wormhole}, il s'avère que ce protocole à aussi été victime d'une attaque de grande envergure. \\
|
||||
Nous pouvons ainsi nous questionner sur la présence de l'intermédiaire de confiance dans l'échange centralisé.
|
||||
En effet, la majeure partie des attaques observés sur des \textit{Bridges} ou plus généralement sur des protocoles d'échanges centralisés, résultent de problèmes d'implémentation dans le code de ces protocoles.
|
||||
Le tiers de confiance est donc un point d'entrée pour les pirates vers les \gls{actif}s des utilisateurs.
|
||||
|
||||
@ -26,7 +26,6 @@ Combiné à l'adresse du contrat de l'émetteur et à l'identifiant de la chaîn
|
||||
correspondant peut être récupéré auprès d'un nœud du réseau de gardiens.\\
|
||||
Un message Wormhole est vérifié grâce à la fonction \textit{parseAndVerifyVAA()} prenant en entrée le message.
|
||||
Selon la validité de l'entrée, la fonction retourne en sortie le \textit{payload} ou une exception.
|
||||
\newpage
|
||||
|
||||
VAA \cite{wormholeVAA} est la primitive de messagerie de base de Wormhole. Un VAA contient une en-tête
|
||||
ainsi qu'un \textit{body}. L'en-tête contient l'index des gardiens ayant signés le message et la collection des signatures.
|
||||
@ -51,7 +50,7 @@ B est légitime.
|
||||
|
||||
\subsubsection{Gardiens}
|
||||
|
||||
Un gardien \cite{wormholeGuardian} est une autorité de confiance qui a comme de rôle valider
|
||||
Un gardien \cite{wormholeGuardian} est une autorité de confiance qui a comme rôle de valider
|
||||
(par une signature) le \textit{payload} contenu dans un VAA.
|
||||
Comme évoqué précédemment, le réseau de gardiens observe tous les messages \textit{crosschain} via la
|
||||
surveillance des \textit{core contracts}.
|
||||
@ -74,11 +73,10 @@ devenu populaire grâce à l'absence de tels autorités. Wormhole justifie la d
|
||||
système \cite{wormholeGuardian} par la présence de plusieurs parties (et non d'un seul) dans le contrôle du réseau.
|
||||
Selon notre analyse, la décentralisation résulte de l'absence d'un ou plusieurs tier(s) de confiance lorsque deux parties
|
||||
souhaitent réaliser une transaction.
|
||||
\newpage
|
||||
|
||||
\subsubsection{Relais}
|
||||
|
||||
Un relai \cite{wormholeRelayer} est un processus qui délivre un ou plusieurs VAA(s) à une destination.
|
||||
Un relai \cite{wormholeRelayer} est un processus qui délivre un VAA vers une destination.
|
||||
Les relais ne sont ni de confiance, ni privilégiés, ils écoutent directement le réseau de gardiens
|
||||
via l'intermédiaire d'un processus espion. Ces relais ne peuvent pas compromettre l'intégrité d'un VAA
|
||||
car une altération serait détectée lors du processus de vérification des signatures. Cependant, il n'est
|
||||
|
||||
@ -32,16 +32,33 @@ difficile de creer un modèles économique autour de ces solutions.
|
||||
\subsection{Générale}
|
||||
Pour conclure le sujet, nous constatons un certain flou entre ce qui est considéré comme centralisé et décentralisé.
|
||||
Durant nos recherches nous avons pris comme referentiel une certaine définition de ce que nous considéreons comme
|
||||
centralisé ou décentralisé. Il nous parait important de souligner que l'usage de ces termes présentent un argument marketing
|
||||
centralisé ou décentralisé. Il nous parait important de souligner que l'usage de ces termes présente un argument marketing
|
||||
important, et beaucoup d'acteurs remanient la définition de décentralisé pour correspondre avec leurs produits.
|
||||
|
||||
% \begin{table}[h!]
|
||||
% \centering
|
||||
% \caption{Tableau Récapitulatif}
|
||||
% \begin{tabular}{|l|l|l|}
|
||||
% \hline
|
||||
% & Centralisé & Décentralisé \\ \hline
|
||||
% Avantages & \begin{tabular}[c]{@{}l@{}}Facilité d'utilisation\\ Popularité\\ Variétés des produits financiers\end{tabular} & \begin{tabular}[c]{@{}l@{}}Fiabilité et Sécurité\\ Maitrise des données\\ Frais de transactions\end{tabular} \\ \hline
|
||||
% Inconvénients & \begin{tabular}[c]{@{}l@{}}Sécurité et Fiabilité relative à la plateforme\\ Frais de transactions\\ Opacité des plateformes\\ Dépendance aux tiers\end{tabular} & \begin{tabular}[c]{@{}l@{}}Complexité d'implémentation\\ Difficulté d'usage\end{tabular} \\ \hline
|
||||
% \end{tabular}
|
||||
% \end{table}
|
||||
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
\caption{Tableau Récapitulatif}
|
||||
\begin{tabular}{|l|l|l|}
|
||||
\hline
|
||||
& Centralisé & Décentralisé \\ \hline
|
||||
Avantages & \begin{tabular}[c]{@{}l@{}}Facilité d'utilisation\\ Popularité\\ Variétés des produits financiers\end{tabular} & \begin{tabular}[c]{@{}l@{}}Fiabilité et Sécurité\\ Maitrise des données\\ Frais de transactions\end{tabular} \\ \hline
|
||||
Inconvénients & \begin{tabular}[c]{@{}l@{}}Sécurité et Fiabilité relative à la plateforme\\ Frais de transactions\\ Opacité des plateformes\\ Dépendance aux tiers\end{tabular} & \begin{tabular}[c]{@{}l@{}}Complexité d'implémentation\\ Difficulté d'usage\end{tabular} \\ \hline
|
||||
\begin{tabular}{|l|l|c|c|l|}
|
||||
\hline
|
||||
& & \multicolumn{1}{l}{Décentralisation} & \multicolumn{1}{l}{Accessibilité} & Rèf \\ \hline
|
||||
& Plateformes d'échanges & \cellcolor[HTML]{FD6864}$---$ & \cellcolor[HTML]{9AFF99}$+++$ & \\ \cline{2-5}
|
||||
\multirow{-2}{*}{Centralisé} & Blockchains Bridges & \cellcolor[HTML]{FD6864}$-$ & \cellcolor[HTML]{9AFF99}$++$ & \\ \hline
|
||||
& Relay & \cellcolor[HTML]{9AFF99}$+$ & \cellcolor[HTML]{FD6864}$--$ & \\ \cline{2-5}
|
||||
& Sidechains & \cellcolor[HTML]{9AFF99}$++$ & \cellcolor[HTML]{FD6864}$--$ & \\ \cline{2-5}
|
||||
& Reserves de Liquidités & \cellcolor[HTML]{9AFF99}$+++$ & \cellcolor[HTML]{9AFF99}$+++$ & \\ \cline{2-5}
|
||||
& HTLC & \cellcolor[HTML]{9AFF99}$+++$ & \cellcolor[HTML]{FD6864}$---$ & \\ \cline{2-5}
|
||||
\multirow{-5}{*}{Décentralisé} & Off-chain & \cellcolor[HTML]{9AFF99}$++$ & \cellcolor[HTML]{9AFF99}$+$ & \\ \hline
|
||||
\end{tabular}
|
||||
\end{table}
|
||||
\end{table}
|
||||
@ -29,8 +29,8 @@ Lors d'un échange atomique les HTLC vont être utilisés de manière centrale c
|
||||
Si nous nous penchons sur le déroulement d'un échange atomique à 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 Les deux parties échangent les informations nécessaires pour effectuer une transaction sur la \textit{\gls{blockchain}} de l'autre partie.
|
||||
\item Les deux parties vérifient l'exactitude des informations reçues et signent la transaction.
|
||||
\item Ils échangent les informations nécessaires pour effectuer une transaction sur la \textit{\gls{blockchain}} de l'autre partie.
|
||||
\item Ils vérifient l'exactitude des informations reçues et signent la transaction.
|
||||
\item Les événements sont envoyés sur les \textit{\gls{blockchain}s} respectives.
|
||||
\item Les transactions sont confirmés par les \textit{\gls{blockchain}s} respectives et les fonds sont débloqués.
|
||||
\end{enumerate}
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
\subsection{Etat de l'art}
|
||||
\input{decentralisation/etat_art.tex}
|
||||
% \subsection{Etat de l'art}
|
||||
% \input{decentralisation/etat_art.tex}
|
||||
|
||||
\subsection[Relay]{Relay}
|
||||
\input{decentralisation/relay.tex}
|
||||
|
||||
@ -10,7 +10,7 @@ Ils sont des échanges d’\gls{actif}s internes au réseau et ont donc leurs pr
|
||||
\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.
|
||||
Tout cela se fait dans un objectif bien précis qui est de garder le maximum de sécurité/fiabilité de la \textit{\gls{blockchain}} mère tout en essayant d'améliorer la vitesse d'échange et les frais de transaction.
|
||||
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.
|
||||
|
||||
\subsubsection{Le réseau lightning}
|
||||
@ -45,7 +45,7 @@ Alice va donc ouvrir un portefeuille multi-signature\footnote{Portefeuille qui n
|
||||
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.
|
||||
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 envoyer sur la \textit{\gls{blockchain}} principale.
|
||||
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.\\ \\
|
||||
Enfin il existe aussi une autre caractéristique intéressante du réseau Lightning: le \textit{channel hopping}.
|
||||
Cette propriété permet de mettre en place une transitivité entre les parties du réseau. Par exemple si Alice a déjà échangé avec Bob et Bob à déjà échangé avec Carol alors Alice pourra échanger avec Carol et vice-versa.
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
\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
|
||||
remporter une comission à chaque transaction \cite{jensen2021introduction, belchior2022survey, augustin2022yield}.
|
||||
Les fournisseurs de liquidités déposent des fonds dans une résreve de liquidité et reçoivent des jetons
|
||||
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
|
||||
retirer des fonds de la réserve. Les réserves de liquidité sont un concept clé de l’écosystème DeFi. Il permettent la mise en place d'échangeurs décentralisés
|
||||
qui donne la possibilité aux utilisateurs d’échanger des actifs sans avoir besoin d’un intermédiaire centralisé. \\
|
||||
@ -35,12 +35,8 @@ de liquidités sont des attaques dans lesquelles un utilisateur manipule le prix
|
||||
réserve. Cela peut entraîner une baisse significative du prix de l’actif et des pertes pour les fournisseurs de liquidités. De plus, les réserves de liquidités
|
||||
peuvent être affectés par des problèmes de liquidité. Si une réserve de liquidités n’a pas suffisamment de liquidités, il peut être difficile pour les
|
||||
utilisateurs d’acheter ou de vendre des actifs sur la plateforme. Enfin, les réserves de liquidités peuvent être affectés par des problèmes de sécurité. Si
|
||||
une réserve de liquidités est compromis, les utilisateurs peuvent perdre leurs fonds. \\
|
||||
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 contrat intelligent pour une réserve de liquidité en lien avec
|
||||
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.
|
||||
|
||||
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 gagner des frais de transaction en retour. Les fournisseurs de liquidités déposent des fonds dans une résreve 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 retirer des fonds de la réserve. Les réserves de liquidité sont un concept clé de l’écosystème DeFi. Il permettent la mise en place d'échangeurs décentralisés qui donne la possibilité aux utilisateurs d’échanger des \gls{actif}s sans avoir besoin d’un intermédiaire centralisé. \\
|
||||
A chaque échange réalisé via la réserve, les possesseurs de liquidités recoivents des récompenses qui sont les frais d'échanges des utilisateurs. Les récompenses sont généralement des jetons de gouvernance ou des jetons de protocole. Les réserves de liquidité se régulent ainsi en ajustant les frais de transaction en fonction de l’offre et de la demande. Si la demande pour une réserve de liquidité particulier est élevée, les frais de transaction augmentent pour encourager les fournisseurs de liquidités à déposer plus de fonds dans la réserve. Si la demande est faible, les frais de transaction diminuent pour encourager les utilisateurs à échanger des \gls{actif}s sur la réserve de liquidité. \\
|
||||
Une réserve de liquidité repose sur un \gls{smart contract} et bénéficie ainsi de la décentralisation et de la sécurité de la \gls{blockchain} sur laquelle il repose.
|
||||
sur ses jetons.
|
||||
@ -22,7 +22,7 @@ dans le contrat. Ce qui offre une possibilité d'opérabilité unidirectionnelle
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{tBTC}
|
||||
Un exemple de relay est le projet tBTC, qui permet aux utilisateurs d’échanger des bitcoins contre des
|
||||
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
|
||||
|
||||
@ -11,7 +11,7 @@
|
||||
}
|
||||
|
||||
\newglossaryentry{actif}{
|
||||
name = actif / Jeton,
|
||||
name = actif,
|
||||
description= {Dans le contexte de la \textit{blockchain}, un actif ou jeton peut être matériel (une maison, une voiture, de l’argent, un terrain) ou immatériel (propriété intellectuelle, brevets, droits d’auteur, marque).
|
||||
Tout ce qui a de la valeur est traçable et échangeable sur un réseau de blockchain}
|
||||
}
|
||||
|
||||
@ -5,7 +5,7 @@ permettant ainsi aux utilisateurs de transférer des \gls{actif}s d’une \texti
|
||||
un échange centralisé. Cela peut être très utile pour les utilisateurs qui souhaitent échanger des \gls{actif}s qui
|
||||
ne sont pas disponibles sur leur \textit{\gls{blockchain}} d’origine ou qui souhaitent simplement utiliser une \textit{\gls{blockchain}}
|
||||
différente pour des raisons de sécurité ou de confidentialité. Cependant, les échanges d’\gls{actif}s entre différentes
|
||||
\textit{\gls{blockchain}s} posent des problèmes de sécurité et de confiance car il est difficile de garantir que les \gls{actif}s seront
|
||||
\textit{\gls{blockchain}s} posent des problèmes de sécurité et de confiance car il est difficile de garantir que les \gls{actif}s soient
|
||||
transférés en toute sécurité et que les utilisateurs ne seront pas victimes d’une fraude ou d’une arnaque. Il est
|
||||
donc important de mettre en place des solutions sécurisées et fiables pour les échanges d’\gls{actif}s entre différentes
|
||||
\textit{\gls{blockchain}s}.
|
||||
@ -23,10 +23,10 @@ chaque bloc d’une \textit{\gls{blockchain}} et pour vérifier si une transacti
|
||||
Actuellement, rare sont les \textit{\gls{blockchain}s} supportant de manière native le transfert d'\gls{actif}s entre elles. Ainsi les solutions
|
||||
de \textit{Swapping} actuels passent par des applications tierces. Bien que la \textit{\gls{blockchain}} soit une technologie que nous
|
||||
pouvons considérer comme décentralisée, il est néanmoins possible de venir y connecter des interfaces tierces plus ou
|
||||
moins décentralisées dans le but d'y ajouter des fonctionnalités. Ce sont ces solutions que nous allons présenter durant ce rapport. \\
|
||||
moins centralisées dans le but d'y ajouter des fonctionnalités. Ce sont ces solutions que nous allons présenter durant ce rapport. \\
|
||||
Il devient donc nécessaire de définir ce que nous entendons par centralisé et décentralisé. Ainsi nous allons considérer comme
|
||||
centralisé tout système où une autorité centrale contrôle les décisions et les actions.
|
||||
Il y a une hiérarchie entre les pairs et un groupe fermé d’individus ou un individu seul représente l’intermédiaire. \\
|
||||
Il y a une hiérarchie entre les pairs, et un groupe fermé d’individus ou une seule entité représente l’intermédiaire. \\
|
||||
Nous considérons comme décentralisé tout système où il n’y a pas d’autorité centrale et où les décisions sont prises
|
||||
par un groupe de pairs. Dans ce système, il n’y a pas de hiérarchie entre les pairs et n'importe qui peut faire partie
|
||||
du réseau.
|
||||
|
||||
@ -1,29 +0,0 @@
|
||||
% makeindex style file created by the glossaries package
|
||||
% for document 'main' on 2023-4-3
|
||||
actual '?'
|
||||
encap '|'
|
||||
level '!'
|
||||
quote '"'
|
||||
keyword "\\glossaryentry"
|
||||
preamble "\\glossarysection[\\glossarytoctitle]{\\glossarytitle}\\glossarypreamble\n\\begin{theglossary}\\glossaryheader\n"
|
||||
postamble "\%\n\\end{theglossary}\\glossarypostamble\n"
|
||||
group_skip "\\glsgroupskip\n"
|
||||
item_0 "\%\n"
|
||||
item_1 "\%\n"
|
||||
item_2 "\%\n"
|
||||
item_01 "\%\n"
|
||||
item_x1 "\\relax \\glsresetentrylist\n"
|
||||
item_12 "\%\n"
|
||||
item_x2 "\\relax \\glsresetentrylist\n"
|
||||
delim_0 "\{\\glossaryentrynumbers\{\\relax "
|
||||
delim_1 "\{\\glossaryentrynumbers\{\\relax "
|
||||
delim_2 "\{\\glossaryentrynumbers\{\\relax "
|
||||
delim_t "\}\}"
|
||||
delim_n "\\delimN "
|
||||
delim_r "\\delimR "
|
||||
headings_flag 1
|
||||
heading_prefix "\\glsgroupheading\{"
|
||||
heading_suffix "\}\\relax \\glsresetentrylist "
|
||||
symhead_positive "glssymbols"
|
||||
numhead_positive "glsnumbers"
|
||||
page_compositor "."
|
||||
@ -7,6 +7,10 @@
|
||||
\usepackage{fullpage}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{biblatex}
|
||||
|
||||
\usepackage{multirow}
|
||||
\usepackage[table,xcdraw]{xcolor}
|
||||
|
||||
\usepackage{stackengine}
|
||||
\usepackage{listings}
|
||||
\usepackage{glossaries}
|
||||
@ -39,7 +43,15 @@
|
||||
Merci à M. TRAVERS Corentin et M. LABOUREL Arnaud pour la proposition de ce sujet et son encadrement.
|
||||
\end{remerciements}
|
||||
\begin{abstract}
|
||||
abstract
|
||||
Ces dernières années, un grand nombre de blockchains ont vu le jour, accompagnées d’un lot de problématiques.
|
||||
Parmi les questions les plus importantes figure celle des échanges entre ces blockchains.
|
||||
En effet le marché des cryptomonnaies augmente fortement et malheureusement toutes les blockchains ne sont pas forcément compatibles entre elles, ce qui crée une forte pression sur le marché actuel.
|
||||
Dans cet ouvrage, vous trouverez un résumé exhaustif des recherches menées sur les échanges cross-chain.
|
||||
Que ce soit en termes de protocoles ou bien d'implémentation plus techniques, nous avons essayé de regrouper le plus grand nombre d'exemples.
|
||||
Nous commencerons par les protocoles d’échanges centralisés qui sont les plus répandus grâce à leur facilité d'utilisation et leur rapidité.
|
||||
Mais ces protocoles sont souvent la source d'attaques ou bien même de failles, car le marché des échanges inter-blockchain est souvent rejoint par des entités n'ayant pas de connaissance en fiabilité.
|
||||
Ensuite nous continuerons par les protocoles d'échanges décentralisés qui représentent une bonne alternative aux échanges centralisés, car ils offrent une meilleure sécurité au détriment d'une complexité d'utilisation accrue.
|
||||
Vous allez donc pouvoir comprendre quels sont les avantages et les inconvénients de ces deux méthodes d'échanges de jetons inter-blockchain.
|
||||
\end{abstract}
|
||||
|
||||
\newpage
|
||||
|
||||
Reference in New Issue
Block a user