Ⅰ. 서론

블록체인은 거래 데이터들로 구성된 블록들을 체인 형태로 연결하고 분산 노드들에 저장하기 때문에 임의로 변경할 수 없으며, 참여 노드들 간의 거래를 효율적으로 검증하고 영구적으로 기록할 수 있는 개방형 분산 원장기술이다.^[1] 2008년 사토시 나카모토가 제안한 블록체인은 분산장부 기반의 디지털 화폐인 비트코인의 발행과 유통이 활성화되면서 기술 및 산업계의 많은 관심을 가져왔다.^[2]

이후 이더리움의 스마트 계약 기반의 디앱 확산과 Private 블록체인의 출현으로 블록체인은 실용성 측면에서 많은 문제점을 확인하고 이를 보완하는 연구들이 진행 중이다. 인터넷의 성장 기반인 TCP/IP처럼 새로운 사업 기반을 창조하는 역할로 블록체인은 성장할 것으로 예측되고 있다. 미국의 헬스케어 산업 사례를 보면, 국가의료정보표준(ONC-HIT: Office of the National Coordinator for Health Information Technology)은 다양한 기관과 단체로부터의 민감한 고객 의료 기록에 대해 안정적인 접근을 보장하고 정보 흐름의 투명성을 달성하는 대안으로 블록체인을 활용하고 있다.^[3][4][5][6]

블록체인은 요청된 트랜잭션이 시간 순서대로 같은 결과를 갖도록 분산 저장되어야 한다. 이를 위해서는 네트워크 참여 노드들 간에 트랜잭션들로 구성된 블록을 생성하고 블록의 유효성을 검증하고 신뢰할 수 있는 방식으로 공유하는 합의 알고리즘이 필요하다.

블록체인은 네트워크 참여 관점에서 보면 노드의 승인 여부에 따라 비허가형(Permissionless) 블록체인과 허가형(Permissioned) 블록체인으로 분류할 수 있으며, 운영 관점에서 보면 비허가형은 Public, 허가형은 Private 또는 Consortium으로 분류할 수 있다. 비허가형 블록체인의 대표적인 합의 알고리즘은 작업 증명(PoW: Proof of Work), 지분 증명(PoS: Proof of Stake), 위임 지분 증명(DPoS: Delegated Proof of Stake)이 있으며, 허가형 블록체인의 대표적인 합의 알고리즘은 PBFT(Practical Byzantine Fault Tolerance)가 있다.^[7]

합의 알고리즘의 정확성을 보장하기 위해서는 Safety와 Liveness 특성을 만족해야 한다. Safety는 모든 노드가 합의에 도달하면 노드들의 트랜잭션 결과 값은 같아야 하며, Liveness는 모든 노드는 합의에 최종적으로 도달해야 한다는 것을 의미한다.^[8]

FLP Impossibility 연구 결과 비동기 네트워크 환경에서 Safety와 Liveness 특성 모두를 만족하는 합의 알고리즘은 존재할 수 없음을 증명하였다.^[9] 그래서 블록체인은 부분 동기 네트워크(Partial Synchronous Netwok)^[10]를 가정한다. 비동기 네트워크 환경은 노드가 메시지를 보내는 시간과 수신 노드가 메시지를 수신하는 시간 사이에 상한선이 무한하다. 그래서 부분 동기 네트워크는 비동기 네트워크 환경에서 시간 초과 등과 같은 메커니즘을 통해 동기 네트워크 환경에서와 유사한 시스템 결과를 달성할 수 있음을 가정한다.

PoW는 Safety보다 Liveness를 보장하는 대표적인 합의 알고리즘이다. 블록체인이 두 갈래로 분기되는 현상인 포크(Fork) 발생으로 최종확정성(Finality)은 보장되지 않는다. 하지만 항상 합의는 이루어진다. 그리고PBFT는 Liveness 보다 Safety를 보장하는 대표적인 합의 알고리즘으로 비잔틴 결함 노드로 인해 합의가 항상 이루어지진 않더라도, 합의가 이루어지면 최종확정성을 보장한다.

