저자: Gabe Parker, Galaxy 분석가; 번역: 진써차이징(Jinse) xiaozou

요약

• 비트코인은 프로토콜 업그레이드에 보수적인 접근 방식을 취하므로 합의 변경은 비교적 드뭅니다. 하지만 이전 SegWit과 Taproot 업그레이드에서 보여졌듯이 개발자들은 비트코인의 프로그래밍 언어와 네트워크 매개변수를 최적화하려는 의지를 여전히 가지고 있습니다.

• 비트코인의 프로그래밍 언어인 비트코인 ​​스크립트는 거래에서 글로벌 상태를 전달하거나 내성 기능을 갖도록 할 수 없으므로 표현력이 제한됩니다.

• 현재 두 가지 주요 제안이 있는데, OP_CAT(BIP 347) 와 OP_CTV(BIP 119) 입니다. 이는 거래 출력에 더 많은 지출 조건을 부여하여 비트코인 ​​거래의 프로그래밍성을 향상시키는 것을 목표로 합니다. 이러한 제안은 비트코인 ​​스크립트의 기능을 크게 향상시켜 더욱 유연하게 만들 수 있습니다.

• OP_CAT 및 OP_CTV의 가장 유망한 적용 시나리오는 다음과 같습니다 : 비트코인의 첫 번째 계층(L1)과 두 번째 계층(L2) 사이에 신뢰할 필요가 없는 크로스 체인 브리지를 구축하고, 고급 자체 보관 볼트 솔루션을 개선하고, 라이트닝 네트워크를 개선하는 것입니다.

• 소프트 포크 업그레이드에 대한 거버넌스 프로세스에는 여러 비트코인 ​​이해 관계자가 참여합니다. 프로토콜 아이디어와 기술 검토의 초기 단계에서는 미디어 인플루언서와 핵심 개발자가 가장 큰 영향력을 행사합니다.

• 갤럭시 리서치는 비트코인 ​​핵심 개발자들이 2025년에 OP_CAT 또는 OP_CTV에 대한 합의에 도달할 것으로 예측하지만, 활성화 프로세스의 복잡성으로 인해 실제 구현에는 1~2년이 걸릴 수 있습니다.

1. 서론

비트코인 프로토콜을 변경하려면 프로토콜 개발자, 전체 노드, 최종 사용자, 채굴자 등을 포함하되 이에 국한되지 않는 여러 이해 관계자 간의 논의와 협업이 필요합니다. 프로토콜 업그레이드를 달성하기 위한 합의 프로세스는 복잡하고 논란의 여지가 있습니다. 예를 들어, 2015~2017년의 "블록 크기 전쟁"은 비트코인 ​​커뮤니티를 분열시켰는데, 한 쪽은 블록 크기를 조정하기를 원했고 다른 쪽은 반대했습니다. 수년간의 논쟁 끝에 블록체인이 영구적으로 포크 되고 비트코인의 포크 버전인 새로운 암호화폐인 비트코인 ​​캐시가 탄생했습니다.

프로토콜 변경에 대한 합의에 도달하기 어렵기 때문에 비트코인의 주요 업그레이드는 드뭅니다. 비트코인 프로토콜 개발자들은 논란이 되는 업그레이드를 거부해 온 오랜 역사를 가지고 있으며, 더 광범위한 비트코인 ​​커뮤니티의 지지를 받은 업그레이드를 구현하는 데는 수년이 걸렸습니다. 이는 예측 가능성, 네트워크 충실성 및 이전 버전과의 호환성을 촉진하기 위해 비트코인 ​​개발에 보수적인 접근 방식을 취하려는 개발자들의 노력을 강조합니다.

비트코인에서 합의 변경이 발생하는 경우는 비교적 드물지만, 비트코인 ​​개발자들은 비트코인 ​​스크립트와 네트워크 매개변수를 최적화하려는 개방적인 태도를 보였습니다. 블록 크기에 대한 논쟁에서 나온 분리된 증인(SegWit) 업그레이드는 실제로 블록 크기 제한을 늘려 블록에 포함할 수 있는 거래 수가 늘어났습니다. SegWit은 또한 거래 데이터의 측정 단위를 바이트에서 가상 바이트(vbytes)로 변경하여 거래 데이터의 형식을 최적화합니다. 이러한 변화와 함께, 서명 데이터를 증인 필드로 옮기면 비트코인 ​​블록이 최대 4m개의 가중치 단위의 거래 데이터(약 4MB)를 담을 수 있게 됩니다. 비트코인의 마지막 소프트 포크 2021년 Taproot 업그레이드였으며, Tapscript라는 업데이트된 스크립팅 언어를 도입했습니다. 이 새로운 버전의 비트코인 ​​스크립트에는 새로운 서명 방식(슈노르 서명)과 개선된 키 집계 기능이 포함되어 있으며, 여러 개의 공개 키와 서명을 단일 서명 키로 결합합니다. Schnorr 서명을 위한 키 집계는 여러 서명이 필요한 거래 데이터의 양을 줄이는 동시에 Lightning Network(비트코인의 가장 큰 P2P 지불 계층으로 비트코인 ​​기본 계층 위에 구축됨)에서 거래의 개인 정보 보호를 향상시킵니다. SegWit과 Taproot에 대한 이 간략한 개요는 비트코인 ​​개발자들이 비트코인 ​​합의의 변화에 ​​신중한 반면, 비트코인의 기술적 특징이 변하지 않을 것이라는 의미는 아니라는 것을 보여줍니다.

SegWit과 Taproot 이후, 비트코인 ​​개발자들은 이제 비트코인의 거래 프로그래밍 가능성을 높여 거래에 스마트 계약 로직을 추가하는 방안을 모색하고 있습니다. 비트코인 스마트 계약은 지출 조건을 사용하는 것을 포함하는데, 이는 미래에 지출되지 않은 거래 출력(UTXO)을 어떻게 지출할 수 있는지 제한하고 제어할 수 있는 기능입니다. 더 복잡하고 엄격한 지출 제약 조건을 "계약"("제한" 또는 "계약")이라고 합니다. 이 글에서는 먼저 비트코인 ​​스크립트를 살펴보고 이것이 비트코인의 UTXO 회계 모델과 어떻게 작동하는지 알아보겠습니다. 이어서, 보류 중인 두 가지 명령어인 OP_CTV와 OP_CAT을 분석하여 이러한 명령어가 효율적인 거래 프로그래밍을 가능하게 하는 강력한 기능을 포함하도록 Bitcoin 스크립트를 개선할 수 있는 잠재력이 있는 방법을 알아보겠습니다. 마지막으로 이 논문에서는 브리지와 에스크로와 같은 비트코인 ​​인프라에 대한 거래 프로그래밍성의 중요성을 강조하고, OP_CAT과 OP_CTV에 대한 합의 가능성과 이러한 명령어를 다음 소프트 포크 업그레이드에 구현하는 경로를 살펴봅니다.

2. 비트코인 ​​스크립트와 UTXO 모델

