[Mastering Bitcoin] 마스터링 비트코인 내 맘대로 정리 - Ch 10

Ch.10 Mining and Consensus

Changing the Consensus Rules

합의 규칙은 거래와 블록의 유효성을 결정한다. 합의 규칙은 단기간에 변하지 않으며 모든 노드에서 일관되어야 하지만, 장기적으로 변함이 없는 것은 아니다. 비트코인 시스템이 진화하고 발전하기 위해서 새로운 기능, 개선 사항 또는 버그 수정을 수용하기 위한 규칙이 수시로 변경되어야 한다. 그러나 전통적인 소프트웨어 개발과 달리 합의 시스템의 업그레이드는 훨씬 어렵고 모든 참여자 간의 조정이 필요하다.

Hard Forks

네트워크가 다음 두 가지 사슬로 갈라질 수 있는 또 다른 시나리오가 있다 : 합의 규칙의 변화. 이 유형의 포크를 하드포크라고 한다. 포크 후에 네트워크가 단일 체인으로 재구성되지 않는다. 대신, 두 사슬은 독립적으로 진화한다. 하드포크는 네트워크의 일부가 나머지 네트워크와 일치하는 합의 규칙에서 작동할 때 발생한다. 이것은 버그 또는 합의 규칙의 구현에서 고의적인 변경으로 인해 발생할 수 있다.

하드포크는 합의 규칙을 변경하는 데 사용할 수 있지만 시스템의 모든 참가자들 간에 조정이 필요하다. 새로운 합의 규칙으로 업그레이드하지 않는 노드는 합의 메커니즘에 참여할 수 없으며 하드포크가 발생하면 별도의 체인에 강제 적용된다. 따라서 하드포크에 의해 도입된 변화는, 업그레이드되지 않은 시스템이 더 이상 새로운 합의 규칙을 처리 할 수 ​​없다는 점에서 ‘순방향 호환성’이 아닌 것으로 간주 될 수 있다.

하드포크 메카니즘을 구체적인 예를 들어 살펴 보자.

아래는 두 개의 포크가 발생한 블록체인을 보여준다. 블록 높이 4에서 한 블록에 포크가 발생한다. 이것은 ‘Blockchain Forks’에서 본 자발적인 포크 유형이다. 블록 5의 마이닝을 사용하면 네트워크가 한 체인에서 재구성되고 분기가 해결된다.

[그림 1] - 포크가 있는 블록체인

그러나 나중에 블록 높이 6에서 하드포크가 발생한다. 합의 규칙의 변경과 함께 클라이언트의 새로운 구현이 릴리스된다고 가정해보자. 블록 높이 7에서 시작하여 이 새로운 구현을 실행하는 마이너는 새로운 유형의 디지털 서명을 수락한다. ECDSA 기반이 아닌 "Smores"서명이라고 해보자. 즉시 새 구현을 실행하는 노드는 Smores 서명을 포함하는 트랜잭션을 생성하고, 이 트랜잭션을 포함하는 업데이트된 소프트웨어 블록(7b)을 포함하는 마이너를 생성한다.

Smores 서명의 유효성을 검사하기 위한 소프트웨어를 업그레이드하지 않은 노드나 마이너는 이제 블록 7b를 처리할 수 ​​없다. 그들의 관점에서 볼 때 Smores 서명이 포함된 트랜잭션과 해당 거래를 포함하는 블록 7b는 모두 오래된 합의 규칙에 따라 트랜잭션을 평가하기 때문에 유효하지 않다. 이 노드는 트랜잭션과 블록을 거부하고 이를 전파하지 않는다. 기존 규칙을 사용하는 마이너는 블록 7b를 허용하지 않으며 블록 6인 부모를 가진 후보 블록을 계속 채굴한다. 실제로 이전 규칙을 사용하는 마이너는 연결된 모든 노드가 블록 7b를 수신하지 않을 수도 있다. 또한 이전 규칙을 따르므로 블록을 전파하지 않는다. 결국, 그들은 블록 7a를 채굴 할 수 있게 될 것이다.

Hard Forks: Software, Network, Mining, and Chain

