비트코인 레이어 2 네트워크의 성배: 성찰과 언약

cd

이더리움과 같은 튜링 완전형 블록체인에 비해 비트코인의 스크립팅 언어는 기본적인 연산만 가능하고 곱셈과 나눗셈 기능도 부족해 상당히 제한적인 것으로 간주됩니다. 더 중요한 것은 블록체인의 자체 데이터는 스크립트에서 거의 접근할 수 없기 때문에 유연성과 프로그래밍 가능성에 심각한 제한이 있다는 점입니다. 따라서 사람들은 오랫동안 비트코인 스크립트에 대한 인트로스펙션을 활성화하는 방법을 모색해 왔습니다.

자기 성찰은 비트코인 스크립트가 거래 데이터를 검사하고 제한할 수 있는 기능입니다. 이를 통해 스크립트는 특정 거래 세부 정보를 기반으로 자금 사용을 제어하여 보다 복잡한 기능을 구현할 수 있습니다. 현재 대부분의 비트코인 옵코드는 사용자가 제공한 데이터를 스택에 푸시하거나 이미 스택에 있는 데이터를 조작합니다. 그러나 인트로스펙션 옵코드는 타임스탬프, 금액, 거래 ID와 같은 현재 거래 데이터를 스택에 푸시할 수 있어 UTXO 지출을 보다 세밀하게 제어할 수 있습니다.

현재 비트코인 스크립트에서 인트로스펙션을 지원하는 주요 옵코드는 세 가지뿐입니다: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, CHECKSIG입니다. CHECKSIG에는 CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, CHECKMULTISIGVERIFY 등 여러 변종이 있습니다.

언약은 토큰을 전송하는 방법에 대한 제한입니다. 사용자는 컨벤션을 통해 UTXO를 배포하는 방법을 지정할 수 있으며, 대부분은 인트로스펙션 옵코드를 사용하여 구현됩니다. 현재 비트코인 옵텍은 인트로스펙션을 컨트랙트 항목으로 분류합니다.

비트코인에는 현재 두 가지 컨벤트가 있습니다: 시간 기반 컨벤턴트이며 라이트닝 네트워크와 같은 많은 확장 솔루션의 기초를 형성하는 CSV(CheckSequenceVerify)와 CLTV(CheckLockTimeVerify)가 그것입니다. 이는 비트코인의 확장성 솔루션이 인트로스펙션과 컨벤트에 크게 의존하고 있음을 나타냅니다.

토큰 전송에 조건을 추가하는 방법

암호화폐 세계에서 가장 일반적인 방법은 해시를 사용하여 구현되는 약속을 이용하는 것입니다. 전송 조건이 충족되었음을 증명하기 위해 서명 메커니즘이 검증에 사용됩니다. 따라서 컨벤트는 해시와 서명에 대한 수많은 조정을 수반합니다.

다음은 널리 논의되고 있는 약정 옵코드 제안입니다:

CTV (CheckTemplateVerify) BIP-119

BIP-119에 포함된 CTV(CheckTemplateVerify)는 많은 논쟁이 있는 비트코인 업그레이드입니다. CTV를 사용하면 출력 스크립트에서 nVersion, nLockTime, scriptSig 해시, 입력 횟수, 시퀀스 해시, 출력 횟수, 출력 해시, 입력 인덱스 등의 필드를 포함한 지출 트랜잭션에 대한 템플릿을 지정할 수 있습니다. 이러한 템플릿 제한은 해시 커밋을 통해 구현되며, 향후 지출 스크립트는 지출 트랜잭션에서 지정된 필드의 해시 값이 입력 스크립트의 해시 값과 일치하는지 확인합니다. 이러한 템플릿은 기본적으로 향후 UTXO 트랜잭션의 시간, 방법, 금액을 정의합니다.

