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 actifs numériques contre d'autres actifs numériques ou contre d'autres monnaies fiduciaires.
Ces plate-formes peuvent opérer sur des \textit{blockchains} publiques ou être dédiées à une utilisation en interne.
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.
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.
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 actifs 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, 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é.
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 actifs des utilisateurs.
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 actifs de l'utilisateurs sont traçables par les autorités.
Ce point signifie aussi que les \gls{actif}s de l'utilisateurs sont traçables par les autorités.
\subsubsection{Fonctionnement}
@ -23,14 +23,14 @@ Un ordre étant une demande d'un utilisateur visant à réaliser une opération
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.
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-actif souhaité lors d'un échange ou d'une vente. \\
ce dernier sera échangé contre le crypto-\gls{actif} souhaité lors d'un échange ou d'une vente. \\
Dans le cadre des échanges inter-blockchains, les plate-formes d'échanges utilisent des \textit{bridges} reliant les différentes \textit{blockchains}.
Dans le cadre des échanges inter-\gls{blockchain}s, les plate-formes d'échanges utilisent des \textit{bridges} reliant les différentes \textit{\gls{blockchain}s}.
Ces protocoles seront explicités dans la partie suivante.
Cependant, nous n'avons pas pu trouver de plus amples explications quant aux fonctionnements des plate-formes, notamment les protocoles précis utilisés lors des échanges.
Les documentations disponibles pour les plateformes d'échanges étant à destination des utilisateurs finaux.
Les \textit{blockchains} et leurs protocoles d'échanges ne sont pas exemptes d'attaques informatiques ou bien de défaillances.
Les \textit{\gls{blockchain}s} et leurs protocoles d'échanges ne sont pas exemptes d'attaques informatiques ou bien de défaillances.
Ces attaques peuvent cibler des portefeuilles (attaques sur des \textit{hot wallets}\footnote{portefeuille de cryptomonnaies en ligne, à différencier des \textit{Cold Wallets}, des portefeuilles hors lignes}) ou encore des \textit{bridges}.
Ce sont ces dernières qui nous ont intéressées dans le cadre de ce projet de recherche sur les échanges inter-blockchains.
Les bridges, comme explicité dans la partie dédiée du rapport, sont des protocoles permettant la circulation de données entre deux \textit{blockchains} différentes.\\
Nous avons, au cours de nos recherches, trouvés de nombreux cas d'attaques sur des protocoles d'échanges inter-blockchains.
Ce sont ces dernières qui nous ont intéressées dans le cadre de ce projet de recherche sur les échanges inter-\gls{blockchain}s.
Les bridges, comme explicité dans la partie dédiée du rapport, sont des protocoles permettant la circulation de données entre deux \textit{\gls{blockchain}s} différentes.\\
Nous avons, au cours de nos recherches, trouvés de nombreux cas d'attaques sur des protocoles d'échanges inter-\gls{blockchain}s.
De manière à illustrer les types d'attaques possibles et les points critiques de ces systèmes nous allons décrire deux attaques parmi les plus importantes : \textit{Wormhole} et \textit{Nomad}.
\subsubsection{Le cas Wormhole}
Nous vous avons présenté le protocole \textit{Wormhole} dans la partie précédente.
Le 2 Février 2022, une attaque exploite une erreur d'implémentation dans une \textit{Dapp} sur la chaîne Solana \cite{SolMed}\cite{SolRekt}.
Le 2 Février 2022, une attaque exploite une erreur d'implémentation dans une \textit{\gls{dApp}} sur la chaîne Solana \cite{SolMed}\cite{SolRekt}.
Pour se faire l'attaquant à réussi à contourner la vérification des signatures des gardiens en exploitant
une correction de bug ayant été publié sur le code source du projet mais n'étant pas encore effective en production.
Ainsi il à réussi à récupérer l'équivalent de 120 000 \textit{ETH} en \textit{whETH} (\textit{Wormhole ETH}).
@ -17,7 +17,7 @@ Lors d'un transfert de jetons d'une chaîne à une autre, plusieurs étapes sont
Après la formulation de la transaction, une fonction va se charger de récupérer les signatures des gardiens dans un \textit{SignatureSet}\footnote{Ensemble de signatures de gardiens}, ces dernières sont ensuite vérifiées.
Pour cela, une fonction nommée \texttt{verify\_signature} va appeler un programme de vérification de Solana permettant l'analyse du \textit{SignatureSet}.
L'appel à ce programme se fait de la manière suivante, en utilisant le nom \texttt{sysvarinstruction}\cite{SolGitError} dans la transaction.
Dès lors que les signatures sont validées, un \textit{VAA} peut être émis et transmis vers la \textit{blockchain} souhaitée. \\
Dès lors que les signatures sont validées, un \textit{VAA} peut être émis et transmis vers la \textit{\gls{blockchain}} souhaitée. \\
La transaction de l'attaquant étant frauduleuse, il n'aurait donc pas pu obtenir de signatures des gardiens.
Pour contourner cette étape de récupération des signatures la transaction de l'attaquant était dotée d'un \textit{SignatureSet} correspondant à une transaction antérieure.
Seulement, n'étant pas pour la bonne opération cet ensemble ne peut pas être approuvé par \texttt{verify\_signature}.
@ -28,10 +28,10 @@ Avec le \texttt{SignatureSet} ainsi validé, l'attaquant a pu générer un \tex
La correction de cette faille était contenue dans la mise à jour évoquée en début de paragraphe\cite{SolGitFixed}, permettant la vérification du programme appelé pour la vérification.
\subsubsection{Le cas Nomad}
Nomad est un protocole d'interopérabilité entre chaînes permettant de passer des actifs entre deux \textit{blockchains} différentes.
Nomad est un protocole d'interopérabilité entre chaînes permettant de passer des \gls{actif}s entre deux \textit{\gls{blockchain}s} différentes.
Pour fonctionner, ce protocole fait appel à des applications décentralisées opérant sur les chaînes du réseau.
Une première \textit{Dapp} appelée \textit{réplica} est déployée sur les \textit{blockchains} recevant les messages, elle fait office de "boite de réception".
Une seconde \textit{Dapp} appelée \textit{home} est déployé sur les \textit{blockchains} émettrices de message. \\
Une première \textit{\gls{dApp}} appelée \textit{réplica} est déployée sur les \textit{\gls{blockchain}s} recevant les messages, elle fait office de "boite de réception".
Une seconde \textit{\gls{dApp}} appelée \textit{home} est déployé sur les \textit{\gls{blockchain}s} émettrices de message. \\
Le 1\textsuperscript{er} août 2022 une attaque exploitant une erreur d'implémentation sur l'application \textit{Réplica} a engendré une perte de 190 millions de dollars en liquidité \cite{NomadMedium}\cite{NomadRekt}.
Cette attaque s'est déroulée après le déploiement d'une mise à jour, un moyen de contourner la vérification des signatures du message étant apparu.
En analysant l'application \textit{Réplica} après la mise à jour, nous pouvons voir que lors d'une initialisation, la racine des messages, appelée \texttt{\_commitedRoot}, est initialisée à $0$, ce signifiant que le message n'a pas encore été validé.
@ -54,7 +54,7 @@ En analysant l'application \textit{Réplica} après la mise à jour, nous pouvon
\end{lstlisting}
Dans les lignes précédentes nous observons cette affectation : \texttt{confirmAt[\_commitedRoot] = 1}, le rôle de cette ligne est de pré-approuver la racine d'un message.
Cette fonction est utilisée pour approuver le premier message lors du déploiement du contrat sur une \textit{blockchain}.
Cette fonction est utilisée pour approuver le premier message lors du déploiement du contrat sur une \textit{\gls{blockchain}}.
Or ici, la valeur de la racine à été initialisée a $0$, donc cette racine devient une racine valide pour la fonction de vérification des messages.
Seulement comme nous l'avons énoncé précédemment, $0$ est la valeur par défaut pour un message n'ayant pas encore été vérifié.
Ainsi, lors de l'émission d'un message par la fonction \texttt{process}, tout message non vérifié sera envoyé.
@ -81,19 +81,19 @@ Le contrat à été corrigé, dans une mise en ligne datant du 3 Septembre 2022,
%\subsubsection{DeFi hacklabs}
%Lors de nos recherches sur des attaques sur des protocoles inter-blockchains, nous avons découvert \textit{Web3sec}, un groupe de recherche centré sur la sécurité du web3.
%Lors de nos recherches sur des attaques sur des protocoles inter-\gls{blockchain}s, nous avons découvert \textit{Web3sec}, un groupe de recherche centré sur la sécurité du web3.
%Le groupe met à disposition des ressources indexés sur une page notion (en annexe) :
%\begin{itemize}
% \item Plusieurs dépots \textit{Github} pour étudier les attaques et apprendre les vulnérabilités sur ces types de programmes.
% \item \textit{DeFi Hacks Analysis - Root Cause} : Une base de données d'analyses d'attaques sur des solutions et organismes traitant sur des blockchains, les analyses sont sourcées et redirigent vers le dépot \textit{GitHub} de reproduction des attaques.
% \item \textit{DeFi Hacks Analysis - Root Cause} : Une base de données d'analyses d'attaques sur des solutions et organismes traitant sur des \gls{blockchain}s, les analyses sont sourcées et redirigent vers le dépot \textit{GitHub} de reproduction des attaques.
% \item Un ensemble d'outils utilitaires tels que des outils de debug de transaction, des dashboards ou encore des newletters.
%\end{itemize}
%Ces outils nous ont permis d'explorer de nombreuses sources concernant les attaques sur les protocoles interblockchains.
%Ces outils nous ont permis d'explorer de nombreuses sources concernant les attaques sur les protocoles inter\gls{blockchain}s.
\subsubsection{Contre-mesures et solutions envisageables}
Comme nous avons pu le voir, de nombreux cas d'attaques sont observables sur des protocoles d'échanges centralisés.
Dans la plupart des cas, elles résultent de problèmes d'implémentations et autres oublis dans les codes sources des protocoles utilisés.
Cela peut être expliqué par le fait que la \textit{blockchain} est un domaine qui évolue très vite et chaque innovation technique peut rapporter des parts de marché importantes au premier arrivé.
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.
@ -101,4 +101,4 @@ Tout d'abord des standards de sécurité pourraient être mis en place afin de d
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.
%En effet, les attaques les plus importantes ont comme point d'entrée une faille dans la structure de l'intermédiaire.
%Cette menace constante d'attaques a mené à des recherches visant à soutirer ce tiers des échanges inter-blockchain. Ce menant aux échanges décentralisés.
%Cette menace constante d'attaques a mené à des recherches visant à soutirer ce tiers des échanges inter-\gls{blockchain}. Ce menant aux échanges décentralisés.
Comme son nom l’indique, un \textit{Blockchain Bridge} également appelé \textit{Cross-chain Bridge} est un protocole reliant deux \textit{blockchains} entre elles de manière unilatérale ou bilatérale dans une optique d’interopérabilité.\\
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{blockchains} 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 \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}.\\
Il existe trois différentes manières de déplacer les actifs en tant que \textit{bridge}. Tout d’abord, le mécanisme de \textit{Lock and Mint} signifiant Verrouiller et Frapper, les actifs 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 actifs 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'actifs entre la chaîne d’origine et la chaîne de destinataire.\cite{EthereumMechanism}
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}
\subsubsection{Mécanisme de vérification}
Comme évoqué précédemment, deux \textit{blockchains} ne peuvent pas communiquer directement entre elles, par conséquent lors de l’utilisation d’un \textit{bridge} les deux chaînes ne se connaissent pas et ont seulement connaissance des évènements se produisant sur leur chaîne respectives. Il est donc nécessaire d’établir une relation de confiance entre les deux chaînes pour qu’elles puissent accepter de communiquer. Pour cela, les \textit{bridges} emploient un mécanisme utilisant des vérificateurs. Un vérificateur est une autorité de confiance qui vérifie et valide les transactions sur une \textit{blockchain}. \\
Comme évoqué précédemment, deux \textit{\gls{blockchain}s} ne peuvent pas communiquer directement entre elles, par conséquent lors de l’utilisation d’un \textit{bridge} les deux chaînes ne se connaissent pas et ont seulement connaissance des évènements se produisant sur leur chaîne respectives. Il est donc nécessaire d’établir une relation de confiance entre les deux chaînes pour qu’elles puissent accepter de communiquer. Pour cela, les \textit{bridges} emploient un mécanisme utilisant des vérificateurs. Un vérificateur est une autorité de confiance qui vérifie et valide les transactions sur une \textit{\gls{blockchain}}. \\
Il existe un grand nombre de \textit{bridges}, chacun avec leurs propres spécificités mais ils peuvent généralement être séparés en deux catégories les \textit{Trusted Blockchain Bridge} et les \textit{Trustless Blockchain Bridge}. \\
Il existe un grand nombre de \textit{bridges}, chacun avec leurs propres spécificités mais ils peuvent généralement être séparés en deux catégories les \textit{Trusted \gls{blockchain} Bridge} et les \textit{Trustless \gls{blockchain} Bridge}. \\
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 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{\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{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 actifs. Par conséquent leur niveau de sécurité est égal à celui des \textit{blockchains} 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{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{blockchains} entre elles. Il est codé comme un \textit{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 actifs 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{blockchains} et donc la sécurité dépend de la sécurité des \textit{blockchains} elles-même (ce qui est avantageux si elles sont forcément sécurisées comme la chaîne d’Ethereum par exemple).
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.
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!]
\centering
@ -35,8 +35,8 @@ La vérification native commence par l’utilisation d’un \textit{light client
\pagebreak
La vérification externe consiste en un ensemble de vérificateurs n’appartenant pas aux \textit{blockchains} 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 le 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{blockchains}. \\
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 le 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}. \\
@ -55,7 +55,7 @@ Contrairement à la vérifications native, les \textit{bridges} vérifiés de ma
\end{figure}
\pagebreak
Il est intéressant de noter que les \textit{blockchains} ont également leur propre ensemble de vérificateurs sous la forme de vérificateur de données. Ces derniers sont utilisés lors de la vérification locale. Lors de la vérification locale, les chaînes se vérifient entre elles en envoyant un vérificateur en tant que représentant.
Il est intéressant de noter que les \textit{\gls{blockchain}s} ont également leur propre ensemble de vérificateurs sous la forme de vérificateur de données. Ces derniers sont utilisés lors de la vérification locale. Lors de la vérification locale, les chaînes se vérifient entre elles en envoyant un vérificateur en tant que représentant.
\begin{figure}[h]
\centering
@ -66,17 +66,17 @@ Il est intéressant de noter que les \textit{blockchains} ont également leur pr
\subsubsection{Les risques liés aux Bridges}
La popularité des \textit{Blockchain Bridges} pour les échanges centralisés ne cesse d’augmenter au fils du temps mais il est important de comprendre que comme tout outil, ces derniers ne sont pas sans risques. \\
La popularité des \textit{\gls{blockchain} Bridges} pour les échanges centralisés ne cesse d’augmenter au fils du temps mais il est important de comprendre que comme tout outil, ces derniers ne sont pas sans risques. \\
Les \textit{bridges trustless} utilisent des \textit{smart contracts} lors du processus d’échange dans le but de le rendre autonome afin de ne pas utiliser une entité centrale entre les deux blockchains. Cependant ces \textit{bridges} sont néanmoins centralisés car ils utilisent les vérificateurs pour obtenir un consensus lors des transactions.
Un \textit{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.
Les \textit{bridges trustless} utilisent des \textit{\gls{smart contract}s} lors du processus d’échange dans le but de le rendre autonome afin de ne pas utiliser une entité centrale entre les deux \gls{blockchain}s. Cependant ces \textit{bridges} sont néanmoins centralisés car ils utilisent les vérificateurs pour obtenir un consensus lors des transactions.
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 actifs et faire confiance aux vérificateurs externes aux blockchains. Sauf que dans certains cas, ces derniers peuvent coopérer pour tromper les utilisateurs en récupérant leurs actifs 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{smart contract} empêchant les utilisateurs d’utiliser ou revendre les actifs frappés, seul le fraudeur en a le droit. Il peut donc en toute tranquillité revendre les actifs et récupérer l’argent. En revanche, pour les \textit{soft rug pull}, les utilisateurs ne sont pas coincés avec des actifs 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 actifs.\\
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.\\
Comme vu dans la section présentant les différentes méthodes d’échange des \textit{bridges}, ces derniers frappent les actifs 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’actifs en utilisant une faille d’un \textit{bridge} sans verrouiller ou brûler d’actifs sur sa \textit{blockchain}. Suite à cela, l’individu réintroduit ces actifs sur le marché ce qui fait violemment baisser leur coût ce qui engendre un risque financier systémique.\\
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{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 blockchains 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 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 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. \\
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.
@ -84,7 +84,7 @@ Un autre facteur portant atteinte à la sécurité des \textit{bridges} est le f
\caption{Pertes en millions de dollars des bridges les plus connus.}
\label{fig:GraphBridges}
\end{figure}
@ -97,18 +97,18 @@ Le mot trustless peut être traduit par «sans confiance» faisant allusion à l
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.
La vérification native ne respecte pas la notion d’extensibilité car le \textit{bridge} n’est pas réutilisable. Néanmoins elle respecte la notion de généralisation parce qu’elle est codée de manière spécifique aux \textit{blockchains} reliées au \textit{bridge}. Le critère basé sur la notion \textit{trustless} est également rempli étant donné que le niveau de sécurité dépend des vérificateurs des chaînes.
La vérification native ne respecte pas la notion d’extensibilité car le \textit{bridge} n’est pas réutilisable. Néanmoins elle respecte la notion de généralisation parce qu’elle est codée de manière spécifique aux \textit{\gls{blockchain}s} reliées au \textit{bridge}. Le critère basé sur la notion \textit{trustless} est également rempli étant donné que le niveau de sécurité dépend des vérificateurs des chaînes.
La vérification externe ne respecte pas la notion de \textit{trustless} cependant elle est fortement extensible et générale vis-à-vis des données. \cite{NgraveVerif}
Suite au paragraphe précédent, il est possible de constater que les \textit{bridges} interopérables ne respectent que deux des trois notions énoncées. Ce problème est connu sous le nom de trilemme de l’interopérabilité.
\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 actifs entre les \textit{blockchains}. 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 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}. \\
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{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{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.
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.
@ -126,7 +126,7 @@ Une solution a été implémentée pour palier à cela comme la mise en place d
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é. \\
La faculté de l’observateur à pouvoir couper la connexion s’il conteste la transaction lui permet d’effectuer un déni de service appelé \textit{Watcher DoS}. C’est pourquoi il lui ait possible de fermer définitivement la connexion d’une transaction si ce dernier continue sans cesse de couper le processus sans raison valable. Heureusement, la fermeture ne concerne que la connexion et n’impacte en aucun cas le système du \textit{bridge}. Cependant cette attaque semble irrationnelle en terme de ressources et de temps car l’observateur effectuant le déni de service ne gagne rien financièrement contrairement au processus habituel. En effet, si un observateur prouve une fraude correctement, ce dernier peut récupérer le collatéral du vérificateur. Mais ici puisqu’aucune fraude n’est prouvée les données se trouvant sur la chaîne d’origine sont conservées et sécurisés. Cela cause seulement une perte de temps pour l’utilisateur ou l’application décentralisée voulant effectuer l'échange d’une \textit{blockchain} à une autre.
La faculté de l’observateur à pouvoir couper la connexion s’il conteste la transaction lui permet d’effectuer un déni de service appelé \textit{Watcher DoS}. C’est pourquoi il lui ait possible de fermer définitivement la connexion d’une transaction si ce dernier continue sans cesse de couper le processus sans raison valable. Heureusement, la fermeture ne concerne que la connexion et n’impacte en aucun cas le système du \textit{bridge}. Cependant cette attaque semble irrationnelle en terme de ressources et de temps car l’observateur effectuant le déni de service ne gagne rien financièrement contrairement au processus habituel. En effet, si un observateur prouve une fraude correctement, ce dernier peut récupérer le collatéral du vérificateur. Mais ici puisqu’aucune fraude n’est prouvée les données se trouvant sur la chaîne d’origine sont conservées et sécurisés. Cela cause seulement une perte de temps pour l’utilisateur ou l’application décentralisée voulant effectuer l'échange d’une \textit{\gls{blockchain}} à une autre.
Une réponse à ce problème actuellement mise en œuvre par le \textit{bridge} de Nomad est la présence d’un groupe restreint d’observateurs autorisés à contester, de cette manière il est facile de connaître les observateurs malveillants. Chaque observateur possède une clé permettant de signer une attestation confirmant la présence d’une fraude dans la transaction, chaque \textit{bridge} stocke un ensemble contenant les adresses des attestations appartenant aux observateurs autorisés. Si l’attestation reçue par le \textit{bridge} est présente dans l’ensemble alors la connexion est rompue\cite{NomadDocsWatcher}.
Sur le long terme, une proposition consistant à la mise en place de frais si l’on souhaite contester est en train d’être étudiée. Le montant doit répondre à deux contraintes: ce dernier doit être assez haut pour dissuader les observateurs malhonnêtes mais assez bas pour que ceux ayant réellement l’envie de prouver de manière valide une fraude existante puissent le faire. Dans la continuité de cette solution, il serait également possible de récupérer la signature de la déconnexion générée par l’observateur sur la chaîne originale et de le pénaliser en lui retirant les frais qu’il a payé tel une garantie\cite{OptimisticBhuptani}.
Pour conclure sur les échanges centralisés, nous avons pu voir que le fonctionnement des plate-formes est relativement opaque.
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 blockchains.
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.
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 actifs des utilisateurs.
Cette menace constante a menée à des recherches visant à soutirer cet intermédiaire des échanges inter-blockchain, donc d'employer des moyens décentralisés pour résoudre cette problématique.
Le tiers de confiance est donc un point d'entrée pour les pirates vers les \gls{actif}s des utilisateurs.
Cette menace constante a menée à des recherches visant à soutirer cet intermédiaire des échanges inter-\gls{blockchain}, donc d'employer des moyens décentralisés pour résoudre cette problématique.
Lorsqu'un \textit{smart contract} envoie un message \textit{crosschain} comme un verrouillage
de jetons sur une \textit{blockchain} source et une demande de frappe de jetons sur une
\textit{blockchain} cible, celui-ci interargit avec un \textit{core contract}\cite{wormholeCoreContract}.
Un \textit{core contract} est déployé sur toutes les \textit{blockchains} compatibles avec le protocole
Lorsqu'un \textit{\gls{smart contract}} envoie un message \textit{crosschain} comme un verrouillage
de jetons sur une \textit{\gls{blockchain}} source et une demande de frappe de jetons sur une
\textit{\gls{blockchain}} cible, celui-ci interargit avec un \textit{core contract}\cite{wormholeCoreContract}.
Un \textit{core contract} est déployé sur toutes les \textit{\gls{blockchain}s} compatibles avec le protocole
Wormhole. Tout \textit{core contract} est observé par le réseau de gardiens.
Un message Wormhole est émis grâce à la fonction \textit{publishMessage()} prenant en entrée le \textit{payload}.
La sortie de cette fonction est un \textit{sequence number}, un numéro d'index unique pour le message.
@ -37,16 +37,16 @@ et le \textit{payload}.\\ 5 \textit{payloads} peuvent être utilisés dont \text
\textit{AssetMeta}, attestant les méta-données du jeton.\\
Le \textit{payload AssetMeta} est obligatoire avant un premier transfert.
En effet, le \textit{payload Transfer} n'informe pas la chaîne B des meta-données du jeton verrouillé.
En l'absence de connaissance de ces informations, il n'est pas possible pour la \textit{blockchain} B
En l'absence de connaissance de ces informations, il n'est pas possible pour la \textit{\gls{blockchain}} B
de frapper la quantité correcte de jetons.\\
Si l'on souhaite ensuite transférer des jetons depuis une \textit{blockchain} A vers une
\textit{blockchain} B, il faut verrouiller les jetons sur A et les frapper sur B.
Si l'on souhaite ensuite transférer des jetons depuis une \textit{\gls{blockchain}} A vers une
\textit{\gls{blockchain}} B, il faut verrouiller les jetons sur A et les frapper sur B.
D'où l'utilisation du \textit{payload Transfer} contenant des informations comme la
quantité de jetons transférés, l'adresse de la chaîne d'origine et de destination,
le numéro d'identification de la chaîne d'origine et de destination..
Une preuve doit être fournie que les jetons sur A sont verrouillés avant que la frappe puisse
avoir lieu sur B. La signature des gardiens sur le VAA correspondant est la preuve apportée à
la \textit{blockchain} B que le verrouillage a bien été effectué et que la frappe de jetons sur
la \textit{\gls{blockchain}} B que le verrouillage a bien été effectué et que la frappe de jetons sur
B est légitime.
\subsubsection{Gardiens}
@ -59,11 +59,11 @@ Le réseau de gardiens est composé de 19 gardiens à parts égales sans chef (\
Il est conçu pour servir d'oracle à Wormhole et est l'élement le plus critique de l'écosystème.
Si une majorité de deux tiers ou plus des gardiens signent le même VAA, alors le consensus est atteint :
le VAA est automatiquement considéré valide par tous les contrats Wormhole sur toutes les
\textit{blockchains} et le \textit{payload} est actionné.
\textit{\gls{blockchain}s} et le \textit{payload} est actionné.
Chaque gardien utilise un algorithme de signature à courbe elliptique : ECSDA pour
\textit{Elliptic Curve Signature Digital Algorithm}.
Plus précisément, chaque gardien se réfère à «secp256k1» comme paramètres de la courbe elliptique,
aussi utilisé par les \textit{blockchains} Bitcoin et Ethereum.\\
aussi utilisé par les \textit{\gls{blockchain}s} Bitcoin et Ethereum.\\
Le modèle de consensus utilisé est une \textit{Proof of Authority} (PoA) avec un système de
\textit{multisignature} M/N \cite{wormholeChainswap}, c'est à dire que M clefs parmi N sont nécessaires
pour signer un VAA. Ce modèle permet un traitement rapide des transactions et une dispense de participation monétaire, par rapport à la preuve de travail (PoW) et la preuve
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
PC_Salle_1.06