개념적으로 하드포크는 소프트웨어 포크, 네트워크 포크, 마이닝 포크 및 체인 포크의 4 단계로 발전하는 것으로 생각할 수 있다.

이 프로세스는 수정된 합의 규칙을 가진 클라이언트의 대체 구현이 개발자에 의해 만들어졌을 때 실행된다.

이 분기된 구현이 네트워크에 배치되면 특정 비율의 마이너, 지갑 사용자 및 중간 노드가 이 구현을 채택하고 실행할 수 있다. 포크의 결과는 새로운 합의 규칙이 블록, 트랜잭션 또는 시스템에 적용되는지 여부에 따라 달라진다. 새로운 합의 규칙이 트랜잭션과 관련된 경우 새 규칙에 따라 트랜잭션을 만드는 지갑은 네트워크 포크를 발생시킬 수 있으며, 트랜잭션이 블록으로 채굴될 때 하드포크가 이어질 수 있다. 새 규칙이 블록과 관련된 경우 새 규칙에 따라 블록이 채굴될 때 하드포크 프로세스가 시작될 것이다.

먼저, 네트워크가 포크된다. 합의 규칙의 원래 구현을 기반으로 한 노드는 새로운 규칙에 따라 생성된 트랜잭션과 블록을 거부한다. 또한 원래의 합의 규칙을 따르는 노드는 이러한 잘못된 트랜잭션과 블록을 보내는 노드를 일시적으로 금지하고 연결을 끊는다. 결과적으로 네트워크는 두 개로 분할될 것이다 : 기존 노드는 기존 노드에만 연결될 것이고 새 노드는 새 노드에만 연결될 것이다. 새 규칙을 기반으로 하는 단일 트랜잭션이나 블록은 네트워크를 통해 전파되어 파티션을 두 개의 네트워크로 만든다.

새로운 규칙을 사용하는 마이너가 블록을 채취하면 마이닝 파워와 체인도 포크된다. 신규 마이너는 새로운 블록 위에 채굴할 것이고 오래된 마이너는 기존 규칙에 따라 별도의 채굴을 할 것이다. 분할 네트워크는 별도의 합의 규칙에 따라 운영되는 마이너가 서로 다른 두 개의 네트워크에 연결되어있어 서로의 블록을 받지 못하도록 한다.

Diverging Miners and Difficulty

마이너가 두 개의 서로 다른 체인을 채굴할 때마다 해시 파워가 체인 사이에서 분할된다. 채굴 파워는 두 체인 사이의 어떤 비율로 나뉠 수 있다. 새로운 규칙은 소수에 의해, 또는 강한 채굴 파워에 의해서만 뒤따를 수 있다.

예를 들어, 80% - 20%의 분할에서 대부분의 마이닝 파워는 새로운 합의 규칙을 사용한다고 가정해보자. 그리고 포크가 재타겟팅(retargeting) 기간 후 즉시 발생한다고 가정해보자.

두 체인은 각각 재타겟팅 기간에 어려움(difficulty 난이도?)을 상속 받게 된다. 새로운 합의 규칙은 이전에 이용 가능한 마이닝 파워의 80%를 가진 것이다. 즉, 이 체인의 마이닝 파워는 이전 기간과 비교하여 갑자기 20% 감소한 것이다. 블록은 매 12.5분마다 평균적으로 발견될 것이며, 이 체인을 확장하는데 사용할 수 있는 마이닝 파워의 20% 감소를 나타낸다. 블록 발급 비율은 (마이닝 파워의 어떤 변화가 없다면) 2016 블록이 채굴될 때까지 계속될 것이며, 약 25,200분(블록 당 12.5분) 또는 17.5일이 소요될 것이다. 17.5일 후 재타겟팅이 발생하고 이 체인의 해싱 파워가 감소된 상태에서 10분 블록을 다시 생성하기 위해 난이도가 조정된다.

해시 파워의 20%만 사용하는 이전 규칙에 따라 마이닝하는 소수의 체인은 훨씬 더 어려운 작업에 직면하게 된다. 이 체인에서 블록은 평균 50분마다 채굴된다. 난이도는 2016 블록으로 조정되지 않으며 100,800분 또는 약 10주가 소요된다. 블록 당 고정 용량을 가정하면 트랜잭션을 기록하는데 사용할 수 있는 시간당 블록 수가 적기 때문에 트랜잭션 용량이 5배 감소한다.