특히, 입력 TXID는 해시 커밋에서 제외됩니다. 이 제외는 레거시 트랜잭션이든 세그윗 트랜잭션이든, 기본 SIGHASH_ALL 서명 유형을 사용할 때 TXID가 scriptPubKey 값에 의존하기 때문에 필요합니다. TXID를 포함하면 순환 종속성이 발생하여 해시 커밋을 구성할 수 없게 됩니다.

CTV는 새로운 옵코드를 통해 지정된 트랜잭션 정보를 직접 가져와 해싱하고 스택의 커미트먼트와 비교하는 방식으로 인트로스펙션을 수행합니다. 이 방법은 온체인 공간을 덜 차지하지만 유연성이 다소 부족합니다.

라이트닝 네트워크와 같은 2계층 솔루션의 기반은 사전 서명된 트랜잭션입니다. 사전 서명이란 일반적으로 트랜잭션을 미리 생성하고 서명하지만, 특정 조건이 충족될 때까지 이를 브로드캐스팅하지 않는 것을 의미합니다. 기본적으로 CTV는 더 엄격한 사전 서명 기능을 구현하여 사전 서명된 약속을 온체인에 직접 게시하고, 미리 정의된 템플릿에 따라 트랜잭션만 허용합니다.

CTV는 처음에 비트코인 혼잡을 완화하기 위해 제안되었으며 혼잡 제어라고도 합니다. 혼잡도가 높은 기간 동안 CTV는 한 번의 트랜잭션을 통해 향후 여러 트랜잭션을 커밋할 수 있으므로 혼잡한 동안 여러 트랜잭션을 브로드캐스트할 필요가 없고 혼잡이 완화한 후에 실제 트랜잭션을 완료할 수 있습니다. 이는 거래소 운영 시 상당한 도움이 될 수 있습니다. 또한 템플릿을 사용해 볼트를 구현하면 자금의 목적지가 미리 정해져 있어 해커의 공격을 방지할 수 있으며, 해커가 CTV 스크립트를 사용해 주소로 UTXO를 보내는 것이 불가능해집니다.

CTV는 세컨드 레이어 네트워크를 크게 개선할 수 있습니다. 예를 들어, 라이트닝 네트워크에서 CTV를 사용해 타임아웃 트리와 채널 팩토리를 구현하면 단일 UTXO가 CTV 트리로 확장되어 단 하나의 온체인 트랜잭션과 확인으로 여러 상태 채널을 열 수 있습니다. 또한, CTV는 아크 프로토콜에서 아토믹 트랜잭션(ATLC)을 지원합니다.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118은 보다 유연한 지출 로직을 쉽게 작성할 수 있도록 탭스크립트를 위한 새로운 서명 해시 플래그인 SIGHASH_ANYPREVOUT을 제안합니다. APO와 CTV는 여러 면에서 유사합니다. 스크립트펍키와 TXID 간의 순환적 종속성을 해결하기 위해 APO의 솔루션은 관련 입력 정보를 제외하고 출력에만 서명하여 트랜잭션이 다른 UTXO에 동적으로 바인딩될 수 있도록 하는 것입니다.

논리적으로 확인 연산 OP_CHECKSIG(및 관련 옵코드)에는 세 가지 기능이 있습니다:

  1. 지출 거래의 일부를 조립합니다.
  2. 이 부분을 해시하세요.
  3. 해시가 주어진 키로 서명되었는지 확인합니다.

서명의 구체적인 내용은 크게 조정할 수 있으며, 어떤 트랜잭션 필드에 서명할지는 SIGHASH 플래그에 의해 결정됩니다. BIP 342 서명 옵코드의 정의에 따르면 SIGHASH 플래그에는 SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY 등이 포함됩니다. SIGHASH_ANYONECANPAY는 입력을 제어하고 다른 플래그는 출력을 제어합니다.

SIGHASH_ALL은 모든 출력에 서명하는 기본 SIGHASH 플래그입니다. SIGHASH_NONE은 어떤 출력도 서명하지 않으며, SIGHASH_SINGLE은 지정된 출력만 서명합니다. SIGHASH_ANYONECANPAY는 다른 세 플래그와 함께 설정할 수 있으며, 설정하면 지정된 입력만 서명하고, 그렇지 않으면 모든 입력에 서명해야 합니다.

