저자: 닉차오, 파우스트, 셰우 왕; 출처: 긱 웹3
요약: 최근 델파이 디지털은 비트코인 롤업과 관련된 핵심 개념을 체계적으로 정리한 "비트코인 프로그래밍 가능성의 여명: 롤업을 위한 길"이라는 제목의 비트코인 레이어 2 기술에 대한 연구 논문을 발표했습니다.
이 연구는 비트코인 2차 계층 기술에 대한 광범위한 그림을 제시하지만, 포괄적인 것은 아닙니다. <이 보고서는 비트코인의 레이어 2 기술에 대한 광범위한 그림을 제공하지만, 전반적인 일반성과 세부적인 내용이 부족하여 이해하기 어렵습니다. <긱 웹3은 델파이의 연구 논문을 더욱 깊이 파고들어 BitVM 및 기타 기술에 대한 보다 체계적인 이해를 제공하고자 노력했습니다.
이 프로젝트는 Bitlayer 팀 및 BitVM 중국 커뮤니티와 협력할 것입니다.
우리는 Bitlayer 연구팀 및 BitVM 커뮤니티와 협력하여 "BTC에 접근하기"라는 칼럼 시리즈를 개발할 것이며, 이는 BitVM, OP_CAT, 비트코인 크로스체인 브리지 및 기타 주요 주제에 초점을 맞추고 비트코인 기술의 두 번째 계층을 조명하고 더 많은 애호가들이 길을 닦을 수 있도록 돕는 데 전념할 것입니다.
몇 달 전, 제로싱크의 대표인 로빈 라이너스는 "BitVM: 비트코인에서 무엇이든 계산하기"라는 제목의 기사를 발표하여 BitVM의 개념을 공식적으로 소개하고 비트코인의 세컨드 레이어 기술 발전에 박차를 가했습니다. 비트코인 생태계에서 가장 혁명적인 혁신 중 하나로 꼽히는 이 기술은 비트코인 레이어 2 생태계 전체에 불을 붙였고, 비트레이어, 시트레아, BOB 등 스타 프로젝트의 참여를 이끌어내며 시장 전체에 활기를 불어넣었습니다.
그 후, more 연구자들이 개선에 참여했습니다. BitVM1, BitVM2, BitVMX 및 BitSNARK의 다양한 반복을 통해 BitVM을 다듬었습니다. 일반적인 그림은 다음과 같습니다:
작년에 로빈 라이너스가 처음 발표한 BitVM 구현 백서는 가상의 게이트 기반 BitVM을 구현한 것입니다. BitVM0;
로빈 라이너스는 이후 몇 차례의 강연과 인터뷰를 통해 옵티미즘의 사기 증명 시스템인 캐논과 유사하며, 비트코인 스크립트를 사용해 범용 CPU로 오프체인에서 시뮬레이션할 수 있는 가상의 CPU 기반 BitVM 솔루션(BitVM1이라고 함)을 비공식적으로 소개하기도 했습니다.
로빈 라이너스는 또한 비허가형 단일 단계 비대화형 사기 증명 프로토콜인 BitVM2를 제안했습니다.
< strong>루트스톡 랩과 페어게이트 랩의 구성원들이 BitVM1과 유사하게 비트코인 스크립팅을 통해 범용 CPU(오프체인)의 효과를 모방하는 것으로 보이는 BitVMX 백서를 발표했습니다.
현재 BitVM 관련 개발자 생태계 구축이 점점 더 가시화되고 있으며 주변 도구의 반복적인 개선도 눈에 띄게 나타나고 있습니다. 작년에 비해 BitVM 생태계가 더욱 가시화되면서 점점 더 많은 개발자와 VC가 비트코인 생태계에 진입하고 있습니다.
하지만 대부분의 사람들에게 BitVM과 비트코인 세컨드 티어와 관련된 기술 용어를 이해하는 것은 쉽지 않습니다. 특히 비트코인 스크립팅과 탭루트에 대한 배경 지식과 함께 관련 기본 사항을 체계적으로 이해해야 하기 때문에 대부분의 사람들에게 BitVM과 비트코인 레이어 2를 이해하는 것은 쉬운 일이 아닙니다. 현재 온라인에서 제공되는 참고 자료는 너무 길고 복잡하거나 이해하기 쉽도록 충분히 설명하지 않습니다. <저희는 가능한 한 명확한 언어로 비트코인의 두 번째 계층의 주변부를 더 많은 사람들이 이해할 수 있도록 돕고, BitVM 시스템에 대한 체계적인 이해를 구축함으로써 이러한 문제를 해결하기 위해 최선을 다하고 있습니다.
MATT와 약속: 비트VM의 근간이 되는 아이디어
우선, 비트브이엠의 기본 아이디어는 MATT로, 이는 머클아이즈 올 더 씽스(Merkleize All The Things)를 의미하며, 주로 복잡한 프로그램 실행 과정을 보여주는 나무 모양의 데이터 저장 구조인 머클 트리를 의미한다는 점을 강조하고 싶습니다. 비트코인 네이티브의 검증된 사기 증명.
MATT는 복잡한 프로그램과 그 데이터 처리 추적을 나타낼 수는 있지만, BTC의 데이터를 직접 나타내지는 않습니다. 트레이스의 전체 크기가 매우 크기 때문에 이 데이터를 BTC 체인에 직접 게시하지 않습니다. MATT 접근 방식은 체인 아래 머클 트리에만 데이터를 저장하며, 머클 트리의 최상위 요약(머클 루트)만 체인에 게시됩니다. 이 머클 트리는 세 가지 주요 핵심 요소를 포함합니다:
스마트 계약 스크립트 코드
계약에 필요한 데이터
계약에 필요한 데이터
컨트랙트 실행 시 남겨지는 흔적(스마트 컨트랙트가 EVM과 같은 가상 머신에서 실행될 때 메모리, CPU 레지스터에 변경된 기록)
(다층 해시 계산 후 그래프 하단의 8개 데이터 조각에서 머클 루트가 계산되는 간단한 머클 트리의 도식)
MATT 방식에서는 아주 작은 머클 루트만 체인에 저장되고 머클 트리에 포함된 전체 데이터 세트는 체인 아래에 저장되며, 이는 "커밋"이라는 아이디어를 활용합니다. . 커밋에 대한 설명은 다음과 같습니다.
커밋은 단순화된 문과 유사합니다. strong>로, 대량의 데이터를 압축하여 얻은 '지문'이라고 생각할 수 있습니다. 일반적으로 체인에 '약속'을 게시하는 사람들은 오프체인에 저장된 특정 데이터가 정확하며, 이 오프체인 데이터가 간결한 진술, 즉 '약속'에 해당한다고 주장합니다.
어느 시점에서 데이터의 해시는 데이터 자체에 대한 '약속' 역할을 합니다. 다른 커미션 체계로는 KZG 커미션이나 머클 트리가 있습니다. Layer2의 일반적인 사기 증명 프로토콜에서는 데이터 게시자가 오프체인에 전체 데이터 세트를 게시하고, 온체인에 데이터 세트의 약속을 게시합니다. 누군가 체인 아래 데이터 세트에 유효하지 않은 데이터가 있음을 발견하면 체인상의 데이터에 대한 데이터 약속에 이의를 제기할 수 있습니다.
커미트먼트를 통해 ), 레이어 2는 대량의 데이터를 압축하고 비트코인 체인에만 '커미트먼트'를 게시할 수 있습니다. 물론 체인에 게시된 전체 데이터 집합을 외부에서 관찰할 수 있도록 하는 것도 중요합니다.
BitVM0, BitVM1, BitVM2, BitVMX와 같은 현재 주요 BitVM 체계는 기본적으로 유사한 추상화를 사용합니다.
1. 절차적 분해 및 약속: 먼저 복잡한 절차를 보다 기본적인 다수의 옵코드로 분해(컴파일)한 다음, 특정 실행 중에 이러한 옵코드가 생성한 흔적은 다음과 같습니다. 그런 다음 특정 실행 중에 이러한 코드가 생성한 트레이스(쉽게 말해 CPU와 메모리에서 실행 중인 프로그램의 전체 상태 변경 기록을 트레이스라고 함)를 기록합니다. 그런 다음 Trace와 옵코드를 포함한 모든 데이터를 수집하여 데이터 집합으로 정리한 다음 해당 데이터 집합에 대한 프로미스를 생성합니다.
특정 약속 체계는 머클 트리와 같은 다양한 형태가 될 수 있습니다.
2. strong>2. 자산 서약 및 사전 서명: 데이터 게시자와 검증자는 사전 서명을 통해 일정량의 자산을 체인에 잠가야 하며, 제한적인 조건이 있을 것입니다. 이러한 조건은 향후 발생할 수 있는 사건에 대응하여 트리거되며, 데이터 게시자가 악의적인 행위를 저지른 경우 검증자는 증거를 제출하여 데이터 게시자의 자산을 빼앗을 수 있습니다
3. 데이터 및 프로미스 게시: 데이터 게시자는 온체인에 프로미스를 게시하고 전체 데이터 세트는 오프체인에 게시하며 검증자는 데이터 세트를 검색하고 오류를 확인합니다. 체인 아래의 데이터 세트의 각 부분은 체인 상의 약속과 상관관계를 갖습니다.
4. 챌린지 및 페널티: 검증자가 데이터 게시자가 오류가 있는 데이터를 제공하면, 이 부분을 체인으로 가져가 직접 검증(특히 이 부분을 먼저 잘라내는 것)하는데, 이것이 바로 위조 증명 논리입니다. 검증 결과 데이터 게시자가 유효하지 않은 데이터를 체인에 제공한 것으로 밝혀지면, 이의를 제기한 검증자가 해당 자산을 가져가게 됩니다.
이를 요약하면 데이터 게시자 앨리스(Alice) 는 레이어 2 트랜잭션이 실행되는 동안 생성된 모든 추적을 오프체인에 게시하고, 해당 약속을 체인에 게시합니다. 데이터의 일부가 잘못되었다는 것을 증명하려면 먼저 데이터의 일부가 체인의 약속과 연관되어 있다는 것을 비트코인 노드에게 증명하고, 즉 이 데이터가 앨리스 자신이 공개적으로 사용할 수 있다는 것을 증명한 다음 비트코인 노드가 데이터의 일부가 잘못되었다고 판단하도록 해야 합니다.
이제 BitVM에 대해 전반적으로 이해했으니, 모든 BitVM이 동일한 아이디어를 가지고 있다는 것을 알 수 있습니다. 모든 BitVM 변형은 기본적으로 위의 패러다임을 따릅니다. 이제 비트코인 스크립팅과 탭루트, 사전 서명의 기본부터 시작하여 위 프로세스에서 사용되는 몇 가지 중요한 기술을 배우고 이해해 보겠습니다.
비트코인 스크립트란 무엇인가요
비트코인 관련 지식은 이더보다 훨씬 더 이해하기 어렵고, 가장 기본적인 송금 행위에도 UTXO(미사용 트랜잭션 출력), 스크립트 잠금(ScriptPubKey라고도 함), 스크립트 잠금 해제(ScriptSig라고도 함)를 비롯한 여러 개념이 포함되어 있습니다. 이러한 핵심 개념부터 설명하겠습니다.
(상위 언어보다 낮은 수준의 옵코드로 구성된 비트코인 스크립팅 코드의 예)
이더리움의 자산 표현은 알리페이나 위챗처럼 송금할 때마다 다른 계좌의 잔액을 더하거나 빼는, 계좌 중심적인 접근 방식이며 자산 잔액은 계좌 이름 아래 숫자에 불과하고, 비트코인의 자산 표현은 금처럼 각 금 조각(UTXO)에 소유자 태그가 붙는 방식에 가깝습니다. strong>송금은 실제로 기존 UTXO를 소멸시키고 새로운 UTXO를 생성합니다(소유자가 변경됨).
비트코인 UTXO 에는 두 개의 주요 필드가 포함되어 있습니다.
주의할 점은
이후에, Sam 이 비트코인을 사용하려면 샘이 자신이 샘임을 증명하는 디지털 서명을 제시하는 잠금 해제 스크립트(ScriptSig)를 제출해야 합니다. 잠금 해제 스크립트가 앞서 언급한 잠금 스크립트와 일치하면 샘은 비트코인을 잠금 해제하고 다른 사람에게 전송할 수 있습니다.
(잠금 해제 스크립트가 작동하려면 잠금 스크립트와 일치해야 함)
표현의 관점에서 보면, 비트코인 체인의 각 트랜잭션은 여러 개의 입력과 출력에 해당하며, 각 입력은 잠금 해제하려는 UTXO를 선언하고 잠금 해제 스크립트를 제출하여 UTXO를 잠금 해제 및 소멸시키고, 출력은 새로 생성된 UTXO 정보를 표시하고 잠금 스크립트를 공개적으로 사용할 수 있게 만듭니다. 정보를 입력하여 잠금 스크립트의 내용을 공개합니다.
예를 들어 트랜잭션의 Input에서 다음과 같이 증명할 수 있습니다. 샘, 다른 사람으로부터 받은 여러 개의 UTXO를 잠금 해제하고 균일하게 파괴한 다음, 향후 XXX가 잠금 해제할 수 있도록 선언하여 여러 개의 새 UTXO를 생성합니다.
특히, 트랜잭션의 입력 데이터에서 잠금 해제하려는 UTXO를 선언하고 해당 UTXO 데이터의 '저장 위치'를 표시합니다. 비트코인은 데이터 저장을 위해 컨트랙트와 EOA 계정을 모두 제공하는 이더와 매우 다르며, 자산 잔액은 컨트랙트 또는 EOA 계정 이름 아래에 숫자로 기록되고 "스테이트 오브 더 월드"라는 데이터베이스에 저장되므로 스테이트 오브 더 월드에서 특정 계정으로 직접 이체할 수 있어 데이터가 저장된 위치를 쉽게 찾을 수 있다는 점에 유의해야 합니다. >
비트코인에는 세계 상태 디자인이 없으며, 자산 데이터는 통과 블록에 분산되어 저장됩니다( 즉, 각 트랜잭션의 아웃풋에 별도로 저장되는 잠금 해제된 UTXO 데이터).
UTXO를 잠금 해제하려면 과거 트랜잭션의 어떤 출력에 UTXO 정보가 있는지, 트랜잭션의 ID(해시)를 표시하고 비트코인 노드가 기록을 살펴볼 수 있도록 합니다. 주소의 비트코인 잔액을 조회하려면 처음부터 모든 블록을 순회하여 주소 xx와 연결된 잠금 해제된 UTXO를 찾아야 합니다.
비트코인 지갑을 정기적으로 사용할 때 특정 주소가 보유한 비트코인 잔액을 빠르게 확인할 수 있는 이유는 지갑 서비스 자체에서 블록을 스캔하여 모든 주소를 인덱싱하기 때문에 빠르게 확인할 수 있는 경우가 많기 때문입니다.
(다른 사람에게 UTXO를 전송하기 위해 트랜잭션 명세서를 생성할 때 해당 UTXO가 속한 트랜잭션의 해시/ID를 기준으로 비트코인 기록에서 UTXO의 위치를 표시하세요)
흥미롭게도 비트코인 거래의 결과는 오프체인에서 계산되므로 사용자가 로컬 장치에서 거래를 생성할 때 입력과 출력을 모두 직접 생성해야 합니다. 트랜잭션의 출력을 계산하는 것과 동일한 출력이 생성됩니다. 트랜잭션은 비트코인 네트워크에 브로드캐스트되고 체인에 업로드되기 전에 노드의 검증을 받습니다. 이 "오프체인 계산 - 온체인 검증" 모델은 트랜잭션 입력 매개변수만 제공하면 이더 노드에서 결과를 계산하여 출력하는 이더와는 완전히 다른 모델입니다.
또한, UTXO의 락킹 스크립트( 잠금 스크립트)를 사용자 지정할 수 있으며, 디지털 서명과 공개 키(P2PKH)가 필요한 "특정 비트코인 주소의 소유자만 잠금 해제 가능"하도록 UTXO를 설정할 수 있습니다. 그리고 P2SH(Pay-to-Script-Hash) 거래 유형에서는 UTXO 잠금 스크립트에 스크립트 해시를 추가할 수 있으며, 해당 해시에 해당하는 원본 스크립트 이미지를 제출하고 해당 원본 스크립트 이미지에 미리 설정된 조건을 충족하는 사람은 누구나 UTXO의 잠금을 해제할 수 있습니다.. BitVM이 사용하는 탭루트 스크립트는 P2SH와 유사한 기능을 사용합니다.
비트코인 스크립트가 트리거되는 방법
우리는 비트코인 스크립트가 어떻게 트리거되는지 보여주는 예로 P2PKH를 사용할 것이며, 어떻게 트리거되는지 이해해야만 더 복잡한 탭루트와 BitVM을 이해할 수 있습니다.P2PKH는 "공개 키 해시 지불"로 알려져 있으며, 이 시나리오에서 UTXO의 잠금 스크립트는 다음과 같이 설정됩니다. 이 시나리오에서 UTXO는 잠금 스크립트에 공개 키 해시를 설정하고 잠금을 해제할 때 해당 해시에 해당하는 공개 키를 제출해야 하며, 이는 기본적으로 일반 비트코인 전송과 동일한 개념입니다.
이 시점에서 비트코인 노드는 잠금 스크립트에 어떤 공개키를 설정할지, 어떤 공개키가 잠금 스크립트에 설정될지 결정합니다. 그리고 잠금 스크립트에 지정된 공개키 해시, 즉 잠금 해제자가 제출한 '키'와 UTXO가 미리 설정한 '잠금'이 서로 일치하는지 확인합니다.
또한 P2PKH 시나리오에서. 트랜잭션을 수신하면 비트코인 노드는 사용자가 제공한 잠금 해제 스크립트 ScriptSig와 잠금 해제할 UTXO의 잠금 스크립트 ScriptPubkey를 연결하고 BTC 스크립트의 실행 환경 내에서 이를 실행합니다. 다음 이미지는 실행 전 스플라이스를 보여줍니다:
BTC 스크립팅 환경에 대해 잘 모르는 독자가 있을 수 있어 간략하게 소개해드리겠습니다. 먼저, BTC 스크립트에는 두 가지 요소가 포함되어 있습니다.
데이터 및 옵코드. 데이터와 옵코드는 왼쪽에서 오른쪽 순서로 스택에 눌려지고 지정된 로직에 따라 실행되어 최종 결과를 얻습니다(스택이 무엇인지에 대한 자세한 설명은 하지 않겠지만 Chatgpt의 독자에게 맡기겠습니다).
위 이미지(예: left)는 누군가 잠금 해제 스크립트가 포함된 ScriptSig라는 스크립트를 업로드하는 것을 보여줍니다. 왼쪽에는 누군가가 자신의 디지털 서명과 공개 키가 포함된 잠금 해제 스크립트인 ScriptSig를 업로드했고, 오른쪽에는 UTXO를 생성할 때 UTXO 생성자가 설정한 옵코드와 데이터가 포함된 잠금 스크립트인 ScriptPubkey가 있습니다(각 옵코드의 의미는 알 필요가 없고 일반적인 사항만 알면 됩니다).
DUP, HASH160 및 EQUALVERIFY는 위 이미지의 오른쪽 잠금 스크립트에 있는 옵코드입니다, 위 그림 오른쪽의 잠금 스크립트에 있는 EQUALVERIFY와 다른 옵코드는 왼쪽의 잠금 해제 스크립트에 전달된 공개키와 잠금 스크립트에 미리 설정된 공개키 해시를 비교하여 같으면 잠금 해제 스크립트에 업로드된 공개키가 잠금 스크립트에 미리 설정된 공개키 해시값과 일치하여 1차 검증을 통과했다는 의미입니다.
하지만 문제가 있습니다: UTXO 잠금 스크립트의 내용은 실제로 체인에서 공개적으로 사용 가능합니다. UTXO 잠금 스크립트의 내용은 실제로 체인에 공개되어 있어 누구나 그 안에 포함된 공개키 해시를 관찰할 수 있으며, 누구나 해당 공개키를 업로드하고 자신이 '선택된' 사람이라고 거짓으로 주장할 수 있습니다. 따라서 공개 키와 공개 키 해시를 확인한 후에는 트랜잭션의 개시자가 실제로 공개 키의 실제 컨트롤러인지 확인해야 하며, 이를 위해서는 디지털 서명을 확인해야 합니다. 잠금 스크립트의 CHECKSIG 연산 코드는 디지털 서명 확인을 담당합니다.
요약하면, P2PKH 시나리오에서는 다음과 같습니다. 트랜잭션 개시자가 제출한 잠금 해제 스크립트에는 잠금 스크립트에 지정된 공개 키 해시와 일치해야 하는 공개 키와 디지털 서명이 포함되어 있고 트랜잭션이 올바르게 디지털 서명되어 있으며 이러한 조건이 충족되어야 UTXO를 성공적으로 잠금 해제할 수 있습니다.
(이 이미지는 동적입니다: P2PKH 시나리오에서 비트코인 잠금 해제 스크립트의 도식)
출처: https://learnmeabitcoin.com/ 기술/스크립트)
물론 비트코인은 물론 비트코인 네트워크는 공개 키/공개 키 해시에 대한 지불뿐만 아니라 P2SH(Pay to Script 해시) 등 다양한 거래 유형을 지원합니다. 이 모든 것은 UTXO 생성 시 사용자 지정 잠금 스크립트가 무엇으로 설정되어 있는지에 따라 달라집니다.
잠금 스크립트에서 스크립트 해시를 미리 설정할 수 있으며, 잠금 해제 스크립트는 스크립트 해시에 해당하는 스크립트의 전체 내용을 제출해야 한다는 점에 유의해야 합니다. 비트코인 노드는 이 스크립트를 실행할 수 있으며, 이 스크립트에 다중 서명 확인 로직이 정의되어 있으면 비트코인 체인에서 다중 서명 지갑 효과를 구현하는 데 사용할 수 있습니다.
물론 P2SH 시나리오에서 UTXO의 생성자는 잠금을 해제할 사람으로 하여금 UTXO 생성자는 향후 UTXO를 잠금 해제할 사람에게 스크립트 해시에 해당하는 스크립트의 내용을 미리 알려줘야 하며, 양측이 이 스크립트의 내용을 알고 있다면 다중서명보다 더 복잡한 비즈니스 로직을 구현할 수 있습니다.
명확하게 말하면, 비트코인 체인은 블록에 어떤 UTXO가 있는지 직접 기록하지 않습니다. ) 어떤 UTXO가 어떤 주소와 연결되어 있는지 직접 기록하지 않고, 어떤 공개 키 해시/어떤 스크립트 해시로 UTXO를 잠금 해제할 수 있는지만 기록하지만, 공개 키 해시/스크립트 해시(지갑 인터페이스에 표시되는 횡설수설하는 코드 조각)를 기반으로 해당 주소를 빠르게 파악할 수 있습니다.
블록 브라우저와 지갑 인터페이스에서 xx 주소에 xx 양의 비트코인이 표시되는 이유는 블록 브라우저와 지갑 프로젝트가 해당 데이터를 파싱하여 모든 블록을 스캔하고 잠금 스크립트에 선언된 공개 키 해시/스크립트 해시를 기반으로 해당 '주소'를 계산하기 때문입니다. 그런 다음 주소 XX라는 이름 아래에 몇 개의 비트코인이 있는지 표시합니다.
분리 증인 대... serif; font-size: 18px;">P2SH의 개념을 이해하면 BitVM이 의존하는 탭루트에 한 걸음 더 가까워집니다. 하지만 그 전에 중요한 개념인 증인과 격리된 증인을 이해해야 합니다.
이전 섹션의 잠금 해제 및 잠금 스크립트와 UTXO 잠금 해제 프로세스를 다시 살펴보니 문제가 발견됩니다. 잠금 해제 프로세스를 살펴보면 트랜잭션의 디지털 서명이 잠금 해제 스크립트에 포함되어 있고, 서명을 생성할 때 잠금 해제 스크립트를 커버할 수 없기 때문에(서명 생성에 사용되는 파라미터에 서명 자체를 포함할 수 없음) 디지털 서명이 잠금 해제 스크립트 외부 부분만 커버할 수 있어 트랜잭션 데이터의 백본과만 연관될 수 있고 전체 거래 데이터를 커버할 수 없다는 문제를 발견할 수 있습니다.
이런 식으로 이러한 경우 트랜잭션의 잠금 해제 스크립트가 트랜잭션의 잠금 해제 스크립트가 중개자에 의해 약간 변조되더라도 서명 검사 결과에는 영향을 미치지 않습니다. 예를 들어, 비트코인 노드나 마이닝 풀은 서명 확인이나 거래 결과에 영향을 주지 않고 거래의 데이터를 약간 변경하는 다른 데이터를 거래의 잠금 해제 스크립트에 삽입한 다음 프로세스가 끝날 때 거래의 해시/거래 ID를 변경할 수 있습니다. 이를 트랜잭션 확장성 문제라고 합니다.
이 방식의 단점은 여러 트랜잭션을 연속으로 시작하려는 경우와 순차적 종속성이 있는 여러 트랜잭션을 연속으로 시작하려는 경우(예: 트랜잭션 3은 트랜잭션 2의 출력을 참조하고 트랜잭션 2는 트랜잭션 1의 출력을 참조), 연속으로 이어지는 트랜잭션은 이전 트랜잭션의 ID(해시)를 참조해야 하며 채굴 풀이나 비트코인 노드와 같은 중개자가 잠금 해제 스크립트의 내용을 조정하여 거래의 업로드 해시를 예상과 다르게 만들 수 있고 미리 만든 순차적 종속성이 무효화될 수 있다는 것입니다. 미리 생성한 트랜잭션이 무효화됩니다.
실제로 DLC Bridge 및 BitVM2 시나리오에서 트랜잭션의 순차적 상관관계는 일괄적으로 빌드됩니다. 는 순차적 상관관계로 트랜잭션을 빌드하므로 앞서 언급한 시나리오가 드물지 않습니다.
단순히 말해, 트랜잭션 확장성의 문제는 잠금 해제 스크립트의 데이터가 포함된 트랜잭션 ID/해시가 계산되고 비트코인 노드와 같은 중개자가 잠금 해제 스크립트의 내용을 미세 조정할 수 있어 사용자가 예상하는 것과 일치하지 않는 트랜잭션 ID가 생성된다는 것입니다. 사실 이는 비트코인의 초기 설계가 제대로 고려되지 않은 역사적 유산입니다.
분리 증인/SegWit 업그레이드는 실제로 거래 ID와 거래 ID를 같은 수준으로 변경하는 방식이었습니다. 업그레이드는 실제로 트랜잭션 ID와 잠금 해제 스크립트를 완전히 분리하는 것으로, 트랜잭션 해시 계산에 잠금 해제 스크립트 데이터가 포함될 필요가 없습니다. 세그윗 업그레이드를 따르는 UTXO 잠금 스크립트에는 기본적으로 "OP_0"이라는 옵코드가 토큰으로 작동하며, 해당 잠금 해제 스크립트의 이름은 시그스크립트에서 위트니스로 변경될 것입니다.
분리된 위트니스 규칙을 사용하면 트랜잭션 확장성이 적절히 해결되며 비트코인 노드로 전송되는 트랜잭션 데이터를 미세 조정하는 것에 대해 걱정할 필요가 없습니다. 물론 너무 복잡하게 생각할 필요는 없습니다. P2WSH의 기능은 앞서 설명한 P2SH와 근본적으로 다르지 않으며, UTXO 잠금 스크립트에 스크립트 해시를 미리 설정하고 잠금 해제 스크립트 제출자가 스크립트 내용에 대한 해시 대응을 체인에 제출하고 실행할 때까지 기다릴 수 있습니다.
하지만 구현하려는 스크립트가 특히 크고 코드가 많은 경우 UTXO 방법을 사용하는 것이 더 쉽게 구현할 수 있습니다. 특히 많은 양의 코드가 포함된 스크립트의 경우, 일반적인 방법으로는 전체 스크립트를 비트코인 체인에 제출할 수 없습니다(블록당 크기 제한이 있습니다). 그렇다면 어떻게 해야 할까요? BitVM은 탭루트에 구축된 복잡한 솔루션으로, 체인에 업로드할 스크립트를 간소화하고 단순화하기 위해 Taproot가 필요합니다.