PBFT는 허가형 블록체인 중에서 신뢰성이 수학적으로 보장된 대표적인 합의 알고리즘이지만 합의 과정에서 전체(all-to-all) 통신 방식 사용으로 많은 메시지 수가 발생한다.^[11] 그래서 PBFT는 소규모 네트워크에서 적합하며 확장 가능한 구조를 위한 추가적인 개선이 필요하다. 본 연구에서는 합의 알고리즘의 3중 딜레마 문제 중에서 확장성 문제를 분석하고 PBFT의 O(n²)인 메시지 복잡도를 O(n)으로 줄이고 확장 구조에 적합한 클러스터 구조 기반의 CBS-PBFT를 제안한다.

Ⅱ. 관련연구

1. 확장성

블록체인은 확장성-보안성-탈중앙화의 3중 딜레마 문제를 갖고 있다. 블록체인을 확장 가능하게 하려면 합의 방식을 수정하거나 시스템 특성을 조정하여 시스템이 기존 시스템보다 높은 성능을 달성할 수 있어야 한다. 그래서 확장성을 높이기 위해서는 참여 노드 수, 처리 트랜잭션 수, 합의 처리 속도가 매우 중요한 결정 요소가 된다.

비허가형 블록체인의 경우, PoW는 블록 시간 간격, 블록 크기 같은 내부 특성요인으로 인해 시스템 확장성에 영향을 미친다. 블록 크기를 높이면 네트워크 전달 속도가 느려지고, 블록 생성 시간을 줄이면 성능은 높아지지만 포크(Fork) 발생 빈도가 늘어나 보안성이 떨어진다. 그래서 블록 크기 확대, 블록 생성 간격 조절 그리고 데이터 분할 처리와 같은 블록체인의 특성을 향상시키는 방식인 샤딩(Sharding)과 세그윗(Segwit)이 있으며 기본 블록체인 외부에 별도의 오프체인을 이용해 네트워크 효율을 높이는 방식인 라이트닝 네트워크(Lightning Network)과 플라즈마(Plazma)가 있다.^[12]

허가형 블록체인의 경우, PBFT는 메시지 복잡도(Message Complexity) O(n²)로 인해 네트워크 증가에 따른 처리량이 감소한다. 그래서 Zilliqa, Hyperledger 프로젝트들은 노드 간에 통신 오버헤드를 줄이기 위해 프로세스를 간소화하는 방식들을 많이 활용하고 있다. 그 외에 블록체인의 기본데이터 구조와 프로세스 그리고 블록 개념 없이 상호 연결된 그래프를 사용하는 DAG(Directed Acyclic Graphs)가 있다.^[12]

PBFT 확장성에 관한 일부 연구에서는, 메시지 복잡도를 개선하기 위해 전체(all-to-all) 통신 방식에서 선형(Linear)통신 방식으로 변경하여 적용하였다. 특히 SBFT^[13]와 HSBFT^[14]는 컬렉터(Collector) 노드 개념을 도입하였고 HSBFT는 Prepare와 Commit 합의 단계에서 백업 노드와의 메시지 송수신을 통해 조정자 역할을 수행하여 통신 복잡도를 O(n²)에서 O(n)으로 줄였다. 그리고 전체 통신 방식을 사용한 SDMA-PBFT^[15]는 계층적 구조에 기존 PBFT를 구현하여 통신 복잡도 O(n²)를O(n * k * logkn)으로 개선하여 확장성을 높였다. 본 연구는 PBFT에 선형 통신 방식을 도입하여 통신 복잡도를 줄이고 노드들의 군집화(Clustering)를 통해 노드 증가로 발생하는 확장성 문제를 개선하였다.

2. PBFT

비잔틴 장군 문제(The Byzantine Generals Problem)^[16] 연구가 분산 동기 네트워크 환경에서 해킹 또는 오류 발생 가능성에도 불구하고 신뢰할 만한 합의 결과를 내는 규칙을 정의했다면 BFT(Byzantine Fault Tolerance)는 이 규칙을 적용한 알고리즘이다. PBFT^[11]는 BFT 알고리즘의 성능 문제와 비동기 네트워크 환경에서의 한계를 개선하여 악의적인 노드가 있어도 네트워크 합의를 도출할 수 있는 신뢰할 수 있는 알고리즘이다. PBFT는 Pre-Prepare, Prepare, Commit 3단계 프로토콜로 구성되며 비동기 네트워크에서 비잔틴 결함 노드가 f 개일 경우, 총 노드 개수가 3f + 1개 이상이면 신뢰할 수 있는 합의가 이루어질 수 있는 알고리즘이다.

