XCASH et les Chaînes Collatérales (#SideChains)

écrit par Ju (12 Juin 2021) | traduit par Ju (12 Juin 2021)

Intro

  • Sur le long terme, le développement du projet X-CASH prévoit un ajout toujours croissant de nouvelles fonctionnalités et de nouveaux cas d’usage sur la blockchain XCASH.
  • Ces évolutions vont inexorablement conduire à une augmentation significative du nombre de transactions sur la blockchain principale XCASH, si aucune parallélisation de leur traitement n’est mise en œuvre et en service.
  • De plus la blockchain principale XCASH traite actuellement les blocs à une vitesse de un bloc toutes les 5 minutes. Cette vitesse permet de répondre à certains cas d’usage mais pas à l’ensemble de ceux attendu en cible dans le cadre du projet X-CASH, comme celui des paiements instantanés.

Objectifs

  • Protéger la croissance naturelle et organique native du nombre de transactions sur la blockchain principale XCASH
  • Éviter l’engorgement de la blockchain principale XCASH
  • Éviter de faire grossir la blockchain principale XCASH avec des informations non-essentielles à son fonctionnement
  • Continuer à déployer les nouveaux usages et les nouvelles fonctionnalités du projet X-CASH sans impacter les performances et le développement de la blockchain principale XCASH
  • Garantir la flexibilité et l’évolutivité du projet X-CASH et de la blockchain principale XCASH

Cas d’usage principaux

  • Réaliser des paiements instantanés sans polluer ni impacter la blockchain principale XCASH avec autant de microtransactions associées et à une vitesse bien plus rapide (~instantanée).
  • Permettre la mise en œuvre et la mise en service de fonctionnalités supplémentaires du projets X-CASH, en parallèle de la blockchain principale XCASH (ex : NFT)

Quel design de Chaînes Collatérales possible pour XCASH ?

  • PEG Bidirectionnelle Symétrique ?

+ Pas besoin d’avoir une copie complète de la blockchain principale

- Possibilité de création de chaînes collatérales en cascade

- Gestion de la sécurité pouvant être complexifiée en cas de multiplication trop importante des cascades de chaînes collatérales

  • PEG Bidirectionnelle Asymétrique ?

- Besoin d’avoir une copie de la blockchain principale

+ Limitation des possibilités de création de chaînes collatérales en cascade

+ Gestion de la sécurité simplifiée par la limitation de la multiplication des chaînes collatérales potentielles

  • Design unique créé pour XCASH par X-CASH ?

Du fait que tous les délégués DPoPS XCASH hébergent et gèrent la blockchain principale XCASH, il apparaissaient naturel voir évident de regarder du côté des architectures PEG Bidirectionnelle Asymétrique pour les chaînes XCASH collatérales…

CEPENDANT, grâce aux apports techniques de la couche primaire de la blockchain XCASH et de sa couche L1 DPoPS, il apparait finalement plus pertinent de prévoir un design unique et spécifique par “Héritage” afin d’optimiser les performances, les possibilités d’évolution et de scalabilité des Chaines Collatérales XCASH.

Le design par Héritage

  • L’idée est d’avoir plusieurs pièces et couches superposées qui héritent de caractéristiques les unes des autres.
  • L’enjeu consiste à faire en sorte que le design des chaînes collatérales ressemble plus à celui du design API d’un point de vue code qu’à celui du design blockchain classique, afin de développer les éléments et fonctionnalités à un haut niveau plutôt que dans les couches basses.

Concrètement ?

  • Nous avons xcash-core qui est responsable de la synchronisation au plus bas niveau, ainsi que de la sécurité et de la transmission.
  • Nous avons ensuite DPOPS qui est essentiellement une couche au-dessus et qui est le “consensus connecté” qui contrôle xcash-core
  • Les chaînes collatérales peuvent donc naturellement et nativement hériter de la sécurité et du consensus de ces deux couches.
  • Ainsi, au niveau du DAG (voir quesako), nous n’avons plus besoin du consensus, grâce aux 50 délégués validateurs, déjà identifiés dans la couche DPOPS. Cela permet ainsi au dernier producteur de bloc d’obtenir toutes les récompenses pour cet intervalle de 5 minutes, et permet globalement aux 50 délégués DPoPS d’exécuter un mutex (voir quesako) dans le code pour vérifier chaque transaction.
  • Ce design sur mesure et unique pour XCASH permettra donc d’atteindre des performance extrêmement rapide (~instantanée) grâce à ce modèle par héritage.
  • Les jetons seront la partie la plus délicate et leur design sera plus proche des design des chaînes collatérales standards.
    Il y aura en effet, une chaîne collatérale séparée pour chaque jeton, et ils n’auront pas besoin d‘être vérifiés par tous les délégués du TOP50. Il reste cependant encore des arbitrages techniques à réaliser sur la meilleure façon de mettre en œuvre ce mécanisme mais ce sera assurément plus aligné avec les designs technologiques standards en la matière.

Quelques Caractéristiques

  • Technologie DAG : construite sur mesure et héritant du consensus et de la sécurité de DPoPS.
  • Vitesse : Instantanée
  • Frais : Voté par les Délégués [Moyenne pondérée sans valeurs aberrantes des propositions de frais faites par les Délégués [pouvant faire l’objet de modifications dans le futur].
  • Qui reçoit les frais : Toutes les transactions vont au dernier producteur de bloc jusqu’au nouveau (5 minutes)
  • Comment fonctionnent les dépôts et les retraits : vérifiés par tous les délégués et envoyés par tous les délégués signataires.

Quesako ?

DAG

  • Le DAG, Directed Acyclic Graph, est une structure de données qui utilise l’ordre topologique.
  • DAG est un concept qui est apparu suite à l’apparition du concept des Chaînes Collatérales afin d’éliminé le processus de minage et ainsi optimiser la scalabilité des transactions.
  • Le DAG est une implémentation de la structure graphique dirigée qui est principalement utilisée pour résoudre des problèmes de traitement des données, d’identification du meilleur parcours dans la navigation, la planification et la compression des données.

MUTEX

  • Un MUTEX est un objet d’exclusion mutuelle qui synchronise l’accès à une ressource. Il est créé avec un nom unique au début d’un programme.
    Le MUTEX est un mécanisme de verrouillage qui garantit qu’un seul thread peut acquérir le MUTEX à la fois et entrer dans la section critique.
  • Ce thread ne libère le MUTEX que lorsqu’il quitte la section critique.

Vidéo de démo des Chaînes Collatérales XCASH

par Zach Hildreth, X-CASH CTO [Chaîne Youtube Zachy Zone]

Liens Importants

--

--

--

🕵️X-Cash Community Manager, Ambassador, News Writer, Translator 🕵️Manager of $XCASH #DPoPS Delegate @xcash_ju_fr in partnership with @MasterNodesSF

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ju

Ju

🕵️X-Cash Community Manager, Ambassador, News Writer, Translator 🕵️Manager of $XCASH #DPoPS Delegate @xcash_ju_fr in partnership with @MasterNodesSF

More from Medium

How To Use the Splyt Reserve: 100X Launch Pool

What is the real value of an NFT?

Metaverse and its potential for retail and consumer brands (Part-3)

When will Formula 1 return to Africa?