이러한 SIGHASH 플래그 중 어떤 것도 입력의 영향을 제거할 수 없습니다. SIGHASH_ANYONECANPAY조차도 하나의 입력에 대한 약정이 필요합니다.

따라서 BIP 118은 SIGHASH_ANYPREVOUT을 도입합니다. APO 서명은 사용된 입력 UTXO(PREVOUT이라고 함)에 커밋할 필요가 없고 출력에만 서명하므로 비트코인 제어에 더 높은 유연성을 제공합니다. 트랜잭션을 미리 구성하고 해당 일회용 서명과 공개 키를 생성하면, 해당 공개 키 주소로 전송된 자산은 미리 구성된 트랜잭션을 통해 소비되어 언약을 달성해야 합니다.

APO의 유연성은 트랜잭션 복구에도 사용할 수 있습니다. 낮은 수수료로 인해 트랜잭션이 온체인에서 중단되는 경우, 새로운 서명이 필요 없이 다른 트랜잭션을 쉽게 생성하여 수수료를 높일 수 있습니다. 또한 다중 서명 지갑의 경우 사용한 입력값에 의존하지 않는 서명을 사용하면 작업이 더 간단해집니다.

스크립트PubKey와 입력 TXID 간의 순환 종속성을 제거함으로써 APO는 감시에서 출력 데이터를 추가하여 내성 검사를 수행할 수 있지만, 여전히 추가 감시 데이터 공간이 필요합니다.

라이트닝 네트워크와 볼트와 같은 오프체인 프로토콜의 경우, APO는 중간 상태 스토리지의 필요성을 줄여 스토리지 요구사항과 복잡성을 크게 낮춥니다. APO의 가장 직접적인 사용 사례는 엘투로, 채널 팩토리를 단순화하고, 가볍고 저렴한 워치타워를 구축하며, 잘못된 상태를 남기지 않고 일방적인 출구를 허용하여 라이트닝 네트워크의 성능을 향상시킵니다. APO는 CTV의 기능을 시뮬레이션할 수 있지만, 서명과 사전 서명된 트랜잭션의 개인 저장소가 필요하기 때문에 CTV보다 비용이 많이 들고 효율성이 떨어집니다.

APO의 주요 비판은 새로운 키 버전이 필요하기 때문에 기존 시스템과 호환되지 않는다는 점입니다. 또한 새로운 서명 해시 유형은 잠재적인 이중 지출 위험을 초래할 수 있습니다. 광범위한 커뮤니티 논의를 거쳐 APO는 이제 원본 서명 외에 일반 서명을 요구하여 보안 문제를 완화하고 BIP-118 번호를 획득했습니다.

OP_VAULT BIP-345

BIP-345는 두 개의 새로운 옵코드, OP_VAULT와 OP_VAULT_RECOVER를 제안하여 CTV와 연동하고 지정된 토큰 지출에 지연 기간을 적용하는 전용 컨벤션을 구현하며, 이 기간 동안 복구 경로를 통해 지출을 “취소”할 수 있도록 합니다.

사용자는 특정 탭루트 주소를 설정하여 볼트를 만들 수 있으며, MAST에 최소 두 개의 스크립트, 즉 예상 출금 프로세스를 촉진하는 OP_VAULT 스크립트와 출금 완료 전에 코인을 복구하는 OP_VAULT_RECOVER 스크립트를 포함할 수 있습니다.

OP_VAULT는 어떻게 중단 없는 시간 제한 출금을 실현하나요?

간단히 말해서, OP_VAULT 옵코드는 사용된 OP_VAULT 스크립트를 지정된 스크립트로 대체하여 MAST의 단일 리프 노드만 업데이트하고 나머지는 변경되지 않도록 합니다. 이는 TLUV와 유사하지만 내부 키 업데이트를 지원하지 않습니다.

