Covenants의 상세 설명: 비트코인의 프로그래머블성을 어떻게 실현할 것인가?

저자: Jeffrey HU, Harper LI, HashKey Capital

최근 비트코인 커뮤니티에서는 OP _ CAT 등의 연산 코드를 재활용하자는 논의가 일고 있습니다. Taproot Wizard는 Quantum Cats NFT를 출시하고 BIP -420 번호를 획득했다고 주장하며 많은 사람들의 주목을 끌었습니다. 지지자들은 OP _ CAT을 활성화하면 "제한 조항"(covenants)을 구현하고 비트코인의 스마트 계약 또는 프로그래머블성을 실현할 수 있다고 주장합니다.

"제한 조항"이라는 단어를 주목하고 조금 검색해보면, 이는 또 다른 큰 토끼굴이라는 것을 알 수 있습니다. 개발자들은 수년간 OP _ CAT 외에도 OP _ CTV, APO, OP _ VAULT 등 제한 조항을 구현하는 기술에 대해 논의해왔습니다.

그렇다면 비트코인의 "제한 조항"이란 무엇일까요? 왜 이렇게 많은 개발자들이 수년간 지속적으로 관심과 논의를 쏟고 있을까요? 비트코인의 어떤 프로그래머블성을 실현할 수 있을까요? 그 뒤에 있는 설계 원리는 어떤 모습일까요? 본문에서는 이러한 내용을 개괄적으로 소개하고 논의해보겠습니다.

무엇이 "제한 조항"인가

Covenants, 즉 "제한 조항"은 미래의 비트코인 거래에 조건을 설정할 수 있는 메커니즘입니다.

현재 비트코인 스크립트에도 제한 조건이 포함되어 있습니다. 예를 들어, 지출할 때 유효한 서명을 입력해야 하거나 적합한 스크립트로 보내야 합니다. 그러나 사용자가 잠금을 해제할 수 있다면, 해당 UTXO를 원하는 곳에 자유롭게 사용할 수 있습니다.

제한 조항은 잠금을 해제하는 방법에 대한 제한을 두는 것 외에도, UTXO 이후의 지출을 제한하는 등의 추가적인 제한을 설정하여 "전용 자금"의 효과를 구현할 수 있습니다. 또는 하나의 거래에서 다른 입력 조건을 설정하는 등의 방식입니다.

보다 엄밀하게 말하면, 현재 비트코인 스크립트에도 일정한 제한 조항이 존재합니다. 예를 들어, 연산 코드 기반의 시간 잠금은 거래의 nLock 또는 nSequence 필드를 통해 거래 지출 전의 시간 제한을 구현하지만, 기본적으로 시간 측면의 제한에 국한됩니다.

그렇다면 개발자와 연구자들은 왜 이러한 제한 검사를 설계해야 할까요? 제한 조항은 단순히 제한하기 위한 것이 아니라, 거래 실행의 규칙을 설정하기 때문입니다. 이렇게 되면 사용자는 미리 설정된 규칙에 따라 거래를 실행할 수 있어, 예정된 비즈니스 프로세스를 완료할 수 있습니다.

따라서 직관적으로는 더 많은 응용 시나리오를 열 수 있습니다.

응용 시나리오

스테이킹의 벌칙 보장

제한 조항의 가장 직관적인 예는 Babylon의 비트코인 스테이킹 과정에서의 슬래시 거래입니다.

Babylon의 비트코인 스테이킹 과정은 사용자가 자신의 BTC 자산을 메인 체인에 특별한 스크립트로 전송하는 것으로, 지출 조건은 두 가지가 있습니다:

• 해피 엔딩: 일정 시간이 지나면 사용자가 자신의 서명으로 잠금을 해제할 수 있으며, 즉 언스테이크 과정을 완료합니다.
• 배드 엔딩: 사용자가 Babylon이 임대한 보안 PoS 체인에서 이중 서명 등의 악의적인 행동을 할 경우, EOTS(추출 가능한 일회성 서명)를 통해 해당 자산을 잠금 해제할 수 있으며, 네트워크의 실행 역할이 일부 자산을 강제로 소각 주소로 전송합니다(슬래시).

