Foreword: Recently, the BSV incident in the currency has caused heated discussions in the currency circle. People's concerns about centralizedism and easy manipulation of centralized exchanges have intensified, and the demand for decentralized exchanges has become more urgent. In order to relieve everyone's doubts, this article will analyze the overall structure of the decentralized exchange, because the length is longer, it is divided into context, the following will be released tomorrow, so stay tuned. The author, Lindsay X. Lin, is a legal counsel at Interstellar and the Stellar Development Foundation, translated from the first class.
Decentralized exchanges are becoming an important tool for buying and selling more and more cryptocurrencies. The term "decentralized exchanges" generally refers to distributed ledger books and applications that enable users to conduct cryptocurrency transactions without the need to trust a centralized entity intermediary or its cryptocurrency custodian.
Advantages of decentralized trading
(1) Reduce the risk of counterparty (ie, no need to trust the centralized switch to protect and manage the private key);
- Centralized Exchange VS Decentralized Exchange Who is the future of cryptocurrency?
- Decentralized exchanges: Why do markets need them? (Part 1)
- DEX is very hot, and DEX has loopholes, saying that "preemptive trading" is a disease.
- Opinion: Is the long tail market the future of DEX?
- The second "uprising" of the exchange
- Read the classic design model of the centralized exchange
(2) reduce transaction costs;
(3) The transaction diversifies the portfolio and unlocks access to cryptocurrencies with higher risk or less liquidity. As the demand for these features increases, there may be significant growth in the use, development, and adoption of decentralized exchange technology over the next few years.
Disadvantages of decentralized exchanges
(1) The number of various cryptocurrencies has soared, making comprehensive listing unrealistic;
(2) The currency of the Shanghai Central Exchange is facing regulatory risks;
(3) The user needs to avoid more private and less review transactions in order to avoid the “know your customer” (KYC) of the centralized exchange.
Decentralized exchanges have significant differences in technology, trust, security, legal influence, and economic impact. These differences make some exchanges more or less suitable for a particular use case. The purpose of this paper is to explain the architecture of decentralized exchanges and the trade-offs between performance and security of various architectures. By understanding these technical differences, readers will have a better understanding of decentralized exchanges for different use cases.
Decentralized exchange structure
"Decentralized exchanges" are often used to describe blockchain-based exchange protocols, as well as applications that utilize these protocols. In other words, decentralized exchange agreements are software programs that are hosted on or integrated into one or more distributed ledgers (eg, Ethereum) that support automatic settlement of peer-to-peer transactions on distributed ledgers. The user retains the sole custody of the private key throughout the transaction process.
The decentralized exchange application is built on a decentralized exchange agreement and adds a chain or chain order database and a graphical user interface (GUI) or API to access information.
In general, the decentralized exchange application can be broken down into the following components:
1. Blockchain platform and technology implementation;
2. Counterparty discovery mechanism;
3. Sequence matching algorithm;
4. Transaction settlement agreement;
The four components of the decentralized exchange application may not be fully decentralized. For many decentralized exchange applications, one or more components may be chained/centralized, or otherwise provide economic incentives to promote a centralization trend.
We will discuss these components one by one and provide some examples of decentralized exchange agreements implementing these components.
1. Platform and technology compatibility
Typically, most decentralized exchange agreements operate on tokens that have the same technology implementation, and these tokens belong to the same distributed ledger platform. For example, AirSwap, EtherDelta, and 0x are separate protocols that can only be operated on Ethereum using standard ERC-20 tokens. Outside of Ethereum, Stellar's decentralized exchange can operate tokens posted on the Stellar network, while BitShares' OpenLedger decentralized exchange can only operate on tokens posted on the BitSharess blockchain platform. Encrypted currencies and assets under the chain can also be traded through Stallar or OpenLedgerd's decentralized exchanges, provided that the "anchor" is issued on the network, representing the ownership of the cryptocurrency defined by the chain. However, this requires users to believe that there is enough under-chain cryptocurrency reserve to satisfy all redemption token needs.
Some decentralized exchanges have begun to use atomic exchange to enable users to trade cryptocurrencies stored on different blockchain networks (for example, to exchange bitcoin for dogs from different blockchains). However, atomic exchange still requires the cryptocurrency of the transaction to comply with certain public technical standards. For example, in BarterDEX, a cross-chain decentralized exchange that allows users to trade cryptocurrencies from different blockchains, atomic exchange is only available for cryptocurrencies that implement the functionality corresponding to the Bitcoin reference implementation, such as BIP65 (Check LockTime Verify) and other standard Bitcoin API methods. In practice, this means that cryptocurrencies built on Bitcoin reference implementations, such as Litecoin and Dogecoin, or cryptocurrencies derived from Bitcoin, such as Bitcoin cash and Bitcoin gold, will be the easiest to be compatible with Bitcoin. Atomic exchange.
Cross-chain exchange technologies like Polkadot and Cosmos are also building tools and protocols that will eventually be integrated into decentralized exchange applications that automatically exchange tokens for different blockchains. However, due to the current latency of most cross-chain atomic exchanges (transaction confirmation relies on the acknowledgment time of the underlying blockchain of two cryptocurrencies), most popular decentralized exchange applications currently focus on only one chain of generations. Currency trading. With the improvement and development of cross-chain switching tools and protocols such as PolkaDot and Cosmos, as well as the upgrade of enhanced trading performance such as lightning and lightning, users will enjoy high-liquidity and low-latency cross-chain decentralized exchanges one day.
2. Counterparty discovery mechanism
The counterparty discovery mechanism enables the buyer to discover sellers who are willing to execute the transaction under conditions acceptable to both parties. In traditional cryptocurrency exchanges (such as Binance, Bittrex, and Kraken), users can submit both market orders and limit orders, which automatically match unidentified transactions through all user orders in the exchange's central limit order book. opponent.
Most decentralized exchanges also have an order book. These order books may exist on a chain hosted by a distributed ledger book or under a chain hosted by a third party. Most decentralized order books show individual orders for each counterparty, not aggregated orders for all counterparties. Users often need to identify a particular order to determine a particular counterparty in order to trade.
Some decentralized exchanges do not have an order book, but instead use a reserve-based model. The reserve provides a supply and demand relationship for various tokens. These tokens can be adjusted at any time based on the reserve and sell quotes for the token. The reserve is created by a smart contract on the chain that enforces the trading and settlement process. The transaction price can also be determined programmatically by smart contracts.
In the remainder of this document, the term "manufacturer" will refer to the party that provided the order, and the term "recipient" will refer to the party that filled out the order.
How does the order book on the chain work?
The order book on the chain is directly hosted on the distributed ledger: all orders are submitted to the distributed ledger network and confirmed by the network. Anyone can host and access a copy of the order book, and as long as the distributed ledger is public, anyone can submit their own order and add it to the order book.
Examples of order books on the chain include BitShares and Stellar Decentralized Exchanges. In the Stellar network, user-submitted orders are hosted on a persistent and public chain order book in the Stellar distributed ledger. Information about this order will be broadcast to all Stellar verifier nodes and will be viewable by the public. When the prices of the two orders intersect, the Stellar network automatically executes and settles. BitSharess decentralized transactions are conducted in a similar mode, but for the BitSharess blockchain and network.
• Less review: Less dependent on the centralized party to host and operate orders. The order book may have a centralized GUI, but any independent party can create a separate GUI and populate it with data on the chain. Assuming that the ordering and operation of the order is distributed on a separate, non-collusion verifier node, there is no centralized attack point, compromise point or responsibility point, and the order will not be closed or the specific order will be restricted by the centralized party. Happening.
• Less trust required: Decentralized, on-line order book hosting means that there is no need to rely on centralized, offline participants to accurately and reliably publish or broadcast order books.
• The order book inherits the performance, cost, and security characteristics of the underlying blockchain: the speed and cost of submitting or deleting quotes on the chain order book is limited by the speed and cost of interaction with the underlying blockchain. The user must pay for each order update on the network, wait for the network to agree on its update, and then wait for the security confirmation update. If the blockchain is attacked, the order book may also be attacked. Therefore, slower and higher cost blockchains are less suitable for hosting user-friendly chained order books.
• Slower updates: In the absence of Layer 2 technologies (such as lightning networks or lightning networks), on-chain orders are typically updated based on information contained in the latest block or ledger. This will create a delay, ranging from a few minutes to a few seconds, depending on the platform. Conversely, since most of them only need to change the centralized database to update, the chain order book can support almost instant updates.
• Stale orders: Decentralized exchanges on the chain typically support dormant orders, where the price and quantity are determined by the manufacturer at the time the offer is created. In the dormant state, if the manufacturer does not wish to trade under these terms (for example, the price has changed dramatically), then he must voluntarily cancel the offer. Since the transaction verification speed of the underlying network can cause delays to update the order on the chain, an order on the chain can create an environment to use a dormant order in the event of high price fluctuations. However, with the increasing use of orders on the chain, we hope that trading tools (such as trading robots) will be added and adopted to help users automatically submit and cancel orders programmatically when market prices change.
How does the chain order book work?
The order book under the chain refers to an order book that is hosted by a centralized entity other than the distributed ledger. The centralized entity helps the parties discover other parties who quote the asset and restricts access to view or submit the order.
The usefulness of the chain or chain order book depends to a large extent on the performance of the chain. Decentralized exchanges typically do not use on-chain orders because each order and adjustments to the order on the chain require an update of the blockchain, resulting in transaction costs and waiting times. In some chains, transaction costs are negligible and latency is measured in seconds. In this case, the on-chain order book is suitable for a medium number of intermittent orders. In contrast, in the Ethereum blockchain, transaction costs are expensive and waiting times are in minutes. Using Ethereum's chained orders can result in expensive transaction costs and extremely short waiting times. For this reason, Ethereum – 0x, AirSwap, EtherDelta and Idex, the four most famous decentralized exchanges, use chain orders. As of October 2018, 0x, AirSwap, EtherDelta and IDEX support ERC-20 tokens.
· In the 0x ecosystem, entities called “repeaters” place orders, manage and publish orders. The manufacturer submits the purchase order directly to the repeater, who aggregates all orders received into his order book. The recipient finds the manufacturer's order by querying the repeater's order book. After finding the appropriate order, the recipient fills in the order based on the information submitted by the 0x agreement for the 0x exchange contract on the Ethereum blockchain. Since all repeaters use the 0x protocol for settlement, repeaters can choose to share their order books with other repeaters, unlocking more order books and greater liquidity.
· On the AirSwap platform, the manufacturer will submit a "transaction intent" for a particular pair of transactions to an entity called "indexer." The indexer will summarize information about the dealer and its trading intent. The recipient who wants to trade a pair of trades will query the indexer to find the identity of the appropriate bookmaker, using the indexer as the counterparty discovery mechanism. Once the recipient finds the right manufacturer, they will negotiate the terms of the deal off-site and may use the “forecast” input to provide fair pricing advice for the transaction. Once the manufacturer's response satisfies the recipient, the recipient will submit the order to the Ethereum blockchain.
· On the EtherDelta web application, in order to complete the order, the manufacturer and the recipient will deposit the token from the Ethereum wallet into EtherDelta's chain smart contract. The manufacturer will submit the order to EtherDelta's chained order book and broadcast the order book, which will be incorporated into the blockchain to verify that the manufacturer has sufficient balance in the smart contract to complete the order. The recipient will then select an order and click on "Buy" on the web application to execute the transaction with the EtherDelta Smart Contract.
· On the IDEX web application, in order to complete the order, the user will deposit the token from the Ethereum wallet into the IDEX smart contract. The user then places the buy and sell order in the chain order book using the IDEX application interface. IDEX and EtherDelta have a similar structure, both of which integrate chain-to-chain orders with on-chain smart settlement contracts, but IDEX adds a “transaction processing arbiter” to help manage pending trade orders to confirm transactions in the correct order. Therefore, when the user makes a transaction, the IDEX application interface will update the displayed balance in real time, but since the transaction needs to be queued, the on-chain settlement may be delayed. By controlling the order of transactions, IDEX separates transaction execution from transaction settlement, making the user experience smoother.
Having a chain to place an order has both advantages and disadvantages.
· Performance improvements: The chain order book is better suited to fast order turnarounds. Instead of waiting to dig out and confirm a block (or update a ledger) to update the order book, the under-chain service can update the general ledger almost instantaneously.
· Improve costs: There is no transaction fee to submit or update an order.
· The order book has fewer blockchain native risks: the managed order book is hosted under the chain, the order is not subject to the original vulnerability of the blockchain such as 51% attack (user may reverse trade), mouse bin (user can Submitting higher transaction fees gives them faster packaging or update speeds).
· Compatible with all ERC-20 tokens: Any token with ERC-20 technology implementation can be traded on these decentralized trading agreements. Tokens do not necessarily require any approval, audit or review by anyone to trade.
· A higher level of trust is required: the user must rely on the host of the order book to properly broadcast the order. However, the underlying host may not be able to accurately display and update orders, so users cannot rely on these hosts to discover counterparties. Worst of all, these hosts can arbitrarily review valid orders or manipulate the market by planning to display inaccurate or outdated orders. In addition, the hacker can change the chain order interface and manipulate the user to send the cryptocurrency to the hacker's cryptocurrency account.
· Greater Restrictions: As a centralized entity, orders placed in the chain of operations may be subject to greater legal and regulatory requirements, such as understanding the fulfillment of your customer's needs and obtaining the necessary authorizations and licenses required to classify transactions into securities. And enforce rules and strategies that are resistant to market manipulation. While these requirements help prevent illegal and abusive use of orders, they may raise concerns about transaction privacy, open accessibility, and user experience.
· Inaccurate order: The time when the manufacturer submitted the order and the recipient completed the order did not match. When a recipient wants to fill out an order, all of the given orders displayed on the chain order book may be out of date. For example, the manufacturer may have withdrawn the token she wants to trade, but her order is still being released by the relayer. Therefore, the recipient may attempt to fill out the order by submitting a transaction to the blockchain, but eventually finds that the order has expired. This can delay the recipient and consume a lot of transaction costs.
In addition to the order on the chain and the order placed in the chain – no (or hidden) orders: liquidity reserve
In order to solve the problem of low liquidity, some decentralized transaction protocols, such as KyberNetwork, Bancor and Omega One, establish or utilize liquidity reserves, which are readily available when users wish to exchange tokens. The performance of these models depends on reserve depth/broadness and accurate quotes.
· In KyberNetwork, “reserve contributors” contribute tokens to build “reserves” of various tokens. For each transaction pair, each reserve has a conversion rate that is dynamically managed by the reserve manager. If the user wants to exchange token B with token a, she will send the token to the KyberNetwork smart contract, and KyberNetwork will find the best exchange rate for her according to the reserve manager. If the rate meets the user's predefined minimum requirements, the smart contract will send the corresponding number of tokens B to the sender's pre-designated address. Users can also view and approve the worst-case rate before sending any tokens.
· In Bancor, users can exchange tokens for other tokens through a smart contract called “smart tokens”, which store ERC-20 tokens and ether. To illustrate this, users wishing to exchange token B with token A need to find a smart contract (ie, smart token AB) that stocks the AB token. The user sends the token A to the smart token AB to purchase a certain amount of smart token AB according to the formula price of the token A. Next, the user will send the smart token AB to their smart contract to destroy the tokens and take a large amount of B tokens based on the formula price of token B. The price is determined programmatically by a formula that combines the reserve supply of each token with a constant reserve ratio.
· Omega One's goal is to aggregate the liquidity between cryptocurrency exchanges by using the entire centralized and decentralized exchange environment as a potential reserve. Users who want to exchange token B with token A will store token A in Omega One's chain smart contract and submit the order to transaction token B based on time and price restrictions. Omega One will then use its own centralized and decentralized exchange account to purchase token B and exchange token A with the user via a smart contract.
· Less trading friction: Since both the supply and demand have fixed trading terms (such as reserves) and can trade at any time, the reserve model makes it easier for users to trade. This eliminates the friction that can arise when a counterparty is discovered and negotiated.
· Need to trust smart contracts or third parties: This model requires a party to trust a smart contract that is fulfilling a subscription or execute order function, or to trust the security, accuracy, and fairness of a third party. Because smart contracts are complex, difficult to audit, and there may be unforeseen security breaches, users may lose money if they are hacked or cheated on their own. Models that rely on third-party liquidity, such as KyberNetwork and Omega One, require users to believe that these third parties can act reliably and fairly.
• Uncertain pricing: Due to the volatility of token prices, some models require users to trust a central body to provide fairness and pricing updates. At the same time, models that rely on deterministic pricing algorithms are easily exploited by arbitrageurs.
· tend to support large reserve contributors: because lower trading spreads will require higher trading volumes to be profitable, and a reserve model that relies on user-provided funds may be more motivated than those with fewer reserve contributors Larger reserve contributors. In this case, the user may need to rely on the participation of a large number of types of reservers to obtain liquidity, thereby providing more centralized control over the reserve supply.
· There may be reserves and liquidity only for the most popular tokens: new or foreign tokens may not have available reserves, or there may not be enough reserves to complete the price and volume transactions based on user expectations. Only the tokens that are traded frequently have the potential to have a deep liquidity reserve.
Source of this article: First class warehouse
This article is from Lindsay X. Lin, translated from the first class. For reprint, please indicate the source!