분리된 증인(Segregated Witness, BIP 141)과 Taproot (BIPs by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns)는 비트코인 프로토콜에 대한 두 가지 가장 큰 변화입니다.
전자는 비트코인 거래의 구조를 근본적으로 변경하였고, 그 과정에서 비트코인 블록도 이전 거래 구조의 고유한 한계를 해결하기 위해 변경되었습니다. 후자는 비트코인의 스크립팅 언어의 일부 측면을 재구성하고, 복잡한 스크립트가 어떻게 구조화되고 검증되는지를 변경하며, 암호화 서명을 생성하기 위한 새로운 방식을 도입했습니다.
이는 CHECKTIMELOCKVERIFY (CLTV)와 같은 단일 연산 코드를 추가하는 것과 비교할 때 거대한 변화입니다. CLTV는 수신자가 특정 시간 동안 자신의 코인이 이동하지 않도록 선택할 수 있게 해주는 것 외에는 아무것도 하지 않습니다.
이러한 변화는 비트코인 시스템의 매우 현실적인 단점과 한계를 해결하기 위해 이루어졌습니다. 비트코인은 전 세계적으로 비트코인의 전체 상태, 즉 모든 미사용 코인에 대한 합의를 유지하기 위한 기초적인 층으로서, 매우 귀중하고 훌륭한 혁신입니다. 그러나 그 코인으로 직접 거래를 가능하게 하는 수단으로는 매우 불충분합니다.
분리된 증인과 Taproot가 활성화된 이후 몇 년이 지나면서 그들이 해결한 많은 단점들이 잊혀졌습니다. 디자인 결정의 이유와 논리는 시간이 지나면서 왜곡되었습니다.
이 두 가지 비트코인 프로토콜 변경은 각각 큰 문제에 대한 해결책이었지만, 또한 다른 문제를 해결하거나 미래의 개선을 위한 기초를 마련했습니다.
이러한 변화가 활성화된 이후 많은 새로운 사람들이 네트워크에 합류한 시점에서, 디자인 선택을 다시 살펴보고 맥락을 이해하는 것이 중요합니다.
분리된 증인(Segregated Witness, BIP 141)
비트코인 거래가 코인을 사용할 때, 그것은 코인을 생성한 거래의 출력 인덱스와 거래 ID(TXID)를 참조합니다. 이는 거래의 입력이 고유하게 식별될 수 있도록 보장하며, 절대적으로 확실하게 이전에 사용된 적이 없음을 검증할 수 있습니다.
분리된 증인 이전의 거래 구조는 다음과 같았습니다:
[버전] [입력] [출력] [잠금 시간]
TXID는 이 데이터의 해시입니다. 문제는 거래가 유효하다는 것을 증명하는 ScriptSig(서명, 해시 프리이미지 등)가 입력의 일부라는 것입니다. ScriptSig의 작은 프로그램 지침을 변경하거나 심지어 암호화 서명 자체를 변경할 수 있지만, 이를 무효화하지는 않습니다.
이러한 “변형”은 TXID를 변경합니다. 이는 사전 서명된 거래에 큰 문제입니다.
라이트닝 네트워크, Ark, Spark, BitVM, 비밀 로그 계약(DLC) 등 모든 이러한 확장 도구는 사전 서명된 거래에 의존합니다. 이들은 서명되지 않은 자금 거래를 생성하고, 자금 거래를 서명하고 확인하기 전에 적절한 실행과 자금의 안전을 보장하는 모든 거래를 사전 서명해야 합니다. 모든 이러한 시스템은 이중 지출에 대한 안전을 보장하기 위해 다중 서명 인증을 사용합니다(이는 나중에 중요합니다).
만약 그 자금 거래가 변형되고, 블록에서 확인되기 전에 그 거래 ID가 변경된다면, 모든 사전 서명된 거래가 무효화됩니다. 네트워크를 통해 전파되는 동안 누군가가 자금 TXID를 변경할 수 있는 환경에서는 이러한 도구가 작동하지 않습니다.
분리된 증인은 입력의 ScriptSig 대신 정의되지 않은 연산 코드를 일종의 블라인딩 커튼으로 사용하고, 모든 데이터를 “증인”이라는 새로운 거래 필드로 이동시킵니다. 새로운 거래 구조는 다음과 같습니다:
[버전] [마커/플래그] [입력] [출력] [증인] [잠금 시간]
입력의 “블라인딩 커튼”은 오래된 노드가 기본적으로 그 뒤의 모든 것을 유효한 것으로 표시할 수 있게 하며, 새로운 노드는 실제로 적절한 검증 논리를 적용할 수 있게 합니다. 이제 전통적인 TXID는 증인의 ScriptSig 데이터를 변경해도 더 이상 변경되지 않습니다. 이는 사전 서명된 거래에 대한 문제를 해결하고, 오늘날 그것들을 사용하는 모든 확장 솔루션의 문을 열었습니다.
그러나 블록 헤더의 거래 머클 트리는 거래의 전통적인 TXID에만 커밋되므로 문제가 발생합니다. 블록에는 어떤 증인 데이터에 대한 커밋도 없습니다. 이는 증인 커밋과 증인 거래 ID(WTXID)를 요구합니다. 일반 TXID의 머클 트리가 구성되는 방식과 유사하게, 각 거래의 WTXID 트리가 구성되고 코인베이스 거래의 증인에 커밋됩니다.
유일한 차이점은 트리의 루트가 예약 값으로 해시되고, 그것이 코인베이스 증인에 포함된다는 것입니다. 이는 그 값이 미래에 합의 규칙의 다른 새로운 데이터 필드에 커밋하는 데 사용될 수 있도록 합니다. 이 증인 트리 커밋의 발명 이전에는, 분리된 증인이 거래 구조 변경과 블록 헤더에 별도의 증인 커밋이 필요하기 때문에 하드포크가 필요할 것이라고 가정되었습니다.
“블라인딩 커튼” 디자인은 또한 모든 새로운 데이터가 무시되고 이를 지원하지 않는 노드에 의해 검증되지 않기 때문에 스크립팅 시스템에 대한 임의의 업그레이드를 허용합니다. 이는 새로운 스크립트 시스템이 기존 스크립트 시스템의 모든 제약을 우회할 수 있게 합니다. 여기에서 업그레이드 경로의 유연성은 슈노르 서명이 통합될 수 있게 했으며, 필요하다면 양자 저항 서명을 허용할 것입니다(양자 저항 공개 키는 일반적으로 기존 520바이트 데이터 항목 한계보다 크며, 서명도 마찬가지입니다).
분리된 증인은 비트코인을 더 많은 사용자에게 제공할 수 있는 확장 가능한 두 번째 레이어의 개발을 저해했던 거래 ID 변형의 근본적인 문제를 해결했지만, 또한 이러한 두 번째 레이어를 지원하고 개선하는 데 필요한 스크립팅 개선을 위한 기초를 마련했습니다.
슈노르 서명
슈노르 서명은 1991년 클라우스 슈노르에 의해 발명되었으며, 즉시 특허를 받았습니다. 사실, ECDSA 서명 방식은 슈노르 서명에 대한 특허 때문에 발명되었습니다. 슈노르 서명에 대한 특허는 비트코인 네트워크가 시작된 지 1년 조금 넘은 2010년 2월에 만료되었습니다.
특허가 없었다면, 사토시(그리고 나머지 세계)는 처음부터 슈노르 서명을 사용했을 가능성이 높습니다.
슈노르 서명이 ECDSA에 비해 몇 가지 주요 이점을 가지고 있습니다:
- 슈노르 서명은 증명 가능하게 안전합니다. 슈노르 서명이 위조 불가능하다는 수학적 증명은 ECDSA보다 훨씬 강력하며, 더 적은 가정을 합니다. 비트코인의 핵심에 있는 암호화에 대해 더 강력한 보안 보장을 갖는 것은 분명히 큰 긍정적입니다.
- 슈노르 서명은 본질적으로 변형 불가능하므로, 서명을 무효화하지 않고 변경할 수 있는 ECDSA의 문제는 슈노르 서명에서는 불가능합니다.
- 슈노르 서명은 단순하고 효율적인 가법 키 구성, 분산 키 생성 및 분산 서명 생성을 허용하는 선형성을 가지고 있습니다. 이를 통해 사용자는 개별 슈노르 공개 키를 간단히 “더할” 수 있으며, 해당 집합 공개 키에 대한 서명을 그룹으로 생성할 수 있습니다.
그들은 더 안전하고, 제3자에 의해 변형되지 않으며, 다중 서명 인증을 개선하기 위한 모든 종류의 효율적이고 유연한 암호화 계획의 문을 엽니다.
이전에 거래 변형에 대해 논의할 때, 사전 서명된 거래를 사용하여 오프체인에서 구축하는 모든 것이 사용자 자금을 보호하기 위해 다중 서명 인증에 의존한다고 언급했습니다. 이는 자금의 공유 제어에 있어 암묵적인 확장 한계를 생성했습니다. 기존 다중 서명은 그만큼 클 수 없습니다. 거래 크기 제한이 있으며, 버전 0(분리된 증인) 증인에는 증인 크기 제한이 있습니다. 다중 서명 주소에는 최대 15명의 참가자만 있을 수 있었으며, 분리된 증인 이후 최대 크기는 20명의 참가자였습니다.
슈노르 기반 다중 서명 계획은 각 구성원 키를 개별적으로 포함하는 스크립트를 구성하는 대신, 공개 키를 단일 그룹 공개 키로 집계하여 이 한계를 벗어납니다. 분리된 증인 이전에는 다중 서명 주소에 최대 15명의 참가자만 있을 수 있었지만, 분리된 증인 이후 최대 크기는 20명이었습니다.
MuSig 및 FROST와 같은 슈노르 기반 다중 서명 계획에서는 이러한 제한이 존재하지 않으며, 적어도 합의 수준에서는 그렇습니다. 다중 서명 스크립트는 사용자가 원할 만큼 클 수 있으며, 선택한 크기 내에서 서명 프로세스를 조정하는 것이 실용적이라면 중단이나 참여 거부 없이 가능합니다.
이러한 키 집계를 가능하게 하는 동일한 속성은 효율적인 적응 서명도 가능하게 하며, 이는 누군가가 비밀 정보가 공개될 때까지 유효하지 않은 서명을 생성할 수 있게 해줍니다. 이러한 속성은 서명자가 볼 수 없는 메시지에 대한 서명을 생성하기 위한 제로 지식 증명 기반 계획도 가능하게 합니다.
탭루트
탭루트는 머클화된 추상 구문 트리(Merkelized Abstract Syntax Trees, MAST)라는 오래된 개념의 진화로, 이는 Pay-to-script-hash(P2SH)의 일종의 확장입니다. P2SH는 두 가지 주요 문제를 해결하기 위해 처음 만들어졌습니다:
- 큰 사용자 정의 스크립트를 사용할 때, 결과적으로 미사용 출력이 더 커져 UTXO 세트에 저장하는 데 더 많은 공간이 필요합니다.
- 큰 사용자 정의 스크립트를 사용할 때, 발신자는 거래의 지불 출력이 더 커지므로 더 높은 수수료를 지불하게 되어, 사람들이 더 안전한 사용자 정의 스크립트에 대해 더 많은 비용을 지불하는 것을 단념하게 만듭니다.
출력에 전체 스크립트를 명시적으로 포함하는 대신, 해당 스크립트의 해시를 포함하고, 사용 시 수신자는 해시에 대해 검증하기 위해 지출되는 입력에서 전체 스크립트를 제공해야 합니다. 이는 미사용 출력 저장 공간 문제를 해결하고, 더 큰 스크립트를 사용하는 비용을 자금을 보내는 사람에게 전가합니다.
하지만 여전히 문제가 남아 있습니다. 사용자 정의 스크립트는 여러 가지 방법으로 지출할 수 있지만, 사용 시 사용자는 여전히 코인이 실제로 지출되는 조건을 검증하는 데 필요하지 않은 스크립트 분기를 포함하여 전체 스크립트를 공개해야 합니다. 이는 공간 효율성이 매우 떨어지며, 지출하는 사용자에게 불필요한 높은 비용을 초래합니다.
MAST의 아이디어는 다중 분기 스크립트에서 각 개별 지출 조건을 분리하고, 각 개별 지출 경로의 머클 트리를 구성하는 것입니다. 각 경로는 해시되고, 그 머클 트리의 루트가 사용자의 주소가 됩니다. 사용 시 사용자는 자신이 사용하는 지출 경로와 함께 그것이 트리의 리프임을 증명하는 머클 증명과 해당 스크립트를 충족하는 데 필요한 데이터를 제공하면 됩니다.
이 머클 트리 구조는 P2SH와 동일한 문제를 해결하며, MAST 사용자의 지출 비용을 최적화합니다(그리고 그들의 프라이버시도 개선합니다!).
탭루트는 이 개념을 더 프라이버시를 보호하는 방식으로 통합하여 슈노르 서명의 선형 속성을 활용합니다. 사람들이 구축하고자 하는 대부분의 계약 유형은 낙관적인 결과를 가질 것이며, 두 사용자가 자금을 분배하는 방법에 대해 단순히 동의합니다. 이러한 경우 그들은 거래에 서명할 수 있습니다. 탭루트는 MAST 루트를 가져와 슈노르 공개 키를 “조정”하여 새로운 공개 키를 생성합니다. 동일한 MAST 루트로 개인 키를 “조정”하면 새로운 공개 키에 해당하는 개인 키에 도달합니다.
이제 사용자는 조정된 키를 사용하여 출력을 간단히 지출할 수 있으며, MAST 트리가 존재한다는 흔적을 남기지 않거나, 실제로 사용하는 지출 경로와 함께 원래 공개 키와 MAST 루트를 공개할 수 있습니다. 또한 키 경로를 포함하지 않으려면, 일반 공개 키 대신 증명할 수 없는 특별한 NUMS(내 손에 아무것도 없다) 값을 사용할 수 있으며, 이는 유효한 지출 경로로서 오직 MAST 스크립트만 남게 됩니다.
분리된 증인의 디자인 선택을 활용하여, 탭루트는 또한 새로운 스크립팅 시스템인 탭스크립트를 도입했습니다. 여기에서 주요 변경 사항은 OP_CHECKMULTISIG와 OP_CHECKMULTISIGVERIFY를 비활성화하는 것입니다. 이들은 여러 서명을 더 효율적으로 검증할 수 있는 OP_CHECKSIGADD로 대체됩니다. 이는 슈노르 키 집계와 결합되어 기존 스크립트와 동일한 다중 서명 기능을 허용합니다.
탭스크립트는 또한 OP_CHECKSIG와 OP_CHECKSIGVERIFY를 수정하여 슈노르 서명과만 작동하도록 하고, OP_NOP(기존 스크립트의 정의되지 않은 연산 코드)의 대체로 OP_SUCCESS를 도입합니다. OP_SUCCESS는 OP_NOP보다 더 깨끗하고 안전한 연산 코드 업그레이드를 허용하도록 설계되었습니다.
증인 한계
지금까지 논의되지 않은 두 가지 측면이 있습니다. 분리된 증인에서 도입된 블록 가중치 한계와 탭루트에서 증인 크기 한계 증가입니다.
이 두 가지 결정은 생태계 내에서 매우 활동적인 소수의 파워 사용자들 사이에서 논란의 여지가 되었습니다. 블록 가중치 한계를 도입할 때의 블록 크기 증가에 대해서는 논의하지 않겠습니다. 이는 당시 하드포크 블록 크기 증가를 요구하는 반대 사용자들과의 타협이었으며, 당시 네트워크 참가자들에 의해 안전하다고 여겨졌습니다. 그러나 증인 할인 동적 자체는 중요합니다.
비트코인 거래 수수료는 거래의 데이터 양에 기반합니다. 이는 전송되는 가치의 양과는 관계가 없습니다. 이는 오직 입력과 출력(및 증인)의 수와 그들이 차지하는 바이트 수에 따라 결정됩니다. 앞서 분리된 증인 이전에 ScriptSig, 즉 서명 및 기타 데이터가 거래 입력에 포함되었다고 언급했습니다. 이는 출력에 포함되지 않은 입력에 포함된 많은 양의 데이터입니다.
이는 입력이 출력보다 더 비쌉니다라는 것을 의미하며, 그 차이는 상당합니다. 이는 사용자가 많은 작은 출력을 수집하고 지출하는 것보다 큰 출출을 지출하고 새로운 변경 출출을 생성하는 것을 선호하도록 장기적인 인센티브를 만듭니다. 이는 모든 완전 검증 노드에 필요한 UTXO 세트를 지속적으로 성장시키도록 유도하는 장기적인 경제적 인센티브입니다.
증인 할인은 그 가격 차이를 수정하기 위해 설계되었으며, 이를 미세하게 만들어줍니다. 이는 경제적으로 합리적인 사용자들이 단순히 거래를 할 때 책임 있는 UTXO 관리를 경제적으로 유도하는 데 매우 중요합니다.
탭루트는 거래의 증인 필드에 대한 기존 크기 제한을 제거했습니다. 분리된 증인에서 그 제한은 10,000 바이트였습니다. 이는 탭루트의 설계가 검증하기 비싼 거래의 잠재적 구성을 완화했기 때문에 이루어졌으며, 탭스크립트에서 이러한 제한을 도입하려고 하면 Miniscript에서 큰 복잡성을 초래했습니다. 이러한 제한이 존재했던 문제는 탭루트에 영향을 미치지 않았으며, 개발자와 사용자 모두에게 사용자 정의 스크립트를 더 안전하고 접근 가능하게 만들기 위한 도구에 복잡성을 도입했습니다.
큰 그림
비트코인에 대한 이 두 가지 변화는 더 많은 사람들이 자산을 자가 관리하는 방식으로 사용할 수 있도록 하는 데 있어 거대한 장애물을 제거했지만, 프로토콜의 기본 부분에 대해 유사하게 거대한 변화를 필요로 했습니다.
이제 이러한 디자인 선택과 그 뒤에 있는 논리를 이전에 잘 알지 못했던 독자들이 그들이 설계된 주의와 미래를 내다보는 사고를 이해할 수 있기를 바랍니다. 비트코인은 놀라운 혁신이며, 정말 그렇지만, 인구의 상당한 비율에 가까운 혜택을 제공할 수는 없습니다.
분리된 증인과 탭루트는 비트코인의 확장성 부족을 해결하기 위해 시도하는 데 절대적으로 필요한 두 개의 초석을 놓았습니다. 이 두 가지 제안이나 동일한 문제를 해결하는 대체 프로토콜 변경이 없었다면, 오늘날 우리가 가지고 있는 모든 확장성 레이어와 시스템은 존재하지 않았을 것입니다.
라이트닝, Ark, Spark, BitVM, DLC – 이들 중 어느 것도 구축할 수 없었을 것입니다.
이것이 큰 그림입니다. 오늘날의 비트코인은 완벽하지 않지만, 실제로 의미 있는 그룹의 사람들에게 확장할 수 있는 좋은 기회를 가지고 있으며, 탈퇴를 원하는 사람들에게 진정한 대안을 제공할 수 있습니다. 이는 이 두 가지 프로토콜 업그레이드와 그들이 제거한 매우 근본적인 장벽 덕분입니다.
기회를 놓치지 마세요 핵심 문제 — 많은 핵심 개발자들이 자신이 작업하는 프로젝트를 설명하는 기사를 포함하고 있습니다!
이 글은 최신 인쇄판 비트코인 매거진, 핵심 문제에 실린 편집자의 편지입니다. 전체 호에서 탐구된 아이디어를 미리 살펴보는 것입니다.
[1] https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
[2] https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
[4] https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
[5] https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki
[6] https://github.com/siv2r/bip-frost-signing
[7] https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
[8] https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
