KR20230010603A

KR20230010603A - 다중-트랜잭션 차등 퍼징을 통한 컨센서스 버그 탐지

Info

Publication number: KR20230010603A
Application number: KR1020220085984A
Authority: KR
Inventors: 양영석; 전병곤; 김태수
Original assignee: 서울대학교산학협력단; 조지아 테크 리서치 코포레이션
Priority date: 2021-07-12
Filing date: 2022-07-12
Publication date: 2023-01-19
Also published as: WO2023287183A1

Abstract

실시예에 의하면, 멀티-트랜잭션 차등 퍼징(Multi-Transaction Differential Fuzzing)을 이용하여 컨센서스 버그(Consensus Bug)를 찾는 방법 및 장치를 제공한다.

Description

다중-트랜잭션 차등 퍼징을 통한 컨센서스 버그 탐지{CONSENSUS BUG DETECTION VIA MULTI-TRANSACTION DIFFERENTIAL FUZZING}

본 발명은 컨센서스 버그 탐지에 관한 것으로, 다중-트랜잭션 차등 퍼징(Multi-transaction Differential Fuzzing)을 이용하여 이더리움 클라이언트에 잠재된 컨센서스 버그를 찾는 방법 및 장치에 관한 것이다.

이하에서 기술되는 내용은 본 발명의 실시예와 관련되는 배경 정보를 제공할 목적으로 기재된 것일 뿐이고, 기술되는 내용들이 당연하게 종래기술을 구성하는 것은 아니다.

이더리움(Ethereum)은 비트코인(Bitcoin) 다음으로 두 번째로 큰 블록체인(Blockchain) 플랫폼이다. 이더리움 네트워크에서, 이더리움 스펙(Ethereum Specification)에 따라 탈집중화된(Decentralized) 이더리움 클라이언트들은 동일한 블록체인 상태로의 전이(transition)을 통해 컨센서스(consensus)에 도달한다.

컨센서스 버그는(Consensus Bug)는 이더리움 클라이언트들이 부정확한 블록체인 상태로 전이한 결과, 다른 클라이언트들과 컨센서스에 도달하는 것을 실패하도록 만드는 버그를 의미한다.

컨센서스 버그는 지극히 드물게 발생하지만, 일단 트리거(trigger)되면 네트워크 분리 및 도난을 위해 악용될 수 있고, 이는 이더리움 생태계(ecosystem)에서 신뢰성 및 보안에 치명적인 이슈들을 야기할 수 있으며, 특히 메인넷(mainnet)의 하드 포크(hard fork) 및 블록 유실이 발생되므로 이의 방지가 최우선적으로 요구된다.

한편, 퍼징(fuzzing) 기법을 활용하여 컨센서스 버그를 찾으려는 시도들이 존재하고, 일부 알려진 퍼저(fuzzer)는 몇몇 컨센서스 버그 발견에 성공하였다. 퍼징은 반복적으로 랜덤한 입력값을 만들고 이를 타겟 프로그램에 주입시켜서 버그를 발견하는 기술이다. 기존 이더리움 퍼징 기술은 한 개의 블록체인 상태(Blockchain State)와 한 개의 트랜색션(Transaction)을 만들고, 이를 여러 클라이언트들에 주입시켜서 서로 컨센서스를 이루는지 체크하였다(Differential Fuzzing).

하지만 이와같은 기존 퍼징 기술은 깊이 있는 클라이언트 상태 (Client State)를 탐색하지 못한다. 왜냐하면, 클라이언트 코드 패스(Code Path) 중에는 다중의 트랜잭션을 실행시켜야지만 발동되는 코드 패스들이 있기 때문이다. 결과적으로, 현존하는 퍼저에서 사용되는 블록체인 상태 모델은 컨센서스 버그를 찾기 위한 전체 탐색 공간(search space)을 커버하지 못하며, 결과적으로 이와 같은 한정된 커버리지를 벗어난 컨센서스 버그를 놓치는 한계가 있다.

따라서, 전체 탐색 공간에서 잠재적인 컨센서스 버그를 유발할 수 있는 코드 경로(code path)를 사전에 효과적으로 찾아낼 수 있는 방법이 필요하다.

한편, 전술한 선행기술은 발명자가 본 발명의 도출을 위해 보유하고 있었거나, 본 발명의 도출 과정에서 습득한 기술 정보로서, 반드시 본 발명의 출원 전에 일반 공중에게 공개된 공지기술이라 할 수는 없다.

본 발명의 일 과제는 전술한 문제점을 해결하기 위하여, 전체 탐색 공간에서 잠재적인 컨센서스 버그를 효과적으로 찾아낼 수 있는 컨센서스 버그 탐지 방법 및 장치를 제공하는 것이다.

본 발명의 일 과제는 컨센서스 버그 탐지를 위한 다중-트랜잭션 차등 퍼징 기법을 제공하는 것이다.

본 발명의 목적은 이상에서 언급한 과제에 한정되지 않으며, 언급되지 않은 본 발명의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있고, 본 발명의 실시 예에 의해 보다 분명하게 이해될 것이다. 또한, 본 발명의 목적 및 장점들은 청구범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 알 수 있을 것이다.

실시예에 따른 컨센서스 버그 탐지 방법은, 일련의 트랜잭션을 포함한 테스트 케이스에 대하여, 프로세서에 의해, 적어도 하나의 변이 과정을 실행하여 상기 일련의 트랜잭션 중 적어도 일부가 변경된 일련의 변이 트랜잭션(mutated transaction)을 생성하는 단계, 상기 프로세서에 의해, 상기 일련의 변이 트랜잭션을 복수의 이더리움 클라이언트에게 제공하는 단계, 상기 복수의 이더리움 클라이언트의 각각으로부터 상기 일련의 변이 트랜잭션에 의한 각 이더리움 클라이언트의 초기 블록체인 상태로부터의 상태 전이(state transition)와 연계된 일련의 전이 블록체인 상태를 획득하는 단계 및 상기 일련의 전이 블록체인 상태를 기반으로 상기 복수의 이더리움 클라이언트 간 컨센서스 정보를 결정하는 단계를 포함할 수 있다.

실시예에 따른 컨센서스 버그 탐지 장치는, 적어도 하나의 명령어를 저장하는 메모리; 및 프로세서를 포함하고, 상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금, 일련의 트랜잭션을 포함한 테스트 케이스에 대하여, 프로세서에 의해, 적어도 하나의 변이 과정을 실행하여 상기 일련의 트랜잭션 중 적어도 일부가 변경된 일련의 변이 트랜잭션(mutated transaction)을 생성하고, 상기 프로세서에 의해, 상기 일련의 변이 트랜잭션을 복수의 이더리움 클라이언트에게 제공하고, 상기 복수의 이더리움 클라이언트의 각각으로부터 상기 일련의 변이 트랜잭션에 의한 각 이더리움 클라이언트의 초기 블록체인 상태로부터의 상태 전이(state transition)와 연계된 일련의 전이 블록체인 상태를 획득하고, 상기 일련의 전이 블록체인 상태를 기반으로 상기 복수의 이더리움 클라이언트 간 컨센서스 정보를 결정하도록 구성될 수 있다.

전술한 것 외의 다른 측면, 특징, 및 이점이 이하의 도면, 청구범위 및 발명의 상세한 설명으로부터 명확해질 것이다.

실시예에 의하면 다중-트랜잭션 차등 퍼징을 이용한 컨센서스 버그 탐지 방법 및 장치가 제공된다.

