블록체인의 확장성 문제와 솔루션 소개 - 1
Scalability 팀
Scalability 팀은 블록체인의 확장성 문제를 다루는 팀입니다. 일반인들이 블록체인의 확장성 문제와 솔루션들에 관하여 쉽게 이해할 수 있도록 함이 목적입니다. 첫 번째 게시글은 블록체인의 확장성 문제에 대한 포괄적인 개요(overview)를 제시하는 글로써, 확장성 문제와 솔루션에 대한 대략적인 설명을 다룹니다. 이후 글들에서 각 솔루션들에 대한 자세한 설명을 다룰 것입니다.
‘확장성(Scalability)’은 블록체인 응용프로그램의 실현에 큰 문제가 되고 있다. 이러한 확장성 문제가 영원히 풀리지 않을거라 할 수는 없지만, 적어도 오늘날에는 한계로 다가온다. 사실상 오늘날 블록체인 기술이 직면한 가장 큰 문제라 보아도 과언이 아닐 것이다.
대부분의 블록체인 합의 프로토콜(Bitcoin, Ethereum, Ripple, Tendermint)에는 확장성의 한계가 존재한다. 이는 블록체인의 특징으로 부터 발생한다. 먼저 블록체인 시스템의 경우, 네트워크에 참여하는 노드들은 모든 ‘트랜잭션(Transaction)’을 처리하여야 한다. 또한 하나의 노드가 전체 상태에 대한 복사본을 유지해야한다. 이러한 분산 합의 메커니즘은 강력한 보안과 중립성 및 신뢰성을 제공하지만 확장성을 보장하지는 못한다.
기존 데이터베이스 시스템에서는 더 많은 서버를 추가함으로써 처리할 수 있는 트랜잭션을 증가시키면서 확장성 문제를 해결할 수 있다. 그러나 블록체인 시스템이 처리할 수 있는 트랜잭션의 개수는 하나의 노드가 처리할 수 있는 트랜잭션의 개수로 제한된다. 따라서 블록체인 네트워크에 참여하는 노드의 수가 증가할 수록 시스템 성능은 감소 될 수 있다.
결과적으로, 분산화 된 환경에서의 퍼블릭 블록체인(Public Blockchain) 합의 프로토콜은 낮은 트랜잭션 처리량과 높은 수준의 중앙화 사이에서 절충점을 찾아야 한다. 즉, 블록체인의 크기가 커질수록 네트워크 참여에 요구되는 스토리지, 대역폭, 연산성능 등이 증가하게 되며, 따라서 어느 시점에서 부터는 일부 노드들만이 트랜잭션을 처리할 수 있게 된다.
실제 확장성에 대한 문제가 어떻게 나타나는지 확인해보자.
“Ethereum Average GasLimit Chart; June 6, 2018”, Etherscan‘이더리움(Ethereum)’ 노드의 최대 트랜잭션 처리량은 이론적으로 초당 1,000건이 넘는다. 그러나 이더리움의 ‘가스(Gas)’ 제한으로부터 실제로는 이보다 낮은 처리량을 보인다. 이더리움 에서의 가스는 계산력의 척도로, 각 연산(Operation)들은 가스 소모량이 정해져 있다. 또한 각 트랜잭션에는 발신자(Sender)가 지불하고자 하는 가스의 최대량을 지정하는 ‘Gas Limit Field’가 존재한다. 반면 각 블록(Block)에 해당하는 ‘Block Gas Limit’도 있으며, 이로부터 해당 블록에 포함될 수 있는 트랜잭션의 개수가 결정된다. 현재의 ‘Block Gas Limit’은 (원문 작성 시점을 기준으로) 평균 670만, 표준 트랜잭션당 가스 사용량은 21K이므로 블록당 대략 300건의 트랜잭션을 포함할 수 있다. 평균 블록 타임이 20초이므로 초당 트랜잭션 처리량은 최대 15tps 정도이다. 물론 더 복잡한 거래를 내포한다면 ‘TPS(Transaction Per Second)’는 더욱 낮아질 것이다.
이더리움 네트워크상에서 트랜잭션의 수가 상당히 빠르게 증가하고 있다. 일일 트랜잭션의 양은 16년 2분기에서 17년 2분기까지 40K에서 240K로 크게 증가하였으며, 전년 대비 500%의 증가폭을 보였다. 또한 지난 한 달 동안에 하루 440,000건 이상의 거래가 발생하였으며, 초당 평균 5회의 트랜잭션이 발생하였음을 추산할 수 있다.
비트코인 역시 마찬가지로, 이론적으로 초당 4,000건의 트랜잭션을 처리할 수 있음에도 불구하고, 현재 초당 7건의 트랜잭션만을 처리할 수 있으며, 복잡한 트랜잭션의 경우 초당 3건의 트랜잭션만을 처리할 수 있다.
본 글은 블록체인 확장성 문제에 제시된 솔루션의 개요를 제시하고, 추후에 작성될 글에 더욱 흥미를 가질 수 있도록 하고자 한다. 불행하게도 지금까지 제시된 솔루션들은 어느 하나 뛰어나다고 칭하기에는 부족한 면모가 있다. 그럼에도 불구하고 이러한 해결방안들은 확장성을 점진적으로 향상시킴에 도움이 되며, 종합적으로 적용함으로써 기대하는 효과 일부를 누릴 수 있을 것으로 기대된다. 또한 본 글은 독자가 블록체인에 대한 기본적인 지식을 가지고 있다는 가정 하에 작성되었다.
블록체인의 확장성은 잘 알려진 도전과제이며, 수년간 연구되어온 분야이다. 일반적인 솔루션으로는 ‘세그윗(Segwit)’과 2MB 블록 크기 증가 방법이 있다. 이는 비트코인 블록체인 플랫폼에서의 블록당 1MB 제한을 해결하는 것을 목표로 한다.
제안된 솔루션 #1: Segwit (Bitcoin-only)
모든 비트코인 트랜잭션은 입력과 출력으로 구성된다. 입력에는 발신자의 이전 거래 세부 정보와 고유한 ‘개인키(ScriptSig)’가 포함된다. 이전 거래를 기준으로 하여 발신자가 거래를 위한 적절한 금액을 가졌는지를 검증한다. 한편 출력에는 보낼 금액과 수신자의 ‘공개키(ScriptPubKey)’가 포함된다. 이 요소들 중 디지털서명-개인키의 크기가 가장 크며, 대략 트랜잭션의 60-70%에 해당하는 용량을 차지하고 있다. 그러나 서명은 유효성 검사 시에만 사용된다는 점을 상기하면 이는 큰 낭비처럼 여겨질 수 있을 것이다.
Current
Segregated Witness세그윗은 나머지 거래 데이터로부터 서명-증인을 분리하는 솔루션이다. 서명은 입력에서 제거되어 트랜잭션의 끝으로 이동하게 된다. 이 새롭게 형성된 ‘증인 필드(Witness Field)’ 덕분에 세그윗을 적용한 블록은 보다 많은 데이터를 포함할 수 있다. 대략 70%의 트랜잭션 증가를 도출한다고 한다.
세그윗은 소프트포크에 해당한다. 소프트웨어의 업그레이드를 하지 않더라도 모든 노드에서 사용할 수 있으며, 구버전의 노드는 1MB 이상의 블록을 읽지는 못하지만 거래에서 주된 입/출력 내역은 1MB에 모두 포함되므로 작은 용량이 문제되지는 않는다. 다만, 서명 부분이 빠져 있기 때문에 검증을 할 수는 없겠지만, 세그윗이 적용된 노드들이 이를 증명할 수 있기 때문에 네트워크 전체적인 관점에서 보면 이 역시 문제는 되지 않는다고 볼 수 있다.
또한, 세그윗은 거래 ‘가단성(Malleability)’ 문제를 해결할 수 있으나 확장성과는 큰 상관이 없기에 자세히 언급하지는 않겠다.
제안된 솔루션 #2: 2MB 블록 크기 (Bitcoin-only)
비트코인 커뮤니티의 한 측은 세그윗을 강력하게 지지하지만, 다른 측에서는 1MB 블록 크기 제한을 2MB로 변경하는 하드포크를 선호하였다. 이러한 블록 크기 제한 변경은 하드포크 없이는 불가능하다. 블록 크기를 2MB로 변경하자는 기본 아이디어는 간단한데, 블록 크기를 늘리면 각 블록에 더 많은 트랜잭션을 포함할 수 있기 때문에 네트워크가 초당 더 많은 트랜잭션을 처리할 수 있게 된다.
이 제안은 비트코인 커뮤니티의 열띤 논쟁거리가 되었으며, 블록 크기가 현재의 한계인 1MB에 도달하기 시작한 15년 이래로 점점 더 많은 관심을 받아왔다.
제안된 솔루션 #3: Off-chain State Channel
‘상태 채널(State Channel)’은 블록체인 상에서 발생하는 상호작용을 고려하는, 간단하지만 매우 광범위하게 적용될 수 있는 방법이다. 이는 암호화되어 안전한 방법으로 실시되기 때문에 참여자의 위험을 증가시키지 않으면서도 비용과 속도 측면에서 상당한 향상을 제공할 수 있다. 원문 저자의 개인적인 생각으로는 이 상태 채널이 블록체인 확장성에 주요한 부분이 될 것으로 기대한다고 한다.
상태 채널은 다음의 세 단계로 작동한다.
1. 블록체인 “State”, 가령 코인의 일부가 ‘다중서명(Multi-signature)’ 또는 일종의 ‘스마트 컨트랙트(Smart Contract)’로 잠겨있다. 이를 업데이트, 즉 돈을 송금하는 등의 “State” 변화를 유발하는 유일한 방법은 특정 참여자 집합이 완전히 동의하는 경우(혹은 미리 정의된 계약을 충족할 경우)이다.
2. 참여자들은 블록체인에 제출되는 트랜잭션을 작성하고 서명함으로써 상태를 업데이트한다. 각각의 새로운 업데이트는 이전 업데이트를 덮어씌운다.
3. 마지막으로 참여자들은 “State”를 블록체인에 등록하며, 해당 상태 채널을 닫고 “State”를 잠금 해제함으로써 상태 채널의 작동이 완료된다.
1단계와 3단계는 네트워크에 게시되고, 비용을 지불하고 확인을 기다리는 블록체인 작업과 관련되어 있다. 그러나 2단계는 블록체인을 전혀 포함하지 않는다. 이는 무제한으로 업데이트를 포함할 수 있으며 무기한으로 열어 둘 수 있다. 이러한 측면에서 블록체인은 오직 최종 합의를 위한 계층으로 사용되며, 최종 합의를 위한 일련의 연속된 상호 작용은 체인 밖에서 일어나게 된다. 이로써 블록체인의 부담을 덜어줄 수 있다.
상태 채널을 사용하면 트랜잭션 용량을 개선할 수 있을 뿐만 아니라, 속도 향상과 비용 절감이라는 두 가지의 매우 중요한 이점을 제공받을 수 있다. 트랜잭션의 대부분이 ‘오프체인(Off-chain)’을 통해 발생하여, 두 당사자 간의 업데이트는 네트워크 처리와 확인에 추가 자원을 필요로 하지 않기 때문에, 즉각적으로 처리될 수 있다. 또한 대다수의 트랜잭션은 오프체인으로 수수료 없이 진행되고, 오직 작은 수의 ‘온 체인(On-chain)’ 트랜잭션만이 필요하므로 수수료의 부담도 덜 수 있다.
상태 채널을 구현하기 위한 몇 가지 방안이 있다. 대표적으로 ‘라이트닝(Lightning) 네트워크’는 스마트 컨트랙트를 통해 상태 채널을 사용하여 참가자간 즉각적이고 확장가능한 지불을 가능하게 하는 분산 네트워크이다. ‘라이덴(Raiden) 네트워크’는 이더리움계의 라이트닝 네트워크로 볼 수 있다. 라이덴 네트워크는 오프체인 “State” 네트워크로 이더리움을 확장 가능하고 즉각적인 트랜잭션으로 확장한다.
다음 2부에서는 샤딩(Sharding), 플라즈마(Plasma), 트루빗(Truebit)에 대해 알아보도록 하자.
Edit by
맹주현
한양대학교 모바일및네트워크지능연구실 박사과정
maengjuhyun@gmail.com
관심분야: 블록체인, IoT, 인공지능
김상혁
서강대학교 분산처리연구실 석사과정
ksangh228@gmail.com
관심분야: 블록체인, 분산처리시스템, 클라우드컴퓨팅
박상현
서강대학교 컴퓨터공학과 학사과정
twodude@naver.com
관심분야: 블록체인, 이종컴퓨팅, 인공지능
참고 문헌
[1] “Blockchains don’t scale. Not today, at least. But there’s hope”, Medium
[2] “블록체인 확장성 솔루션 시리즈 2-1 :: Plasma Overview”, Medium
[3] “라이트닝 네트워크 이해하기 (1부)”, Medium
[4] “Bitcoin and Blockchain (3)”, Medium
[5] “[케블리] #18. 트루빗(Truebit), 이더리움 확장성(Scalability) 한계의 대안이 될 수 있을까”, Steemit Beta
[6] "몇시간전 비트코인 SegWit의 활성화-가격 상승 요인", Steemit Beta
[7] “비트코인 SegWit2x 그리고 마이너들의 중앙집중화”, Steemit Beta
[8] “세그윗(SegWit)에 대한 간단한 설명”, Steemit Beta
[9] “비트코인과 스케일링 논쟁”, © 2018 Lee Jungmin
[10] “비트코인 스케일링 논쟁 – 빅블록의 문제점”, CoinKorea
[11] “세그윗(Segwit)이란 무엇인가?”, CRYPTOKIWI
[12] “비트코인 SegWit 란 무엇인가?”, THE WANDERER-PAIN 블로그
[13] “상태채널(State Channel)”, Aeternity Community of KOREA
[14] “이더리움의 호재, Raiden Network란?”, 코인 트레이너-비트코인, 이더리움
[15] “Plasma: Scalable Autonomous Smart Contracts”, https://plasma.io/
[16] “ethereum/wiki/wiki/FAQs”, Github
[17] “Making Sense of Ethereum’s Layer 2 Scaling Solutions: State Channels, Plasma, and Truebit”, Medium
[링크 1] https://en.wikipedia.org/wiki/Shard_(database_architecture)
[링크 2] https://en.wikipedia.org/wiki/Tree_(data_structure)
