커뮤니티

5월 초 비트코인 커뮤니티를 뜨겁게 달궜던 Ordinals 사건은 근래 들어서는 잠잠해지고 있습니다. 하지만, 이 문제를 해결하기 위해 해외 비트코인 커뮤니티에서는 다양한 의견이 제안되고 있는데, 그 중 한 커뮤니티 사용자는 Taproot 업그레이드가 문제의 원인이라고 지적하며 Taproot 업그레이드 이전으로 되돌려야 한다고 주장했습니다.

이러한 주장은 이해가 가지만, 사실 비트코인 Taproot 업그레이드 이전에도 Ordinals 와 같은 사건들이 있었고, 혹여나 롤백한다 하더라도 비트코인 네트워크에 즉시 반영될 수 있는 것은 아닙니다. 앞으로 두 편에 걸쳐 비트코인 역사상 가장 큰 업그레이드였던 SegWit 업그레이드와 Taproot 업그레이드를 알아보면서 비트코인의 업그레이드가 왜 필요했는지 알아보고, 이러한 업그레이드가 왜 바로 반영되기 어려운지에 대해서 알아보도록 하겠습니다. :)

비트코인 SegWit 업그레이드

SegWit 업그레이드가 등장한 배경에는 비트코인 커뮤니티를 크게 뒤흔들었던 ‘블록 사이즈 전쟁 (BlockSize War)’이 있습니다. 비트코인에 관심있는 사람들이라면 한번은 들어봤을 법한 블록 사이즈 전쟁은 비트코인 네트워크의 높아지는 트랜잭션 수수료 문제를 해결할 수 있는 방법으로 “블록 크기를 키우자” 라는 주장과 “블록 크기를 키울 수 없다는 주장”이 충돌한 사건입니다.

블록 크기를 키우자는 측의 주장은 블록의 크기를 키워서 더 많은 트랜잭션을 하나의 블록에 수용함으로써 높은 트랜잭션 수수료를 낮추자는 주장이었고, 블록의 크기를 유지해야 된다는 측의 주장은 블록의 크기가 커지면 풀노드를 운영하는데 더 많은 저장 용량이 필요하는 등 고사양의 하드웨어가 필요하기 때문에 중앙화의 문제가 발생할 수 있다고 주장했습니다.

치열했던 비트코인 블록 크기에 대한 논쟁은 결과적으로 비트코인을 하드포크하기까지 이르러 양 진영이 비트코인 캐시 (BCH) 와 기존의 비트코인 (BTC) 으로 나뉘게 되었습니다. 비트코인 캐시는 블록 크기를 기존 1MB 에서 32MB 까지 확장시켰고, 기존 비트코인 커뮤니티는 비트코인 코어 로직 업그레이드를 통해서 확장성 문제를 해결하려고 했습니다. 그 업그레이드가 바로 SegWit 업그레이드 입니다. SegWit 업그레이드는 비트코인의 보안성을 높이고 확장성을 개선한 업그레이드인데, 블록 사이즈 전쟁 때문에 확장성 업그레이드로 좀 더 잘 알려져 있습니다.

SegWit 의 동작 원리

SegWit는 ‘Segregated Witness’ 라는 이름에서 알 수 있듯이, 서명 데이터를 witness 영역에서 분리하여 별도로 저장하는 방법을 의미합니다. SegWit의 핵심은 트랜잭션 영역과 서명 영역을 분리하는 것입니다. 이 업그레이드가 어떻게 하나의 블록 안에 더 많은 트랜잭션을 추가할 수 있도록 했을까요? 그 이유는 블록에 저장되는 트랜잭션의 구조에 있습니다. 기존 구조에서는 트랜잭션 데이터와 서명 데이터가 하나의 트랜잭션 구조에 포함되어 있었는데, 새로운 구조에서는 서명 영역을 분리시킴으로써 1MB 로 제한되어 있는 블록 크기에 더 많은 트랜잭션을 넣을 수 있게 된 것입니다. 하나의 블록에서 60~70%를 차지했던 서명 데이터를 분리함으로써 블록 크기는 바꾸지 않고 더 많은 트랜잭션 데이터를 넣을 수 있었습니다.

<그림 1. 코스트코에서 고기 사는 것으로 SegWit 업그레이드를 이해해보자>