출처: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy

여기서 "강제 전송"이라는 점에 주목해야 합니다. 이는 이 UTXO를 잠금 해제할 수 있더라도 해당 자산을 다른 곳으로 자유롭게 전송할 수 없고, 오직 소각만 가능하다는 것을 의미합니다. 이렇게 해야 악의적인 사용자가 자신이 알고 있는 서명을 사용해 자산을 자신에게 돌려받아 벌칙을 피할 수 없도록 보장할 수 있습니다.

이 기능이 OP _ CTV 등의 제한 조항이 구현된 후에는 스테이킹 스크립트의 "배드 엔딩" 분기에서 OP _ CTV 등의 연산 코드를 추가하여 제한을 구현할 수 있습니다.

OP_CTV가 활성화되기 전, Babylon은 사용자가 + 위원회가 공동으로 실행하는 방식으로 제한 조항 강제 실행 효과를 시뮬레이션해야 했습니다.

혼잡 제어

일반적으로 혼잡은 비트코인 네트워크에서 수수료가 매우 높고 거래 풀에 많은 거래가 쌓여 있을 때를 의미합니다. 따라서 사용자가 거래를 빠르게 확인하고 싶다면 수수료를 높여야 합니다.

이때 사용자가 여러 수취인에게 여러 거래를 보내야 한다면, 수수료를 높여야 하며, 이는 높은 비용을 감수해야 함을 의미합니다. 동시에 전체 네트워크의 수수료율도 더욱 상승하게 됩니다.

제한 조항이 있다면, 한 가지 해결 방법은 송신자가 먼저 대량 전송 거래에 대한 약속을 할 수 있습니다. 이 약속은 모든 수취인이 최종 거래가 이루어질 것이라고 믿게 하여, 수수료율이 낮을 때 구체적인 거래를 전송할 수 있도록 합니다.

아래 그림과 같이 블록 공간에 대한 수요가 매우 높을 때 거래는 매우 비쌉니다. 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)는 비트코인 응용 프로그램에서 널리 논의되는 응용 시나리오 중 하나로, 특히 제한 조항 분야에서 그렇습니다. 일상적인 작업에서 자금 보관과 자금 사용 요구 사이의 균형을 맞추는 것이 불가피하기 때문에, 사람들은 자금을 안전하게 보장할 수 있는 보관소 응용 프로그램을 원합니다. 심지어 계정이 해킹당하더라도(개인 키가 유출되더라도) 자금 사용을 제한할 수 있어야 합니다.

제한 조항을 구현하는 기술을 기반으로 보관소 응용 프로그램을 쉽게 구축할 수 있습니다.

OP _ VAULT의 설계 방안을 예로 들면, 보관소의 자금을 사용할 때 먼저 거래를 블록체인에 전송해야 합니다. 이 거래는 보관소를 사용하려는 의도를 나타내며, 즉 "트리거" 역할을 하며 조건을 설정합니다:

• 모든 것이 정상이라면, 두 번째 거래는 최종 인출 거래가 됩니다. N개의 블록이 지나면 자금을 자유롭게 사용할 수 있습니다.
• 만약 이 거래가 도난당했거나(또는 "렌치 공격"으로 협박당한 경우), N개의 블록의 인출 거래가 전송되기 전에 즉시 다른 안전한 주소로 전송할 수 있습니다(사용자가 더 안전하게 보관).

OP _ VAULT의 프로세스, 출처: BIP -345

제한 조항이 없는 경우에도 보관소 응용 프로그램을 구축할 수 있지만, 가능한 방법 중 하나는 개인 키를 사용하여 나중에 사용할 서명을 준비한 후 이 개인 키를 파기하는 것입니다. 그러나 여전히 많은 제한이 있습니다. 예를 들어, 이 개인 키가 이미 파기되었는지(제로 지식 증명에서의 신뢰할 수 있는 설정 과정과 유사) 확인해야 하며, 금액과 수수료를 미리 결정해야 하므로(미리 서명해야 하므로) 유연성이 부족합니다.

OP _ VAULT와 미리 서명된 보관소 프로세스 비교, 출처: BIP -345

