당신은 아마도 비트코인을 위한 새로운 제안된 소프트 포크 업그레이드인 Taproot에 대해 이미 들어봤을 것입니다. 이 업그레이드는 새로운 서명 알고리즘과 더 향상되고, 더 개인적이며 유연한 스크립팅 메커니즘을 도입할 것입니다.
Taproot에 대한 논의는 오랫동안 이루어졌고, 그 코드가 이미 비트코인 코어에 병합되었지만, 실제 업그레이드는 아직 이루어지지 않았습니다. 즉, 변경 사항이 아직 네트워크에 의해 활성화되고 시행되지 않았습니다. 여전히 남아 있는 가장 큰 질문은 활성화를 어떻게 조정할 것인가입니다.
비트코인 변경 사항 조정
조정이 왜 그렇게 중요한가요? 비트코인 소프트 포크가 작동하는 방식은 합의 프로토콜에 새로운 규칙을 도입하기 때문입니다. 즉, 노드가 블록이 유효한지 여부를 결정하는 규칙입니다. 이 말은 이론적으로, 만약 노드가 혼자서 소프트 포크를 활성화하면, 다른 모든 노드가 여전히 수용하는 블록을 거부할 위험에 처하게 되어, 본질적으로 자신을 다른 체인으로 포크하게 되고, 그 체인에서는 어떤 채굴자도 작업하지 않으며, 어떤 사용자도 거래를 원하지 않게 됩니다.
이제, 만약 소수의 노드가 소프트 포크를 활성화하기 위해 조정한다면, 그들은 위와 같은 위험에 처하게 됩니다. 그들은 서로 거래할 수는 있지만, 적어도 일부 채굴자가 여전히 그 블록을 채굴하는 데 작업을 할 것이라고 가정할 때, 그들은 여전히 포크되지 않은 체인에서 작업하는 채굴력의 큰 부분을 잃게 되어, 다른 노드가 그들의 거래를 수용하지 않기 때문에 그들의 포크는 덜 유용해지고, 51% 공격에 더 취약해집니다.
경제적 다수(지불 검증에 적극적으로 사용되는 노드)가 소프트 포크를 함께 활성화하기 위해 조정할 때만 채굴자들도 위험에 처하게 됩니다. 업그레이드하지 않으면 대부분의 사용자가 거부할 블록에서 작업할 위험이 있기 때문에, 그들은 아무도 수용하지 않을 채굴 보상을 얻으려는 시도로 자원을 낭비하게 됩니다.
그렇지만, 경제적 다수의 네트워크 노드가 성공적으로 조정하고 변경 사항을 활성화했을 때, 채굴자의 상당 부분이 새로운 규칙을 시행하지 않겠다고 고집하면, 보안 해시 파워의 큰 부분을 잃을 위험이 임박하게 됩니다. “게임 이론”은 이것이 모든 측면에서 가장 바람직하지 않은 결과가 되게 합니다. 채굴자는 노드가 거부할 블록을 채굴함으로써 돈을 잃을 위험이 있고, 네트워크의 노드는 해시 파워를 잃고 그들의 체인이 공격에 더 취약해질 위험이 있습니다.
모든 측면이 이 시나리오를 피하고자 하므로, 조정에 많은 노력이 투자되고 있으며, 노드와 채굴자가 소프트 포크를 활성화할 준비가 되어 있고 기꺼이 하도록 보장하고 있습니다.
SegWit 소프트 포크 활성화의 드라마를 기억할 수도 있습니다. 대규모 채굴자와 노드를 운영하는 사람들 간의 합의가 처음에는 이루어지지 않았고, 채굴자들이 결국 사용자 활성화 소프트 포크(UASF)의 위협 아래에서 SegWit를 활성화하기 위해 네트워크의 요구를 준수하게 되었습니다.
이것은 비트코인의 힘이 궁극적으로 사용자에게 속한다는 훌륭한 실시간 시연이었지만, 채굴자는 관리자보다는 서비스 제공자의 역할을 합니다. 아무도 UASF 위협을 실현하는 것이 바람직한 과정이라고 제안하지 않습니다. 채굴자는 사용자가 무효하다고 간주하는 블록을 만들면서 돈을 잃게 되고, 사용자는 비업그레이드된 채굴자의 블록을 거부함으로써 한동안 보안의 큰 요소를 잃게 됩니다.
LOT: Taproot와 함께 나아가기
다행히도, Taproot의 활성화는 SegWit만큼 논란의 여지가 없으며, 논란이 있다 하더라도 사용자나 채굴자들로부터 주목할 만한 반대가 거의 제기되지 않았습니다. 그럼에도 불구하고 이 업그레이드 프로세스를 올바르게 수행하는 것이 매우 중요합니다. 비트코인에 가능한 한 안전하고 무해한 전환을 만들기 위해서입니다.
Taproot 활성화에 선택된 프로세스는 BIP 8(비트코인 개선 제안 8)에 자세히 설명되어 있습니다. 간단히 말해, 이 프로세스는 채굴자가 생산하는 블록에서 특별한 데이터를 통해 업그레이드되었고 변경 사항을 활성화할 준비가 되었음을 신호하는 슈퍼 다수의 필수 임계값(일반적으로 약 95%)을 설정하는 방식으로 작동합니다. 해당 임계값에 도달하면 약 2주(2,016 블록, 하나의 난이도 조정)의 최종 기간이 시작되며, 그 후 소프트 포크가 활성화되고 새로운 규칙이 시행됩니다. 이 메커니즘에는 “만료” 옵션도 포함되어 있으며, 특정 블록 높이를 지나도 필수 임계값이 충족되지 않으면 활성화 프로세스가 취소되고 실패한 것으로 간주됩니다.
지금까지 이 메커니즘은 이전에 소프트 포크에 사용된 BIP 9와 거의 동일합니다. 그러나 BIP 8의 프로세스에는 “lockinontimeout” (LOT)이라는 다른 가능한 옵션이 포함되어 있습니다. 이 옵션은 true 또는 false(사용됨 또는 사용되지 않음)로 설정할 수 있습니다.
이 옵션이 true로 설정되면, 만약 채굴자 신호 임계값이 만료 시간 이전에 도달하지 못했을 경우 다른 경로를 도입합니다. 실패하는 대신, lockinontimeout는 활성화를 진행하도록 강제합니다. 본질적으로 만료 날짜 대신 마감일로 작용합니다. 이 경우, 활성화 프로세스를 실행하는 노드는 업그레이드에 대한 준비 신호를 보내지 않는 블록을 거부하기 시작합니다. 이는 체인이 임계값에 도달하도록 강제할 것입니다(신호 블록만 포함되므로) 그리고 다음 난이도 조정 기간은 “잠금” 기간이 될 것입니다 — 활성화 이전의 마지막입니다. 간단히 말해, LOT는 채굴자가 행동하기를 거부할 경우 사용자 활성화 소프트 포크(UASF)를 촉발할 것입니다. 이는 SegWit가 활성화된 방식과 유사합니다.
기본적으로 LOT에 대한 논란
Taproot를 활성화하는 경로가 BIP 8 프로세스가 될 것이라고 결정되었지만, LOT 사용에 대한 논의는 여전히 진행 중입니다. 2월 16일에 열린 최근 논의에서는 비트코인 코어 개발자들의 대다수가 기본적으로 LOT 옵션을 활성화하지 않기를 선호한다고 제안했습니다. LOT 사용에 대한 주요 반대 이유는 Taproot의 활성화가 대부분의 지표가 제시하는 것처럼 논란이 없다면, LOT 사용이 불필요할 것이고, 만약 논란이 생긴다면 활성화되기보다는 실패해야 한다는 것입니다. 또한, 코어 개발자들은 변경 사항을 제안하는 역할만 해야 하며, LOT를 활성화하는 것은 기본적으로 제안 이상의 더 공격적인 입장을 취하는 것이며, 프로토콜 변경을 적극적으로 추진하게 되는 것이라고 주장합니다 — 이는 그들이 행동해야 할 범위를 넘어서는 것입니다.
그러나 회의 중에 그들이 원래의 선호를 고수할 것인지 질문을 받았을 때, LOT 활성화에 찬성하는 약간의 다수가 형성된 것으로 보였습니다. LOT 사용을 지지하는 주요 주장은 Taproot가 오랫동안 커뮤니티에서 철저히 논의되고 승인되었으며, 소수의 채굴자가 업그레이드하는 것을 귀찮아할 수 있다는 이유로 실패하게 해서는 안 된다는 것입니다. LOT가 있으면 채굴자는 변경 사항을 무시할 여유가 없게 되고, 사용자 요구에 따라 적극적으로 행동해야 할 것입니다. 또한, 비트코인 코어 자체가 LOT에 대한 신호를 제공하지 않으면, 다른 누군가가 코드를 포크하여 옵션을 활성화하고 많은 사용자(노드 운영자)가 포크된 소프트웨어로 이동할 것이라고 합니다. 이러한 시나리오는 SegWit 활성화 과정에서 배운 바와 같이 매우 가능성이 높으며, 위험한 체인 분할을 더욱 가능하게 만들 것입니다.
어떤 접근 방식이 결국 채택될지는 여전히 불확실하며, 양측의 개발자들이 자신의 주장을 강하게 고수하고 있습니다. 그러나 비트코인 코어에 어떤 선택이 최종적으로 남더라도, 그것이 네트워크로서 비트코인에 대해 어떤 의미에서든 “구속력”이 없다는 점을 강조할 가치가 있습니다. 비트코인 코어는 네트워크와 상호작용하기 위한 코드의 구현일 뿐이며, 위에서 언급했듯이, 누구나 코드를 복사하고 해당 설정을 변경하여 사용자에게 문제에 대한 다른 선택을 제공할 수 있습니다.
이러한 이유로, 노드를 운영하는 모든 사람이 논의를 이해하려고 노력하는 것이 매우 중요합니다. 코어 개발자의 결정은 항상 추천에 불과하며, 최종 결정은 각 노드 운영자와 그들이 거래를 검증하는 코드에 의해 이루어집니다.
Taproot 활성화 프로세스와 계획된 일정에 대한 후속 정보를 보려면 비트코인 위키의 지정된 페이지를 확인하십시오.
이 글은 Ben Kaufman의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하지는 않습니다.