실시예에 의하면 다수의 트랜색션을 퍼징함으로서 더 깊이 있는 클라이언트 상태를 탐색하여, 더 많은 수의 이더리움 버그를 검출할 수 있다.

본 발명의 효과는 이상에서 언급된 것들에 한정되지 않으며, 언급되지 아니한 다른 효과들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

도 1은 이더리움 블록체인 구성을 개략적으로 도시한다.
도 2는 실시예에 따른 컨센서스 버그 탐지를 개략적으로 설명하기 위한 도면이다.
도 3은 실시예에 따른 컨센서스 버그 탐지 장치의 블록도이다.
도 4는 실시예에 따른 컨센서스 버그 탐지 방법의 흐름도이다.
도 5a는 실시예에 따른 컨센서스 버그 탐지 방법의 추가 흐름도이다.
도 5b는 실시예에 따른 컨센서스 버그 탐지 방법의 추가 흐름도이다.
도 6은 실시예에 따른 컨센서스 버그 탐지를 예시적으로 설명하기 위한 도면이다.
도 7은 실시예에 따른 컨센서스 버그 탐지를 위한 예시적인 테스트 케이스의 자료 구조를 도시한다.
도 8은 실시예에 따른 컨센서스 버그 탐지를 위한 예시적인 변이 과정을 도시한다.
도 9는 실시예에 따른 컨센서스 버그 탐지 방법에 의한 예시적인 컨센서스 버그 탐지 과정을 설명하기 위한 도면이다.
도 10은 실시예에 따른 컨센서스 버그 탐지 방법에 의한 예시적인 컨센서스 버그 탐지 과정을 설명하기 위한 도면이다.

본 발명은 여러 가지 상이한 형태로 구현될 수 있으며, 여기에서 설명하는 실시예들에 한정되지 않는다. 이하 실시예에서는 본 발명을 명확하게 설명하기 위해서 설명과 직접적인 관계가 없는 부분을 생략하지만, 본 발명의 사상이 적용된 장치 또는 시스템을 구현함에 있어서, 이와 같이 생략된 구성이 불필요함을 의미하는 것은 아니다. 아울러, 명세서 전체를 통하여 동일 또는 유사한 구성요소에 대해서는 동일한 참조번호를 사용한다.

이하의 설명에서 제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 되며, 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 또한, 이하의 설명에서 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.

이하의 설명에서, "포함하다" 또는 "가지다" 등의 용어는 명세서 상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다. 이하 도면을 참고하여 본 발명을 상세히 설명하기로 한다.

도 1은 이더리움 블록체인 구성을 개략적으로 도시한다.

이더리움 네트워크(ENET)는 탈중앙화된 여러 이더리움 클라이언트 들(CLNT)로 이루어져있다. 클라이언트들은 서로 통신하면서 동일한 블록체인 상태(Blockchain State)로 변환하면서 서로 컨센서스(Consensus)를 이룬다. 블록체인 상태 변환 방식은 이더리움 명세(Ethereum Specification)를 따른다. 탈중앙화 피어-투-피어(peer-to-peer) 방식의 이더리움 클라이언트(CLNT)는 이더리움 가상 머신(Ethereum Virtual Machine; EVM) 스펙(specification)을 구현한다.

EVM은 이더리움 블록체인 상태(blockchain state)가 이더리움 블록 상에 기록된 트랜잭션을 통해 어떻게 변경되는지를 명세한 튜링 완전 머신(Turing complete machine)이다. 여기서 이더리움 블록체인 상태는 이더리움 계정(account)의 집합을 의미한다. 이더리움 계정(account)은 주소(address)가 있고, 이더리움 암호화폐인 이더(ETH)로 잔고(balance)를 보유한다.

이더리움 블록체인에는 두 종류의 계정(account)이 있다. 하나는 이더리움 유저가 소유하는 외부-소유 계정(Externally Owned Account; EOA)이고, 다른 하나는 코드(code)가 소유하는 key-value 저장소를 가진 스마트 계약(smart contract) 계정이다. 추가적으로, EVM은 고정된 주소들에서 특별한 오퍼레이션들(operations)을 수행하는 사전컴파일된 계약(precompiled contract)을 제공할 수 있다.

이더리움 트랜잭션(transaction)은 새로운 스마트 계약을 생성하는 계약 생성(contract creation) 트랜잭션과 스마트 계약을 발동(invoke)할 수 있는 메시지 콜(message call) 트랜잭션을 포함한다.

이더리움 클라이언트(CLNT)는 이더리움 네트워크 내에서 동일한 블록체인 상태로 합의를 이루는 소프트웨어 프로그램으로서, 이더리움 EVM 스펙에 부합하도록 구현된 EVM의 인스턴스(instance)이다. 이더리움 클라이언트(CLNT)는 예를 들어 Go and Rust와 같은 프로그래밍 언어로 EVM을 구현한다. 예를 들어 이더리움 클라이언트는 Geth(Golang 언어로 작성)와 OpenEthereum(Rust 언어로 작성)이 가장 많이 사용되고 있다.

EVM은 이더리움 클라이언트(CLNT)와 연계된 계정에 대한 트랜잭션(예를 들어, Ti, Ti+1)을 실행한다. EVM은 이더리움 바이트코드 명령어(bytecode instructions)를 처리하여 트랜잭션을 실행하며, 클라이언트의 블록체인 상태를 전이한다.

예를 들어, 이더리움 클라이언트(CLNT)는 트랜잭션(Ti)을 실행하여 블록체인 상태(Si-1)에서 블록체인 상태(Si)로 전이한다. 후속한 트랜잭션(Ti+1)에 의해 블록체인 상태(Si)에서 블록체인 상태(Si+1)로 전이할 수 있다.

도 2는 실시예에 따른 컨센서스 버그 탐지를 개략적으로 설명하기 위한 도면이다.

실시예에 따른 컨센서스 버그 탐지 장치(100)는 복수의 이더리움 클라이언트(예를 들어, CLNT_A, CLNT_B, CLNT_K)에게 테스트 케이스(Test Case)를 제공한다. 여기서 테스트 케이스는 일련의 트랜잭션을 포함한다. 도 2에는 세 개의 클라이언트와 3회의 트랜잭션이 도시되어 있으나 이는 예시적인 것이고 이에 제한되지 않으며, 더 많거나 적은 수의 클라이언트 및 트랜잭션이 가능하다.

각각의 이더리움 클라이언트(CLNT_A, CLNT_B, CLNT_K)는 테스트 케이스에 포함된 일련의 트랜잭션을 실행하고 그 결과를 컨센서스 버그 탐지 장치(100)에게 제공한다.

컨센서스 버그 탐지 장치(100)는 각각의 이더리움 클라이언트(CLNT_A, CLNT_B, CLNT_K)로부터 획득한 테스트 케이스 실행 결과를 비교하여 컨센서스 정보를 결정한다.

테스트 케이스 실행 결과는 트랜잭션에 의한 이더리움 클라이언트의 최종 블록체인 상태를 의미한다.

한편, 각 클라이언트는 클라이언트 프로그램 상태(Client Program State)를 가진다. 여기서 클라이언트 프로그램 상태는 클라이언트 프로그램 변수(program variable)로서, 클라이언트 코드에 해당한다.

