관리 메뉴

멍개의 연구소

[블록체인] 블록체인 시스템은 어떻게 구축할까 1편 - exchange, wallet, payment에서 transaction 취급방법 본문

블록체인

[블록체인] 블록체인 시스템은 어떻게 구축할까 1편 - exchange, wallet, payment에서 transaction 취급방법

멍개. 2022. 8. 27. 16:40

▶ 서론

블록체인의 가장 큰 단점은 처리속도가 느리다는 점 입니다!!

처리속도가 느리다는건 transaction을 처리하는데 소요 시간이 든다는 점 입니다. 이러한 특징 때문에 블록체인 기반 어플리케이션은 transaction 처리를 많이 고민해야 합니다. 또한, 모든 어플리케이션이 transaction을 같은 형태로 처리하지 않습니다.

블록체인 기반의 어플리케이션을 만들게 되면, 블록체인과 데이터베이스의 동기화가 중요합니다. 그렇기 때문에 시스템 특징에 따라 transaction 관리방법을 달리합니다.

필자는 블록체인 기반의 유통 시스템, 평가 시스템 등 다양한 시스템을 구축하면서 transaction 처리 방법에 대해 많은 연구와 고민을 하였으며, 이번글에서는 큰 차별점을 가진 거래소, 지갑, 암호화폐 기반 결제 시스템의 transaction 처리 방법을 소개합니다. 또한 해당 시스템의 기본적인 구조도 함께 소개합니다.

( 참고로 필자는 현재 거래소와 암호화폐기반 결제 시스템 및 지갑을 개발하고 있습니다.)

1. 거래소(exchange)

가장먼저, 거래소 시스템에서 transaction을 어떻게 관리하는지 알아보겠습니다.

거래소는 발생된 모든 거래 내역은 블록체인에 저장하지 않습니다. 거래소에서 대표적인 기능을 알아보겠습니다.

· 1.1 거래소 대표기능

[그림 1.1] 거래 페이지
[그림 1.2] 출금 페이지
[그림 1.3] 입금 페이지

1. 코인/토큰 매매 등록하기

2. 코인/원화 입금하기

3. 코인/원화 출금하기

거래소의 대표적인 기능 3가지 입니다. 여기서 3번만 블록체인에 저장합니다. 하지만 특정 상황에 대해서만 블록체인에 transaction을 관리하고 일반적으로는 데이터베이스로만 관리합니다.

· 1.2 코인/토큰 매매 등록하기

거래소에서 가장 핵심 기능인 매매 기능을 알아보겠습니다. 사용자는 보유 원화/코인/토큰을 이용하여 구매, 판매등록을 합니다. 사용자가 보유한 원화/코인/토큰은 해당 거래소 시스템에서 데이터베이스로 관리합니다.

[그림 1.4] 데이터 베이스 - balance관리

유저가 매매 등록을 하면 balanceTable에서 매매한 만큼 차감을 합니다. 그다음 매칭을 위해 해당 내역을 테이블에 저장합니다. 여기서 매매 등록행위를 오더(order)를 등록한다고 표현합니다. 등록된 오더들을 오더북(orderBook)이라고 부릅니다.

[그림 1.5] 데이터 베이스 - 오더관리

사용자가 오더(매매)를 넣으면 보유중인 원화/코인/토큰을 저장하는 balance 테이블을 업데이트 한 후 orderBook에 해당 주문을 추가합니다.

[그림 1.6] 데이터 베이스 - 채결 데이터 관리

오더를 받는 서버에서 이제 매칭 서버로 해당 오더를 주게되면 매칭 서버는 해당 오더와 채결할 데이터를 선별하여 채결합니다. 이렇게 되면 orderBook 테이블에서 채결 테이블로 옮기게 됩니다. 이때 누구의 오더와 채결했는지를 저장한 후 채결과 동시에 balanceTable을 업데이트 합니다.

(참고로 이 외에 종가를 저장하는 테이블이나 수수료 처리를 하게 됩니다.)

주문을 넣는 프로세스에는 블록체인에서 transaction을 발생하지 않습니다. tx를 발생할 경우 트래픽이 몰리면 해당 데이터를 빠르게 처리할 수 없기 때문입니다.

(사실 다른 이유가 있지만 이 부분은 기술적인 부분보다 비즈니스 적인 부분이라 언급하지 않겠습니다.)