더 강력하고 유연한 상태 채널

일반적으로, 라이트닝 네트워크를 포함한 상태 채널은 메인 체인과 거의 동일한 보안성을 가지고 있다고 볼 수 있습니다(노드가 최신 상태를 관찰하고 정상적으로 최신 상태를 블록체인에 게시할 수 있는 경우). 그러나 제한 조항이 도입되면, 새로운 상태 채널 설계 아이디어가 라이트닝 네트워크 위에서 더 강력하거나 유연해질 수 있습니다. 이 중 잘 알려진 예로는 Eltoo, Ark 등이 있습니다.

Eltoo(또는 LN - Symmetry)는 그 중 하나의 전형적인 예입니다. 이 기술 솔루션은 "L2"의 발음을 따르며, 라이트닝 네트워크에 대해 후속 채널 상태가 이전 상태를 대체할 수 있도록 허용하는 실행 레이어를 제안합니다. 이 과정에서 처벌 메커니즘이 필요하지 않으므로, 라이트닝 네트워크 노드가 상대방의 악의적인 행동을 방지하기 위해 여러 이전 상태를 저장해야 하는 문제를 피할 수 있습니다. 이러한 효과를 실현하기 위해 Eltoo는 SIGHASH _ NOINPUT의 서명 방식을 제안했습니다. 즉, APO(BIP -118)입니다.

Ark는 라이트닝 네트워크의 유입 유동성과 채널 관리의 어려움을 줄이는 것을 목표로 합니다. 이는 joinpool 형태의 프로토콜로, 여러 사용자가 일정 시간 동안 서비스 제공자를 거래 상대방으로 받아들이고, 오프체인에서 가상 UTXO(v UTXO) 거래를 수행하지만, 온체인에서 하나의 UTXO를 공유하여 비용을 절감합니다. 보관소와 유사하게, Ark는 현재 비트코인 네트워크에서 구현할 수 있습니다. 그러나 제한 조항이 도입되면, Ark는 거래 템플릿을 기반으로 필요한 상호작용을 줄여 더 신뢰할 수 없는 단방향 종료를 실현할 수 있습니다.

제한 조항 기술 개요

위의 응용 사례에서 볼 수 있듯이, 제한 조항은 특정 기술이 아닌 효과에 가깝기 때문에 여러 가지 구현 기술 방식이 존재합니다. 분류하면 다음과 같습니다:

• 유형: 일반형, 전용형
• 구현 방식: Opcode 기반, 서명 기반
• 재귀: 재귀, 비재귀

그 중 재귀는 일부 제한 조항의 구현이 다음 출력 제한을 통해 다음 출력 제한을 설정할 수 있음을 의미하며, 추가된 제한이 하나의 거래를 초과하여 더 깊은 거래 깊이를 달성할 수 있습니다.

주요 제한 조항 설계에는 다음이 포함됩니다:

제한 조항의 설계

앞서 소개한 바와 같이, 현재 비트코인 스크립트는 잠금을 해제하는 조건을 주로 제한하고 있으며, 해당 UTXO가 어떻게 추가로 사용될지를 제한하지 않습니다. 제한 조항을 구현하기 위해서는 반대로 생각해야 합니다: 왜 현재 비트코인 스크립트가 제한 조항을 구현할 수 없는가?

주된 이유는 현재 비트코인 스크립트가 거래 자체의 내용을 읽을 수 없기 때문입니다. 즉, 거래의 "내성"(introspection)입니다.

만약 거래의 내성을 구현할 수 있다면, 즉 거래의 모든 내용을(출력을 포함하여) 검사할 수 있다면, 제한 조항을 구현할 수 있습니다.

따라서 제한 조항의 설계 아이디어는 주로 내성을 어떻게 구현할 것인가에 초점을 맞추고 있습니다.

Opcode 기반 vs 서명 기반

가장 간단하고 직접적인 아이디어는 하나 이상의 연산 코드를 추가하여 거래의 내용을 직접 읽는 것입니다. 이것이 바로 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를 통해 비트코인 사용자는 비트코인을 사용하는 방식을 제한할 수 있습니다.