도 2의 예시에서, 클라이언트 A(CLNT_A)는 제 1 트랜잭션(Tx1)에 의하여 클라이언트 A(CLNT_A)의 블록체인 상태(Sa1)로 전이한다. 후속하여 클라이언트 A(CLNT_A)는 제 2 트랜잭션(Tx2)에 의하여 클라이언트 A(CLNT_A)의 블록체인 상태(Sa2)로 전이하고, 제 3 트랜잭션(Tx3) 완료 후 클라이언트 A(CLNT A)의 블록체인 상태(Sa3)로 전이한다.

마찬가지로 클라이언트 B(CLNT_B)는 각 트랜잭션(Tx1, Tx2, Tx3)에 의해 클라이언트 B(CLNT_B)의 블록체인 상태(Sb1, Sb2, Sb3)를 전이하고, 클라이언트 K(CLNT_K)는 각 트랜잭션(Tx1, Tx2, Tx3)에 의해 클라이언트 K(CLNT_K)의 블록체인 상태(Sk1, Sk2, Sk3)를 전이한다.

컨센서스 버그 탐지 장치(100)는 일련의 트랜잭션(Tx1, Tx2, Tx3)에 의한 각 클라이언트의 블록체인 상태를 비교하고, 비교 결과를 기반으로 컨센서스 정보를 결정한다. 예를 들어, 컨센서스 버그 탐지 장치(100)는 일련의 트랜잭션(Tx1, Tx2, Tx3)에 의한 일련의 상태 전이가 합치되지 않으면, 해당 테스트 케이스에 의해 컨센서스 버그가 트리거된다고 결정할 수 있다.

한편, 각 클라이언트(CLNT_A, CLNT_B, CLNT_K)의 초기 블록체인 상태(Sa0, Sb0, Sk0)는 컨센서스 버그 탐지 장치(100)에 의해 각 클라이언트에게 제공될 수 있다. 즉, 각 클라이언트의 초기 블록체인 상태는 컨센서스 버그 탐지 장치(100)가 정한 블록체인 상태에 따라 결정될 수 있다. 즉, 각 클라이언트(CLNT_A, CLNT_B, CLNT_K)의 초기 블록체인 상태(Sa0, Sb0, Sk0)는 동일하다.

이하에서 실시예에 따른 컨센서스 버그 탐지에 대하여 구체적으로 설명한다.

도 3은 실시예에 따른 컨센서스 버그 탐지 장치의 블록도이다.

컨센서스 버그 탐지 장치(100)는 프로세서(110) 및 메모리(120)를 포함한 전자 장치로서, 프로세서(110)는 메모리(120)에 저장된 적어도 하나의 명령어를 실행하여 실시예에 따른 컨센서스 버그 탐지 과정을 실행할 수 있다.

예를 들어, 컨센서스 버그 탐지 장치(100)는 데스크탑, PC, 모바일 단말 또는 서버 장치와 같은 프로세서(110)를 구비한 컴퓨팅 장치일 수 있다. 예를 들어, 컨센서스 버그 탐지 장치(100)는 단일(standalone) 컴퓨팅 장치 또는 분산 컴퓨팅 장치일 수 있으며, 이에 제한되지 않고 다양한 컴퓨팅 방식으로 구현될 수 있다.

프로세서(110)는 일종의 중앙처리장치로서, 메모리(120)에 저장된 하나 이상의 명령어를 실행하여 컨센서스 버그 탐지 장치(100)의 동작을 제어할 수 있다.

프로세서(110)는 데이터를 처리할 수 있는 모든 종류의 장치를 포함할 수 있다. 프로세서(110)는 예를 들어 프로그램 내에 포함된 코드 또는 명령으로 표현된 기능을 수행하기 위해 물리적으로 구조화된 회로를 갖는, 하드웨어에 내장된 데이터 처리 장치를 의미할 수 있다.

이와 같이 하드웨어에 내장된 데이터 처리 장치의 일 예로서, 마이크로프로세서(microprocessor), 중앙처리장치(central processing unit: CPU), 프로세서 코어(processor core), 멀티프로세서(multiprocessor), ASIC(application-specific integrated circuit), FPGA(field programmable gate array) 등의 처리 장치를 망라할 수 있으나, 이에 한정되는 것은 아니다. 프로세서(110)는 하나 이상의 프로세서를 포함할 수 있다.

메모리(120)는 실시예에 따른 컨센서스 버그 탐지 방법을 실행하기 위한 적어도 하나의 명령어를 저장할 수 있다.

메모리(120)는 테스트 케이스를 포함한 코퍼스(corpus), 블록리스트 정보, 트랜잭션 정보, 블록체인 상태 정보, 클라이언트 프로그램 상태 정보 및 컨센서스 버그 탐지 과정에서 생성되는 중간 데이터 및 연산 결과 등을 저장할 수 있다.

메모리(120)는 내장 메모리 및/또는 외장 메모리를 포함할 수 있으며, DRAM, SRAM, 또는 SDRAM 등과 같은 휘발성 메모리, OTPROM(one time programmable ROM), PROM, EPROM, EEPROM, mask ROM, flash ROM, NAND 플래시 메모리, 또는 NOR 플래시 메모리 등과 같은 비휘발성 메모리, SSD, CF(compact flash) 카드, SD 카드, Micro-SD 카드, Mini-SD 카드, Xd 카드, 또는 메모리 스틱(memory stick) 등과 같은 플래시 드라이브, 또는 HDD와 같은 저장 장치를 포함할 수 있다. 메모리(120)는 자기 저장 매체(magnetic storage media) 또는 플래시 저장 매체(flash storage media)를 포함할 수 있으나, 이에 한정되는 것은 아니다.

추가적으로 컨센서스 버그 탐지 장치(100)는 외부 장치와의 데이터 송수신을 수행하도록 구성된 통신 인터페이스를 더 포함할 수 있다. 예를 들어 컨센서스 버그 탐지 장치(100)는 통신 인터페이스를 통해 테스트 케이스를 외부 장치로부터 수신하고 버그 탐지 결과를 외부 장치로 전송할 수 있다.

도 4는 실시예에 따른 컨센서스 버그 탐지 방법의 흐름도이다.

실시예에 따른 컨센서스 버그 탐지 방법은 일련의 트랜잭션을 포함한 테스트 케이스에 대하여, 프로세서(110)에 의해, 적어도 하나의 변이 과정을 실행하여 일련의 트랜잭션 중 적어도 일부가 변경된 일련의 변이 트랜잭션(mutated transaction)을 생성하는 단계(ST1), 프로세서(110)에 의해, 일련의 변이 트랜잭션을 복수의 이더리움 클라이언트(CLNT)에게 제공하는 단계(ST2), 복수의 이더리움 클라이언트(CLNT)의 각각으로부터 일련의 변이 트랜잭션에 의한 각 이더리움 클라이언트(CLNT)의 초기 블록체인 상태로부터의 상태 전이(state transition)와 연계된 일련의 전이 블록체인 상태를 획득하는 단계(ST3) 및 일련의 전이 블록체인 상태를 기반으로 복수의 이더리움 클라이언트(CLNT) 간 컨센서스 정보를 결정하는 단계(ST4)를 포함한다.

단계(ST1)에서 프로세서(110)는 일련의 트랜잭션을 포함한 테스트 케이스에 대하여, 프로세서(110)에 의해, 적어도 하나의 변이 과정을 실행하여 일련의 트랜잭션 중 적어도 일부가 변경된 일련의 변이 트랜잭션을 생성한다.

단계(ST1)은 트랜잭션 컨텍스트(transaction context) 변이, 트랜잭션 파라미터 변이 및 EVM 바이트코드 변이 중 적어도 하나의 변이를 적용하는 단계를 포함한다.