그림 1은 이 알고리즘의 합의 프로세스를 보여주고 있다.^[11] 클라이언트가 프라이머리 노드에게 요청 메시지를 보내면 합의 프로세스를 진행한다.

그림 1. PBFT 합의 프로세스

Fig. 1. PBFT consensus process

1. [PrePrepare]: 프라이머리 노드는 백업 노드들에게 σp 메시지를 발송한다. v는 View 번호, n은 생성한 Sequence 번호,D(m)은 메시지 해쉬 값, σp는 프라이머리 노드 디지털 서명이다.

2. [Prepare]: 백업 노드들은 수신한 PrePrepare 메시지를 검증하고 σi 메시지 모든 노드들에게 전송한다. 동시에 다른 노드들로부터 2f 개의 메시지를 집한다. 이때 2f 개의 메시지를 수집한 경우를 prepared certificate라 한다. i는 검증한 노드 식별번호다.

3. [Commit]: 노드들은 prepared certificate를 가지게 되면 σi 메시지를 모든 노드들에게 전송한다. 동시에 다른 노드들로부터 자신의 메시지 포함하여 2f + 1개의 메시지를 수집한다. 이때 2f + 1개의 메시지를 수집한 경우를 committed certificate라 한다. 그리고 요청된 메시지를 실행한다.

최종적으로 클라이언트는 노드들로부터 f + 1개의 동일한 답변을 받으면 결과를 확인하고 완료한다.

Ⅲ. 제안하는 CBS-PBFT

3장은 CBS-PBFT 합의 알고리즘에 대한 내용이다. CBS-PBFT 블록체인 시스템은 4가지 형태의 노드로 구성된다.

∎ 클라이언트 노드(CL: Client Node) - 트랜잭션을 생성하고 클러스터 프라이머리 노드에게 전송한다.

∎ 클러스터 프라이머리 노드(CPN: Cluster Primary Node) - 클라이언트 노드로부터 수신한 메시지를 다른 로컬 프라이머리 노드에게 전송하고 동시에 자체 클러스터 내에서 합의 프로세스를 진행한다.

∎ 로컬 프라이머리 노드(LPN: Local Primary Node) - 클러스터 내 노드들 중에서 선택된 프라이머리 노드다. 로컬 클러스터 내에서 합의 프로세스를 진행한다.

∎ 백업 노드(BN: Backup Node) - 클러스터 내 로컬 프라이머리 노드를 제외한 모든 노드들이다.

1. 시스템 모델

CBS-PBFT 시스템 모델은 PBFT 시스템 모델을 기반으로 합의 과정에 선형 통신 방식을 도입하며 확장 구조에 적합한 클러스터 구조다. 그림 2는 CBS-PBFT 시스템 모델을 보여준다.

그림 2. CBS-PBFT 시스템 모델

Fig. 2. CBS-PBF System Model

다음은 CBS-PBFT 시스템 모델의 조건들이다.

∎ 클러스터 영역 크기는 클러스터 내 노드들의 수를 말한다. 클러스터 영역 크기가 K이고 클러스터의 수가 M일 경우 전체 노드의 수는 M＊ K 노드가 된다. 그리고 클러스터당 한 대의 프라이머리 노드가 필요하기 때문에 총 M개의 LPN이 존재하고 그 중의 한 대가 CPN이어야 한다.

∎ 클러스터 영역 크기 K는 3f + 1 이상이어야 한다. 이때 f는 비잔틴 결함 노드의 수를 의미한다.

∎ 클러스터 프라이머리 노드(CPN)는 로컬 프라이머리 노드(LPN)와 클러스터 프라이머리 노드(CPN) 2가지 역할을 수행한다. 그리고 View Change Protocol이 실행되면 클러스터 프라이머리 노드(CPN)는 교체된다.

2. 기본 합의 프로세스

CBS-PBFT는 PBFT와 비교했을 때 크게 2가지 차이점이 있다. 첫 번째는 전체 노드를 복수의 클러스터로 분할하고 클러스터 단위 별로 합의 과정을 진행한다. 두 번째로 LPN은 CPN으로부터 수신한 Request 메시지를 전달 받은 후, 클러스 내에서 합의 과정인 Prepare단계와 Commit단계에서 조정자 역할을 수행한다. 이 단계에서 메시지 복잡도를 O(n)으로 줄일 수 있다. 그림 3은 CBS-PBFT 합의 프로세스를 보여준다.