SegWit 업그레이드에 대해 좀 더 쉽게 이해하기 위해서 코스트코에서 10kg 만큼의 고기를 산다고 가정해봅시다. 쇼핑을 하면서 덩어리 고기 10kg를 담았는데 집에 가져와서 지방을 발라내니 실제로 살코기는 5kg 정도 뿐입니다. 그 이유는, 코스트코 덩어리 고기는 손질이 되지 않은 상태로 살코기 + 지방으로 이뤄져있어 손질하고 나면 실제 고기는 5kg 뿐이었던 것입니다. 그래서 나머지 5kg 를 추가로 사기 위해서 다시 마트를 방문해서 덩어리 고기 10kg를 사왔습니다.

SegWit 업그레이드는 이런 번거로움과 비효율성을 개선하기 위해 카트에 고기를 담기 전에 미리 살코기와 지방을 분리합니다. 그래서 지방은 다른 카트에 담고, 10kg 용량의 카트에는 살코기만 담아서 마트를 한 번만 가도 10kg 살코기를 가져올 수 있습니다. 이 방법을 통해서 10kg 카트에 필요한 살코기만 담아 카트 공간을 효율적으로 사용할 수 있고, 마트 가는 횟수를 줄여 결과적으로 빠르게 요리를 시작할 수 있게 되었습니다. Segwit 업그레이드는 이러한 방법으로 거래 내역이 저장되어 있는 트랜잭션 데이터 (살코기) 와 거래 내역에 대한 서명 데이터 (지방) 를 분리함으로써 1MB 크기로 한정된 블록 (10kg 용량의 카트) 에 더 많은 트랜잭션 데이터를 담아 블록 용량을 효율적으로 사용할 수 있게 합니다.

서명 데이터는 어디에?

하지만 여기서 의문이 하나 생깁니다. 미리 분리시킨 서명 데이터는 어디에 저장이 될까요? 코스트코 예시에서 다른 카트에 지방을 분리시켰는데, 비트코인에서 다른 카트는 무엇이며 어디에 저장되는 것일까요? 사실, 분리된 서명은 여전히 블록에 저장됩니다. 즉, 트랜잭션 데이터가 포함되어 있는 블록과 같은 블록에 서명 데이터는 포함되어 있습니다. 다만, 서명 데이터의 위치가 블록의 중간에 위치해있는지 블록의 마지막에 위치했는지의 차이만 있을 뿐입니다. 이 답을 들으면 무슨 소리인지 혼란스러울 수 있습니다. 아니, 분명히 블록 크기를 증가시키지 않았다고 했는데 어떻게 서명 데이터를 추가로 저장할 수 있지? 라는 의문이 드실 수 있습니다. 10kg (카트 용량) - 10kg (살코기) = 0kg, 남아있는 용량은 0kg 인데 어떻게 지방이 저장될 공간이 남아있는거지? 라며 혼란스러울 수 있습니다.

이것을 이해하기 위해서 알아두어야 할 사실이 있습니다. SegWit 업그레이드는 정말로 블록 크기를 늘리지 않았을까? 라는 질문에 대해서 “블록 크기를 늘리지 않았다. 하지만 블록 크기는 1MB 보다 늘어날 수 있다” 라는 대답을 할 수 있습니다. 다시 말해, 블록 크기에 대해 비트코인 프로토콜 상에 명시적으로 업데이트 하지 않았지만, 서명 데이터를 별도로 저장하여 블록 크기 제한을 우회하는 방법으로 블록의 크기를 증가시킬 수 있었습니다. 이 블록 크기는 트랜잭션의 가중치에 따라서 결정되기 때문에 정해진 값이 아니라 트랜잭션에 따라서 유동적으로 변화하고, 최대 약 4MB 까지 블록의 크기는 늘어날 수 있습니다.

<그림 2. SegWit 은 블록 크기를 명시적으로 증가시키지 않고 우회하는 방법으로 블록 공간을 효율적으로 사용했다.>

코스트코 예시로 돌아가보면, 10kg 용량의 카트는 바꾸지 않고 살코기만 가득 담았는데, 지방을 담는 장바구니를 하나 더 가지고 다니는 것과 같다고 볼 수 있습니다. 그래서 사실상 10kg 보다는 더 들고 다니게 되는 것입니다. 지방은 필요없고 살코기만 필요하니까 지방은 그냥 버리면 안될까라는 생각이 들 수 있지만, 이것은 검증의 문제를 낳을 수 있습니다.