트랜잭션 컨텍스트 변이는 테스트 케이스의 블록 리스트와 트랜잭션 리스트를 랜덤하게 변이한다. 트랜잭션 파라미터 변이는 트랜잭션 리시버 주소 등을 변이한다. EVM 바이트 코드 변이는 계약 생성 트랜잭션의 생성자(constructor) 필드와 반환 코드(code-to-return) 필드를 변이한다. 각 변이에 대하여는 도 8을 참조하여 후술한다.

단계(ST1)에서 프로세서(110)는 일련의 트랜잭션 중 적어도 일부에 대하여 전술한 세 가지 변이 중 적어도 하나의 변이를 적용할 수 있다.

단계(ST2)에서 프로세서(110)는 단계(ST1)에서 생성된 일련의 변이 트랜잭션을 복수의 이더리움 클라이언트(CLNT)에 제공한다.

예를 들어 프로세서(110)는 다양한 방식의 프로세스 간 통신 인터페이스를 통해 이더리움 클라이언트에 일련의 변이 트랜잭션을 제공할 수 있다. 예를 들어 프로세서(110)는 통신 인터페이스를 통해 외부 장치에서 실행 중인 이더리움 클라이언트에 일련의 변이 트랜잭션을 전송할 수 있다.

복수의 이더리움 클라이언트(CLNT)는 컨센서스 버그 탐지 장치(100)가 제공한 일련의 변이 트랜잭션을 실행한다. 복수의 이더리움 클라이언트(CLNT)는 각각 일련의 변이 트랜잭션에 의해 각자의 초기 블록체인 상태로부터 일련의 전이 블록체인 상태로 순차적으로 블록체인 상태를 전이(state transition)하며, 일련의 변이 트랜잭션에 의한 코드 경로(code path) 정보를 생성한다.

단계(ST3)에서 프로세서(110)는 복수의 이더리움 클라이언트(CLNT)의 각각으로부터 일련의 변이 트랜잭션에 의한 각 이더리움 클라이언트(CLNT)의 초기 블록체인 상태로부터의 상태 전이와 연계된 일련의 전이 블록체인 상태를 획득한다.

예를 들어 프로세서(110)는 다양한 방식의 프로세스 간 통신 인터페이스를 통해 이더리움 클라이언트로부터 일련의 전이 블록체인 상태를 획득할 수 있다. 예를 들어 프로세서(110)는 통신 인터페이스를 통해 외부 장치에서 실행 중인 이더리움 클라이언트로부터 일련의 전이 블록체인 상태를 수신할 수 있다.

단계(ST3)는 프로세서(110)에 의해 일련의 변이 트랜잭션에 의한 코드 경로 정보를 획득하는 단계를 포함할 수 있다. 프로세서(110)는 전술한 일련의 전이 블록체인 상태를 획득하는 방식과 동일한 방식으로 복수의 이더리움 클라이언트(CLNT)로부터 각 이더리움 클라이언트에서의 일련의 변이 트랜잭션에 의한 코드 경로 정보를 획득할 수 있다.

단계(ST4)에서 프로세서(110)는 일련의 전이 블록체인 상태를 기반으로 복수의 이더리움 클라이언트(CLNT) 간 컨센서스 정보를 결정할 수 있다. 단계(ST4)에서 프로세서(110)는 복수의 이더리움 클라이언트(CLNT)가 일련의 변이 트랜잭션에 의해 각각 동일한 블록체인 상태로 전이하였는 지를 판단할 수 있다.

단계(ST4)는 프로세서(110)에 의해 각 이더리움 클라이언트로부터 단계(ST3)에서 획득한 일련의 전이 블록 상태를 각 순서대로 비교하는 단계 및 이와 같은 비교의 결과를 기반으로 일련의 트랜잭션에 대한 복수의 이더리움 클라이언트 간 컨센서스 결과를 결정하는 단계를 포함한다. 이에 대하여는 도 6을 참조하여 살펴본다.

한편, 컨센서스 정보는 테스트 케이스에 대한 복수의 이더리움 클라이언트(CLNT)의 상태 전이가 합치되는 지를 나타내는 정보로서, 예를 들어 복수의 이더리움 클라이언트(CLNT) 간 충돌(crash) 정보를 포함한다.

단계(ST4)는 프로세서(110)에 의해 단계(ST3)에서 획득한 코드 경로 정보에 기반하여 복수의 이더리움 클라이언트 간 충돌 정보를 추적하는 단계를 포함할 수 있다. 여기서 충돌 정보는 예를 들어 불합치된 전이 블록체인 상태 정보 및 충돌을 유발한 코드 위치를 포함할 수 있다.

추가적으로 컨센서스 버그 탐지 방법은 코퍼스에 저장된 테스트 케이스 집합에서 테스트 케이스를 선택하는 단계(ST0) 및 일련의 변이 트랜잭션를 포함하는 또다른(another) 테스트 케이스를 테스트 케이스 집합에 저장하는 단계(ST5)를 더 포함할 수 있다.

예를 들어, 단계(ST4)에서 컨센서스에 도달한 경우, 실시예에 따른 방법은 일련의 변이 트랜잭션을 또다른 테스트 케이스로서 코퍼스에 저장하는 단계(ST5)를 더 포함할 수 있다. 또한, 단계(ST1)에 앞서서 테스트 케이스를 선택하는 단계(ST0)를 더 포함할 수 있다. 이에 대하여는 도 5a 및 도 5b를 참조하여 살펴본다.

한편, 컨센서스 버그 탐지 방법은 소정의 횟수만큼 또는 코퍼스 내의 모든 테스트 케이스에 대하여 단계(ST0) 내지 단계(ST5)를 반복하여 실행할 수 있다.

도 5a는 실시예에 따른 컨센서스 버그 탐지 방법의 추가 흐름도이다.

컨센서스 버그 탐지 방법은 단계(ST4) 이후에 단계(ST4)에서 컨센서스에 도달한 경우, 일련의 변이 트랜잭션를 포함하는 또다른 테스트 케이스를 상기 테스트 케이스 집합에 저장하는 단계(ST5)를 더 포함할 수 있다.

도 5b는 실시예에 따른 컨센서스 버그 탐지 방법의 추가 흐름도이다.

컨센서스 버그 탐지 방법은 단계(ST1) 이전에 코퍼스에 저장된 테스트 케이스 집합에서 테스트 케이스를 선택하는 단계(ST0)를 더 포함할 수 있다. 예를 들어 프로세서(110)는 랜덤방식으로 또는 테스트 케이스에 포함된 트랜잭션의 개수의 내림차순 또는 오름차순으로 테스트 케이스를 선택할 수 있으며, 이에 제한되지 않고 다양한 방식으로 테스트 케이스를 선택할 수 있다.

도 6은 실시예에 따른 컨센서스 버그 탐지를 예시적으로 설명하기 위한 도면이다.

컨센서스 버그 탐지 장치(100)는 다중-트랜잭션 차등 퍼저(Multi-Transaction Differential Fuzzer)로서 작동한다.

컨센서스 버그 탐지 장치(100)는 클라이언트 프로그램 상태 모델로서 이더리움 클라이언트(CLNT)를 모델링함으로써, 컨센서스 버그를 찾기 위한 탐색 공간을 전체적으로 커버할 수 있다. 클라이언트 프로그램 상태 모델에서 컨센서스 버그 탐지 장치(100)는 매 반복(iteration)에서 일련의 다중-트랜잭션들을 테스트한다. 또한, 컨센서스 버그 탐지 장치(100)는 교차-참조 오라클(cross-reference oracles)로서 복수의 이더리움 클라이언트를 사용한다.

