Current Issue

가나슈(Ganache)란 테스트 목적으로 PC에 설치해서 사용할 수 있는 일종의 간이 블록체인이다. 메인 네트워크와 연결없이 로컬에서 작동하여, 계약을 손쉽게 배포 및 테스트할 수 있으며 계정과 잔액에 대한 정보를 제공한다. geth 또는 parity 같은 클라이언트를 사용하면 각 트랜잭션 실행에 15초씩 걸리기 때문에 테스트가 어렵다. 따라서 가나슈를 활용한다. 또한 테스트를 위해 100이더가 탑재된 10개의 테스트 계정을 제공한다.

본 개발 과정에서는 가나슈 버전 1.1.0.appx – Candy Apple을 사용하였으며 그림 2는 가나슈 UI로 노드에서 채굴한 마지막 블록 넘버인 Current Block, 노드가 트랜잭션을 채굴하기 위한 최소 가스 가격인 Gas Price, 트랜잭션 완료를 위해 필요한 최대 가스인 Gas Limit, 체인 네트워크 식별 ID인 Network Id, 블록 채굴 속도인 Mining status, 메타마스크에서 가나슈 계정이전을 위한 키인 MNEMONIC, 트랜잭션 처리 횟수인 TX count, 계정 생성 순서인 Index, 개인 비밀키 등의 정보를 제공한다.

Fig. 2. 
Ganache user interface

메타마스크는 크롬이나 파이어폭스의 브라우저 extension으로 제공되는 이더리움 개인 지갑으로, 인퓨라라는 원격 이더리움 노드를 통해 이더리움 네트워크에 접속한다. 앞서 설명한 가나슈의 MNEMONIC을 통해 메타마스크로 계정을 이전할 수 있다. 메타마스크는 메인 네트워크와 테스트 네트워크, Local Host 8545 그리고 Custom RPC에 접속할 수 있다. 테스트 네트워크는 가짜 에더를 사용하지만, 환경은 메인 네트워크와 같다.

Fig. 3. 
Metamask

트러플은 스마트 컨트랙트를 컴파일 및 테스트와 배포를 위한 프레임워크로 npm을 통해 설치할 수 있고 node.js 가 먼저 설치되어야 실행 가능하다.

제안하는 DApp은 Node.js 기반으로 백앤드 환경을 구축하였다. Node.js는 크롬 V8 자바스크립트 엔진으로 빌드된 가볍고 효율적인 비동기 이벤트 주도 자바스크립트 런타임으로써 확장성 있는 네트워크 애플리케이션을 만들 수 있다[12].

DApp은 웹 애플리케이션 형태로 Express 기반으로 개발되었다. Express는 간결하고 유연한 Node.js 기반 웹 애플리케이션 프레임워크이다. 서버의 페이지가 늘어나고 사이트가 커지면 코드가 복잡해지는데, Express는 코드의 양을 줄여주고 유지보수가 쉽다. Express는 요청을 처리할 때 미들웨어를 통해 지정한 동작을 수행할 수 있다. 대표적인 미들웨어는 Morgan, Body-parser, Cors 등이 있으며, 모두 npm으로 설치 가능하다. Morgan은 Express 동작 중 발생하는 메시지를 콘솔에 출력하며, Body-parser는 폼에서 전송되는 POST 값을 사용할 수 있게 해준다. 또한, Cors는 다른 도메인 간의 AJAX 요청을 가능하게 한다. Express의 다른 장점은 라우팅이 편리하다는 것이다.

라우팅은 요청 주소에 따라 다른 처리를 하는 것으로, Express는 REST API에 따라 처리하며 그 방법이 아주 간단하다. app.get, app.post, app.put, app.delete 등의 메소드를 사용한다.[13]

제안하는 DApp은 토큰 기반의 사용자 인증을 활용한다. 토큰은 클라이언트 측에 저장하기 때문에 완전히 stateless 하며, 서버를 확장하기에 적합하며 쿠키를 사용하지 않아 쿠키관련 취약점이 없고 토큰을 공유하여 다른 서비스에서도 권한을 공유할 수 있다.

JWT는 RFC7519 표준으로 두 개체에서 JSON 객체를 사용하여 가볍고 안전하게 정보를 전달한다. JWT는 C, Java, Python, C++, R, C#, PHP, JavaScript, Ruby, Go, Swift 등 대부분의 주류 프로그래밍 언어에서 지원되며, JWT에서 발급된 토큰은, 토큰 기본정보, 전달 정보, 그리고 토큰 검증을 위한 signature를 포함한다. 또한, JWT는 HTTP 헤더, URL 파라메터 등을 통해 손쉽게 전달될 수 있으며 그림 4와 같이 회원 인증에서 유용하게 사용된다.

