저자: 앙투안 푸앵소
출처: https://bitcoinmagazine.com/print/the-core-issue-consensus-cleanup
비트코인의 미래에 대해 프로토콜 개발자들은 일반적으로 대부분의 비트코인 사용자들보다 비관적인 견해를 가지고 있습니다. 비트코인의 불완전한 점들을 매일 접하면서 더욱 냉철한 시각을 갖게 된 것은 당연하지만, 이는 비트코인의 성과를 반영하는 것이기도 합니다. 인종, 나이, 성별, 국적 등 그 어떤 기준에도 구애받지 않고 전 세계 누구든 중립적인 화폐 네트워크에서 가치를 저장하고 전송할 수 있으며, 이 네트워크는 나날이 성장하고 있습니다. 하지만 비트코인에는 여전히 많은 비트코인 사용자들이 미처 알아차리지 못한 문제점들이 존재하며, 이러한 문제점들이 제대로 해결되지 않으면 비트코인의 미래를 위협할 수 있습니다. "합의 정리(Consensus Cleanup)"에서 수정된 취약점들이 바로 그러한 문제점 중 하나입니다.
"합의 규칙 정리"(BIP 54 1 )는 비트코인 합의 프로토콜의 오랜 취약점을 수정하기 위한 소프트 포크 제안입니다. 이 저널(비트코인 매거진의 "코어 특집호")에서 다루는 대부분의 Bitcoin Core 개발 작업과는 달리, 이는 소프트 포크 제안입니다. 이 제안은 역사적으로 Bitcoin Core 프로젝트에 참여하는 여러 개발자들이 주도해 왔지만, 실제로는 "비트코인 프로토콜 개발"이라는 더 넓은 범주에 속합니다.
이 글에서는 본 제안에 포함된 네 가지 개선 방안을 소개하고, 각 방안이 해결하고자 하는 문제점, 그 영향, 그리고 개선 조치의 결과를 설명합니다. 또한, 피드백을 반영하고 새롭게 발견된 취약점을 해결함으로써 이러한 개선 방안들이 어떻게 구체화되었는지 설명합니다. 마지막으로, 본 소프트 포크 제안의 현재 진행 상황을 개괄적으로 제시합니다.
비트코인 작업증명 메커니즘의 취약점
비트코인 네트워크는 채굴 난이도를 조정하여 평균 10분마다 새로운 블록 하나를 생성하는 채굴 속도를 유지합니다. 그러나 이 난이도 조정 메커니즘 구현에는 "일회성 오류"(흔히 발생하는 프로그래밍 오류)가 있어 "시간 왜곡 공격"이라는 취약점이 존재합니다. 즉 , 채굴 해시레이트 의 대부분을 장악한 채굴자들이 난이도를 낮춰 블록 생성 속도를 임의로 높일 수 있는 것입니다.
다행히 이 공격은 채굴 해시레이트 의 51% 이상을 장악해야만 가능하지만, 블록 생성 속도를 임의로 높이는 것은 치명적인 결함입니다. 이는 풀 노드가 더 이상 자원 사용을 통제할 수 없게 되고, 공격자가 비트코인 블록 보너스(새로운 화폐) 배포 속도를 크게 높일 수 있음을 의미합니다.
이 공격은 "채굴자의 51%"만 필요로 하지만, 비트코인이 직면한 일반적인 위협 모델과는 상당히 다릅니다. 전통적인 "51% 공격"은 단일 채굴자가 (해시레이트 우위를 유지하는 경우) 거래 확인을 막을 수 있도록 합니다. 그러나 이 취약점을 이용하면 공격자는 채굴 난이도를 급격히 낮춰 38일 이내에 전체 네트워크를 마비시킬 수 있습니다.
하지만 공격자들은 네트워크 전체를 마비시키지 않고, 오히려 이 취약점을 소규모로 악용할 수도 있습니다. 현재 채굴자들이 담합하여 블록 생성 속도를 네 배로 늘려(2.5분마다 블록 하나씩 채굴) 비트코인 네트워크가 정상적으로 작동하는 것처럼 보이게 할 수 있습니다. 본질적으로 이는 사용 가능한 블록 공간을 네 배로 늘리고 미래 채굴자들의 블록 생성 보조금을 가로채는 결과를 초래합니다. 단기적으로는 블록 공간이 많아지면 블록체인 내 거래 수수료가 낮아지기 때문에(다른 조건이 동일하다고 가정할 때) 이러한 공격을 지지할 유인이 생길 수 있습니다. 물론 이는 전체 노드 운영에 부담을 주고 네트워크의 장기적인 안정성을 저해하는 결과를 낳습니다.
타임워프 공격은 난이도 조정 주기가 겹치지 않는다는 점을 악용합니다. 따라서 새로운 주기의 블록 타임스탬프를 이전 주기의 마지막 블록 타임스탬프보다 더 빠르게 설정할 수 있습니다. 난이도 조정 주기가 겹치면 하드 포크 발생하므로, 최선의 절충안은 난이도 조정 주기 경계에 있는 블록들의 타임스탬프를 서로 연관시키는 것입니다. BIP 54는 난이도 조정 주기의 첫 번째 블록 타임스탬프가 이전 주기의 마지막 블록 타임스탬프보다 2시간 이상 빠를 수 없다고 규정합니다.
또한, BIP 54는 난이도 조정 주기가 반드시 양의 분 단위 시간(분)을 가져야 한다고 규정합니다. 즉, 난이도 조정 주기 내에서 마지막 블록의 타임스탬프는 첫 번째 블록의 타임스탬프보다 빠를 수 없습니다. 비트코인에 이 규칙이 없었다는 사실이 놀랍지 않으신가요? 저희도 이 규칙이 필요하다는 사실에 놀랐습니다. 실제로 이는 개발자 "Zawy"와 Mark "Murch" Erhardt가 합의 규칙 정리 제안을 검토하는 과정에서 발견한 시간 왜곡 관련 교묘한 공격에 대한 간단한 해결책이었습니다.
확인하는 데 몇 시간이 걸리는 블록
채굴자들은 까다로운 검증 작업을 악용하여 검증에 매우 오랜 시간이 걸리는 블록을 생성할 수 있습니다. 일반적인 비트코인 블록은 100밀리초 정도면 검증이 완료되지만, 이러한 "공격 블록"은 고성능 컴퓨터에서도 10분 이상, 라즈베리 파이(풀 노드를 실행하는 데 일반적으로 사용되는 하드웨어)에서는 10시간 이상 걸릴 수 있습니다.
악의적인 공격자는 이 공격을 이용하여 전체 네트워크를 파괴할 수 있습니다. 반면, 경제적으로 더 유리한 경우, 채굴자는 이 공격을 이용하여 경쟁자의 채굴을 지연시키고, 자신의 수익을 늘리고, 네트워크 붕괴가 전체로 확산되는 것을 막을 수 있습니다.
역사적으로 이 문제를 해결하려는 시도는 비트코인의 스크립팅 기능에 제한을 두어야 했기 때문에 많은 어려움을 겪었습니다. 이러한 제한은 잠재적으로 "권리 박탈"로 이어질 수 있으므로, 진지한 소프트 포크 설계에서는 절대적으로 피해야 합니다.
(역자 주: 여기서 언급된 "압수"는 해당 스크립트의 특정 용도가 비활성화됨에 따라 스크립트에 포함된 동전을 더 이상 사용할 수 없게 된 것을 의미합니다.)
맷 코랄로가 2019년에 처음 제안한 "대규모 합의 정리(Great Consensus Cleanup)"는 검증 시간 문제를 해결하기 위해 분리된 증인(Segregated Witness) 스크립트가 아닌 스크립트(흔히 "레거시 스크립트"라고 함)에서 특정 드문 연산을 비활성화하는 방안을 제시했습니다. 일각에서는 이러한 연산을 사용하는 거래가 기본 Bitcoin Core 구성에서는 수년 동안 전달되거나 채굴되지 않았지만, 일부 사용자가 특정 위치에서 이를 몰래 사용하고 있을 가능성을 우려하고 있습니다. 물론 이러한 리스크 단일 채굴자가 이 취약점을 악용하여 모든 비트코인 사용자에게 미칠 수 있는 리스크 과 비교하여 신중하게 고려해야 합니다.
몰수에 대한 이러한 우려는 거의 전적으로 이론적인 것이지만, 동시에 철학적인 질문이기도 합니다. 즉, 비트코인 프로토콜 개발 과정에서 취약점을 해결하면서 몰수 가능성을 최소화하는 적절한 완화 조치를 어떻게 설계해야 하는가 하는 문제입니다. 제가 나중에 합의 규칙 정리 제안을 개선하면서 이러한 우려를 해소하기 위해 특정 비트코인 스크립트 작업을 비활성화하지 않으면서도 유해한 행위를 정확하게 정의하는 제한을 추가했습니다.
위조된 지불 증거
비트코인 블록 헤더에는 블록 내의 모든 거래를 확정하는 머클 루트가 포함되어 있습니다. 이를 통해 특정 작업증명(Proof-of-Work)을 통해 블록체인에서 거래가 확정되었다는 간결한 증거를 생성할 수 있습니다. 이를 일반적으로 "SPV 증거"라고 부릅니다.
하지만 머클 트리의 설계 결함으로 인해, 블록에 정교하게 조작된 64바이트 거래가 포함되어 있을 경우 공격자는 가짜(존재하지 않는) 거래에 대한 SPV 증거를 위조할 수 있습니다. 이는 SPV 검증자(일반적으로 하위 시스템으로 들어오는 지불이나 예금을 검증하는 데 사용됨)를 속이는 데 사용될 수 있습니다. 검증자가 이러한 잘못된 증거를 거부할 수 있도록 하는 완화 조치가 존재하지만, 암호학자조차 간과하는 경우가 많아 특정 상황에서 문제가 될 수 있습니다.
합의 규칙 정리 제안은 합의 규칙 내에서 직렬화 크기가 정확히 64바이트인 트랜잭션을 비활성화함으로써 이 문제를 해결합니다. 이러한 트랜잭션은 본질적으로 안전하지 않으며(자금을 소진하거나 누구나 사용할 수 있음), 2019년부터 Bitcoin Core 기본 설정은 이러한 트랜잭션의 전달 및 채굴을 중단했습니다. 기존 완화 조치를 개선하는 등의 다른 접근 방식도 논의되었지만, 제안 작성자들은 문제의 근본 원인을 해결하는 방식 을 택하여 소프트웨어 개발자가 완화 조치를 과시하거나 취약점을 인지할 필요성을 없애기로 했습니다.
참고 a: 머클 트리의 깊이는 블록 헤더의 버전 번호 필드에 기록됩니다.
UTXO 클론: 중복 트랜잭션
"소규모...중규모...대규모 인플레이션 - 과열된 경제"는 러셀 오코너가 2012년 2월에 발표한 블로그 게시물의 제목이었습니다. 이 게시물에서 그는 비트코인 거래 중복 가능성에 대해 논했습니다. 이는 한때 비트코인의 치명적인 결함이었으며, 거래 식별자(해시 값)가 고유하다는 기본 가정을 깨뜨렸습니다. 이 문제는 채굴자의 코인베이스 거래에 빈 입력값이 하나만 존재한다는 사실에서 비롯되었습니다. 즉, 동일한 출력값을 가진 모든 코인베이스 거래는 정확히 동일한 거래 식별자를 갖게 된다는 의미였습니다.
(역자 주: 코인베이스 거래는 블록의 첫 번째 거래로, 블록을 생성한 채굴자가 거래 수수료와 블록 보상을 받을 수 있도록 하는 데 사용됩니다. UTXO를 사용하지 않고도 수행할 수 있습니다.)
당시 Bitcoin Core (당시에는 "비트코인"이라고 불렸음) 개발자들은 BIP 30 2 를 통해 이 취약점을 수정했는데, 이는 풀 노드가 블록을 수신할 때 추가 검증을 수행하도록 요구하는 것이었습니다. 하지만 이 추가 검증은 필수적인 것은 아니었고, 같은 해에 구현된 BIP 34 3 에서 우회되었습니다. 불행히도 BIP 34의 수정은 완벽하지 않았고, 20년이 지난 지금 우리는 BIP 30 검증을 다시 도입해야 할 필요성을 느끼게 되었습니다. 이 검증 조치는 필수적인 것도 아닐 뿐더러, Utreexo와 같은 대안 비트코인 클라이언트에서는 실행될 수 없으며, 실제로 블록체인을 완전히 검증하는 것을 방해할 것입니다.
합의 규칙 정리 제안은 보다 안정적이고 오랜 기간 검증된 해결책을 통합합니다. 코인베이스 거래를 포함한 모든 비트코인 거래에는 거래의 "유효일"을 결정하는 필드가 있습니다. 이 필드의 값은 거래가 무효로 간주되기 직전의 마지막 블록 높이를 나타냅니다. BIP 54는 모든 코인베이스 거래가 이 필드를 해당 블록 높이에서 1을 뺀 값으로 설정해야 한다고 규정합니다.
앤서니 타운스의 현명한 제안, 즉 타임락 검증이 항상 실행되도록 하는 것과 결합하면 이전 블록의 코인베이스 거래가 동일한 타임락 값을 사용할 수 없게 됩니다. 결과적으로 두 코인베이스 거래가 동일한 거래 식별자(해시 값)를 갖지 않게 되므로 BIP 30 검증이 필요 없어집니다.
예방이 치료보다 낫다
합의 규칙 정리(BIP 54)에서 다루는 취약점들은 비트코인에 당장 심각한 위협이 되지는 않습니다. 일부 취약점은 네트워크 전체를 마비시킬 가능성이 있지만, 현재로서는 악용될 가능성은 낮습니다. 그럼에도 불구하고 상황은 언제든 변할 수 있으므로, 단기적으로 소프트 포크 조정하는 부담이 따르더라도 비트코인 네트워크의 장기적인 리스크 사전에 완화하는 것은 매우 중요합니다.
합의 규칙 정리 제안에 대한 작업은 2019년 맷 코랄로(Matt Corallo)의 최초 제안에서 시작되었습니다. 6년 후, BIP 54가 공개되고 비트코인 합의 규칙 변경 테스트넷인 비트코인 인퀴지션(Bitcoin Inquisition)의 소프트 포크 구현과 함께 이 제안이 마침내 결실을 맺었습니다. 이 기간 동안 제안은 대량 피드백을 받았으며, 여러 대안을 논의하고 다른 약점들을 보완하는 조치를 추가했습니다. 이제 비트코인 사용자들과 공유할 준비가 되었다고 생각합니다.
합의 규칙 정리 작업은 소프트 포크 입니다. 비트코인 프로토콜 개발자들은 어떤 개선 사항을 먼저 구현하고 공개할지 선택합니다. 하지만 비트코인 합의 규칙 변경 사항을 채택할지 여부에 대한 최종 결정은 사용자에게 달려 있습니다. 선택은 여러분의 몫입니다.
(위에)
참고 자료
1. https://github.com/bitcoin/bips/blob/master/bip-0054.md
2. https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
3. https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