단계(ST0)에서 프로세서(110)는 사전에 실행된 테스트 케이스들의 코퍼스로부터 테스트 케이스를 선택한다. 테스트 케이스는 컨센서스 버그 탐지 장치(100)가 이더리움 클라이언트를 한번 실행할 때 사용하는 테스트 단위로서, 하나의 테스트 케이스는 여러 블록들을 가지고 있다. 여기서 블록(Block)은 이더리움 블록으로 하나의 블록은 여러 개의 트랜잭션을 기록한다.

코퍼스(CPS)는 과거 실행한 테스트 케이스 저장소이고, 뮤테이터(Mutator; MUTT)는 단계(ST1)에서 프로세서(110)에 의해 실행되며, 테스트 케이스를 변이하여 생성된 일련의 변이 트랜잭션을 포함한 새로운 테스트 케이스 생성한다.

트랜잭션(Tx)은 하나의 이더리움 계정 (account)가 다른 계정으로 이더리움을 송금하는 것으로서, 만약 받는 계정이 스마트 컨트랙트(Smart contract)일 경우 해당 스마트 컨트랙트의 코드가 실행된다.

각 테스트 케이스는 다중 트랜잭션들과 트랜잭션들 간 의존도에 대한 정보를 포함한다.

단계(ST1)에서 프로세서(110)는 단계(ST0)에서 선택된 테스트 케이스의 일련의 트랜잭션을 변이하여 일련의 변이 트랜잭션(M_SEQ_T)을 생성한다.

후속하여 복수의 이더리움 클라이언트(예를 들어 CLNT_A, CLNT_B, CLNT_K)는 일련의 변이 트랜잭션(M_SEQ_T)을 실행한다.

복수의 이더리움 클라이언트(예를 들어 CLNT_A, CLNT_B, CLNT_K)는 변이된 테스트 케이스 내의 트랜잭션들(Tx1, Tx2, Tx3)을 실행하는 동안, 초기 블록체인 상태(Sa0, Sb0, Sk0)를 새로운 블록체인 상태, 즉 일련의 전이 블록체인 상태(CLNT_A: (Sa1, Sa2, Sa3), CLNT_B: (Sb1, Sb2, Sb3), CLNT_K: (Sk1, Sk2, Sk3))로 전이한다.

실행이 완료된 경우, 프로세서(110)는 단계(ST3)에서 복수의 이더리움 클라이언트(예를 들어 CLNT_A, CLNT_B, CLNT_K)로부터 새로운 블록체인 상태들과 코드 커버리지 피드백을 수집한다. 여기서 코드 커버리지(Code coverage)는 클라이언트 상태(Client State)를 얼마나 많이 탐색하였는지에 대한 통계정보이다.

단계(ST4)에서 프로세서(110)는 일련의 전이 블록체인 상태를 기반으로 복수의 이더리움 클라이언트(CLNT) 간 컨센서스 정보를 결정할 수 있다.

단계(ST4)에서 프로세서(110)는 상이한 클라이언트로부터 수집된 블록체인 상태를 교차-확인(cross-check)한다.

예를 들어 클라이언트가 두 개(CLNT_A, CLNT_B)인 경우, 프로세서(110)는 클라이언트들이 (Sa1 != Sb1 || Sa2 != Sb || Sa3 != Sb3)를 실행하는 동안 서로 다른 상태로 전이하였는 지를 판단하고 이에 따라 컨센서스 정보를 결정한다.

예를 들어 클라이언트가 k 개(CLNT_A, CLNT_B 내지 CLNT_K)인 경우, 프로세서(110)는 각 클라이언트가 일련의 트랜잭션 후 서로 다른 상태로 전이하였는 지를 판단하고 이에 따라 컨센서스 정보를 결정한다.

클라이언트들이 서로 다른 상태로 전이한 경우 충돌(crash)이 발생한 것으로 판단한다. 클라이언트들이 동일한 최종 블록체인 상태에 도달하였다면 컨센서스 버그가 검출되지 않은 것으로 판단하고 다시 단계(ST0)를 시작한다.

단계(ST5)에서 프로세서(110)는 단계(ST3)에서 수집한 정보로부터 새로운 코드 경로(code path)가 발견되면 일련의 변이 트랜잭션을 포함한 새로운 테스트 케이스를 코퍼스에 저장한다.

도 7은 실시예에 따른 컨센서스 버그 탐지를 위한 예시적인 테스트 케이스의 자료 구조를 도시한다.

테스트 케이스(class FluffTestCase)는 블록 리스트를 포함하고, 각 블록(class Block)은 트랜잭션 리스트를 포함한다.

즉, 프로세서(110)는 순서에 따라 블록 리스트의 각 블록의 트랜잭션들을 복수의 이더리움 클라이언트 각각에서 실행토록 하고, 각 트랜잭션을 블록 체인 상태에 적용하여 테스트 케이스를 실행한다.

-Test Case

하나의 테스트 케이스는 여러 블록들을 가지고, 각 블록은 여러 트랜잭션을 갖는다. 테스트 수행시, 블록과 트랜잭션이 리스트 순서대로 여러 이더리움 클라이언트들에서 실행된다.

이더리움 블록과 트랜잭션에서 주요한 parameter들만 특정 후보값들을 지정해놓고 랜덤하게 생성한다. 언급되지 않은 parameter들은 적절한 constant값을 갖게 하여 이더리움 클라이언트에서 실행한다.

Parameter 이외에도, 랜덤하게 Transaction 개수 및 Block 개수를 변형해 가며 퍼징을 진행한다.

- Block

transactions: 다중의 transaction 기록

versionNumber: 블록의 버전 넘버로 이더리움이 hard-fork upgrade한 시점의 버전 넘버들을 후보로 사용한다.

timestamp: 블록의 timestamp로 앞 뒤 블록의 timestamp의 사이 값들을 후보로 사용한다.

- Transaction

gasLimit: gasLimit은 주로 smart contract 코드의 실행 범위를 결정하는데, 너무 큰 gasLimit은 너무 큰 smart contract를 실행하여 의미 없는(버그가 있을 확률이 적은) contract instruction들을 실행하여 fuzzer의 성능을 낮추기 때문에, threshold 안에서 후보 값을 정한다. 예를들어 한번 테스트를 실행 했을 때 smart contract infinite loop에 오랬동안 빠져서 다음 테스트를 실행하기 전까지 너무 많은 시간을 소요하는 것을 방지한다.

value: 코너케이스인 0-value 트랜잭션을 좀 더 많이 테스트하도록 설정한다.

data: 기존 퍼징 기술들을 이 parameter를 random bytes로 설정하지만, 본 발명에서는 CreateContract/MessageCall에 따라 다르게 설정한다. (CreateContract는 새로운 smart contract를 생성하는 트랜색션이고, MessageCall은 생성된 smart contract를 호출하는 트랜색션이다.)

- CreateContract extends Transaction

data parameter를 다음 두 개의 항목을 조합하여 생성한다.

constructor: smart contract를 생성할 때 실행되는 부분, 랜덤한 EVM instruction들을 생성한다.

codeToReturn: smart contract의 코드로 설정되는 부분, 랜덤한 EVM instruction들을 생성한다.

- MessageCall extends Transaction

receiver: 과거 transaction에서 생성된 smart contract 주소 (activated address)

