블록체인 환경에서 애플리케이션 서비스의 트래픽 부하를 얼마나 처리할 수 있을까? (Feat. Blockchain Benchmark)

Published in

Decipher Media ｜디사이퍼 미디어

17 min readAug 31, 2024

Disclaimer: 이 글은 컴퓨터 과학/공학(Computer Science/Engineering) 분야의 최우수 학회 중 하나인 Eurosys에서 2023년에 발간한 “DIABLO: A Benchmark Suite for Blockchains” 논문을 바탕으로 작성되었습니다. 본 아티클에는 작성자의 주관적인 의견도 포함되어 있으며, 오타나 내용에 대한 피드백은 언제든지 환영합니다. 이 아티클의 내용은 투자 조언이 아니며, 투자 조언으로 해석되어서도 안 됩니다.

Author

송만섭 of Decipher

Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)

Reviewed By 최재우, 신성헌

1. TL;DR

본 아티클에서는 2023년도에 컴퓨터 시스템 분야의 가장 권위 있는 학회 중 하나인 European conference on computer systems(Eurosys)에서 발표된 논문 “DIABLO: A Benchmark Suite for Blockchains”의 내용을 바탕으로 구성되어 있습니다.
최근 다양한 블록체인이 등장했지만, 애플리케이션 개발자가 자신의 서비스에 적합한 블록체인을 선택하는 것은 여전히 어렵습니다.
특히, 특정 블록체인의 확장성과 성능은 대개 해당 블록체인의 개발팀이 자체적으로 측정하고 검증한 것이기 때문에 객관성이 부족하고 신뢰하기 어렵습니다.
본 논문에서는 실험에 사용된 다양한 서버 머신의 하드웨어 사양, 실험 환경과 규모, 그리고 실험 설정이 여섯 가지 블록체인의 성능에 미치는 영향을 평가하는 것을 목표로 하고 이를 위해, DIABLO라는 벤치마크를 개발했습니다.
결과적으로, 테스트에 사용된 블록체인 중 어느 것도 아직 현실적인 애플리케이션 서비스의 트래픽 부하를 감당하기에 충분하지 않다는 결론을 도출했습니다.
구현은 오픈 소스로 공개되어 있습니다(https://diablobench.github.io/).

2. Introduction

2024년 8월 기준, 9,000개가 넘는 암호화폐가 존재할 정도로 블록체인 네트워크의 수가 급격히 증가하고 있습니다. 이러한 블록체인의 과잉은 충분한 기술 검증 없이도 쉽게 운영될 수 있다는 점에서 문제가 될 수 있습니다. 예를 들어, 기존 블록체인을 그대로 가져와 이름만 바꾸거나, 충분한 실험 없이 메인넷을 운영할 수 있습니다. 애플리케이션 개발자는 적절한 블록체인을 찾기 위해 1) 소스 코드를 분석하여 해당 블록체인의 프로토콜을 직접 검토하거나, 2) 워크로드를 생성하여 성능을 측정하는 방법을 사용할 수 있습니다. 전자는 많은 시간과 노력이 요구되는 반면, 후자는 성능을 수치로 표현할 수 있어 직관적이고 편리합니다. 일반적으로 블록체인 프로젝트는 후자의 방법을 사용해 자사의 블록체인 성능을 측정하고 이를 홍보합니다. 하지만 이러한 성능 측정은 독립된 기관이 아닌 블록체인 개발팀이 직접 수행하기 때문에 객관성이 떨어지며 신뢰하기 어려운 경우가 많습니다. 예를 들어, Avalanche는 최근 공식 웹사이트에서 2초의 지연 시간으로 초당 4,500개의 트랜잭션 처리량(TPS)을 달성했다고 주장했으나, 이 결과를 얻은 실험 조건은 명시되어 있지 않았습니다. 또한, 각 블록체인이 다른 실험 환경에서 성능을 측정했기 때문에, 블록체인 간의 성능을 비교하는 것도 매우 어렵습니다. 예를 들어, A 블록체인의 성능 실험은 4대의 노드를 한국에서만 운영한 반면, B 블록체인은 200대의 노드를 전 세계적으로 운영했다면, 두 블록체인의 성능을 공정하게 비교하기 어렵습니다.

