Home

블록체인 기술은 2009년 Nakamoto Satoshi에 의해 처음 보여진 기술[2] 이며 저장된 데이터의 무결성, 영속성, 투명성, 부인방지를 만족시켜 준다. 이러한 블록체인 기술의 특징은 [3][4]와 같이 여러 분야에서 다양한 활용을 가능하게 하였다.

블록체인은 퍼블릭 블록체인과 프라이빗 블록체인으로 나눌 수 있다. 퍼블릭 블록체인은 만들어진 블록에 대해 PoW(Proof of Work), PoS(Proof of Stake)와 같은 합의 알고리즘을 이용하여 네트워크 참여자들 사이의 블록에 대한 Safty를 만족시킨다. 또한 네트워크 참여자에 대한 제한을 두지 않기 때문에 높은 확장성을 가진다. 하지만 이 방법은 낮은 TPS(Transaction Per Second)를 갖는 문제점이 있어 실제 서비스에서 사용하기 어려움을 겪고 있다. 이에 반하여 프라이빗 블록체인은 네트워크 참여자를 신뢰할 수 있는 노드들의 묶음으로 제한하며 PBFT[5], IBFT[6], RAFT[7]와 같은 합의 알고리즘을 사용해 높은 TPS를 갖지만 낮은 확장성을 갖는 문제점을 가지고 있다.

스마트 컨트랙트[8]는 1997년 Nick Szabo에 의해 발의된 개념으로 암호화 및 기타 보안 매커니즘을 사용하여 컴퓨터를 이용한 완전한 계약을 가능하게 하는 내용을 담고 있다. 이 개념은 당시에는 각광받지 못하다가 2015년 블록체인 시스템에 스마트 컨트랙트 개념을 추가한 Vitalik Buterin의 이더리움이 등장하면서 각광받기 시작했다. 블록체인에서의 스마트 컨트랙트는 블록체인 네트워크의 스마트 컨트랙트의 소스와 스마트 컨트랙트를 구동하기 위한 파라메터, 그에 의해 변하는 상태에 대한 내용이 모두 기록되고 변조가 불가능 하기 때문에 그 의의를 갖게 된다. 이를 통해 블록체인 네트워크의 사용자 사이의 신뢰가 존재하지 않더라도 제 3자의 보증 없이 계약을 진행할 수 있게 한다.

하이퍼레저 페브릭[9]은 IBM의 주도 하에 개발이 이루어지고 있는 오픈소스 기반 프라이빗 블록체인 플랫폼이다. 하이퍼레저 페브릭에서는 오더링 방식의 합의를 진행하고 있으며 이는 퍼블릭 블록체인에서 사용하는 기존의 합의 방식과 같이 확률론적 접근을 통한 합의를 진행하지 않고 결정론적 합의 모델을 갖는다. 이는 곧 트랜잭션의 정렬과 빠른 TPS를 가능하게 한다. 하이퍼레저 페브릭의 오더링 시스템이 트랜잭션을 검증하는 방식은 그림 1과 같다.

Fig. 1. 
Transaction verification method of ordering system

어플리케이션이 발생시킨 트랜잭션은 오더링 시스템에 전송되며 일정 시간 혹은 일정 개수의 트랜잭션이 모이면 오더링 시스템은 모인 트랜잭션을 이용하여 블록을 생성하고 이를 endorser라고 불리는 검증자들에게 전송한다.

검증자는 전달받은 블록의 트랜잭션을 실행시키며 자신의 원장의 상태 변화값을 담아 오더링 시스템에게 되돌려 준다. 오더링 시스템은 이 데이터가 모두 같은지 확인하여 트랜잭션을 통한 상태의 변화가 결정적으로 이루어질 수 있도록 한다.

오픈뱅킹[10]이란 핀테크 기업이 금융 서비스를 편리하게 개발할 수 있도록 은행의 금융서비스를 표준화된 형태로 제공하는 인프라를 의미한다. 금융기관 대신 고객의 금융정보를 조회하거나 대신 이체를 진행할 수 있게 하는 등의 서비스를 제공하고 있다. 한국에서는 2019년 10월부터 시범 운영을 시작하였으면 같은 해 12월부터 정식으로 서비스를 시작하였다. 우리는 제안하는 모델에서 오픈뱅킹 API를 사용하여 결제를 가능하게 할 것이며 그 증거 데이터를 얻어 올 것 이다.

블록체인과 부동산 거래를 연계하고자 하는 연구는 계속되어 왔다(e.g. [11][12]). 하지만 이러한 연구는 한국의 부동산 및 금융시스템에 초점을 두고 있지 않으며 그 방법을 명확하게 서술하지 않고 있는 문제점을 가지고 있다. [13]는 블록체인과 스마트 컨트랙트에 대한 간략한 설명과 부동산 거래에서의 블록체인 사용 예시를 보여주고 있다. 이더리움 네트워크를 기반으로 하고 있으며 이더리움 계정 즉 EOA(Externally Owned Account)를 이용하여 임대인 및 임차인을 네트워크에 참여할 수 있도록 한다.

