비트코인의 다음 큰 업그레이드는? OP_CAT과 OP_CTV에 대한 평가

저자: Gabe Parker, 애널리스트, Galaxy; 번역: Golden Finance xiaozou

요약

• 비트코인은 프로토콜 업그레이드에 보수적인 접근 방식을 취해왔기 때문에 합의 변경이 상대적으로 드물었습니다. 그러나 이전의 세그윗과 탭루트 업그레이드에서 알 수 있듯이 개발자들은 여전히 비트코인의 프로그래밍 언어와 네트워크 매개변수를 최적화하려는 의지가 있습니다.

• 비트코인의 프로그래밍 언어인 비트코인 스크립트는 트랜잭션에 글로벌 상태를 전달할 수 없으며, 인트로스펙션 기능을 지원하지 않아서 표현력을 제한합니다.

• 현재 비트코인 트랜잭션의 프로그래밍 가능성을 향상시키고자 하는 두 가지 주요 제안이 있는데, OP_CAT (BIP 347)과 OP_CTV (BIP 119)가 그것입니다. 그리고 트랜잭션 출력을 더 많은 비용에 의존하도록 만드는 것을 목표로 합니다. 이러한 제안은 비트코인 스크립트의 기능을 크게 향상시키고 더 유연하게 만들 수 있는 잠재력을 가지고 있습니다.

• OP_CAT과 OP_CTV의 가장 유망한 적용 시나리오는 다음과 같습니다:비트코인의 첫 번째(L1) 계층과 두 번째(L2) 계층 사이에 신뢰 없는 교차 체인 브리지 생성. 고급 자체 호스팅 금고 솔루션 개선 및 라이트닝 네트워크 개선.

• 소프트 포크 업그레이드를 위한 거버넌스 프로세스에는 여러 비트코인 이해관계자가 참여했습니다. 프로토콜 개념화 및 기술 검토 초기 단계에서는 미디어 인플루언서와 핵심 개발자가 가장 큰 영향을 미쳤습니다.

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

1. 소개

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

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

비트코인에서 합의 변경은 드물지만, 비트코인 개발자들은 비트코인 스크립트와 네트워크 매개변수를 최적화하는 데 개방적인 모습을 보여왔습니다. 블록 크기 논쟁에서 탄생한 세그윗(Segregated Witness) 업그레이드는 실제로 블록 크기 제한을 늘려 블록에 더 많은 트랜잭션을 포함할 수 있게 했으며, 세그윗은 측정 단위를 바이트에서 가상 바이트로 변경하여 거래 데이터의 형식을 최적화하기도 했습니다. 이러한 변화는 서명 데이터를 감시 필드로 옮기는 것과 함께 비트코인 블록에 최대 4m 무게 단위(약 4MB)의 트랜잭션 데이터를 포함할 수 있게 했습니다. 비트코인의 마지막 소프트 포크는 2021년 탭루트 업그레이드로, 탭스크립트라는 스크립팅 언어의 업데이트 버전이 도입되었습니다. 이 새로운 버전의 비트코인 스크립트에는 여러 개의 공개 키와 서명을 하나의 서명 키로 결합하는 향상된 키 집계 기능을 갖춘 새로운 서명 체계(슈노르 서명)가 포함되어 있습니다. 슈노르 서명을 위한 키 집계는 여러 서명이 필요한 거래 데이터의 양을 줄이는 동시에 라이트닝 네트워크(비트코인 재단 계층 위에 구축된 비트코인 최대 P2P 결제 계층)에서 거래의 프라이버시를 개선합니다. . 세그윗과 탭루트에 대한 간략한 개요는 비트코인 개발자들이 비트코인에 대한 합의 변경을 경계하고 있지만, 이것이 비트코인의 기술적 특성이 변하지 않는다는 것을 의미하지는 않는다는 것을 보여줍니다.

세그윗과 탭루트 이후 비트코인 개발자들은 거래에 스마트 콘트랙트 로직을 추가하기 위해 비트코인의 거래 프로그래밍 기능을 개선하는 방법을 모색하고 있습니다. 비트코인 스마트 콘트랙트에는 미사용 거래 산출물(UTXO)의 향후 사용 방법을 제한하고 제어하는 기능인 지출 조건이 포함되며, 보다 복잡하고 엄격한 지출 제약은 "언약"("제한 조항" 또는 "언약")으로 알려져 있습니다. "약정"). 이 백서에서는 먼저 비트코인 스크립트와 비트코인의 UTXO 회계 모델과 어떻게 작동하는지 살펴보겠습니다. 이어서, 보류 중인 두 가지 옵코드인 OP_CTV와 OP_CAT을 분석하여 이러한 옵코드가 비트코인 스크립트를 효율적인 트랜잭션 프로그래밍을 가능하게 하는 강력한 기능을 포함하도록 개선할 수 있는 잠재력을 가지고 있음을 강조할 것입니다. 마지막으로 이 백서에서는 브리징과 에스크로와 같은 비트코인 인프라에서 트랜잭션 프로그래밍 기능의 중요성을 강조하고, OP_CT와 OP_CTV에 대한 합의 도출 가능성과 다음 소프트포크 업그레이드에서 이러한 옵코드를 구현하는 경로에 대해 전망합니다.

2. 비트코인 스크립팅과 UTXO 모델

비트코인은 네이티브 스크립팅 언어를 사용해 트랜잭션을 구성하는 " 비트코인 스크립트"라는 트랜잭션을 구성합니다. 스크립트는 거래 수신자가 전송되는 비트코인을 사용하는 방법을 정의하는 일련의 지침("지출 조건"이라고도 함)으로 구성됩니다. 비트코인 스크립트는 명령 함수로 실행되는 186개의 옵코드로 구성됩니다. 이러한 옵코드는 네트워크에서 비트코인 자산이 어떻게 사용되고 전송되는지에 대한 공식 규칙을 만드는 데 사용됩니다. 예를 들어, 페이투펍키 해시 거래에는 비트코인을 해시된 공개 키로 보내고 지출자와 연결된 올바른 공개 키와 개인 키를 사용해야만 사용할 수 있는 비트코인 거래에 지출 조건을 적용하는 4개의 코드가 포함되어 있습니다.

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

