소프트포크 시행 방법: 정책 규칙으로 부터의 보호책을 강구하라

요약: 일전에 게시된 history of consensus forks 의 후속 기사인 이 글에서는 객원 작가인 Johnson Lau 박사가 포크의 정책 규칙 (policy rules) 과 합의 규칙 (consensus rules) 간의 차이를 설명할 것입니다. 그는 합의 규칙 변경과 관련한 위험 요소를 제거해주기 때문에 새로 제안된 합의 규칙이 정책 규칙 (비표준적 행동 방식인) 에 포함되어 있을 경우, 새로운 소프트포크의 도입이 더 안전한 방식일 수 있다는 점을 설명할 것입니다.

출처: gryb25

소프트포크는 합의 규칙을 수정하고 새로운 비트코인 합의 규칙 도입을 위한 일차적인 방법입니다.
이 기획 기사는 비트코인 소프트포크가 어떻게 설계되는지에 대해 서술할 것입니다.

합의 규칙과 소프트포크

합의 규칙 (Consensus rules) 은 거래내역과 블록이 유효한지 아닌지를 결정합니다. 비트코인 네트워크 상의 모든 사용자와 마이너들은 일련의 동일한 합의 규칙을 계속 준수할 것으로 예상되며, 따라서 그들 모두는 단일 거래 원장 방식에 동의할 것입니다.

소프트포크는 다수의 사용자/혹은 마이너들이 더 엄격한 합의 규칙의 채택을 결정했을 때 진행됩니다.
소프트포크는 이전에 유효했던 거래 / 블록들을 유효하지 않게 만들 수 있지만, 그 반대의 작업은 할 수 없습니다. 다수의 사람들이 새로운 규칙을 이행하면, 이 규칙을 위반한 모든 포크는 (통계적으로) 작업 증명 (proof of work) 의 측면에서 절대 더 엄격한 포크를 따라잡을 수 없습니다. 이전 규칙을 이행하는 소수의 사람들은 언제나 더 길고 엄격한 포크를 따라가게 되고 그 결과, 네트워크 상의 모든 사람들은
단일 거래 원장 방식에 여전히 동의하게 됩니다.

정책 규칙과 합의 규칙

합의 규칙이 거래의 유효성, 전달 또는 마이닝 노드만을 결정하는 기준이기 때문에 다른 것보다 몇몇
종류의 거래내역을 더 선호할 수도 있습니다. 예를 들면:

  • 스팸 제어 때문에, 수수료가 낮은 거래 또는 “샌드 아웃풋 (sand outputs)” (가치가 매우 낮은
    아웃풋) 은 승인이 거절됩니다.
  • 몇몇의 마이너들은 거래의 스팸화를 고려하여 “도박 관련 블록체인 상에서 (on-chain casino)” 의 거래를 하지 않습니다..
  • 알 수 없는 버전을 통한 거래는 승인되지 않습니다. (현재는 버전 1 과 2 만이 “알 수 있는” 버전 입니다).
  •  흔하지 않은 특이한 스크립트를 통한 거래 (P2PKH, P2SH, v0 세그윗 또는 몇 가지 경우는 해당되지 않음) 와 알수없는 NOPx 코드를 통한 거래 (현재 OP_NOP2 와 OP_NOP3 코드만이 알려져 있음) 는 승인되지 않습니다.
  • “수수료 경매제도 (Replace by fee)” 와 and “child pay for parent (거래가 승인되지 않거나
    승인 시간이 오래 걸려 수수료를 못 받았을 때, 다른 거래 ID를 찾아 수수료가 적당한 시점에 송금하는 방식, 이를 통해 새로운 거래를 함으로써 수수료를 얻을 수 있다)” 또한 마이너들이 선호하는 거래 방식을 알아내는 정책 규칙입니다.

의미상으로 정책 규칙은 최소한 합의 규칙과 동일한 수준으로 엄격해야 합니다. 분명한 것은, 블록상에서 유효하지 않은 거래를 하거나 (마이닝의 보상이 없어질 수도 있는) 전달 (유효하지 않은 거래를 전달받는 것은 거래 상대방에 의해 금지되어 있습니다) 하고 싶어하는 마이너는 없다는 사실입니다.

정책 규칙이 합의 규칙보다 더 엄격할 수는 있지만, 정책 규칙은 거래의 유효성을 결정하지 못한다는
점을 아는 것은 매우 중요합니다. 일단 거래가 유효 블록에 기록되면, 그것이 정책 규칙을 위반하더라도 모든 네트워크 노드는 이를 승인하게 됩니다.