비트코인은 "비트코인 스크립트"라는 기본 스크립팅 언어를 사용하여 거래를 구성합니다. 스크립트는 수신자가 전송되는 비트코인을 어떻게 사용할 수 있는지 정의하는 일련의 지침으로 구성되며, 이를 "지출 조건"이라고도 합니다. 비트코인 스크립트는 명령 기능으로 실행되는 186개의 명령어로 구성됩니다. 이러한 명령어는 비트코인 ​​자산을 네트워크에서 사용하고 전송하는 방법에 대한 공식 규칙을 만드는 데 사용됩니다. 예를 들어, Pay-to-PubKey 해시 거래에는 비트코인 ​​거래에 대한 지출 조건을 적용하는 4개의 명령어가 포함되어 있습니다. 여기서 비트코인은 해시된 공개 키로 지출되고 지출자와 연결된 올바른 공개 키와 개인 키를 사용해서만 지출될 수 있습니다.

비트코인 스크립트는 입력과 출력을 사용하는 비트코인의 사용되지 않은 거래 출력(UTXO 모델)을 위해 설계되었습니다. 모든 비트코인 ​​거래는 최소한 1개의 입력과 1개의 출력으로 구성되지만, 대부분의 간단한 거래는 최소한 1개의 입력과 2개의 출력으로 구성됩니다(입력 측의 BTC 일부는 거래 자금을 조달하는 데 사용되고, 일부는 수신자에게 전송되고, 나머지는 출력 측의 지출자에게 반환됩니다). UTXO는 아직 사용되지 않은 비트코인의 일부이며 향후 거래에 사용될 수 있습니다. UTXO가 거래의 입력으로 사용되면 더 이상 출력이 되지 않습니다. 따라서 사용자가 비트코인을 사용하면 UTXO가 지속적으로 생성되고 소거됩니다. 다음은 UTXO 모델의 간단한 예입니다.

*앨리스가 지갑에 1BTC 상당의 UTXO를 가지고 있고 밥에게 0.5BTC를 보냈다면 앨리스의 입력은 1BTC가 됩니다. *그녀가 출력하는 금액은 0.49 BTC(앨리스에게 반환)와 0.5 BTC(밥에게 전송)입니다. 0.01 BTC 차이는 거래 수수료로 지불된 BTC를 나타냅니다(이 거래 수수료는 네트워크 혼잡도에 따라 달라집니다). *이 거래가 끝나면 앨리스는 남은 0.49 BTC를 나타내는 새로운 UTXO 세트를 갖게 됩니다. 1단계에서 앨리스는 1 BTC 상당의 UTXO를 거래의 첫 번째 입력으로 사용하여 UTXO를 파기합니다. 2단계에서 앨리스는 0.5 BTC와 0.49 BTC의 가치가 있는 두 개의 새로운 UTXO를 생성하는데, 하나는 거스름돈으로 그녀에게 반환되고, 다른 하나는 밥에게 지불됩니다. 3단계에서 앨리스는 이제 0.49 BTC 상당의 새로운 UTXO를 갖게 됩니다. 앨리스가 밥에게 0.5 BTC를 지불해야 하는 경우, 앨리스는 1단계에서 여러 개의 UTXO를 사용하여 총 0.5 BTC를 지불할 수 있습니다. 입력 UTXO가 수신자에게 모두 전달되지 않은 경우, 앨리스는 1개 대신 새로운 UTXO 2개를 받을 수 있습니다. UTXO 모델은 비트코인 ​​네트워크의 핵심 특징이며, 거래 처리 및 검증에 중요한 역할을 합니다.

위의 UTXO 예는 전적으로 Bitcoin Script를 사용하여 구축되었습니다. 각 UTXO에는 잠금 스크립트가 포함되어 있으며, 여기에는 UTXO를 사용할 수 있는 조건 집합이 포함됩니다. 사용자가 해당 공개 키와 연관된 올바른 개인 키 서명을 제공하여 입력(사용 중인 UTXO)의 소유권을 증명하면 UTXO의 잠금 스크립트가 잠금 해제됩니다. 이 정보를 "스크립트 서명"이라고 하며, 올바른 스크립트 서명이 입력에 포함되면 지출 조건이 충족되고 비트코인을 지출할 수 있습니다. 앨리스와 밥의 UTXO 예로 돌아가면, 1단계에서 앨리스는 UTXO를 사용하기 위해 자신의 입력에 대한 개인 키 서명을 제공해야 합니다. 이후 밥은 새로 받은 0.5 BTC를 사용하기 전에 동일한 정보를 제공해야 합니다.

비트코인의 스크립팅 언어에는 여러 서명을 요구하거나 특정 블록 높이에서 비트코인을 잠금 해제하는 등 더 복잡한 지출 조건이 포함될 수 있습니다. 그러나 Bitcoin Script는 범용적이지 않으며 이더 의 기본 프로그래밍 언어인 Solidity의 표현력이 부족합니다. 따라서 비트코인 ​​스크립트를 사용해 브리지 및 보관 솔루션을 위한 스마트 계약 로직을 프로그래밍하는 것은 매우 어렵습니다.

3. 2025년까지 비트코인 ​​스크립트가 직면한 장애물

비트코인 스크립트는 지난 16년 동안 사용자에게 유용성과 더블 스펜딩 공격 대한 회복성을 입증했지만, 이 스크립팅 언어는 표현력 및 전역 상태를 저장하는 기능과 같은 범용 기능이 부족합니다. 비트코인 스크립트는 스택 기반 프로그래밍 언어이기 때문에 큰 숫자에 대한 곱셈과 산술 연산을 수행할 수 없으므로 표현력이 부족합니다. 비트코인 스크립트는 32비트 크기의 값에 대해서만 사소하지 않은 계산을 수행할 수 있습니다. 따라서 비트코인 ​​스크립트는 32비트보다 큰 스택 요소를 서로 분리합니다. 이 32비트 제한은 현재의 명령어 집합이 처리할 수 있는 것보다 더 큰 스크립트 크기를 필요로 하는 암호화 함수, 곱셈 및 나눗셈을 사용하는 계산 집약적 명령을 격리합니다. 여러 개의 명령어를 사용하여 산술과 곱셈을 에뮬레이트하는 것은 가능하지만, 이를 위해서는 많은 스택 요소가 필요하며, Bitcoin Script의 스택 크기는 1000개의 요소로 제한됩니다. 따라서 현재 운영을 넘어서는 거래 출력에 대한 복잡한 지출 조건을 만드는 것은 어렵습니다.

비트코인 스크립트의 가장 큰 한계는 이 언어가 지출자가 제공한 입력만 읽을 수 있기 때문에 거래 데이터를 읽고 쓰고 저장할 수 없다는 것입니다. 프로그래밍 언어가 글로벌 상태를 저장할 수 없으면 스크립트는 애플리케이션이나 브리지의 계좌 잔액 독립적으로 확인할 수 없습니다. 비트코인 스크립트 로직은 글로벌 상태에 접근할 수 없습니다. 모든 상태 데이터는 단일 거래에 맞아야 하기 때문입니다. 따라서 L2 네트워크와 비트코인 ​​기본 계층 사이에 일반 기능을 개발하거나 신뢰할 수 없는 브리지를 구축하는 것은 거의 불가능합니다.