※ 결론. 매수/매도에서는 transaction을 발생시키지 않는다.

· 1.3 코인/원화 입/출금하기

거래소는 직바을 2가지 형태로 관리를 합니다.

1. 거래소(admin) 지갑

2. 사용자(user) 지갑

만약, 거래소에서 생성한 지갑에 돈을 입금하면 거래소 시스템에서는 게더링 서버가 동작하여 사용자 지갑에 있는 코인 및 토큰을 거래소 지갑으로 옮깁니다.

[그림 1.7] 게더링 서버

사용자 지갑에 있는 보유 코인/토큰을 거래소 지갑으로 옮긴 후, 사용자 코인량을 관리하는 balance 테이블에 옮긴만큼 증가하여 업데이트 합니다. 토큰의 경우, 지갑에 돈을 입금하면 자동으로 거래소 지갑으로 옮기는 형태로 개발가능합니다.(이 부분은 따로 개발 방법을 알아보겠습니다.)

그리고 여기서 사용자 지갑 -> 거래소 지갑으로 실제 코인/토큰을 옮겨야 하기 때문에 transaction을 발생합니다. 그렇기 때문에 거래소에서 생성한 지갑으로 입금하면 다수의 transaction이 발생합니다.

다음으론 출금입니다. 출금을 하게되면 수신자가 거래소에서 관리되고 있는 지갑인지 검사합니다. 거래소에서 관리하는 지갑이면 데이터 베이스만 업데이트 합니다. 하지만 거래소에서 관리중인 지갑이 아니면 거래소(admin) 지갑에서 수신자에게 전송하는 transaction을 발생합니다.

[그림 1.8] 트랜잭션 처리

입/출금에서 발생한 transaction은 transaction 처리를 검사하는 배치서버를 통해 검사합니다.

자 여기서! 한가지 중요한점은 거래소 입/출금은 우리가 알고있는 입/출금의 개념이 아닙니다. 거래소 시스템에서 관리하는 지갑으로 돈이 들어온 경우 입금, 거래소 시스템에서 관리하고 있는 코인/토큰/원화가 빠져 나가는 것을 출금이라고 하며, 이 경우에만 트랜잭션을 발생합니다.

즉, 거래소는 블록체인으로만 이루어진 시스템이 아닙니다.

2. 지갑(wallet)

지갑은 거래소처럼 복잡한 시스템을 구축하지 않습니다. 지갑의 경우 비즈니스 모델이 약하기 때문에 심플한 형태로 구축합니다.

[그림 2.1] 사용자 wallet, transaction 관리

블록체인 자체에서 이력관리는 가능하나 사용자에게 띄워주기 위해 많은 리소스가 들어가므로 일부 데이터 시스템을 이용하여 사용자에게 편의성을 제공합니다.

[그림 2.2] 전송요청

지갑은 사용자 관리를 해야하기 때문에 회원가입을 하게되고 회원가입한 유저에 대해 지갑(주소)를 만들어 줍니다. 여기서는 출금(전송)을 하게되면, 즉시 transaction을 발생하고 사용자에게 응답합니다.

[그림 2.3] 월랫 전송 프로세스

 

transaction이 블록에 포함되기 까지 기다리지 않고 만들어진 txHash를 즉시 응답하는 것이 포인트 입니다. 물론 기다려도 됩니다. 하지만 필자의 경우는 기다리지 않고 즉시 응답하여 사용자에게 대기중이라는 메시지를 띄워주는 형태로 시스템을 만들었습니다.

월랫의 데이터 베이스는 사용자의 보유량을 따로 저장하지 않습니다. 잔액 조회시 디비가 아니라 블록체인 네트워크에 조회를 하여 보유량을 알려줍니다. 그렇기 때문에 어느 지갑에서나 사용가능합니다.

※ 추가로. 지갑의 경우 데이터 베이스 없이 완전 P2P 형태로 개발 가능합니다. 이럴경우 해당 어플리케이션에서 관리하는 데이터 베이스(캐시, 로컬 데이터 베이스)를 지울경우 사용 내역을 볼 수 없고, 사용자 식별이 힘든 부분이 있어 일부 데이터 베이스 시스템에 의존합니다. 만약, 데이터 베이스 시스템 없이 구축하게 되면 블록체인 시스템에서 트랜잭션 처리 완료시 이벤트를 받아서 처리하면 됩니다.

