Getting started with DEX

What is DEX?

DEX 란 Decentralized Exchange 의 약어로 중간자 없이 가상화폐 지갑과 지갑 사이의 p2p 교환을 해주는 것이다.

DEX 에서는 custody 즉, 누가 거래에서의 키를 보관하는가에 대한 중대한 이슈가 있으며, DEX 는 모든 교환과정에 있어 개인이 키를 소유하고 완변하게 decentralized 되 토큰의 교환을 하는 것에 그 목적이 있다.

Basic Procedure

본 프로젝트에서 DEX 의 기본적인 프로세스는 다음과 같다.

먼저, 브라우저 상에서 토큰의 교환을 원하는 사용자가 매도 혹은 매수 주문을 걸면, 해당 주문정보를 EIP 712 로 서명한 서명정보와 함께 전달하면, Relayer API 를 통해 해당 기록이 off-chain 상의 orderbook 에 기록되게 된다. 그 이후, orderbook 을 조회하여 여러 주문들의 쌍을 받아와 교환이 가능한 거래쌍을 선정하여 스마트 컨트랙으로 전송한다.(즉, 하나의 taker order와 하나 이상의 maker order 들을 전달하며, 모든 주문은 서명이 완료된 주문이다. 여기서, 전송을 하는 과정에 있어 주문에 필요한 다양한 정보들을 전부 parameter 로 전달하면 gas 비 문제등 많은 문제들이 존재하기 때문에, 거래에 필요한 데이터를 data 라는 필드로 만들어 OrderParam 에 포함하여 전달한다.

또한, 위 과정을 진행함에 앞서 실제 거래의 주체가 아닌 relayer 를 통해 자금을 교환하기 때문에 플랫폼에서 만들어둔 relayer account 를 approve 하여 일정 자금에 대한 사용권한을 주어야 한다.

스마트 컨트랙에 전달된 인자들이 들어오면, 컨트랙은 주어진 주문 쌍을 분석하여 거래를 진행하기 위한 Result 들의 집합으로 나누고, 해당 주문을 filled 라는 orderHash:amount 쌍에 기록한다.

Smart Contract

주문의 전달

모든 주문은 Order Server 내의 orderbook 에 기록되고, 매칭이 가능한 조합들을 모아 스마트 컨트랙트의 matchOrders 를 호출하며, 그 인자는 다음과 같다.

OrderParam memory takerOrderParam,
OrderParam[] memory makerOrderParams,
OrderAddressSet memory orderAddressSet

여기서 order param 은 주문에 필요한 maker와 taker 의 요청정보이며, 그 형태는 다음과 같다.

OrderParam

struct OrderParam {
    address trader;
    uint256 baseTokenAmount;
    uint256 quoteTokenAmount;
    uint256 gasTokenAmount;
    bytes32 data; # 주문정보를 조합하여 32byte 로 축약, 가스비 절약 목적
    OrderSignature signature; # EIP 712 서명
}

위에서 base token 과 quote token 이 무엇인지 헷갈릴 수 있는데, taker가 매도 혹은 매수를 할때 기준이 되는 토큰을 base token이라고 한다. 즉, taker 가 특 정 토큰을 구매한다고 하면 그 구매의 대상이 되는 토큰을 base token 이라고 하며, 판매를 한다고 하면, 판매의 대상이 되는 그 토큰을 quote token 이라고 한다.

또한 여기서 OrderSignature 는 브라우저가 생성하고자 하는 주문정보를 EIP 712 로 서명한 서명정보로 추후 스마트 컨트랙트에서 해당 사용자의 주문정보를 해시하여 위 시그내처를 통해 유효성을 검증하는 과정을 거친다.

---

인증과정에서의 데이터의 흐름

사용자의 orderParam 쌍 => param 의 data property 에서 order rebuild => EIP712 hash 를 orderParam 의 signature 로 validate

---

* 여기서 signature 의 목적은 무엇일까?

여기서 signature 는 사용자가 본래 요청하고자 했던 주문정보가 스마트 컨트랙트에서 체결되는 시점에도 해당 사용자가 요청한 주문과 내용이 맞는지 검증하는 것이다.

가령, DEX 에서 두 사용자가 거래를 진행할때 다른 사용자가 특정 사용자의 계정을 스마트컨트랙에 거래를 요청하는 경우, 주문정보가 동일하더라도 주문을 작성한 유저가 요청한 주문이 아니므로 거래가 이루어 져서는 안되며, 특정 주문내용을 바꾸어서 컨트랙트에 체결을 요청하는 등 다양한 악용을 막는 역할을 수행한다.

* EIP 712 란 무엇인가?

EIP 712 란 Ethereum Improvement Proposals 712 의 약어로 이더리움에서 향후 지원하게 될 다양한 제안들중 하나이다. 과거 사용자가 어떤 거래를 함에 있어 sign 을 할때에는 sign 의 대상이 되는 message 가 hash 화 되어 존재하기 때문에, 서명을 하는 사용자가 자신이 서명하는 내용에 대해 잘 알기 힘든 문제가 있었으며, 가령 유사한 해시값을 가진 피싱 사이트로 유도하여 사이닝을 유도한다던가 하는 다양한 위험에 노출되어 있었다.

이를 해결하기 위해 안전하고 값이 변조되지 않는 해싱을 보장하면서도 readability 를 가질 수 있는 서명방법을 고안하게 되었으며 그 제안내용이 EIP712 에 제안되었다.

EIP712 를 통해 사용자는 자신이 서명하는 정보에 대해 명확하게 인지할 수 있게 된다고 볼 수 있다.

EIP 서명의 절차에 대해 간략하게 소개하면, 먼저 서명을 하고자 하는 데이터의 형태를 정의하는데 이러한 typed structured data 를 먼저 정의하는 것으로 서명이 시작된다. 데이터의 정의가 완료되면, 여러 DAPP 들 사이에 구별되기 위한 domain separator 를 정하여 서명을 검증할 스마트 컨트랙트의 주소부터 version, salt 등의 데이터로 구성된다.

EIP 서명이 완료되면, 사용자는 signature 를 얻게 되며 추후 스마트 컨트랙트는 주문정보를 직접 해싱하여 사용자가 제공한 signature 로 validation 을 진행하여 유효성을 검증한다.

거래의 체결

matchOrders 함수가 호출되는 시점에 매칭된 오더들의 정보가 filled 에 orderHash:filledAmount 의 mapping 형태로 기록되며, 만약 주문이 체결되었다면 기존에 있던 주문들에 새로운 주문이 발생하면서 체결이 될 것이다.

여기서 기존에 있던 주문을 한 사용자를 maker 라 칭하며, 주문을 체결하는 주문을 발생시킨 사용자를 taker 라 명명한다.

또한, 거래의 특성상 taker 가 넣은 주문을 만족시키는데 필요한 하나 이상의 주문이 필요하게 되므로 주문이 매칭 될 때에는 하나의 taker 주문에 한개 이상의 maker 주문이 매칭된다.

Taker 의 매도 주문

taker 의 매도주문으로 인해 주문이 체결되는 경우의 시나리오는 다음과 같으며, n개의 거래쌍이 이루어 졌다고 전제한다.

1. maker 가 relayer 에게 만족하는 quote token 과 maker fee, maker gas fee(maker rebate fee 는 차감한다.) 를 n번 지급한다.
2. taker 가 maker 에게 만족하는 base token 을 n번 지급한다.
3. relayer 가 taker 에게 만족하는 quote token 중 taker gas fee 를 제하고 1회 지급한다.

Taker 의 매수 주문