Contentious Hard Forks

하드포크는 소수를 업그레이드하거나 소수 체인에 남겨두기 때문에 위험하다고 간주된다. 전체 시스템을 2개의 경쟁 시스템으로 분할하는 위험은 많은 사람들에게 받아들일 수 없는 위험으로 간주됩니다. 결과적으로, 많은 개발자들은 전체 네트워크에서 거의 만장일치가 아닌 이상, 하드포크를 사용하여 합의 규칙에 대한 업그레이드를 수행하는 것을 꺼린다. 거의 만장일치가 아닌 하드포크 제안은 시스템의 파티션을 위험에 빠뜨리지 않고 시도하기엔 "논쟁의 여지가 있는"것으로 간주된다.

하드포크의 문제는 비트코인 개발 커뮤니티에서 논쟁의 여지가 많다. 특히 최대 블록 크기 제한을 제어하는 ​​합의 규칙에 대한 제안된 변경 사항과 관련이 있다. 일부 개발자는 모든 형태의 하드포크에 반대하며 너무 위험하다고 생각한다. 다른 사람들은 하드포크의 메커니즘이 "기술적 부채"를 피하고 과거와의 완전한 단절을 하기 위한 합의 규칙을 업그레이드하는데 필수적인 도구라고 생각한다. 마지막으로, 일부 개발자는 하드포크를 많은 사전 계획과 만장일치로 합의가 이루어져서, 가끔 사용되어야 하는 메커니즘으로 간주한다.

Soft Forks

모든 합의 규칙 변경으로 하드포크가 생기는 것은 아니다. 소프트포크는 업그레이드하지 않은 클라이언트도 계속 새로운 합의 규칙을 운영할 수 있도록 한 호환 가능한 합의 규칙의 변경이다.

소프트포크의 한 가지 측면은 명확하지 않지만 소프트포크 업그레이드는 합의 규칙을 확장하는 것이 아니라 제약을 가하는 데에만 사용할 수 있다는 것이다. 순방향 호환을 위해서는 새 규칙에 따라 생성된 트랜잭션과 블록이 이전 규칙에서도 유효해야하지만 그 반대는 유효하지 않다. 새로운 규칙은 유효한 규칙만 제한할 수 있다. 그렇지 않으면 이전 규칙에 따라 거부될 때 하드 포크를 한다.

Soft Fork Signaling with Block Version

소프트포크는 수정되지(업그레이드되지) 않은 클라이언트가 합의하에 계속해서 작업할 수 있기 때문에, 소프트포크를 "활성화"하는 메커니즘은 마이너가 신호에 대한 준비할 수 있도록 하기위한 것이다. 마이너의 대다수는 새로운 합의 규칙을 실행할 준비가 되어 있으며 기꺼이 동의해야한다. 자신의 행동을 조정하기 위해서 합의 규칙 변경에 대한 자신의 지지를 보여줄 수 있는 신호 메커니즘이 있다. 이 메커니즘은 2013년 3월에 BIP-34가 활성화되고 2016년 7월에 BIP-9가 활성화됨으로써 도입되었다.

BIP-34 Signaling and Activation

BIP-34의 첫 번째 구현은 블록 버전 필드를 사용하여 마이너가 특정 합의 규칙 변경에 대한 준비를 알릴 수 있게 했다. BIP-34 이전에는 합의에 의해 시행되지 않는 협약에 의해 블록 버전이 "1"로 설정되었다.

BIP-34는 코인베이스(coinbase) 트랜잭션의 코인베이스 필드가 블록 높이를 포함하도록 하는 합의 규칙의 변경을 정의했다. BIP-34 이전에는 마이너가 선택한 임의의 데이터가 코인베이스에 포함될 수 있었다. BIP-34가 활성화 된 후 유효한 블록은 코인베이스의 시작 부분에 특정 블록 높이를 포함해야하며 버전 번호가 "2"이상이어야 한다.

