Whitepaper draft

Whitepaper draft for the Enon decentralized exchange. This is a high level overview of the planned DEX's architecture. The finalized whitepaper will be up on December 15th.

Abstract

A multi-assets cross-chain decentralized exchange would allow assets from different blockchains to be exchanged directly from one address to another without going through a centralized point of failure. Atomic swaps provide part of the solution, but benefits are lost if it isn’t compatible with non-segwit blockchains with limited trading features and availability compared to a centralized exchange counterpart. We propose a solution to the decentralized exchange limitations using a two layers solution with the Gateway, the first layer, leveraging multisignature supported blockchains that guarantee secure deposits, withdrawals and IOUs issuance and Trading floor, the second layer, which operates on the Enon blockchain and provides high performance and cost efficient trading with trading fees that are redistributed to incentivize all participants to exhibit desired behavior.

Introduction

Bitcoin was the first successful attempt at a trustless version of electronic cash to be sent directly from one party to another making third parties obsolete. Bitcoin’s open source nature empowered anyone who shared the same vision to build upon its source.

A few years after its release, Bitcoin succeeded in more than just its vision; it introduced the world to a decentralized ideology. Litecoin is one of the early Bitcoin adaptors, which modified bitcoin’s settings and changed its hashing algorithm with a goal of maximizing the proof-of-work efficiency and increasing transactions per second. As a leading pioneer in the industry, Litecoin encouraged others to experiment with bitcoin’s technologies and discover new and innovative solutions which led to the growth of the cryptocurrencies and assets market. The growth of the number of crypto-assets created a new need for the market. The need for a way to exchange digital assets.

Current solutions use centralized exchanges, which hold the consumer assets and act as third parties for the exchange of users’ assets. The CEX is an imperfect solution for exchanging assets that are decentralized in nature.

Other solutions and decentralized exchanges only support assets that exist on their native blockchain and can’t be used for cross-chain trading. There isn’t a DEX solution for cross-chain assets exchange due to the difficulties and different conditions associated with each blockchain and their consensus algorithms.

Enon is designed to be a trustless and fully decentralized crypto-assets exchange that addresses the current market demand for a fast, trustless and modular exchange that can easily integrate assets from different blockchains without facing problems with different network requirements like different confirmation time, security requirements and congestion issues.

Physical layer

The physical structure of the network, the escrow node architecture in terms of which software components it should contain, the initial hardware requirements and specifications and the software components of the end user (client), which will interact with the network.

a) Escrow node software components

The software components required for each escrow node are the following:

• A cryptocurrency node for each supported cryptocurrency (blockchain) - the type of cryptocurrency node is to be determined, but the plan is to use pruned nodes to take advantage of the reduced hardware requirements.

• Node for the Enon (internal) blockchain

• Software for service discovery (node discovery)

• Software for managing the deposits and withdrawals from the users and nodes for the deposit/withdrawal blockchain. This blockchain may be part of the Enon blockchain as it is also an internal blockchain.

The Enon blockchain will be developed using the hyperleger fabric framework and will be used for cryptocurrency trading. The orderbooks and IOU specifications and details will be kept on this blockchain. The exact consensus algorithm and specifications are to be determined.

Service (node) discovery software will be developed for escrow node discovery and communication between the nodes. Existing technologies and principles will be used, but new components will be built on top of that due to the specifics of the blockchain.

Deposits and withdrawals will be managed by each escrow. A blockchain dedicated to storing the user deposit and withdrawal transactions will be used, which may be a part of the Enon blockchain or may be its own separate sidechain.

b) Escrow node hardware requirements and specifications

The hardware requirements and specifications for running all the software packages required for each escrow node are to be determined. More tests are needed to determine the exact minimal hardware requirements, which depend on the type of cryptocurrency nodes in use, the internal blockchain, as well as the deposit/withdrawal management blockchain. All of the software components will be packaged using docker images and recipes (docker-compose file) for easy deployment of the provided escrow node software.

c) Client software components

The client’s software components consist of the Overhold wallet and the logic behind the Overhold wallet. The wallet will provide the exchange view to end users where they can interact with the exchange. This software component will enable deposits, withdrawals, and general interaction with the escrow nodes of the exchange.

Logical layer

The logical layer of the exchange, in general, can be divided into two parts: the gateway and the trading floor. These parts will be briefly described in the following sections.

a) Gateway

The gateway represents the user’s deposits and withdrawals on the exchange. This process is managed by the escrow nodes. Separate blockchains for withdrawals and deposits will be used to store the user withdrawal and deposit requests and transactions, as well as keep the deposited money safe in case of “dead” escrow nodes. Multisignature addresses and transactions will be used for withdrawals and deposits The exact multisignature schema (M of N) will be determined after the final analysis, but up to 20 public keys can be used to generate multisignature addresses and sign transactions doesn’t change much because the blockchain for deposits and withdrawals, along with the custom service discovery, provides security and enables us to use the multisignature feature in a randomized manner.

Deposits

To begin using the exchange, the user must deposit the assets they are trading to an address provided by the escrow, which is part of the exchange. The provided address is a multisignature address generated by the escrow. The multisignature address is generated in a randomized way: the escrow, which interacts directly with the end user, randomly collects the public keys of N-1 active escrows (N public keys total, including the pubkey of the “host” escrow itself), using the service (node) discovery, generates the address and makes it available to the end user for the deposit. After the deposit, an entry (transaction) in the internal deposit/withdraw blockchain is created with the multisig address, redeem script, deposit address, and other fields necessary for a complete transaction. A transaction is created in the Enon blockchain for assigning the deposit address X amount of IOU tokens, corresponding to the deposited amount.

Withdrawals

Withdrawal of user assets can be requested at any time by the end user. For a withdrawal to happen, the end user creates requests to some of the escrows (it doesn’t necessarily need to be the same escrow with whom the client interacted with for the deposit). The escrow looks for entries in the Enon blockchain for the IOUs owned by the requester as well as the deposit/withdrawal blockchain to find the requester’s deposits and any other escrows that interacted with the requester’s deposits. This data is internally processed by the current escrow which is contacted by the requester and if everything is valid a transaction for the withdrawal is created to the requester which needs to be signed by multiple escrows (who will prove the validity of the withdrawal, before signing). Finally, the transaction will be broadcast to the cryptocurrency node for the corresponding withdrawal asset.

b) Tradingfloor

The trading floor consists of components necessary for asset trading. The trading floor is represented by the Enon blockchain, which will use the hyperledger framework. Order books, as well as the IOU token specifications, will be kept on this blockchain. IOU tokens will be introduced on this blockchain and will be used as a 1:1 mapping for cryptocurrencies. Transactions will be created for assigning IOUs to specific users, burning IOU assets after withdrawal, as well as trading transactions. The trading floor is not dependent on any external blockchain which enables fast trading and high TPS. The Enon blockchain parameters and consensus algorithm are to be determined as more testing is needed to determine the optimal speed/stability ratio.

Network Incentives

Fees from trades and withdrawals will be redistributed to incentivize all participants to exhibit desired behavior. The definite economic model, including the node feedback and sanctions model, will be determined after more research is conducted about the tokenomics and the network incentives’ possible effects and side effects.