또한 합의 규직의 적용 범위가 매우 넓은 것에 비해 정책 규칙의 적용 범위는 좁다는 점도 중요합니다.
이것은 서로 다른 네트워크 노드가 각자 다른 정책 규칙 (policy rules) 을 가질 수도 있지만, 동일한
합의 규칙 (consensus rules) 을 실행하는 한 동일한 블록체인 거래 원장 방식에 동의한다는 것을
의미합니다.

정책 규칙을 위반한 거래는 때때로 “비표준적 거래 (non-standard transactions)” 라고 불리며 이는 “유효하지 않은 거래 (invalid transactions)” 와는 구분되는 개념입니다.

정책 규칙과 소프트포크

이상적으로, 모든 마이너들은 소프트포크 진행 전에 새롭고 더 엄격한 규칙을 만들거나 진행 후에는 이를 업그레이드해야 합니다. 유효하지 않은 블록의 마이닝은 (개정된 규칙의 관점에서) 막대한 금전적 손실을 야기할 수 있는 반면, 소프트포크를 통해 마이너들은 경제적으로 엄청난 인센티브를 얻을 수 있습니다. 하지만, 비트코인과 같이 탈중앙화된 시스템 하에서 위 같은 경제적 이득은 보장되지 않습니다.

마이너들은 규칙 변경 제안에 대해 항상 주의를 기울이며 적절한 조치를 취해야 하지만, 유효하지 않은 블록체인을 설계하는 마이너들은 시장에 혼란을 야기하여 평범한 투자자들의 금전적인 손실을 일으킬 수 있습니다. 따라서, 아무리 잘 짜여진 소프트포크라도 이러한 점을 유념하고 위험성을 최소화해야 합니다.

소프트포크의 진행은 이것이 현재 폭넓게 적용되고 있는 정책 규칙에 의해 보장받을 수 있을 경우에만
가능합니다. 새로운 합의 규칙을 인식하지 못한 채 정책 규칙을 따르고 있는 마이너들은 기본적으로
위 같은 거래를 거부합니다. 따라서 그들은 새로운 합의 규칙의 관점에서 유효하지 않은 거래를 절대
하지 않습니다. 비트코인 거래에서의 몇몇 경우가 이를 나타내고 있습니다.

한 인부가 오래 전부터 있었던 장애물 때문에 이용되지 않았던 길에 “도로 폐쇄” 라는 표지판을 설치하고 있습니다. 새로운 교통 법규는 “기준에 어긋나는 (non-standard)” 행위와 최소한의 교통 혼잡만을
방지할 수 있습니다.  

사례 연구 설명
BIP65: 잠금 가능 시간 증명 및 확인

명령 코드 OP_NOP1 부터 OP_NOP10 까지는 원래 비트코인 스크립트
언어에 있어 별다른 의미가 없었습니다. 이것들은 명령어의 하나로 간주되지만, (스크립트 상의 명령어는 201개로 제한되어 있습니다) 사실상 거래 유효성
검사 과정에서 생략되었습니다. 그러나 버전 0.10 이  명령 코드 OP_NOPx 를
기본으로 받아들이지 않은 이후로 정책 규칙이 비트코인 코어 (Bitcoin Core) 에 포함되었습니다. BIP65 는 비트코인 코어 0.12 버전에서 OP_NOP2 를 OP_CHECKLOCKTIMEVERIFY (OP_CLTV) 로 재정의하기 위해 도입된
소프트포크입니다.  OP_CLTV 는 스택 밸류 (stack value)가 최고점일 때의 규모가 거래의 nLockTime 필드 (몇 가지 조건과 더불어) 보다 큰 지를 확인합니다. 이에 부합되는 조건이 하나라도 있는 경우, 유효하지 않은 거래로 분류됩니다. 그렇지 않은 경우, OP_CLTV 는 OP_NOP2 와 같이 생략됩니다. 새로운 노드는 언제나 소프트포크 시행 후에 신규 합의 규칙을 실행합니다. 하지만,
소프트포크 시행 이전에도 원래의 OP_NOP2 정책 규칙이 OP_CLTV 규칙으로 대체될 수 있습니다. (OP_CLTV 규칙은 원래의 OP_NOP2 정책 규칙보다
엄격하기 때문입니다).