3. 암호화폐 결제(payment)

앞의 시스템을 응용하여 암호화폐 결제할 수 있습니다

[그림 3.1] 암호화폐 기반 결제

[그림 3.1] 처럼 쇼핑몰에 암호화폐 결제방법을 사용하여 결제할 수 있습니다.

암호화폐 결제시 transaction을 처리방법은 앞에서 지갑(wallet)에서 트랜잭션을 기다리면 됩니다. 지갑(wallet) 시스템처럼 기다리지 않아도 되지만 기다리는 것이 구조상 훨씬 간단합니다.

[그림 3.2] 결제 시스템 전송 프로세스

결제 시스템의 경우 안정성이 중요하기 때문에 하나의 트랜잭션(of DataBase) 보장을 해줘야 합니다. 이렇게 되면 트랜잭션 처리 검사 배치서버를 두지 않아도 됩니다. 훨씬 더 심플해지는 대신 응답 시간이 다소 소요됩니다.

여기서 결제 시스템의 경우 트랜잭션을 발생하고 해당 트랜잭션 처리를 기다려 줍니다. 트랜잭션 처리 응답을 받고 transactionComplete 테이블에 저장한후 사용자에게 결제가 완료됬다고 알려줍니다. 여기서 사용자는 일반 사용자일 수 있고 암호화폐 시스템을 연동한 다른 시스템일 수 있습니다.

물론 결제 시스템이기 때문에 사용자는 인증된 유저에 한해서만 결제를 진행하도록 해야합니다. 여기서 유저 인증은 API 키를 발급하는 형태로 진행할 수 있습니다.

이러한 부분을 SDK 형태로 만든다면 naver pay 처럼 사용 가능합니다. 현

4. 결합(combination)

앞에서 보여드린 3가지의 시스템은 독립적으로는 의미가 없습니다. 각각의 시스템은 하나의 시스템으로 만들어 졌을때 빛을 발합니다. 예를 들면 다음과 같이 시스템을 구축할 수 있습니다.

먼저, wallet와 payment 시스템은 하나의 서버에서 /wallet, /payment로 라우트하여 처리합니다. /wallet의 경우 트랜잭션을 기다리지 않기 때문에 transaction 테이블을 사용하고, /payment는 transaction 처리를 기다리으모 transactionComplete 테이블을 사용합니다.

payment와 wallet은 동일한 계정을 사용하여 wallet에서 다른 사람으로부터 받은 암호화폐를 payment 시스템에서 사용가능 합니다. 여기서 거래소 시스템을 별도로 두는 이유는 거래소 시스템은 게더링 서버를 통해 유저 지갑에 보유중인 금액을 거래소 지갑으로 옮기기 때문에 결제시 해당 지갑주소에 보유금액이 없어 결제가 되지 않습니다.

/payment에서는 결제만 가능하고 다른 유저에게 코인 전송하는 기능은 없습니다. 다른 사람에게 암호화폐를 받기 위해서는 wallet을 통해 받거나 줄 수 있습니다.

★ 정리

먼저, 블록체인은 실시간 처리에서 사용하는 것 보다 데이터를 요청하고 즉시 응답을 받지 않아도 되는 시스템에서 사용하는 것이 좋습니다. 실생활에서도 요청과 즉시 바로 응답이 되는 시스템이 있지만 요청을 하더라도 며칠이 걸리는 작업이 있습니다. 블록체인은 이러한 곳에 활용한다면 좀 더 좋은 곳에 활용가능 하다고 생각합니다.

해당 글에서 사용한 이미지 및 자료는 저와 저의 회사에서 실제 개발했던, 개발중인 시스템 구조도와 UI 입니다. 거래소는 현재 CBT 진행중인데 버그가 넘 많아서 골치 아프고 암호화폐 기반 결제 시스템은 프로젝트 기간이 워낙 짧아서 골치아퍼하는 멍개였습니다. 현재는 naverpay 처럼 시스템을 구축하기 위해 인증 부분과 SDK 설계 및 준비중입니다. SDk를 만들어서 배포하게 되면 다른 사람들도 같이 사용해야 하는 부분이라 문서화가 미흡한 부분 작업중입니다

Comments