이에 따라 본 아티클에서 소개하는 논문에서는 DIABLO라는 블록체인 벤치마크 프레임워크를 구축하고, 여섯 가지 블록체인(Algorand, Avalanche, Diem, Quorum, Ethereum, Solana)을 대상으로 거래소(e.g., NASDAQ), 웹 서비스(e.g., FIFA), 모빌리티 서비스(e.g., Uber), 비디오 스트리밍(e.g., YouTube)과 같은 실제 워크로드를 통해 다양한 실험을 수행하고, 그 결과로부터 인사이트를 제공합니다.

실험 결과를 확인하기에 앞서, Algorand, Avalanche, Solana에서 제시한 성능 수치와 DIABLO를 통해 얻은 실제 성능 수치를 비교하여 문제점을 다시 한 번 강조하고자 합니다.

3. Problem Statement

새로운 블록체인 프로토콜이 기존 프로토콜보다 더 높은 성능을 제공하는 경우가 많지만, 이러한 결과는 종종 재현하기 어려워 객관적인 비교가 어렵습니다. 그림 1은 최근 발표된 블록체인의 성능 수치와 실제 측정 결과 간의 차이를 보여줍니다.

그림 1: 블록체인 팀에서 주장하는 성능과 직접 실험을 통해 얻은 성능 차이 비교 (출처: DIABLO 논문)

Solana는 12개의 CPU 코어와 256GB 메모리를 권장하며, 각각 50개의 노드와 150개의 테스트넷에서 250,000TPS와 200,000TPS를 달성했다고 주장합니다. 또한 1초 미만의 트랜잭션 커밋(확정) 시간을 제시하지만, Solana는 여러 브랜치로 포크될 수 있어 잠재적인 불일치가 발생할 수 있기 때문에 비트코인이나 이더리움처럼 몇 개(e.g., 30개)의 블록이 추가로 연결되어야 확률적으로 커밋이 가능합니다. DIABLO는 36개의 CPU와 72GB 메모리가 장착된 머신에서 10대의 노드를 이용해 실험을 진행했으며, 최대 8,845TPS의 처리량(throughput)과 최소 12초의 대기 시간(latency)을 기록했습니다.

Avalanche는 (구체적이지 않은 실험 환경을 곁들인) 4,500TPS 이상의 처리량과 약 2초의 대기 시간을 주장하지만, Solana와 유사한 실험 환경에서 최대 323TPS와 평균 49초의 대기 시간을 기록했습니다.

Algorand는 구체적인 실험 환경을 언급하지 않았고, 블록 간 파이프라이닝을 통해 최대 46,000TPS까지 도달할 수 있다고 주장합니다. 그러나 4개의 CPU와 8GB 메모리를 갖춘 머신에서 10대의 노드를 이용해 실험한 결과, 최대 885TPS와 8.5초의 대기 시간이 걸렸습니다. (추후 개발팀과 소통한 결과, 1,000TPS 이상에 도달할 수 있다는 확인을 받았다고 합니다.)

DIABLO의 측정치와 발표된 성능 수치는 실험 방식에서 차이가 있을 수 있지만(e.g., 트랜잭션 일괄 처리, 트랜잭션 크기), 여기서 강조하고자 하는 것은 자체 팀에서 발표한 성능 결과를 맹신할 필요는 없다는 점입니다.

4. The Decentralized Applications Suite

DIABLO는 성능을 측정하기 위해 다섯 가지 DApp을 사용합니다. DApp을 구축할 때, Ethereum, Avalanche, Quorum, Solana는 Solidity v0.7.5를, Algorand는 PyTeal v5, Diem은 Move v3을 사용합니다. 이 DApp들은 실제 중앙화된 애플리케이션 서비스의 워크로드를 분석하여 각각 고유한 특징을 가지도록 설계되었습니다. 이제 각 어플리케이션의 특징을 하나씩 설명드리겠습니다.

그림 2: DIABLO에 사용된 DApp 소개 및 DApp 별 특징 소개 (x축: 경과 시간(초), y축: 트랜잭션 수, 출처: DIABLO 논문)