• 1. 유저가 아이디와 비밀번호로 로그인을 한다.
• 2. 서버는 계정정보를 검증하고, signed 토큰을 발급한다.
• 3.4. 클라이언트는 전달받은 토큰을 저장하고,
• 5. 요청을 할 때마다, 해당 토큰을 함께 전달한다.
• 6. 서버는 토큰을 검증하고,
• 7. 요청에 응답한다.

Fig. 4. 
Token-based authentication procedures

서버 측에서는 유저의 로그인 여부를 신경 쓸 필요가 없고, 요청시 동봉된 토큰만 확인하여, 세션 관리가 필요 없다.

제안하는 시스템은 자주 변경되며 상대적으로 큰 데이터를 MySQL 데이터베이스를 활용하여 저장, 관리한다. MySQL은 오픈소스기반 관계형 데이터베이스로 다중 사용자와 다중 스레드를 지원하며, C, C++, JAVA, PHP 등 여러 프로그래밍 언어를 위한 다양한 API를 제공한다.

그림 5는 제안하는 시스템을 위한 데이터베이스 구조이다.

Fig. 5. 
Proposed DB for sharing market

Id, password, name, address 등 사용자 정보를 저장하는 Member 테이블과 상품의 다양한 정보를 저장하는 Product 테이블의 id를 Key로 연결하였으며, 특정 주문의 상태 변경정보를 관리하기 위한 Order_history 테이블이 존재한다.

그림 6은 제안하는 시스템의 회원가입 및 로그인 절차이다. 일반적인 웹 서비스의 회원가입 절차에 메타마스크를 통한 이더리움 네트워크의 계정정보인 지갑 주소(Wallet address) 획득 절차가 더해진 형태이다. 사용자가 DApp을 통해 회원가입을 요청하면, 먼저 메타마스크를 통해 이더리움 계정정보를 호출한다. 이때 이더리움 계정이 없다면, 메타마스크를 통해 계정을 생성할 수 있다. 계정정보를 획득한 DApp은 이를 포함한 사용자 정보를 웹서버에 전달하여 사용자 회원가입 절차를 진행하며, 해당 정보를 DB에 저장한다.

Fig. 6. 
Sign-up & Log-in procedures

로그인 절차는 그림6의 하단부와 같이 사용자의 ID, Password를 전달하여 일치 여부를 판단하고, 메타마스크를 통해 획득한 계정정보를 기반으로 블록체인 네트워크의 지갑 주소를 획득한다.

그림 7은 제안하는 시스템의 상품정보 업로드 및 갱신 절차이다. 사용자는 DApp을 통해 상품의 정보를 웹서버에 전송한다. 상품정보는 지속적으로 변경 가능한 정보로 블록체인 네트워크에 저장되지 않는다. 웹서버는 해당 정보를 DB에 기록하며, 상품정보 갱신도 동일한 절차를 거쳐 DB에 갱신된다.

Fig. 7. 
Product information upload/update procedures

그림 8은 제안하는 시스템의 구매 절차이다. 소비자가 DApp을 통해 구매 요청을 하면 메타마스크를 통해 송금에 관한 서명을 획득한다. DApp은 획득한 서명정보와 구매하려는 제품정보 및 가격정보, 그리고 지갑주소를 전달하며, 송금을 요청한다. 이때 물품 대금은 상품의 수령확인 및 구매확정이 이루어지기 전까지 Locker라고 하는 중간 보관소 역할을 하는 계정에 보관된다. 이와 같은 송금 내역(거래내역)은 이더리움 네트워크의 각 블록에 추가되며, 모든 노드가 확인할 수 있다. 대금의 송금이 완료되면 해당 상품의 상태가 거래중으로 변경되기 위해 웹서버의 DB가 갱신되며, 갱신된 상품의 정보가 소비자와 상품 제공자에게 전달된다.

Fig. 8. 
Product purchase procedures

그림 8에서 설명한 바와 같이 물품 구매 절차가 끝나면 물품대금은 소비자의 지갑에서 Locker 계정의 지갑으로 송금된다. 이후 그림 9와 같은 구매확정 및 환불절차가 진행된다. 만약 사용자가 해당 물품을 잘 수령하고, 거래를 확정지을 경우, DApp은 거래완료 정보를 웹서버에 보내고, 웹서버는 해당 상품의 상태를 거래완료로 변경한다. 또한 블록체인 네트워크에 Locker 계정에서 물건 제공자 계정으로의 송금을 요청한다. 해당 트랜잭션이 완료되어 블록에 거래 내역이 저장되면, 거래 완료 정보를 판매자와 구매자에게 전달하여, 거래 완료를 알린다.

