비트코인 2층 네트워크의 성배: 내성과 계약
글 작성: Chakra Research
개요
튜링 완전성 블록체인인 이더리움과 비교할 때, 비트코인의 스크립트는 기본적인 연산만 지원하고 곱셈 및 나눗셈조차 제공하지 않아 제약이 크다고 여겨진다. 더 중요한 점은 블록체인 자체의 데이터를 스크립트에서 거의 읽을 수 없어 유연성이 크게 부족하며 프로그래밍 가능성이 낮다는 것이다. 따라서 오랫동안 사람들은 비트코인 스크립트(Script)가 내성(introspection) 기능을 갖도록 하는 방법을 찾고 있다.
내성이란 비트코인 스크립트가 거래 데이터를 검사하고 제한할 수 있는 능력을 의미한다. 이를 통해 스크립트는 거래의 구체적인 세부사항에 따라 자금 사용 방식을 제어함으로써 보다 복잡한 기능을 실현할 수 있다. 현재 비트코인의 오퍼코드(opcode)는 대부분 두 가지 기능만 수행한다: 사용자가 제공한 데이터를 스택에 푸시하거나, 스택에 이미 존재하는 데이터를 조작하는 것이다. 반면 내성 오퍼코드는 현재 거래의 데이터(예: 타임스탬프, 금액, 거래 ID 등)를 스택에 푸시하여 UTXO 지출 방식에 대해 더욱 세밀한 제어를 가능하게 한다.
현재 비트코인 스크립트에서 내성을 지원하는 주요 오퍼코드는 세 가지뿐이다: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, CHECKSIG; 여기에 CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, CHECKMULTISIGVERIFY 등의 변형도 포함된다.
계약(covenant)이란 간단히 말해 토큰의 이전 방식에 대한 제한이며, 사용자는 계약을 통해 UTXO의 분배 방식을 지정할 수 있다. 많은 종류의 계약은 내성 오퍼코드를 통해 구현되며, 현재 Bitcoin Optech에서는 내성이 계약 항목 하에 분류되어 논의되고 있다.
비트코인은 현재 CSV(CheckSequenceVerify)와 CLTV(CheckLockTimeVerify)라는 두 가지 계약만을 가지고 있으며, 모두 시간 기반 계약이다. 이는 라이트닝 네트워크와 같은 다수의 확장 솔루션들이 작동하는 기초가 된다. 이를 통해 비트코인의 확장 전략이 얼마나 내성과 계약에 의존하고 있는지를 알 수 있다.
토큰 이전에 제한 조건을 어떻게 추가할 수 있을까? 암호화 세계에서 가장 일반적으로 사용되는 방법은 커밋먼트(commitment)이며, 대개 해시(hash)를 통해 이루어진다. 또한 우리가 이전 조건을 충족했음을 증명하기 위해선 서명 메커니즘을 통한 검증이 필요하다. 따라서 계약에는 해시와 서명에 대한 다양한 조정이 존재한다.
아래에서는 널리 논의되고 있는 계약 오퍼코드 제안들을 설명하겠다.
CTV (CheckTemplateVerify) BIP-119
CTV(CheckTemplateVerify)는 커뮤니티 내에서 활발히 논의된 비트코인 업그레이드로, BIP-119에 포함되어 있다. CTV는 출력 스크립트가 해당 자금을 사용하는 거래의 템플릿을 지정할 수 있게 하며, 여기에는 거래의 nVersion, nLockTime, scriptSig 해시, 입력 개수, sequences 해시, 출력 개수, outputs 해시, 입력 인덱스 등의 필드가 포함된다. 이러한 템플릿 제한은 하나의 해시 커밋먼트를 통해 구현되며, 이후 사용 시 스크립트는 지출 거래의 특정 필드 해시값이 입력 스크립트의 해시값과 일치하는지 확인한다. 이 템플릿은 실제로 해당 UTXO의 미래 지출 거래에 대한 시간, 방식, 금액 등을 제한한다.
주목할 점은 입력 TXID가 해시 커밋먼트에서 제외되었다는 사실이다. 이 제외는 필수적이다. Legacy 또는 Segwit 거래에서 기본 SIGHASH_ALL 서명 타입을 사용할 경우, TXID는 scriptPubKey 값에 의존하여 생성되기 때문이다. 따라서 TXID를 포함하면 해시 커밋먼트에 순환 구조가 발생하여 성공적인 구성이 불가능해진다.
CTV는 새로운 오퍼코드를 통해 거래의 특정 정보를 직접 가져와 해시한 후 스택의 커밋값과 비교함으로써 내성을 구현한다. 이 방식은 체인 상의 공간 소모가 적지만 유연성은 다소 떨어진다.
라이트닝 네트워크 등 비트코인 2층(Layer-2) 솔루션의 기반은 사전 서명된 거래(presigned transaction)이다. 사전 서명이란 조건이 만족될 때까지 네트워크에 방송하지 않고 미리 생성하고 서명하는 것을 의미한다. 본질적으로 CTV는 보다 엄격한 형태의 사전 서명 기능을 구현하며, 그 커밋먼트를 체인 상에 직접 공개하여 사전 템플릿에 따라 거래만 허용한다.
CTV는 처음에 비트코인의 혼잡 완화, 즉 혼잡 제어(congestion control)를 위해 제안되었다. 비트코인이 혼잡할 때 CTV를 사용하면 여러 미래 거래를 단일 거래로 커밋할 수 있으므로 혼잡 시점에 여러 거래를 방송할 필요 없이 블록 혼잡이 완화된 후 실제 거래를 완료할 수 있다. 특히 거래소가 대규모 인출 요청을 받을 때 이러한 혼잡 제어가 큰 도움이 될 수 있다. 또한 템플릿은 보안 강화를 위한 '금고(vault)' 구현에도 활용될 수 있다. 자금의 이동 경로가 고정되어 있기 때문에 해커는 CTV 스크립트를 사용하는 UTXO를 자신의 주소로 보내지 못한다.
CTV는 2층 네트워크에 매우 큰 개선을 가져올 수 있다. 예를 들어 라이트닝 네트워크에서 Timeout Trees 및 채널 팩토리(channel factory)를 구현할 때, CTV를 통해 단일 UTXO가 CTV 트리로 확장되어 여러 상태 채널을 동시에 열 수 있으며, 체인 상에서는 단 한 건의 거래와 하나의 확인만 필요하다. 또한 CTV는 Ark 프로토콜의 원자적 거래(ATLC)에도 지원을 제공한다.
APO (SIGHASH_ANYPREVOUT) BIP-118
BIP-118은 tapscript를 위해 보다 유연한 지출 로직 작성을 가능하게 하는 새로운 서명 해시 플래그인 SIGHASH_ANYPREVOUT을 제안한다. APO는 CTV와 여러 면에서 유사하며, scriptPubKeys와 TXID 사이의 순환 문제에 직면한다. APO의 해결책은 입력 관련 정보를 제외하고 출력만 서명함으로써 거래가 동적으로 다른 UTXO에 연결될 수 있도록 하는 것이다.
논리적으로 보면, 서명 검증 오퍼레이션 OP_CHECKSIG(및 관련 오퍼코드)는 세 가지 기능을 가진다:
-
지출 거래의 각 부분 조합
-
해시 처리
-
해시가 주어진 키로 서명되었는지 검증
서명 내용은 조합할 거래 필드에 따라 크게 달라지며, 어떤 필드를 서명에 포함할지는 SIGHASH 플래그가 결정한다. BIP 342 서명 오퍼코드 정의에 따르면, SIGHASH 플래그는 SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY 등으로 나뉜다. 여기서 SIGHASH_ANYONECANPAY는 입력을 제어하며, 나머지는 출력을 제어한다.
SIGHASH_ALL은 모든 출력에 서명하는 기본 플래그이며, SIGHASH_NONE은 출력에 서명하지 않는다. SIGHASH_SINGLE은 지정된 하나의 출력에만 서명한다. SIGHASH_ANYONECANPAY는 앞 세 가지 플래그와 함께 설정 가능하며, 이 플래그가 설정되면 지정된 입력에만 서명하고, 그렇지 않으면 모든 입력에 서명해야 한다.
분명히 기존 SIGHASH 플래그들로는 입력의 영향을 제거할 수 없다. 심지어 SIGHASH_ANYONECANPAY도 하나의 입력에 대한 커밋을 요구한다.
따라서 BIP 118은 SIGHASH_ANYPREVOUT을 제안한다. APO 서명은 사용되는 입력 UTXO(PREVOUT이라 함)를 커밋하지 않고 출력만 서명하므로 비트코인 제어에 더 높은 유연성을 제공한다. 미리 거래를 구성하고 대응하는 일회용 서명 및 공개키를 만들어 공개키 주소로 전송된 자산은 반드시 미리 구성된 거래를 통해만 사용될 수 있어 계약이 실현된다. APO의 유연성은 거래 수정(transaction bumping)에도 활용될 수 있다. 예를 들어 수수료가 낮아 체인 상에서 막힌 거래의 경우, 새 서명 없이도 수수료를 높인 새 거래를 쉽게 생성할 수 있다. 또한 다중 서명 지갑에서 서명이 사용되는 입력에 의존하지 않으므로 운영이 더욱 간편해진다.
scriptPubKeys와 입력 TXID 사이의 순환이 제거됨에 따라 APO는 위트니스(witness)에 출력 데이터를 추가함으로써 내성을 구현할 수 있다. 다만 이는 여전히 추가적인 위트니스 데이터 공간 소모를 수반한다.
라이트닝 네트워크 및 금고와 같은 오프체인 프로토콜에서 APO는 저장해야 할 중간 상태를 줄여 저장 요구와 복잡성을 크게 감소시킨다. APO의 가장 직접적인 용례는 Eltoo이며, 이는 채널 팩토리를 단순화하고 가볍고 저렴한 옵저버 타워(watchtower)를 구축하며, 일방적인 탈퇴를 허용하면서 잘못된 상태를 남기지 않음으로써 라이트닝 네트워크의 전반적인 성능을 향상시킨다. APO는 CTV 기능을 시뮬레이션하는 데에도 사용할 수 있지만, 개인이 서명과 사전 서명된 거래를 저장해야 하므로 비용이 더 크고 효율이 CTV보다 떨어진다.
APO는 전적으로 새로운 키 버전을 요구한다는 점에서 비판을 받아왔다. 단순한 하위 호환성만으로는 구현할 수 없다. 또한 새로운 서명 해시 유형은 잠재적인 이중 지불(doublespend) 위험을 초래할 수 있다. 커뮤니티의 광범위한 논의 후, APO는 기존 서명에 일반 서명을 추가하도록 요구함으로써 보안 문제가 완화되었고, 이로 인해 BIP-118 번호를 획득했다.
OP_VAULT BIP-345
BIP-345는 OP_VAULT과 OP_VAULT_RECOVER 두 개의 새로운 오퍼코드를 제안하며, CTV와 결합하여 전용 계약을 구현한다. 이를 통해 사용자는 특정 토큰의 사용에 지연 기간을 강제할 수 있고, 지연 기간 중에는 복구 경로를 통해 이전 사용을 '취소'할 수 있다.
사용자는 특수한 Taproot 주소를 생성하여 금고를 구성할 수 있다. MAST에는 최소한 두 개의 스크립트가 포함되어야 하며, 하나는 예상 인출을 촉진하는 OP_VAULT 스크립트이고, 다른 하나는 인출 완료 전 언제든지 코인을 복구할 수 있도록 보장하는 OP_VAULT_RECOVER 스크립트이다.
OP_VAULT은 어떻게 중단 가능한 시간 잠금 인출을 구현할까? 간단히 말해, OP_VAULT 오퍼코드는 자신이 사용된 스크립트를 지정된 스크립트로 교체하는 일을 수행하며, 이는 MAST의 단일 리프 노드를 업데이트하는 것이며, 나머지 리프 노드는 변경되지 않는다. TLUV 설계와 유사하지만, OP_VAULT은 내부 키의 업데이트를 지원하지 않는다는 점이 다르다.
스크립트 업데이트 과정에 템플릿을 도입하면 지급 제한 효과를 얻을 수 있다. 여기서 시간 잠금 매개변수는 OP_VAULT에 의해 지정되며, CTV 오퍼코드가 제공하는 템플릿은 해당 스크립트 경로를 통해 지출되는 출력 집합을 제한한다.
BIP-345는 금고를 위해 탄생하였으며, OP_VAULT과 OP_VAULT_RECOVER를 통해 사용자는 안전한 위탁 방식을 가질 수 있다. 고보안 키(종이 지갑, 분산형 다중 서명 등)를 복구 경로로 사용하고, 일상 지불에는 일정한 지출 지연을 설정할 수 있다. 사용자의 장치는 지속적으로 금고의 지출 상황을 모니터링하며, 예기치 않은 이전이 발생하면 사용자가 복구할 수 있다.
BIP-345가 금고를 구현하는 과정에서는 수수료 문제를 고려해야 한다. 특히 복구 거래의 경우, CPFP, 임시 앵커(anchor), 새로운 서명 해시 플래그인 SIGHASH_GROUP 등의 실현 가능한 해결책이 있다.
TLUV (TapleafUpdateVerify)
TLUV 방안은 Taproot를 중심으로 구성되며, 공유된 UTXO의 효율적인 탈퇴 문제를 해결하는 것을 목표로 한다. 핵심 아이디어는 Taproot 출력이 사용될 때, TLUV 스크립트가 설명하는 업데이트 절차를 따라 Taproot 주소의 내부 구조와 암호학적 변환을 이용해 내부 키와 MAST를 부분적으로 업데이트함으로써 계약 기능을 실현하는 것이다.
TLUV 방안은 새로운 오퍼코드 TAPLEAF_UPDATE_VERIFY를 통해 다음 작업 중 하나 이상을 실행함으로써 현재 소비 입력을 기반으로 새로운 Taproot 주소를 생성할 수 있다:
-
내부 공개키 업데이트
-
메르클 경로 잘라내기
-
현재 실행 중인 리프 노드 제거
-
메르클 경로 끝에 새 리프 노드 추가
구체적으로, TLUV는 세 가지 입력을 받는다:
-
내부 공개키를 어떻게 업데이트할지 지정하는 것
-
메르클 경로에 새 리프 노드를 지정하는 것
-
현재 리프 노드와/또는 몇 개의 메르클 경로 리프 노드를 제거할지 지정하는 것
TLUV 오퍼코드는 업데이트된 scriptPubKey를 계산하고, 현재 입력에 해당하는 출력이 이 scriptPubKey로 지출되는지 검증한다.
TLUV의 영감을 준 시나리오는 공동 풀(CoinPool)이다. 현재 사전 서명된 거래만으로 공동 풀을 만들 수 있지만, 무허가 탈퇴를 원할 경우 지수적으로 증가하는 서명 수가 필요하다. 반면 TLUV는 사전 서명 없이 무허가 탈퇴를 가능하게 한다. 예를 들어, 친구들이 Taproot을 사용해 서로의 자금을 모아 공유 UTXO를 구성한다고 하자. 그들은 Taproot 키를 사용해 내부에서 자금을 이동시키거나 공동 서명으로 외부 지불을 시작할 수 있다. 개인은 언제든지 이 공동 풀에서 탈퇴하여 자신의 지불 경로를 삭제할 수 있으며, 나머지 사람들은 기존 경로를 계속 사용할 수 있다. 또한 개인의 탈퇴는 내부 다른 사람들의 추가 정보를 노출시키지 않는다. 비풀화된 거래와 비교할 때, 이 방식은 더욱 효율적이며 프라이버시를 보호한다.
TLUV 오퍼코드는 원래 MAST의 업데이트를 통해 부분적인 지출 제한을 구현하지만, 출력 금액에 대한 내성은 제공하지 않는다. 따라서 새로운 오퍼코드 IN_OUT_AMOUNT이 필요하며, 이는 두 가지 데이터를 스택에 푸시한다: 해당 입력 UTXO의 금액과 대응 출력의 금액. 이후 TLUV를 사용하는 사람은 수학 연산자를 사용해 자금이 업데이트된 scriptPubKey 내에 적절히 유지되었는지 검증할 수 있다.
출력 금액에 대한 내성은 또 다른 복잡성을 추가한다. 비트코인 금액은 사토시 단위로 최대 51비트가 필요하지만, 스크립트는 32비트 수학 연산만 허용하기 때문이다. 이를 해결하려면 스크립트 내 연산자의 동작을 재정의하거나, IN_OUT_AMOUNT를 대체하는 SIGHASH_GROUP을 사용해야 한다.
TLUV는 탈중앙화된 2층(Layer-2) 자금 풀에 솔루션을 제공할 가능성이 있으며, 물론 Taproot 공개키의 tweak 방식에 있어서 신뢰성은 아직 검증이 필요하다.
MATT
MATT(Merkleize All The Things)는 세 가지 목표를 달성하려 한다: 상태의 메르클화, 스크립트의 메르클화, 실행의 메르클화. 이를 통해 범용 스마트 계약을 실현한다.
상태의 메르클화: 상태 해시값을 리프 노드로 하는 메르클 트라이를 구성하며, 메르클 루트는 전체 계약의 상태를 나타낸다.
스크립트의 메르클화: MAST로 구성된 Tapscript에서, 각 리프 노드는 가능한 상태 전이 경로이다.
실행의 메르클화: 암호학적 커밋먼트와 사기 도전(fraud challenge) 메커니즘을 통해 실행을 메르클화한다. 임의의 계산 함수 f(x)=y에 대해 참여자는 오프체인에서 계산 후 커밋을 게시하고, 다른 참여자가 잘못된 결과 f(x)=z를 발견하면 도전할 수 있다. 이후 이진 탐색 방식으로 중재되며, 이는 Optimistic Rollup과 원리가 동일하다.
메르클화된 실행 - 사기 도전
MATT를 구현하기 위해 비트코인 프로그래밍 스크립트는 다음과 같은 기능이 필요하다:
-
출력이 특정 스크립트(및 그 금액)를 가지도록 강제
-
출력에 데이터 첨부
-
현재 입력(또는 다른 입력)의 데이터 읽기
두 번째 항목은 매우 중요하다. 동적 데이터는 지출자가 제공하는 입력 데이터를 통해 상태를 계산할 수 있음을 의미하며, 이는 상태 기계를 시뮬레이션하고 다음 상태와 첨부 데이터를 결정할 수 있게 한다. MATT 방안은 OP_CHECKCONTRACTVERIFY(OP_CCV) 오퍼코드를 제안하여, 기존의 OP_CHECKOUTPUTCONTRACTVERIFY와 OP_CHECKINPUTCONTRACTVERIFY 오퍼코드를 통합하고, 추가적인 flags 파라미터로 대상을 지정한다.
출력 금액 제어: 가장 직접적인 방법은 직접적인 내성이지만, 출력 금액은 64비트 숫자이며 64비트 연산이 필요해 비트코인 스크립트에서 구현하기 매우 복잡하다. CCV는 OP_VAULT과 유사한 지연 검사 방식을 채택한다. 동일한 출력을 가리키는 CCV를 포함하는 모든 입력의 금액을 합산하여 해당 출력 금액의 하한선으로 삼는다. 지연되는 이유는 이 검사가 입력 스크립트 평가 중이 아니라 거래 처리 과정에서 이루어지기 때문이다.
사기 증명의 보편성 덕분에 MATT 계약의 일부 변형은 모든 유형의 스마트 계약이나 2층 구조를 구현할 수 있을 것이다. 다만 자본 잠금 및 도전 기간 지연과 같은 추가 요건은 정확하게 평가되어야 한다. 어떤 애플리케이션이 수용 가능한 거래인지 평가하기 위한 추가 연구가 필요하다. 예를 들어, 암호학적 커밋먼트와 사기 도전 메커니즘을 사용해 OP_ZK_VERIFY 함수를 시뮬레이션하여 비트코인 상에서 신뢰 없는 롤업을 구현할 수 있다.
실제로 이런 일이 이미 진행되고 있다. Johan Torås Halseth는 MATT 소프트포크 제안의 OP_CHECKCONTRACTVERIFY 오퍼코드를 사용해 elftrace를 구현하였으며, 이는 RISC-V 컴파일을 지원하는 모든 프로그램을 비트코인 체인 상에서 검증할 수 있게 한다. 계약 프로토콜의 일방이 계약을 통해 자금을 인출할 수 있도록 하여, 비트코인 네이티브 검증 브리지를 실현하였다.
CSFS (OP_CHECKSIGFROMSTACK)
APO 오퍼코드 소개에서 살펴보았듯이, OP_CHECKSIG(및 관련 오퍼코드)는 거래 조합, 해시 처리, 서명 검증을 담당한다. 하지만 검증하는 메시지는 해당 오퍼코드를 사용하는 거래의 직렬화로부터 얻어지며, 다른 메시지를 지정할 수 없다. 간단히 말해, OP_CHECKSIG는 서명 메커니즘을 통해 거래 입력으로서의 UTXO가 서명 소유자에게 사용 권한이 있는지 검증함으로써 비트코인의 보안을 지킨다.
CSFS는 이름에서 알 수 있듯이, 스택(stack)에서 서명을 검사한다. CSFS 오퍼코드는 스택에서 세 가지 매개변수—서명, 메시지, 공개키—를 받아 서명의 유효성을 검증한다. 이를 통해 사용자는 위트니스 데이터를 통해 스택에 임의의 메시지를 전달하고 CSFS로 검증할 수 있으며, 이는 비트코인 상의 혁신을 가능하게 한다.
CSFS의 유연성은 지불 서명, 권한 위임, 오라클 계약, 이중 지불 보호 채권 등 다양한 메커니즘을 실현할 수 있게 하며, 무엇보다 거래 내성을 가능하게 한다. CSFS를 이용한 거래 내성 원리는 매우 간단하다. 위트니스를 통해 OP_CHECKSIG가 사용하는 거래 내용을 스택에 푸시한 후, 동일한 공개키와 서명을 사용하여 CSFS와 OP_CHECKSIG 모두에서 검증을 수행한다. 두 검증이 모두 성공하면, CSFS에 전달된 임의 메시지의 내용은 OP_CHECKSIG에 암시적으로 사용된 직렬화된 지출 거래(및 기타 데이터)와 동일하다는 의미가 되며, 이로써 스택 상에 검증된 거래 데이터를 얻게 되어 다른 오퍼코드를 통해 지출 거래에 제한을 걸 수 있다.
CSFS는 일반적으로 OP_CAT과 함께 사용된다. OP_CAT을 통해 거래의 다양한 필드를 연결하여 직렬화할 수 있으므로, 내성 대상 필드를 더욱 정밀하게 선택할 수 있다. OP_CAT이 없다면 스크립트는 개별적으로 검사 가능한 데이터로부터 해시를 다시 계산할 수 없으며, 실제로 할 수 있는 것은 해시가 특정 값과 동일한지 확인하는 정도뿐이다. 이는 코인이 단 하나의 특정 거래로만 사용될 수 있음을 의미한다.
CSFS는 CLTV, CSV, CTV, APO 등의 오퍼코드를 모두 구현할 수 있으며, 범용 내성 오퍼코드이므로 비트코인 2층 확장 솔루션에도 도움이 된다. 단점은 스택에 전체 서명된 거래 사본을 추가해야 하므로 CSFS를 사용해 내성을 수행하는 거래의 크기가 상당히 커질 수 있다는 점이다. 반면 CLTV나 CSV와 같은 단일 목적 내성 오퍼코드는 오버헤드가 최소이며, 각 새로운 특수 내성 오퍼코드를 추가하려면 합의 변경이 필요하다.
TXHASH (OP_TXHASH)
OP_TXHASH는 매우 직접적인 내성 오퍼코드로, 연산자가 특정 필드의 해시를 스택에 푸시할 수 있게 한다. 구체적으로, OP_TXHASH는 스택에서 txhash 플래그를 팝하고, 해당 플래그에 따라 (표시된) txhash를 계산한 후 결과 해시를 스택에 푸시한다.
TXHASH와 CTV의 유사성으로 인해 커뮤니티 내에서 두 기술에 대한 논의가 많았다.
TXHASH는 CTV의 범용 업그레이드로 볼 수 있으며, 사용자가 지출 거래의 일부를 명시할 수 있는 고급 거래 템플릿을 제공한다. 이는 거래 수수료 관련 많은 문제를 해결한다. 다른 계약 오퍼코드들과 비교할 때, TXHASH는 위트니스에 필요한 데이터 사본을 제공할 필요가 없어 저장 요구를 더욱 낮춘다. CTV와 달리 TXHASH는 NOP 호환되지 않으며 tapscript에서만 구현 가능하다. TXHASH와 CSFS의 조합은 CTV와 APO의 대안으로 사용될 수 있다.
계약 구축 방식 측면에서, TXHASH는 '덧셈 계약'을 더 쉽게 구현한다. 고정하려는 거래 데이터의 모든 부분을 스택에 푸시하고, 모두 함께 해시한 후 결과 해시가 고정된 값과 일치하는지 검증한다. 반면 CTV는 '뺄셈 계약'을 더 쉽게 구현한다. 자유롭게 두려는 거래 데이터의 모든 부분을 스택에 푸시한 후, 거래 해시 데이터 접두사를 커밋한 고정된 중간 상태에서 시작하여 롤링 OP_SHA256을 사용한다. 자유 부분은 이 중간 상태에 해시된다.
TXHASH 사양에서 정의한 TxFieldSelector 필드는 OP_TX 등의 다른 오퍼코드로 확장될 가능성이 있다.
TXHASH 관련 BIP는 현재 Github에서 초안(Draft) 상태이며, 번호는 미정이다.
OP_CAT
OP_CAT은 보안 문제로 중본사토시에 의해 폐기되었다가 최근 비트코인 핵심 개발자들 사이에서 다시 활발히 논의되며 인터넷 밈(meme) 문화를 일으키기도 한 미스터리한 오퍼코드이다. 결국 OP_CAT은 BIP-347을 승인받았으며, 많은 사람들이 최근 가장 가능성이 높은 BIP 제안이라고 평가한다.
사실 OP_CAT의 동작은 매우 간단하다. 스택의 두 요소를 하나로 연결(concatenate)하는 기능이다. 이것이 어떻게 계약 기능을 구현할 수 있을까?
실제로 두 요소를 연결하는 기능은 강력한 암호학 데이터 구조인 메르클 트라이(Merkle Trie)에 대응한다. 메르클 트라이를 구성하려면 연결과 해시 두 가지 연산만 있으면 되며, 비트코인 스크립트에서는 해시 함수가 사용 가능하다. 따라서 OP_CAT이 생기면 이론적으로 비트코인 스크립트에서 메르클 프루프(Merkle Proof)를 검증할 수 있게 되며, 이는 블록체인에서 가장 일반적으로 사용되는 경량 검증 방식이다.
앞서 언급했듯이, CSFS는 OP_CAT의 도움을 받아 범용 계약 방안을 구현할 수 있다. 사실 CSFS 없이도 Schnorr 서명 구조를 활용하면 OP_CAT 자체로 거래 내성을 실현할 수 있다.
Schnorr 서명에서 서명할 메시지는 다음 필드들로 구성된다:
이 필드들은 거래의 주요 요소를 포함하며, 이를 scriptPubKey 또는 위트니스에 배치하고 OP_CAT과 OP_SHA256을 사용하면 Schnorr 서명을 구성하고 OP_CHECKSIG로 검증할 수 있다. 검증이 성공하면 스택에 검증된 거래 데이터가 남게 되어 거래의 각 부분(예: 입력, 출력, 대상 주소, 관련 비트코인 금액 등)을 추출하고 '검사'할 수 있다.
구체적인 암호학 원리는 Andrew Poelstra가 발표한 "CAT and Schnorr Tricks" 글을 참조할 수 있다.
결론적으로, OP_CAT의 유연성은 거의 모든 계약 오퍼코드를 시뮬레이션할 수 있게 하며, 많은 계약 오퍼코드가 OP_CAT의 기능에 의존하기 때문에 합의 리스트에서 위치가 크게 앞당겨졌다. 이론적으로 OP_CAT과 기존 비트코인 오퍼코드만으로도 신뢰를 최소화한 BTC ZK 롤업을 구성할 수 있으며, Starknet, Chakra 및 기타 생태계 파트너들이 이를 실현하기 위해 적극적으로 노력하고 있다.
결론
비트코인을 확장하고 그 프로그래밍 가능성을 향상시키기 위한 다양한 전략을 탐색하면서, 앞으로의 길은 로컬 개선, 오프체인 계산, 복잡한 스크립트 기능의 결합이라는 점이 명백해졌다.
유연한 기반 계층이 없다면 더 유연한 2층을 구축할 수 없다.
오프체인 계산 기반 확장이 미래이지만, 비트코인의 프로그래밍 가능성은 진정한 세계 화폐가 되기 위해 반드시 돌파구를 마련해야 한다.
그러나 비트코인의 계산은 이더리움의 계산과 본질적으로 다르다. 비트코인은 '검증'만을 계산 형태로 지원하며 일반 계산은 불가능하다. 반면 이더리움은 본질적으로 계산 중심이며 검증은 계산의 부산물이다. 이 차이는 다음 점에서 드러난다: 이더리움은 실패한 거래에도 가스 형태의 수수료를 부과하지만, 비트코인은 그렇지 않다.
계약은 계산이 아닌 검증을 기반으로 한 스마트 계약 형태를 실현한다. 계약에 관해서는 소수의 중본 원교주의자를 제외하면 모두가 비트코인을 개선하는 좋은 선택이라고 생각하는 듯하다. 그러나 커뮤니티는 어느 방식으로 계약을 구현할지에 대해 여전히 격렬하게 논쟁하고 있다.
APO, OP_VAULT, TLUV는 직접적인 애플리케이션에 더 초점을 맞추며, 이를 선택하면 특정 애플리케이션을 보다 저렴하고 효율적인 방식으로 구현할 수 있다. 라이트닝 네트워크 애호가는 LN-Symmetry를 구현할 수 있는 APO를 선호할 것이며, 금고를 구현하려면 OP_VAULT이 가장 좋다. CoinPool을 구축하려면 TLUV가 프라이버시와 효율성 측면에서 더 우수하다. OP_CAT과 TXHASH는 더욱 범용적이며 보안 취약점 가능성도 작고, 다른 오퍼코드와의 조합으로 더 많은 용례를 실현할 수 있지만, 스크립트의 복잡성이라는 대가를 치를 수도 있다. CTV와 CSFS는 블록체인 처리 과정을 조정하는데, CTV는 지연 출력을, CSFS는 지연 서명을 구현한다. MATT는 다소 독특한데, 낙관적 실행과 사기 증명 개념을 활용해 메르클 트라이 구조로 범용 스마트 계약을 실현하지만, 여전히 내성 기능을 위한 새로운 오퍼코드가 필요하다.
우리는 비트코인 커뮤니티가 소프트포크를 통해 비트코인에 계약 기능을 부여할 가능성에 대해 격렬하게 논의하고 있음을 목격하고 있다. Starknet은 공식적으로 비트코인 생태계에 진입한다고 발표하며, OP_CAT 병합 후 6개월 이내에 비트코인 네트워크 상에서의 정산을 실현할 계획이라고 밝혔다. Chakra는 비트코인 생태계의 최신 동향을 계속 주시하며 OP_CAT 소프트포크 병합을 추진하고, 내성과 계약이 가져오는 프로그래밍 가능성을 활용해 더욱 안전하고 효율적인 비트코인 정산 계층을 구축할 것이다.
이 글의 검토 및 제안을 해준 Jeffrey, Ben, Mutourend, Lynndell께 감사드립니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@ChakraChain