비트코인 스크립트의 한계를 극복하기 위한 이니셔티브는 2020년부터 진행되어 왔습니다. 수년간 개발자들 사이에서는 비트코인 ​​스크립트의 표현력을 높이는 유일한 방법은 소프트 포크 업그레이드를 수행하고 계약을 활성화하는 새로운 명령어를 구현하는 것이라는 의견의 일치가 있었습니다. 비트코인 커뮤니티의 한 부분은 이러한 업그레이드가 비트코인 ​​네트워크에 리스크 초래한다고 믿는 반면, 다른 부분은 비트코인의 사용 사례를 확장하기 위해 비트코인에 더 많은 프로그래밍 기능이 필요하다고 믿습니다. 비트코인의 거래 프로그래밍성을 개선하는 데 가장 적합한 명령어가 무엇인지에 대한 실질적인 진전은 없었지만, 현재 언약 지지자들은 OP_CTV와 OP_CAT가 비트코인의 거래 프로그래밍성을 개선하기 위한 주요 비트코인 ​​개선 제안(BIP)이라는 데 대부분 동의하고 있습니다. 비트코인에서 계약을 구현하는 데에는 두 가지 이상의 솔루션이 있다는 것을 알고 있지만, 이 글에서는 가장 대표적인 두 가지 제안인 OP_CTV와 OP_CAT만 설명하겠습니다.

4. BIP 119(OP_CTV)

비트코인 개선 제안 119(BIP 119)는 CHECK-TEMPLATE-VERIFY(CTV)로도 알려져 있으며, 비트코인 ​​코어 개발자 제레미 루빈이 2020년 1월에 제안한 제안입니다. 이 제안은 비트코인 ​​거래 출력에 대해 계약이라고 알려진 일반 지출 조건을 적용할 수 있는 새로운 명령어 OP_CTV를 도입합니다. 간단한 배경 소개는 다음과 같습니다. “CHECK_TEMPLATE_VERIFY”의 템플릿 부분은 비트코인 ​​스크립트를 작성할 때 따라야 하는 거래 형식을 나타냅니다. CHECK-TEMPLATE-VERIFY는 거래 출력의 잠금 스크립트가 잠금 스크립트에 해시로 저장된 지출 조건을 커밋할 수 있도록 하는 새로운 기능입니다. 커밋 해시라고도 합니다. 따라서 거래 출력은 커밋 해시에 자세히 설명된 조건이 충족되는 경우에만 잠금 해제될 수 있습니다. 일단 온체인 브로드캐스트되면 거래와 관련된 커밋먼트 해시는 변경할 수 없습니다. OP_CTV의 이점은 거래 발신자가 수신자에게 지출 조건을 부과할 수 있다는 것입니다. 이는 발신자에 대한 지출 조건만 구성할 수 있는 현재 Bitcoin Script 규칙에 큰 변화를 가져온 것입니다.

언약에는 두 가지 주요 유형이 있습니다. 일반 계약은 복사되어 여러 UTXO에 적용될 수 있습니다. UTXO가 사용된 후에는 계약이 만료되지 않습니다. 반면, 미리 계산된 계약도 복제가 가능하지만 제한된 사전 정의된 횟수만큼만 복제할 수 있습니다. 미리 계산된 계약의 논리는 발신자가 사전에 지정해야 하며, 지출 조건을 무한히 복제할 수 없다는 점에서 일반 계약과 다릅니다. 일반 계약은 재귀적 계약이라고도 하며 UTXO의 대체성에 리스크 초래할 수 있습니다. 따라서 BIP 119 지지자들은 일반적으로 미리 계산된 계약을 사용하는 OP_CTV 사용 사례에만 초점을 맞추고 있으며, BIP 119가 일반 계약을 지원하지 않는 이유입니다. 예를 들어, 일반 계약이 활성화되면 보관 기관이나 비트코인 ​​거래소 영구적인 지출 조건을 적용하여 인출을 처리할 수 있으며, 이러한 비트코인은 정부나 기타 기관의 검열 가능성을 피할 수 없습니다.

5. BIP 119를 사용하여 계약 배포

볼트 솔루션을 예로 들면, OP_CTV 함수가 계약을 구현하는 방식은 다음과 같습니다.

앨리스는 자신의 1 BTC UTXO 중 0.8 BTC를 밥과 찰리에게(각각 0.4 BTC) 향후 10년 동안 지출하고자 합니다. 앨리스는 또한 약 0.2 BTC에 해당하는 잔돈을 새로운 금고로 보내고 싶어하는데, 이 금고는 BTC를 10년 더 보관해 둡니다.

1단계: 앨리스는 자신의 UTXO 상당 1 BTC를 밥과 찰리에게 사용하고, 잠금 스크립트에는 밥과 찰리가 525,000 블록 이후에 BTC를 사용할 수 있다는 내용이 자세히 나와 있습니다. 이는 약 10년 후입니다. 앨리스는 또한 그녀의 잔돈 약 0.2 BTC가 그녀가 소유한 금고 주소로 전송되고, 그녀의 UTXO 525k 블록, 즉 약 10년 후가 잠길 것이라는 자세한 지시를 포함시켰습니다.

2단계: 밥과 찰리는 525,000 블록 이후 각자의 UTXO인 0.4 BTC를 사용합니다. 앨리스가 설정한 잠금 스크립트는 커밋 해시를 현재 블록 높이와 비교하여 확인하고, 조건이 충족되면 밥과 찰리는 새로운 UTXO를 사용할 수 있습니다.

2단계에서 Bob과 Charlie가 UTXO를 사용한 후, "잠금 스크립트"라고도 하는 Bitcoin 스크립트의 일부가 지출 조건의 충족 여부를 확인하여 BTC를 출금하기 전에 모든 조건이 충족되는지 확인합니다. 이 작업은 올바른 스크립트 서명을 사용하여 비트코인 ​​출력을 "잠금 해제"하는 것으로 종종 불립니다. 조건이 충족되지 않으면 잠금 스크립트가 BTC 전송을 시작하지 않습니다.

3단계: 찰리와 밥이 잠금 스크립트에서 커밋 해시를 충족한 후, 앨리스에게 반환된 UTXO는 변경 사항(약 0.2 BTC)으로 지정 볼트 스크립트 공개 키가 있는 주소의 입력으로 사용됩니다. 볼트 스크립트 공개 키에는 앨리스가 약 0.2 BTC 상당의 UTXO를 사용하기 위해 525,000 블록 이후에 볼트를 잠금 해제할 수 있는 해시가 포함되어 있습니다. 볼트 체계를 사용하는 이점은 앨리스가 해시에 세부적인 보안 조치를 추가할 수 있다는 것입니다. 예를 들어, 누군가가 그녀의 개인 키를 훔쳐 525k 블록 시간 잠금 전에 UTXO를 잠금 해제하려고 시도하는 경우에 대비해 비밀 복구 주소와 같은 보안 조치를 추가할 수 있습니다.

계약이 없다면 이전 예에서 앨리스는 밥과 찰리에게 지출하는 BTC에 대한 향후 지출 조건을 강제하기 위해 미리 서명된 거래를 생성해야 합니다. 사전 서명된 거래는 보낸 사람의 개인 키로 미리 서명된 하나 또는 여러 개의 거래일 수 있지만, 실제로는 확인 및 실행을 위해 네트워크에 브로드캐스트되지 않습니다. 사전 서명된 거래는 사용자가 온체인 실행될 때까지 여러 거래에 대한 데이터를 저장해야 하기 때문에 확장이 불가능합니다. 또한, 사전 서명된 거래의 경우 자금을 지출하기 전에 서명 당사자 모두 간의 상호작용이 필요합니다. 그러나 OP_CTV를 통해 커밋 해시를 사용하여 계약을 구현하면 사용자가 사전 서명된 거래 데이터를 저장할 필요성이 사라지고 거래에 참여하는 모든 당사자 간의 상호 작용에 의존할 수 있습니다.

