In the world of blockchain, hundreds of thousands of coins and tokens are mined or created every moment. Each of them plays different roles in the ecosystem. To increase the liquidity and make more people involved, exchanges are not only service providers but also important infrastructures. Exchanges that fully control users’ assets are called Centralized Exchanges (CEXs). On the contrary, exchanges that trade users’ assets under verifiable rules, and let users reserve full control over their own asset, are called decentralized exchanges (DEXs).
To increase liquidity, supporting more trading pairs is necessary. The assets in a trading pair might or might not belongs to the same network. When the assets are from different chains, things become a little tricky.
Trading on different chains
As we mentioned in Cross-chain Explained: Business Vision, CEX provides a smooth user experience by sacrificing an important factor: user’s authority. By doing so, orders can be matched by updating the account information, which does not have to be on-chain. Only when a user deposits to or withdraws from the exchange, the transaction will be broadcasted to the main net. Therefore, updating the information on different chains is not really a problem for CEX.
However, there should be a more ideal option to achieve trading on the blockchain. The strength of DEX is to make the trading being settled based on the execution logic that is defined on the blockchain. Therefore, when we are trading ERC20 tokens, these tokens can be traded by the rules that are defined on a smart contract. This is also the way how the DEXs on Ethereum works. By reaching the consensus on Ethereum, we can get the one and only result of execution.
How about the trading pairs that are not on the same network? As we mentioned, the accounting of CEX is achieved through information in the database. Results are settled to chain by CEX’s will. Just like when a group of people from different countries which speak different languages, CEX is the middleman that listens to the request and directly tells everyone what to do. On the contrary, DEX only takes actions based on verifiable rules and provided information. DEX should act as a coordinator, translate and provide the information to the group member and let them take action. Therefore, a mechanism to let the chains that involve in trading to communicate with each other is necessary. Without cross-chain communication, an ideal solution for a blockchain cannot be achieved.
Cross-chain communication
How to communicate between different networks? In other words, how to define communication among networks? Every action in a chain can be defined as a state transition. To get the one and only result, we need to reach a consensus among all the nodes in the blockchain. Therefore, we can say that communication is actually reaching a common state within a system. For example, when we trade ERC20 tokens, this can be done trivially since that Ethereum itself offers a consensus system to guarantee that resources can be synced. However, when we talk about inter-chain communication, what we need is reaching an inter-chain consensus. Notice how much effort we spent to make the nodes in the same chain to communicate and get a consistent state. And now, what we are talking about is to reach consensus with another chain. Is that really possible?
How can the consensus be reached between different chains? The most straightforward idea is that there is a node that runs clients of different networks, and the node is responsible for broadcasting the transactions that might influence the dependent states. However, relying on a single node can be dangerous, just like a centralized service. Some projects try to give a general solution by solving this problem by coordinating it with a decentralized structure and a bridging interface. Some projects simply use an oracle to achieve synchronization and wait for an ideal solution to be developed.
Another idea
Are there other options rather than syncing the states by another consensus system? Another idea is to sync the state by making the state-changing transactions to be executed simultaneously. If so, we can say that the service state remains synchronized, though the action might take place on different networks. This seems practical and more light-weighted, since that it does not require another consensus system. When the off-chain execution result needs to be committed back to the chain, how can the on-chain and off-chain synchronicity be guaranteed? If this is applicable, how to apply it to different chains? If we are able to deal with all these problems, the idea of a light-weighted solution for trustless-interoperability that is applicable for DEX is on the way.
In our next article, we will share the technical challenges we faced in the current landscape.
Links
- Official Website: dinngo.co
- Twitter: https://go.dinngo.co/twitter
- Contact Us: support@dinngo.co
