Improving Reliability of Smart Contracts and DApps by Applying Property-based and Model-based Test Methods to Different Test Levels
속성 기반 및 모델 기반 테스트를 통한 테스트 단계별 스마트 컨트랙트 및 DApp 신뢰성 향상

Kyeongsic Min, Jung-Won Lee, Byungjeong Lee
2019 Journal of KIISE  
Smart contract technology based on the blockchain enables transparent transactions and automated contract execution without third-party intervention. Ethereum provides Solidity and EVM (Ethereum Virtual Machine) that can be used to implement smart contracts. In addition, it can be used to create a DApp (Decentralized Application) without developing a new blockchain using smart contract. However, the source codes cannot be updated in smart contracts. Therefore, a lot of work is needed to fix
more » ... s needed to fix even minor errors following deployment. Therefore, the source code should be thoroughly tested or analyzed prior to the deployment of the contract to ensure that it is free of defects. In this paper, we propose a method to identify the errors and verify the accuracy of smart contracts and DApps using dynamic testing methods. Toward this end, we defined the dynamic model needed in each test level and applied the current testing methodology, using property-based and model-based testing. Keywords: blockchain, smart contract, model-based testing, property-based testing 정보과학회논문지 제46권 제8호(2019. 8) 1. 서 론 최근 몇 년간 블록체인(Blockchain)은 분산원장의 무 결성 및 보안성으로 많은 주목을 받아 빠른 속도로 발 전되고 있다. 기존의 중앙 서버 방식을 탈피하여 제 3자 의 개입 없이도 투명한 거래가 가능하다는 특징이 있다. 블록체인이 발전하며 주목을 받은 또 다른 개념은 스마 트 컨트랙트(Smart Contract)이다[1]. 이더리움과 같은 블록체인 플랫폼들은 스마트 컨트랙트 기능을 제공한다. 이 기능을 이용해 개발자들은 새로운 블록체인을 개발할 필요 없이 DApp(Decentralized Application)을 만들 수 있으며, 그 사례는 다양한 분야에서 증가하고 있다[2,3]. 하지만 BOS(Blockchain-oriented Software) 개발은 기존의 어플리케이션 개발과는 차이가 있기 때문에 새로 운 소프트웨어 공학적 접근이 필요하다[4]. [4]에서는 블 록체인 프로젝트들을 위한 BOSE(Blockchain-oriented Software Engineering)의 개념을 제안하고 있다. 또한, 신뢰성과 보안성을 보장해야 하는 블록체인의 특성상 보다 많은 결함을 발견하기 위해 철저한 테스팅이 필요 하다[5]. 특히, 현재 스마트 컨트랙트 개발의 경우 첫 배포 이 후 코드 업데이트가 불가능하고, 스마트 컨트랙트의 결 함을 수정하기 위해서는 많은 작업 혹은 비용이 요구되 며, 결함으로 초래된 문제를 되돌리는 것이 불가능할 수 도 있다. 스마트 컨트랙트의 특성 및 결함으로 인한 대 표적인 사건으로는 750억원 정도의 이더리움이 탈취당 한 TheDAO 사건과 370억원 정도가 탈취당한 Parity 해킹 사건이 있었다[6,7]. 스마트 컨트랙트는 블록체인보 다 개발이 용이하지만, 숙련되지 않은 개발자가 개발할 경우 영구적인 결함이 생길 수 있다. 따라서 결함들을 배포 전에 발견하기 위해서는 초기 에 정확한 테스트 케이스를 개발하고, 개발된 소프트웨 어를 정확하게 테스트하는 것이 중요하다. 하지만 테스 트 케이스 개발 및 테스트 과정은 테스터의 지식과 경 험에 좌우되어 신뢰성을 보장하기 힘들다. 또한, 정형 검증 기법으로는 발견할 수 있는 결함이 한정적이며, 동 적 테스팅 기법과는 결함의 종류가 다르다. 모델 기반 테스트는 이러한 문제점을 보완하고자 테스트 설계를 효율적으로 수행하는 방법으로서 소개되었다[8]. 또한, 속성 기반 테스팅을 이용하면 테스트 케이스 설계 없이 도 단위 테스트 단계에서 대상 모듈의 완전성을 확인함 으로써 컨트랙트 배포 전에 더 많은 결함을 발견해낼 수 있다. 정보과학회논문지 제46권 제8호(2019. 8) 테스트를 의뢰할 수 있다. 메시지 1~3, 8에서 의뢰자는 팀을 선택하고, 보상을 지불한다. 메시지 4~5는 보상을 지불할 채널(Channel)을 생성하는 과정이고, 메시지 6~ 7는 토큰 컨트랙트를 통해 토큰을 송금하는 과정이다. 메시지 9, 10은 스마트 컨트랙트에 등록된 의뢰 정보를 팀장(teamLeader)의 블록체인 내 컨트랙트와 동기화를 수행하는 단계이다. 그림 6,7은 그림 5의 시퀀스 다이어 그램을 각각 액티비티 다이어그램과 동시 제어 흐름 그 래프로 변환한 것이다. 그 후, 동시 제어 흐름 그래프에 서 모든 가능한 동시 경로를 추출한다. 추출된 동시 제 어 흐름 경로는 다음과 같다. 또한, 시퀀스 다이어그램의 대체(alt) 상호작용 연산자 에서 추출한 술어는 다음과 같다. P1: testing.status = verified P2: team.address exists P3: team.status = ready 동시 제어 흐름 그래프에서 P2와 P3은 P1이 참인 경 우에만 경로에 영향을 미칠 수 있다. 따라서 추출된 술 어를 조합하여 술어 전 범위 기준을 만족시킬 수 있는 모든 경우는 다음과 같다. Combination 1: P1 Combination 2: ~P1 Combination 3: P1&P2&P3 Combination 4: P1&~P2&P3 Combination 5: P1&P2&~P3 Combination 6: P1&~P2&~P3 그리고 스마트 컨트랙트가 행위자 혹은 사용자에게 전달할 메시지(스마트 컨트랙트의 예상 결과)는 아래와 같이 나열할 수 있다. Output A. 서버가 검증되지 않음. Output B. 해당 팀이 존재하지 않음. Output C. 해당 팀은 이용 불가. Output D. 팀 리스트 출력. Output E. 테스트 의뢰 완료. 마지막으로, 술어의 조합 6가지와 예상 결과를 이용해 결정 테이블을 생성하면 표 3과 같다. T는 참(True)을, F는 거짓(False)을 의미한다. 따라서, 결과적으로 requestTest 유즈케이스를 테스트하기 위한 테스트 케이스의 개수는 술어의 조합의 개수와 같으며, 결정 테이블을 이용하여 도출한 테스트 케이스는 다음과 같다. 정보과학회논문지 제46권 제8호(2019. 8) 과 보완점은 다음과 같다. 1. 단위 테스트 단계: 현재 단위 테스트는 메소드의 입력 값과 출력 값의 속성을 이용하여 테스트를 진행하여 대상 메소드의 무결성을 검증한다. 하지만, 개발자가 개발된 소스코드에 맞춰 속성을 구상하는 일은 테스 트 케이스를 생성하는 것만큼이나 어려울 수 있다. 따 라서 소스 코드 작성 전, 정적 설계 단계에서 정적 모 델 설계 시, 각 세부 모듈의 기능 및 의존관계 정의와 함께 모듈의 속성을 포함한다면, 이를 동적 테스트 단 계에서 사용할 수 있을 것이다. 2. 통합 테스트 단계: 본 연구의 통합 테스트 단계에서는 술어 전 범위 기준을 사용하여 테스트 케이스를 생성 한다. 하지만 해당 기준은 시퀀스 다이어그램의 모든 메시지를 테스트해보지 못할 수도 있다. 따라서, 테스 트 자동화와 함께 메시지 전 범위 기준(All Message Coverage Criterion)을 충족하는 테스트 케이스를 생 성한다면 모든 메시지를 테스트할 수 있어 더욱 정확 한 테스트가 가능할 것이다. 3. 시스템 테스트 단계: 본 연구의 시스템 테스트 단계에 서는 깊이 우선 탐색을 이용하여 유즈케이스 의존성 그래프로부터 의존성 순서를 생성한다. 이렇게 생성된 유즈케이스 순서는 시스템의 기능적 정확성을 확인할 수 있는 테스트 케이스로 사용된다. 하지만 시스템의 확장성을 테스트하기 위해서는 예외적인 상황을 포함 한 모든 시나리오의 테스트 케이스를 개발해야 한다. 따라서, 생성된 의존성 순서의 매개변수를 다양화하 고, 의존성 순서들을 조합하여 새로운 의존성 순서를 만드는 방식을 통해 기존의 테스트 케이스를 보완하 여, 예외적인 상황을 포함하는 테스트 케이스를 개발 할 필요가 있다. 7. 결 론 본 논문은 단위 테스트 단계에서 속성 기반 테스트를, 통합 테스트, 시스템 테스트 단계에서는 모델 기반 테스 트를 통해 스마트 컨트랙트 및 DApp의 신뢰성 및 정확 성을 체계적으로 테스트하는 기법을 제안하였다. 기존 UML 2.4.1 모델을 스마트 컨트랙트 소프트웨어에 맞게 확장하여 동적 설계 모델을 기반으로 테스트 케이스를 생성하는 기법을 제안하였으며, 단위 테스트 단계에서는 속성 기반 테스트로 테스트 케이스 없이 테스트를 진행 하는 기법을 사용하였다. 체계적인 각 테스트 단계를 거 쳐 Oyente와 같은 스마트 컨트랙트 정적 취약점 분석 도구들로는 발견할 수 없는 일반적인 소프트웨어 결함 을 발견할 수 있으며, 개발된 소프트웨어의 요구사항 충 족 여부를 확인할 수 있다. 또한, 통합 테스트와 시스템
doi:10.5626/jok.2019.46.8.763 fatcat:x6ambqclkfhq7huvl6fuacbghi