스크립트 업데이트 중에 템플릿을 도입하면 결제 효과가 제한될 수 있습니다. 시간 잠금 매개변수는 OP_VAULT로 지정되며, CTV 옵코드가 가져온 템플릿은 해당 스크립트 경로를 통해 소비되는 출력 집합을 제한합니다.

BIP-345는 볼트용으로 설계되어 사용자가 매우 안전한 복구 경로(종이 지갑, 분산 다중 서명)를 사용하면서 일상적인 결제에 대한 지출 지연을 구성할 수 있습니다. 사용자의 장치가 볼트의 지출을 지속적으로 모니터링하여 무단 이체가 발생할 경우 복구할 수 있습니다.

BIP-345로 볼트를 구현하려면 특히 복구 트랜잭션의 경우 수수료 문제를 고려해야 합니다. 가능한 해결책으로는 CPFP(자식이 부모에게 지불), 임시 앵커, SIGHASH_GROUP과 같은 새로운 서명 해시 플래그가 있습니다.

TLUV(탭리프업데이트검증)

TLUV 체계는 탭루트를 중심으로 구축되었으며, 공유 UTXO를 효율적으로 종료하는 문제를 해결하는 것을 목표로 합니다. 기본 원칙은 탭루트 출력이 소비될 때 탭루트 주소의 내부 구조와 암호화 변환을 사용하여 TLUV 스크립트에 설명된 업데이트 단계에 따라 내부 키와 MAST를 부분적으로 업데이트하여 컨트랙트 기능을 달성할 수 있다는 것입니다.

TLUV 체계의 아이디어는 다음 작업 중 하나 이상을 수행할 수 있는 새로운 옵코드 TAPLEAF_UPDATE_VERIFY를 통해 현재 지출 입력을 기반으로 새로운 탭루트 주소를 생성하는 것입니다:

구체적으로 TLUV는 세 가지 입력을 받습니다:

  1. 내부 공개키를 업데이트하는 방법에 대한 명세서
  2. 머클 경로에 대한 새 리프 노드
  3. 현재 리프 노드를 제거할지 여부 및/또는 제거할 머클 경로 리프 노드 수에 대한 사양입니다.

TLUV 연산 코드는 업데이트된 스크립트펍키를 계산하고 현재 입력에 해당하는 출력이 해당 스크립트펍키에 소비되었는지 확인합니다.

TLUV의 영감은 코인 풀입니다. 오늘날 공동 풀은 사전 서명된 트랜잭션을 사용하여 만들 수 있지만, 무허가 출구를 달성하려면 기하급수적으로 늘어나는 서명을 만들어야 합니다. TLUV를 사용하면 사전 서명된 트랜잭션 없이도 무허가 출구를 구현할 수 있습니다. 예를 들어, 한 파트너 그룹이 탭루트를 사용하여 공유 UTXO를 구축하여 자금을 모았다고 가정해 보겠습니다. 탭루트 키를 사용하여 내부적으로 자금을 이동하거나 외부 결제를 위해 공동으로 서명할 수 있습니다. 개인은 언제든지 공유 풀에서 탈퇴하여 결제 경로를 제거할 수 있으며, 다른 파트너는 나머지 멤버에 대한 추가 정보를 노출하지 않고 원래 경로를 통해 결제를 계속 완료할 수 있습니다. 이 방법은 풀링되지 않은 거래에 비해 더 효율적이고 비공개적입니다.

TLUV 옵코드는 원래 MAST를 업데이트하여 부분적인 지출 제한을 달성합니다. 그러나 출력 금액에 대한 인트로스펙션은 달성하지 못합니다. 따라서 이 입력의 UTXO 금액과 해당 출력 금액이라는 두 가지 데이터를 스택에 푸시하는 새로운 옵코드 IN_OUT_AMOUNT가 필요합니다. 그런 다음 TLUV를 사용하는 사람은 수학 연산자를 사용하여 업데이트된 스크립트PubKey에 자금이 제대로 보존되었는지 확인해야 합니다.

