Community view | understanding the exchange protocol on mov chain


Community view | understanding the exchange protocol on mov chain

Development of decentralized exchange protocol

From bitshare, stellar to etherdelta, Bancor, 0x protocols on Ethereum, decentralized switching protocols have also gone through several generations of development and many modes of exploration. Each generation improves and deepens through the pain points of the previous protocols,

It can be divided into three parts

  1. On chain order book, on chain settlement;
  2. Offline order book and online settlement;
  3. Fund pool based on smart contract management;

On chain order book

Etherdelta is the first successful exploration of Ethereum based decentralized switching protocol, which once occupied half of the decentralized switching market It is a relatively complete decentralized mode, in which users recharge, list, bill, settlement and cash withdrawal are all completed on the chain.

The specific operation mechanism is as follows:

Community view | understanding the exchange protocol on mov chain

The whole operation of etherdelta is completed on the chain. Users keep their own private key, and the platform will not touch the user’s assets, ensuring the security and transparency of assets and exchange. But its disadvantages are obvious

1) Because all the exchange links are completed on the chain, and every operation such as order registration, order cancellation and bill taking will consume gas expenses, resulting in high delay and low cost-effectiveness.

2) The possibility of illegal pre exchange exists.

Offline order book, online settlement

In order to solve the problem of low efficiency and low handling charge in the pure chain, the concept of relay is introduced in the protocol. All orders are sent to the relay, and there is no need to be on the chain. Only the transaction will be on the chain.

The operation mode of “order relay under the chain and final settlement on the chain” of the system is as follows:

Community view | understanding the exchange protocol on mov chain

The main problem of the protocol is that if an order needs to be shared, every transaction of the exchange using the protocol needs to be broadcast so that other exchanges can know and confirm it. Therefore, the simple use of the protocol can not achieve instantaneous transaction. In addition, the need to convert eth into weth also increases the exchange cost.

Fund pool based on smart contract management;

The most typical capital pool models are Bancor and kyber. The so-called fund pool can be understood as a pool of various assets established by the platform using smart contracts. The providers of assets in the fund pool can be ordinary users or market makers.

Introduction of MOV decentralized switching protocol

When we examine various exchange protocols, in fact, the pure on chain exchange protocol is the most valuable solution for blockchain. However, because of the performance problems of Ethereum and other public chains, the pure on chain scheme like etherdelta is frustrated, and the offline orderbook like 0x appears to improve the performance. The fundamental reason is that the infrastructure is not perfect, which leads to the change. Therefore, compared with the original chain MOV, we started to solve the problem of blockchain performance from the beginning.

High speed side chain is the guarantee

Mov uses the high-speed side chain vapor Pro as the underlying infrastructure. Every 0.5s, the vapor blocks out, and each block can hold 8000 transactions, that is, 16000 TPS per second. In the case of increasing the block size and improving the node server, there is still room for further improvement. This performance can meet the needs of users in the current off peak period, and can be compared with the centralized scheme.

At the same time, MOV adopts dpos as a consensus mechanism. Although it loses a certain degree of decentralization, it increases the threshold for matchmaking on the chain. Raising the access threshold can better prevent some “miners” with bad intentions from trading in advance. At the same time, because matchmaking on the chain itself has a certain matchmaking income, this economic incentive can prevent dpos from breaking out The cost of doing evil is higher than the normal benefit of not doing evil.

Order sharing

In order to solve the performance problem, the offline orderbook is adopted in the protocol. However, the problem is the separation of orders. For their own interests, different participants in the protocol will not share their own orders, which will affect the overall transaction depth. While mov uses the online orderbook, all users’ orders are on the chain, which is open and transparent, and all participants can participate in the transaction This depth can be shared with the matching consensus nodes, so as to enhance the liquidity of assets on mov.

Advantages of magnetic contract

Because the original chain is based on the bitcoin utxo model, the magnetic contract on the utxo model has greater advantages as the exchange protocol. Because the utxo model itself takes assets as the basic unit, compared with the account model, the operation of assets is more simple and convenient. Let’s compare the two processes.

For example, the whole interaction process is as follows:

  • Maker grants DEX contract access to its own token a balance
  • Maker creates an order (the order has a fixed format) and signs it with a private key
  • Maker uses any means of communication to broadcast orders
  • Taker receives orders and is willing to execute them
  • Taker grants DEX contract access to its own token B balance
  • Tucker submit order to Dex
  • DEX verifies the legitimacy of the order and transfers between the two accounts according to the exchange rate on the order

Then the whole process of magnetic contract is much simpler

  • Maker creates a magnetic contract (put your own assets in the magnetic contract, and specify the assets and quantity to be exchanged)
  • Tucker creates a magnetic contract (puts his own assets in the magnetic contract, and specifies the assets and quantity to be exchanged)
  • According to the price and quantity in the contract, the consensus node triggers the magnetic contract that can be matched, and exchanges the assets of the two.

Not only is the process simple, but the service charge will also be lower because of the simplification of the process. We only need to charge the service charge when the user sets up the magnetic contract. In fact, we can also try zero service charge, because with dpos mode, the game between each node will not be too complicated about the service charge.

The ecology of cross chain assets

When we observe the current decentralized exchange protocol on Ethereum, we still stay in the ecology of Ethereum itself. Although we can’t deny that Ethereum’s ecology is powerful, it’s actually the bigger world outside. Of course, cross chain is the main theme of the follow-up, including cosmos and polkdot, who want to do cross chain things. Therefore, MOV has considered cross chain things at the beginning, and will be better than the original one through ofmf The assets outside the chain are mapped to the original chain, and then form a big ecosystem that includes all digital assets. Users experience the same experience as centralization in MOV, and can trade a variety of assets. These assets are not only in the ecosystem of a certain chain.