대체로 이 기능은 다양하고 정교하고 보안성이 뛰어나며 복원력이 뛰어난 호스팅 및 보안 설계를 만드는 데 사용할 수 있으며, 셀프 호스팅 또는 관리형 설정을 개선하고, 혁신적인 새로운 쿼럼이나 업무 계정 설정을 만들거나, 투명성과 안정성이 더 높은 자율 실행 체계를 만드는 데 도움이 됩니다.

6. BIP 347(OP_CAT)

BIP 347은 2023년 10월 이선 하일만과 아민 사부리가 작성한 또 다른 비트코인 ​​개선 제안으로, 비트코인 ​​거래 출력에 미리 계산된 지출 조건을 적용할 수 있게 해줍니다. 이 제안은 비트코인 ​​스크립팅 언어에 OP_CAT 명령어를 추가하는 것을 제안하는데, 이 기능을 통해 비트코인 ​​개발자는 스택에서 두 데이터 포인트를 "결합"하고 해당 값을 스택 맨 위에 배치할 수 있습니다. 간단한 배경 소개를 살펴보겠습니다. "연결"은 두 개 이상의 코드 문자열을 더 큰 바이트 또는 데이터 문자열로 결합하는 프로세스입니다. Bitcoin Script는 각 코드 문자열을 순차적으로 평가하는 스택 기반 프로그래밍 언어입니다. 5줄의 코드로 구성된 스택의 경우, Bitcoin Script는 먼저 1줄을 평가하고 마지막으로 5줄을 평가합니다. 불행히도 비트코인의 스크립팅 언어에는 개발자가 스택 전체에서 여러 코드 문자열을 병합할 수 있는 명령어가 포함되어 있지 않습니다. 현재 비트코인 ​​스크립트에는 산술 및 곱셈 기능이 없어 비트코인 ​​스크립트를 압축하는 기능이 제한되어 있으며, 단일 스택에서 대규모 스크립트(32비트 초과)와 소규모 스크립트(32비트 미만)의 상호 작용이 제한됩니다. "연결"을 통해 스크립트를 압축하고 대규모 스크립트가 소규모 스크립트와 통신할 수 있는 기능이 없다면 거래 출력에 대한 복잡한 지출 조건을 구현할 수 없습니다.

가장 중요한 점은, 스택 맨 위에 있는 Bitcoin Script의 연결된 요소들이 산술 및 곱셈 함수를 에뮬레이션할 수 있으므로 오류가 발생하기 쉬운 길고 데이터 집약적인 스크립트를 작성하지 않고도 복잡한 스크립트를 작성할 수 있다는 것입니다. 또한, OP_CAT의 연결 기능을 통해 개발자는 Tapscript에서 Merkle 트리 및 기타 해시된 데이터 구조를 사용하여 지출 조건을 생성할 수 있습니다. Tapscript는 2021년 11월에 활성화될 Taproot 업그레이드 세트의 일부로 새로운 거래 유형을 활성화하는 데 사용되는 기본 스크립팅 언어입니다.

특히, 사토시 나카모토 비트코인 ​​스크립트가 스크립트 내에서 복잡한 수학 연산을 직접 수행할 수 있도록 하는 OP_CAT 및 기타 명령어를 비활성화했습니다. 사토시 나카모토 모토는 OP_CAT을 삭제했습니다. 당시 비트코인 ​​스크립트 제한이 2000바이트였기 때문에 이 명령어를 OP_DUP와 결합하여 데이터 집약적 스크립트를 구성할 수 있었기 때문입니다. 이 크기의 스크립트는 비트코인 ​​노드의 컴퓨팅 리소스에 부담을 주고 과부하를 일으킬 수 있습니다. 그러나 Taproot 업그레이드는 2021년에 Taproot 스크립트에 520바이트의 크기 제한을 도입했기 때문에 OP_CAT은 더 이상 노드 운영자에게 과도한 컴퓨팅 오버헤드를 발생시키지 않습니다.

7. BIP 347(OP_CAT)을 사용하여 계약 배포

2021년 Taproot 업그레이드에서는 Bitcoin 스크립트 언어에 Schnorr 서명이 도입됩니다. 슈노르 서명은 공개 키와 개인 키 집계를 지원하여 여러 당사자가 단일 서명으로 거래에 공동으로 서명할 수 있습니다. Schnorr 서명에 포함된 검증 명령어를 OP_CAT와 결합하면 트랜잭션 해시를 생성하는 비재귀적 계약이 생성됩니다. OP_CAT를 통해 사용자는 보내는 주소나 보내는 금액 등 거래의 특정 부분을 잠금 해제 스크립트에 대한 요구 사항으로 제한할 수 있으며, 거래 해시는 잠금 해제의 키 역할을 합니다.

볼트 솔루션을 예로 들면, OP_CAT 함수가 계약을 구현하는 방법에 대한 일반적인 개요는 다음과 같습니다. 이 예제의 기술적 세부 사항은 이 글의 범위를 벗어납니다.

앨리스는 100블록 이후 UTXO를 잠금 해제하는 볼트를 생성하려고 합니다.

*1단계: 앨리스는 자신의 UTXO를 볼트 주소로 사용하고, 블록 높이를 포함하여 볼트 잠금 해제 스크립트의 지출 조건 세부 정보를 증인 필드에 포함합니다.

*2단계: Alice의 거래에서 OP_CAT은 Witness 필드의 볼트 잠금 해제 지침을 연결하고 이를 두 번 해시하여 sighash/txhash를 얻습니다.

*3단계: 100개의 블록 확인 후, 앨리스는 볼트 UTXO에 대한 지출 거래를 브로드캐스팅하여 볼트 비트코인을 사용하는 프로세스를 시작합니다. 앨리스가 모든 지출 조건을 충족하는지 확인하기 위해 그녀의 지갑은 백그라운드에서 CheckSig 명령어를 실행합니다. 이 작업은 두 가지 주요 검증을 수행합니다. 초기 설정 거래의 거래 해시를 확인하는 것(1단계)과 이를 현재 지출 거래와 비교하는 것(3단계)입니다. CheckSig 기능은 설정 거래의 구성 요소를 재구성하고 현재 거래의 공개 키 서명을 검증하여 모든 금고 지출 조건이 충족되었는지 확인합니다.

*4단계: 앨리스의 거래 공개 키가 CheckSig에 의해 검증된 후(CheckSig는 증인 필드에 저장된 지출 조건을 재구성함), 앨리스는 자신의 UTXO를 자유롭게 사용할 수 있습니다.

위의 예는 OP_CAT 자체로는 거래에 지출 조건을 적용할 수 없지만, 비트코인 ​​스크립트의 다른 명령어와 OP_CAT을 결합하면 계약을 구현하는 스크립트 작성을 간소화할 수 있음을 보여줍니다. OP_CAT의 유일한 기능은 스택의 상위 두 요소를 연결하는 것입니다.