비트코인 금액은 사토시로 표시되고 최대 51비트가 필요하지만 스크립트에서는 32비트 수학 연산만 허용하기 때문에 출력 금액의 인사이트는 또 다른 복잡성을 추가합니다. 이를 위해서는 스크립트에서 연산자 동작을 재정의하거나 SIGHASH_GROUP을 사용하여 IN_OUT_AMOUNT를 대체함으로써 연산자를 업그레이드해야 합니다.

TLUV는 탈중앙화된 레이어 2 코인 풀을 위한 솔루션을 제공할 것으로 예상되지만, 탭루트 공개키 조정에 대한 신뢰성은 추가 확인이 필요합니다.

MATT

MATT(머클라이즈 올 더 씽스)는 세 가지 목표를 달성하는 것을 목표로 합니다: 머클라이즈 상태, 머클라이즈 스크립트, 머클라이즈 실행을 통해 일반적인 스마트 컨트랙트를 달성하는 것입니다.

MATT를 달성하려면 비트코인 프로그래밍 스크립트에 다음과 같은 기능이 있어야 합니다:

  1. 출력에 특정 스크립트(및 그 양)를 적용합니다.
  2. 출력에 데이터 첨부
  3. 현재 입력(또는 다른 입력)에서 데이터 읽기

동적 데이터는 지출자가 제공한 입력 데이터를 통해 상태 머신을 시뮬레이션하고 다음 상태와 첨부 데이터를 결정하여 상태를 계산할 수 있기 때문에 두 번째 포인트가 중요합니다. MATT는 앞서 제안한 OP_CHECKOUTPUTCONTRACTVERIFY와 OP_CHECKINPUTCONTRACTVERIFY 오퍼코드를 결합한 OP_CHECKCONTRACTVERIFY(OP_CCV) 오퍼코드에 연산 대상을 지정하는 flags 파라미터를 추가하여 제안합니다.

출력량 제어: 가장 직접적인 방법은 직접 인트로스펙션을 사용하는 것입니다. 그러나 출력 금액은 64비트 숫자로 64비트 연산을 필요로 하므로 비트코인 스크립트 구현에 복잡성을 더합니다. CCV는 OP_VAULT와 유사한 지연 검사를 채택하여 동일한 출력에 대한 모든 입력의 입력 금액을 합산하고 해당 출력 금액의 하한을 CCV로 설정합니다. 이 확인은 입력 스크립트 평가 중이 아닌 트랜잭션 프로세스로 지연됩니다.

사기 증명의 일반성을 고려할 때, MATT 계약의 일부 변형은 모든 유형의 스마트 컨트랙트 또는 레이어 2 구조를 달성해야 하지만, 추가 요구 사항(예: 자본 고정 및 챌린지 기간 지연)은 정확한 평가가 필요합니다. 어떤 애플리케이션이 허용 가능한 트랜잭션인지 평가하려면 추가 연구가 필요합니다. 예를 들어, 암호화 약정 및 사기 챌린지 메커니즘을 사용해 OP_ZK_VERIFY 함수를 시뮬레이션하여 비트코인에서 신뢰 없는 롤업을 달성할 수 있습니다.

실제로는 이미 일어나고 있는 일입니다. 요한 토로스 할세스는 MATT 소프트 포크 제안의 OP_CHECKCONTRACTVERIFY 연산 코드를 사용해 elftrace를 구현하여, RISC-V 컴파일이 지원하는 모든 프로그램을 비트코인 체인에서 검증할 수 있게 함으로써 계약 프로토콜을 위한 기본 비트코인 검증 브릿지를 가능하게 했습니다.

CSFS(OP_CHECKSIGFromSTACK)