*알리스가 지갑에 1 BTC 상당의 UTXO를 가지고 있고 0.5 BTC를 밥에게 보내는 경우, 앨리스의 입력은 1 BTC가 됩니다.* 출력은 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 중 수신자에게 완전히 지급된 것이 없다면 앨리스가 이제 2개의 UTXO를 받을 수 있다는 점에 유의하시기 바랍니다. 이제 앨리스는 1개가 아닌 2개의 새로운 UTXO를 받을 수 있습니다. UTXO 모델은 비트코인 네트워크의 핵심 기능이며 트랜잭션 처리와 검증에 중요한 역할을 합니다.

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

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

3. 2025년 기준 비트코인 스크립팅의 장애물

비트코인 스크립팅은 사용자에게 유용하고 이중 플러시 공격에 대한 회복력이 입증되었지만 공격에 대한 복원력은 입증되었지만, 스크립팅 언어에는 표현력이나 글로벌 상태 저장 기능과 같은 범용적인 기능이 부족합니다. 비트코인 스크립트는 스택 기반 프로그래밍 언어이기 때문에 큰 숫자에 대한 곱셈과 산술 연산을 수행할 수 없기 때문에 표현력이 부족합니다. 비트코인 스크립트는 32비트 크기의 값에 대해 사소하지 않은(사소하지 않은) 연산만 수행할 수 있습니다. 따라서 비트코인 스크립트는 32비트보다 큰 스택 요소를 서로 격리합니다. 이 32비트 제한은 암호화 함수, 곱셈, 나눗셈을 사용하는 계산 집약적인 명령을 격리하며, 현재 연산 코드 세트보다 더 큰 스크립트 크기를 필요로 합니다. 여러 개의 연산 코드를 사용하여 산술과 곱셈을 시뮬레이션할 수는 있지만, 여기에는 많은 스택 요소가 필요하며 비트코인 스크립트는 스택 크기가 1,000개 요소로 제한됩니다. 따라서 트랜잭션 출력에 현재 연산을 넘어서는 복잡한 비용 조건을 생성하는 것이 어렵습니다.

비트코인 스크립트의 가장 큰 한계는 지출자가 제공한 입력만 읽을 수 있기 때문에 트랜잭션 데이터를 읽고 쓸 수 없고 저장할 수 없다는 점입니다. 프로그래밍 언어가 글로벌 상태를 저장할 수 없으면 스크립트는 애플리케이션이나 브릿지에서 계정 잔액을 독립적으로 확인할 수 없습니다. 상태 데이터는 개별 트랜잭션에 적합해야 하므로 비트코인 스크립팅 로직은 글로벌 상태에 액세스할 수 없습니다. 따라서 일반적인 기능을 개발하거나 L2 네트워크와 비트코인 베이스레이어 사이에 신뢰 없는 브리지를 구축하는 것은 거의 불가능합니다.

2020년부터 비트코인의 스크립팅 한계를 극복하기 위한 이니셔티브가 진행되어 왔습니다. 지난 몇 년 동안 비트코인 스크립트의 표현력을 개선하는 유일한 방법은 새로운 옵코드를 구현하는 소프트 포크 업그레이드를 실시해 컨벤트를 활성화하는 것이라는 데 개발자들 사이에 합의가 이루어진 것으로 보이며, 비트코인 커뮤니티의 일부에서는 이러한 업그레이드가 비트코인 네트워크에 위험을 초래할 수 있다고 생각하는 반면, 다른 일부에서는 비트코인 사용 사례를 확장하려면 더 많은 프로그래밍 기능이 필요하다는 의견을 가지고 있습니다. 비트코인 거래의 프로그래밍 가능성을 개선하는 데 가장 적합한 옵코드에 대한 상당한 진전이 아직 이루어지지 않았지만, 현재 규약을 지지하는 사람들은 대부분 OP_CTV와 OP_CAT이 비트코인 거래의 프로그래밍 가능성을 개선하기 위한 주요 비트코인 개선 제안(BIP)이라는 데 동의하고 있습니다. 비트코인에서 컨벤션을 구현하기 위한 두 가지 이상의 솔루션이 있다는 것을 알고 있지만, 이 글에서는 가장 눈에 띄는 두 가지 제안인 OP_CTV와 OP_CAT만 설명합니다.

4. BIP 119(OP_CTV)

비트코인 개선 제안 119(BIP 119), CHECK-로도 알려진 템플릿 검증(CTV)으로도 알려진 2020년 1월 비트코인 코어 개발자 제레미 루빈이 제안한 것입니다. 이 제안은 비트코인 거래의 출력에 일반적인 지출 조건 또는 약정을 적용하는 새로운 옵코드인 OP_CTV를 도입하는 것으로, 간략한 배경은 다음과 같습니다. "CHECK_TEMPLATE_VERIFY"의 템플릿 부분은 비트코인 스크립트를 작성할 때 따라야 하는 트랜잭션 형식을 나타냅니다. CHECK-TEMPLATE-VERIFY는 트랜잭션 출력에 대한 잠금 스크립트가 잠금 스크립트에 저장된 지출 조건을 커밋할 수 있도록 하는 새로운 기능입니다. 에 저장된 지출 조건을 해시(커밋 해시라고도 함)로 커밋할 수 있게 해줍니다. 따라서 트랜잭션 출력은 커밋된 해시에 명시된 조건을 충족하는 경우에만 잠금을 해제할 수 있습니다. 체인에 브로드캐스트되면 트랜잭션과 관련된 커밋된 해시는 변경할 수 없으며, OP_CTV의 장점은 트랜잭션 발신자가 수신자에게 지출 조건을 부과할 수 있다는 점으로, 이는 발신자 지출 조건만 구성할 수 있는 현재 비트코인 스크립팅 규칙에서 크게 달라진 점입니다.