OP_CAT을 CheckSig와 함께 사용하여 계약을 생성할 수는 있지만 OP_CAT만 추가하면 Bitcoin Script에 Solidity와 같은 기능을 제공할 수 없습니다. 이 제한은 OP_CTV만 추가하는 경우에도 적용됩니다. OP_CAT를 사용하더라도 비트코인 ​​거래는 최소한의 내부 조사만 가능합니다. 즉, 거래는 이전 거래의 요소나 상태에 대한 전체적 접근 권한을 가질 수 없습니다. 따라서 OP_CAT는 Taproot 거래 출력에 대해서만 세분화된 계약만을 지원할 수 있습니다. OP_CAT는 Taproot 출력의 리프 노드를 복구하거나 사용된 내부 키를 확인할 수 없습니다. Taproot 리프는 Taproot 출력에 제출된 단일 지출 조건 또는 스크립트입니다. 이를 비트코인을 사용하는 다양한 "경로" 또는 방법으로 생각해 보세요. 각 리프 노드는 비트코인을 사용할 수 있는 가능한 방법을 나타냅니다. 비트코인 탭루트 거래의 내부 키는 가장 효율적인 지출 경로에 사용되는 주요 공개 키입니다. 내부 키를 사용하여 UTXO를 사용하는 경우 스크립트나 Merkle 경로를 공개하지 않고 온체인 서명만 제공하면 됩니다.

이러한 제한 사항은 OP_TWEAK_VERIFY 및 OP_INTERNALKEY와 같은 다른 명령어 제안을 통해 해결할 수 있다는 점을 알아두는 것이 중요합니다. 전반적으로 OP_CAT는 거래 출력에 대한 복잡한 지출 조건을 생성하는 주요 구성 요소로 볼 수 있지만 CheckSig를 포함한 다른 구성 요소도 비트코인 ​​거래 프로그래밍성 개발을 진행하는 데 중요합니다.

8. Covenants가 비트코인에 가져올 수 있는 주요 기능

(1) 신뢰 없는 브리징 및 일방적 종료

Starkware(이더 의 Starknet zk-rollup을 만든 사람)는 OP_CAT이 신뢰할 수 없는 비트코인 ​​브리지를 위한 STARK 검증자와 Merkle 검증자의 생성을 어떻게 지원할 수 있는지 강조하는 보고서를 발표했습니다. 신뢰할 수 없는 브리지는 머클 트리에 기록된 거래 체인을 통해 브리지 상태를 유지하는 재귀적 계약 시스템을 통해 구성됩니다. 이 메커니즘의 핵심은 사용할 수 없는 OP_RETURN 출력에 저장된 브리지 지속 상태이며, 이 출력에는 계좌 잔액 나타내는 머클 트리의 루트 해시가 포함되어 있습니다. OP_CAT 계약은 모든 새로운 입금 또는 출금 거래에 현재 브리지 상태를 반영하는 유효한 상태 전환이 포함되어야 함을 요구합니다. 사용자는 전문적인 입금 및 출금 계약을 통해 브리지와 상호작용하며, 머클 트리를 사용하여 여러 거래를 일괄 처리하여 효율적으로 검증합니다. 머클 트리의 루트는 메인 브리지 계약에 병합되어 각 입금 또는 출금을 검증하고 처리합니다. 인출 시, 계약은 인출 주소가 리프 거래의 첫 번째 입력 주소와 일치하는지 확인하여 소유권을 확인합니다. 이 설계는 비트코인 ​​스크립트에서 효율적인 상태 업데이트를 위해 Merkle 증명을 활용하여 신뢰할 수 있는 제3자가 필요 없이 OP_CAT가 만든 온체인 계약 로직을 통해 브리지의 상태와 규칙이 완전히 적용되는 신뢰할 수 없는 시스템을 만듭니다. 가장 중요한 점은 신뢰할 수 없는 비트코인 ​​브리지가 최종 시스템 상태 전환을 검증하려면 비트코인 ​​스크립트에 검증 증명이 필요하다는 것입니다. OP_CAT은 해시 데이터를 연결하여 STARK 검증자의 기능을 비트코인 ​​스크립트에 구축하여 UTXO 잠금 스크립트가 최종 시스템 상태 전환의 zk-proofs(영지식 증명)를 검증할 수 있도록 합니다.

Taproot Wizard 팀은 OP_CAT와 BitVM을 결합하는 새로운 신뢰할 수 없는 브리징 프레임 혁신했습니다. BitVM은 임의의 계산을 분할하여 비트코인에서 실행할 수 있도록 하여 튜링 완전한 표현력을 달성합니다. BitVM은 Bitcoin Script를 활용한 임의의 계산 런타임을 Bitcoin의 여러 거래로 분할합니다. 계약 없이 비트코인을 잠그는 BitVM 브리지는 브리지를 설정하기 위해 사전 서명된 거래가 필요합니다. OP_CAT는 이전 거래의 데이터를 전송할 수 있는 기능을 통해 BitVM 브리지가 사전 서명된 거래 없이도 비트코인을 잠그거나 잠금 해제할 수 있습니다. OP_CAT는 "스택의 CAT"라는 트릭을 통해 이전 거래의 데이터를 전달할 수 있습니다. 이 트릭은 스택에 있는 해시된 데이터를 연결하여 OP_CAT이 검증할 수 있는 Merkle 트리 루트를 구축하는 것입니다. 따라서 CatVM 브릿지는 성공적인 출금 후에도 머클 루트가 계속되도록 보장하기 위해 이전 거래, 입금 및 출금의 특정 거래 데이터를 다음 거래에 포함하도록 합니다. 스택 트릭의 CAT는 한 사용자가 인출한 후에 나머지 브리지된 비트코인은 모든 적격 사용자가 인출할 수 있도록 보장합니다.

(2) 고급 금고 보관

Bitcoin Vault는 개인 키가 손상된 경우 사용자가 비밀 주소로 비트코인을 클레임 수 있도록 하는 복구 경로와 같은 보안 기능이 포함된 새로운 보관 솔루션입니다. 공식적으로 OP_VAULT로 알려진 BIP 345는 OP_CTV를 활용하여 비트코인 ​​보관의 보안 매개변수를 강화하는 보류 중인 비트코인 ​​개선 제안입니다. OP_CAT는 사전 서명된 거래 없이도 비트코인 ​​금고의 지출 조건을 생성하는 데 사용될 수 있다는 점도 중요합니다. 비트코인 코어 개발자 제임스 오베른은 OP_CTV의 사용 사례를 좁히기 위해 2023년 1월에 OP_VAULT를 제안했습니다. OP_VAULT는 예금자가 여러 거래에 미리 서명할 필요 없이 보관된 비트코인에 대한 지출 조건을 생성하기 위해 OP_CTV를 사용합니다. 계약에 따라 금고에는 원래 시간 잠금 전에 누군가가 금고에 보관된 비트코인을 쓰려고 시도할 때 발생하는 시간 지연이 발생합니다. 이는 일반적으로 자금을 훔치려는 공격자 때문입니다.

(3) 비모호성 계약

Non-Equivocation 계약은 2015년에 비트코인 ​​네트워크에 도입되었습니다. 이는 서명자가 이중으로 사용할 경우 서명 키가 유출되는 비트코인 ​​거래 출력입니다. 실제로, 사용자들은 기본 비트코인을 삭감 가능한 보증금 으로 잠급니다. 이 보증금 통해 사용자는 기본 계층에서 0-확인 거래를 수행할 수 있으며, 이는 나중에 블록으로 채굴됩니다. 0-확인 거래는 비트코인 ​​합의 규칙에 의해 검증되고 보안이 유지되는 즉각적인 비트코인 ​​거래입니다. 0-확인 거래의 발신자가 거래가 채굴되기 전에 입력 금액을 소비하는 경우, 상대방은 손상된 서명 키로 인해 비트코인 ​​보증금 몰수당할 수 있습니다.

