본 글은 '비트코인, 공개 블록체인 프로그래밍(Andreas M. Antonopoulos 저, 최은실, 김도훈, 송주한 옮김, 2018)'을 바탕으로 작성되었습니다.
이전 글까지는 채굴과 분산화된 합의가 이루어지는 전반적인 과정에 대해 알아보았다. 이제는 그것 이외의 다른 세부사항들에 대해 알아보자.
> 합의 공격
비트코인 장부는 시간이 지나면서 점점 더 변경하기 힘들도록 되어 있다. 이론상으론는 어떤 깊이에서도 분기가 발생할 수 있지만 실제로는 아주 깊은 깊이에서 분기가 발생하다록 하려면 어마어마한 컴퓨팅 파워가 필요하기 때문에 실질적으로는 이전에 생성된 파일들은 변경이 어렵ㅂ다. 그렇지만 앞으로 발생하게 될 합의나, 가장 최근 블록에는 합의 공격이 영향을 미칠 수 있다.
합의 메커니즘에 대한 공격 시나리오 중 하나는 '51% 공격'이다. 이 시나리오 상에서는 네트워크 전체의 해싱 파워 중 다수(51%)를 제어하고 있는 채굴자 집단이 블록체인과 이중지불 거래 내에서 의도적인 '분기'를 야기하거나 특정 거래 혹은 주소에 대해 서비스거부 공격을 시행한다. 분기/이중지불 공격은 공격자가 이전에 승인된 블록 아래에서 분기를 만들어서 해당 체인에 재수렴을 시행함으로써 기승인 블록을 무효화하는 경우 발생한다. 파워가 충분한 경우 공격자는 연달아 6개 이상의 블록을 무효화해서 변경이 불가능하다고 여겼던(6회의 승인) 거래들을 무효화시킨다.
이중지불은 공격자 본인의 거래에서만 가능하다는 점을 참고하자. 왜냐하면 그 공격자만이 해당 거래에 대한 유효한 서명을 만들어 낼 수 있기 때문이다. 자신의 거래를 이중지불하게 되면, 해당 거래를 무효화함으로써 해당 공격자가 실제로 지불하지 않고도 변경 불가능한 잔액 혹은 상품을 얻을 수 있다.
만약 비트코인으로 값비싼 물품을 구매하는 경우, 이중지불 공격의 위험성이 있다. 구매자는 동일한 입력값(UTXO)을 소비하는 경쟁 거래를 전송하고서 상인에게 지불했던 내역을 취소하게 된다. 이중지불 공격은 두 가지 경로를 통해 발생할 수 있는데, 하나는 거래가 승인되기 전에 발생할 수 있고 또 다른 하나는 공격자가 여러 블록을 무효로 만들기 위해 블록체인 분기를 악용하는 경우 발생할 수 있다. 51% 공격을 통해서 공격자들은 새로운 체인 내에 있는 본인들의 거래를 이중지불 처리해서 예전 체인에 있던 대응 거래들을 무효화시킨다.
예를 들어보자. 악의가 있는 공격자인 맬러리는 캐롤의 갤러리로 가서 사토시 나카모토를 그려 놓은 세 폭짜리 아름다운 작품을 구매했다. 캐롤은 그림을 비트코인으로 250,000달러에 맬러리에게 판매한다. 해당 거래에 대해 6회 이상의 승인을 기다리지 않고 1회 승인만 끝난 직후에 작품을 포장해서 맬러리에게 전달한다.
맬러리는 대규모 패굴 풀을 운영하는 공범자 폴과 함께 일한다. 폴은 맬러리의 거래가 블록 내에 포함되자마자 51% 공격을 시작한다. 폴은 맬러리의 거래가 담겨 있는 블록과 동일한 블록 높이를 다시 채굴하라고 채굴 풀에 지시해서 맬러리가 캐롤에게 지불한 거래와, 맬러리의 지불금액과 동일한 입력값으로 이중 지불한 거래를 교체한다. 이 이중지불 거래는 동일한 UTXO를 소비해서 캐롤에게 돈을 지불하는 대신 맬러리의 지갑으로 다시 해당 금액이 전송되도록 함으로써 본질적으로는 맬러리가 비트코인을 계속 보유할 수 있도록 해 준다.
그 후 폴은 이중지불 거래가 담겨 있는 체인을 원래의 체인보다 길게 만들기 위해 추가 블록을 채굴하라고 채굴 풀에 지시한다. 블록체인 분기 현상이 새로운 체인에 의해 해결되고 나면 이중지불된 거래는 캐롤에 대한 원거래를 대체한다.
이러한 종류의 공격으로부터 보호받기 위해서는 값비싼 품목을 판매하는 상인은 구매자에게 제품을 건네주기 전에 최소 6회의 승인을 기다려야 한다. 승인 횟수가 더 많아질수록 51% 공격으로 거래를 무효화시키기 더욱 어려워지기 때문이다.
이중지불 공격과 더불어 합의 공격의 또 다른 시나리오는 특정 비트코인 참가자에 대해 서비스를 거부하는 것이다. 다른 채굴자가 채굴한 블록 안에 특정 거래가 담겨 있는 경우, 공격자는 의도적으로 블록에 대한 분기를 만들고 해당 블록을 다시 채굴해서 특정 거래를 제외시키도록 할 수 있다. 이러한 유형의 공격은 공격자가 채굴 파워의 다수를 통제하는 한 특정 주소 혹은 주소 집합에 대해 서비스거부를 계속 유지할 수 있다.
이러한 시나리오들은 모두 이론적으로는 가능하지만 비트코인 네트워크의 전반적인 해싱 파워가 기하급수적으로 증가하면서 점점 더 비현실적이 되어 가고 있다. 최근 들어 P2Pool 채굴과 같이 비트코인이 한층 개선되면서 채굴 작업에 대한 통제를 분산화하는 데 그 목적을 두고 있으며, 이를 통해 비트코인 합의 공격이 좀 더 어려워지고 있다.
> 합의 규칙 변경하기
합의 규칙은 거래 및 블록의 유효성을 결정한다. 이러한 합의 규칙은 모든 비트코인 노드들이 협력을 하는 데 기본이 되며, 모든 로컬 관점을 전체 네트워크 내의 단일하고 일관된 블록체인으로 수렴하도록 하는 역할을 맡고 있다.
단기적으로는 이 합의 규칙이 변하지 않고 모든 노드에 걸쳐 일관되어야 하지만 장기적으로는 변한다. 비트코인 시스템을 진화시키고 발전시키기 위해서 이 합의 규칙은 새로운 특징이나 개선사항, 버그 수정 등을 수용하기 위해 때때로 변경되어야만 한다. 하지만 전통적인 소프트웨어 개발과는 달리 합의 시스템에 대한 업그레이드는 더 어렵고 모든 참가자 간 조정이 필요하다.
> 하드 분기
네트워크가 두 개의 체인으로 분기할 수 있는 시나리오 중 하나는 합의 규칙의 변경이다. 이러한 유형의 분기를 하드 분기(hard fork)라고 한다. 왜냐하면 분기가 진행되고 난 후에는 해당 네트워크가 단일 체인으로 재수렴하지 않기 때문이다. 그 대신 이 두개의 체인은 독립적으로 진화한다. 네트워크의 일부가 나머지 네트워크 하에 있을 때보다 다른 합의 규칙 하에서 가동될 때 하드 분기가 발생한다.
하드 분기는 합의 규칙을 변경하는 데 사용될 수 있다. 하지만 규칙을 변경하기 위해서는 시스템 내의 모든 참가자 간에 조정이 이루어져야 한다. 새로운 합의 규칙으로 업그레이드가 이루어지지 않은 노드라면 합의 메커니즘에 참가할 수 없고 하드 분기가 발생하는 시점에 개별 체인상에 있게 된다. 따라서 업그레이드가 이루어지지 않은 시스템은 더 이상 새로운 합의 규칙을 처리할 수 없다는 점에서 하드 분기에 의해 발생한 변화는 '상위 호환적(forward compatible)'이지 않다고 간주될 수 있다.
구체적인 예시를 들어 하드분기의 메커니즘을 살펴보자.
다음은 두 개의 분기가 발생한 블록체인이다.
블록 높이가 4인 지점에서 한 블록 분기가 발생한다. 블록 #5의 채굴로 네트워크가 하나의 체인으로 재수렴하고 해당 분기 현상이 해결되었다.
하지만 블록 높이가 6인 지점에서 하드 분기가 발생한다. 합의 규칙을 변경한 클라이언트의 새로운 구현이 출시되었다고 가정해 보자. 이 새로운 구현을 가동하는 채굴자가 블록 높이가 7인 지점에서 시작해서 블록 #7b를 채굴한다. 소프트웨어가 업그레이드되어 있지 않은 노드 혹은 채굴자는 누구라도 블록 #7b를 처리할 수 없다. 예전 규칙을 사용하고 있는 채굴자들은 블록 #7b를 수락하지 않고 부모가 블록 #6인 후보 블록을 계속해서 채굴할 것이다. 결국 그들은 예전 규칙 하에서 블록 #7a를 채굴할 수 있다.
이 두개의 체인이 이 시점부터 분기되기 시작한다. 'a' 체인상에 있는 채굴자들은 블록 #8b를 그 부모블록인 '7b'가 유효하지 않은 블록으로 인식되므로 고아 블록처럼 인식한다. 그 반대도 마찬가지다.
하드 분기 : 네트워크 분기
분기가 일어난 구현이 네트워크에 배치되면 특정 비율의 채굴자, 지갑 사용자, 중개 노드들이 이 구현을 채택해서 가동한다. 새로운 합의 규칙이 블록, 거래, 그 외 시스템의 다른 부분에 적용되는지에 따라 분기가 발생할 것이다. 만약 새로운 합의 규칙이 거래와 관련이 있으면 새로운 규칙 하에서 거래를 생성하는 지갑은 네트워크 분기가 발생할 수 있고, 그 후에 해당 거래가 블록 내에서 채굴될 때 하드 분기가 발생할 수 있다. 그리고 새로운 규칙이 블록과 관련이 있으면 블록이 새로운 규칙 하에서 채굴될 때 하드 분기 과정이 시작할 것이다.
우선 네트워크가 분기될 것이다. 기존의 합의 규칙 구현에 기반을 두고 있는 노드들은 새로운 규칙을 따르는 노드들은 그들에게 이 유효하지 않은 거래 및 블록을 전송하는 노드들과 일시적으로 작업을 중단하거나 연결을 끊는다. 결과적으로 해당 네트워크는 두 개로 분할된다. 이전 노드들은 이전 노드들과 연결된 채로 남아 있게 되고, 새로운 노드들은 새로운 노드들과 연결되게 된다. 새로운 규칙에 기반을 두고 있는 단일 거래 혹은 블록은 네트워크상에 퍼져 나가게 되고 네트워크를 두 개로 분할시킨다.
새로운 규칙을 사용하는 채굴자가 블록을 채굴하는 경우, 채굴 파워와 체인 역시 분기된다. 새로운 채굴자들은 새로운 블록 상부에서 채굴을 진행하고 이전 채굴자들은 이전의 규칙을 기반으로 별개의 체인을 채굴할 것이다. 이렇게 분할된 네트워크로 인해 개별의 합의 규칙을 운영하는 채굴자들은 두 개의 서로 다른 네트워크에 연결되기 때문에 서로의 블록을 수신받지 않을 것이다.
> 하드 분기에 대한 논란
하드 분기가 비주류 블록을 업그레이드하거나 비주류 체인상에 남아 있게 하기 때문에 위험해 보이기도 한다. 전체 시스템을 두 개의 경쟁 시스템으로 분할하는 것에 대한 위험성은 받아들일 수 없는 위험만큼이나 많이 목격된다. 따라서 많은 개발자들은 합의 규칙에 대한 업그레이드를 시행하는 데 네트워크 전체의 거의 만장일치인 지원이 없다면 하드 분기 메커니즘을 사용하지 않으려고 한다. 거의 만장일치인 지원을 받지 않는 하드 분기 제안은 위험 감수 없이 시스템을 분할시킨다는 '논란을 불러일으킬 수 있다'고 간주된다.
하드 분기 개발은 비트코인 개발 커뮤니티에서는 매우 논란이 많이 되고 있다. 특히 하드 분기가 최대 블록 크기를 제어하는 합의 규칙에 대한 변경을 제안하는 경우에 더욱 그러하다. 어떤 개발자는 너무 위험도가 높다는 이유로 어떠한 형태의 하드 분기라도 반대한다. 어떤 개발자는 하드 분기 메커니즘을 '기술 부채(technical dept)'를 피하고 과거와 깔끔하게 단절되는 방법으로 합의 규칙을 업그레이드하는 데 꼭 필요한 툴이라고 생각한다. 하드 분기는 다양한 고급 기획과 거의 만장일치인 합의 하에서만 가끔 사용되어야 하는 메커니즘이어야 한다고 생각하는 개발자도 있다.
하드 분기의 위험성을 해결할 수 있는 새로운 방법들이 등장했다. 이러한 방법들은 알아보도록 하자.
> 소프트 분기
소프트 분기는 하드 분기와 구별되는 용어로, 합의 규칙에 대한 상위-호환적인 변경이다. 이는 업그레이드가 이루어진 클라이언트가 새로운 규칙을 가지고 합의를 이루어 낼 수 있도록 해 준다.
소프트 분기의 특징 중 하나는 소프트 분기 업그레이드가 합의 규칙을 확장하는 데 쓰이는 것이 아니라 제한하는 데만 사용된다는 점이다. 소프트 분기가 상위-호환적이 되기 위해서는 새로운 규칙 하에서 생성된 거래와 블록들이 이전의 규칙 하에서도 유효해야 한다.
소프트 분기는 다야한 방법으로 구현될 수 있다.
> NOP 연산코드를 재정의하는 소프트 분기
비트코인 스크립트에는 향후 사용할 목적으로 비축된 연산코드가 NOP1부터 NOP10까지 열 개 있다. 합의 규칙 하에서 스크립트 내 이러한 연산코드의 존재는 null-potent 연산자로 해석된다. 아무런 영향력이 없다는 말이다.
소프트 분기는 NOP 코드의 의미를 변경해서 새로운 의미를 부여한다. 예를 들어, BIP-65(CHECKOCKTIMEVERIFY)는 NOP2 연산코드를 재해석한다. BIP-65를 구현하는 클라이언트는 NOP2를 OP_CHECKLOCKTIMEVERIFY로 해석하고 잠금 스크립트에 이 연산코드를 담고 있는 UTXO에 절대적 잠금시간 합의 규칙을 부여한다.
이것이 바로 소프트 분기다. 왜냐하면 BIP-65 하에서 유효한 거래라면 BIP-65를 구현하지 않는 어떠한 클라이언트상에서도 유효하기 때문이다. 이전 클라이언트상에서는 이 스크립트에 NOP 코드가 담겨 있고, 이 사실은 무시된다.
> 소프트 분기 업그레이드를 위한 다른 방법들
특정한 유형의 합의 변경을 위해 NOP 연산코드에만 의존하는 것은 아닌 또 다른 소프트 분기 메커니즘이 도입되었다. 세그윗이라는 거래 구조에 대한 구조적 변경을 의미하는데, 이 변경을 통해 잠금 스크립트(서명)가 거래 내부에서 데이터 구조 외부로 이동하게 된다.
2015년 11월 비트코인 코어에서 작업하던 한 개발자가 세그윗이 소프트 분기로 도입될 수 있는 메커니즘을 제안했는데, 여기에는 세그윗 규칙 하에서 생성된 UTXO의 잠금 스크립트를 수정한 것이었다. 그러한 환경에서 수정되지 않은 클라이언트들이 잠금 스크립트를 어떤 해제 스크립트를 이용해도 현금화할 수 있는 대상으로 간주하게 되었다. 그 결과 모든 노드에게 업그레이드를 하거나 체인을 분할하라고 요구할 필요 없이 세그윗이 도입될 수 있었다.
> 소프트 분기에 대한 비판
NOP 연산코드에 기반을 두고 있는 소프트 분기는 상대적으로 논란이 덜하다. 하지만 많은 개발자들은 다음과 같은 것들을 우려하고 있다.
-
기술 부채
: 소프트 분기가 하드 분기 업그레이드보다 조금 더 기술적으로 복잡하기 때문에 기술 부채라른 용어가 등장한다. 이는 과거에 발생했던 설계 상충(design tradeoff) 때문에 향후 코드 비용이 증가하는 것을 말한다. 결국 코드의 복잡성은 버그 및 보안 취약성의 가능성을 높이게 된다. -
유효화 완화
: 수정되지 않은 클라이언트들은 수정된 합의 규칙을 평가하지 않고서 거래를 유효하다고 간주한다. 사실상 이 수정되지 않은 클라이언트들은 새로운 규칙을 알지 못하기 때문에 합의 규칙의 모든 내용을 이용해서 유효화하지 않는다. 이는 NOP 기반 업그레이트뿐 아니라 다른 소프트 분기 업그레이드에도 적용된다. -
취소될 수 없는 업그레이드
: 소프트 분기는 추가적인 합의 제약을 가진 거래를 생성하기 때문에 실제로 업그레이드가 취소될 수 없다. 만약 소프트 분기 업그레이드가 활성화된 후에 다시 예전 버전으로 돌아간다면 새로운 규칙 하에서 생성된 거래를 모두 이전 규칙 하에서 자금의 손실로 볼 수도 있기 때문이다.
> 블록 버전을 이용한 소프트 분기 시그널링
변경되지 않은 클라이언트들은 소프트 분기를 통해 합의 내에서 운영을 계속할 수 있기 때문에 소프트 분기를 '활성화'하기 위한 메커니즘은 채굴자들의 시그널링 준비 상황을 통해 이루어진다. 즉, 대부분의 채굴자들은 새로운 합의 규칙을 시행할 준비가 되어 있고 의지가 있다는 사실에 동의해야 한다. 채굴자들의 행동을 조정하기 위해서 합의 규칙 변경에 따른 채굴자들의 지원을 보여 주는 시그널링 메커니즘이 존재한다.
새로운 버전이 출시되면, 네트워크의 참여자들은 이전 버전과 새로운 버전을 구별할 수 있는 블록 버전을 설정한다. 이후 블록 버전이 설정된 블록이 생성될 때마다, 새로운 버전의 지원자는 해당 블록에 대한 시그널링을 시작한다.
시그널링은 새로운 버전을 지원하는 사용자들이 해당 블록에 대해 특정 비트를 설정하여, 그 블록이 새로운 버전에 대한 시그널링을 하는 것을 의미한다. 모든 사용자가 해당 비트를 설정할 필요는 없으며, 일부 사용자만 시그널링을 할 수 있다. 이를 통해 새로운 버전을 지원하는 사용자들이 네트워크 상황을 모니터링하고, 적절한 시기에 새로운 버전을 적용할 수 있도록 도와준다.
소프트 분기 시그널링으로는 BIP-9가 존재한다.
해당 시그널링에 대한 설명은 다음을 참고하자.
> 합의 소프트웨어 개발
합의 소프트웨어 개발은 계속 진화하고 있고 합의 규칙을 변경하는 데 필요한 다양한 메커니즘에 대한 논의도 많이 진행되고 있다. 특성상 비트코인은 변경에 대한 조정 및 합의에 대해 높은 장벽을 치고 있다. 분산화된 시스템으로서 비트코인은 네트워크 사용자들에게 의지를 부여할 수 있는 '중앙 당국'이 없다. 채굴자, 코어 개발자, 지갑 개발자, 교환, 상인 , 최종 사용자 등의 다양한 이해 집단들 사이에 파워가 분산되어 있다. 그 중 어떤 한 집단에 의해 일방적으로 결정이 내려질 수 없다. 파워가 분산되었다는 것의 의미는 모든 참가자들이 서로 조정해야 한다는 뜻이고 조정 없이는 어떠한 변경도 이룰 수 없다는 의미다.
현재의 상황은 엄청난 다수에 의한 강력한 합의가 있다면 몇몇 변경만이 가능한, 안정된 시스템이다. 소프트 분기에 대한 95%라는 기준 값은 이러한 현실을 반영해 주고 있다.
합의 개발에 있어 완벽한 솔루션은 없다는 사실을 인지하는 것은 중요하다. 하드 분기와 소프트 분기 모두 상충되는 부분을 가지고 있다. 어떤 유형의 변경에서는 소프트 분기가 더 나은 선택이 될 수 있고, 어떤 경우에는 하드 분기가 더 나은 선택이 될 수 있다. 완벽한 선택은 존재하지 않고 어떠한 경우라도 위험은 따른다. 합의 소프트웨어 개발의 변함없는 특징 중 하나는 변경이 어렵고 합의가 타협을 하게 만든다는 점이다.