이 제안은 처음에 OP _ CHECKOUTPUTSHASHVERIFY(COSHV)라는 이름으로 출시되었으며, 초기에는 혼잡 제어 거래 생성 능력에 중점을 두었기 때문에, 이 제안에 대한 비판도 이 솔루션이 충분히 일반적이지 않고 혼잡 제어 사용 사례에 너무 구체적으로 초점을 맞추었다는 것이었습니다.

앞서 언급한 혼잡 제어 사용 사례에서 송신자 앨리스는 10개의 출력을 생성하고 이 10개의 출력을 해시하여 생성된 요약을 사용하여 COSHV를 포함하는 탭리프 스크립트를 생성할 수 있습니다. 앨리스는 또한 참여자의 공개 키를 사용하여 Taproot 내부 키를 형성하여 Taproot 스크립트 경로를 노출하지 않고 협력 지출을 허용할 수 있습니다.

그런 다음 앨리스는 각 수취인에게 이 10개의 출력 복사본을 제공하여 각자가 앨리스의 설정 거래를 검증할 수 있도록 합니다. 이후 그들은 이 지불을 사용하고 싶을 때, 그들 중 누구든지 약속 출력을 포함하는 거래를 생성할 수 있습니다.

이 과정에서 앨리스가 설정 거래를 생성하고 전송할 때, 앨리스는 기존의 비동기 통신 방법(예: 이메일 또는 클라우드 드라이브)을 통해 이 10개의 출력 복사본을 전송할 수 있습니다. 이는 수취인이 온라인에 있을 필요도 없고 서로 상호작용할 필요도 없음을 의미합니다.

출처: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

APO와 유사하게, 주소도 지출 조건에 따라 구축할 수 있으며, 다른 키 추가, 시간 잠금, 조합 논리 등을 포함하여 "잠금"을 만들 수 있습니다.

출처: https://twitter.com/OwenKemeys/status/1741575353716326835

CTV는 이 기반 위에서 해시된 지출 거래가 정의된 것과 일치하는지 검사할 수 있는 기능을 제안했습니다. 즉, 거래 데이터를 "잠금"의 키로 사용합니다.

우리는 위의 10명의 수취인 예제를 계속 확장할 수 있습니다. 수취인은 자신의 주소 키를 서명되었지만 방송되지 않은 tx로 설정하여 다음 수취인 주소로 전송할 수 있습니다. 이렇게 하면 다음과 같은 트리 구조가 형성됩니다. 앨리스는 블록체인에서 1 UTXO의 블록 공간만으로 여러 사용자의 계좌 잔액 변화를 구성할 수 있습니다.

출처: https://twitter.com/OwenKemeys/status/1741575353716326835

만약 그 중 하나의 리프가 라이트닝 채널, 콜드 스토리지, 또는 다른 지불 경로라면? 그러면 이 트리는 단일 차원 다층 지출 트리에서 다차원 다층 지출 트리로 확장되어 지원할 수 있는 시나리오가 더욱 풍부하고 유연해질 것입니다.

출처: https://twitter.com/OwenKemeys/status/1744181234417140076

CTV는 제안 이후 2019년 COSHV에서 이름이 변경되었고, 2020년 BIP -119로 할당되었으며, CTV 계약을 지원하는 프로그래밍 언어인 Sapio가 등장했습니다. 22, 23년 동안 커뮤니티에서 많은 논의와 업데이트가 있었으며, 활성화 방안에 대한 논쟁이 있었습니다. 현재도 커뮤니티에서 논의가 활발한 소프트 포크 업그레이드 제안 중 하나입니다.

OP _ CAT

OP _ CAT은 서두에서 소개한 바와 같이 현재 매우 주목받고 있는 업그레이드 제안으로, 스택의 두 요소를 연결(concatenate)하는 기능을 구현합니다. 간단해 보이지만 OP _ CAT은 스크립트에서 많은 기능을 유연하게 구현할 수 있습니다.