이하에서는 도 4를 참조하여 단계(S1)의 변이 트랜잭션을 생성하는 변이 과정에 대하여 살펴본다.

트랜잭션 컨텍스트 변이

프로세서(110)는 트랜잭션의 컨텍스트(context)를 변이할 수 있다. 여기서 트랜잭션의 컨텍스트는 트랜잭션 이전에 실행된 트랜잭션들의 순서화된 시퀀스로 정의한다.

프로세서(110)는 트랜잭션 컨텍스트를 변이하기 위해 블록들의 리스트와 트랜잭션들의 리스트를 랜덤하게 변이할 수 있다. 프로세서(110)는 다음의 4가지, 즉, add, delete, clone, copy에 의해 트랜잭션 컨텍스트를 변이할 수 있다.

예를 들어, 프로세서(110)는 새로운 블록 또는 새로운 트랜잭션을 리스트에 추가하거나 또는 현재 있는 것을 삭제할 수 있다. 또한 예를 들어 프로세서(110)는 존재하는 블록 또는 트랜잭션을 클로닝(clone)하거나 또는 트랜잭션의 내용(contents)을 다른 블록 또는 트랜잭션에 복사할 수 있다.

한편, 종래의 퍼저는 사전-트랜잭션(pre-transaction) 블록체인 상태를 직접 생성하고, 이로부터 단일 트랜잭션을 테스트한다. 이와 같은 각 pre-transaction 블록체인 상태에 대하여 오직 단일 pre-transaction 클라이언트 프로그램 상태만을 테스트하도록 제한된다.

하지만, 실시예에 따른 다중-트랜잭션 차등 퍼징 기법은 각 pre-transaction 블록체인 상태(예를 들어 계정 A는 0ETH를 가진다)에 대하여 다양한 pre-transaction 클라이언트 프로그램 상태(예를 들어 account_a = {ETH:0, deleted: false}), account_a={ETH:3, deleted: true})를 생성 및 테스트할 수 있다.

이는 이더리움 클라이언트들이 클라이언트 프로그램 변수들의 값이 어떤 시퀀스의 트랜잭션들이 실행되는 지에 따라 다양한 방식으로 변화할 수 있기 때문이다. 결과적으로 종래 퍼저로는 찾을 수 없는, 도 10을 참조하여 후술할 버그(transfer-after-destruct bug)를 찾을 수 있다. 도 10의 버그는 블록체인 상태 변이 기법은 생성할 수 없는 특정 pre-transaction 클라이언트 프로그램 상태를 테스트하는 것을 필요로 한다.

EVM 바이트코드 변이

도 7을 참조하여 계약 생성 트랜잭션(class CreateContract)는 계약 생성 트랜잭션을 위한 constructor 및 code-to-return field를 포함한다. 이와 같은 필드는, 몇몇 주입된(injected) 인스트럭션들과 함께, 트랜잭션의 데이터 필드의 일부가 된다.

프로세서(110)는 단계(ST1)에서 직접 새롭게 생성된 스마트 계약들의 코드를 변이할 수 있도록 하며, 이는 트랜잭션이 완료되는 때에 반환코드(code-to-return)로 설정된다. 이에 대하여는 도 8을 참조하여 살펴본다.

기존 이더리움 퍼저들은 퍼징 반복 당 단일 트랜잭션을 실행하고 트랜잭션에 의해 생성된 스마트 계약의 코드를 인보킹하지 않기 때문에 EVM 바이트코드 변이와 같은 접근법을 고려하지 못하였다.

트랜잭션 파라미터 변이

프로세서(110)는 트랜잭션 파라미터를 변이할 수 있다. 프로세서(110)는 단계(ST1)에서 트랜잭션들 및 블록 파라미터들의 가능한 값들을 제한하여 무의미한 변이 및 실행으로 낭비되는 CPU 사이클들을 줄인다. 또한 클라이언트들이 트랜잭션들을 실행하는 방식에 제한적인 영향을 가지는 파라미터들에 대해 상수 값을 사용하도록 설정할 수 있다. 이로써 다중 트랜잭션 변이 및 실행의 오버헤드를 줄일 수 있다.

예를 들어, 타겟 클라이언트들이 활성화된 주소로 변환할 것이라는 전제하에, 프로세서(110)는 트랜잭션 리시버 주소를 랜덤 정수로 단순히 설정할 수 있다.

예를 들어, 프로세서(110)는 EVM이 바이트코드를 인보킹하기 전에 트랜잭션을 거절하지 않기 위해 요구되는 최소 가스의 합으로 gas limit을 설정할 수 있다.

예를 들어, 프로세서(110)는 무한 while loop와 같은 의미없는 인스트럭션들의 긴 시퀀스를 피하기 위하여 0부터 임계값 사이에서 랜덤하게 생성된 숫자로 gas limit을 설정할 수 있다. 예를 들어, 임계값을 1600만 gas로 설정하여 32000 gas가 소요되는 가장 비싼 CREATE 인스트럭션을 50번 실행하는 것을 허락할 수 있다. 1600만 gas는 2020년 8월 기준 이더리움 메인넷 상에서 단지 약 0.8 ETH이다. 트랜잭션에 의해 트랜스퍼 되는 ETH의 양을 결정하는 value의 경우, 프로세서(110)는 0, 1 또는 랜덤 정수를 랜덤하게 선택할 수 있다.

한편, 프로세서(110)는 블록들의 파라미터들을 랜덤하게 변이할 수 있다. 프로세서(110)는 트랜잭션을 실행하는 EVM의 버전을 결정하는 블록 버전 번호를 변이할 수 있다. 이더리움이 2014년에 론칭된 이래로, 약 10 번의 non-backward compatible EVM 하드-포크 업그레이드들이 있어왔고 이는 특정 블록 버전 넘버들에 영향을 주었다. 2020년 8월 기준 1000만개 이상인, 메인넷에서 사용된 모든 블록 버전 넘버들을 커버하기 보다는 새로운 EVM 하드-포크 업그레이드의 시작을 위한 버전 넘버들을 사용할 수 있도록 한다.

도 8은 실시예에 따른 컨센서스 버그 탐지를 위한 예시적인 변이 과정을 도시한다.

CreateContract transaction으로 smart contract가 생성될 때, byte[] data는 EVM instruction들로 해석되어서 실행되고, 이를 통해 RETURN 되는 bytes들이 생성된 smart contract의 code로 저장된다. 따라서 byte[] data가 의미있는 bytes들을 RETURN하는 것이 중요하다.

실시예에서, CreateContract transaction의 byte[] data는 위와 같이 constructor와 codeToReturn의 조합으로 구성된다. 이 조합을 통해 새로운 contract생성을 돕는다. 기존 기술들은 블록체인 스테이트 자체를 랜덤 생성하면서, 임의의 contract를 직접 만들기 때문에 위와 같은 방식을 쓰지 않는다. 이에 비해, 본 발명품은 다수의 트랜잭션을 랜덤생성하기 때문에 이전 트랜잭션이 만든 스마트 컨트랙트를 그 다음 트랜잭션이 호출하는 경우가 발생하기 때문에, 위와 같은 방식으로 새로운 contract를 생성하는 것을 용이하게 하는 것이 중요하다.

byte[] data의 구성요소는 다음과 같다

- byte[] constructor: 생성된 constructor 그대로 사용

- skip code-to-return: EVM instruction들을 삽입하여 codeToReturn을 스킵한다.

- byte[] codeToReturn: 생성된 codeToReturn 그대로 사용