(4) Lightning Network 개선

OP_CAT는 채널 팩토리를 활성화하여 사용자가 비트코인 ​​기본 계층에서 채널 개설 트랜잭션을 먼저 브로드캐스트하지 않고도 Lightning 채널을 열 수 있도록 합니다. 예를 들어, 앨리스가 2개의 라이트닝 채널(하나는 밥과, 다른 하나는 찰리와)을 만들고 싶어하는 경우, 앨리스는 밥과 찰리 모두에게 채널 개설 거래를 브로드캐스트합니다(2개의 거래). 채널 개설 거래에는 양 당사자가 2/2 다중 서명 주소에 비트코인을 입금해야 합니다. 채널 팩토리를 사용하면 Bob과 Charlie는 새로운 채널 개설 트랜잭션을 브로드캐스트하지 않고도 서로 별도의 채널을 개설할 수 있습니다. 따라서 원래 채널 개설 거래에 참여한 모든 참여자는 서로 독립적인 채널을 생성할 수 있습니다.

OP_CTV는 하나의 UTXO가 여러 사용자를 나타내는 공유 UTXO를 생성할 수 있습니다. CTV의 공유 UTXO를 사용하면 여러 사용자가 단일 온체인 거래로 여러 개의 라이트닝 채널을 열 수 있습니다. 일반적으로 각 라이트닝 채널에는 온체인 거래가 필요합니다. 따라서 많은 사용자가 라이트닝 채널을 열면 보류 중인 거래로 메모풀이 가득 차고 거래 수수료가 증가할 수 있습니다. 현재는 문제가 되지 않지만, 수백만 명의 활성 사용자를 유치하기 위해서는 Lightning Network를 지원할 수 있도록 채널 개방을 확장해야 합니다.

9. OP_CAT 및 OP_CTV 관련 리스크

모든 비트코인 ​​소프트 포크 에는 새로운 명령어의 버그나 예상치 못한 사용 사례 등 기술적 리스크 포함됩니다. 전자는 드물지만, 후자는 인스크립션 만드는 과정에서 드러납니다. 인스크립션 거래의 증인 필드에 임의의 데이터를 입력하는 것을 포함하며, 이는 비트코인에서 새로운 토큰과 NFT 컬렉션을 생성하는 데 사용되었습니다. SegWit과 Taproot 업그레이드를 함께 사용하면 사용자가 이미지와 텍스트 데이터를 문자열 데이터로 증인 필드에 입력할 수 있습니다. 디지털 아트와 대체 가능 토큰의 생성이 SegWit이나 Taproot의 활성화 목적이 아니었지만, 수년 후 똑똑한 개발자들이 이러한 업그레이드를 다른 목적으로 사용하는 방법을 알아냈습니다. Galaxy Research는 Ordinals 보고서에서 이러한 관점 강화하면서 SegWit 및 Taproot를 통해 실수로 생성된 인스크립션 커뮤니티가 이러한 새로운 사용 사례에 놀라 새로운 소프트 포크 지원하는 데 더 주저할 수 있으므로 향후 Bitcoin 업그레이드에 부정적인 영향을 미칠 수 있다고 언급했습니다.

비트코인의 업그레이드 능력에 대한 하락 관점 정서 에도 불구하고 OP_CAT과 OP_CTV는 대량 테스트되고 연구되었습니다. 계약에 대한 원래 비판은 정부가 앱에 승인된 주소만 비트코인을 사용할 수 있도록 하는 지출 조건을 시행하도록 강요할 수 있다는 것이었습니다. 이러한 비판은 타당하지 않습니다. 왜냐하면 지출이 발생할 수 있는 조건은 자금을 소유한 사용자에 의해 결정되기 때문입니다. 사용자는 향후 지출을 특정 주소로 제한하는 거래를 생성할 수 있지만, 이러한 제한은 제3자가 외부에서 강제할 수 없으며 잠긴 자금이 지출된 후에는 영구적으로 적용되지 않습니다. 따라서 정부는 자체 호스팅 재무 애플리케이션이나 브리지가 자금을 사용하는 방식을 강제할 수 없습니다. 보관기관과 비트코인 ​​거래소 여전히 사용자의 자금 사용 방법을 제한할 수 있지만, OP_CTV가 허용하지 않는 일반 계약을 시행할 수 없으므로 자금 인출에 대한 영구적인 사용 조건을 추가할 수 없습니다.

전반적으로 OP_CAT와 OP_CTV는 각각 하나의 기능을 매우 잘 수행하는 간단한 명령어입니다. OP_CAT는 스택 맨 위의 두 요소를 연결하는 반면, OP_CTV는 잠금 스크립트에서 지출 조건을 해시할 수 있습니다. 신뢰할 수 없는 브리지 개발과 같은 이러한 명령어의 일부 사용 사례는 브리지가 버그와 해킹에 매우 취약하기 때문에 추가 연구와 현장 테스트가 아직 필요합니다.

10. 다음 소프트 포크 업그레이드를 위한 Covenants 배포 경로

비트코인 이해 관계자의 미래 프로토콜 업그레이드에 대한 합의를 결정하는 것은 제안의 수명 주기 동안 진화하는 복잡한 과정입니다. 이를 BIP(비트코인 개선 제안) 프로세스라고도 합니다. BCAP의 비트코인 ​​업그레이드 역사 보고서는 이러한 이해 관계자의 역할을 다음과 같이 자세히 설명합니다.

* 경제 노드: 거래소, 보관기관, 상인, 지불 제공자

*투자자: 고래, MicroStrategy, ETF 제공업체, Galaxy

*미디어 인플루언서: CoinDesk, Bitcoin Magazine, Celebrity X, 팟캐스터

* 마이너: Bitmain, MicroBT, Riot, Marathon, 대규모 개인 마이너

* 프로토콜 개발자: 비트코인 ​​코어 개발자

*애플리케이션 개발자: L2 프로젝트

비트코인 개선 제안(BIP)의 수명 주기 전체에 걸쳐 다양한 이해관계자가 다양한 정도의 영향력을 행사하며, 소프트 포크 구현하기 위한 합의 구축 과정에서 상대적인 영향력이 변화합니다. 아래는 각 이해관계자의 영향력 수준을 1~10점 순으로 자세히 나타낸 것입니다. 2024년 3월 현재 OP_CAT와 OP_CTV는 프로토콜 구상 단계에 있습니다. 이 단계에서는 미디어 인물이 여론을 조작하고 이야기를 만들어낼 수 있으므로 가장 큰 영향력을 행사합니다. 예를 들어, Taproot Wizards는 유명한 비트코인 ​​인플루언서들로 구성된 팀으로, 방대한 소셜 미디어 팔로워를 활용해 비트코인 ​​커뮤니티에 OP_CAT의 이점을 홍보합니다. Taproot Wizards 팀은 Bitcoin Script에 거래 프로그래밍 기능을 향상시키기 위한 새로운 명령어가 필요하다는 이야기를 전파하기 위해 OP_CAT에 대한 교육 콘텐츠와 연구를 제작해 왔습니다. 그 결과, Taproot Wizards는 OP_CAT를 지지하는 많은 그룹을 만들었고 그들은 핵심 개발자들에게 OP_CAT BIP 초안을 검토하도록 압력을 가하고 있습니다.