코스트코를 이용하는 소비자들이 모두 정직하고 법을 어기지 않는다면 계산할 때 카트만 가져간 다음, “제가 구매하는 것은 10kg 의 살코기와 지방 10kg 입니다” 라고 말하면 됩니다. 하지만, 만에 하나의 가능성으로 “저는 10kg의 살코기를 구매했고 지방은 없습니다” 라던지 “10kg의 살코기와 1kg의 지방입니다” 라며 실제 구입한 양과 다르게 거짓말 하는 소비자들이 있을 수 있습니다. 이를 방지하기 위해서 지방이 담긴 장바구니는 정확한 계산을 위해 갖고 있어야 합니다. SegWit 업그레이드도 마찬가지로 블록에 서명 데이터를 포함시켜야지 다른 풀노드들이 블록에 담긴 트랜잭션에 대해서 정상적으로 검증할 수 있습니다.

SegWit 업그레이드의 채택

SegWit 업그레이드가 진행되는 과정을 통해서 비트코인의 속성 중 하나인 ‘중앙 권위체 없이 이뤄지는 협력’의 과정을 이해해 볼 수 있었습니다. 아무리 비트코인 코어 개발자들이 프로토콜을 업그레이드 했다고 해서 이를 비트코인 네트워크에 전체적으로 적용할 수 있는 것은 아닙니다. 풀노드와 채굴노드들이 업그레이드 된 프로토콜을 적용하지 않으면 개발자들이 업그레이드 된 프로토콜은 무용지물이 됩니다.

이 SegWit 업그레이드에 대해서는 풀노드와 채굴노드 입장에서 대부분 동의를 하여 2022년 기준 80% 이상의 채택률을 보였습니다. 풀노드 입장에서 SegWit 업그레이드는 노드가 저장할 데이터가 증가된다는 결과를 가져오지만, 그 크기가 가변적이고 증가하더라도 그렇게 크지 않았기 때문에 풀노드들은 업그레이드를 수용한 것으로 보입니다.

또한, 업그레이드로 인해 확장성 뿐만 아니라 비트코인 네트워크 성능 개선과 보안성 강화에 효과가 있었던 것도 채택이 순조롭게 진행된 원인 중 하나입니다. 한편, 채굴노드 입장에서는 하나의 블록 안에 담길 수 있는 트랜잭션의 수가 늘었기 때문에 더 많은 수수료를 얻을 수 있다고 판단하여 SegWit 업그레이드를 수용한 것으로 보입니다.

<그림 3. SegWit 업그레이드 채택률>

한편, SegWit 업그레이드를 반대하는 노드들은 SegWit 업그레이드가 적용된 블록은 거절하고, 이전 버전과 호환되는 블록만 받아들일 수 있었습니다. 또는 SegWit 블록일지라도 서명 데이터를 제외한 최대 1MB 크기의 pruned block 을 받아서 저장할 수 있습니다. 이 말은 즉, 업그레이드가 적용되었다고 하더라도, 이전 버전과 호환이 되기 때문에 네트워크에서 여전히 노드의 역할은 할 수 있습니다.

하지만, 이렇게 대다수가 적용한 업그레이드를 적용하지 않은 상태로 남아있게 된다면 점점 스스로 검증할 수 있는 블록의 수는 줄어들고, 서명 데이터 없이 저장하고 있는 pruned block 에 대해서는 노드 스스로가 직접 검증할 수 있는 능력이 없기 때문에 사실상 비트코인 지갑 노드와 같은 SPV 노드 (Simplified Payment Verification) 노드와 같은 역할만 하게 됩니다.

<그림 4. SegWit 업그레이드를 이해하면 왜 블록의 크기가 1MB 이상 인지 이해할 수 있다>

요약하자면, SegWit 업그레이드는 트랜잭션 데이터와 서명 데이터를 분리하여 저장함으로써 보안 강화와 확장성을 높인 업그레이드 입니다. 이에 대한 채택률은 2022년 기준 80%를 넘어서며 대부분의 노드들이 채택하고 있고, 이 업그레이드 때문에 비트코인 블록 크기를 모니터링 해보면 1~2MB 사이의 크기를 갖고 있는 것을 볼 수 있습니다. 다음 글에서는 Taproot 업그레이드에 대해서 소개하면서 어떤 기능이 무슨 이유로 업그레이드가 되었는지 알아보도록 하겠습니다. 감사합니다. :)

참고자료

[그림 1] 자체 제작

[그림 2] 자체 제작

[그림 3] https://studio.glassnode.com/metrics?a=BTC&m=transactions.SegwitAdoption

[그림 4] https://mempool.space/