APO 옵코드를 소개하면서 OP_CHECKSIG(및 관련 연산)가 트랜잭션 어셈블리, 해싱, 서명 검증을 담당한다는 것을 알게 되었습니다. 그러나 이 연산이 검증하는 메시지는 이 옵코드를 사용한 트랜잭션 직렬화에서 파생되므로 다른 메시지를 지정할 수 없습니다. 간단히 말해, OP_CHECKSIG(및 관련 연산)는 트랜잭션 입력인 UTXO가 서명 보유자가 사용할 수 있는 권한이 있는지 확인하여 비트코인의 보안을 보호하는 역할을 합니다.

CSFS는 이름에서 알 수 있듯이 스택에서 서명을 확인합니다. CSFS 연산 코드는 스택에서 서명, 메시지, 공개 키의 세 가지 매개변수를 가져와 서명의 유효성을 확인합니다. 즉, 모든 메시지가 감시 데이터를 통해 스택으로 전달되고 CSFS에 의해 검증될 수 있으며, 이는 비트코인에서 몇 가지 혁신을 가능하게 합니다.

CSFS의 유연성 덕분에 결제 서명, 권한 위임, 오라클 계약, 이중지불 보호 채권 등 다양한 메커니즘을 구현할 수 있으며, 더 중요한 것은 거래 인트로스펙션입니다. CSFS를 사용한 트랜잭션 인트로스펙션의 원리는 매우 간단합니다. OP_CHECKSIG가 사용한 트랜잭션 콘텐츠를 감시를 통해 스택에 푸시하고 동일한 공개 키와 서명을 사용해 CSFS와 OP_CHECKSIG를 모두 검증하고, 둘 다 통과하면 CSFS로 전달된 메시지 내용은 OP_CHECKSIG가 암시적으로 사용한 직렬화된 지출 거래(및 기타 데이터)와 동일합니다. 그런 다음 스택에서 확인된 트랜잭션 데이터를 가져와 다른 옵코드로 지출 트랜잭션에 제한을 적용하는 데 사용할 수 있습니다.

OP_CAT은 트랜잭션의 여러 필드를 연결하여 직렬화를 완료할 수 있으므로, 내사를 위해 트랜잭션 필드를 보다 정밀하게 선택할 수 있기 때문에 CSFS는 종종 OP_CAT과 함께 나타납니다. OP_CAT이 없으면 스크립트는 개별적으로 확인할 수 있는 데이터에서 해시를 다시 계산할 수 없으므로 해시가 특정 값과 일치하는지 여부만 확인할 수 있으므로 코인은 하나의 특정 트랜잭션을 통해서만 사용할 수 있습니다.

CSFS는 CLTV, CSV, CTV, APO와 같은 옵코드를 구현할 수 있으며 일반적인 인트로스펙션 옵코드로서 비트코인의 레이어 2 확장 솔루션에도 도움이 됩니다. 단점은 서명된 트랜잭션의 전체 사본을 스택에 추가해야 하므로, 인트로스펙션에 CSFS를 사용하려는 트랜잭션의 크기가 크게 증가할 수 있다는 것입니다. 반면, CLTV와 CSV와 같은 단일 목적 인트로스펙션 옵코드는 오버헤드가 가장 적지만, 새로운 특수 인트로스펙션 옵코드를 추가할 때마다 합의 변경이 필요합니다.

TXHASH(OP_TXHASH)

운영자가 필드의 해시를 선택하여 스택에 푸시할 수 있는 매우 간단한 인트로스펙션 연산자입니다. 구체적으로 OP_TXHASH는 스택에서 txhash 플래그를 꺼내고, 플래그를 기반으로 (플래그가 지정된) txhash를 계산한 다음, 결과 해시를 스택에 푸시합니다.

TXHASH와 CTV의 유사성으로 인해 커뮤니티에서 이 둘에 대한 광범위한 논의가 있었습니다.

