Soutenance mémoire
Blockchain
Modification et suppression d’un instrument financier
La mise à jour et la suppression d’instruments ne sont pas mises en place pour des raisons de sécurité. Dans le cas où l’adresse d’un instrument serait mise à jour, les traders possédant cet instrument ne serait plus en mesure de l’échangé et perdrait donc la totalité de sa valeur sur la plateforme d’échange. Le problème est le même dans un cas de suppression d’instrument. On pourrait cependant imaginer un cas de figure où une institution, ayant mis un instrument en circulation, se verrait dans l’obligation de redéployer une version comportant un patch de sécurité ou une modification du comportement du contrat. Ce redéploiement engendrerait la modification de l’adresse initial du contrat. Il serait donc utile de pouvoir modifier l’adresse ou bien l’ABI du contrat.
En revanche, cela demande d’avoir une validation et une supervision beaucoup plus complexe des contrats en circulation qui sont acceptés sur la plateforme. Il serait donc nécessaire d’ajouter un mécanisme de consensus (manuel ou automatisé) à la plateforme afin de pouvoir prévenir les modifications frauduleuses de contrats se trouvant sur l’échange décentralisé. Pour cette raison, la modification et la suppression d’instrument ne sera pas couvert dans ce travail, que ce soit au niveau conceptuel ou pratique. 5.5.8 Affichage des instruments financier disponible sur la plateforme Une fois enregistrer, un trader doit pouvoir connaitre et rechercher les instruments disponibles sur la plateforme. Pour que l’expérience d’utilisation soit semblable à celle des applications de trading centralisé, il est primordial que l’utilisateur puisse chercher les titres par leur nom ou par leur symbole plutôt que par leurs adresses. Figure 19: Diagramme des microservices impliqués dans l’affichage des instruments financier
Fait à l’aide du logiciel Visual Paradigm
Lorsqu’un utilisateur se connecte, il est directement redirigé sur son tableau de bord. Depuis ce dernier, il peut sélectionner l’instrument qui l’intéresse dans une liste déroulante (en haut à gauche sur la figure ci-dessous). En fonction de l’élément choisi, le carnet d’ordre est automatiquement mis à jour avec les informations relatives au titre. Figure 20: Tableau de bord de la plateforme
Capture d’écran de la plateforme
Les prix affichés dans le carnet d’ordres sont directement récupérés depuis le service « MatchingEngine » et sont mis à jour à chaque fois qu’un nouvel ordre est reçu sur ce dernier. L’implémentation de la logique d’allocation d’ordre est détaillée dans la section « Order book ». 5.5.9 Dépôt de tokens pour lancer la session de trading Comme évoqué précédemment, pour que les ordres soient exécutés instantanément, il n’est pas possible de traiter l’allocation d’ordre directement sur la blockchain. En revanche, grâce à une technique connue sous le nom de « State Channel » (SC), il est possible de garantir un échange hors-blockchain (HB) par un dépôt sur un smart contract se trouvant sur la blockchain (pour plus d’information se référer à la section State Channel). En déplaçant la gestion des ordres en dehors de la blockchain tout en garantissant chacun des échanges par un dépôt, il est alors possible de gagner en vitesse d’exécution tout en réduisant fortement le risque de conflit lié à des échanges HB.
Il est cependant important de noter que le principe des SC est généralement appliqué entre deux acteurs qui se connaissent mutuellement. Or, dans un système de trading, il n’est ni nécessaire, ni possible pour un acteur de connaitre chacun des traders présents sur la plateforme. Bien qu’un échange HB puisse être effectué instantanément, ce n’est pas le cas du dépôt initial qui doit être effectué sur la blockchain et qui est limité par la vitesse de transaction de cette dernière. Il n’est donc pas envisageable que pour chaque échange entre deux acteurs il faille créer une nouvelle SC entre les deux afin de pouvoir procéder à l’échange HB. Il a donc fallu trouver une solution qui permette à un trader de garantir tous ses échanges lors d’une session de trading, sans pour autant devoir créer des nouvelles SCs en permanence. Donc plutôt que de définir un montant à déposer pour un échange entre deux traders, il faut définir un montant pour l’entièreté de la session de trading. Avant de pouvoir placer un ordre, le système va vérifier que le montant total des ordres du trader ne dépasse pas le montant total du dépôt. Le problème des multiples SC est résolu, mais cela en crée un autre. Sur une SC simple, les échanges d’un token A sont garantis par un dépôt de token A. Or, sur l’échange nous voulons pouvoir échanger un token de type monétaire pour un token de type actif financier (une action par exemple). Les différents types n’ayant pas le même prix à l’unité, il n’est donc pas possible de garantir un échange uniquement par une certaine quantité de token. Il est donc nécessaire de prendre en compte le prix à l’unité de chaque token et d’exprimer le montant total des actifs bloqués pour une session dans un unité de mesure unique. En l’occurrence, l’unité de mesure choisi est le « USDX ». Il est également important de prendre en compte que les prix des titres fluctuent en permanence et donc que les montants des dépôts également. Il faut donc actualiser périodiquement le prix sur chaque smart contract d’instrument financier pour refléter ces fluctuations.Pour pouvoir effectuer un dépôt et placer des ordres, le trader doit donc avoir en sa possession, des tokens de type « USDX ». Il peut en acheter directement sur la plateforme contre des ETH. Dans la partie « Profile » de la plateforme, il lui suffit de rentrer le montant qu’il désire obtenir dans le formulaire « Buy Fiat » (voir figure cidessous). Il pourra ensuite utiliser le formulaire de dépôt qui se trouve au même endroit pour pouvoir initier une session de trading avec la limite qu’il souhaite s’accorder.
Placement d’un ordre d’achat ou de vente pour un instrument financier spécifique
Après avoir déposé des fonds sur le DEX en passant par l’interface graphique, un trader doit pouvoir placer des ordres d’achat ou de ventes pour chaque actif disponible sur la plateforme. Il doit également pouvoir modifier ou annuler un ordre envoyé et consulter l’état d’un ordre à tout moment. Avec l’approche hybride choisi, contrairement aux échanges décentralisés avec un carnet d’ordre on-chain, aucune commission n’est prélevée lors d’une annulation ou d’une modification. En effet, n’ayant pas besoin d’interagir avec la blockchain pour effectuer ce type d’opération, aucun frais n’est engendré.Le processus de placement d’ordres est décrit dans le diagramme de séquence cidessous. Il met en avant les actions effectuer par chacun des composants de hautniveau impliqués dans ce cas d’utilisation ainsi que les messages et informations échangés. Figure 25: Diagramme de séquence du placement d’un ordre de trading
Fait avec l’outil Mermaid Live Editor
Une information essentielle n’est cependant pas présente sur le schéma : la signature des messages envoyés off-chain. Dans le cadre standard de l’utilisation de canaux d’état, le processus est simple. Chacun des acteurs voulant s’échanger des montants sans devoir passer par la blockchain déposent une partie de leurs fonds dans un Smart Contrat. Ils peuvent ensuite procéder à des échanges off-chain qui doivent être inférieur à la somme déposée. Chaque fois qu’ils s’envoient une transaction, les deux parties doivent signer le message cryptographiquement. Lorsqu’ils ont terminé leurs échanges, ils peuvent envoyer la dernière transaction signée représentant l’état final de leurs comptes.
Dans le cadre d’une plateforme de trading en revanche, les acteurs ne communiquent pas directement et ne se connaissent pas et ils doivent passer par la plateforme pour conclure des échanges. Ils ne sont donc pas en charge de conserver les messages signés, ni de connaitre l’état des comptes des autres utilisateurs. C’est le rôle de l’ExchangeAPI. Toute la logique de signature et de conservation des messages est donc effectuée sur ce service. Le processus est le suivant : 1. Réception de l’ordre d’un trader 2. L’API vérifie que le trader a suffisamment de fonds pour placer un ordre d’un certain montant 3. L’API vérifie que le trader a suffisamment de fonds déposé dans le DEX 4. LAPI signe l’ordre avec la clé privé envoyé par le trader (sans ne jamais la conserver) 5. L’API conserve l’ordre signé en mémoire pour référence 6. L’API met à jour l’état du compte du trader pour refléter la transaction 7. L’API met à jour l’historique d’activité du trader pour refléter la transaction 8. L’API envoie l’ordre signé au service MatchingEngine 9. L’API met à jour le statut de l’ordre en fonction du résultat d’exécution retourné par le MatchingEngine (le statut peut être un des suivants : pending, cancelled, filled, partially-filled) 10. L’API met à jour l’état du compte du trader pour refléter le résultat d’exécution 11. L’API met à jour l’historique d’activité du trader pour refléter le résultat d’exécution
|
Table des matières
Déclaration
Remerciements
Résumé
Liste des tableaux
1. Introduction
2. Blockchain
2.1 Définition générale
2.2 Historique
2.2.1 La liste de diffusion décentralisée
2.2.2 Spammeurs
2.2.3 Hashcash
2.2.4 B-money
2.2.5 Bit Gold
2.3 Bitcoin
2.3.1 Proof of work
3. Ethereum
3.1 Smart Contracts
3.1.1 Token
3.1.2 Limitations
3.1.2.1 Réseaux partagés et débit limité
3.1.2.2 Sécurité des Smart Contracts
3.1.2.3 Le problème des oracles
3.2 State Channel
3.2.1 Canaux de payement
3.2.2 Canaux d’état
4. Plateformes de trading
4.1 Architecture des échanges décentralisés
4.1.1 La blockchain et les standards de compatibilité choisis
4.1.2 Matching engine
4.1.3 Le mécanisme de découverte d’ordres
4.1.4 Carnet d’ordres on-chain
4.1.4.1 Avantages d’un carnet d’ordre on-chain
4.1.4.2 Inconvénients d’un carnet d’ordre on-chain
4.1.5 Carnet d’ordres off-chain
4.1.5.1 0x
4.1.5.2 EtherDelta
4.1.5.3 IDEX
4.1.5.4 Avantages d’un carnet d’ordres off-chain
4.1.5.5 Inconvénients d’un carnet d’ordres off-chain
4.1.6 L’algorithme d’allocation d’ordres
4.1.6.1 Exécution manuelle des ordres
4.1.6.2 Exécution automatisée des ordres
5. Implémentation
5.1 Concept
5.1.1 Objectifs de la solution
5.1.2 Portée de la solution
5.2 Spécifications fonctionnelles
5.3 Spécifications non-fonctionnelles
5.4 Spécifications techniques
5.4.1 React.js
5.4.2 Solidty
5.4.3 Ganache
5.4.4 Web3.js
5.4.5 Express.js
5.4.6 OpenZeppelin
5.5 Implémentation des use-cases
5.5.1 Architecture de la solution
5.5.1.1 Trading UI
5.5.1.2 ExchangeAPI
5.5.1.3 MatchingEngine
5.5.1.4 Order Book
5.5.1.5 Remarques
5.5.2 Architecture des Smart Contracts
5.5.2.1 ERC20
5.5.2.2 USDX
5.5.2.2.1 Stablecoin garanti par une commodité (Commodity-backed)
5.5.2.2.2 Stablecoin garanti par une monnaie (Fiat-backed)
5.5.2.3 USDXCrowdsale
5.5.2.4 Stock
5.5.2.5 StockICO
5.5.2.6 DEX (pour decentralized exchange)
5.5.2.6.1 Constructeur
5.5.2.6.2 Dépôt de tokens
5.5.2.6.3 Retrait de tokens
5.5.2.6.4 Montant du dépôt
5.5.2.6.5 Transactions
5.5.3 Blockchain Interface
5.5.4 Création d’un compte de trading
5.5.4.1 Remarques
5.5.5 Login
5.5.6 Enregistrement d’un instrument financier
5.5.6.1 Représentation ABI
5.5.6.2 Exemple de requête
5.5.6.3 Exemple de réponse
5.5.6.4 Remarques
5.5.7 Modification et suppression d’un instrument financier
5.5.8 Affichage des instruments financier disponible sur la plateforme
5.5.9 Dépôt de tokens pour lancer la session de trading
5.5.10 Placement d’un ordre d’achat ou de vente pour un instrument financier spécifique
5.5.10.1 Exemple de requête
5.5.10.2 Exemple de réponse d’un ordre sans correspondance
5.5.10.3 Remarques
5.6 Limitations et risques
5.6.1 Matching engine off-chain et centralisé
5.6.1.1 Attaque par front-running
5.6.1.2 Attaque par censure
5.6.1.3 Défaillance
6. Résultats
7. Améliorations possibles
7.1 Transparence d’exécution
7.2 Échange décentralisé basé sur un réseau de State Channel
8. Conclusion
Annexe 1 : Lexique des termes financier
8.1.1 Broker
8.1.2 Market order
8.1.3 Limit order
8.1.4 Order book
8.1.5 Bid et Ask
8.1.6 Profondeur du marché
8.1.7 Front-running
8.1.8 Arbitrage
Annexe 2 : Algorithme de correspondance d’ordres
First-in-first-out (FIFO)
8.1.8.1 Pure Pro-rata
Annexe 3 : Sharding
Annexe 4 : Tests d’acceptation
Annexe 5 : Librairies et frameworks utilisés
Bibliographie
Télécharger le rapport complet