커버넌트 콘트랙트에는 크게 두 가지 유형이 있습니다. 일반 컨벤트는 복제하여 여러 UTXO에 적용할 수 있으며, 컨벤트는 UTXO가 소비된 후에도 만료되지 않습니다. 반면에 사전 계산된 컨약은 복제가 가능하지만 미리 정의된 횟수만큼만 제한적으로 사용할 수 있습니다. 사전 계산된 계약의 로직은 발신자가 미리 지정해야 하며, 지출 조건을 무한정 복제할 수 없다는 점에서 일반 계약과 다릅니다. 재귀 계약이라고도 하는 일반 계약은 UTXO 대체 가능성에 위험을 초래할 수 있으며, 이것이 BIP 119 지지자들이 일반적으로 사전 계산된 계약을 사용하는 OP_CTV 사용 사례에만 초점을 맞추는 이유이자 BIP 119가 일반 계약을 지원하지 않는 이유이기도 합니다. 예를 들어, 일반 계약이 활성화되면 수탁자나 비트코인 거래소가 영구적인 지출 조건으로 인출을 처리할 수 있으며, 해당 비트코인은 정부나 기타 기관의 감시에서 자유로울 수 없을 것입니다.

5. BIP 119로 컨벤츠 배포

볼팅 시나리오를 예로 들어 OP_CTV 기능에 대해 다음과 같은 방법을 구현할 수 있습니다. 약정:

앨리스가 향후 10년간 1 BTC에 해당하는 0.8 BTC를 밥과 찰리(각각 0.4 BTC)에게 보내려고 합니다.앨리스는 또한 약 0.2 BTC의 잔돈을 새로운 볼트로 보내려고 합니다. 새로운 금고로 보내려고 합니다.

1단계: 앨리스는 1 BTC 상당의 UTXO를 밥과 찰리에게 보내고, 잠금 스크립트에 밥과 찰리가 525,000 블록 후에 BTC를 사용할 수 있다고 상세히 설명합니다. 10년 후. 앨리스는 또한 ~0.2 BTC의 변경 출력을 자신이 소유한 볼트 주소로 전송하여 525,000 블록 후, 즉 ~10년 후에 UTXO를 잠글 것이라는 자세한 지침을 포함하고 있습니다.

2단계: 밥과 찰리는 525,000 블록 후 0.4 BTC에 해당하는 각자의 UTXO를 사용합니다.앨리스가 설정한 잠금 스크립트는 현재 블록 높이와 커밋된 해시를 확인하고, 조건이 충족되면 밥은 다음을 수행합니다.

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

3단계: 찰리와 밥이 잠금 스크립트에서 약속한 해시를 충족하면 앨리스에게 잔돈으로 반환된 UTXO(~0.2 BTC)를 지정된 볼트 스크립트 공개 키로 주소에 입력으로 사용합니다. 볼트 스크립트 공개 키에는 525,000블록 후에 앨리스가 ~0.2 BTC 상당의 UTXO를 사용하기 위해 볼트를 잠금 해제할 수 있는 해시가 포함되어 있습니다. 볼트 방식을 사용하면 누군가 개인 키를 도용하여 525,000블록 시간 잠금 전에 UTXO를 잠금 해제하려고 시도하는 경우에 대비하여 앨리스가 비밀 복구 주소와 같은 세부 보안 조치를 해시에 추가할 수 있다는 이점이 있습니다.

언약이 없는 경우, 앞의 예시에서 앨리스는 밥과 찰리에게 보내는 BTC에 대한 향후 지출 조건을 적용하기 위해 사전 서명된 트랜잭션을 생성해야 합니다. 사전 서명 트랜잭션은 발신자의 개인 키로 미리 서명하지만 실제로 확인과 실행을 위해 네트워크에 브로드캐스트되지는 않는 단일 또는 다중 트랜잭션일 수 있습니다. 사전 서명된 트랜잭션은 체인에서 실행될 때까지 사용자가 여러 트랜잭션에 대한 데이터를 저장해야 하므로 확장성이 떨어집니다. 또한, 사전 서명된 트랜잭션은 자금을 사용할 수 있을 때 모든 서명 당사자 간의 상호 작용이 필요합니다. 그러나 OP_CTV를 통해 커밋된 해시를 사용해 컨벤션을 구현하면 사용자가 사전 서명된 트랜잭션의 데이터를 저장하고 트랜잭션과 관련된 모든 당사자 간의 상호작용에 의존할 필요가 줄어듭니다.

일반적으로 이 기능은 정교하고 안전하며 탄력적인 다양한 호스팅 및 보안 설계를 만드는 데 사용할 수 있으며, 셀프 호스팅 또는 호스팅 설정을 개선하거나 혁신적인 새로운 쿼럼 또는 비즈니스 계정 설정을 만들거나 투명성과 신뢰성이 높은 보다 자율적인 실행 시나리오를 만드는 데 도움이 됩니다. .

6. BIP 347 (OP_CAT)

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

결정적으로, 스택 상단에 있는 비트코인 스크립트의 연결 요소는 산술과 곱셈 기능을 에뮬레이션할 수 있어 오류가 발생하기 쉬운 데이터 집약적인 긴 스크립트를 작성할 필요 없이 복잡한 스크립트를 구현할 수 있습니다. 또한, 2021년 11월에 활성화된 탭루트 업그레이드의 일환으로 개발자는 OP_CAT의 연결을 통해 새로운 트랜잭션 유형을 활성화하는 데 사용되는 기본 스크립팅 언어인 탭스크립트에서 머클 트리 및 기타 해시 데이터 구조를 사용하여 비용 조건을 생성할 수 있습니다.