그림 3. CBS-PBFT 기본 합의 프로세스

Fig. 3. CBS-PBFT Normal Consensus Process

다음은 CBS-PBFT의 합의 과정을 설명한다.

1. [Request 단계]: [Request, o, t, c, n]σ_c 메시지를 CN은 CPN에게 전송한다. CPN은 새로운 Sequence 번호 n을 생성하고 Request 메시지를 LPN에게 전송한다. o는 트랜잭션 세부 내용, c는 클라이언트 식별자, t는 타임스탬프로서 클라이언트가 요청한 시점 그리고 n은 Sequence 번호 의미한다.

2. [PrePrepare 단계]: [PrePrepare, v, n, D(m)]σ_p 메시지를 PN과 LPN들은 로컬 영역의 BN들에게 전송한다. v는 현재의 View 번호, σ_p는 CPN과 LPN의 각 서명 그리고 D(m)은 메시지 해쉬 값을 나타낸다. BN은 v, n, D(m), σ_p를 검증한다.

3. [Prepare 단계]: [Prepare, v, n, D(m), i]σi 메시지를 BN들은 LPN에게 전송한다. σi는 BN(i)의 서명을 의미한다. LPN는 최종 검증된 Prepare 메시지가 2f 개 이상일 경우, BN들에게 [Prepare-set, S, v, n, D(m)]σ_p 메시지를 전송한다. 이때 S는 LPN이 수신하여 검증한 Prepare 메시지 집합이다. BN들은 S메시지 집합을 추출하여 검증하고, v, n, D(m), σ_p를 검증한다.

4. [commit 단계]: [Commit, v, n, D(m), i]σi 메시지를 BN들은 LPN에게 전송한다. LPN은 자신을 포함한 최종 검증된 Commit 메시지가 2f + 1개 이상일 경우, BN들에게 [Commit-set, S, v, n, D(m)]σ_p 메시지를 전송하고 CN의 요청 메시지를 실행한다. 이때 S는 LPN이 수신하여 검증한 Commit 메시지 집합이다. Commit-set메시지를 수신한 BN들은 메시지를 검증한 후 CN의 요청 메시지를 실행한다.

5. [Reply 단계]: [Reply, v, t, c, i, r]σi 메시지를 LPN들과 BN들은 CN에게 전송한다. 이때 r은 실행 결과 값, t는 타임스탬프로서 클라이언트가 요청한 시점을 의미한다. CN은 클러스터 별로 f + 1개 또는 전체 노드의 2/3를 초과한 동일 결과 값을 갖는 메시지를 확인하면 요청을 완료한다.

3. View Change Protocol

PBFT는 프라이머리 노드의 실패를 해결하기 위해 View Change Protocol을 사용한다. 각 노드는 합의 진행이 막힐 경우 시간초과(Timeout) 개념을 사용하여 프라이머리 노드의 실패를 탐지하고 View-Change 메시지를 전송하여 View 변경과 프라이머리 노드의 교체를 진행한다. 그래서 PBFT는 View Change Protocol을 통해 합의 프로세스를 계속 진행시켜 Liveness를 제공한다.^[15] CBS-PBFT에서도 동일한 개념을 적용한다. 그러나 신규 프라이머리 노드 선출방식과 선형 통신 방식으로 변경으로 인한 예외 동작에 대해서는 새로운 해결 방안을 적용하였다.

PBFT는 New Primary = v mod N으로 차기 View를 수행할 프라이머리 노드를 선택한다. v View 번호, N은 전체 노드의 수다.^[17]

CBS-PBFT의 프라이머리 노드 선출방식은 다음과 같다. 클러스터 영역 크기가 K이고 러스터의 수가 M일 경우 전체 노드 수는 N = M＊K이다. 모든 클러스터의 크기 값인 K가 동일하고 노드 번호가 순차적으로 배정되었다고 가정한다.

Cluster(0) = {Node0, Node1, Node2, Node3}

Cluster(1) = {Node4, Node5, Node6, Node7}

간단한 알고리즘은 다음과 같다.

begin

CPN = v mod N

for (i=0; i<M; i++)

LPN[i] = (CPN mod K) + Kⁱ

end for

end