레거시 마이닝 노드는 nLockTime 확인 기능을 수행하지 못합니다. 그러나,
이 노드의 버전이 버전 0.10 혹은 그 상위 버전을 유지하고 있는 한, 기본 명령 코드인 OP_NOP2 정책 규칙은 OP_CLTV 가 포함된 모든 거래를 금지할 것입니다. 해당 거래의 유효성 여부에 상관없이 말이죠. 결과적으로, 버전 0.10
혹은 그 상위 버전의 레거시 마이닝 노드는 절대 신규 OP_CLTV 합의 규칙과 관련된 유효하지 않은 블록을 자발적으로 생성할 수 없습니다.

BIP68: 시퀀스 번호를 이용한 상대 잠금 가능
시간
nSequence는 원래 사용되지 않았던 비트코인 거래의 필드 중 하나입니다.
소프트포크 BIP68은 nSequence field를 결제수단과 라이트닝 네트워크 (Lightning Network) 와 같은 고급 거래를 위한 블록 설계시  중요 요소인
상대 잠금 가능 시간 기능 (relative lock-time) 을 목적으로 시행됐습니다.
그러나 nSequence 필드는 비트코인의 초기 버전 이후로 쭉 등한시되었고,
마이너들은 nSequence 의 가치가 있는 모든 거래를 수용했습니다. nSequence 가치를 관리하는 정책 규칙이 없었기 때문에 앞서 언급한 OP_CLTV. 와 같이
안전한 소프트포크를 쉽게 실행할 수 없었습니다. 소프트포크를 위한 묘책은
거래 버전 필드 (transaction-verson field) (nVersion의) 를 활용하는 것이였습니다. 버전 0.7 이후, non-verson-1 거래가 정책 규칙에 의해 승인되지
않았습니다. 이 점을 활용하기 위해 BIP68 은 nSequence 가 거래 버전 2 혹은 그 상위 버전 (엄밀히 말하면, 0 이하의 버전) 에서만 활성화 될 수 있다는
규칙을 제정했습니다. 따라서, 기본적으로 non-verson-1 거래를 포함하고
있지 않은  레거시 마이닝 노드는 BIP68 의 규칙을 위반하는 어떠한 블록도
생성할 수 없습니다.BIP68 의 공격자는 단순한 거래 버전 변경을 통해 소프트포크를 중단시킬 수
없습니다. 이 거래 버전은 서명을 통해 암호화되어 있기 때문입니다. 또한 이는 합의 규칙과 관련된 거래 버전을 사용하는 유일한 소프트포크입니다.
BIP141: 증인 분리, Segwit 증인 분리 (세그윗 / segwit – Segregated witness) 은 특정 스크립트 패턴을 재정의함으로써 거래의 유연성을 개선하기 위해 고안된 소프트포크입니다. BIP141는 아웃풋 스크립트(혹은 P2SH 리딤스크립트)패턴이며 해당 스크립트는 단일 명령어인 OP_x (x = 0 에서 16) 로 시작하고 2에서 40바이트 사이의 정식 데이터로 이루어져 있습니다. 하지만 이는 원래 제안된 방식이 아니였습니다. 
초안
에서 증인 프로그램 (witness – program) 의 패턴은 2에서 41바이트
사이였습니다. 이 정책 규칙은 버전 0.6이 흔치 않거나 독특한 스크립트
(예를 들어, P2PKH, P2SH 그리고 몇몇 스크립트를 제외하고) 를 사용한 거래를 승인하지 않은 이후부터 시행되었습니다. 이 점에 있어 증인프로그램의 초안은
비표준적 이라고도 할 수 있습니다.증인 프로그램의 문제는 P2SH 와 관련된 것이였습니다. 버전 0.10이 적용되기 이전의 정책 규칙은 흔하지 않은 P2SH 스크립트의 승인을 모두 거절했습니다. 이 정책 규칙은 버전 0.10 하에서 완화되었고, 초기에 설계된 증인 프로그램은 포함되지 않았습니다.몇 가지의 제안이 대안으로 고려되었습니다:

  • 새로운 거래 버전 (BIP68 와 같은) 은 작동하지 않습니다. 만약 새로운
    합의 규직이 “거래 버전이 2 이상일때만 실행되는 세그윗 규칙이라면” , 공격자는 거래 버전을 바꿔 세그윗 아웃풋에 보관된 돈 전부를 훔칠 수
    있을 것입니다. (세그윗 규칙이 적용 가능한 거래 버전이 세그윗 서명으로 암호화되는 반면, 버전이 2 이하일 경우에는 확인이 불가합니다).
  • 명령어 OP_NOPx 는 증인 프로그램의 레이블 (label) 로 활용되었을 수도 있습니다. 하지만, 이것은 모든 증인 프로그램을 1바이트 보다 크게
    그리고 제한된 OP_NOPx 의 범위를 차지하게 할 수도 있습니다.