특히, 사토시 나카모토는 비트코인 스크립트가 스크립트 내에서 직접 복잡한 수학 연산을 수행할 수 있게 해주는 OP_CAT과 다른 옵코드를 비활성화했습니다. 비트코인 스크립트가 2,000바이트로 제한되어 있던 시절, 사토시 나카모토가 OP_CAT을 제거한 이유는 OP_DUP과 함께 데이터 집약적인 스크립트를 구성할 수 있었기 때문입니다. 이 정도 크기의 스크립트는 비트코인 노드의 연산 자원에 부담을 주고 과부하를 일으킬 수 있었습니다. 그러나 2021년에 탭루트 업그레이드를 통해 탭루트 스크립트의 크기가 520바이트로 제한되었기 때문에 OP_CAT은 더 이상 노드 운영자에게 과도한 연산 오버헤드를 유발하지 않습니다.

7. BIP 347(OP_CAT)로 컨벤츠 배포

2021년 Taproot 업그레이드는 다음과 같이 진행됩니다. 비트코인 스크립트 언어에 대한 슈노르 서명: 슈노르 서명은 공개 및 개인 키 통합을 지원하여 여러 당사자가 단일 서명으로 거래에 공동 서명할 수 있습니다. 슈노르 서명에 포함된 검증 옵코드를 OP_CAT과 결합하면 트랜잭션 해시를 생성하는 비재귀적 컨트랙트가 생성됩니다. OP_CAT을 사용하면 사용자는 트랜잭션 해시를 잠금 해제의 키로 사용하여 스크립트를 잠금 해제하기 위한 요구 사항으로 전송 주소 또는 전송 금액과 같은 트랜잭션의 특정 부분을 제한할 수 있습니다.

볼팅 시나리오를 예로 들어, 다음은 OP_CAT 기능으로 언약을 활성화하는 방법에 대한 일반적인 개요입니다. 이 예시의 기술적 세부 사항은 이 글의 범위를 벗어납니다.

앨리스가 100블록 후 UTXO를 잠금 해제하는 볼트를 만들고자 합니다:

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

*2단계: 앨리스의 트랜잭션 중에 OP_CAT은 감시 필드에서 볼트 잠금 해제 명령을 연결하고 두 번 해시하여 sighash/txhash를 얻습니다.

*3단계: 100번의 블록 확인 후 앨리스는 볼트 UTXO의 지출 트랜잭션을 브로드캐스팅하여 자신의 볼트 비트코인을 지출하는 프로세스를 시작합니다. 앨리스가 모든 지출 조건을 충족했는지 확인하기 위해 지갑은 백그라운드에서 CheckSig 옵코드를 실행합니다. 이 작업은 두 가지 주요 검증을 수행합니다: 초기 설정 트랜잭션의 트랜잭션 해시를 확인하고(1단계), 현재 지출 트랜잭션과 비교합니다(3단계). CheckSig 함수는 설정 트랜잭션의 구성 요소를 다시 빌드하고 현재 트랜잭션의 공개 키 서명을 확인하여 모든 볼트 지출 조건이 충족되었는지 확인합니다.

*4단계: 앨리스 트랜잭션의 공개 키가 (감시 필드에 저장된 지출 조건을 다시 빌드하는) CheckSig에서 확인되면 앨리스는 UTXO를 자유롭게 지출할 수 있습니다.

위 예시는 OP_CAT 단독으로는 트랜잭션에 지출 조건을 적용할 수 없지만, 비트코인 스크립트의 다른 옵코드와 함께 사용하면 스크립팅을 단순화하여 콘벤트를 활성화할 수 있음을 보여주며, OP_CAT의 유일한 기능은 스택 상단에 있는 두 요소를 연결하는 것뿐입니다.

OP_CAT을 CheckSig와 함께 사용해 컨벤트를 생성할 수는 있지만, OP_CAT만 추가한다고 해서 비트코인 스크립트에 솔리디티와 같은 기능을 제공하지는 않습니다. 이러한 제한은 OP_CTV만 추가하는 경우에도 적용됩니다. OP_CAT을 사용하더라도 비트코인 트랜잭션은 최소한의 인트로스펙만 가능하므로 이전 트랜잭션의 요소나 상태에 대한 완전한 액세스 권한이 없습니다. 결과적으로 OP_CAT은 탭루트 트랜잭션의 출력에서 세분화된 언약만 지원할 수 있으며, 탭루트 출력의 리프 노드를 수정하거나 사용된 내부 키를 검증할 수 없습니다.탭루트 리프 노드는 탭루트 출력에 제출된 개별 지출 조건 또는 스크립트입니다. 각 리프 노드는 비트코인을 사용하는 다양한 '경로' 또는 방법이라고 생각하시면 됩니다. 비트코인 탭루트 트랜잭션의 내부 키는 가장 효율적인 지출 경로에 사용되는 기본 공개 키입니다. 내부 키를 사용해 UTXO를 사용할 때는 스크립트나 머클 경로를 공개하지 않고 체인에 서명을 제공하기만 하면 됩니다.

이러한 한계는 OP_TWEAK_VERIFY, OP_INTERNALKEY와 같은 다른 옵코드 제안으로 해결할 수 있다는 점에 유의해야 합니다. 전반적으로 OP_CAT은 거래 출력에 복잡한 비용 조건을 생성하는 주요 빌딩 블록으로 간주할 수 있지만, 비트코인 거래의 프로그래밍 가능성을 발전시키는 데는 CheckSig를 포함한 다른 빌딩 블록이 중요합니다.

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

(1) 신뢰 없는 브리징과 일방적 이탈

(1) 신뢰 없는 브리징과 일방적 이탈

