OP_CAT이 발생하고 있나요? 계약 제안이 방금 BIP 번호 #347로 지정되었습니다. 그러나 더 깊이 파고들기 전에, 계약이 무엇인지 그리고 비트코인 사용자들이 왜 그것을 원할 수 있는지 살펴보겠습니다.
비트코인은 디지털 전자 화폐의 이상적인 상태인가요, 아니면 우리가 온체인에서 더 많은 것을 원하나요?
표면을 긁어내기: 비트코인 스크립트의 한계
OP_CAT과 같은 계약 제안을 이해하려면, 현재 비트코인 스크립트의 기본적인 한계를 이해하는 것이 중요합니다. 비트코인은 기본적인 스마트 계약을 생성할 수 있도록 자금을 잠그고 해제하는 규칙을 정의하는 코드를 통해 작동합니다. 그러나 비트코인 스크립트는 프로그래밍 언어로서 새로운 거래에서 코인을 이동할 때만 작동하는 기본 논리에 제한되어 있습니다.
현재 비트코인에서는 코인의 거래 경로를 미리 구성하거나 지정할 수 있는 방법이 없으며, 코인이 잠겨 있을 때 얼마나 빨리 이동할 수 있는지도 정해져 있지 않습니다(PSBT, 부분 서명된 비트코인 거래를 사용하는 해킹 방식은 제외하고, 이는 거래 수수료를 적절히 포함하거나 사용되지 않을 경우 삭제를 증명하거나 나중에 방송을 방지할 수 없습니다).
이 단순함은 비트코인의 보안 모델의 핵심이지만, 스크립트 언어가 기본적인 스마트 계약조차 지원하는 능력에 상당한 제한을 도입합니다.
선형 실행 모델
비트코인 스크립트의 한 가지 한계는 opcodes가 루프 없이 순차적으로 실행되는 운영 모델입니다.
P2PKH 거래의 이 예에서, 스크립트가 선형적으로 실행되는 방식을 볼 수 있습니다: 공개 키를 복제하고, 이를 주소로 해시하고, 잠금 스크립트에 대해 해시를 검증한 다음, 공개 키에 대해 서명을 확인합니다.
루프가 없다는 것은 스크립트가 튜링 완전하지 않으며 종료가 보장되어 무한 루프와 같은 문제를 방지하여 네트워크를 중단시키거나 크게 느리게 할 수 없다는 것을 의미합니다. 이러한 설계 선택은 자원 사용을 정적으로 제한할 수 있게 하지만, 복잡한 워크플로우를 관리하는 스크립트의 능력을 제한합니다.
기본 산술 부족
비트코인 스크립트에는 100개 미만의 비트코인 opcodes가 있으며, 놀랍게도 스택에서 객체를 곱하거나 나누거나 결합할 수 있는 기능이 없습니다. OP_CAT에 관심이 있는 많은 사용자들이 알다시피, 사토시는 2010년에 OP_OR, OP_MUL(곱하기), OP_DIV(나누기), OP_CAT(연결하기) 등을 포함한 여러 opcodes를 비활성화했습니다. 비활성화된 opcodes는 원래 구현에 네트워크 보안을 위협할 수 있는 취약점이 있었기 때문에 제거되었습니다. 그러나 이러한 opcodes의 부재는 거래 수수료를 계산하는 것과 같은 간단한 시나리오에서 유용할 수 있는 기본적인 수학을 수행하기 어렵게 만듭니다.
거래 데이터 가시성 부족
표면적으로, 대부분의 사람들은 비트코인 스마트 계약이 가치 금액 및 거래 데이터의 다른 부분을 볼 수 있다고 가정하는 것 같습니다. 이 정보는 이미 블록체인에서 공개적으로 볼 수 있기 때문입니다. 그러나 이러한 가정과는 달리, 비트코인 계약은 거래 데이터를 기반으로 지출 조건을 설정할 수 없습니다. 비트코인 스크립트는 거래 데이터를 전혀 볼 수 있는 능력이 매우 제한적이기 때문입니다.
스크립트가 거래 데이터 내에서 더 많은 세부 정보를 해석할 수 있는 능력이 있다면, 우리는 특정 지출 조건을 시행하고, 다단계 거래를 생성하며, 금고와 같은 더 발전된 보안 기능을 활성화할 수 있는 훨씬 더 강력한 계약을 구축할 수 있습니다.
우리는 어떻게 해야 할까요?
우리는 비트코인에 이러한 한계가 있다는 것을 알고 있으며, 수년 동안 이러한 기능을 도입하기 위한 다양한 제안이 논의되었습니다. Simplicity와 같은 비트코인 스크립트에 대한 더 넓은 실험은 스택 기반 제약의 대안을 제공하는 것을 목표로 합니다. OP_MULTISHA256, OP_LESS 및 OP_LE32TOLE64와 같은 opcodes는 비트코인의 산술 능력을 업그레이드하는 것을 목표로 합니다. OP_CTV 및 OP_CAT과 같은 제안은 introspection opcodes와 관련되어 있으며, 계약으로 그룹화됩니다.
그렇다면 스마트 계약과 새로운 용어인 계약의 차이는 무엇인가요?
스마트 계약 vs. 계약
스마트 계약은 중개자 없이 자금을 이전하는 자가 실행 거래입니다. 현재 비트코인에서 스마트 계약은 비트코인 스크립트를 사용하여 비트코인을 잠그고 해제하는 행위로 제한됩니다. 계약은 사용자가 향후 거래에서 자금이 어떻게 지출되는지를 제어할 수 있도록 하여 비트코인의 스마트 계약 기능을 향상시키는 것을 목표로 합니다.
스크립트가 거래 데이터를 해석할 수 있게 함으로써, 우리는 그 데이터가 계약 논리에서 사용될 수 있는 방법을 효과적으로 생성합니다.
다음은 계약 기능을 위한 몇 가지 흥미로운 introspection opcodes입니다:
- OP_TXHASH: 거래의 입력(또는 출력)의 해시를 제공하며, 스크립트가 거래 데이터를 기반으로 조건을 검증하고 시행할 수 있는 능력을 부여합니다.
- OP_CSFS + OP_CAT: 두 개가 함께 스크립트가 거래 자체뿐만 아니라 모든 데이터에 대해 서명을 확인할 수 있게 합니다. 이는 스크립트가 거래 데이터 또는 외부 정보를 기반으로 조건을 검증할 수 있게 하여 비트코인 스크립트 내에서 검증 가능성을 확장합니다.
이 두 opcodes는 의도적으로 광범위하여 복잡한 검증 프로세스와 introspection 기능을 가능하게 합니다. 다른 것들은 범위가 더 좁고 더 제한된 형태의 계약을 위해 설계되었습니다.
- OP_CHECKTEMPLATEVERIFY (CTV): 거래 출력을 미래의 지출 거래의 템플릿을 포함하도록 허용하여 보다 제한된 방식으로 계약을 가능하게 합니다.
- OP_VAULT: 사용자가 거래 목적지를 지정할 수 있지만 지연 후에만 코인을 실제로 이동할 수 있는 특정 형태의 계약을 가능하게 합니다.
그런 다음 OP_CAT이 단독으로 존재하는데, 이는 직접적인 introspection opcode는 아닙니다…
- OP_CAT: 스크립트가 스택의 두 요소를 연결할 수 있게 하여 스크립트 내에서 다양한 정보 조각을 결합하는 데 유용합니다.
OP_CAT은 introspection 능력이 없는 것처럼 보이는데, 여기서 무슨 일이 일어나고 있나요?
OP_CAT: 모든 가능성을 풀어내기
거래 introspection
2021년, Andrew Poelstra는 OP_CAT introspection 트릭에 대해 블로그 포스트를 작성했습니다. 그는 특정 예를 제공했지만 독자가 유사한 기술에 대한 사전 지식이 있다고 가정했습니다. 여기서는 더 나은 이해를 위해 그 설명을 단순화하려고 합니다.
비트코인 스크립트에는 거래 데이터를 introspect할 수 있는 세 가지 주요 opcodes만 있습니다: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY 및 CHECKSIG. 추가적으로 CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG 및 CHECKMULTISIGVERIFY와 같은 변형이 있으며, 이는 기본적으로 CHECKSIG의 약간의 변형입니다. 처음 두 개는 확인이 검증되었는지 여부만 볼 수 있게 하여 기능이 상당히 제한적입니다. CHECKSIG는 유사하지만, 여기서의 차이는 스택에서 서명과 공개 키를 가져올 수 있게 한다는 것입니다. 흥미롭습니다.
전통적으로 우리는 연결을 두 항목을 결합하는 기능으로 생각하지만, 우리는 또한 이를 사용하여 항목을 분리하거나 나눌 수 있습니다. 이 경우 서명을 (r, s) 쌍으로 나누는 것입니다.
우리는 OP_CAT에서 OP_SPLIT 기능을 어떻게 유도할 수 있을까요?
“큰 객체가 있다면 사용자가 두 조각을 제공하는 데 시간을 소비하도록 요청하여 두 개로 나눌 수 있습니다. 이를 CAT하여 기본적으로 동등성을 확인합니다. 이 방법으로 모든 작업을 항상 반전할 수 있습니다. CAT만으로 서명을 분리할 수 있습니다.” — Andrew Poelstra, TABConf 2021
여기서 무슨 일이 일어나고 있나요?
사용자에게 서명, 공개 키 및 거래를 제공하도록 요구함으로써, 서명을 구성 요소로 나누고 각 부분을 거래 데이터에 대해 독립적으로 확인할 수 있습니다. 이 기술은 서명과 공개 키가 유효한 거래의 구성 요소임을 검증하는 분할 또는 결합의 형태로 볼 수 있습니다.
이 모든 것이 어떻게 introspection을 가져오는 걸까요?
“Taproot에서 우리는 OP_CAT과 Schnorr 서명 검증 opcodes를 사용하여 비재귀적 계약의 형태를 얻을 수 있습니다. 이는 문자 그대로 거래 해시를 얻는 것이 가능합니다. 재미있는 변형 거래 해시가 아니라 모든 거래 데이터의 문자 그대로 SHA2 해시를 스택에 올리는 것입니다.” — Andrew Poelstra, TABConf 2021
Poelstra는 스택에 남겨진 거래 입력 또는 출력에 대한 SHA2 해시를 얻는 방법을 보여줍니다. 여기서 복잡한 수학은 생략하겠지만, OP_CAT을 사용하면 잠금 해제 스크립트의 요구 사항으로 거래의 일부를 제한할 수 있다는 의미입니다. 우리는 보내는 주소나 해당 거래에서 전송되는 값을 제한할 수 있으며, 거래 해시는 이를 잠금 해제하는 키 역할을 합니다.
금고
같은 기술을 사용하여 거래 introspection을 제공하고 금고의 기본 버전을 빠르게 제공합니다. Poelstra의 블로그에서 설명된 논리를 따라, Rijndael이라는 개발자는 OP_CAT만으로 이를 구현할 수 있음을 증명했습니다.
“스택에서 이전 거래를 introspect하기 위해 TXID를 재구성하는 것이 예상보다 실제로 더 쉬웠습니다.” — Rijndael
금고를 사용하면 사용자가 자금이 가야 할 다음 주소를 지정하여 키 손상 시 자금 회수를 위한 메커니즘을 제공하고, 개인 키 도난에 대한 유인을 줄입니다.
스크립트를 위한 머클 트리
현재 비트코인에서 머클 트리는 데이터 검증, 동기화 및 블록체인의 거래와 블록을 서로 연결하는 데 사용되는 데이터 구조입니다. 두 스택 변수를 연결할 수 있게 하는 OP_CAT opcode는 공개 키의 SHA256 해시와 함께 사용될 때 스크립트에 대한 간단한 머클 트리 검증 프로세스를 촉진합니다. 이 접근 방식은 2015년 Pieter Wuille에 의해 처음 제안되었으며, Liquid 네트워크에서 성공적으로 구현되었습니다.
해시 프리이미지, 타임락 및 공개 키와 같은 다양한 지출 조건으로 가득 찬 트리 구조를 상상해 보세요. 이를 트리 서명이라고 합니다.
트리 서명
OP_CAT은 다음과 같은 트리 서명의 생성을 가능하게 합니다:
“…공개 키 수에 따라 크기가 로그 수준이 될 수 있는 다중 서명 스크립트를 제공하며, n-of-m을 넘어서는 지출 조건을 인코딩할 수 있습니다. 예를 들어, 1KB 미만의 거래는 천 개의 공개 키를 가진 트리 서명을 지원할 수 있습니다. 이는 일반화된 논리적 지출 조건도 가능하게 합니다.” — BIP 저자 Ethan Heilman, bitcoin-dev 메일링 리스트에서
이는 트리 내의 해시된 콘텐츠를 검증할 수 있게 하여 데이터 무결성과 신뢰성을 유지하면서 블록체인에 불필요한 부하를 추가하지 않도록 합니다.
이 모든 것이 흥미로운 이유는 무엇인가요?
재귀적 계약
거래를 검사하고 특정 부분에 제약을 적용할 수 있는 능력이 있다면, 여러 거래를 통해 이어지는 조건을 설정할 수 있습니다. 이는 재귀적 계약이라고 불립니다. OP_CAT은 단 10줄의 코드로 많은 힘을 제공하기 때문에 독특한 제안입니다. 이는 우리가 처음에 다룬 세 가지 초기 한계: 거래 데이터 가시성, 더 나은 수학 기능 및 선형 실행 모델을 해결할 수 있는 능력을 가지고 있습니다.
OP_CAT은 처음에는 간단해 보일 수 있지만, 창의적으로 활용할 때 상당한 잠재력을 열어줍니다. 이는 이 논의의 범위를 넘어서는 더 많은 기능을 위한 기본 블록 역할을 합니다. 예를 들어, 포스트-양자 램포트 서명과 같은 기능입니다.
이것은 안전한가요?
OP_CAT이 처음 제거되기 전, OP_DUP(복제)와 결합되어 스택에서 처음 1바이트 값을 반복적으로 복제하는 데 사용되면 메모리 사용량이 폭발적으로 증가할 수 있었습니다. 이는 메모리 소비 증가로 인해 서비스 거부(DoS) 공격으로 사용될 수 있었습니다. 새로운 제안은 스택 요소에 520바이트 제한을 부과하여 이 공격을 간단히 방지합니다.
계약이 영원히 실행될 위험이 있나요?
이것이 OP_CAT이 스크립트의 실행 모델을 변경하여 더 이상 자원 사용을 정적으로 제한하지 않게 만드는 것을 의미한다면(스크립트 크기의 선형 함수로서)? 아닙니다.
계약이 비트코인 위에 다른 코인에 대한 시장을 만들까요?
재귀적 계약이 있다면, 네, 기술적으로 복잡한 레이어-2 애플리케이션을 구축할 수 있습니다. 여기에는 NFT, 분산형 거래소 및 양자 고양이 등이 포함됩니다. 그러나 그렇게 하는 것은 간단하지 않습니다. 심각한 시장이 그렇게 할 가능성은 낮습니다.
CAT을 사용하여 코인을 영구적으로 “오염시킬” 수 있나요?
컬러드 코인 및 NFT의 경우, 이러한 자산을 발행하면 사용자가 사실상 사토시를 ‘소각’하여 ‘레이어-2’ 자산의 소유권을 나타내는 방식으로 표시합니다. 이 과정은 코인을 ‘오염시키는’ 것으로 알려져 있습니다. 그러나 코인의 소유자만이 자신의 코인을 표시할 수 있으며, 비트코인 지갑은 더 이상 이를 인식하지 않습니다(저자들이 이를 가능하게 하는 코드를 명시적으로 추가하지 않는 한). 결과적으로 생성된 코인은 비트코인 지갑에서 수용되지 않을 것입니다. 아마도 그것들은 크립토캣 지갑이나 그와 유사한 곳에서는 수용될 수 있지만, 이는 대부분의 비트코인 사용자에게는 무관합니다.
이것이 비트코인에서 MEV 문제를 만들까요?
비트코인과 이더리움의 주요 차이점은 거래 가시성입니다. 이더리움과 달리 계약의 모든 측면이 반드시 투명하지는 않으며, 이는 비트코인 채굴자가 내부 계약 상태를 볼 수 있는 능력이 동일하지 않다는 것을 의미합니다.
경제적으로 생각하는 비트코인 사용자들이 OP_CAT에 대해 가장 우려하는 점은 채굴자 추출 가능 가치(MEV)의 잠재성입니다. 이 주제에 대해 이전 게시물에서 더 광범위하게 논의되었습니다. 많은 사용자들이 레이어-2 계약을 기술적으로 가능하게 만들면 MEV가 불가피해질 것이라고 우려하고 있습니다. 그러나 이것이 사실인가요? 특히 비트코인에서 레이어-2 코인의 기술적 가능성이 그들의 불가피한 생성과 채택을 의미합니까?
간단한 스왑 계약이나 비교적 비효율적인 NFT를 구축하는 것은 상상할 수 있지만, 자동 시장 제조기가 있는 DEX와 같은 복잡한 것을 구축하는 것은 극히 불가능해 보이며, ‘기술적 가능성’이 있음에도 불구하고 Liquid에서 그런 것을 본 적이 없습니다.
그렇다면 OP_CAT은 정말 완벽한가요?
전혀 그렇지 않습니다. 일부 사람들은 재귀적 계약을 보고 싶어하지만, 다른 사람들은 비트코인이 전혀 변하지 않기를 원합니다.
비트코인 사용자 중 일부인 “경직주의자”들은 비트코인을 현재 상태로 유지하는 것을 옹호하며, 모든 프로토콜 업그레이드에 회의적입니다. 그들은 계약과 같은 중요한 변화가 네트워크의 분산화를 저해할 수 있다고 우려합니다. 그들의 주장은 비트코인의 원래 비전을 고수하는 것이 최선이라는 믿음에 기반합니다. 아이러니하게도 OP_CAT은 원래 비트코인의 일부였으며, 이는 반론을 촉발합니다. 일부는 OP_CAT을 되돌리는 것이 실제로 비트코인을 사토시의 초기 비전과 재조정할 수 있다고 믿습니다.
재귀적 계약이 가능하게 할 수 있는 보안 기능을 보고 싶다면, OP_CAT이 좋겠지만, 완전한 Lisp 스타일의 스크립팅 언어만큼 좋지는 않을 것입니다. 여기서의 문제는 이것이 비트코인에 대한 대규모 변화가 될 것이며, 가까운 시일 내에 자리를 잡을 가능성이 낮다는 것입니다.
혹은 아마도 당신은 반대편에 있으며, OP_CTV나 OP_VAULT와 같은 비재귀적 계약의 단순함을 선호할 것입니다. 비재귀적 계약은 더 간단하고 이해하기 쉬우며, 통제되지 않은 제약 체인을 생성할 위험이 없습니다.
재귀적 계약의 어떤 버전이 불가피하다면 어떻게 될까요?
수년 동안 개발자들은 거래 검증 논리에 대한 거의 모든 확장이 OP_CAT의 기능을 에뮬레이트하는 데 사용될 수 있다는 것을 알아차렸습니다.
스크립트 우주에는 스택 요소의 크기를 기준으로 두 가지 영역이 있습니다. 4바이트보다 큰 스택 요소의 경우, 동등성을 비교하거나 서명을 키로 해석하거나 해시할 수 있습니다. 4바이트 이하의 스택 요소의 경우, 산술 또는 분기를 수행하는 객체로 취급할 수 있습니다. BitVM에서 RISC-V 프로세서를 실행하면 문자 그대로 무엇이든 할 수 있습니다. OP_CAT을 에뮬레이트하거나 스택 요소를 분해하거나 결합할 수 있는 모든 것은 이 두 영역을 결합하여 스크립트로 ‘무엇이든 할 수 있게’ 합니다.
Andrew Poelstra와 같은 연구자들은 우리가 거의 모든 새로운 opcode로 재귀적 계약을 수행할 수 있을 것으로 기대하고 있습니다. 만약 그렇다면, 이는 이를 잘 수행할 수 있는 방법을 찾기 위한 정당화가 될 것입니다.
OP_CAT이 계약을 위한 앞으로의 경로가 될 가능성이 있나요?
계약이 단순히 흥미로운 것이 아니라 불가피하다면, 우리는 그것이 비트코인 사용자가 사토시가 원래 구상했던 것처럼 신뢰 없이 전송하도록 구현되도록 어떻게 보장할 수 있을까요? 경직주의자들이 여전히 분열된 상태이지만, OP_CAT은 계약 논의에서 강력한 경쟁자로 계속 부상하고 있습니다.
OP_CAT은 가장 우아한 조각 도구는 아니지만, 개발자들이 놀라운 새로운 기능을 조각낼 수 있도록 허용하는 가장 좋은 힘 대 복잡성 비율을 가진 도구입니다.
이 글은 Kiara Bickers의 게스트 포스트입니다. 표현된 의견은 전적으로 그들의 것이며 BTC Inc 또는 Bitcoin Magazine의 의견을 반드시 반영하지는 않습니다.
