비트코인에 가까이 다가서기: BitVM을 이해하기 위한 배경 지식 (1)
글: Nickqiao, Faust, Shew Wang, Geek web3
자문: Bitlayer 연구팀
요약: 최근 Delphi Digital은 「The Dawn of Bitcoin Programmability: Paving the Way for Rollups」라는 제목의 비트코인 레이어2 기술 보고서를 발표했다. 이 보고서는 BitVM 패밀리, OP_CAT 및 커번트(Covenant) 조건, 비트코인 생태계 DA 계층, 브리지, 그리고 Bitlayer, Citrea, Yona, Bob 등 BitVM을 채택한 주요 4개의 비트코인 레이어2 프로젝트와 관련된 핵심 개념들을 체계적으로 정리하였다.
해당 보고서는 전반적으로 비트코인 레이어2 기술의 개괄적인 그림을 제공하지만, 구체적인 세부 설명이 부족하여 다소 막연하게 느껴진다. 이에 Geek web3는 Delphi 보고서를 바탕으로 심층적인 추가 분석을 진행하여, BitVM 등 관련 기술을 더 많은 사람들이 체계적으로 이해할 수 있도록 노력하고 있다.
우리는 Bitlayer 연구팀과 BitVM 중문 커뮤니티와 함께 「BTC에 다가가기」라는 시리즈 칼럼을 공동 기획하여, 향후 장기간에 걸쳐 BitVM, OP_CAT, 비트코인 크로스체인 브리지 등의 핵심 주제를 중심으로 대중 교육 활동을 전개할 예정이다. 이를 통해 더 많은 사람들에게 비트코인 레이어2 기술의 신비를 벗기고, 관심 있는 이용자들이 쉽게 접근할 수 있는 길을 열어줄 것이다.
몇 달 전, ZeroSync 책임자인 Robin Linus는 「BitVM: Compute Anything on Bitcoin」이라는 제목의 글을 발표하며 공식적으로 BitVM 개념을 제시했으며, 이는 비트코인 레이어2 기술 발전에 중요한 진전을 가져왔다. 비트코인 생태계에서 가장 혁신적인 기술 중 하나라 할 수 있으며, 전체 비트코인 레이어2 생태계를 촉발시켰고, Bitlayer, Citrea, BOB 등의 유명 프로젝트들의 참여를 이끌어냈다. 이로 인해 시장 전반에 활력이 불어왔다.
그 이후,더 많은 연구자들이 BitVM의 개선에 참여하여 BitVM1, BitVM2, BitVMX, BitSNARK 등 다양한 버전을 차례로 출시하였다. 주요 내용은 다음과 같다:
-
Robin Linus가 작년 처음 제안한 BitVM 백서는 가상의 논리 게이트 회로 기반의 구현 방식으로, 이를 BitVM0이라 부른다;
-
Robin Linus는 이후 몇 차례 강연 및 인터뷰에서 공식적이지는 않지만, 가상 CPU 기반의 BitVM 방식(이하 BitVM1)을 소개하였으며, 이는 Optimism의 사기 증명 시스템 Cannon과 유사하다. 즉, 비트코인 스크립트를 사용해 오프체인에서 범용 CPU 효과를 시뮬레이션하는 방식이다.
-
Robin Linus는 또한 BitVM2를 제안했는데, 이는 권한 없는 단일 스텝 비대화형 사기 증명 프로토콜이다.
-
Rootstock Labs와 Fairgate Labs 소속 멤버들은 BitVMX 백서를 발표했는데, BitVM1과 유사하게, 비트코인 스크립트를 이용해 오프체인에서 범용 CPU 효과를 시뮬레이션하는 것을 목표로 한다.
현재 BitVM 관련 개발자 생태계의 구축이 점점 뚜렷해지고 있으며, 주변 도구들의 반복적 개선도 눈에 띄게 이루어지고 있다. 작년과 비교하면, 지금의 BitVM 생태계는 더 이상 공중누각이 아니라 서서히 윤곽이 드러나는 단계에 접어들었다. 이는 점점 더 많은 개발자들과 VC들이 비트코인 생태계로 몰려드는 계기가 되고 있다.
하지만 대부분的人来说, BitVM과 비트코인 레이어2 관련 기술 용어를 이해하는 것은 결코 쉬운 일이 아니다. 먼저 비트코인 스크립트, Taproot 등 기초 지식에 대한 체계적인 이해가 필요하기 때문이다. 현재 온라인에서 찾을 수 있는 참고 자료들은 너무 장황하거나 설명이 부족해 여전히 모호하게 느껴진다.우리는 이러한 문제 해결을 목표로 하며, 가능한 한 명확한 언어를 사용해 더 많은 사람들이 비트코인 레이어2 관련 지식을 이해할 수 있도록 돕고, BitVM 체계에 대한 체계적인 인식을 형성하고자 한다.
MATT와 커밋: BitVM의 기초 사상
우선 강조해야 할 것은, BitVM의 기초 사상은 MATT(Merkleize All The Things)라는 점이다. 이는 Merkle 트리라는 나무 형태의 데이터 저장 구조를 통해 복잡한 프로그램 실행 과정을 표현하고, 비트코인 네이티브 방식으로 사기 증명을 검증할 수 있도록 하는 것을 의미한다.
MATT는 복잡한 프로그램과 그 데이터 처리 흔적을 표현할 수 있지만, 이러한 데이터를 BTC 체인 상에 직접 게시하지는 않는다. 왜냐하면 데이터 규모가 매우 크기 때문이다.MATT 방식은 오직 오프체인 Merkle 트리에 데이터를 저장하고, Merkle 트리 최상단의 요약 정보(Merkle Root)만 체인에 게시한다. 이 Merkle 트리는 다음 세 가지 핵심 내용을 포함한다:
-
스마트 계약 스크립트 코드
-
계약 수행에 필요한 데이터
-
계약 실행 중 남긴 흔적(EVM 등 가상 머신에서 메모리, CPU 레지스터 변경 기록)
(간단한 Merkle 트리 예시. Merkle Root는 아래 8개의 데이터 조각을 여러 단계 해시 연산을 통해 도출된다.)
MATT 방식에서는 극히 작은 크기의 Merkle Root만 체인에 저장되며, Merkle 트리의 전체 데이터셋은 오프체인에 저장된다. 이는 일종의 '커밋(commitment)' 전략을 활용한 것이다. 여기서 '커밋'이란 무엇인지 설명하겠다.
커밋은 일종의 간결한 선언과 같다. 우리는 이를 대량의 데이터를 압축한 '지문(fingerprint)'으로 이해할 수 있다. 일반적으로 체인에 커밋을 게시하는 사람은 오프체인에 저장된 데이터가 정확하다고 주장하며, 해당 오프체인 데이터는 간결한 선언(즉, 커밋)과 대응되어야 한다.
경우에 따라 데이터의 해시 값이 데이터 자체에 대한 '커밋' 역할을 할 수 있으며, 다른 커밋 방식에는 KZG 커밋이나 Merkle 트리 등이 있다. 레이어2에서 흔히 사용되는 사기 증명 프로토콜에서,데이터 게시자는 오프체인에 전체 데이터셋을 게시하고, 체인 상에는 데이터셋의 커밋을 게시한다. 누군가 오프체인 데이터셋에 무효 데이터가 있음을 발견하면, 체인 상의 데이터 커밋에 대해 이의를 제기할 수 있다.
커밋(Commitment)을 통해 레이어2는 대량의 데이터를 압축 처리하여 비트코인 체인 상에는 오직 그 '커밋'만 게시할 수 있다. 물론 오프체인에 저장된 전체 데이터셋이 외부에서 관측 가능하도록 보장되어야 한다.
현재 주요 BitVM 방식들(BitVM0, BitVM1, BitVM2, BitVMX)은 기본적으로 유사한 추상 구조를 채택하고 있다:
1. 프로그램 분해 및 커밋: 먼저 복잡한 프로그램을 다수의 기초적인 오퍼레이션 코드들로 분해하고(컴파일), 각 오퍼레이션 코드가 실제 실행될 때 남기는 흔적을 기록한다. (즉, 프로그램이 CPU와 메모리에서 실행될 때 상태 변화를 기록하는 것으로, Trace라고 부른다.) 이후 Trace와 오퍼레이션 코드를 포함한 모든 데이터를 정리하여 하나의 데이터셋으로 구성하고, 해당 데이터셋의 커밋을 생성한다.
구체적인 커밋 방식은 여러 형태가 있을 수 있다: Merkle 트리, PIOPs(다양한 ZK 알고리즘), 해시 함수 등
2. 자산 담보 및 사전 서명: 데이터 게시자와 검증자는 사전 서명 방식을 통해 일정 금액의 자산을 체인 상에 잠그며, 특정 조건을 설정한다. 이러한 조건은 미래 발생 가능한 상황에 따라 트리거되며, 데이터 게시자가 악의적인 행위를 할 경우 검증자가 증명을 제출함으로써 게시자의 자산을 획득할 수 있다.
3. 데이터 및 커밋 게시: 데이터 게시자는 체인 상에 커밋을 게시하고, 오프체인에 전체 데이터셋을 게시한다. 검증자는 데이터셋을 검색하여 오류가 있는지 확인한다. 오프체인 데이터셋의 각 부분은 체인 상의 커밋과 연관되어 있다.
4. 도전 및 처벌: 검증자가 데이터 게시자가 제공한 데이터에 오류가 있음을 발견하면, 해당 데이터를 체인 상에서 직접 검증한다. (해당 데이터를 매우 세밀하게 분할해야 함) 이것이 바로 사기 증명의 로직이다. 검증 결과 데이터 게시자가 오프체인에 무효 데이터를 제공한 것이 확인되면, 그의 자산은 도전한 검증자가 가져간다.
요약하자면,데이터 게시자 Alice는 오프체인에서 레이어2 거래 실행 과정에서 발생한 모든 흔적을 공개하고, 해당 커밋을 체인 상에 게시한다. 만약 특정 데이터가 잘못되었음을 입증하고자 한다면, 먼저 해당 데이터가 체인 상의 커밋과 연결되어 있음을 비트코인 노드에 증명해야 한다(즉, 이 데이터가 Alice 본인이 공개한 것임을 입증). 이후 비트코인 노드가 해당 데이터에 오류가 있음을 판단한다.
이제 우리는 BitVM의 전체 사고방식을 대략적으로 이해했다. 모든 BitVM 변종들은 기본적으로 위의 패턴에서 벗어나지 않는다. 이제부터는 위 프로세스에서 사용되는 주요 기술들을 학습하고 이해해보자. 가장 기초적인 비트코인 스크립트, Taproot 및 사전 서명부터 시작하자.
비트코인 스크립트(BTC Script)란?
비트코인 관련 지식은 이더리움보다 이해하기 더 어렵다. 가장 기초적인 송금 행위조차 UTXO(미사용 거래 출력), 잠금 스크립트(ScriptPubKey), 해제 스크립트(ScriptSig) 등 일련의 개념을 포함한다. 먼저 주요 개념들을 설명하겠다.
(비트코인 스크립트 코드 예시. 고급 언어보다 더 낮은 수준의 오퍼레이션 코드들로 구성됨)
이더리움의 자산 표현 방식은 알리페이나 위챗과 더 유사하다. 매번 송금 시 각 계정의 잔액을 더하거나 빼는 방식이며, 계정 기반으로, 자산 잔액은 계정 이름 아래의 숫자일 뿐이다. 반면 비트코인의 자산 표현 방식은 황금과 더 유사하다. 각 조각의 황금(UTXO)마다 주인이 표시되어 있으며,송금은 사실상 이전 UTXO를 파괴하고 새로운 UTXO를 생성하는 것이다(주인은 변경됨).
비트코인 UTXO는 두 가지 핵심 필드를 포함한다:
-
금액: '사토시(satoshi)' 단위(1억 사토시 = 1 BTC);
-
잠금 스크립트: '스크립트 공개키(ScriptPubKey)'라고도 하며, UTXO의 해제 조건을 정의한다.
주의할 점은,비트코인 UTXO의 소유권은 잠금 스크립트를 통해 표현된다. 자신의 UTXO를 Sam에게 양도하고자 한다면, 자신의 특정 UTXO를 파괴하는 거래를 생성하고, 새로 생성된 UTXO의 해제 조건을 '오직 Sam만 해제 가능'으로 설정할 수 있다.
그 후,Sam이 이 비트코인을 사용하고자 한다면 해제 스크립트(ScriptSig)를 제출해야 하며, 이 해제 스크립트에서 자신의 디지털 서명을 제시하여 자신이 Sam임을 입증해야 한다. 해제 스크립트가 앞서 언급한 잠금 스크립트와 일치하면, Sam은 UTXO를 해제하고 타인에게 다시 송금할 수 있다.
(해제 스크립트는 잠금 스크립트와 일치해야 함)
표현 형식 측면에서,비트코인 체인 상의 각 거래는 여러 Input과 Output에 대응된다. 각 Input에서는 자신이 해제하고자 하는 특정 UTXO를 선언하고 해제 스크립트를 제출하여 해당 UTXO를 해제하고 파괴한다. Output에서는 새로 생성된 UTXO 정보를 표시하며, 잠금 스크립트의 내용을 공개한다.
예를 들어, 거래의 Input에서 당신은 자신이 Sam임을 입증하고, 타인이 준 여러 UTXO를 해제하여 통합 파괴한 후, 여러 새로운 UTXO를 생성하고 xxx가 향후 해제하도록 선언한다.
구체적으로, 거래의 Input 데이터에서, 어떤 UTXO를 해제할지 선언하고, 해당 UTXO 데이터의 '저장 위치'를 지정해야 한다. 여기서 주의할 점은, 비트코인과 이더리움은 근본적으로 다르다는 것이다. 이더리움은 데이터 저장을 위해 컨트랙트 계정과 EOA 계정 두 가지를 제공하며, 자산 잔액은 숫자로 기록되어 컨트랙트 또는 EOA 계정 이름 아래에 위치하며, 모두 '월드 스테이트(world state)'라는 데이터베이스에 통합 저장된다. 송금 시 '월드 스테이트'에서 특정 계정을 수정함으로써 데이터 저장 위치를 쉽게 찾을 수 있다.
비트코인은 월드 스테이트 설계가 없으며, 자산 데이터는 과거 블록들에 분산 저장된다(즉, 해제되지 않은 UTXO 데이터는 각 거래의 Output에 별도로 저장됨).
특정 UTXO를 해제하고자 할 경우, 해당 UTXO 정보가 과거 어느 거래의 Output에 존재하는지 밝혀야 하며, 해당 거래의 ID(즉, 해시값)를 제시하여 비트코인 노드가 과거 기록에서 찾도록 해야 한다. 특정 주소의 비트코인 잔액을 조회하고자 할 경우, 처음부터 모든 블록을 순회하여 xx 주소와 연관된 미해제 UTXO를 찾아야 한다.
평소 비트코인 지갑을 사용할 때 특정 주소의 잔액을 빠르게 확인할 수 있는 것은, 지갑 서비스 자체가 블록을 스캔하여 모든 주소에 색인을 만들어 놓았기 때문에 빠르게 조회가 가능하기 때문이다.
(자신의 UTXO를 타인에게 보내겠다고 거래를 생성할 때, 해당 UTXO가 속한 거래 해시/ID를 기반으로 비트코인 역사 기록 내 위치를 표시해야 함)
흥미롭게도,비트코인 거래의 결과는 체인 외부에서 계산이 완료된다. 사용자가 로컬 장치에서 거래를 생성할 때 이미 Input과 Output을 모두 생성하여 마치 거래의 출력 결과를 계산한 것처럼 만든다. 거래는 비트코인 네트워크에 브로드캐스트되고 노드의 검증을 거쳐 체인에 올라간다. 이러한 '체인 외부 계산 - 체인 상 검증' 모델은 이더리움과 완전히 다르다. 이더리움에서는 거래 입력 매개변수만 제공하면 되며, 거래 결과는 이더리움 노드가 계산하여 출력한다.
또한,UTXO의 잠금 스크립트(Locking Script)는 사용자 정의가 가능하다. UTXO를 '특정 비트코인 주소의 주인이 해제 가능'하도록 설정할 수 있으며, 해당 주인은 디지털 서명과 공개키(P2PKH)를 제공해야 한다. 반면,Pay-to-Script-Hash(P2SH) 거래 유형에서는 UTXO 잠금 스크립트에 스크립트 해시를 추가할 수 있으며, 누구든지 해당 해시에 대응하는 스크립트 원상(image)을 제출하고, 스크립트 원상 내 사전 설정된 조건을 충족하면 UTXO를 해제할 수 있다.BitVM이 의존하는 Taproot 스크립트는 P2SH와 유사한 특성을 활용한다.
비트코인 스크립트는 어떻게 실행되는가?
여기서는 먼저 P2PKH 사례를 통해 비트코인 스크립트의 실행 방식을 설명하겠다. 그 실행 방식을 이해해야 더 복잡한 Taproot와 BitVM을 이해할 수 있다. P2PKH는 'Pay to Public Key Hash'의 약자로, 이 방식에서 UTXO의 잠금 스크립트에는 공개키 해시가 설정되며, 해제 시 해당 해시에 대응하는 공개키를 제출해야 한다. 이는 일반적인 비트코인 송금 개념과 거의 동일하다.
이때,비트코인 노드는 해제 스크립트에 포함된 공개키가 잠금 스크립트에 지정된 공개키 해시와 일치하는지 확인해야 하며, 즉,해제자가 제출한 '열쇠'가 UTXO에 사전 설정된 '자물쇠'와 서로 맞는지 확인해야 한다.
더 나아가, P2PKH 방식에서 비트코인 노드가 거래를 수신하면, 사용자가 제출한 해제 스크립트(ScriptSig)를 해제할 UTXO의 잠금 스크립트(ScriptPubkey)와 함께 연결한 후, BTC 스크립트 실행 환경에서 실행한다. 아래는 실행 전 연결 결과를 보여준다:
독자들이 BTC 스크립트 실행 환경을 잘 모를 수 있으므로 간단히 소개하겠다. 우선,BTC 스크립트는 두 가지 요소를 포함한다:
데이터와 오퍼레이션 코드. 이 데이터와 오퍼레이션 코드들은 왼쪽에서 오른쪽으로 순서대로 스택(stack)에 푸시되어 지정된 로직에 따라 실행되며, 최종 결과를 얻는다(스택이 무엇인지에 대해서는 여기서 설명하지 않으며, 독자들은 Chatgpt 등을 참고하시기 바란다).
위 그림을 예로 들면,왼쪽은 누군가가 업로드한 해제 스크립트(ScriptSig)로, 디지털 서명과 공개키를 포함하며, 오른쪽의 잠금 스크립트(ScriptPubkey)에는 UTXO 생성자가 해당 UTXO를 생성할 때 설정한 일련의 오퍼레이션 코드와 데이터가 포함되어 있다(여기서 각 오퍼레이션 코드의 의미를 알 필요는 없으며, 대략적인 이해만 하면 된다).
위 그림에서 오른쪽 잠금 스크립트의 DUP, HASH160, EQUALVERIFY 등의 오퍼레이션 코드는 왼쪽 해제 스크립트에 포함된 공개키를 해시하여 잠금 스크립트에 사전 설정된 공개키 해시와 비교한다. 두 값이 같다면, 해제 스크립트에 업로드된 공개키가 잠금 스크립트에 사전 설정된 공개키 해시와 일치함을 의미하며, 이는 첫 번째 검증을 통과한 것이다.
하지만 문제가 하나 있다. UTXO 잠금 스크립트의 내용은 사실상 체인 상에 공개되어 있어 누구나 그 안의 공개키 해시를 관찰할 수 있고, 누구나 해당 공개키를 업로드하여 자신이 '지명된 사람'이라고 거짓말할 수 있다. 따라서 공개키와 공개키 해시 검증 후에는 거래 발신자가 실제로 해당 공개키를 제어하는지 여부도 검증해야 한다. 이를 위해 디지털 서명을 검증해야 한다.잠금 스크립트의 CHECKSIG 오퍼레이션 코드가 바로 디지털 서명을 검증하는 역할을 한다.
요약하면, P2PKH 방식에서 거래 발신자가 제출한 해제 스크립트에는 공개키와 디지털 서명이 포함되어야 하며, 해당 공개키는 잠금 스크립트에 지정된 공개키 해시와 일치하고, 거래의 디지털 서명이 정확해야 UTXO를 성공적으로 해제할 수 있다.
(이 이미지는 동적이다: P2PKH 방식에서 비트코인 해제 스크립트 예시)
출처: https://learnmeabitcoin.com/technical/script )
물론, 비트코인 네트워크는 P2PK/P2PKH 외에도 P2SH(Pay to Script hash) 등 다양한 거래 유형을 지원하며,이는 모두 UTXO 생성 시 사용자 정의된 잠금 스크립트의 설정 방식에 따라 결정된다.
여기서 주의할 점은,P2SH 방식에서 잠금 스크립트에 스크립트 해시를 사전 설정할 수 있으며, 해제 스크립트는 스크립트 해시에 대응하는 스크립트 내용을 완전히 제출해야 한다. 비트코인 노드는 이 스크립트를 실행할 수 있으며, 이 스크립트 내 다중 서명 검증 로직이 정의되어 있다면, 비트코인 체인 상에서 다중 서명 지갑 효과를 실현할 수 있다.
물론, P2SH 방식에서 UTXO 생성자는 향후 UTXO를 해제할 사람이 사전에 스크립트 해시에 대응하는 스크립트 내용을 알고 있어야 한다. 양측이 스크립트 내용을 알고 있다면 다중 서명보다 더 복잡한 비즈니스 로직을 실현할 수 있다.
한 가지 설명해야 할 점은, 비트코인 체인 상(블록)은 어떤 UTXO가 어떤 주소와 연관되어 있는지를 직접 기록하지 않는다는 것이다. 오직 UTXO가 어떤 공개키 해시 / 어떤 스크립트 해시로 해제 가능한지만 기록한다. 그러나 우리는 공개키 해시/스크립트 해시로부터 대응하는 주소(지갑 인터페이스에 표시되는 일련의 난수 문자열)를 빠르게 계산할 수 있다.
왜 블록 탐색기나 지갑 인터페이스에서 xx 주소에 xx 수량의 비트코인이 있는지 볼 수 있는가? 블록 탐색기와 지갑 프로젝트 팀이 이러한 데이터를 해석해주기 때문이다. 모든 블록을 스캔하여 잠금 스크립트에 선언된 공개키 해시/스크립트 해시를 기반으로 대응하는 '주소'를 계산한 후, xx 주소 이름 아래 얼마나 많은 비트코인이 있는지 표시하기 때문이다.
격리 위트니스(SegWit)와 Witness
P2SH의 사고방식을 이해한 후에는 BitVM이 의존하는 Taproot에 한 발 더 가까워졌다. 하지만 그 전에 중요한 개념인 Witness와 격리 위트니스(Segregated Witness)를 이해해야 한다.
앞서 설명한 해제 스크립트와 잠금 스크립트, 그리고 UTXO 해제 프로세스를 되돌아보면 문제점 하나를 발견할 수 있다. 디지털 서명은 해제 스크립트에 포함되며, 서명 생성 시 해제 스크립트를 포함해서는 안 된다(서명 생성에 사용된 매개변수는 서명 자체를 포함할 수 없다). 따라서디지털 서명은 해제 스크립트 외부 부분만 덮을 수 있으며, 즉 거래 데이터의 주요 부분과만 연관될 수 있고, 거래 데이터 전체를 완전히 덮지 못한다.
이러한 경우,거래의 해제 스크립트를 중간자가 약간 조작하더라도 검증 결과에는 영향을 주지 않는다. 예를 들어, 비트코인 노드나 채굴풀은 거래의 해제 스크립트에 다른 데이터를 삽입할 수 있으며, 검증과 거래 결과에 영향을 주지 않는 전제 하에 거래 데이터를 미세하게 변경하여 최종 계산된 거래 해시/거래 ID도 변경할 수 있다. 이를거래 변조성 문제(transaction malleability problem)라 한다.
이로 인한 단점은, 연속적으로 여러 거래를 발행하고자 할 경우, 특히 순서상 종속성이 있는 경우(예: 거래 3이 거래 2의 출력을 참조하고, 거래 2가 거래 1의 출력을 참조함) 후순위 거래는 반드시 이전 거래의 ID(해시)를 참조해야 한다는 점이다. 채굴풀이나 비트코인 노드 같은 중간자가 해제 스크립트 내용을 미세 조정하여 체인에 올라간 거래 해시가 사용자가 예상한 것과 일치하지 않게 만들면, 미리 생성한 순서가 있는 여러 거래는 실패하게 된다.
실제로 DLC 브리지와 BitVM2 방식에서는 순서가 있는 여러 거래를 일괄적으로 구성하므로 앞서 언급한 시나리오는 드물지 않다.
간단히 말해,거래 변조성 문제는 거래 ID/해시를 계산할 때 해제 스크립트 데이터를 포함하기 때문이며, 비트코인 노드 등의 중간자가 해제 스크립트 내용을 미세 조정함으로써 거래 ID가 사용자의 예상과 맞지 않게 되기 때문이다. 사실 이것은 비트코인 초기 설계 시 고려가 부족했던 역사적 문제이다.
이후 도입된격리 위트니스(SegWit) 업그레이드는 거래 ID와 해제 스크립트를 완전히 분리하는 것이다. 거래 해시를 계산할 때 해제 스크립트 데이터를 포함하지 않는다. SegWit를 따르는 UTXO 잠금 스크립트는 기본적으로 맨 앞에 'OP_0'이라는 오퍼레이션 코드를 설정하여 마킹한다. 반면, 대응하는 해제 스크립트는 SigScript에서 Witness(위트니스)로 명칭이 변경되었다.
격리 위트니스 규칙을 따르면 거래 변조성 문제는 적절히 해결되며, 비트코인 노드에 전송한 거래 데이터가 미세 조정되는 것을 걱정할 필요가 없다. 물론 너무 복잡하게 생각할 필요 없다. P2WSH의 기능은 앞서 언급한 P2SH와 본질적 차이가 없다. UTXO 잠금 스크립트에 스크립트 해시를 사전 설정할 수 있으며, 해제 스크립트 제출자가 해당 해시에 대응하는 스크립트 내용을 체인에 제출하고 실행하면 된다.
하지만구현하고자 하는 스크립트 내용이 특히 방대하고, 매우 많은 코드를 포함할 경우, 일반적인 방법으로는 전체 스크립트를 비트코인 체인에 제출할 수 없다. (각 블록은 크기 제한이 있음) 그렇다면 어떻게 해야 할까? 이때Taproot를 활용해야 한다. 체인에 올라가는 스크립트 내용을 간소화 처리하는데, BitVM은 바로 이러한 Taproot 기반으로 구축된 복잡한 방식이다.
「BTC에 다가가기」 시리즈의 다음 기사에서는 Taproot, 사전 서명 등 BitVM과 관련된 기타 더 복잡한 기술들에 대해 자세히 설명할 예정이니, 많은 기대 부탁드립니다!
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