비트코인 코어 개발자는 프로토콜 아이디어 단계에서 영향력 면에서 두 번째로 높은 순위를 차지합니다. BIP 편집자는 보류 중인 BIP 초안을 검토할 책임이 있으며, 가장 중요한 점은 BIP를 비트코인 ​​코어 GitHub 저장소에 병합할 수 있는 유일한 개체이기 때문입니다. 비트코인 코어 개발자의 지원 없이는 BIP는 결국 보류되고 거부될 것입니다. 비트코인 코어 개발자는 비트코인 ​​코드베이스를 유지 관리하고 버그가 없는지 확인하는 책임도 있습니다. 비트코인 핵심 개발자들 사이에서 합의에 도달하는 것은 어려운 과정입니다. 핵심 개발자들 사이에서 이념적 관점 다를 수 있고, 각 핵심 개발자가 의사 결정 과정에서 미치는 영향력은 그들의 기여도와 배경에 따라 달라지기 때문입니다.

OP_CAT 및 OP_CTV BIP는 미디어 인플루언서, 사용자, 애플리케이션 개발자가 자신의 영향력을 사용하여 Bitcoin Core 개발자들에게 이러한 합의 변경 사항이 Bitcoin 거래의 프로그래밍 가능성을 높일 것이라고 확신시키는 단계에 있습니다. 합의 여정의 다음 단계에서는 기술 전문가, 애플리케이션 개발자, 핵심 개발자가 OP_CAT 및 OP_CTV의 모든 잠재적 리스크 자세히 설명하기 위해 구체적인 연구가 필요합니다. 특정 연구와 핵심 개발자들과의 공개 대화가 없다면, 더 광범위한 핵심 개발자 커뮤니티에서 OP_CAT과 OP_CTV에 대한 집단적 관점 도출될 수 없을 것입니다.

핵심 개발자들 사이에서 합의가 이루어지면 OP_CAT과 OP_CTV는 BIP를 Bitcoin Core 저장소에 구현하는 마지막 단계를 원활하게 진행할 수석 유지 관리자를 지정해야 합니다. OP_CAT 및 OP_CTV에 대한 BIP가 Bitcoin Core 저장소에 병합된 후에는 활성화 방법을 결정해야 합니다. 활성화 방법이 선택되면 신호 기간이 시작되는데, 이 기간에는 채굴자, 투자자, 경제 노드가 가장 큰 영향력을 행사합니다. 2024년 3월 현재, 채굴자, Microstrategy와 같은 대규모 투자자, Coinbase와 같은 경제 노드는 OP_CAT 및 OP_CTV에 대해 공개적으로 의견을 표명하지 않았습니다. 이러한 이해 관계자들은 BIP를 구현하기 전에 OP_CAT 및 OP_CTV의 리스크 과 이점을 더 잘 이해해야 합니다.

11. BIP 활성화 방법

Bitcoin Core 개발자가 다음 소프트 포크 업그레이드에 OP_CAT 또는 OP_CTV를 포함하는 데 동의하면 커뮤니티는 BIP 활성화 방법에 대해 합의해야 합니다. 활성화 방법을 통해 채굴자는 업그레이드에 대한 준비가 되었음을 알릴 수 있습니다.

대체로 비트코인에서 코드를 변경하는 방법은 두 가지가 있습니다. 첫째, 코드 변경은 소프트 포크 통해 구현될 수 있습니다. 소프트 포크 비트코인 ​​노드 운영자가 클라이언트 소프트웨어를 업그레이드하지 않고도 비트코인 ​​네트워크에서 안전하게 운영할 수 있도록 하는 이전 버전과의 호환성을 갖춘 업그레이드입니다. 소프트 포크 의 또 다른 이점은 이전 버전과의 호환성을 통해 비트코인 ​​코어(주요 비트코인 ​​클라이언트)의 방향에 동의하지 않는 사람이 새로운 BIP 활성화를 제외한 이전 버전의 클라이언트 소프트웨어를 실행하도록 선택할 수 있지만 여전히 정식 비트코인 ​​블록체인에 연결할 수 있다는 것입니다. 소프트 포크 기존 규칙 세트보다 더 제한적인 새로운 조건을 만들어 기능을 추가하여 기존 규칙에 맞춥니다.

소프트 포크 사용자(광부 아님)에 의해 활성화되면 사용자 활성화 소프트 포크(UASF)라고 합니다. 비트코인의 UASF의 가장 유명한 예는 2017년 8월 1일의 "블록 크기 전쟁" 중에 거의 발생했는데, 이는 SegWit 업그레이드 채택을 가속화하는 데 도움이 되었습니다. 블록 크기 분쟁 동안, 비트코인 ​​사용자들은 SegWit 업그레이드를 지원하기 위해 노드를 업그레이드한 뒤, 업그레이드하지 않은 노드의 블록을 거부하겠다고 위협했습니다. 이를 통해 비트코인 ​​클라이언트 소프트웨어를 업그레이드하지 않은 채굴자는 블록을 더 널리 전파하고 블록 보상을 받을 가능성을 높이기 위해 Segwit을 도입하도록 권장됩니다. 블록 크기 전쟁 중에는 UASF가 발생하지 않았지만 잠재적인 UASF 위협으로 인해 채굴자들이 SegWit을 도입하게 되었습니다.

코드 변경을 구현하는 두 번째 방법은 하드 포크 통한 것입니다. 하드 포크는 이전 버전과 호환되지 않는 업그레이드로, 업그레이드된 노드와 업그레이드되지 않은 노드 간의 합의를 영구적으로 분할합니다. 비트코인 코어 개발자들은 커뮤니티가 프로토콜 코드의 강화와 이전 버전과의 호환성을 중요하게 여기기 때문에 하드 포크 구현한 적이 없습니다. 소수의 사용자가 블록 크기를 변경하는 등의 하드 포크 업그레이드를 수행할 경우 비트코인은 체인 분할을 경험할 수 있습니다. 이것이 2017년에 비트코인 ​​커뮤니티 일부가 Segwit 업그레이드에 동의하지 않고 대신 블록 크기를 늘리기 위해 이전 버전과 호환되지 않는 코드 변경을 활성화하여 비트코인 ​​프로토콜에서 포크 를 원했을 때 비트코인 ​​캐시가 만들어진 방식입니다.

포크 와 소프트 포크 활성화를 구분하는 것 외에도 포크 발생하기 전에 업그레이드에 대한 커뮤니티의 정서 측정하는 다양한 방법이 있습니다. 다음은 비트코인 ​​커뮤니티에서 소프트 포크 업그레이드 활성화를 보다 잘 지원하기 위해 제안한 다양한 프로세스 유형 BIP에 대한 개요입니다.

*BIP 9: BIP 9는 채굴자가 비트코인 ​​블록 헤더의 버전 비트 필드를 수정하여 소프트 포크 업그레이드에 대한 지지를 표시할 수 있는 프레임 제공합니다. 신호 기간이 끝나면 비트코인 ​​커뮤니티는 업그레이드를 지지하는 채굴자의 비율을 평가하고 채굴자 해시레이트 에 따라 가중치를 두고 투표할 수 있습니다. 특정 지원 임계값을 초과하면 업그레이드는 "플래그 데이"에 활성화로 진행될 수 있습니다. 플래그 데이는 업그레이드가 활성화할 지정된 블록 높이입니다.

