이 글은 비트코인 분야의 자가 교육을 받은 교육자이자 기술 중심의 비트코인 팟캐스트 호스트인 신노비의 의견 기고입니다.
2022년 10월 9일, 비트매트릭스의 부락(리퀴드 네트워크에 구축된 스왑 도구)은 998-999 임계값을 가진 Tapscript 멀티시그로 UTXO를 사용하여 메인 비트코인 네트워크에 트랜잭션을 생성하고 방송했습니다. 이 트랜잭션은 증인 필드에 998개의 개별 서명이 있었고, 크기는 거의 0.1MB였으며, 재미있게도 999명의 모든 참가자에게 동일한 공개 키를 재사용했습니다. 이 트랜잭션은 LND와 btcd(비트코인 네트워크의 대체 클라이언트)에서 버그를 노출시켜 라이트닝 네트워크에 큰 혼란을 일으켰습니다.
이 트랜잭션을 생성한 전체 목적은 Taproot가 가능하게 한 멀티서명 스크립트의 향상된 확장성을 보여주는 것이었습니다. Schnorr 서명 기반의 MuSig 프로토콜을 사용하지 않더라도, Taproot는 이전 버전의 비트코인 스크립트보다 훨씬 더 큰 멀티시그 참가자 집합을 가능하게 합니다. 비트코인 스크립트를 사용하여 멀티시그를 구성할 수 있는 모든 가능한 방법을 깊이 파고들면 이전의 크기 제한에 대한 논의가 다소 복잡해질 수 있으므로, 간단함을 위해 P2SH(스크립트 해시로 지불) 및 P2WSH(증인 스크립트 해시로 지불) 멀티시그 구성에 적용되는 이전 한계에 대해서만 논의하겠습니다. P2SH 멀티시그를 수행하는 표준 방법의 경우, 참가자의 최대 크기 제한은 15명에 불과하며, 표준 P2WSH 멀티시그의 경우 최대 크기는 20명입니다. 이러한 제한은 이러한 다양한 스크립트 작업을 사용할 때 스크립트의 크기에 허용되는 크기와 단일 스크립트의 범위 내에서 수행할 수 있는 처리 작업의 수에 대한 제한 때문입니다. 이러한 제한 중 하나라도 위반하면 트랜잭션이 무효가 됩니다.
Taproot의 구현으로 이러한 스크립트 크기 제한이 완전히 제거되었으며, Taproot 스크립트 크기의 유일한 제한은 블록 크기 제한 자체입니다. 여기서 LND와 btcd와 관련된 문제가 발생합니다. btcd에서 구현된 합의 규칙은 스크립트 크기와 관련된 이러한 제한을 올바르게 제거했지만, 문제는 피어 투 피어 통신을 위한 코드베이스가 노드 운영자를 위한 이중 방어층을 추가하기 위해 스크립트 크기에 대한 검사를 구현했다는 것입니다. 블록과 트랜잭션은 실제 검증을 수행하는 핵심 합의 코드에 도달하기 전에 일종의 “사전 합의” 합의 검증을 거치게 되며, 이중 검증이 무효 블록이나 트랜잭션에 대한 추가 방어층을 추가한다는 논리가 있습니다. 이 코드는 스크립트 크기 제한을 제거하기 위해 적절하게 업데이트되지 않아 Taproot 트랜잭션에 대해 SegWit의 이전 스크립트 제한을 계속 적용했습니다. 따라서 실제 합의 코드 자체는 이 매우 큰 Taproot 트랜잭션을 올바르게 검증했지만, 이를 포함하는 블록은 피어 투 피어 검증에서 실제 합의 검증 논리로 전달되지 않았으며, 그 결과 모든 btcd 노드는 부락의 트랜잭션을 포함하는 블록에서 정체되었습니다.
많은 사람들이 LND 인스턴스 아래에서 비트코인 코어를 실행하는데, 왜 이 문제가 LND에 영향을 미쳤을까요? 이는 LND가 블록을 수신하고 처리하기 위해 btcd와 동일한 코드를 사용하기 때문입니다. 따라서 비트코인 코어 위에서 실행되는 LND 노드가 관련 블록을 올바르게 검증하고 정체되지 않았더라도, LND 인스턴스는 해당 블록을 수용하지 않고 정체되었으며, 주 체인 노드는 계속해서 정상적으로 진행되었습니다.
이 버그는 매우 빠르게 패치되었으며, 내가 아는 한 해를 초래하는 방식으로 적극적으로 악용되지는 않았지만, 이는 외부 감시탑을 사용하지 않는 한 라이트닝 네트워크의 모든 LND 노드를 채널에서 자금 도난의 잠재적 위험에 노출시켰습니다. 노드가 해당 블록에서 정체되어 있었기 때문에 블록체인에 대한 실시간 뷰를 가지지 못했고, 채널 상대방이 블록체인에 오래된 채널 상태를 제출한 경우 이를 전혀 인지하지 못하고 사용자의 자금을 보호하기 위한 적절한 페널티 트랜잭션으로 대응할 수 없었습니다. 이는 매우 심각한 버그로, 사용자가 수동으로 노드를 패치하고 업데이트하거나 채널을 개인적으로 모니터링하여 구식 상태로 종료될 경우 수동으로 대응할 수 있는 경우가 아니면 라이트닝 네트워크의 비트코인 상당 부분이 도난 위험에 처하게 했습니다. 비기술적 노드 운영자의 대다수는 아마도 그렇게 할 수 없었을 것입니다.
다행히 이 문제는 널리 악용되지 않았지만, 만약 부락의 트랜잭션이 블록체인에 푸시되기 전에 코드베이스에서 발견되었다면, 이는 악의적인 행위자들에 의해 매우 전술적으로 악용될 수 있었을 것입니다. 개인 또는 그룹은 네트워크에서 많은 수의 채널을 쉽게 열고, 잠수 스왑을 통해 해당 채널의 모든 자금을 자신에게 다시 스왑한 다음, 부락이 한 것처럼 대규모 Taproot 트랜잭션을 제출하여 구식 상태를 사용하여 즉시 채널을 종료할 수 있었습니다. 피해자는 이를 인지하지 못할 것이며, 만약 인지하더라도 많은 노드 운영자의 상대적으로 낮은 기술적 능력으로 인해 대부분의 사람들이 페널티 트랜잭션으로 문제를 수동으로 수정하는 데 제때 대응할 수 없었을 가능성이 매우 높습니다.
이 버그는 고려해야 할 두 가지 중요한 문제를 강조합니다. 첫째, 비트코인 노드의 여러 독립적인 구현은 매우 위험할 수 있습니다. 다행히도 거의 아무도 btcd를 심각한 용도로 노드로 실행하지 않으므로, 이로 인해 기본 비트코인 네트워크에 미친 영향은 무시할 수 있는 것이었으며, 단지 몇몇 개인의 노드가 정체된 것에 불과했습니다. 만약 채굴자들이 btcd를 실행하고 있었다면, 이는 비트코인 네트워크에서 체인 분할을 초래할 수 있었으며, 모든 btcd 운영자가 수동 개입이 필요한 소수 체인으로 이동하게 되었을 것입니다. 두 번째 문제는 주요 네트워크 위의 두 번째 레이어의 경우, 합의 검증 구현이 매우 신중하게 이루어져야 한다는 것입니다. 이는 까다로운 문제입니다. 왜냐하면 비트코인 전체 노드 위에서 실행되는 모든 라이트닝 노드가 이 검증을 100% 아웃소싱할 수 있지만, 모든 라이트닝 노드가 자신의 신뢰할 수 있는 전체 노드를 사용하지는 않기 때문입니다. 이는 바뀔 가능성이 낮습니다. 많은 사용자가 여전히 그렇게 노드를 운영할 가능성이 높기 때문에, 어느 정도는 비트코인 합의 규칙의 일부 또는 전부에 대한 검증이 라이트닝 구현에서도 지원되어야 합니다.
앞으로 이 문제는 이 공간의 소프트웨어 간에 합의 검증 검사가 모두 동기화되어 있는 것이 얼마나 중요한지를 일깨우는 계기가 되기를 바랍니다. 모든 것이 동기화되지 않으면 실제로 일관된 비트코인 네트워크가 존재하지 않기 때문입니다. 이로 인해 전체 네트워크에서 대규모 악용이 발생하지 않은 것에 대해 모두가 매우 기뻐해야 하지만, 만약 상황이 이렇게 진행되지 않았다면 이 문제가 얼마나 심각할 수 있었는지 인식해야 합니다.
이 글은 신노비의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 비트코인 매거진의 의견을 반드시 반영하지는 않습니다.