- Copy and return: codeToReturn 부분을 복사하여 리턴한다.

CreateContract는 다음과 같이 실행된다.

(1) Execute constructor: constructor 코드가 실행된다.

(2) Skip code-to-return: codeToReturn 이후로 PC(Program Counter)를 JUMP 한다

(3) Copy to EVM memory: codeToReturn에 해당하는 코드를 EVM memory에 CODECOPY 한다

(4) Return the copied Code-To-Return: 카피된 해당 코드를 RETURN한다.

이를 통해, 새롭게 만들어진 contract는 codeToReturn을 코드로 갖는다.

도 8을 참조하여 바이트코드 변이를 살펴본다.

프로세서(110)는 바이트코드를 변이하기 위하여 계약 생성 트랜잭션들의 constructor와 code-to-return 필드를 변이할 수 있다.

구체적으로, 프로세서(110)는 계약 생성 트랜잭션들의 constructor와 code-to-return 필드에 랜덤하게 바이트코드 인스트럭션들을 add, delete, mutate, copy 할 수 있다.

다양한 EVM 인스트럭션들 중에서 프로세서(110)는 EVM이 바이트들 및 바이트 코드 인스트럭션들을 인터프리팅(interpret)하고 실행하는 대신에 해당 필드들에서 몇몇 후속 바이트들(1B-32B)을 EVM 스택 상으로 푸쉬하도록 하는 PUSH 인스트럭션들(PUSH1-PUSH32)을 add하지 않았으며, 이와 같은 접근법은, 변이를 거치면서 프로세서(110)에 의해 직접적으로 변경되지 않는 바이트코드 인스트럭션들의 시멘틱(semantics)을 보존할 수 있도록 한다.

도 8에서, 프로세서(110)는 변이된 constructor와 code-to-return을 이용하여 data 필드를 업데이트할 수 있다.

프로세서(110)는 constructor, code-to-return의 실행을 스킵하는 인스트럭션(JUMP), code-to-return을 EVM 메모리에 복사하는 인스트럭션(CODECOPY), 그리고 복사된 바이트코드를 리턴(RETURN)하는 인스트럭션을 연결(concatenate)한다.

이후, 트랜잭션이 실행되고 data 필드의 바이트코드가 인보킹될 때, constructor는 실행되고 code-to-return이 리턴된다.

이와 같은 바이트 코드 변이는, data 필드를 단일 시퀀스의 인스트럭션으로 취급하지 않으며, data 필드 전체를 하나로(as a whole) 변이하지 않도록 하며, 이로써 적합한 바이트코드를 리턴하는 스마트 계약 constructor들을 생성할 수 있도록 해준다.

data 필드를 단일 시퀀스의 인스트럭션으로 취급하고, data 필드 전체를 하나로(as a whole) 변이하는 경우, 생성된 constructor는 리턴(RETURN)을 인보킹하여 바이트코드를 리턴하기 전에 이미(prematurely) 종료되기 쉽다는 문제점이 있는 반면, 실시예에 따른 바이트코드 변이는 이와 같은 문제를 완화한다. 또한, RETURN을 인보킹하기 전에 적합한 바이트들이 EVM 메모리의 제 영역에 저장되어야만 하고, 작은 변이에 의해 저장된 바이트들이 완전히 변경되는 문제를 완화한다.

실시예에서, 스마트 계약의 코드가 계약을 생성한 트랜잭션의 code-to-return 필드와 항상 동일한 것은 아니며, 이는 트랜잭션의 constructor 필드 실행 중에 EVM 스택 오버플로우와 같은 에러들이 여전히 발생할 수 있고, 후속한 삽입된 인스트럭션들이 code-to-return을 복사 및 리턴하는 것을 방지하기 때문이다.

도 9는 실시예에 따른 컨센서스 버그 탐지 방법에 의한 예시적인 컨센서스 버그 탐지 과정을 설명하기 위한 도면이다.

도 9는 실시예에 따른 컨센서스 버그 탐지 방법에 의해 Geth에서 Shallow Copy bug를 발견할 수 있도록 한 테스트 케이스 및 작동 과정을 보여준다.

공격자(attacker)는 shallow copy bug를 이용하여 사전컴파일된(precompiled) DataCopy 계약을 무너뜨리고(corrupt), Geth가 EVM 스펙과 다르게 작동(deviate)하도록 만들 수 있다.

도 10은 실시예에 따른 컨센서스 버그 탐지 방법에 의한 예시적인 컨센서스 버그 탐지 과정을 설명하기 위한 도면이다.

도 9는 실시예에 따른 컨센서스 버그 탐지 방법에 의해 Geth에서 Transfer-After-Destruct-Bug를 발견할 수 있도록 한 테스트 케이스 및 작동 과정을 보여준다.

Transaction 1이 B를 인보킹하고, 이는 Call A를 2회 실행하도록 한다. Transaction 2는 A를 인보킹한다. 공격자는 Transfer-After-Destruct-Bug를 이용하여 삭제된 계정의 잔고를 동일한 주소의 새로운 계정으로 가로챌 수 있으며, 이는 Geth가 EVM 스펙과 다르게 작동(deviate)하도록 만든다.

본 기술을 확장하여, 이더리움 이외에 다른 스마트 컨트랙트 기반 블록체인 버그 검출에도 적용될 수 있다(예: Cardano, Stellar, EOS, NEM, Tron, Tezos, and Neo)

전술한 본 발명의 일 실시예에 따른 방법은 컴퓨터 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 즉, 일 실시예에 따른 방법은 프로세서에 의해 실시예에 따른 방법을 실행하도록 구성된 적어도 하나의 명령어를 포함하는 컴퓨터 프로그램을 저장한 컴퓨터 판독가능한 비 일시적 기록 매체로 제공가능하다.

컴퓨터가 읽을 수 있는 비 일시적 기록 매체는, 컴퓨터 시스템에 의하여 읽힐 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 비 일시적 기록 매체의 예로는, HDD(Hard Disk Drive), SSD(Solid State Disk), SDD(Silicon Disk Drive), ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있다.

이상 설명된 본 발명의 실시 예에 대한 설명은 예시를 위한 것이며, 본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명의 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 쉽게 변형이 가능하다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 예를 들어, 단일형으로 설명되어 있는 각 구성 요소는 분산되어 실시될 수도 있으며, 마찬가지로 분산된 것으로 설명되어 있는 구성 요소들도 결합된 형태로 실시될 수 있다.

본 발명의 범위는 상기 상세한 설명보다는 후술하는 청구범위에 의하여 나타내어지며, 청구범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

100: 컨센서스 버그 탐지 장치
110: 프로세서
120: 메모리
ENET: 이더리움 블록체인 네트워크
CLNT: 이더리움 클라이언트
EVM: 이더리움 가상 머신

Claims

