공개마켓 플레이스를 위한 블록체인의 RDB 구현 방법 연구

2.1 블록체인

2.2 공개마켓

온라인 쇼핑몰은 개인몰, 종합몰, 공개마켓, 소셜커머스로 나눌 수 있다. 공개마켓은 운영주체가 상품을 판매하지 않고 단지 장소를 제공하는 역할을 한다. 판매자는 경쟁적으로 싼 가격을 소비자에게 제공해야 살아남을 수 있기 때문에 지나친 가격 경쟁을 피할 수 없고 지불해야 할 수수료 부담도 크다.

공개마켓 조사에서 발견된 문제점 개선을 위해 블록체인에 적용했을 때의 장점은 다음과 같다.

2.3 블록체인의 한계와 개선 방안

3.1 거래와 블록에 OTPB 적용

본 논문의 목표는 중앙 집중형 공개마켓과 달리 분산형 공개마켓 플레이스에서 운영자의 개입 없이 계약과 이행이 자동 처리되는 블록체인을 적용하는 것이다. ACABD 블록체인에서 거래로 다뤄지는 것은 화폐, 게시물, 계약이다.

ACABD 블록체인에서 블록은 화폐, 게시물, 계약 등 세 가지 유형으로 구분한다. 화폐는 블록체인에서 정산할 때 필요하며 공개마켓 플레이스 환경에서만 사용 가능하다. 게시물은 상품평과 하자처리로 나뉜다. 계약은 상품등록과 주문거래 및 상품거래, 배송거래로 구분한다. 상품등록은 반복적으로 사용하는 일반 상품과 한번 구매하면 소멸되는 일회성 상품으로 구분되며 주문거래는 상품거래를 수반하고 배송거래는 상품거래에 대한 이행과정이다. 배송거래가 완료된 때 정산이 개시된다.

그림 4에서와 같이 ACABD 블록체인에서는 블록은 한 개의 주문거래이며 여러 개의 상품거래(Items)를 포함하고 있다. 상품평의 경우에도 동일한 블록 구조가 적용된다.

Fig. 4.

ACABD transaction block

3.2 ACAB블록 생성

1) ACABD 블록체인의 블록 헤더

ACABD 블록체인에서 블록 헤더는 8개 항목으로 구성되어 있다. Block Hash는 ver, prev_block, block_type, time, node, country, tran_hash 등 7개 항목을 이어 붙힌 값에다 SHA256 해시를 이중으로 적용하고 값을 뒤집은 결과 값이다. 블록 해쉬 값 계산은 그림 5와 같은 7단계를 거친다.

Fig. 5.

ACABD block hash value calculation procedure

3.3 합의와 채굴 자동화

비트코인은 블록 처리시간이 7 TPS 이고 블록 생성 간격이 10분이므로 수많은 거래가 발생하게 되면 임시 풀에 저장하고 수수료가 많거나 저장이 오래된 순서에 의해 선택적으로 새로운 블록에 포함되고 P2P 네트워크로 전파되어 6회 이상의 확인을 받아야만 유효한 거래로 인정된다[4]. 공개마켓 플레이스에서는 주문거래가 많고 결제 과정은 신속해야 하기 때문에 임시 풀에 저장된 후 선택적으로 블록에 포함돼서는 안된다. ACABD 블록체인은 자신의 노드를 제외한 모든 노드의 최종 블록에 대한 위.변조를 검사하는 합의과정과 새로운 블록 해쉬 값을 자동 생성하는 ACAB 방식을 적용하였다.

ACAB방식은 주문거래가 발생한 노드에서 마지막 블록을 읽어 직전 블록의 해시 값과 새 블록에 사용할 순차 값을 구한 후 다른 요소와 합쳐 새로운 블록 해시 값을 계산한 후 블록을 생성하며, 인증서버에 기록된 다른 노드의 IP를 이용하여 순차적으로 원격 접속하고 동일한 방법으로 직전 블록의 왜곡여부를 확인한 후 새로운 블록을 자동으로 추가한다. 이러한 방식은 노드에 의해 반복적으로 블록 해쉬 값을 구하여 블록 생성 권한과 화폐 보상을 받는 채굴 기능을 제거함으로써 과도한 채굴경쟁과 비용 낭비를 제거하고 실시간으로 거래를 블록에 포함시킴으로써 처리시간을 단축시킨다.

4.1 인증 서버

4.2 상품 등록

ACABD블록체인 기반의 공개마켓은 모든 노드가 독립적으로 마켓을 운영할 수 있으므로 상품 등록을 블록체인에 적용할 때 자신이 등록한 상품인지 다른 노드로부터 P2P 네트워크로 전파된 상품인지 구분하도록 한다. 상품 유형은 서비스 및 용역, 중고물품과 같이 상품이 판매됨과 동시에 소멸하는 일회성 상품과 한 번 등록하면 반복적으로 판매할 수 있는 일반 상품이 있다. 기존의 블록체인을 이용하여 상품을 등록한다면 1~4Mb 용량 제한에 걸린다. ACABD 블록체인은 데이터베이스의 BLOB 속성을 이용하여 상품 이미지를 저장할 수 있으므로 이미지를 많이 사용하는 공개마켓에 적합하다.

