이 글은 개별 계약 제안에 대해 심층적으로 분석하는 시리즈의 다섯 번째 기사입니다.
OP_CAT은 BIP 347에서 Ethan Heilman과 Armin Sabouri가 재활성화를 위해 제안한 것으로, 계약이 아닙니다. 이는 스택에서 데이터 요소를 조작하기 위해 비트코인의 첫 번째 릴리스에 원래 포함된 opcode였습니다. 2010년 비트코인 0.3.10의 릴리스와 함께 서비스 거부 공격으로 인해 노드를 충돌시킬 수 있다는 우려로 여러 다른 opcode와 함께 비활성화되었습니다. 스크립트를 실행하는 동안 스택의 개별 항목에 대한 전역 최대 한도인 520바이트도 추가되었습니다.
스크립트 평가가 스택에서 어떻게 작동하는지에 대한 기본적인 이해가 있어야 하며, 비트코인 거래의 기본 요소도 알고 있어야 하므로 OP_CAT에 대한 사전 설명은 그리 필요하지 않습니다.
OP_CAT은 그 자체로 계약이 아닐 수 있지만, Schnorr 서명이 작동하는 방식의 특이성으로 인해 계약을 에뮬레이트할 수 있습니다. 이는 꽤 심층적인 주제로, Blockstream의 Andrew Poelstra가 여기에서 완전히 설명하고 있으므로, 저는 고수준의 관점만 유지하겠습니다. 모든 타원 곡선에는 키 생성 및 서명에 사용되는 생성기 점, 즉 본질적으로 “1”이 있습니다. Schnorr를 사용하면 생성기 점을 키로 사용하여 서명할 수 있으며, 몇 바이트를 반복적으로 서명해야 하는 것을 감안할 때, 결과 서명은 실제로 서명한 거래의 동일한 해시입니다.
현재 그것이 수학적으로 어떻게 작동하는지의 메커니즘은 제쳐두고, 이러한 “이상한” 서명이 스택에서 현재 거래의 TXID를 가져올 수 있게 해준다는 것을 기억해 두세요.
OP_CAT 작동 방식
OP_CAT은 스택의 상위 두 데이터 항목을 가져와서 연결합니다. 따라서 스택의 상위 두 항목이 “1”과 “2”라면, OP_CAT은 두 항목을 제거한 후 “12”를 스택의 맨 위에 놓습니다. 그게 전부입니다.
OP_CAT의 유용성
좋습니다, 그럼 왜 이렇게 중요한가요? OP_CAT이 작동하는 방식에 대한 설명이 단 한 문단도 안 되는 간단한 것임에도 불구하고 왜 모두가 OP_CAT에 대해 이렇게 흥분하고 있나요?
두 가지 이유가 있습니다. OP_CAT은 스택에서 메르클 트리를 직접 구성하고 검증할 수 있게 해주며, 이는 흥미로운 행동과 기능을 열어줍니다. 또한 위에서 언급한 “이상한” Schnorr 서명 덕분에 계약을 에뮬레이트할 수 있게 해주어 완전한 세부 검사 기능을 제공합니다.
메르클 증명 검증은 Taproot의 핵심 요소이지만, 구현 방식상 메르클 트리 검증은 tapscript 지출 경로가 지출되는 동전의 출력 스크립트에서 루트 Schnorr 공개 키에 커밋되었는지 검증하는 맥락에서만 발생합니다. Taproot는 일반적인 메르클 증명 검증을 지원하지 않습니다.
OP_CAT은 이를 완전히 일반적인 방식으로 허용합니다. 단순히 리프 해시와 내부 해시 노드를 올바른 순서로 제공하고 OP_CAT을 연속적으로 호출하면 메르클 루트 해시를 재구성할 수 있으며, 스크립트에서 미리 정의된 해시와 비교할 수 있습니다. 이를 통해 CatVM과 같이 공유 UTXO에 대한 일방적 인출 경로를 제공하거나, 유효한 작업이 포함된 블록에 다른 거래가 포함되도록 거래를 의존하게 하거나, 메르클 증명으로 검증할 수 있는 거의 모든 조건에 거래를 의존하게 만들 수 있습니다.
이제 완전한 내부 검사를 가능하게 하는 계약 에뮬레이션에 대해 이야기해 보겠습니다. 당신이 하려는 것은 거래가 유효하기 위해 특정 특성을 가져야 한다는 것을 보장하는 것입니다. 이제 “이상한” 서명이 스택에서 거래의 해시를 가져온다는 것을 기억하세요. 거래 서명은 실제 거래의 원시 데이터가 아니라 그 해시에 대해 수행됩니다. 이는 우리가 흥미로운 일을 할 수 있게 해줍니다.
OP_CAT을 사용하여 거래의 개별 원시 조각을 증인으로 사용하여 매우 복잡하고 얽힌 스크립트를 구성할 수 있으며, OP_CAT을 사용하여 스택에서 천천히 조합할 수 있습니다. 그 과정에서 거래의 개별 조각을 미리 정의된 해시와 비교하여 확인할 수 있습니다. 스크립트의 끝에서 전체 거래가 스택에 있고 필요한 데이터를 추가한 후 다시 해시하여 OP_EQUAL과 비교할 수 있습니다. 이때 “이상한” 서명과 비교합니다. 이 검사가 통과하면 일반 CHECKSIG을 실행할 수 있으며, “이상한” 서명이 지출되는 거래로 만들어졌다면 모든 것이 유효하게 실행됩니다.
거래의 개별 조각에 대한 OP_EQUAL 검사는 해당 조각이 정확히 있어야 함을 보장합니다. 이 중 하나라도 검증에 실패하면 거래는 무효입니다. 이는 에뮬레이트된 계약을 강제합니다. 마지막으로 OP_CAT으로 구성된 거래 해시와 “이상한” 서명이 일치하면, 최종 CHECKSIG은 OP_CAT으로 구성된 거래와 에뮬레이트된 계약이 실제로 지출되는 거래와 일치함을 보장합니다.
마무리 생각
OP_CAT은 내부 검사와 데이터 전송의 문을 완전히 열어줍니다. 내부 검사는 원하는 모든 세부 수준으로 수행할 수 있으며, 거래의 각 개별 필드가 독립적으로 커밋될 수 있습니다. 이는 TXHASH가 제공하는 모든 내부 검사 기능을 가능하게 하며, 그 이상도 가능합니다.
일반 메르클 증명을 검증할 수 있는 기능은 강력한 기능이지만, 그 기능이 어떻게 사용될지와 어떤 종류의 인센티브를 생성할 수 있을지에 대한 의문을 제기합니다. 비트코인 스크립트는 메르클 트리를 사용하여 외부 블록체인 시스템에서 거래가 이루어져야 하는 요구 사항을 설정할 수 있습니다.
OP_CAT은 그 자체로 계약이 아니지만, 훨씬 덜 효율적인 블록체인 발자국으로 계약을 완전히 에뮬레이트할 수 있게 해줍니다(개발자가 실수를 하여 돈을 잃을 가능성도 있습니다). 이는 매우 간단한 제안이지만, 열어주는 거대한 설계 공간을 고려할 때 신중하게 접근해야 합니다.