프로세서를 포함한 컨센서스 버그 탐지 장치에 의해 실행되는 컨센서스 버그 탐지 방법에 있어서,
일련의 트랜잭션을 포함한 테스트 케이스에 대하여, 프로세서에 의해, 적어도 하나의 변이 과정을 실행하여 상기 일련의 트랜잭션 중 적어도 일부가 변경된 일련의 변이 트랜잭션(mutated transaction)을 생성하는 단계;
상기 프로세서에 의해, 상기 일련의 변이 트랜잭션을 복수의 이더리움 클라이언트에게 제공하는 단계;
상기 복수의 이더리움 클라이언트의 각각으로부터 상기 일련의 변이 트랜잭션에 의한 각 이더리움 클라이언트의 초기 블록체인 상태로부터의 상태 전이(state transition)와 연계된 일련의 전이 블록체인 상태를 획득하는 단계; 및
상기 일련의 전이 블록체인 상태를 기반으로 상기 복수의 이더리움 클라이언트 간 컨센서스 정보를 결정하는 단계를 포함하는,
컨센서스 버그 탐지 방법.
제 1 항에 있어서,
상기 일련의 트랜잭션의 각 트랜잭션은 스마트 계약을 생성하는 계약 생성 트랜잭션 또는 스마트 계약을 호출하는 메시지 콜 트랜잭션인,
컨센서스 버그 탐지 방법.
제 1 항에 있어서,
상기 일련의 변이 트랜잭션을 생성하는 단계는,
상기 일련의 트랜잭션 중 적어도 일부에 트랜잭션 컨텍스트 변이, 트랜잭션 파라미터 변이 및 EVM 바이트코드(bytecode) 변이 중 적어도 하나의 변이를 적용하는 단계를 포함하는,
컨센서스 버그 탐지 방법.
제 3 항에 있어서,
상기 적어도 하나의 변이를 적용하는 단계는,
적어도 하나의 명령어 추가, 삭제, 복제(clone) 및 복사(copy) 중 적어도 일부를 실행하는 단계를 포함하는,
컨센서스 버그 탐지 방법.
제 3 항에 있어서,
상기 EVM 바이트코드 변이는 계약 생성 트랜잭션의 생성자(constructor) 변이 및 반환코드(code-to-return) 변이 중 적어도 하나를 포함하는,
컨센서스 버그 탐지 방법.
제 1 항에 있어서,
코퍼스에 저장된 테스트 케이스 집합에서 상기 테스트 케이스를 선택하는 단계; 및
상기 일련의 변이 트랜잭션를 포함하는 또다른(another) 테스트 케이스를 상기 테스트 케이스 집합에 저장하는 단계를 더 포함하는,
컨센서스 버그 탐지 방법.
제 1 항에 있어서,
상기 일련의 전이 블록 상태를 획득하는 단계는,
상기 일련의 변이 트랜잭션에 의한 코드 경로(code path) 정보를 획득하는 단계를 포함하는,
컨센서스 버그 탐지 방법.
제 7 항에 있어서,
상기 컨센서스 정보는 상기 복수의 이더리움 클라이언트 간 충돌 정보를 포함하고,
상기 컨센서스 정보를 결정하는 단계는,
상기 코드 경로 정보에 기반하여 상기 충돌 정보를 추적하는 단계를 포함하는,
컨센서스 버그 탐지 방법.
제 1 항에 있어서,
상기 컨센서스 정보를 결정하는 단계는,
각 이더리움 클라이언트로부터 획득한 상기 일련의 전이 블록 상태를 각 순서대로 비교하는 단계; 및
상기 비교의 결과를 기반으로 상기 일련의 트랜잭션에 대한 상기 복수의 이더리움 클라이언트 간 컨센서스 결과를 결정하는 단계를 포함하는,
컨센서스 버그 탐지 방법.
제 1 항에 있어서,
상기 복수의 이더리움 클라이언트는 각각 이더리움 스펙(specification)에 따라 구현된 이더리움 가상 머신(Ethereum Virtual Machine; EVM)의 인스턴스(instance)인,
컨센서스 버그 탐지 방법.
컨센서스 버그 탐지 장치에 있어서,
적어도 하나의 명령어를 저장하는 메모리; 및 프로세서를 포함하고, 상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금,
일련의 트랜잭션을 포함한 테스트 케이스에 대하여, 프로세서에 의해, 적어도 하나의 변이 과정을 실행하여 상기 일련의 트랜잭션 중 적어도 일부가 변경된 일련의 변이 트랜잭션(mutated transaction)을 생성하고,
상기 프로세서에 의해, 상기 일련의 변이 트랜잭션을 복수의 이더리움 클라이언트에게 제공하고,
상기 복수의 이더리움 클라이언트의 각각으로부터 상기 일련의 변이 트랜잭션에 의한 각 이더리움 클라이언트의 초기 블록체인 상태로부터의 상태 전이(state transition)와 연계된 일련의 전이 블록체인 상태를 획득하고,
상기 일련의 전이 블록체인 상태를 기반으로 상기 복수의 이더리움 클라이언트 간 컨센서스 정보를 결정하도록 구성되는,
컨센서스 버그 탐지 장치.
제 11 항에 있어서,
상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금, 상기 일련의 변이 트랜잭션을 생성하기 위하여,
상기 일련의 트랜잭션 중 적어도 일부에 트랜잭션 컨텍스트 변이, 트랜잭션 파라미터 변이 및 EVM 바이트코드(bytecode) 변이 중 적어도 하나의 변이를 적용하도록 구성되는,
컨센서스 버그 탐지 장치.
제 12 항에 있어서,
상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금, 상기 적어도 하나의 변이를 적용하기 위하여,
적어도 하나의 명령어 추가, 삭제, 복제(clone) 및 복사(copy) 중 적어도 일부를 실행하도록 구성되는,
컨센서스 버그 탐지 장치.
제 12 항에 있어서,
상기 EVM 바이트코드 변이는 계약 생성 트랜잭션의 생성자(constructor) 변이 및 반환코드(code-to-return) 변이 중 적어도 하나를 포함하는,
컨센서스 버그 탐지 장치.
제 11 항에 있어서,
상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금,
코퍼스에 저장된 테스트 케이스 집합에서 상기 테스트 케이스를 선택하고,
상기 일련의 변이 트랜잭션를 포함하는 또다른 테스트 케이스를 상기 테스트 케이스 집합에 저장하도록 구성되는,
컨센서스 버그 탐지 장치.
제 11 항에 있어서,
상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금, 상기 일련의 전이 블록 상태를 획득하기 위하여,
상기 일련의 변이 트랜잭션에 의한 코드 경로(code path) 정보를 획득하도록 구성되는,
컨센서스 버그 탐지 장치.
제 16 항에 있어서,
상기 컨센서스 정보는 상기 복수의 이더리움 클라이언트 간 충돌 정보를 포함하고,
상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금, 상기 컨센서스 정보를 결정하기 위하여,
상기 코드 경로 정보에 기반하여 상기 충돌 정보를 추적하도록 구성되는,
컨센서스 버그 탐지 장치.
제 11 항에 있어서,
상기 적어도 하나의 명령어는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금, 상기 컨센서스 정보를 결정하기 위하여,
각 이더리움 클라이언트로부터 획득한 상기 일련의 전이 블록 상태를 각 순서대로 비교하고,
상기 비교의 결과를 기반으로 상기 일련의 트랜잭션에 대한 상기 복수의 이더리움 클라이언트 간 컨센서스 결과를 결정하도로 구성되는,
컨센서스 버그 탐지 장치.
제 11 항에 있어서,
상기 복수의 이더리움 클라이언트는 각각 이더리움 스펙(specification)에 따라 구현된 이더리움 가상 머신(Ethereum Virtual Machine; EVM)의 인스턴스(instance)인,
컨센서스 버그 탐지 장치.
제 1 항 내지 제 10 항 중 어느 한 항에 따른 컨센서스 버그 탐지 방법을 프로세서에 의해 실행하도록 구성된 적어도 하나의 명령어를 포함한 컴퓨터 프로그램을 저장한 컴퓨터 판독가능한 비 일시적 기록매체.