또한, 임대인과 임차인 사이의 거래를 스마트 컨트랙트를 이용하여 진행할 수 있도록 하였다. 이를 가능하게 하기 위해 계약서에 임대인과 임차인의 서명을 동시에 서명하는 방식을 통해 계약서 내용에 대한 합의를 도출했으며 블록체인의 무결성과 부인방지의 특성을 이용하여 이 계약을 확정시켰다.

하지만 이 논문은 프로세스 임대 계약의 ‘지불’에 대한 방법과 증명을 위한 명확한 방법을 제시하지 않았으며 단지 ‘여러 가지 방법을 통한 지불을 한다.’ 라고 명시하고 있다. 따라서 이 모델을 통해서는 정상적으로 계약서대로의 지불이 이루어졌는지 확인할 수 있는 방법이 존재하지 않는다.

제안하는 모델의 계층구조는 그림 2와 같다. 블록체인 플랫폼은 하이퍼레저 페브릭으로 하며 합의 알고리즘은 오더링 시스템을 사용할 것이다. 거래를 위해 하이퍼레저 패브릭의 스마트 컨트랙트 기능을 이용하며 결재와 결제의 증거를 가져오기 위해 오픈뱅킹 API를 사용할 것이다. 또한 제안하는 모델을 사용하는 여러가지 어플리케이션들이 만들어 질 수 있다.

Fig. 2. 
Hierarchical model of the proposed model

제안하는 모델은 하이퍼레저 페브릭 기반의 블록체인 네트워크로 이루어져 있다. 이때 거래를 원하는 유저는 네트워크 가입 절차를 통해 Fabric CA에서 발급받은 개인키를 기반으로 하여 임차인 및 임대인이 될 수 있으며 자신임을 증명하게 된다.

Fig. 3. 
System model

블록체인 네트워크를 이루는 피어는 국토교통부, 한국 부동산 개발 협회, 공정거래 위원회 등 신뢰 있는 기관들이 될 수 있으며, 이 기관들을 모아 거버넌스 형태로 블록체인 네트워크를 운영하도록 한다. 또한 오픈뱅킹 API는 금융거래가 진행될 때에만 사용되기 때문에 언제나 피어와 연결되어 있을 필요가 없다.

현재 오픈뱅킹 API는 REST API 방식을 취하고 있기때문에 HTTP를 사용하여 통신한다. 따라서 통신이 필요할 때 적절한 메소드를 사용하여 통신을 하도록 한다. 또한 사용자의 시스템 사용 편의성을 위해 모델은 어플리케이션을 지원해야 한다. 이는 웹 또는 모바일 어플리케이션으로 지원하며 거버넌스가 운영하는 중앙 서버를 통해 한다.

제안하는 모델을 사용하고자 하는 사용자는 거버넌스가 제공하는 어플리케이션을 통해 사용자 등록을 진행하여야 하며 오픈뱅킹에도 가입하여야 한다. 오픈뱅킹 가입절차는 오픈뱅킹의 절차를 그대로 따르며 제안하는 모델의 사용자 등록 흐름은 다음과 같다.

사용자는 어플리케이션을 통해 회원가입 요청을 보낸다. 이때 어플리케이션에서 사용자에게 요청할 수 있는 데이터는 실명, 생년원일, 주소 와 같은 데이터들이 있으며 SMS 인증 방식이나 ARS 인증방식을 통해 사용자의 실명 인증 절차를 진행하게 한다. 모든 인증절차가 완료되면 Fabric CA를 통해 새로운 인증서를 생성하고 사용자에게 전송한다. 이를 통해 사용자는 본 시스템의 사용 권한을 얻을 수 있게 된다. 이때, 하이퍼레저 패브릭은 x.501 인증서 표준을 사용한다. 따라서 제3기관에서 발행하는 공인인증서를 본 시스템에서 그대로 사용할 수도 있다. 사용자가 공인인증서를 통한 가입을 시도하면 어플리케이션에서는 공인인증서 발급기관에 공인인증서의 유효 여부를 파악한다. 공인인증서가 정상이라고 판별되면 공인인증서의 공개키를 Fabric CA에 등록하고 사용자는 기존의 공인인증서를 본 모델에서 사용할 수 있게 된다.