TXHASH는 사용자가 지출 거래의 일부를 지정할 수 있는 고급 거래 템플릿을 제공하여 거래 수수료와 관련된 많은 문제를 해결하는 CTV의 일반적인 업그레이드로 볼 수 있습니다. 다른 컨트랙트 연산 코드와 달리 TXHASH는 증인에 필요한 데이터의 사본을 제공할 필요가 없으므로 스토리지 요구량을 더욱 줄일 수 있습니다. CTV와 달리 TXHASH는 NOP와 호환되지 않으며 탭스크립트에서만 구현할 수 있습니다. TXHASH와 CSFS의 조합은 CTV와 APO의 대안으로 간주할 수 있습니다.

컨트랙트 구성 측면에서 TXHASH는 수정하려는 트랜잭션 데이터의 모든 부분을 스택에 푸시하고 함께 해싱한 후 결과가 고정값과 일치하는지 확인함으로써 “가산형 컨트랙트”를 달성하기가 더 쉽습니다. CTV는 자유롭게 유지하려는 트랜잭션 데이터의 모든 부분을 스택에 푸시하여 “빼기 계약”을 더 쉽게 달성할 수 있습니다. 그런 다음 고정된 중간 상태에서 시작하여 롤링 OP_SHA256을 사용하면 해당 중간 상태가 트랜잭션 해시 데이터 접두사를 커밋합니다. 자유 부분은 해당 중간 상태로 해시됩니다.

TXHASH 사양에 정의된 TxFieldSelector 필드는 OP_TX와 같은 다른 옵코드로 확장될 것으로 예상됩니다.

TXHASH와 관련된 BIP는 현재 깃허브에서 초안 상태이며 아직 번호가 할당되지 않았습니다.

OP_CAT

OP_CAT은 사토시 나카모토가 보안 문제로 인해 더 이상 사용하지 않는 다소 미스터리한 옵코드입니다. 그러나 최근 비트코인 코어 개발자들 사이에서 광범위한 토론을 불러일으키며 온라인 커뮤니티에서 밈이 되기도 했습니다. 결국 OP_CAT은 BIP-347로 승인되었으며, 많은 이들이 가까운 시일 내에 통과될 가능성이 가장 높은 BIP 제안으로 꼽고 있습니다.

실제로 OP_CAT의 동작은 매우 간단합니다. 스택의 두 요소를 하나로 연결합니다. 하지만 이것이 어떻게 컨트랙트 기능을 가능하게 할까요?

두 요소를 연결하는 기능은 머클 트라이라는 강력한 암호화 데이터 구조에 해당합니다. 머클 트라이의 구성에는 연결과 해시 연산만 필요하며, 이 두 가지 연산은 비트코인 스크립트에서 사용할 수 있습니다. 따라서 OP_CAT을 사용하면 이론적으로 블록체인에서 가장 일반적인 경량 검증 방법인 비트코인 스크립트에서 머클 증명을 검증할 수 있습니다.

앞서 언급했듯이, CSFS는 OP_CAT을 사용해 일반적인 컨트랙트 체계를 달성할 수 있습니다. 사실 CSFS가 없어도 슈노르 서명의 구조는 OP_CAT 자체적으로 트랜잭션 내성 검사를 달성할 수 있습니다.

슈노르 서명에서 서명할 메시지는 다음 필드로 구성됩니다:

이러한 필드에는 트랜잭션의 주요 요소가 포함되어 있습니다. 스크립트PubKey 또는 witness에 배치하고 OP_CAT 및 OP_SHA256을 사용하여 슈노르 서명을 구성하고 OP_CHECKSIG로 검증할 수 있습니다. 검증이 통과되면 스택은 확인된 트랜잭션 데이터를 유지하여 트랜잭션 내사를 가능하게 합니다. 이를 통해 트랜잭션의 입력, 출력, 목적지 주소, 관련 비트코인 금액 등 트랜잭션의 다양한 부분을 추출하고 ‘검사’할 수 있습니다.

더 자세한 암호화 원리는 Andrew Poelstra의 “CAT와 슈노르 트릭” 문서를 참조하세요.