Starkware(이더리움의 스타크넷 zk-롤업 개발사)는 OP_CAT이 어떻게 신뢰 없는 비트코인 브리징을 위한 스타크 검증자와 머클 검증자 생성을 지원하는지 강조하는 보고서를 발표했습니다. 무신뢰 브리징은 머클 트리에 기록된 거래 체인을 통해 브리지 상태를 유지하는 재귀적 콘트랙트 시스템을 통해 구축됩니다. 이 메커니즘의 핵심은 계정 잔액을 나타내는 머클 트리의 루트 해시를 포함하는 사용 불가능한 OP_RETURN 출력에 저장된 브리지의 영구적인 상태이며, OP_CAT 컨트랙트는 각각의 새로운 입금 또는 출금 거래에 현재 브리지 상태를 반영하는 유효한 상태 전환이 포함되도록 요구합니다. 사용자는 효율적인 유효성 검사를 위해 머클 트리를 사용해 여러 거래를 일괄 처리하는 전용 입금 및 출금 계약을 통해 브리지와 상호작용합니다. 그런 다음 이 머클 트리의 루트는 각 입금 또는 출금을 검증하고 처리하는 메인 브릿징 컨벤턴트에 병합됩니다. 인출 시 컨트랙트는 인출 주소가 리프 트랜잭션에 입력된 첫 번째 주소와 일치하는지 확인하여 소유권을 검증합니다. 이 설계는 비트코인 스크립트의 효율적인 상태 업데이트를 위해 머클 증명을 활용하여 제3자 신뢰 없이 OP_CAT이 생성한 온체인 콘트랙트의 논리를 통해서만 상태와 브리징 규칙이 시행되는 신뢰가 필요 없는 시스템을 구축합니다. 결정적으로, 최종 시스템 상태 전환을 검증하는 신뢰 없는 비트코인 브리징의 경우 비트코인 스크립트가 증명을 검증해야 하며, 해시 데이터를 함께 연결하여 비트코인 스크립트에 STARK 검증자를 구축하는 OP_CAT의 기능을 통해 UTXO 잠금 스크립트가 최종 시스템 상태 전환의 zk 증명(영지식 증명)을 검증할 수 있습니다.

탭루트 마법사 팀은 비트코인에서 임의의 계산을 분할하고 실행할 수 있도록 하여 튜링 완전 표현을 가능하게 하는 OP_CAT과 BitVM을 결합한 새로운 신뢰 없는 브리징 프레임워크를 혁신했습니다. BitVM은 비트코인 스크립트를 활용한 임의의 계산을 비트코인 스크립트와 결합하여 런타임에 계산을 여러 트랜잭션으로 분할하여 비트코인에서 실행합니다. 약정이 없으면 비트코인을 잠그는 BitVM 브리지는 브리지를 설정하기 위해 사전 서명된 트랜잭션이 필요하지만, OP_CAT은 이전 거래의 데이터를 전송하는 기능을 통해 사전 서명된 거래 없이 비트코인을 잠그고 잠금을 해제할 수 있습니다.OP_CAT은 "스택 위의 CAT"이라는 기술을 통해 비트코인을 잠그고 잠금을 해제할 수 있습니다. OP_CAT은 "스택상의 CAT"이라는 기술을 통해 이전 트랜잭션의 데이터를 전달할 수 있습니다. 이 기술은 스택에서 해시 데이터를 연결하여 머클 트리의 루트를 구축하는 것으로, OP_CAT은 이를 확인할 수 있습니다. 결과적으로 CatVM 브리지는 이전 거래, 입금, 출금의 거래별 데이터가 다음 거래에 포함되어야 성공적인 출금 후 머클 루트가 이월되도록 보장하며, CAT 온 더 스택 트릭은 사용자가 출금한 후에도 자격을 갖춘 사용자가 브리지된 나머지 비트코인을 출금할 수 있도록 보장합니다.

(2) 고급 볼트 에스크로

비트코인 볼트는 개인 키가 손상된 경우 사용자가 비트코인을 출금할 수 있는 복구 경로와 같은 보안 기능을 포함하는 새로운 에스크로 솔루션입니다. 개인 키가 손상된 경우 비트코인을 비밀 주소로 인출할 수 있는 복구 경로를 제공하며, 공식적으로 OP_VAULT로 알려진 BIP 345는 비트코인 에스크로의 보안 매개변수를 강화하기 위해 OP_CTV를 활용하는 보류 중인 비트코인 개선 제안입니다. OP_CAT은 사전 서명된 거래 없이도 비트코인 금고에 대한 지출 조건을 만드는 데 사용할 수 있다는 점에 유의해야 합니다. 비트코인 코어 개발자 제임스 오바인은 2023년 1월 OP_CTV의 사용 사례를 좁히기 위해 OP_VAULT를 제안했습니다. OP_VAULT는 예금자가 여러 거래에 사전 서명할 필요 없이 볼트 비트코인의 지출 조건을 생성하기 위해 OP_CTV에 의존합니다. 시간 지연을 설정할 수 있으며, 이는 일반적으로 자금을 훔치려는 공격자가 원래의 시간 잠금 전에 볼트 비트코인을 사용하려고 시도할 때 트리거됩니다.

(3) 부인 방지 계약

비부인 계약이 비트코인 네트워크에 도입되었습니다. 네트워크에 도입되었으며, 서명자가 서명 키를 이중으로 사용할 경우 서명 키가 유출되는 비트코인 트랜잭션 출력입니다. 실제로 사용자는 네이티브 비트코인을 몰수할 수 있는 증거금으로 잠급니다. 이 증거금을 통해 사용자는 기본 계층에서 0-확인 트랜잭션을 실행할 수 있으며, 나중에 블록에서 채굴됩니다.0-확인 트랜잭션은 비트코인 합의 규칙에 의해 검증되고 보호되는 즉각적인 비트코인 트랜잭션입니다. 0-확인 거래의 발신자가 거래가 채굴되기 전에 입력을 사용하면 거래 상대방은 손상된 서명 키로부터 비트코인 마진을 몰수당할 수 있습니다.

(4) 라이트닝 네트워크 개선

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