상품정보에 사용되는 이미지를 블록에 저장할 때, 이미지 파일에 포함된 예기치 않은 특수문자를 제거하기 위해 chunk_split 함수와 base64_encode 함수를 사용하였다.

$img = chung_split(base64_encode(file_get_contents ($tmpfile)));
이미지를 꺼내 보려면 base64 디코딩을 거친 후 img tag를 사용한다.
$img= base64_decode(img)
<imgsrc=$img>

4.3 주문거래와 상품 묶음 관리

상품 #1의 해쉬 값은 Item Hash로 묶어준 Order_num, Sequence, 주문상품정보 등 세 항목을 연결하여 계산하고 주문거래에 상품 #1로 저장시킨다. 상품 #n까지 해쉬 값을 계산하여 순차적으로 주문거래에 저장하였으면 다시 이들 상품 #1 부터 상품 #n까지를 연결하여 Root Item Hash 값을 계산한 후 저장한다.

상품거래에서 상품 #1 부터 상품 #n까지 반복되므로 연관 배열로 만든 후 다시 JSON Format으로 변환하여 평문(plain text)을 만들어 블록에 저장한다.

한 개의 주문거래에 속한 상품거래는 Order_num으로 종속관계를 가지며 개별 상품마다 판매자가 다를 수 있다. 판매자가 다른 경우 수령인에 대한 정보를 상품마다 제공해야 한다.

4.4 판매 보상

비트코인의 경우 채굴을 하면 화폐로 보상을 해준다. 그런데 처음부터 2,100만 비트코인이 발행되도록 설계되었기 때문에 채굴이 고갈된 이후에 채굴자들이 인센티브 없이 계속 네트워크를 유지해 줄 것인가 하는 의문이 있다[11].

ACABD 블록체인은 거래가 발생하면 OTPB 방식에 의해 한 개의 블록이 생성된다. 블록 해쉬 값은 자동 계산되고 인증 서버를 이용하여 자신을 제외한 모든 노드의 직전 블록 해쉬 값을 비교하여 합의 과정을 거치므로 채굴자가 필요하지 않고 채굴에 따른 보상도 없다.

ACABD 블록체인은 모든 노드가 마켓을 유지하는 공개마켓 플레이스 환경을 제공하기 때문에 구매자가 블록체인을 검색하여 상품을 선택하고 결제할 때 판매자는 상품판매 수익을 얻게 된다. ACABD 블록체인의 보상은 판매금액의 1% 를 기본 적용한다. 중앙 집중형 공개마켓 수수료의 1/10에 해당하지만 참여 노드와 구매자가 증가할수록 수수료 규모는 커진다. 판매자가 상품을 등록할 때 기본 수수료 보다 더 많은 수수료를 제공할 경우 노드가 운영하는 마켓은 더 많은 보상을 받기 위해 해당 상품을 많이 노출시킬 것이다.

주문거래가 발생하면 결제대금은 에스크로 계정에 보내지고 배송이 완료되면 개별 상품마다 다음과 같이 네 개의 UTXO가 생성되어 정산절차가 진행된다.

- 물품대금 UTXO : 판매대금에서 보상(수수료)를 공제한 금액
- 마켓보상 UTXO : 구매자가 접속하여 상품주문을 한 마켓 보상
- 회원보상 UTXO : 구매자를 가입시킨 노드에 대한 회원 보상
- 공급보상 UTXO :판매자를 가입시킨 노드에 대한 공급 보상

완전한 공개마켓에서 노드는 마켓 역할을 하고, 각 노드는 자신에게 회원 등록된 구매자와 판매자가 있다. 이런 조건은 모든 노드의 조건과 같다. 구매자는 자신이 가입한 노드의 마켓을 이용할 수 있고 다른 마켓을 이용할 수도 있다. 구매자는 자신이 가입한 노드의 마켓에 상품을 판매하는 판매자의 상품을 구매할 수도 있고 다른 마켓에서 등록한 상품이 블록체인으로 공유되어 구매하는 경우도 있다.

물품대금을 정산 할 때 판매자에게 지급하고 남은 수수료는 마켓, 판매자, 구매자의 조건에 따라 UTXO를 생성하여 전자지갑에 전송한다.

4.5 시뮬레이션

실험은 블록 헤더를 DB에 체인으로 추가하는 과정에서 매 건마다 직전 생성된 블록의 위.변조 여부를 점검하는 “합의”와 새로 추가될 블록의 해쉬 값을 계산하여 블록 헤더를 완성하고 체인에 추가하는 과정을 2,000,000번 수행하였다. 쿼리가 지원되는 RDB 방식을 블록체인에 적용하였을 때 기존의 DB4 방식에 비해 어떤 차이가 있는가를 비교하는 것이므로 네트워크 상태에 따른 전송속도의 차이점을 배제하였고 단일 노드에서의 동일 조건의 블록을 생성하였다. 동일한 조건으로 비트코인에서 사용되고 있는 Berkeley DB 4.8.30에 블록 데이터를 생성하고 처리속도와 파일 사이즈를 비교하였다.