Fig. 9. 
Transaction confirm and reject procedures

하지만 해당 상품 구매를 취소하고 환불 절차를 진행하고 싶은 경우, DApp을 통해 거래 거절 메시지를 웹서버로 보낸다. 웹서버는 판매자에게 이를 통보하고, 판매자가 환불에 동의할 경우 해당 상품정보를 갱신하고, 블록체인 네트워크에 Locker 계정에서 구매자 계정으로의 송금을 요청한다. 환불 트랜잭션이 완료되어 블록에 거래내역이 저장되면, 구매확정과 마찬가지로 판매자와 구매자에게 환불절차의 완료를 알린다.

그림 10은 제안하는 시스템의 물품 대여 절차이다. 물품의 대여는 대여기간, 보증금 등의 추가 정보가 요구되는 것을 제외하고 구매와 동일하다. 대여 요청 시 상품의 보증금을 포함하여 Locker 계정으로의 송금이 진행되며 물품의 사용이 끝나면 물품 상태의 확인 후 반납과 배상 과정으로 이어진다.

Fig. 10. 
Product rental procedures

대여의 경우 상품의 반납이 이루어져야 하며, 상품의 손상 상태에 따른 배상이 이루어져야 한다. 제안하는 반납과 배상의 시퀀스 다이어그램은 그림 11과 같다. 대여 상품의 공급자가 상품 수령 후 손상 상태를 확인하고 이에 따라 상태 변화가 있을 경우 배상금 계산이 이루어지며, Locker 계정에 저장되어 있던 보증 금액에서 배상 금액을 차감한 금액을 소비자에게, 배상 금액은 공급자에게 송금되며 거래가 완료된다. 이후 상품의 상태 및 거래 내역 정보의 업데이트가 이루어진다.

Fig. 11. 
Returning and compensation procedures

스마트 컨트랙트는 계약의 기능을 디지털 명령어로 작성한 디지털 계약 프로토콜이다. 디지털 명령어로 작성되었기에 조건에 따라 계약의 내용이 자동으로 즉각 이행되며, 그 내용은 변경될 수 없도록 한다. 이로 인해 제 3자의 개입 없이도 신뢰할 수 있는 거래가 가능하다. 이더리움은 튜링 완전 스마트 컨트랙트 개발 언어인 솔리디티(Solidity)를 제공한다[15]. 개발자는 솔리디티를 이용하여 자체적인 로직을 포함하는 스마트 컨트랙트를 개발할 수 있으며 계약 진행 후, 계약 당사자 간 부인이 불가능하며 신뢰할 수 있는 트랜잭션을 보관한다[16]. 작성된 스마트 컨트랙트는 컴파일을 통해 바이트 코드로 변환하여 블록체인에 배포된다. 채굴자는 배포된 스마트 컨트랙트 코드를 EVM (Ethereum Virtual Machine)에서 실행한다. 이때, Gas Fee가 계산되면서 블록에 추가되고, 실행 결과가 유효한 경우 State에 반영된다.

스마트 컨트랙트에서 제공하는 함수는 Web3.js 라이브러리를 통해 웹 브라우저에서 접근된다[17]. Web3.js는 이더리움 JSON RPC를 구현한 자바스크립트 API로, 자바스크립트 기반으로 DApp이나 서비스를 구현할 때 활용된다. 내부적으로 HTTP나 IPC를 통해 JSON RPC API를 호출한다.

개발된 컨트랙트의 함수에 대해 여러 유형의 안전한 접근을 지원하기 위해 ABI(Application Binary Interface) 기능을 제공한다. ABI는 컨트랙트의 함수와 매개변수들을 JSON 형식으로 나타낸 리스트로 함수 호출에 필요한 정보를 제공한다[18].

그림 12는 거래 기록의 저장을 위한 구조체 설계 내용이다. 이는 특정 판매자, 구매자, 거래 유형, 금액 등의 거래 정보를 저장하는 Trade 구조체를 정의하였고 이 구조가 블록에 저장된다. Goblin은 이를 웹상에서 호출하고 활용하기 위한 객체이다. Trades는 블록에 저장한 거래내용을 저장하기 위해 Trade 구조체 형태이며, owner는 해당 스마트 컨트랙트의 생성자 주소를 저장한다. tradeID는 거래정보를 조회하기 위한 ID 값이다. behavior() 함수는 구매 및 대여와 같은 거래행위를 했을 때 송금 처리 및 거래 기록을 남기기 위한 기능을 수행한다. 이때 저장되는 데이터의 위치를 ‘storage’로 설정하면, 메모리가 아닌 실제 블록에 해당 내용이 기록되며 함수 타입을 Payable로 설정하여 송금이 가능하게 한다. 이때 필요 정보인 판매자, 구매자, 거래액 등의 값은 파라미터로 전달한다. getTrade() 함수는 거래정보를 블록에서 탐색하여 반환하는 함수로, 사용자가 거래정보를 확인할 수 있도록 한다. getTradeID() 함수는 마지막에 처리된 거래의 ID를 반환한다.