OP_CTV는 하나의 UTXO가 여러 사용자를 대표하는 공유 UTXO를 만들 수 있습니다. CTV를 사용하는 공유 UTXO를 사용하면 여러 사용자가 하나의 온체인 트랜잭션으로 여러 라이트닝 채널을 열 수 있습니다. 일반적으로 각 라이트닝 채널에는 하나의 온체인 트랜잭션이 필요합니다. 따라서 많은 사용자가 라이트닝 채널을 열면 메모리 풀이 보류 중인 트랜잭션으로 가득 차고 트랜잭션 수수료가 증가할 수 있습니다. 현재는 문제가 되지 않지만, 라이트닝 네트워크가 수백만 명의 활성 사용자를 유치하기 위해서는 채널 개설이 확장되어야 합니다.

9. OP_CT 및 OP_CTV와 관련된 위험

모든 비트코인 소프트 포크에는 새로운 옵코드 버그나 예기치 않은 사용 사례와 같은 기술적 위험이 포함되어 있습니다. 사용 사례와 같은 기술적 위험이 있습니다. 전자는 드물지만, 후자는 비문 생성 과정에서 노출될 수 있습니다. 비문은 거래의 감시 필드에 임의의 데이터를 입력하는 것으로, 비트코인에서 새로운 토큰과 NFT 컬렉션을 생성하는 데 사용되어 왔습니다.세그윗과 탭루트 업그레이드를 통해 사용자는 이미지와 텍스트 데이터를 감시 필드에 문자열 데이터로 입력할 수 있게 되었습니다. 디지털 아트와 대체 가능한 토큰 생성은 세그윗이나 탭루트 활성화의 초점이 아니었지만, 몇 년 후 영리한 개발자들이 이러한 업그레이드를 다른 용도로 사용하는 방법을 발견했습니다.갤럭시 리서치는 조례 보고서에서 이 아이디어를 강조하며 세그윗과 탭루트를 통해 우연히 비문을 생성하는 것이 향후 비트코인에 영향을 미칠 수 있다고 지적했습니다. 를 통한 우발적인 비문 생성은 향후 비트코인 업그레이드에 부정적인 영향을 미칠 수 있으며, 이러한 새로운 사용 사례에 대한 커뮤니티의 놀라움으로 인해 새로운 소프트 포크를 지지하는 것을 더 주저하게 만들 수 있습니다.

비트코인의 업그레이드 능력에 대한 부정적인 정서에도 불구하고, OP_CAT과 OP_CTV는 많은 테스트와 연구를 거쳤습니다. 규약에 대한 초기 비판은 정부가 승인된 주소에서만 비트코인을 사용할 수 있도록 하는 지출 조건을 적용하도록 애플리케이션을 강제할 수 있다는 것이었습니다. 지출 조건의 조건은 자금을 소유한 사용자가 결정하기 때문에 이러한 비판은 타당하지 않습니다. 사용자는 특정 주소로 향후 지출을 제한하는 거래를 생성할 수 있지만, 이러한 제한은 제3자가 외부에서 강제할 수 없으며 잠긴 자금이 사용된 후에는 영구적으로 유지될 수 없습니다. 따라서 정부는 자체 호스팅 볼트 앱이나 브릿지에서 자금을 어떻게 사용하는지 강제할 수 없습니다. 수탁자와 비트코인 거래소는 여전히 사용자가 자금을 사용하는 방법을 제한할 수 있지만, 일반 규약을 강제할 수 없는 인출된 자금에 영구적인 지출 조건을 추가할 수는 없으며, OP_CTV는 이를 허용하지 않습니다.

전반적으로 OP_CAT과 OP_CTV는 각각 기능을 잘 수행하는 간단한 오코드로, OP_CAT은 스택 상단에 있는 두 요소를 연결하고 OP_CTV는 잠금 스크립트에서 지출 조건을 해시할 수 있습니다. 이러한 옵코드의 일부 사용 사례(예: 신뢰할 수 없는 브리지 개발)는 버그와 해킹에 매우 취약하기 때문에 추가적인 연구와 실제 테스트가 필요합니다.

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

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

*경제 노드: 거래소, 수탁자, 판매자, 결제 제공자

*투자자: MegaWhale, 마이크로스트레티지, ETF 제공업체, 갤럭시

*미디어 리디터: 코인데스크, 비트코인 매거진, X 셀러브리티, 팟캐스트

*채굴자: 비트메인, 마이크로BT, 라이엇, 마라톤, 대형 개인 채굴자

*프로토콜 개발자: 비트코인 핵심 개발자

*응용 프로그램 개발자: L2 프로젝트

비트코인 개선 제안(BIP)의 수명 주기 동안 다양한 이해관계자들이 다양한 정도의 영향력을 행사하며, 그들의 상대적 영향력은 소프트 포크를 구현하는 합의 형성 과정에서 변화합니다. 아래는 각 이해관계자의 영향력 수준을 1~10점 척도로 분류한 세부 분석입니다. 2024년 3월 현재 OP_CAT과 OP_CTV는 프로토콜 아이디어 단계에 있습니다. 이 단계에서는 미디어 인물이 여론을 움직이고 내러티브를 만들 수 있기 때문에 가장 큰 영향력을 가지고 있습니다. 예를 들어, 유명한 비트코인 유명인들로 구성된 팀인 탭루트 마법사(Taproot Wizards)는 대규모 소셜 미디어 팬층을 활용해 비트코인 커뮤니티에 OP_CAT의 이점에 대해 교육하고 있으며, 탭루트 마법사 팀은 비트코인 스크립트에서 거래 프로그래밍 가능성을 향상시키기 위해 새로운 옵코드가 필요하다는 점을 강조하기 위해 OP_CAT에 대한 교육 콘텐츠와 연구를 제작해왔습니다. 내러티브. 그 결과, 탭루트 마법사는 핵심 개발자들이 OP_CAT BIP 초안을 검토하도록 촉구하는 OP_CAT 지지자 그룹을 대규모로 육성했습니다.

