약정: 비트코인의 프로그래밍 가능성
저자: HashKey Capital 투자 리서치 책임자 Jeffrey HU, HashKey Capital 투자 매니저 Harper LI
최근 비트코인 커뮤니티에서는 OP_CAT 등 연산 코드의 재도입을 둘러싼 논의가 활발히 이루어지고 있다. Taproot Wizard는 Quantum Cats NFT 출시 및 BIP-420 번호 확보 선언 등을 통해 많은 관심을 받고 있다. 지지자들은 OP_CAT 도입 시 「제한 조항(covenants)」 구현이 가능해져 비트코인의 스마트 계약 또는 프로그래밍 기능이 실현될 수 있다고 주장한다.
여기서 「제한 조항」이라는 용어를 주목해 살펴보면, 이 또한 매우 깊은 주제임을 알 수 있다. 개발자들은 오랜 기간 동안 OP_CAT 외에도 OP_CTV, APO, OP_VAULT 등 제한 조항을 구현하는 다양한 기술에 대해 논의해왔다.
그렇다면 비트코인의 「제한 조항」이란 정확히 무엇이며, 왜 이렇게 많은 개발자들이 수년간 집중하고 있는 것일까? 어떤 프로그래밍 기능을 실현할 수 있으며, 그 설계 원리는 무엇일까? 본문에서는 이러한 점들을 개괄적으로 소개하고 논의하고자 한다.
「제한 조항」이란 무엇인가?
Covenants(제한 조항)은 미래의 비트코인 거래에 조건을 설정할 수 있는 메커니즘으로, 때로는 「계약」이라고도 번역된다.
현재의 비트코인 스크립트도 일정한 제한 조건을 포함하고 있는데, 예를 들어 유효한 서명 입력, 적절한 스크립트 제공 등의 조건을 만족해야 한다. 그러나 사용자가 해당 조건을 해제할 수만 있다면, UTXO를 원하는 어디든 자유롭게 사용할 수 있다.
반면 「제한 조항」은 단순한 해제 조건을 넘어, UTXO의 이후 사용 방식까지 제한하는 추가적인 규칙을 설정할 수 있다. 즉, 자금의 특정 목적 전용 사용 효과를 실현하거나, 거래 내 다른 입력 조건 등을 제한할 수 있다.
보다 엄밀히 말하면, 현재의 비트코인 스크립트에도 일부 제한 조항 기능이 존재한다. 예를 들어 시간 잠금(time lock) 연산 코드는 거래의 nLock 또는 nSequence 필드를 확인하여 거래 사용 전의 시간적 제한을 구현한다. 하지만 기본적으로 시간 관련 제한에 국한된다.
그렇다면 왜 개발자와 연구자들은 이러한 제한 검사를 설계하려 하는가? 제한 조항은 단순히 제한을 위한 것이 아니라, 거래 실행 규칙을 설정하기 위함이다. 이를 통해 사용자는 미리 정의된 규칙에 따라 거래를 실행하게 되며, 이는 사전에 계획된 비즈니스 프로세스를 보장한다.
다소 역설적이지만, 이는 오히려 더 많은 응용 시나리오를 가능하게 한다.
응용 시나리오
스테이킹 페널티 보장
제한 조항의 가장 직관적인 예시 중 하나는 Babylon이 비트코인 스테이킹 과정에서 적용한 slash(벌금) 거래이다.
Babylon의 비트코인 스테이킹 과정은 사용자가 자신의 BTC 자산을 메인체인 상 특수 스크립트로 전송하는 것으로 구성되며, 사용 조건은 다음과 같다:
-
행복한 종료(Happy ending): 일정 시간 후 사용자의 서명으로 해제 가능, 즉 언스테이킹(unstake) 완료
-
불리한 종료(Bad ending): 사용자가 Babylon이 보안을 임대한 PoS 체인에서 이중 서명 등 악의적인 행위를 할 경우, EOTS(Extractable One-Time Signatures, 추출 가능한 일회용 서명)를 통해 자산을 해제하고, 네트워크 내 실행 역할을 가진 자가 일부 자산을 강제로 소각 주소(slash)로 전송
출처: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy
여기서 「강제 전송」을 주목할 필요가 있다. 즉, UTXO를 해제할 수 있더라도 해당 자산은 임의의 장소가 아닌 반드시 소각되어야 한다. 이를 통해 악의적인 사용자가 자신의 알려진 서명을 이용해 자산을 먼저 자신에게 전송함으로써 처벌을 회피하는 것을 방지할 수 있다.
이러한 기능은 OP_CTV 등의 제한 조항이 도입되면, 스테이킹 스크립트의 「bad ending」 분기에서 OP_CTV 연산 코드를 추가해 구현할 수 있다.
하지만 OP_CTV가 활성화되기 전에는 Babylon이 변칙적인 방법을 사용해, 사용자와 위원회가 공동으로 실행하는 방식으로 제한 조항의 강제 실행 효과를 모사하고 있다.
혼잡 제어
일반적으로 혼잡이란 비트코인 네트워크의 수수료율이 높아지고 트랜잭션 풀(transaction pool)에 많은 거래가 대기하면서, 사용자가 빠른 거래 확인을 원할 경우 높은 수수료를 지불해야 하는 상황을 의미한다.
이때 사용자가 여러 수취인에게 다수의 거래를 보내야 한다면, 높은 수수료 부담을 감내해야 하며, 이는 전체 네트워크의 수수료율을 더욱 높이는 원인이 된다.
제한 조항이 있다면, 발신자는 우선 대량 송금 거래를 약속할 수 있다. 이 약속을 통해 모든 수취인은 최종 거래가 이루어질 것임을 신뢰할 수 있고, 낮은 수수료율 시점에 실제 거래를 전송하면 된다.
아래 그림과 같이, 블록 공간 수요가 높을 때 거래는 매우 비싸다. OP_CHECKTEMPLATEVERIFY를 사용하면, 대규모 결제 처리업체는 모든 지불금을 단일 O(1) 거래로 집계하여 확인할 수 있다. 이후 블록 공간 수요가 감소했을 때, 해당 UTXO에서 지불금을 확장할 수 있다.
출처: https://utxos.org/uses/scaling/
이 시나리오는 OP_CTV 제안의 대표적인 활용 사례이다. 그 외에도 https://utxos.org/uses/ 에서는 혼잡 제어 외에도 Soft Fork Bets, Decentralized options, Drivechains, Batch Channels, Non Interactive Channels, Trustless Coordination-Free Mining Pools, Vaults, Safer Hashed Time Locked Contracts (HTLCS) Limits 등의 다양한 활용 사례를 확인할 수 있다.
금고(Vault)
금고(vault)는 비트코인 애플리케이션에서 광범위하게 논의되는 시나리오 중 하나로, 특히 제한 조항 분야에서 중요하다. 일상적인 운영에서 자금 보관과 사용 수요 사이의 균형을 맞추는 것이 불가피하므로, 자금을 안전하게 보호하고, 심지어 계정이 해킹당해(비밀키 유출)도 자금 사용을 제한할 수 있는 금고 애플리케이션이 요구된다.
제한 조항 기술을 기반으로 하면, 금고 유형 애플리케이션을 비교적 쉽게 구축할 수 있다.
OP_VAULT 설계 방안을 예로 들면, 금고 자금 사용 시 먼저 체인 상에 거래를 전송해야 한다. 이 거래는 금고 사용 의도(trigger)를 표시하며, 다음 조건을 설정한다:
-
정상적인 경우, 두 번째 거래는 최종 인출 거래이며, N개의 블록을 기다린 후 자금을 임의의 장소로 추가 사용 가능
-
이 거래가 도난당했거나(또는 「몽둥이 공격(wrench attack)」에 의해 강요된 경우), N개의 블록 내 인출 거래 전에 즉시 다른 안전한 주소(사용자가 더 안전하게 관리하는)로 전송 가능
OP_VAULT 프로세스, 출처: BIP-345
주의할 점은, 제한 조항 없이도 금고 애플리케이션을 구축할 수 있다는 것이다. 한 가지 가능한 방법은 비밀키로 이후 사용을 위한 서명을 미리 준비한 후 해당 비밀키를 파기하는 것이다. 하지만 여전히 제한이 많다. 예를 들어 비밀키가 진정으로 파기되었는지 확인해야 하며(제로 kiến식 증명의 trusted setup 과정과 유사), 금액과 수수료가 사전에 결정되어야 하므로(사전 서명 필요) 유연성이 떨어진다.
OP_VAULT과 사전 서명 기반 금고 프로세스 비교, 출처: BIP-345
더 견고하고 유연한 상태 채널
일반적으로 라이트닝 네트워크를 포함한 상태 채널은 메인체인과 거의 동등한 보안성을 가진다고 간주된다(노드가 최신 상태를 관찰하고 정상적으로 최신 상태를 체인에 게시할 수 있는 경우). 그러나 제한 조항이 도입되면, 라이트닝 네트워크를 기반으로 더 견고하거나 유연한 새로운 상태 채널 설계가 가능해진다. 여기에는 Eltoo, Ark 등이 있다.
Eltoo(또는 LN-Symmetry)는 대표적인 사례 중 하나이다. 이 기술은 「L2」의 발음을 차용하여, 라이트닝 네트워크를 위한 실행 계층을 제안하며, 이후 채널 상태가 이전 상태를 대체할 수 있도록 하고, 패널티 메커니즘 없이도 작동한다. 따라서 라이트닝 네트워크 노드처럼 이전 상태를 여러 개 저장하여 상대방의 악의적 행위를 방지할 필요도 없다. 이를 위해 Eltoo는 APO(BIP-118)라고도 불리는 SIGHASH_NOINPUT 서명 방식을 제안한다.
Ark는 라이트닝 네트워크의 입금 유동성 및 채널 관리의 어려움을 줄이려 한다. Ark는 일정 기간 동안 서비스 제공자를 거래 상대방으로 삼아 오프체인에서 가상 UTXO(vUTXO) 거래를 수행할 수 있는 joinpool 형태의 프로토콜이며, 체인 상에서는 하나의 UTXO를 공유함으로써 비용을 절감한다. 금고와 마찬가지로, Ark도 현재의 비트코인 네트워크에서 구현 가능하지만, 제한 조항을 도입하면 거래 템플릿을 기반으로 필요한 상호작용 양을 줄이고, 더 탈중앙화된 단방향 종료를 실현할 수 있다.
제한 조항 기술 개요
위 응용 사례에서 볼 수 있듯이, 제한 조항은 특정 기술이라기보다는 효과에 가깝기 때문에 다양한 구현 방식이 존재한다. 이를 분류하면 다음과 같다:
-
유형: 일반형, 전용형
-
구현 방식: Opcode 기반, 서명 기반
-
재귀성: 재귀적, 비재귀적
여기서 재귀성은, 일부 제한 조항 구현이 다음 출력을 제한함으로써 그 다음 출력까지 제한할 수 있어, 제한 조건이 단일 거래를 넘어 더 깊은 거래 깊이까지 확장될 수 있음을 의미한다.
주요 제한 조항 설계 사례로는 다음과 같은 것들이 있다:
*재귀성: OP_CAT과 함께 사용 시
제한 조항 설계
앞선 설명에서 알 수 있듯이, 현재의 비트코인 스크립트는 주로 해제 조건을 제한할 뿐, 해당 UTXO의 이후 사용 방식은 제한하지 않는다. 제한 조항을 구현하려면 반대로 생각해야 한다. 왜 현재의 비트코인 스크립트는 제한 조항을 구현할 수 없는가?
주요 이유는 현재의 비트코인 스크립트가 거래 자체의 내용을 읽을 수 없기 때문이다. 즉, 거래의 「내성(introspection)」이 불가능하다.
만약 거래의 내성을 구현할 수 있다면—즉 거래의 출력을 포함한 모든 내용을 검사할 수 있다면—제한 조항을 구현할 수 있다.
따라서 제한 조항의 설계 아이디어는 주로 어떻게 내성을 구현할 것인지에 초점을 맞춘다.
Opcode 기반 vs 서명 기반
가장 단순한 아이디어는 하나 이상의 연산 코드(opcode)를 추가하는 것이다(단일 opcode + 다양한 매개변수, 혹은 기능이 다른 다수의 opcode). 이를 통해 직접 거래 내용을 읽을 수 있게 되는데, 이것이 바로 Opcode 기반 접근법이다.
다른 접근법은 스크립트 내에서 직접 거래 내용을 읽고 검사하지 않고, 거래 내용의 해시를 활용하는 것이다. 만약 이 해시에 이미 서명했다면, OP_CHECKSIG 등을 개조해 이 서명을 검증함으로써 간접적으로 거래 내성 및 제한 조항을 구현할 수 있다. 이것이 바로 서명 기반 설계 방식이며, APO 및 OP_CSFS 등이 포함된다.
APO
SIGHASH_ANYPREVOUT(APO)는 제안된 비트코인 서명 방식 중 하나이다. 서명의 가장 간단한 방법은 거래의 입력과 출력 모두에 대해 커밋하는 것이지만, 비트코인은 더 유연한 방법을 제공하는데, SIGHASH는 거래의 입력이나 출력 중 일부만 선택적으로 커밋할 수 있다.
현재 SIGHASH 및 조합이 거래 입력·출력에 적용되는 범위 (출처: 『Mastering Bitcoin, 2nd』)
위 그림에서 보듯, ALL은 전체 데이터에 적용되지만, NONE은 모든 입력에만 적용되고 출력에는 적용되지 않는다. SINGLE은 동일한 입력 순번의 출력에만 적용된다. 또한 SIGHASH는 조합 가능하며, ANYONECANPAY 수식어를 추가하면 단일 입력에만 적용된다.
반면 APO의 SIGHASH는 출력에만 서명하고 입력 부분에는 서명하지 않는다. 즉, APO 방식으로 서명된 거래는 이후 조건을 만족하는 임의의 UTXO에 추가될 수 있다.
이러한 유연성이 바로 APO가 제한 조항을 구현하는 이론적 기반이다:
-
미리 하나 이상의 거래를 생성
-
이 거래 정보를 기반으로 하나의 서명만 계산 가능한 공개키 생성
-
이 공개키 주소로 전송된 자산은 미리 생성된 거래를 통해서만 사용 가능
특히 이 공개키는 대응하는 비밀키가 없으므로, 자산이 반드시 미리 생성된 거래를 통해서만 사용됨을 보장할 수 있다. 따라서 미리 생성된 거래에서 자산의 이동 경로를 규정함으로써 제한 조항을 실현할 수 있다.
이더리움 스마트 계약과 비교해 이해할 수 있다. 스마트 계약은 EOA 서명으로 임의로 사용하는 것이 아니라, 일정 조건을 만족해야만 계약 주소에서 인출할 수 있다. 비트코인도 서명 메커니즘 개선을 통해 유사한 효과를 달성할 수 있는 것이다.
다만, 이 과정에는 순환 의존성 문제가 발생하는데, 입력 내용을 알고 있어야 사전 서명 및 거래 생성이 가능하기 때문이다.
APO 및 SIGHASH_NOINPUT은 이러한 순환 의존 문제를 해결하며, 계산 시 입력 내용이 아닌 출력만 알고 있으면 된다.
OP_CTV
OP_CHECKTEMPLATEVERIFY(CTV), 즉 BIP-119는 Opcode 개선 방식을 채택한다. CTV는 commitment hash를 매개변수로 받아, 해당 연산 코드를 실행하는 모든 거래가 해당 commitment와 일치하는 출력 세트를 포함하도록 요구한다. 이를 통해 비트코인 사용자가 비트코인 사용 방식을 제한할 수 있게 된다.
이 제안은 초기에는 OP_CHECKOUTPUTSHASHVERIFY(COSHV)라는 이름으로 시작했으며, 혼잡 제어 거래 생성 능력에 초점을 맞췄기 때문에, 너무 구체적이며 일반성이 부족하다는 비판을 받았다.
앞서 언급한 혼잡 제어 사례에서, 발신자 Alice는 10개의 출력을 생성하고 이들의 해시값을 계산한 후, 이 해시값을 사용해 COSHV를 포함한 tapleaf 스크립트를 생성할 수 있다. 또한 참여자의 공개키를 사용해 Taproot 내부 키를 형성함으로써, Taproot 스크립트 경로를 노출하지 않고도 공동 지출이 가능하게 할 수 있다.
이후 Alice는 10개 출력의 사본을 각 수취인에게 제공하여, 모두가 Alice의 설정 거래를 검증할 수 있도록 한다. 이후 이 지불금을 사용하고자 할 때, 누구든지 commitment와 일치하는 출력을 포함한 거래를 생성할 수 있다.
전체 과정에서, Alice가 설정 거래를 생성하고 전송할 때, 기존의 비동기 통신 수단(예: 이메일 또는 클라우드 드라이브)을 통해 10개 출력 사본을 전송할 수 있다. 즉, 수취인은 온라인 상태일 필요도 없으며 서로 상호작용할 필요도 없다.
출처:
https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
APO와 마찬가지로, 지출 조건에 따라 주소를 구성할 수 있으며, 다양한 방식으로 「잠금」을 만들 수 있다. 예를 들어 추가 키, 시간 잠금, 조합 가능한 논리 등을 포함할 수 있다.
출처:
https://twitter.com/OwenKemeys/status/1741575353716326835
CTV는 거래 데이터를 해시한 후, 지출 거래가 정의된 것과 일치하는지 검사할 수 있도록 하며, 거래 데이터를 「열쇠」로 사용한다.
위 10명의 수취인 예시를 확장해 보면, 수취인은 자신의 주소 키를 서명되었으나 브로드캐스트되지 않은 tx로 다음 수취인에게 전달할 수 있으며, 이를 반복하면 아래 그림과 같은 트리 구조가 형성된다. Alice는 체인 상에서 단 1 utxo의 블록 공간만으로 다수 사용자의 계정 잔액 변경을 포함하는 구조를 만들 수 있다.
출처:
https://twitter.com/OwenKemeys/status/1741575353716326835
그리고 이 트리의 잎사귀 중 하나가 라이트닝 채널, 콜드 스토리지, 기타 지불 경로라면 어떻게 될까? 그러면 이 트리는 단일 차원 다층 지출 트리에서 다차원 다층 지출 트리로 확장되어, 지원 가능한 시나리오가 더욱 풍부하고 유연해진다.
출처:
https://twitter.com/OwenKemeys/status/1744181234417140076
CTV는 2019년 COSHV에서 명칭 변경을 시작으로, 2020년 BIP-119 번호 배정, CTV 계약을 위한 프로그래밍 언어 Sapio 등장, 2022~2023년 커뮤니티의 활발한 논의 및 업데이트, 활성화 방안에 대한 논쟁 등을 거쳐, 현재까지도 활발히 논의되는 소프트포크 업그레이드 제안 중 하나이다.
OP_CAT
OP_CAT은 앞서 소개했듯이 현재 매우 주목받는 업그레이드 제안으로, 스택 내 두 요소를 연결(concatenate)하는 기능을 제공한다. 단순해 보이지만, OP_CAT은 스크립트 내에서 매우 유연하게 다양한 기능을 구현할 수 있다.
가장 직접적인 예는 머클 트리(Merkle tree) 관련 작업이다. 머클 트리는 두 요소를 연결한 후 해시하는 것으로 이해할 수 있다. 현재 비트코인 스크립트에는 OP_SHA256 등 해시 연산 코드가 있으므로, OP_CAT로 두 요소를 연결할 수 있다면, 스크립트 내에서 머클 트리 검증 기능을 구현할 수 있으며, 이는 경량 클라이언트 검증 능력을 어느 정도 갖추게 되는 것이다.
또 다른 기반은 Schnorr 서명 강화이다. 스크립트의 사용 서명 조건을 사용자의 공개키와 공개 nonce의 연결로 설정할 수 있다. 이후 서명자가 이 자금을 다른 곳으로 사용하기 위해 또 다른 거래를 서명하려면 동일한 nonce를 사용해야 하며, 이는 비밀키 유출로 이어진다. 즉, OP_CAT을 통해 nonce에 대한 커밋을 구현함으로써, 기존 서명 거래의 유효성을 보장하는 것이다.
OP_CAT의 다른 응용 사례로는 Bistream, Tree Signatures, 양자 저항 Lamport 서명, 금고 등이 있다.
OP_CAT 자체는 새로운 기능이 아니다. 비트코인 초기 버전에 존재했으나, 공격에 악용될 수 있다는 이유로 2010년부터 비활성화되었다. 예를 들어 OP_DUP와 OP_CAT을 반복 사용하면 풀 노드의 스택 폭발(stack explosion)을 쉽게 유도할 수 있다(데모 참조).
그러나 현재 OP_CAT을 다시 활성화해도 이전의 스택 폭발 문제가 발생할까? 현재 제안된 OP_CAT은 tapscript 내에서만 활성화되며, tapscript는 각 스택 요소의 크기를 520바이트 이하로 제한하므로, 과거의 스택 폭발 문제는 발생하지 않는다. 일부 개발자들은 중본聪가 OP_CAT을 직접 비활성화한 것이 지나치게 엄격했을 수 있다고 생각한다. 그러나 OP_CAT의 유연성 때문에 현재로서는 모든 취약점 시나리오를 완전히 예측하기 어렵다.
따라서 응용 가능성과 잠재적 위험을 종합적으로 고려해, 최근 OP_CAT은 큰 관심을 받고 있으며, PR 리뷰도 진행되었으며, 현재 가장 핫한 업그레이드 제안 중 하나이다.
맺음말
「자율이 자유를 가져온다.」 앞서 소개한 바와 같이, 제한 조항은 비트코인 스크립트 내에서 거래의 추가 사용을 제한함으로써, 스마트 계약과 유사한 거래 규칙을 실현할 수 있다. BitVM과 같은 오프체인 방식에 비해, 이러한 프로그래밍 방식은 비트코인 상에서 더 원시적으로 검증 가능하며, 메인체인 애플리케이션(혼잡 제어), 오프체인 애플리케이션(상태 채널), 기타 새로운 응용 방향(스테이킹 페널티 등)을 개선할 수 있다.
제한 조항 기술이 일부 저수준 업그레이드와 결합되면, 프로그래밍 가능성의 잠재력이 더욱 확장될 수 있다. 예를 들어 최근 검토 중인 64비트 연산자 제안은, 제안된 TechFlow 공식 커뮤니티에 오신 것을 환영합니다 Telegram 구독 그룹:https://t.me/TechFlowDaily 트위터 공식 계정:https://x.com/TechFlowPost 트위터 영어 계정:https://x.com/BlockFlow_News