사용자는 자신의 부동산에 대한 계약을 진행하기 위해 매물 등록 절차를 진행할 수 있다. 매물의 등록은 어플리케이션을 통해 진행되며 매물의 실사, 가격, 거래 내용을 입력하며 거버넌스가 운영하는 서버와 블록체인 네트워크에 저장된다. 이때 블록체인 네트워크에 저장되는 데이터는 매물의 실사를 제외한 데이터이다.

본 절에서는 제안하는 모델의 계약에 대한 내용을 전반적으로 다룬다. 이때 사용하는 표기법은 표 1과 같다.

3.5.2 계약 체결

부동산 거래의 경우 현물거래가 필요하다. 따라서 기존의 블록체인 기반 부동산 거래 시스템은 블록체인에 계약서의 내용만 저장 하고 계약금 이체를 따로 진행하는 경우가 많다. 이는 곧 스마트 컨트랙트가 구매자와 판매자 사이의 현물거래가 이루어 졌음에 대한 증거는 제공하지 못한다는 것을 의미한다. 하지만 본 모델에서는 오픈뱅킹 API를 사용하여 거래금의 이체 및 확인을 자동화 시킬 것 이다.

또한, 그 증거를 블록체인에 저장하여 거래가 정상적으로 진행됐음을 증명할 것이다. 우리는 계약 생성 절에서 판매자가 판매를 위한 데이터를 스마트 컨트랙트에 전송하는 것을 확인했다. 이 스마트 컨트랙트를 통해 매물 구매자는 전송된 계약서의 내용을 확인한 뒤 거래에 동의 할 수 있다. 동의를 하게 되면 서버는 사용자를 결제 페이지로 리다이렉트 시킨다. 결제 페이지로 리다이렉트된 사용자는 오픈뱅킹의 입금 이체 프로세스에 따라 입금을 진행하고 서버는 그 응답으로 그림 4와 같은 구조를 가지는 데이터를 받는다.

Fig. 4. 
Deposit transfer response data

이때 우리는 차후에 이체 결과를 조회하기 위해 위 데이터 중 bank_trand_id, bank_tran_date, tran_amt를 필요로 하며 이를 OTRD라고 정의한다.