각 노드는 클러스터 프라이머리 노드가 시간초과로 인해 실패로 판단할 때 View Change Protocol을 진행한다. 먼저 [View-Change, v+1, h, C, P, i ] vi 메시지를 전체 노드들에게 전송한다. v+1은 새로운 View 번호, h는 최근 안정적인 체크포인트 Sequence 번호, C는 체크포인트 번호인 h까지 저장된 Sequence 번호와 메시지 집합, P는 h번호보다 큰 Request에 대한 Prepared 메시지 집합과 해당 PrePrepare 메시지 집합이다.

차기 클러스터 프라이머리 노드는 전체 노드 중 2f 개의 View-Change 메시지를 받으면 <New-View, v+0, V, X)σ_p 메시지를 전체 노드들에게 전송한다. V는 View-Change 메시지 집합으로 New-View 메시지의 증명서, X는 체크포인트보다 큰 Sequence 번호의 PrePrepare 메시지 집합이다. New-View 메시지를 받은 모든 노드들은 새로운 View에 해당하는 클러스터 프라이머리 노드와 자신이 속한 클러스터의 로컬 프라이머리 노드를 설정하고 합의 프로세스를 진행한다.

다음은 선형 통신 방식 변경으로 인한 예외 동작에 대한 해결 방안이다.

1. Prepare 단계와 Commit 단계에서 프라이머리 노드가 2f + 1개의 메시지를 받지 못했다면 시간초과가 발생한다. 이 경우는 프라이머리 노드는 백업 노드들에게 [Prepare-Timeout] 메시지를 발행하고 백업 노드들은 View Change Protocol을 진행한다.

2. 백업 노드들이 [Prepare-set], [Commit-set] 메시지를 받지 못했다면 시간초과가 발생한다. 이 경우 백업 노드들은 Vie Change Protocol을 진행한다.

4. 메시지 복잡도 비교

표 1은 PBFT의 메시지 복잡도를 보여준다. 전체 시스템 노드의 수가 n이라고 가정하자. 합의 과정을 수행면 최종적으로 메시지 복잡도는 O(n²)이 된다. 급격하게 늘어나는 네트워크 트래픽 증가는 대규모의 블록체인 시스템의 적용에 적합하지 않다.

표 1. PBFT 메시지 복잡도

Table 1. PBFT Message Complexity

CBS-PBFT는 클러스터 영역 크기가 K이고 클러스터 수가 M이라고 가정할 때, 한 개의 클러스터에 발생하는 단계별 메시지 수는 다음과 같다. Request = 1, PrePrepare = K-1, Prepare = K-1, Prepare-set =K-1, Commit = K-1, Commit-set = K-1, Reply =K

\(\text { 매시지 총합 }=6 M K-4 M=6 N-4 M\)       (1)

만약 전체 노드 수 N = 12 로 가정하면 PBFT는 288개의 메시지 수를 발생하지만 CBS-PBFT의 경우는 K =4, M = 3을 가정할 경우 60개의 메시지 수를 발생한다. CBS-PBFT는 메시지 복잡도를 O(n)으로 줄임으로써 노드 증가로 인한 성능 저하에 효과적으로 대처할 수 있다는 장점이 있다. 단점으로는 선형 통신 방식으로 프라이머리 노드가 단일 실패점으로 작용해 보안성이 약화될 수 있지만 View Change Protocol에서 보완하여 Liveness를 해결할 수 있다.

5. Safety와 Liveness 검증

PBFT는 다음 2가지 속성을 통해 정확성을 보장한다.

∎ Safety: 모든 노드가 합의에 도달하면 노드들의 트랜잭션 결과 값은 같아야 한다. 즉 모든 정상적인 노드들은 클라이언트 요청을 동일한 순서로 실행한다는 것을 의미한다. PrePrepare와 Prepare 단계를 통해 2f + 1 노드가 합의함으로써 해당 Request의 Sequence 번호가 노드들에게 동일한 순서임을 보장할 수 있다. 그리고 Commit 단계수행 후에 클라이언트는 노드들로부터 f + 1개의 동일한 답변을 받음으로서 합의에 도달한 모든 노드들은 동일 값을 가졌음을 보장한다.^[17]

∎ Liveness: 모든 노드는 합의에 최종적으로 도달해야 한다. 즉 클라이언트는 요청에 대한 답변을 최종적으로 받아야 함을 의미한다. 때로는 N-1/3 개를 초과하는 결함 노드로 인해 합의 과정을 완료하지 을 수 있어 Liveness를 일부 희생할 수 있다. 하지만 View Change Protocol을 이용한 View 변경을 통해 노드들은 안정적으로 회복 과정을 수행하고 새로운 합의를 지속할 수 있게 된다.^[17]