그림 2에서 보이는 것처럼, 첫 번째 DApp의 워크로드는 거래소(Exchange)입니다. NASDAQ은 장 초반 3분 동안 19,800TPS를 기록하고, 이후 25~140TPS로 변동하며 요청이 몰리는 워크로드를 보입니다. Exchange 워크로드는 NASDAQ의 워크로드 특징을 기반으로 만들어졌으며, 짧은 몇 초 동안 약 20,000건의 트랜잭션 요청이 발생하고 이후에는 거의 요청이 없는 워크로드로 구성되었습니다.

두 번째 DApp의 워크로드는 이동 수단 서비스(Mobility service)입니다. Uber 워크로드는 고객의 출발 위치와 도착 위치 간의 거리를 계산해야 하므로 연산 집약적인 워크로드로 간주됩니다. 뉴욕의 Uber 수요를 기준으로 평균 864TPS로 측정되었습니다. Mobility service 워크로드는 이러한 Uber의 워크로드 특징을 반영하여 설계되었습니다.

세 번째 DApp의 워크로드는 웹 서비스(Web service)입니다. FIFA 워크로드는 조별경기, 결승전, 라이벌 매치 등 경기 종류에 따라 FIFA 웹 페이지 방문자 수가 크게 달라집니다. Web service 워크로드는 평균 3,587TPS로 변환되었으며, 시간대에 따라 편차가 있도록 설계되었습니다.

네 번째 DApp의 워크로드는 게임(Gaming)입니다. Dota 2 워크로드는 플레이어가 이동할 때마다 위치를 기록해야 하므로 상당히 많은 요청을 요구합니다. Gaming 워크로드는 250x250 크기의 맵에서 10명의 플레이어 위치를 기록하는 트랜잭션을 전송하는 형태로, 트래픽 부하가 높고 이를 장시간 유지해야 합니다.

마지막 DApp의 워크로드는 비디오 스트리밍(Video sharing)입니다. YouTube 워크로드는 초당 38,761개의 비디오가 업로드된다고 가정하며, Video sharing 워크로드는 Gaming 워크로드보다 트래픽 부하가 더 크지만 상대적으로 짧게 유지되도록 설계되었습니다.

이 다섯 가지 DApp 워크로드는 성능 측정을 위해 사용됩니다.

5. Overall Architecture of DIABLO

그림 3은 DIABLO의 아키텍처를 보여줍니다. 워크로드를 분산 생성하기 위해 DIABLO는 Primary와 여러 Secondary라는 두 가지 주요 구성 요소로 이루어져 있습니다. 확장성을 위해 개발자가 새로운 블록체인을 기존 블록체인과 비교할 수 있도록 구현할 수 있는 네 가지 기능을 가진 블록체인 추상화를 제공합니다. 또한 개발자가 새로운 DApp을 추가하여 새로운 특징의 워크로드를 생성할 수 있도록 합니다.

Primary의 목적은 실험을 조정하는 것입니다. 어떤 종류의 워크로드를 생성할지, 노드의 수와 지리적 위치 등을 config 파일을 통해 설정할 수 있습니다. 설정 후 실험을 실행하고 완료되면, 각 Secondary는 TCP 인터페이스를 통해 Primary에 결과를 보내고, 집계자는 결과를 수집하여 JSON 파일로 출력해 각 트랜잭션의 시작 시간과 Secondary에서 기록된 종료 시간을 나타냅니다.

Secondary는 실험 실행을 담당하며, 블록체인 노드와 직접 통신합니다. Secondary 내의 워커(worker)들은 블록체인의 클라이언트 역할을 하여 트랜잭션을 생성하고 이를 블록체인 노드에 전송합니다. 그런 다음 블록에 트랜잭션이 포함되었는지 확인하고, Primary에게 그 시간을 전달합니다.

DIABLO 아키텍처에 대한 더욱 자세한 내용은 해당 논문을 참고하시기 바랍니다.

6. Evaluation

6.1. Experimental Setup

