XCASH and SideChains

write by Ju (June 12, 2021)

Intro

• Over the long term, the development of the X-CASH project foresees an ever increasing addition of new features and use cases on the XCASH blockchain.
• These developments will inexorably lead to a significant increase in the number of transactions on the main XCASH blockchain, if no parallelization of their processing is implemented and in use.
• Moreover, the XCASH main blockchain currently processes blocks at a speed of one block every 5 minutes. This speed allows to answer some use cases but not all of those expected in target within the framework of the X-CASH project, such as instantaneous payments.

Objectives

• Protect the natural and organic growth of the number of transactions on the main XCASH blockchain
• Avoid bottlenecking the XCASH core blockchain
• Avoid overloading the XCASH main blockchain with information that is not essential to its operation
• Continue to deploy new use-cases and new functionalities of the X-CASH project without impacting the performance and development of the main XCASH blockchain
• Guarantee the flexibility and scalability of the X-CASH project and the main XCASH blockchain

Main use-cases

• Perform instant payments without polluting or impacting the main XCASH blockchain with as many associated microtransactions and at a much faster speed (~instantaneous).
• Enable the implementation and commissioning of additional X-CASH project features, in parallel to the main XCASH blockchain. (eg : NFT)

What SideChains design is possible for XCASH ?

• Bidirectional Symmetric PEG ?

+ No need to have a full-copy of the main blockchain

- Possibility of creating cascading sidechains

- Security management can be complicated in case of too many cascades of sidechains

• PEG Bidirectional Asymmetric ?

- Need to have a copy of the main blockchain

+ Limitation of the possibilities of creating cascading sidechains

+ Security management simplified by limiting the multiplication of potential sidechains

• Unique design created for XCASH by X-CASH ?

Since all XCASH DPoPS delegates host and manage the main XCASH blockchain, it seemed natural to look at the PEG Bidirectional Asymmetric architectures for the XCASH SideChains…

HOWEVER, thanks to the technical contributions of the primary layer of the XCASH blockchain and its L1 DPoPS layer, it finally appears more relevant to plan a unique and specific design by “Inheritance” in order to optimize the performances, the possibilities of evolution and the scalability of the XCASH SideChains

The design per Inheritance

• The idea is to have several overlapping parts and layers that inherit characteristics from each other.
• The challenge is to make the design of the sidechains more like the API design from a code point of view than the classical blockchain design, in order to develop the elements and functionalities at a high level rather than in the lower layers.

What does this mean in concrete terms ?

• We have xcash-core which is responsible for the synchronization at the lowest level, as well as security and transmission.
• Then we have DPOPS which is essentially a layer above that and is the “connected consensus” that controls xcash-core
• So sidechains can naturally and natively inherit security and consensus from these two layers.
• Thus, at the DAG level (see quesako), we no longer need the consensus, thanks to the 50 validator delegates, already identified in the DPOPS layer. This allows the last block producer to get all the rewards for this 5 minute interval, and globally allows the 50 DPoPS delegates to execute a mutex (see quesako) in the code to verify each transaction.
• This unique custom design for XCASH will allow for extremely fast (~instantaneous) performance through this inheritance model.
• The tokens will be the trickiest part and their design will be closer to the design of standard sidechains.
  There will be a separate sidechain for each token, and they will not need to be verified by all the TOP50 delegates. There are still technical arbitrations to be made on how to best implement this mechanism, but it will certainly be more in line with standard technological designs in this area.

Some features

• DAG technology : Custom-built inheriting the consensus and security of DPoPS.
• Speed: Instantaneous
• Fee: Voted by Delegates [Weighted average of outlier-free fee proposals made by Delegates [could be subject to change in the future].
• Who gets the fees: All transactions go to the last block producer until the new one (5 minutes)
• How deposits and withdrawals work: verified by all delegates and sent by all signatory delegates.

Quesako ?

DAG

• DAG, Directed Acyclic Graph, is a data structure that uses topological order.
• DAG is a concept that appeared following the appearance of the concept of SideChains in order to eliminate the mining process and thus optimize the scalability of transactions.
• DAG is an implementation of the directed graph structure that is mainly used to solve problems of data processing, identification of the best path in navigation, planning and data compression.

MUTEX

• A MUTEX is a mutual exclusion object that synchronizes access to a resource. It is created with a unique name at the beginning of a program.
• The MUTEX is a locking mechanism that ensures that only one thread can acquire the MUTEX at a time and enter the critical section.
• This thread releases the MUTEX only when it leaves the critical section.

XCASH SideChains Demo Video

by Zach Hildreth, X-CASH CTO [Youtube Channel Zachy Zone]

Important Links

• Website : https://www.xcash.foundation/
• Join the community on Discord: https://discord.gg/8VD74ba
• Learn how to vote with your XCASH and get a passive income:
  https://docs.xcash.foundation/dpops/vote-and-staking.
• Visit the X-Bank: https://x-bank.io/.
• More links on X-Cash: https://linktr.ee/x.cash.