가장 직접적인 예는 머클 트리 관련 작업입니다. 머클 트리는 두 요소를 먼저 연결한 후 해시를 수행하는 것으로 이해할 수 있습니다. 현재 비트코인 스크립트에는 OP _ SHA256 등의 해시 연산 코드가 있으므로, OP _ CAT을 사용하여 두 요소를 연결할 수 있다면 스크립트에서 머클 트리의 검증 기능을 구현할 수 있으며, 이는 일정 부분에서 라이트 클라이언트 검증 능력을 갖추게 됩니다.

또한 구현의 기초에는 슈노르 서명의 강화가 포함됩니다. 스크립트의 지출 서명 조건을 사용자의 공개 키와 공개 nonce의 연결로 설정할 수 있습니다. 이후 서명자가 이 자금을 다른 곳으로 지출하기 위해 다른 거래를 서명하려고 하면 동일한 nonce를 사용해야 하므로 개인 키가 유출될 위험이 있습니다. 즉, OP _ CAT을 통해 nonce에 대한 약속을 구현하여 서명된 거래의 유효성을 보장할 수 있습니다.

OP_CAT의 다른 응용 시나리오에는 Bistream, 트리 서명, 양자 저항 Lamport 서명, 보관소 등이 포함됩니다.

OPCAT 자체는 새로운 기능이 아니며, 비트코인의 초기 버전에서 존재했으나, 공격에 악용될 가능성 때문에 2010년부터 비활성화되었습니다. 예를 들어, OPDUP과 OP_CAT을 반복적으로 사용하면 전체 노드가 이러한 스크립트를 처리할 때 스택 폭발을 쉽게 유발할 수 있습니다. 이 데모를 참조하십시오.

하지만 현재 OP _ CAT을 재활성화하더라도 앞서 언급한 스택 폭발 문제가 발생하지 않을까요? 현재 OP _ CAT 제안은 tapscript에서 활성화하는 것만 포함되어 있으며, tapscript는 각 스택 요소가 520바이트를 초과하지 않도록 제한하므로 이전의 스택 폭발 문제는 발생하지 않습니다. 일부 개발자는 사토시가 OP _ CAT을 직접 비활성화한 것이 지나치게 엄격할 수 있다고 생각합니다. 그러나 OP _ CAT의 유연성으로 인해 현재로서는 일부 취약점을 유발할 수 있는 응용 시나리오를 모두 포괄할 수는 없습니다.

따라서 응용 시나리오와 잠재적 위험 등을 종합적으로 고려할 때, OP_CAT은 최근 많은 주목을 받고 있으며, PR 리뷰도 진행되었습니다. 현재 가장 인기 있는 업그레이드 제안 중 하나입니다.

결론

"자율성이 자유를 가져온다"는 말처럼, 위의 소개에서 볼 수 있듯이 제한 조항은 비트코인 스크립트에서 거래의 추가 지출을 제한할 수 있도록 직접 구현할 수 있으며, 이는 스마트 계약 효과와 유사한 거래 규칙을 실현할 수 있습니다. BitVM과 같은 오프체인 방식에 비해, 이러한 프로그래밍 방식은 비트코인에서 더 원시적으로 검증할 수 있으며, 메인 체인상의 응용(혼잡 제어), 오프체인 응용(상태 채널) 및 기타 새로운 응용 방향(스테이킹 벌칙 등)을 개선할 수 있습니다.

제한 조항의 구현 기술이 일부 기본 업그레이드와 결합된다면 프로그래머블성의 잠재력을 더욱 발휘할 수 있을 것입니다. 예를 들어, 최근 리뷰에서의 64비트 연산자 제안은 제안된 OP_TLUV 또는 기타 제한 조항과 결합하여 거래 출력의 센트 수에 따라 프로그래밍할 수 있습니다.

그러나 제한 조항은 계획되지 않은 남용이나 취약점을 초래할 수 있으므로, 커뮤니티는 이에 대해 신중합니다. 또한 제한 조항의 업그레이드는 합의 규칙의 소프트 포크 업그레이드와 관련이 있어야 합니다. Taproot 업그레이드 시의 상황을 고려할 때, 제한 조항 관련 업그레이드는 완료하는 데 시간이 걸릴 수 있습니다.