Detailed explanation of MOV magnetic contract

Let’s expand the MOV magnetic contract in detail to see how it is realized.

In essence, MOV magnetic contract is a contract with registered orders. Both takers and makers need to generate such a contract. In fact, they don’t distinguish maker and taker, but only distinguish maker and taker according to the first and later of registered orders. Both of them enhance the depth of transaction in the opposite transaction pairs. In fact, they are both makers.

The essence of the contract is to lock in any amount of asset a and be willing to exchange asset B at a specific exchange rate. There should be four constants in the contract (the ID of asset a does not need to be stored, because the contract locks asset a): the ID of the expected exchange asset B, the expected exchange rate (using the numerator denominator method to solve the floating point support problem), and the public key of the registered user, and the address of the registered user accepting asset B. Contracts can be unlocked in three modes:

Unlock all: asset a in all contracts is converted into asset B and transferred to the address of the registered user.

Partial solution: asset a in part of the contract is converted into asset B and transferred to the address of the registered user. The remaining asset a locks the new round contract itself (the newly generated utxo) through the recursive contract mode.

Cancel registration: the registered user transfers all asset a in the contract back to his address through private key signature.

The code of equity is as follows:

MagneticContract source code:
contract MagneticContract(requestedAsset: Asset,
                          ratioNumerator: Integer,
                          ratioDenominator: Integer,
                          sellerProgram: Program,
                          standardProgram: Program,
                          sellerKey: PublicKey) locks valueAmount of valueAsset {
 clause partialTrade(exchangeAmount: Amount) {
  define actualAmount: Integer = exchangeAmount * ratioDenominator / ratioNumerator
  verify actualAmount > 0 && actualAmount < valueAmount
  lock exchangeAmount of requestedAsset with sellerProgram
  lock valueAmount-actualAmount of valueAsset with standardProgram
  unlock actualAmount of valueAsset

 clause fullTrade() {
  define requestedAmount: Integer = valueAmount * ratioNumerator / ratioDenominator
  verify requestedAmount > 0
  lock requestedAmount of requestedAsset with sellerProgram
  unlock valueAmount of valueAsset
 clause cancel(sellerSig: Signature) {
  verify checkTxSig(sellerKey, sellerSig)
  unlock valueAmount of valueAsset


Fulltrade() is the full unlock method; partialtrade() is the partial unlock method. When the partial unlock is triggered, it will be said that the unlocked assets will be put into a new generated magnetic contract, so as to wait for the next matching; the cancel() method will transfer the user’s assets back to their own address and cancel the contract.

Let’s look at the input parameters of the magnetic contract

type MagneticContractArgs struct {
 RequestedAsset   bc.AssetID
 RatioMolecule    int64
 RatioDenominator int64
 SellerProgram    []byte
 SellerKey        []byte

Requestedasset is the asset to be exchanged, ratiomolecule and ratiodenominator is the exchange rate (ratiomolecule / ratiodenominator) of the asset to be exchanged Because the current BVM does not support floating-point type, it uses this parameter as the proportion. Sellerprogram and sellerkey are the contract and address of the contract creator, and the target asset must be locked into the contract creator’s own account.
Careful friends may find that there is one parameter missing from the equity contract, that is, standardprogram. This parameter does not need to be entered by the user, and the system will supplement it by default. Standardprogram actually represents the original contract, because partial matching will make some assets return to the contract even if they are not used.

Finally, let’s make a more straightforward description through a picture

Community view | understanding the exchange protocol on mov chain


Let’s compare several current decentralized exchange protocols

Exchange protocol pattern Degree of decentralization Cost effectiveness User experience
Etherdelta On chain order book ★★★★★ ★★
0x Offline order book, online settlement ★★★★ ★★★ ★★★★
Bancor Fund pool based on smart contract management ★★ ★★★ ★★★★
mov On chain order book ★★★ ★★★★ ★★★★★

Etherdelta, the earliest fully decentralized switching protocol, has the least interference to switching, but the mechanism of fully on chain makes the cost high and the experience poor. The following several types of decentralized exchange protocols are all trade-offs between the fish and the bear’s paw: the reserve pool model represented by Bancor and kyber has a high degree of participation by the administrator in the whole process. If the administrator’s authority in the reserve pool contract is high, for example, Bancor can take away the user’s assets before, it will pose a threat to the user’s capital security; the chain process of the two is relatively simple, and the cost is high The performance of this control is good, and the transaction efficiency is relatively high, but the functionality is slightly inferior to the exchange protocol with orderbook. In the relay mode of X, the platform does not touch user assets, and the degree of decentralization is relatively high, but it also leads to relatively low cost-effectiveness; the overall delivery experience is good, but if it needs to share orders, it can not achieve instant transaction.

On the basis of these predecessors, MOV improves the performance of infrastructure, improves the access threshold through dpos, and realizes the order sharing on the chain. It also improves the user experience. In addition to sacrificing certain decentralization through dpos, MOV has been improved in other aspects. With the further development and improvement of MOV, it will give full play to the advantages of the scheme and improve the user experience So that blockchain can play a huge value in the field of asset exchange, can make decentralized asset exchange landing.

Recommended Today

Source code interpretation of Dubbo layered design idea

1、 Overview of Dubbo layered overall design Let’s start with the following figure to briefly introduce the Dubbo layered design concept: (quoted from duboo Development Guide – framework design document) As shown in the figure, the RPC implemented by Dubbo is divided into 10 layers: service, config, proxy, registry, cluster, monitor, protocol, exchange, transport and […]