위 결제 과정이 완료되면 OTRD와 계약 생성 과정에서 생성된 계약서의 기본키인 h(C,T), 블록체인을 통해 받은 계약서의 데이터를 해쉬화 한 h(C), 그 서명 데이터 [h(C)]_σB를 스마트 컨트랙트로 전송한다. 스마트 컨트랙트는 h(C,T)를 통해 Contract 구조체를 블록체인으로부터 불러오고 그 내부에 저장된 pub_B를 이용하여 [h(C]_σB를 검증한다. 이는 구매자가 계약서 내용에 동의하였음을 의미한다. 그런 뒤 OTRD와 C를 이용하여 계약서와 이체된 금액이 일치하는지 확인한다. 마지막으로 OTRD를 이용하여 오픈뱅킹 API를 통해 이체가 실제로 진행되었는지에 대한 검증을 진행한다. 이 프로세스는 거래 검증 절에서 자세히 설명한다.

3.5.3 결제 검증

우리는 결제가 정상적으로 진행되었는지를 확인하기 위한 프로세스를 진행하며 이 프로세스는 하이퍼레저 페브릭의 오더링 시스템을 기반으로 한다. 또한 전체적인 검증의 흐름은 그림 5와 같다.

Fig. 5. 
Overall verification flow

결제 체결 절에서 우리는 OTRD를 스마트 컨트렉트로 전송하며 표 3의 알고리즘을 통해 오픈뱅킹 API와 OTRD를 이용해 이체 검증을 한다는 것을 확인하였다. 또한 우리는 2.3절에서 하이퍼레저 페브릭의 트랜잭션 검증 방식을 확인했다. 하이퍼레저 페브릭의 트랜잭션 검증 방식에 따르면 트랜잭션을 검증하는 모든 검증자 노드들의 state가 일치하지 않으면 에러를 발생시킨다. 즉 SignContract를 실행시키는 트랜잭션을 검증할 시 모든 검증자 노드에서 해당 알고리즘이 실행된다는 것을 의미하며 이는 검증자 노드의 수만큼 오픈뱅킹 API를 통해 이체 검증을 하게 되는 것을 의미한다. 이체 검증 쿼리는 각 검증자 노드로부터 따로 전송되며 그 응답 데이터도 검증자 노드들이 각자 받게 된다. 응답 데이터의 구조는 그림 6과 같다.

Table 3. 
Algorithm of SignAgreement

function name : SignAgreement

Input : OTRD, h(C, T), h(C), [h(C]σB Output : boolean

Algorithm

c = getState( h(C, T)) if( h(c.C) != h(C)) return false if( signVerify([h(C]σB, c.pubB) return false if( amountVerify(c.C, OTRD) return false //Using OpenBanking API tv = transferVerify(OTRD) c = Agreement{C,pubB,dS, [h(C]σB,tv} putState(h(C, T), c) return true

Fig. 6. 
Transfer result inquiry data

그림 6에서 볼 수 있듯이 응답 데이터는 이체 이력에 대한 데이터를 포함하고 있다. 우리는 이 데이터 중 req_list 데이터를 이체의 증거로써 남길 것 이며 이 데이터를 OCRD라고 정의한다. 오픈뱅킹 서버에 이체 요청을 전송한 뒤 실제 이체가 발생하기 까지 지연이 있을 수 있다. 또한 각 검증자 노드가 개별적인 이체 확인 요청을 전송하기 때문에 검증자 노드 중 일부는 이체 결과 조회 데이터를 받지 못할 수도 있다.

검증자 노드는 OCRD를 블록체인에 추가하여 state를 변경시키고 그 결과값을 오더링 시스템에게 다시 전송한다. 이때 위에 서술한 문제로 인하여 각 검증자에게라도 다른 데이터를 받게 된다면 결정론적이지 않게 됨을 의미하기에 해당 트랜잭션은 실패하게 된다. 이때 만일 해당 트랜잭션이 실패했다면, 오픈뱅킹 API 명세서에 따라 일정 시간이 지난 후 해당 트랜잭션을 다시 시도한다.

만일 트랜잭션이 성공한다면 계약서에 대한 구매자와 판매자의 서명과 오픈뱅킹 API로부터 전송받은 입금에 대한 증거가 블록체인 네트워크에 저장 되었으므로 결제 프로세스가 종료된다.

본 구현에서 계약서는 실제 임대차 계약서를 html로 컨버팅하여 사용하였다. 필요한 부분은 판매자가 직접 채워 넣을 수 있으며 해당 내용들은 블록체인에 저장된다. 구매자가 해당 계약서를 확인하기 위해 서버에 요청하면 서버는 블록체인에서 해당 데이터를 받아와 컨버팅 된 임대차 계약서에 내용을 채워 넣고 구매자의 화면에 보여준다.

Fig. 8. 
Web-converted lease agreement

입금 확인 프로세스는 하이퍼레저 패브릭의 오더링 방식에 의거하여 작동한다. 구현에서 네트워크는 2개의 Org.으로 이루어졌기 때문에 그림 9를 보면 2개의 Org.에 체인코드가 설치된 것을 확인할 수 있으며 검증자 노드 또한 2개로 지정하였다.

Fig. 9. 
Instantiated chaincode

우리는 앞에서 오더링 시스템에 의해 검증자 노드의 수만큼 오픈뱅킹 서버에 입금 확인 요청을 진행할 것 이라고 말하였다. 이를 검증하기 위해 체인코드 소스에 로그를 남기도록 하였다.

그림 10과 그림 11을 보면 각 Org.에서 실행시킨 체인코드에 대한 로그를 보여주고 있다. 제일 처음 입금 확인 요청을 진행하기 위한 OTRD를 보여주고 그에 대한 전체 응답 데이터와 응답데이터에서 추출한 OCRD(res_list)를 확인할 수 있다. 전체 응답 데이터에서 api_tran_id 는 각 요청마다 고유하게 매겨지는 식별자이다. 이때 그림 10과 그림 11의 식별자가 다른 것으로 보아 각 검증자 노드마다 다른 요청을 수행한 것을 확인할 수 있다.

Fig. 10. 
Chaincode logs of Org.1

Fig. 11. 
Chaincode logs of Org2

다음은 오픈뱅킹 서버로부터 서로 다른 값(입금 실패 등)이 오는 경우를 확인해 볼 것이다. 하지만 우리는 오픈뱅킹 테스트 넷을 사용하고 있기 때문에 이를 직접적으로 확인하기에는 어려움이 있다. 따라서 이를 확인하기 위해 의도적으로 체인코드를 비결정적으로 만들어 체인코드가 제대로 수행되는지 확인해 볼 것이다.

테스트 코드는 그림 12와 같다. 렛저의 state를 변경시키는 값을 랜덤하게 주어지게 함으로써 각 검증자 노드마다 서로 다른 state를 가지도록 하였다.

Fig. 12. 
Non-deterministic chaincode

그림 12의 체인코드를 실행시킨 결과는 그림 13과 같다. could not assemble transaction: ProposalResponsePayloads do not match 라는 에러 메시지와 함께 실패하는 것을 볼 수 있다. 즉 만일 입금과정에 문제가 생겨 오픈뱅킹 서버로부터 잘못된 응답이 하나라도 온다면, 비 결정적인 결과가 도출됨으로써 거래에 실패하게 된다.

Fig. 13. 
Response of non-deterministic chaincode