dYdX V4 sera une blockchain L1 indépendante avec un carnet de commandes hors chaîne entièrement décentralisé et un moteur de correspondance.
**Écrit par :**dYdX
** Compiler : IBCL **
dYdX Chain V4 est la dernière itération du protocole dYdX, qui consistera en un logiciel open source. La version actuellement en production est appelée v3, v3 et les versions antérieures de dYdX ont à la base des contrats intelligents déployés sur des chaînes existantes combinées à des services centralisés hébergés dans le cloud.
v4 sera une blockchain L1 indépendante avec un carnet de commandes hors chaîne entièrement décentralisé et un moteur de correspondance. La chaîne dYdX sera basée sur le SDK Cosmos et le protocole de consensus CometBFT PoS.
Alors que nous nous rapprochons du lancement du réseau principal v4, nous voulions vous donner un aperçu de ce que l'équipe dYdX est en train de construire. Cet article fournit une vue d'ensemble de haut niveau de l'architecture v4. Étant donné que la v4 est encore en cours de développement, il peut y avoir des changements.
Architecture système v4
dYdX v4 est conçu pour être entièrement décentralisé de bout en bout. Les principaux composants incluent largement les protocoles, les indexeurs et les interfaces. Chacun de ces composants sera fourni sous forme de logiciel open source. dYdX Trading Inc. n'exécutera aucun composant.
Accord
Le protocole est une blockchain L1 construite sur CometBFT et utilisant le CosmosSDK. Le logiciel Node est écrit en Go et compilé en un seul binaire. Comme toutes les blockchains CosmosSDK, la v4 utilise un mécanisme de consensus de preuve de participation.
Le protocole sera supporté par un réseau de nœuds. Il existe deux types de nœuds :
Validateurs : les validateurs sont chargés de stocker les commandes dans un carnet de commandes en mémoire (c'est-à-dire hors chaîne et sans s'engager dans un consensus), de communiquer des transactions à d'autres validateurs et de générer de nouveaux blocs pour la chaîne dYdX via le processus de consensus. Le processus de consensus demandera aux validateurs de proposer à tour de rôle de nouveaux blocs de manière pondérée à tour de rôle (pondérée par la quantité de jetons jalonnés sur leurs nœuds). Les proposants sont chargés de proposer le contenu du bloc suivant. Lorsqu'une commande est appariée, les proposants l'ajoutent à leur bloc proposé et commencent un tour de consensus. Un bloc est considéré comme engagé et ajouté à la blockchain si ⅔ ou plus de validateurs (par poids de mise) l'approuvent. Les utilisateurs soumettront les transactions directement aux validateurs.
Nœud complet : un nœud complet représente un processus exécutant une application v4 qui ne participe pas au consensus. Il s'agit d'un nœud avec un poids de participation de 0, qui ne soumet pas de propositions et ne vote pas sur celles-ci. Cependant, les nœuds complets se connectent au réseau de validateurs, participent aux potins des transactions et traitent chaque bloc nouvellement soumis. Les nœuds complets ont une vue complète de la chaîne dYdX et de son historique et sont conçus pour prendre en charge les indexeurs. Certaines parties peuvent décider (pour des raisons de performances ou de coût) d'exécuter leurs propres nœuds complets et/ou indexeurs.
indexeur
Indexer est une collection de services en lecture seule dont le but est d'indexer et de servir les données de la blockchain pour les utilisateurs d'une manière plus efficace et conviviale pour le Web2. Cela se fait en utilisant des données en temps réel à partir de nœuds complets v4, en les stockant dans une base de données et en mettant ces données à la disposition des utilisateurs finaux via des requêtes websocket et REST.
Alors que le protocole v4 lui-même est capable d'exposer les points de terminaison aux requêtes de service concernant certaines données de base sur la chaîne, ces requêtes ont tendance à être lentes car les validateurs et les nœuds complets ne sont pas optimisés pour les gérer efficacement. De plus, des requêtes excessives adressées aux validateurs peuvent nuire à leur capacité à participer au consensus. Pour cette raison, de nombreux validateurs Cosmos préfèrent désactiver ces API en production. C'est pourquoi il est important de construire et de maintenir des indexeurs et des nœuds complets séparés des validateurs.
Les indexeurs utiliseront la base de données Postgres pour le stockage de données en chaîne, Redis pour le stockage de données hors chaîne et Kafka pour la consommation de données en chaîne/hors chaîne et le streaming vers divers services d'indexation.
l'extrémité avant
Pour créer une expérience décentralisée de bout en bout, dYdX construit trois interfaces open source : une application Web, une application iOS et une application Android.
Application Web : Le site Web sera construit en utilisant Java et React. Le site Web interagira avec Indexer via l'API pour obtenir des informations sur le carnet de commandes hors chaîne et envoyer des transactions directement sur la chaîne. dYdX ouvrira la base de code frontal et les scripts de déploiement associés. Cela permettra à quiconque de déployer et d'accéder facilement à l'interface dYdX vers/depuis son propre domaine/solution hébergée via une passerelle IPFS/Cloudflare.
Mobile : les applications iOS et Android sont conçues à l'aide de Swift et Kotlin natifs, respectivement. L'application mobile interagira avec l'indexeur de la même manière que l'application Web et enverra les transactions directement à la chaîne. L'application mobile sera également open source, permettant à quiconque de déployer l'application mobile sur l'App Store ou le Play Store. Spécifiquement pour les magasins d'applications, les déployeurs doivent disposer d'un compte développeur et d'un compte Bitrise pour terminer le processus de soumission de l'application.
Cycle de vie de la commande
Maintenant que nous avons une meilleure compréhension de chaque composant du dYdX v4, regardons comment tout cela s'emboîte lors de la passation d'une commande. Lors de la passation d'une commande en v4, celle-ci suivra le processus suivant :
Les utilisateurs effectuent des transactions sur un frontal décentralisé (par exemple, un site Web) ou via une API
La commande est acheminée vers le valideur. Ce validateur parle de la transaction aux autres validateurs et aux nœuds complets pour mettre à jour leurs carnets de commandes avec la nouvelle commande.
Le processus de consensus sélectionne un validateur comme proposant. Les validateurs sélectionnés correspondent à la commande et l'ajoutent au prochain bloc proposé.
Le bloc proposé se poursuit tout au long du processus de consensus. a. Si ⅔ des validateurs votent pour confirmer le bloc, le bloc sera validé et enregistré dans la base de données en chaîne de tous les validateurs et nœuds complets. b. Si le bloc proposé ne parvient pas à atteindre le seuil des ⅔, le bloc sera rejeté.
Une fois qu'un bloc est validé, les données mises à jour en chaîne (et hors chaîne) sont transmises des nœuds complets aux indexeurs. L'indexeur fournit ensuite ces données via l'API et les Websockets au frontal et/ou à tout autre service externe qui interroge ces données.
Le flux ci-dessus est un aperçu de haut niveau de la façon dont les commandes/données se déplacent via la v4. À l'approche du lancement du réseau principal v4, nous approfondirons le protocole, les indexeurs et diverses infrastructures frontales dans les articles de blog suivants.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Décrire brièvement l'architecture technique dYdX V4
**Écrit par :**dYdX
** Compiler : IBCL **
dYdX Chain V4 est la dernière itération du protocole dYdX, qui consistera en un logiciel open source. La version actuellement en production est appelée v3, v3 et les versions antérieures de dYdX ont à la base des contrats intelligents déployés sur des chaînes existantes combinées à des services centralisés hébergés dans le cloud.
v4 sera une blockchain L1 indépendante avec un carnet de commandes hors chaîne entièrement décentralisé et un moteur de correspondance. La chaîne dYdX sera basée sur le SDK Cosmos et le protocole de consensus CometBFT PoS.
Alors que nous nous rapprochons du lancement du réseau principal v4, nous voulions vous donner un aperçu de ce que l'équipe dYdX est en train de construire. Cet article fournit une vue d'ensemble de haut niveau de l'architecture v4. Étant donné que la v4 est encore en cours de développement, il peut y avoir des changements.
Architecture système v4
dYdX v4 est conçu pour être entièrement décentralisé de bout en bout. Les principaux composants incluent largement les protocoles, les indexeurs et les interfaces. Chacun de ces composants sera fourni sous forme de logiciel open source. dYdX Trading Inc. n'exécutera aucun composant.
Accord
Le protocole est une blockchain L1 construite sur CometBFT et utilisant le CosmosSDK. Le logiciel Node est écrit en Go et compilé en un seul binaire. Comme toutes les blockchains CosmosSDK, la v4 utilise un mécanisme de consensus de preuve de participation.
Le protocole sera supporté par un réseau de nœuds. Il existe deux types de nœuds :
indexeur
Indexer est une collection de services en lecture seule dont le but est d'indexer et de servir les données de la blockchain pour les utilisateurs d'une manière plus efficace et conviviale pour le Web2. Cela se fait en utilisant des données en temps réel à partir de nœuds complets v4, en les stockant dans une base de données et en mettant ces données à la disposition des utilisateurs finaux via des requêtes websocket et REST.
Alors que le protocole v4 lui-même est capable d'exposer les points de terminaison aux requêtes de service concernant certaines données de base sur la chaîne, ces requêtes ont tendance à être lentes car les validateurs et les nœuds complets ne sont pas optimisés pour les gérer efficacement. De plus, des requêtes excessives adressées aux validateurs peuvent nuire à leur capacité à participer au consensus. Pour cette raison, de nombreux validateurs Cosmos préfèrent désactiver ces API en production. C'est pourquoi il est important de construire et de maintenir des indexeurs et des nœuds complets séparés des validateurs.
Les indexeurs utiliseront la base de données Postgres pour le stockage de données en chaîne, Redis pour le stockage de données hors chaîne et Kafka pour la consommation de données en chaîne/hors chaîne et le streaming vers divers services d'indexation.
l'extrémité avant
Pour créer une expérience décentralisée de bout en bout, dYdX construit trois interfaces open source : une application Web, une application iOS et une application Android.
Cycle de vie de la commande
Maintenant que nous avons une meilleure compréhension de chaque composant du dYdX v4, regardons comment tout cela s'emboîte lors de la passation d'une commande. Lors de la passation d'une commande en v4, celle-ci suivra le processus suivant :
Le flux ci-dessus est un aperçu de haut niveau de la façon dont les commandes/données se déplacent via la v4. À l'approche du lancement du réseau principal v4, nous approfondirons le protocole, les indexeurs et diverses infrastructures frontales dans les articles de blog suivants.