CBS-PBFT는 PBFT의 Safety와 Liveness 2가지 특성을 가진다. 차이점은 클러스터 단위 별로 합의 과정을 가지는 점과 Prepare 와 Commit 합의 과정을 선형 통신 방식으로 변경한 부분이다. 이 차이와 상관없이 Prepare와 Commit 단계 과정에서 합의에 요구되는 2f+ 1 메시지 수신 조건은 같다. 그래서 CBS-PBFT는 PBFT의 Safety와 Liveness인 2가지 특성과 다르지 않아 정확성을 보장한다.

Ⅳ. 실험 및 평가

기존 PBFT 합의 알고리즘과 제안하는 CBS-PBFT의 비교 분석을 위해 프로토타입을 구현하여 시뮬레이션을 통해 실험하였다.

1. 프로토타입 구현

프로토타입 구현을 위해 동시성 제어 및 서버 시스템 구현에 적합한 Golang 언어를, 시스템 노드 간의 통신은 HTTP 프로토콜을 사용하여 노드 컴포넌트와 클라이언트 컴포넌트로 구성된 아키텍처를 설계했다.

그림 4는 CBS-PBFT 아키텍처의 할당 다이어그램(Deployment Diagram)을 보여준다.

그림 4. CBS-PBFT 시스템 아키텍처

Fig. 4. CBS-PBFT System Architecture

노드 컴포넌트는 합의 모듈, 통신 모듈, 저장 모듈로 구성하고 클라이언트 컴포넌트는 트랜잭션 생성 모듈, 통신 모듈, 저장 모듈로 구성하여 총 2400여 라인의 Golang 코드로 프로토타입을 구현했다.

통신 모듈은 HTTP 기반에 합의 단계를 위한 인터페이스로 REST API를 설계하고, 저장 모듈은 Committed 된 Request 메시지와 Reply된 결과 메시지를 저장하는 기능으로, 트랜잭션 생성 모듈은 다양한 실험을 위한 트랜잭션 생성 기능으로 설계하였다. 그리고 합의 모듈은 PBFT를 기본으로 설계하고 프로토타입 구현과 테스트 수행을 통해 동작을 확인하였다. 이후 CBS-PBFT의 설계를 진행하였다.

2. 시뮬레이션 환경

시뮬레이션 환경은 코어가 4개인 i7-6700 3.40GHz CPU와 RAM 8GB로 구성된 인텔 시스템 22대를 LAN으로 구성하였다. 그리고 합의 지연시간을 성능 평가지표로 사용하였다. 합의 지연시간은 클라이언트의 거래 요청으로부터 블록체인 시스템의 거래결과 응답까지의 간 간격을 의미한다. 본 실험에서는 PBFT와 CBS-PBFT의 성능을 비교를 위해 합의 지연시간을 측정하여 성능을 판단하였다.

\(T_{\text {delay }}=T_{\text {request }}-T_{\text {reply }}\)       (2)

T_delay는 합의 지연시간, T_request는 클라이언트의 Request 메시지 전송시점 그리고 T_reply는 클라이언트의 Reply 메시지 수신시점이다. 실험은 클라이언트 노드가 25개의 트랜잭션을 생성해서 프라이머리 노드에게 전송하여 합의과정을 완료하면, 클라이언트가 수신한 응답 결과를 파일에 저장하는 방식이다. 이때 한 개의 트랜잭션 크기를 125 Byte로 구성하였다. 저장된 응답 메시지에는 클라이언트의 메시지 전송시점과 메시지 수신시점 그리고 전송한 노드의 식별자가 저장되어 있어 합의 지연시간을 알 수 있다. 이 측정 값으로 노드들의 평균 합의 지연시간과 TPS(Transaction Per Second)를 계산할 수 있다. 이 실험 방식을 5회에서 10회까지 반복 측정하여 평균 값을 도출하였다.

3. 실험 결과

그림 5는 PBFT와 CBS-PBFT(n)의 노드 수 변화에 따른 합의 지연시간의 차이를 보여준다.

그림 5. PBFT와 CBS-PBFT(n) 비교

Fig. 5. PBFT vs. CBS-PBFT(n)