최종 버전에서는 BIP62 의 일명 “클린 스택 (clean stack)” 이라 불리는 정책
규칙을 활용하였습니다. 현재 BIP62는 시행되지 않고 있지만, 정책 규칙은
여전히 적용되고 있습니다. “클린 스택” 을 위해서는 유일한 스택 아이템으로
마무리되야 하는 스크립트 평가가 필요합니다. 최종으로 설계된 증인 프로그램은 스택에 2개의 아이템을 남겼습니다. 이는 합의 규칙 하에서는 유효하나 “클린
스택” 정책 규칙은 위반한 것입니다.

실패 사례: BIP16 와
거래 스크립트 사용
단순화를 위한 결제방식 (pay-to-script hash / P2SH)
BIP16 은 가장 처음 계획된 비트코인 소프트포크였습니다. 해시 파워가 55% 에 도달했다는 신호가 올 경우에 실행되었습니다. (현재는 80% 에서 95% 선에서 시행되고 있습니다) P2SH 도입 이전에는 소비 아웃풋의 형식을 확인할 수 있는 정책규칙이 존재하지 않았습니다. 이것의 결과로 소프트포크가 시행되고 한 달이 지날 때까지 엄청난 수의 마이너들은 계속해서 유효하지 않은 블록을 생성하거나 때로는 블록체인을 공매도하기도 했습니다.
실패 사례: 라이트코인의 세그윗 비트코인 세그윗 소프트포크의 시행이 확정된 후 오래지 않아 라이트코인은
세그윗 코드를 통합시키기 시작했습니다. 그러나 비트코인 코어의 세그윗이 버전 0.13.1 인 반면, 그 당시 라이트코인의 최신 세그윗은 “클린 스택” 정책 규칙이 포함되지 않은 버전 0.10.4 였습니다. 라이트코인의 개발자들은 마이너들이
세그윗 버전을 업그레이드 하길 바라며 다른 합의 규칙을 추가하여 이 문제를
해결하고자 했습니다. 추가된 규칙의 내용은 블록 버전이 최소 버전 0x20000000 이 되어야 한다는 것이였습니다. 소프트포크가 실행되기 전 (가장 마지막 마이너는 단 몇 시간 전에 업그레이드를 했습니다) 에 모든 마이너들은
곧바로 버전을 업그레이드 했지만, “클린 스택” 이 부족하여 포크는 실행되지
않았습니다. 나머지 블록체인 버전 규칙이 아주 약한 수준의 방지 정책 혹은
정책 적용을 받지 않았다면 대규모 마이닝 풀은 마지막 순간, 버전 업그레이드에 실패했을 것입니다. 이 내용은 향후 게재될 기사에서 다루어 질 것입니다.

정책 규칙은 만병 통치약이 아닙니다

이 시점에서 독자여러분은 정책 규칙이 오로지 소프트포크 시행 이후 유효하지 않은 첫 번째 블록을
생성한 악덕 마이너들만을 막을 수 있는 묘책이라는 사실을 알게되셨을 것입니다. 그러나 유효하지 않은 불록이 어떻게 생성되었던 간에 악덕 마이너들을 작업 증명 (Proof of Work, POW) 이 더 많은
블록을 선택하고 이러한 블록체인을 연장시킵니다. 따라서, 이 방법은 소프트포크 시행 시 뜻하지 않게 발생하는 체인 분할의 가능성을 감소시키는 유일한 방법이 될 수 있습니다. 하지만 이 방법이 체인분할의 가능성을 완전히 제거하지는 못합니다. 이 사안은 엄청난 수의 마이너들이 동일한 정책 규칙을 포함하지 않을 수도 있는 각기 다른 풀 노드를 이용할 경우에 특히 더 문제가 될 수 있습니다..

비트코인 프로토콜 개발자, Johnson Lau 박사

CC BY-SA 4.0