DIABLO는 실험을 위해 총 5가지 배포 환경을 제공합니다(그림 4의 왼쪽 그림 참조). 예를 들어, Datacenter 환경은 10개의 블록체인 노드로 구성되며, 각 노드는 36개의 CPU 코어와 72GB 메모리를 갖추고 있고, 모든 노드는 미국 오하이오(Ohio) 지역에 위치해 있습니다. Consortium 환경은 200개의 블록체인 노드로 구성되며, 각 노드는 8개의 CPU 코어와 16GB 메모리를 갖추고 있으며, 노드들은 전 세계 10곳의 지역에 분산되어 있습니다. 이 지역들은 그림 4의 오른쪽 그림과 같이 케이프타운(Cape Town), 도쿄(Tokyo), 뭄바이(Mumbai), 시드니(Sydney), 스톡홀름(Stockholm), 밀라노(Milan), 바레인(Bahrain), 상파울루(Sao Paulo), 오하이오(Ohio), 오리건(Oregon)으로, 모든 대륙에 걸쳐 있습니다.

그림 4: (왼쪽): 실험 규모 및 노드 사양, (오른쪽): 지역 간의 대역폭(bandwidth, 초록색)와 왕복 시간(round trip time, 빨간색) (출처: DIABLO 논문)

그림 5는 DIABLO에서 실험에 사용되는 블록체인과 각 블록체인의 특징을 소개합니다. 분류 기준에서 Prop.은 “property”의 줄임말로, Algorand나 Avalanche처럼 블록체인에서 유효한 블록이 생성되면 확률적으로 거의 fork가 발생하지 않아 바로 commit이 가능한 특징을 probabilistic이라고 하며(e.g., DAG 계열 합의 알고리즘), Diem이나 Quorum처럼 한 번 생성된 블록은 절대로 fork가 발생하지 않아 바로 commit이 가능한 특징을 deterministic이라고 합니다(e.g., PBFT 계열 합의 알고리즘). 마지막으로 Ethereum이나 Solana처럼 블록이 생성되어 블록체인에 연결되더라도 fork가 발생할 수 있으며, 해당 블록이 유효해지기 위해 몇 개의 블록이 더 연결되어 롤백될 가능성이 낮아질 때 확률적으로 commit이 되는 특징을 eventual이라고 부릅니다.

이 외의 특징들은 그림 5에서 보듯이 각 블록체인의 Consensus, Virtual Machine, DApp 프로그래밍 언어를 기준으로 분류된 것을 참고할 수 있습니다.

그림 5: DIABLO에서 평가된 블록체인 특징 (출처: DIABLO 논문)

6.2. Experimental Results

그림 6의 실험 결과는 consortium 환경을 기준으로 보여줍니다. 각 DApp(열)에 대해 DIABLO가 효과적으로 제출한 평균 트래픽 부하(각 열의 맨 위), 평균 처리량(첫 번째 행), 평균 대기 시간(두 번째 행) 및 각 블록체인에 대한 커밋된 트랜잭션 비율(세 번째 행)을 나타냅니다.

평균 트래픽 부하가 가장 낮은 168 TPS의 Nasdaq 워크로드인 Exchange DApp의 경우 Avalanche와 Quorum이 트랜잭션의 86% 이상을 커밋하는 반면 다른 모든 블록체인은 트랜잭션의 47% 이하를 커밋합니다. 가장 까다로운 트래픽 부하인 YouTube 트래픽 부하의 경우 커밋 비율은 모든 평가된 블록체인에서 1% 미만입니다. 또한 평균 트래픽 부하가 852TPS(Uber 트래픽 부하와 동일) 또는 3,483TPS(Fifa 트래픽 부하와 동일)인 경우 Quorum만이 622TPS보다 높은 처리량을 유지하는 반면 다른 블록체인의 처리량은 170TPS보다 낮습니다.더 높은 트래픽 부하(Dota 2와 동일)의 경우 어떤 블록체인도 66TPS보다 높은 처리량을 유지하지 않습니다.

