Anatomy of an Ethereum distributed exchange

Is it a good idea to store all data in a blockchain? What do you think?

Frankly speaking, it is a very bad idea. Mainly because a lot of data is transient, especially exchanges’ order books, and this doesn’t really need to freeze resources on thousands of blockchain nodes. What needs to be kept is a record of transactions resulting from a match between the asks and the bids. So, the best solution seems to be mixing transient and out of the blockchain order books and permanently in the blockchain for recording transactions. If in addition, the amounts take the form of cryptocurrencies, the settlement will also occur on the blockchain. Some distributed exchange architectures like 0x are designed along this pattern.

So, what is transient and out of the blockchain and what is in the blockchain?

Transient data: the order Book

The order book consists of two collections:
• The bids. This is the supply of the market.
• The asks. This is the demand side of the market.

People place ask orders to publish to the market what they offer. For example, Frank wants to sell a certain number of ethers (ETH) for a certain number of bitcoins (BTC). Let’s pretend, 100 ethers for 1 bitcoin. On the other hand, two persons post their offer to exchange bitcoins (BTC) for ethers (ETH).
• John offers 1 bitcoin to 100 ethers
• Jimmy offers 0.5 bitcoin for 100 ethers
Frank (the guy who want to sell ethers) order will be placed in the ask data collection and both John and Jimmy (guys who want to buy ethers with bitcoins) orders will be placed in the bid data collection. The ETH-BTC market will then be represented by two columns, one for the asks and one for the bids.

At first glance, there is a match with john’s offer for 100 ETH for 1 BTC. This will lead to a transaction and both orders are fulfilled and removed from the asks and bids columns. Jimmy’s offer will stay in the bids column.

Off course, exchanges matching mechanisms can be more sophisticated and be based on different algorithms. But, as you most likely noticed, the asks and the bids are transient data. People can modify their orders in the asks column when they can’t sell their coins within a desired period. They will do it until somebody finally matches the ask order. On the other hand, if the demand is very strong, the seller may fragment their order in smalls chunks and increase their price. This whole process is behind market dynamics. Sometimes orders are simply canceled and people wait until the market is more favorable.

Because the asks and the bids order are basically transient, they are preferably stored outside of the blockchain.

But when a match occurs, the transaction matching the ask order and the bid order can be permanently stored in the blockchain.

Permanent data: the transaction

Several centralized exchanges will never store their transactions in the blockchain. A new wave of hybrid distributed exchanges like 0x are appearing in the marketplace. In contrast to centralized exchanges requiring from their clients to deposit funds into the exchange’s account, 0x collection of smart contracts communicate directly with the token smart contracts. In addition, the transaction is also recorded into the blockchain. The internals of this choreography of smart contracts is described in 0x github repository. In fact, it is the structure of ERC20 implementations which makes this possible.

Each ERC20 token is managed with an implementation of the ERC20 interface. This interface became an overnight standard for newly created tokens on Ethereum. The ERC20 proposes a common interface for applications needing to perform transactions on their contained account. Can we get a clue of the ERC20 token implementation? hold on, we are getting there.

Behind the ERC20 interface lies a collection of accounts. A client application can perform transfer of funds from one account to another in that collection. So, let’s imagine that John as an account in an ERC20 Token named “Gizmo” (GZM), Jimmy also has an account in the very same token. We can represent a token like a small bank (sometimes containing several million as we noticed in the recent months). This token bank contains a collection of accounts. John and Jimmy have each an account in this token bank. John can transfer gizmos to jimmy with an application using the transfer function, part of the ERC20 standard. And if the gizmo token bank is “exchange” friendly, is support the transferFrom function. The latter allows an exchange to request the permission to transform from one account to another. In other words, a third party, the exchange, requests the permission to perform a transaction on two gizmo accounts.

To recap, the ERC20 offers a function transfer to applications, let’s say a wallet for instance. This transfer function simply transfers amounts from one account to another. It can also present a transferFrom function to, let’s say an exchange. The latter obtained a procurement to do so with the approve function giving the right to a third party to transfer funds from one account (john) to another (jimmy).


What is interesting is that this smart contract organization allows transfer of funds between token is exchange funds. And if we consider that each token has its own bank, then this application interface offers the potential to perform operations between token banks. This time, if we imagine that Lucy wants to exchange gizmo coins for yooo coins, then through the 0x smart contract kit makes it possible.


Synthesis

At the moment, the ERC20 interface is only popular on the Ethereum blockchain, more than 6592 tokens support this interface. Some are minimalist and support only the transfer function, others are exchanged friendly and support also the transferFrom and approve functions. The 0x smart contract kit hybrid solution combines the fast response of a classical centralized server based order book and the settlement on slower blockchain which contains already the token banks. We can think of the 0x kit as a token interbank exchange protocol.

The ERC20 interface and the 0x kit can potentially be ported on other blockchain supporting solidity as their smart contract language. For instance, it could be ported to the Rootstock (RSK) network. This network supports the solidity language which at the heart of the ERC20 interface. Since rootstock has bitcoin as its main currency (Ethereum has Ether), creating a new token bank would require some bitcoin value to do so. At the moment of writing these lines, 11 nodes were active with the new Ginger release. There is also QTum, another blockchain supporting the Ethereum virtual machine (EVM). It can potentially support a solidity ERC20 implementation.

In fact, having the same interface on different platforms could be a certain advantage, isn’t it?

Leave a Reply

Your email address will not be published. Required fields are marked *