비트코인 코어 개발자는 보류 중인 BIP 초안을 검토할 책임이 있으며, 무엇보다도 비트코인 코어 깃허브 저장소에 BIP를 병합할 수 있는 유일한 주체이기 때문에 프로토콜 아이디어 단계에서 두 번째로 영향력이 있는 집단입니다. 비트코인 코어 개발자의 지원이 없다면, BIP는 필연적으로 보류될 수밖에 없고 궁극적으로 거부될 것입니다. 비트코인 코어 개발자는 또한 비트코인 코드베이스를 유지 관리하고 오류가 없는지 확인할 책임이 있습니다. 비트코인 코어 개발자 간에 이념적 견해가 다를 수 있고 의사 결정 과정에서 각 코어 개발자의 기여도와 배경에 따라 영향력이 다르기 때문에 비트코인 코어 개발자 간의 합의에 도달하는 것은 어려운 과정입니다.

OP_CAT과 OP_CTV BIP는 미디어 레드셔츠, 사용자, 앱 개발자들이 그들의 영향력을 이용해 비트코인 코어 개발자들을 설득하는 가운데 다음과 같은 합의를 이끌어내고 있습니다. 변경이 비트코인 거래의 프로그래밍 가능성을 향상시킬 것이라고 설득하고 있습니다. 합의 여정의 다음 단계에서는 기술 유명인, 앱 개발자, 핵심 개발자들이 OP_CAT과 OP_CTV의 모든 잠재적 위험을 자세히 설명하는 구체적인 연구가 필요할 것입니다. 구체적인 연구와 핵심 개발자들과의 열린 대화 없이는 OP_CAT과 OP_CTV에 대한 집단적 견해를 형성할 수 있는 광범위한 핵심 개발자 커뮤니티가 형성되지 않을 것입니다.

핵심 개발자 간에 합의가 이루어지면, OP_CAT과 OP_CTV는 비트코인 코어 저장소에 BIP를 구현하는 마지막 단계를 촉진하기 위해 수석 관리자를 임명해야 합니다. OP_CAT과 OP_CTV의 BIP가 비트코인 코어 저장소에 병합된 후에는 활성화 방법을 결정해야 합니다. 활성화 방법이 선택되면 채굴자, 투자자, 경제 노드가 가장 큰 영향을 미치는 신호 기간이 시작됩니다. 2024년 3월 현재 채굴자, 마이크로스트레티지와 같은 대형 투자자, 코인베이스와 같은 경제 노드는 아직 OP_CAT과 OP_CTV에 대한 공개 의견을 표명하지 않았습니다. 이러한 이해관계자들은 BIP가 시행되기 전에 OP_CAT과 OP_CTV의 위험과 이점에 대해 더 자세히 알아볼 필요가 있습니다.

11. BIP 활성화 방법

비트코인 코어 개발자가 다음 소프트포크 업그레이드에 OP_CT 또는 OP_CTV를 포함하기로 동의하는 경우. 커뮤니티는 BIP의 활성화 방법에 동의해야 합니다. 활성화 방법을 통해 채굴자는 업그레이드에 대한 준비 상태를 알릴 수 있습니다.

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

소프트 포크가 채굴자가 아닌 사용자에 의해 활성화되는 경우, 이를 사용자 활성화 소프트 포크(UASF)라고 합니다. 비트코인에서 가장 유명한 UASF 사례는 2017년 8월 1일 세그윗 업그레이드 채택을 가속화하기 위한 '블록 크기 논쟁' 중에 일어날 뻔한 일이었습니다. 블록 크기 논쟁 중에 비트코인 사용자들은 세그윗 업그레이드를 지원하기 위해 노드를 업그레이드했고, 이후 업그레이드하지 않은 노드의 블록을 거부하겠다고 위협했습니다. 이를 통해 비트코인 클라이언트 소프트웨어를 업그레이드하지 않은 채굴자들은 블록을 더 널리 활용하고 블록 보상을 받을 가능성을 높이기 위해 세그윗을 채택하도록 장려되었습니다. 블록 크기 전쟁 동안 UASF는 발생하지 않았지만, 잠재적인 UASF의 위협은 채굴자들이 세그윗을 채택하도록 영향을 미쳤습니다.

코드 변경을 구현하는 두 번째 방법은 이전 버전과 호환되지 않는 업그레이드인 하드 포크를 통해 컨센서스를 업그레이드된 노드와 그렇지 않은 노드 간에 영구적으로 분할하는 것입니다. 업그레이드된 노드와 그렇지 않은 노드 간의 합의를 영구적으로 분리하는 업그레이드입니다. 비트코인 코어 개발자는 프로토콜 코드의 견고성과 이전 버전과의 호환성을 중요하게 생각하기 때문에 하드 포크를 구현한 적이 없습니다. 소수의 사용자가 하드포크 업그레이드(예: 블록 크기 변경)를 수행하면 비트코인은 체인 분할을 경험할 수 있습니다. 2017년 비트코인 커뮤니티의 일부가 세그윗 업그레이드에 동의하지 않고 단순히 블록 크기를 늘리기 위해 이전 버전과 호환되지 않는 코드 변경을 활성화하여 비트코인 프로토콜에서 포크하고자 했을 때 비트코인 캐시가 탄생한 것도 이러한 이유에서입니다.

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

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

*BIP 8: 오랜 비트코인 코어 개발자 루크 대시(2011년부터 비트코인에 참여해 온)는 2017년 2월에 BIP 9의 후속으로 BIP 8을 제안했습니다. BIP 8은 제안을 승인하기 위한 시그널링 기간을 결정할 때 컴퓨팅 파워가 아닌 블록 높이를 사용할 것을 제안하며, 소프트 포크를 위한 새로운 온체인 활성화 매개변수인 "LOT"도 도입합니다. 이 매개변수를 "TRUE"로 설정하면, 소프트포크가 타임아웃 높이에서 잠겨 있는지 확인하기 위해 최종 기간 동안 신호가 필요합니다. 이후부터는 채굴자의 신호 여부와 관계없이 미리 정의된 플래그 날짜에 노드에 의해 업그레이드가 활성화되며, BIP 8은 채굴자가 원하는 커뮤니티의 제안 활성화에 대한 방해를 최소화하고 업그레이드의 LOT 파라미터가 TRUE로 설정된 경우 업그레이드 노드로부터 블록을 받지 못해 발생하는 수익 손실의 결과를 채굴자가 고려하도록 시도합니다.