n이 전체 노드 수라고 가정하면 CBS-PBFT(n)은 클러스터 크기가 n이므로 하나의 클러스터 내에 모든 노드가 존재한다는 의미다. 그림 5의 실험 결과를 보면, 노드 수가 19대인 실험에서 CBS-PBFT(n)은 PBFT보다 30% 정도 낮은 합의 지연시간을 보여준다. 특히 노드 19대 실험에서의 CBS-PBFT(n) 합의 지연시간 결과 값 46.76ms는 노드 수가 16대 실험에서의 PBFT 결과 값 48.66ms보다 적어 의미 있는 실험 결과를 보여준다. 그리고 비잔틴 결함 노드 수 f를 2에서 6으로 1씩 증가시켰을 경우, 즉 노드 7에서 19대까지 노드 수를 3대씩 늘린 실험 결과를 보면 PBFT는 합의 지연시간 증가율이 구간 평균 24.83%를 보여주고 CBS-PBFT는 상대적으로 7.56%가 낮은 17.27%을 보여준다.

그림 6은 클러스터의 크기를 n, 4, 7로 변화를 주었을 경우, CBS-PBFT의 합의 지연시간의 차이를 보여준다.

그림 6. 클러스터 크기 변화에 따른 CBS-PBFT 비교

Fig. 6. Comparison of CBS-PBFT by Cluster size

그림 6의 실험 결과를 보면, 19대의 노드로 한 개 클러스터를 구성한 CBS-PBFT(n)의 합의 지연시간은 46.76ms다. 그런데 클러스터 크기 4대로 5개의 클러스터를 구성한 CBS-PBFT(4)은 26.71ms의 결과 값을 보여주고 클러스터 크기 7대로 3개의 클러스터를 구성한 CBS-PBFT(7)은 34.08ms 결과 값을 보여준다. 이 두 결과 값은 CBS-PBFT(n)보다 상대적으로 더 적은 합의 지연시간임을 알 수 있다.

노드 수가 7, 13, 19로 증가할 경우 CBS-PBFT(n)의 평균 합의 지연시간 증가율은 37.21%. 노드 수가 8, 14, 20으로 증가할 경우 CBS-PBFT(4)는 10.78%, 노드 수가 14, 21로 증가할 경우 CBS-PBFT(7)는 8.12%이다. 즉 복수 개의 클러스터들로 분할하는 방식이 전체 노드를 한 개의 클러스터로 구성한 방식보다는 좋은 성능을 보여준다. 클러스터 크기가 4대인 CBS-PBFT(4)와 7대인 CBS-PBFT(7)의 평균 합의 지연시간 증가율의 차이는 아주 적음을 알 수 있는데, 이것은 전체 노드 수가 동일한 환경에서 클러스터의 수 보다는 클러스터 크기가 합의 지연시간에 영향을 준다는 것을 알 수 있다

Ⅴ. 결론

본 연구에서는 허가형 블록체인의 대표적인 합의 알고리즘인 PBFT보다 확장 구조에 적합한 클러스터 구조 기반의 CBS-PBFT를 제안하고 시뮬레이션을 통해 실험결과를 검증했다. CBS-PBFT는 합의 과정 중에서 prepare와 commit단계에서 메시지 복잡도를 O(n)으로 줄이고 전체 노드를 한 개의 클러스터로 구성하여 실험하였다. 합의 지연시간을 측정 지표로 실험한 결과로 동일 환경에서 CBS-PBFT가 PBFT에 비해 합의 지연시간과 노드 확장에 따른 합의 지연시간 증가율 차이가 더 낮음을 확인할 수 있었다. 그리고 CBS-PBFT를 대상으로 클러스터 크기 변화를 통한 성능 변화를 실험하였고 클러스터의 크기가 노드확장으로 인한 합의 지연시간 증가율과 합의 성능에 영향을 준다는 결과를 확인할 수 있었다. 이 2가지 결과를 토대로 CBS-PBFT가 PBFT에 비해 확장성이 더 좋은 구조라고 할 수 있다.

추가 연구로는 더 큰 규모의 실험 환경에서 응답 시간 초과를 반영한 실험을 통해 클러스터 크기 변화에 대한 영향력을 분석하고 CBS-PBFT의 확장성을 높일 수 있는 방안과 프라이머리 노드 선정 방식에서의 보안성 강화 방안을 연구할 계획이다.