블록은 다음과 같은 데이터로 구성하였다.

$input['block_hash'] = $new_code;
$input['ver'] = $ver;
$input['prev_block'] = $prev_block;
$input['block_type'] = $block_type;
$input['block_dt'] = $block_dt;
$input['node_num'] = $node_num;
$input['country'] = $country;
$input['tr_hash'] = $tr_hash

ACABD 블록체인 기반의 공개마켓은 웹 환경에서 클라이언트에서 웹 브라우저로 연결하여 테스트 하였다. 이때 응답시간과 대기시간은 통신 환경에 따라 달라질 수 있기 때문에 공정한 테스트를 위하여 동시 사용자 없이 단독으로 클라이언트와 서버가 접속되고 RDB 및 DB4가 연결된 상태까지는 시간을 측정하지 않았다. 또한 호출간격은 따로 제한하지 않고 처리 대상이 완료될 때까지 반복적으로 작업하였다.

10만건 단위로 20번 나누어 처리시간(초), CPU사용률, 메모리 사용량, 메모리 Peak 사용량(Kb)을 측정하였는데 CPU 사용량과 메모리 사용량은 모든 테스트에서 동일하거나 경미하여 분석 대상에서 제외하고 처리시간과 메모리 Peck 사용량을 대상으로 비교하였다. 10만 건 단위로 DB 연결과 Open 및 Commit을 수행하였다. DB4의 경우에도 10만 건 단위로 DB handler와 File을 Open 및 Close 하며 수행하였다. 블록 헤더를 구성할 때 사용된 거래명세 해시는 따로 계산하지 않고 한 개의 고정 값을 구한 후 블록 헤더를 생성할 때 마다 동일한 해쉬 값을 사용하였다. 측정 방법은 직전 블록을 검사하고 새로운 블록의 해쉬 값을 계산하여 순차적으로 블록을 추가하는 과정을 200만번 수행하였고 생성된 블록을 랜덤 검색하는 실험을 하였다.

블록 생성 속도는 MySQL(이하 RDB라 한다)에서는 10만건 당 68.61 sec, Berkeley DB(이하 DB4라고 한다) 에서는 104.22 sec 소요되었다.

그림 6을 보면 블록 개수가 적을 때 10만 개 당 DB4가 RDB에 비해 2배 빠른 처리 속도를 보였는데 60만개를 처리할 때는 DB4는 68.89초, RDB는 66.93초로 역전되었으며 200만개를 처리할 때는 DB4는 166.65초, RDB는 71.01초의 처리 속도를 보였다. DB4는 데이터가 적을 때 32.15초가 걸렸지만 200만 건을 처리할 때는 5배가 느려진 166.65초가 걸렸다.

Fig. 6.

Block header generation processing measurement result comparison

비트코인의 블록 사이즈는 약 1MB로 고정되어 있고 블록 생성시간은 약 10분이므로 초당 처리할 수 있는 사이즈는 약 1.71KB가 된다.

이더리움의 블록 사이즈는 약 30KB이며 블록 생성 시간은 약 10~20초이므로 초당 처리할 수 있는 사이즈는 2KB가 된다. 이더리움이 비트코인에 비해 블록생성시간이 짧지만 초당 처리능력은 비슷하다.

ACABD 블록체인은 RDB에 기록하는 처리시간을 측정해 본 결과 네트워크를 제한 속도를 고려하지 않았을 때 1,457 TPS가 측정되었다. 이러한 속도는 공개마켓에서 실시간 거래를 처리하는데 문제가 될 것이 없다.

그림 7을 보면 RDB의 파일 사이즈는 데이터 부분과 인덱스 부분을 합해 359.97Mb, DB4의 경우는 721.44 Mb로써 두 배가 크다는 점이다. 200만개의 블록을 생성했을 때 RDB는 719.81Mb, DB4는 1,444.28 Mb를 보여주었다.

Fig. 7.

Blockchain size comparison

그림 8을 보면 순차 검색의 경우에는 메모리 사용량이 RDB와 DB4가 비슷하게 사용되고 있지만 랜덤 검색의 경우에는 DB4가 많은 메모리를 사용하고 있다.

Fig. 8.

Sequence and random search memory usage comparison

본 논문에서 기존 블록체인 방식의 DB4와 새로운 비즈니스 모델에 적합한 RDB 방식을 비교했을 때 데이터가 적을 때는 DB4가 빠르지만 데이터가 많아지면 RDB가 4배 이상 빠르다는 것을 확인하였다. 블록 200만건 생성에서 60만 건을 교차점으로 RDB가 DB4 보다 빠른 블록체인을 생성하는 것이 확인 되었으며 데이터 처리 전체 구간에서 RDB는 균등한 속도를 유지되는 안정성도 확인되었다.