이러한 실험 결과는 그림 1에서 설명한 블록체인 팀에서 주장된 성능과 대조됩니다. 물론 성능이 저하되기 쉬운 consortium 환경임에도 불구하고, 이처럼 차이가 나는 이유는 무엇일까요? 다른 실험 결과를 통해 좀 더 자세히 알아보겠습니다.

Scalability

그림 7은 실험 환경이 상대적으로 가장 좋은 datacenter부터 가장 나쁜 community까지의 실험 결과를 보여줍니다(참고로, consortium은 그림 6에서 실험을 했기 때문에 제외). 모든 워크로드 부하는 일정하게 1,000TPS로 트랜잭션을 전송 요청을 진행했습니다.

모든 환경에서 Solana만이 800TPS 이상의 처리량과 21초 미만의 대기 시간을 유지합니다. 이는 Solana의 합의 과정에서 노드 간 커뮤니케이션 오버헤드 비중이 크지않아 비교적 우수한 성능을 보이는 결과로 해석됩니다.

Diem의 경우, datacenter와 testnet 환경에서는 가장 높은 성능을 보여주지만, devnet과 community 환경에서는 성능이 급격히 떨어집니다. 이를 통해 Diem은 노드가 대륙별로 분산된 환경보다는 한 곳에 밀집되어 있는 환경에 더 적합하다는 것을 유추할 수 있습니다.

Avalanche의 경우, Avalanche 팀에서 권장하는 사양의 CPU 코어 수와 메모리를 갖춘 community 환경임에도 불구하고 상대적으로 낮은 처리량을 보였습니다.

그림 7: 실험 환경별 일정한 요청(1,000 TPS)으로 부하 스트레스를 가했을 때 각 블록체인의 평균 처리량(throughput)과 대기 시간(latency)

Robustness

Robustness란 감당하기 어려운 수준의 높은 트래픽 부하에도 불구하고 블록체인이 멈추지 않고 요청을 계속 처리할 수 있음을 의미합니다. 그림 8은 각 블록체인이 가장 적합한 환경 구성에서 높은 트래픽 부하로 스트레스를 받을 때의 성능을 보여줍니다.

이 실험 결과에서 흥미로운 점은 Diem과 Quorum에서 높은 트래픽 부하 시 처리량이 급격히 나빠진다는 점입니다. 이는 두 블록체인이 DoS 공격에 취약할 수 있다는 것을 의미합니다. 두 블록체인이 모두 PBFT 합의 알고리즘을 기반으로 하고 있어, 아마도 PBFT의 동작 과정에서 이러한 문제가 발생하는 것으로 생각됩니다.

또 다른 흥미로운 점은 Avalanche가 더 높은 트래픽 부하에서 오히려 더 높은 처리량을 보여준다는 것입니다. 물론 대기 시간도 함께 늘어나긴 했지만, 처리량 기준으로 볼 때 Avalanche가 가장 robust한 블록체인이라고 평가할 수 있을 것 같습니다.

그림 8: 1,000 TPS(파란색 막대) 또는 10,000 TPS(빨간색 막대)의 일정한 작업 부하로 스트레스를 받았을 때 각 블록체인의 처리량과 지연 시간

7. Summary

본 아티클에서는 여섯 가지 블록체인을 다양한 실험 조건에서 평가한 논문 “DIABLO: A Benchmark Suite for Blockchains”을 소개했습니다. 이 논문에 따르면, 테스트된 블록체인 중 어느 것도 우리가 제안한 현실적인 DApp(게임, 웹 서비스, 거래소, 모빌리티 서비스, 비디오 공유)의 모든 요청을 처리할 수 없었습니다. 그러나 심층 분석을 통해 성능에 긍정적인 영향을 미치는 흥미로운 설계 결정을 확인할 수 있었습니다.

물론 DIABLO도 하나의 연구일 뿐이며, 이 논문에서 제시된 주장과 결과가 절대적인 정답이라고 할 수는 없습니다. 그럼에도 불구하고 DIABLO는 블록체인 설계의 개선이 어떤 영향을 미치는지 테스트할 수 있는 유용한 도구이며, 블록체인을 보다 투명하게 평가하는 데 좋은 참고자료가 될 것이라 생각하며 글을 마치겠습니다.