Fig. 12. 
Data structure for storing transaction

테스트를 위하여 스마트 컨트랙트 코드를 컴파일하고 배포할 수 있는 통합 개발 환경인 Remix를 활용하였다. 그림 13은 Remix 환경에서 스마트 컨트랙트의 배포 결과를 확인한 것이다. status 값을 보면 컨트랙트를 배포하는 트랜잭션 실행이 성공했으며 배포자 주소 및 기타 가스 정보 등을 확인할 수 있다.

Fig. 13. 
Smart contract deploy result

getTradeID() 함수를 활용하여 가장 최근에 실행된 트랜잭션의 정보를 확인한다. 그림 14와 같이 판매자, 구매자, 거래 유형, 값을 확인할 수 있다.

Fig. 14. 
Last transaction information

체인 네트워크를 구축하기 위해서는 먼저 제네시스 블록 설정을 하고, 사용자 정의 Network id와 부트스트랩(부트) 노드가 필요하다. 이때 특정 프라이빗 네트워크를 구성하는 모든 노드의 제네시스 파일과 Network id가 동일해야 하며, 동일한 부트 노드를 통해 연결되어야 한다. 네트워크 상의 피어 노드들을 찾는데 사용되는 노드를 부트 노드라고 하며, 이는 블록체인 정보를 저장하지 않고, 일정 시간 동안 연결된 노드의 목록을 유지하다 새로운 피어 노드에게 노드의 목록을 전달한다. 블록체인은 P2P방식이기 때문에 피어 노드가 네트워크에 연결되면 다른 노드를 탐색하고, 하나 이상의 부트스트랩 노드에 접속하여 연결된 노드의 목록을 받아 해당 노드들과 연결한다. 부트스트랩 노드는 피어 노드가 많은 네트워크에서 사용하며 작은 규모의 경우 Geth 클라이언트가 부트스트랩 노드 역할을 수행한다.

부트 노드 생성 과정은 3단계로 나뉜다. 첫 번째로 제네시스 설정 파일을 작성하고, 두 번째로 제네시스 파일을 이용하여 최초 블록을 생성한 뒤, 사용자가 지정한 Network id에 접속한다. 마지막으로 Account를 생성한 뒤, 초기 Ether를 할당해 주기 위해 제네시스 파일의 alloc부분을 수정하고 제네시스 블록을 다시 생성한다. 그림 15는 부트노드에 제네시스 블록을 생성한 결과이다. 두 번째 단락을 보면, 설정 파일의 ChainId의 값인 20171730을 network id 값으로 세팅하여, 두 번째 노드를 해당 네트워크에 연결한다.

Fig. 15. 
Genesis block creation result

부트 노드와 2개의 피어 노드를 생성한 후, 부트 노드에 피어 노드를 연결하기 위해 admin.nodeInfo.enode 명령을 사용해 부트 노드의 enode를 확인한 뒤, 피어 노드에서 Geth를 구동시키고 addPeer로 부트 노드와 P2P연결을 한다. 연결 명령은 admin.addPeer(“부트 노드 enode”) 이다. 그림 16은 두번째 노드를 연결한 상황을 나타낸 것이다.

Fig. 16. 
Connection for peer and boot node

현재 부트 노드와 피어 노드들이 P2P연결이 되어있기 때문에 피어 노드는 부트 노드를 제외한 다른 노드의 존재를 확인할 수 없다. 따라서 연결 노드 목록의 전달을 위해 그림 17과 같이 부트 노드에서 채굴을 수행한다.

Fig. 17. 
Mining work for node information fowarding

그림 18은 채굴 노드로 node3을 지정하고, PC3에서node4를 추가로 생성해 부트 노드에 연결한다. 같은 호스트에서 여러 노드를 구현할 경우 port번호를 달리하고, IPC-RPC를 disable한다. 이처럼 타 노드를 채굴 노드로 선정하면, 부트 노드가 채굴하지 않아도 새로운 노드의 존재를 확인할 수 있다.

Fig. 18. 
Designation mining node and add peer node