Background
DEX is planned to be implemented as Iroha 2.0 module.
Action items
Problem
Decentralized exchange provides an ability to transfer assets between accounts in exchange for other assets. :
Peer to Peer Scenario
Plant UML
@startuml
Buyer -> Iroha: Place Exchange Order(20XOR, 100USD)
Seller -> Iroha: Place Exchange Order(100USD, 20XOR)
Iroha -> Iroha: Transfer 20XOR from Seller to Buyer
alt Success:
Iroha -> Iroha: Transfer 100USD from Buyer to Seller
end
@enduml
So Iroha should secure peer to peer exchanges across the ledger from malicious actions. In this case Iroha does a good job, the only thing it should check is an ability to transfer assets from and to accounts.
But there are more corner cases when we deal with exchanges via bridge:
Peer to Peer across Bridge Scenario
- Cross blockchain rates should be taken into consideration
- Iroha should prevent double spent of assets
- Additionally to transferring assets, Iroha should mint and de-mint them
Simple scenario:
Plant UML
@startuml
Buyer -> Iroha: Place Exchange Order(20ETH, 1BTC)
Seller -> Iroha: Place Exchange Order(1BTC, 20ETH)
Iroha -> "BTC bridge": Mint 1BTC to Seller
alt Success:
Iroha -> Iroha: Transfer 1BTC from Seller to Buyer
alt Success:
Iroha -> "ETH bridge": Mint 20ETH to Buyer
alt Success:
Iroha -> Iroha: Transfer 20ETH from Buyer to Seller
end
end
end
@enduml
Liquidity Pools is another dimension in this set of scenarios for Decentralized Exchanges. Basically it can be used in pair with or without bridges, so let's take a more clean example without them. But let's not stick to an Exchange Pair and work with multi-currency liquidity:
Plant UML
@startuml
"Liquidity Provider" -> Iroha: Register Exchange Liquidity [20XOR, 20ETH, 1BTC]
Seller -> Iroha: Place Exchange Order(1BTC, 20ETH)
Iroha -> "BTC bridge": Mint 1BTC to Seller
alt Success:
Iroha -> Iroha: Transfer 1BTC from Seller to "Liquidity Provider"
alt Success:
Iroha -> Iroha: Transfer 20ETH from "Liquidity Provider" to Seller
end
end
@enduml
From the high level perspective this scenario looks very similar with two previous because all of them are based on top of two Iroha functions:
- Assets Transfer
- Iroha Triggers
Resulting Behavior
Let's write all three scenarios as one feature description according to BDD with more details:
Click here to expand...
Feature: Decentralized Exchange
Scenario: Buyer exchanges 20xor for 100usd
Given Iroha Peer is up
And Iroha DEX module enabled
And Peer has Domain with name exchange
And Peer has Account with name buyer and domain exchange
And Peer has Account with name seller and domain exchange
And Peer has Asset Definition with name xor and domain exchange
And Peer has Asset Definition with name usd and domain exchange
And buyer Account in domain exchange has 100 amount of Asset with definition usd in domain exchange
And seller Account in domain exchange has 20 amount of Asset with definition xor in domain exchange
When buyer Account places Exchange Order 20xor for 100usd
And seller Account places Exchange Order 100usd for 20 xor
Then Iroha transfer 20 amount of Asset with definition xor in domain exchange from seller account in domain exchange to buyer account in domain exchange
And Iroha transfer 100 amount of Asset with definition usd in domain exchange from account buyer in domain exchange to seller account in domain exchange
Scenario: Buyer exchanges 1btc for 20eth across bridges
Given Iroha Peer is up
And Iroha Bridge module enabled
And Iroha DEX module enabled
And Peer has Domain with name exchange
And Peer has Account with name buyer and domain exchange
And Peer has Account with name seller and domain exchange
And Peer has Asset Definition with name btc and domain exchange
And Peer has Asset Definition with name eth and domain exchange
And Peer has Bridge with name btc and owner btc_owner
And Peer has Bridge with name eth and owner eth_owner
And eth Brdige has buyer Account in domain exchange registered
And btc Brdige has seller Account in domain exchange registered
When buyer Account places Exchange Order 20xor for 100usd
And seller Account places Exchange Order 100usd for 20 xor
Then Iroha mint 1 amount of Asset with definition btc in domain exchange to seller Account in domain exchange using btc Bridge
And Iroha mint 20 amount of Asset with definition eth in domain exchange to buyer Account in domain exchange using eth Bridge
And Iroha transfer 1 amount of Asset with definition btc in domain exchange from seller account in domain exchange to buyer account in domain exchange
And Iroha transfer 20 amount of Asset with definition eth in domain exchange from buyer account in domain exchange to seller account in domain exchange
Scenario: Buyer exchanges 20xor for 100usd
Given Iroha Peer is up
And Iroha DEX module enabled
And Peer has Domain with name exchange
And Peer has Account with name liquidity_provider and domain exchange
And Peer has Account with name seller and domain exchange
And Peer has Asset Definition with name xor and domain exchange
And Peer has Asset Definition with name btc and domain exchange
And Peer has Asset Definition with name eth and domain exchange
And liquidity_provider Account in domain exchange has 1 amount of Asset with definition btc in domain exchange
And liquidity_provider Account in domain exchange has 20 amount of Asset with definition eth in domain exchange
And liquidity_provider Account in domain exchange has 20 amount of Asset with definition xor in domain exchange
And seller Account in domain exchange has 20 amount of Asset with definition eth in domain exchange
When liquidity_provider Account registers Exchange Liquidity 20xor and 20eth and 1btc
And seller Account places Exchange Order 20eth for 1btc
Then Iroha transfer 1 amount of Asset with definition btc in domain exchange from seller account in domain exchange to liquidity_provider account in domain exchange
And Iroha transfer 20 amount of Asset with definition eth in domain exchange from liquidity_provider account in domain exchange to seller account in domain exchange
Solution
DEX realated entities could be represented via Iroha model (Domains, Assets and their definitions), while complex sequences of actions could be implemented via Iroha Special Instructions + Triggers.
Decisions
- Introduce a new module "DEX" with a dependency on "Bridge" module with additional set of Iroha Special Instructions and Queries and new Abstractions like Order (Combination of a Trigger and Asset with a predefined Asset Definition)
- Implement Use cases
- Implement Iroha Special Instructions DSL
Alternatives
- Provide out-of-the-box entities and instructions for DEX - breaks modular approach giving to much information about private API to DEX module and making it mandatory for all peers once it introduced to the ledger
- Make World State View public API - removes possibility to improve internal processes without breaking back compatibility
Concerns
- Users without deep knowledge of Iroha model and instructions may fail to implement this
Assumptions
- Iroha modules need to be optional Iroha features
- Iroha Special Instructions DSL is separated from execution implementations
Risks
- Given functionality will not cover all corner cases `[3;8]`
- Performance may be insufficient for DEX `[2;9]`