*BIP 8: 오랜 비트코인 ​​코어 개발자인 루크 다쉬르(2011년부터 비트코인 ​​개발에 참여)는 BIP 9의 후속으로 2017년 2월에 BIP 8을 제안했습니다. BIP 8은 ​​해시레이트 아닌 블록 높이를 사용하여 제안 승인을 위한 신호 기간을 결정하는 것을 제안합니다. BIP 8은 ​​또한 "LOT"라는 새로운 온체인 활성화 소프트 포크 매개변수를 도입합니다. 이 매개변수를 "TRUE"로 설정하면 소프트 포크 타임아웃 높이에서 잠겼는지 확인하기 위해 마무리 기간 동안 신호가 필요합니다. 이제부터 업그레이드는 채굴자가 신호를 보냈는지 여부와 관계없이 사전 정의된 플래그 날에 노드에 의해 활성화됩니다. BIP 8은 ​​커뮤니티에서 원하는 제안 활성화에 대한 광부 간섭을 줄이고, 업그레이드의 LOT 매개변수가 TRUE로 설정된 경우 업그레이드된 노드에서 블록을 수신하지 못함으로써 발생하는 수익 손실의 결과를 광부들이 고려하도록 강제합니다.

*Speedy Trial: Bitcoin Core 개발자 AJ Townes와 Andrew Chow는 2021년 4월에 "Speedy Trial"이라는 BIP 8 버전을 소개했습니다. Speedy Trial은 채굴자들이 활성화를 위한 준비 신호를 보내는 타임라인을 가속화하기 위한 시도입니다. 이 접근 방식은 지정된 기간 내에 채굴된 블록의 대부분이 준비 신호를 보내면 제안이 활성화된다는 것을 의미합니다. Speedy Trial은 BIP 9 활성화 배포와 유사하게 작동하지만 활성화 창이 더 짧습니다. 최근, Taproot 업그레이드가 Speedy Trial을 통해 비트코인에서 활성화되었습니다. 테스트에서는 Taproot가 네트워크에서 활성화되기 전에 2주 동안 채굴된 블록의 90%가 준비 상태를 나타내는 신호를 보내야 합니다. 재판은 2021년 6월 12일에 끝났습니다. 90% 채굴자 지원 임계값에 도달하면, 네트워크는 채굴자와 노드가 소프트웨어를 업그레이드할 시간을 주기 위해 5개월의 대기 기간에 돌입합니다. Taproot는 2021년 11월 15일에 공식적으로 비트코인에서 활성화되었습니다.

*최신 소프트 포크 활성화: 이는 BIP 9와 BIP 8의 다양한 속성을 결합한 업그레이드 활성화 방법입니다. 이는 Bitcoin Core의 가장 생산적인 기여자 중 한 명인 Matt Corallo가 2020년 1월에 제안했습니다. 이 방법은 세 단계로 구성됩니다. 첫 번째 단계는 BIP 9에 명시된 대로 채굴자 활성화 소프트 포크 입니다. 채굴자들이 업그레이드를 활성화하지 못하면 Corallo가 설명한 최신 소프트 포크 활성화 프로세스는 두 번째 단계로 기본 설정됩니다. 즉, 개발자와 더 광범위한 비트코인 ​​커뮤니티가 코드 변경을 재고할 수 있도록 6개월 동안 기다리는 기간입니다. 6개월 후, 개발자와 사용자가 업그레이드를 계속하려면 3단계를 시작할 수 있습니다. 이는 기본적으로 LOT 매개변수를 TRUE로 설정한 BIP 8과 동일합니다.

12. 결론

OP_CAT(BIP 347)와 OP_CTV(BIP 119)는 많은 유명 비트코인 ​​개발자로부터 지원을 받았지만, 해당 제안이 구현되기 전에 장기간의 실사 과정을 거쳐야 합니다. OP_CAT 및 OP_CTV는 비트코인의 컨센서스 레이어 을 변경해야 하며 이러한 변경에 대한 BIP 거버넌스 프로세스가 광범위하기 때문입니다. BIP 119와 BIP 347의 활성화 일정은 불분명하고 예측할 수 없지만, 긴 검토 기간은 커뮤니티에 OP_CTV와 OP_CAT의 이점과 영향을 이해할 수 있는 충분한 시간을 제공하므로 제안에 이점이 될 수 있습니다. 또한, BIP 기여자들은 OP_CTV와 OP_CAT에 대한 스트레스 테스트를 실시하고 이것이 Bitcoin Script의 향후 버그에 미칠 수 있는 잠재적 영향을 파악할 수 있는 시간이 더 많아질 것입니다.

OP_CAT과 OP_CTV의 모든 잠재력은 아직 탐구 중이지만, 가장 즉각적인 영향은 비트코인 ​​L2와 고급 보안 비트코인 ​​볼트에 대한 신뢰할 수 없는 브리지를 구축하는 데 있습니다. EVM 호환 Bitcoin L2에 대한 신뢰가 필요 없는 브리징의 중요성은 지나치게 강조할 수 없으며, 특히 Bitcoin DeFi의 지속적인 개발 맥락에서 더욱 그렇습니다. 이러한 신뢰할 수 없는 솔루션은 신뢰할 수 있는 중개자에 의존하고 블록체인 기술의 허가가 필요 없는 특성을 훼손하는 WBTC 및 cbBTC와 같은 현재의 대안에 비해 상당한 발전을 나타냅니다. 자체 호스팅 비트코인 ​​볼트가 보관 솔루션 중에서 가장 실용적인 가치를 제공할 수 있지만, 신뢰할 필요가 없는 L2 브리지의 잠재력은 향상된 거래 프로그래밍 기능이 비트코인에 더 광범위한 가능성을 제공한다는 것을 보여줍니다.

개발자 커뮤니티는 2024년에 이러한 제안을 추진하는 데 상당한 진전을 이루었으며, 이러한 추진력은 2025년에도 계속될 가능성이 높습니다. 비트코인 거래 활동이 하락세를 보이고 거래 수수료가 1 sat/VB로 낮아지면서, 이제는 비트코인 ​​네트워크에서 거래 활동을 복원하는 방법에 관심이 쏠리고 있습니다. Galaxy Research 2025 예측 보고서는 Bitcoin Core 개발자들이 OP_CAT 또는 OP_CTV 사이에서 합의에 도달할 것으로 가정하지만, 최종 구현 및 활성화 프로세스에는 1~2년이 더 걸릴 수 있습니다. 그럼에도 불구하고, 이러한 제안이 결국 채택되면 비트코인 ​​스크립트의 발전에 있어서 중요한 이정표가 될 것이며, 앞으로 더욱 정교하고 안전한 비트코인 ​​애플리케이션을 위한 기반을 마련하게 될 것입니다.

거래 프로그래밍 기능을 향상시키면 비트코인은 신뢰할 필요가 없는 크로스체인 브리징과 고급 보관 솔루션과 같은 혁신적인 사용 사례를 더욱 지원할 수 있으며, 이를 통해 비트코인 ​​생태계 개발이 더욱 촉진됩니다. 이러한 기술의 도입은 비트코인의 기능을 개선할 뿐만 아니라, 개발자와 사용자에게 더 안전하고 효율적인 탈중앙화 애플리케이션을 구축할 수 있는 더 많은 도구를 제공할 것입니다. 이러한 목표를 달성하려면 시간이 걸리고 커뮤니티의 공동 노력이 필요하지만, 그 잠재적인 영향은 의심할 여지 없이 비트코인의 미래에 새로운 활력을 불어넣을 것입니다.