*스피디 트라이얼: 비트코인 코어 개발자 AJ 타운스와 앤드류 차우는 2021년 4월에 '스피디 트라이얼'이라는 BIP 8 버전을 소개했습니다. "빠른 평가판은 채굴자가 활성화할 준비가 되었다는 신호를 보내는 타임라인을 가속화하려고 시도합니다. 이 접근 방식은 채굴된 블록의 대다수가 지정된 기간 내에 준비되었다는 신호를 보내면 제안이 활성화된다는 것을 의미합니다. 빠른 평가판은 BIP 9 활성화 배포와 유사하게 작동하지만 활성화 기간이 더 짧습니다. 최근 비트코인에서 빠른 평가판을 통해 탭루트 업그레이드가 활성화되었습니다. 이 평가판에서는 채굴된 블록의 90%가 2주 이내에 준비 신호를 보내야만 네트워크에서 탭루트가 활성화될 수 있었습니다. 평가판은 2021년 6월 12일에 종료됩니다. 90% 채굴자 지원 임계값에 도달한 후 네트워크는 채굴자와 노드가 소프트웨어를 업그레이드할 시간을 주기 위해 5개월의 대기 기간에 들어갔고, 2021년 11월 15일에 비트코인에서 탭루트가 공식적으로 활성화되었습니다.

*현대 소프트 포크 활성화: 이는 BIP 9와 BIP 8의 서로 다른 속성을 결합한 업그레이드 활성화 방법입니다. 비트코인 코어에 가장 많은 기여를 한 매트 코랄로가 2020년 1월에 제안했습니다. 이 방법은 세 단계로 구성됩니다. 첫 번째 단계는 채굴자가 BIP 9에 설명된 대로 소프트 포크를 활성화하는 것입니다. 채굴자가 업그레이드를 활성화하지 못하면, 코랄로가 설명한 최신 소프트포크 활성화 프로세스는 기본적으로 개발자와 더 넓은 비트코인 커뮤니티가 코드 변경을 재고할 수 있도록 6개월의 대기 기간인 두 번째 단계로 넘어갑니다. 6개월 후, 개발자와 사용자가 업그레이드를 진행하고자 하는 경우 3단계를 활성화할 수 있으며, 이는 본질적으로 BIP 8에서 LOT 파라미터를 TRUE로 설정하는 것과 같습니다.

12. 결론

OP_CAT(BIP 347)과 OP_CTV(BIP 119)는 다수의 저명한 비트코인 개발자들이 지지하고 있지만, 이 제안들은 구현되기 전에 여전히 긴 실사 과정을 거쳐야 합니다. OP_CAT과 OP_CTV는 비트코인의 합의 계층을 변경해야 하며, 이러한 변경을 위한 BIP 거버넌스 프로세스가 광범위하기 때문입니다. BIP 119와 BIP 347의 활성화 일정은 불분명하고 예측할 수 없지만, 긴 검토 기간은 커뮤니티가 OP_CAT과 OP_CTV의 이점과 의미를 이해할 수 있는 충분한 시간을 제공함으로써 제안에 도움이 될 수 있습니다. 또한, BIP 기여자들은 OP_CTV와 OP_CAT을 스트레스 테스트하고 향후 비트코인 스크립팅의 버그에 미칠 잠재적 영향을 파악할 수 있는 더 많은 시간을 갖게 될 것입니다.

OP_CT와 OP_CTV의 모든 잠재력은 아직 탐구 중이지만, 가장 즉각적인 영향은 비트코인 L2를 위한 무신뢰 브리징과 고급 보안 비트코인 볼트의 구현에 있습니다. 특히 비트코인 탈중앙 금융이 지속적으로 발전하고 있는 상황에서 EVM 호환 비트코인 L2를 위한 무신뢰 브리징의 중요성은 아무리 강조해도 지나치지 않습니다. 이러한 무신뢰 솔루션은 신뢰할 수 있는 중개자에 의존하고 블록체인 기술의 무허가 특성을 약화시키는 WBTC 및 cbBTC와 같은 현재의 대안에 비해 상당한 진보를 의미합니다. 자체 호스팅 비트코인 금고는 호스팅 솔루션 중 가장 실용적인 가치를 제공할 수 있지만, 무신뢰 L2 브리징의 잠재력은 향상된 거래 프로그래밍 기능이 비트코인에 더 넓은 가능성을 열어줄 수 있음을 보여줍니다.

개발자 커뮤니티는 2024년에 이러한 제안을 추진하는 데 상당한 동력을 얻었으며, 이러한 모멘텀은 2025년에도 계속될 수 있습니다. 비트코인 거래 활동이 감소 추세에 있고 거래 수수료가 1 sat/VB까지 낮아지면서 현재 비트코인 네트워크에서 거래 활동을 되살릴 수 있는 방법으로 초점이 이동하고 있습니다. 갤럭시 리서치 2025 전망 보고서에 따르면 비트코인 코어 개발자들이 OP_CAT 또는 OP_CTV 사이에서 합의에 도달할 것으로 예상되지만, 최종 실현 및 활성화 과정은 1~2년 더 걸릴 것으로 보입니다. 그럼에도 불구하고 이러한 제안이 최종적으로 채택된다면 비트코인 스크립팅의 진화에 중요한 이정표가 될 것이며, 향후 더욱 복잡하고 안전한 비트코인 애플리케이션을 위한 토대가 마련될 것입니다.

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