요약하자면, OP_CAT의 유연성 덕분에 거의 모든 컨트랙트 옵코드를 모방할 수 있으며, 많은 컨트랙트 옵코드가 이 기능에 의존하고 있습니다. 이는 병합 목록에서의 위치를 크게 향상시킵니다. 이론적으로는 OP_CAT과 기존 비트코인 옵코드만으로 신뢰가 최소화되는 BTC ZK 롤업을 구축할 수 있습니다. 스타크넷, 차크라, 그리고 다른 생태계 파트너들은 이를 실현하기 위해 적극적으로 노력하고 있습니다.

결론

비트코인을 확장하고 프로그래밍 가능성을 강화하기 위한 다양한 전략을 모색하면서, 앞으로 나아갈 길은 네이티브 개선, 오프체인 연산, 복잡한 스크립트 기능의 조합이 필요하다는 것이 분명해졌습니다.

유연한 기본 레이어가 없으면 더 유연한 두 번째 레이어를 구축하는 것은 불가능합니다.

오프체인 연산 확장성은 미래이지만, 비트코인의 프로그래밍 기능이 확장을 더 잘 지원하고 진정한 세계 통화가 되려면 이를 돌파해야 합니다.

그러나 비트코인 계산은 이더리움 계산과 근본적으로 다릅니다. 비트코인은 계산의 한 형태로서 ‘검증’만 지원하는 반면, 이더리움은 근본적으로 계산을 기반으로 하며 검증은 부산물입니다. 이러한 차이는 이더리움은 거래 실패에 대해 가스 수수료를 부과하는 반면, 비트코인은 그렇지 않다는 사실에서 분명하게 드러납니다.

콘트랙트는 계산이 아닌 검증을 기반으로 하는 스마트 콘트랙트의 한 형태입니다. 콘트랙트와 관련해, 몇몇 엄격한 사토시 근본주의자들을 제외하면 대부분의 사람들은 콘트랙트가 비트코인을 개선하는 데 좋은 선택이라고 생각합니다. 그러나 커뮤니티에서는 컨트랙트를 구현하기 위해 어떤 방식을 사용할지에 대해 끊임없이 논의하고 있습니다.

APO, OP_VAULT, TLUV는 직접 애플리케이션을 지향합니다. 이를 선택하면 특정 애플리케이션을 더 저렴하고 효율적으로 구현할 수 있습니다. 라이트닝 네트워크 애호가들은 LN-대칭을 달성하기 때문에 APO를 선호하며, 볼트를 생성하려면 OP_VAULT를 사용하는 것이 가장 좋고, 코인풀을 구축하려면 TLUV가 더 프라이빗하고 효율적입니다. OP_CAT과 TXHASH는 더 일반적이며 보안 취약성이 적고 다른 옵코드와의 조합을 통해 더 많은 사용 사례를 달성할 수 있지만 스크립트가 복잡해질 수 있습니다. CTV와 CSFS는 블록체인 처리 방식을 조정했습니다: CTV는 지연된 출력을 구현하고 CSFS는 지연된 서명을 구현합니다. MATT는 낙관적 실행과 사기 증명을 사용하는 비교적 독특한 방식이며, 머클 트라이 구조에 의존하여 일반적인 스마트 계약을 달성하지만, 여전히 인트로스펙션 기능을 제공하기 위해 새로운 옵코드가 필요합니다.

비트코인 커뮤니티는 이미 소프트 포크를 통한 콘트랙트 도입 가능성에 대해 치열하게 논의하고 있습니다. 스타크넷은 OP_CAT 합병 후 6개월 이내에 비트코인 네트워크에서 결제를 구현할 계획으로 비트코인 생태계 진입을 공식적으로 발표했습니다. 차크라는 비트코인 생태계의 최신 발전 상황을 지속적으로 모니터링하고 OP_CAT 소프트포크 병합을 추진하며, 인트로스펙션과 컨트랙트가 가져온 프로그래밍 가능성을 활용해 보다 안전하고 효율적인 비트코인 결제 레이어를 구축할 것입니다.

Related Articles
↑
Exit mobile version