TRC127: Market based on system contracts

[sean-liu55]

tip:127
title: Market based on system contracts
author: sean Liu <liu.sean@tron.network> 
discussions to: https://github.com/tronprotocol/TIPs/issues/127
status: draft
type: Standards Track
category: TRC
created: 2020-01-20

Simple Summary

This TIP provides system contracts for the market in java-tron.

Abstract

This TIP provides system contracts to support the exchange of token, including TRX and TRC-10. The main features include an online order table and online matching.

Using the online order table is one of the biggest features of this project, because of that, all order information is transparent and can be checked. At the same time, it also provides online matching functions, this means it does not rely on an offline centralized matching system, completely decentralized, which is safe and reliable. To achieve these, an innovative trading protocol is adopted, and greatly improves the efficiency of matching transactions. In addition, compared with the smart contract form, the form of built-in system contracts consumes fewer system resources, so the fee is greatly reduced.

Motivation

Security, transparency, and efficiency have always been at the core of DEX, but exchanges in the form of smart contracts often rely on offline matchmaking systems.

In addition, the higher costs also lead to users avoiding frequent transactions as much as possible, reducing the overall transaction volume.

Rationale

The core of the project is how to store the online order table. A double-link list scheme is proposed. For a price pair, all prices form a linked list and all orders of the same price form another linked list. Compared with a linked list structure with only one layer, it can greatly reduce the number of queries.

Another core issue is how to sort it on the chain. The pre-calculation method is adopted here, that is, the user first obtains the price position information when creating a transaction. Considering that a large number of transactions occur at the same time, the redundant processing of position information is the key to the design.

Specification

Only two system contracts are added, which are convenient and simple to use.

Create new order：

message MarketSellAssetContract {
    bytes owner_address = 1;
    bytes sell_token_id = 2;
    int64 sell_token_quantity = 3;
    bytes buy_token_id = 4;
    int64 buy_token_quantity = 5;
    bytes pre_price_key = 6;
}
Parameter：
owner_address：owner address 
sell_token_id：sell token id   
sell_token_quantity：sell token quantity           
buy_token_id：buy token id         
buy_token_quantity：buy token quantity
pre_price_key:order price position

Cancel an order:

message MarketCancelOrderContract {
    bytes owner_address = 1;
    bytes order_id = 2;
}
Parameter：
owner_address：Owner address
order_id：order id

A set of query interfaces is also provided.

Get all orders for the account:

rpc GetMarketOrderByAccount (BytesMessage) returns (MarketOrderList) {};

Get all orders for the trading pair:

rpc GetMarketOrderListByPair (MarketOrderPair) returns (MarketOrderList) {};

Implementation

coming soon

Copyright

All content herein is licensed under Apache 2.0.

[shydesky]

"Market based on system contracts" what's the meaning of the Market? As far as I know, we have already the ability to do tokens exchanging based TRC-10 on the blockchain now. So does the Market have any relationship with the existing exchange?

[sean-liu55]

The scheme proposed here contains “an online order table and online matching”, existing bancor-based exchanges do not have this feature. Which is more similar to that of an ordinary exchange.
Both exchanges can provide trading functions but are not directly related

[sean-liu55]

When the trading transaction is frequent, the pre_price_key pre-calculated by the user may be useless and lead to an impact on performance. A new scheme using the key-sorting feature of level DB is adopted, and we design a custom comparator to adapt the double parameter price presentation.
The pre_price_key in MarketSellAssetContract is removed, and users no need to calculate this parameter.

message MarketSellAssetContract {
    bytes owner_address = 1;
    bytes sell_token_id = 2;
    int64 sell_token_quantity = 3;
    bytes buy_token_id = 4;
    int64 buy_token_quantity = 5; 
}
Parameter：
owner_address：owner address 
sell_token_id：sell token id   
sell_token_quantity：sell token quantity           
buy_token_id：buy token id         
buy_token_quantity：buy token quantity