BIP-34의 변경 및 활성화를 알리기 위해 마이너는 블록 버전을 "1" 대신 "2"로 설정한다. 이것은 버전 "1" 블록을 유효하지 않게 만들지 않았다. 활성화되면 버전 "1" 블록이 유효하지 않게 되고 모든 버전 "2" 블록은 유효해지도록 코인베이스의 블록 높이를 포함해야한다.

BIP-34는 1000 블록의 롤링 윈도우에 기반한 2단계 활성화 메커니즘을 정의했다. 마이너는 "2"를 버전 번호로 하여 블록을 구성하여 BIP-34에 대한 개별 준비 상태를 알린다. 엄밀히 말하자면, 이 블록들은 합의 규칙이 아직 활성화되지 않았기 때문에 코인베이스 거래에서 블록 높이를 포함하는 새로운 합의 규칙을 준수할 필요가 없다. 합의 규칙은 두 단계로 활성화된다.

• 75%(가장 최근 1000개의 블록 중 750개)가 버전 "2"로 표시되면 코인베이스 트랜잭션에서 버전 "2"블록이 블록 높이를 포함해야하며, 그렇지 않으면 유효하지 않은 것으로 간주된다. 버전 "1"블록은 여전히 ​​네트워크에서 허용되며 블록 높이를 포함할 필요가 없다. 이 기간 동안에는 새로운 합의 규칙이 공존한다.

• 95%(가장 최근 1000개의 블록 중 950개)가 버전 "2"일 때, 버전 "1"블록은 더 이상 유효한 것으로 간주되지 않는다. 버전 "2"블록은 코인베이스에 블록 높이가 포함된 경우에만 유효하다. 그런 다음 모든 블록은 새 합의 규칙을 따라야하고 모든 유효한 블록은 코인베이스 트랜잭션에서 블록 높이를 포함해야한다.

BIP-9 Signaling and Activation

BIP-34, BIP-66 및 BIP-65에서 사용된 메커니즘은 세 개의 소프트 포크를 성공적으로 작동 시켰다. 그러나 몇 가지 제한사항이 있기 때문에 대체되었다.

• 블록 버전의 정수 값을 사용하면 한 번에 하나의 소프트포크만 활성화 될 수 있으므로 소프트포크 제안과 해당 우선순위 및 순서에 대한 합의가 필요했다.

• 또한 블록 버전이 증가했기 때문에 메커니즘은 변경을 거부하고 다른 것을 제안하는 간단한 방법을 제공하지 않았다. 오래된 클라이언트가 계속 실행 중이면 이전에 거부된 변경 사항에 대한 신호로 새 변경 사항에 대한 신호를 착각할 수 있다.

• 새로운 변경 사항은 향후 변경 사항을 위해 사용 가능한 블록 버전을 획기적으로 줄였다.

BIP-9는 이러한 과제를 극복하고 미래의 변화를 구현하는 속도와 용이성을 개선하기 위해 제안되었다.

BIP-9는 블록 버전을 정수 대신 비트 필드로 해석한다. 블록 버전은 원래 버전 1에서 버전 4까지의 정수로 사용되었기 때문에 29비트만 비트 필드로 사용할 수 있다. 29개의 다른 제안서에 대해 독립적으로 그리고 동시에 신호 준비에 사용할 수 있는 29비트가 남는다.

또한 BIP-9는 신호 및 활성화를 위한 최대 시간을 설정한다. 이런 식으로 마이너들은 영원히 신호할 필요가 없다. 제안서가 제안서에 정의된 TIMEOUT 기간 내에 활성화되지 않으면 제안서가 거부된 것으로 간주된다. 제안서는 활성화 비트를 갱신하면서 다른 비트로 신호를 재전송 할 수 있다.

또한 TIMEOUT이 지나고 기능이 활성화되거나 거부된 후에는 신호 비트를 혼동하지 않고 다른 기능에 재사용 할 수 있다. 따라서 최대 29개의 변경 사항을 병렬로 전달할 수 있으며 TIMEOUT 이후에 비트를 "재활용"하여 새로운 변경 사항을 제안 할 수 있다.

어렵당..