비트코인 프로그램성 체계 성찰 및 언약 설명

저자: Chakra; 편집: 0xjs@GoldenFinance

이 글은 Chakra에서 발행하는 비트코인 확장성 기사 시리즈의 3부입니다.

1부는 Golden Finance의 이전 글 "비트코인의 네이티브 확장성 체계 검토: 세그윗과 탭루트",

파트 II는 골든 파이낸스의 이전 기사 "비트코인 확장성: 레이어2 체계와 관련 프로젝트 분석"을 참조하세요.

이 글의 세 번째 부분은 다음과 같습니다:

개요

이더와 같은 튜링 완전형 블록체인에 비해 비트코인 스크립트는 기본적인 연산만 가능하고 곱셈과 나눗셈조차 지원하지 않는 극히 제한적인 것으로 간주됩니다. 게다가 블록체인 자체 데이터는 스크립트에서 사실상 접근할 수 없기 때문에 유연성과 프로그래밍 가능성이 심각하게 부족합니다. 그 결과 비트코인 스크립트에서 인트로스펙션을 활성화하기 위한 노력이 있었습니다.

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

현재 비트코인 스크립트에서 인트로스펙션을 지원하는 주요 옵코드는 CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, CHECKSIG의 세 가지와 그 변형인 CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, 그리고 CHECKMULTISIGVERIFY.

제한이라고도 하는 컨벤트는 단순히 자금 이체 방법에 대한 제한으로, 사용자가 UTXO를 할당하는 방법을 지정할 수 있습니다. 많은 컨벤트는 인트로스펙션 옵코드를 통해 구현되며, 인트로스펙션에 대한 논의는 현재 비트코인 옵테크 컨벤트 주제 아래에 분류되어 있습니다.

비트코인에는 현재 두 가지 컨트랙트, 즉 CSV(CheckSequenceVerify)와 CLTV(CheckLockTimeVerify)가 있으며, 둘 다 라이트닝 네트워크와 같은 많은 확장 솔루션의 기반이 되는 시간 기반 컨트랙트입니다. 이는 비트코인의 확장성 솔루션이 인트로스펙션과 계약에 크게 의존하고 있음을 보여줍니다.

토큰 전송에 조건을 어떻게 추가하나요? 암호화폐 공간에서 가장 일반적인 방법은 일반적으로 해시를 통한 약속입니다. 전송 요건이 충족되었음을 증명하기 위해서는 검증을 위한 서명 메커니즘도 필요합니다. 따라서 계약서에는 해시와 서명에 대한 많은 조정 사항이 있습니다.

다음에서는 널리 논의되고 있는 커버넌트 옵코드 제안에 대해 설명합니다.

CTV(체크 템플릿 검증) BIP-119

CTV(체크 템플릿 검증)는 커뮤니티에서 많은 관심을 받고 있는 BIP-119의 비트코인 업그레이드 제안으로, 출력 스크립트가 거래에서 자금 지출에 대한 템플릿을 지정할 수 있도록 합니다. nVersion, nLockTime, scriptSig 해시, 입력 카운트, 시퀀스 해시, 출력 카운트, 출력 해시, 입력 인덱스 등의 필드에 템플릿을 지정할 수 있습니다. 이러한 템플릿 제한은 해시 약속을 통해 구현되며, 자금이 지출되면 스크립트는 지출 트랜잭션의 지정된 필드 해시값이 입력 스크립트의 해시값과 일치하는지 확인합니다. 이를 통해 해당 UTXO에 대한 향후 트랜잭션의 시간, 방법, 금액을 효과적으로 제한할 수 있습니다.

이미지 src="https://img.jinse.cn/7260452_watermarknone.png" title="7260452" alt="ETeWIiEOpZIoadLWMGuZolYJxBSiIvjun7ghUai6.png">< /p>

이 해시에서 입력 TXID가 제외된다는 점에 주목할 필요가 있습니다. 이 제외가 필요한 이유는 기존 및 분리된 감시 트랜잭션 모두에서 기본 SIGHASH_ALL 서명 유형을 사용할 때 TXID는 scriptPubKey의 값에 따라 달라지기 때문입니다. TXID를 포함하면 해시 커미트먼트에 순환 종속성이 발생하여 구성할 수 없게 됩니다.

이미지 src="https://img.jinse.cn/7260453_watermarknone.png" title="7260453" alt="YQuSclZQ9PdTPgwbtCrNYxPFgoosPBridKqJcVfw.png">< /p>

CTV의 내성적 접근 방식은 해싱을 위해 지정된 트랜잭션 정보를 직접 가져온 다음 스택의 커밋과 비교하는 것입니다. 이 내성적 접근 방식은 체인 공간이 덜 필요하지만 유연성이 다소 부족합니다.

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

CTV는 원래 비트코인에서 혼잡을 완화하기 위해 제안되었으며, 혼잡 제어라고도 할 수 있습니다. 혼잡이 심할 때 CTV는 한 번의 트랜잭션에 여러 개의 미래 트랜잭션을 커밋하고, 피크 시간대에 여러 트랜잭션을 방송하지 않으며, 혼잡이 완화되면 실제 트랜잭션을 완료할 수 있습니다. 이는 거래소 운영 중에 특히 유용할 수 있습니다. 또한 템플릿을 사용하여 해킹을 방지하기 위해 볼트를 구현할 수도 있습니다. 자금의 흐름이 미리 정해져 있기 때문에 해커가 CTV 스크립트를 사용해 UTXO를 자신의 주소로 유도할 수 없습니다.

CCTV는 레이어 2 네트워크를 크게 향상시킬 수 있습니다. 예를 들어, 라이트닝 네트워크에서 CTV는 단일 UTXO를 CTV 트리로 확장하여 타임아웃 트리와 채널 팩토리를 생성하고 단일 트랜잭션과 단일 확인으로 여러 상태 채널을 열 수 있습니다. 또한 CTV는 ATLC를 통해 아크 프로토콜에서 아토믹 트랜잭션을 지원합니다.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118은 탭스크립트를 위한 새로운 유형의 서명 해시 플래그를 도입하여 보다 유연한 지출 로직을 촉진하기 위해 설계되었습니다. APO와 CTV는 많은 유사점을 가지고 있습니다. 스크립트펍키와 TXID 사이의 루프를 해결할 때, APO의 접근 방식은 관련 입력 정보를 제외하고 출력에만 서명하여 트랜잭션을 다른 UTXO에 동적으로 바인딩할 수 있도록 하는 것입니다.

논리적으로 서명 검증 연산 OP_CHECKSIG(및 그 변형)는 세 가지 기능을 수행합니다.

1, 비용 트랜잭션의 일부를 조립합니다.

2. 해시 처리.

3. 해시가 주어진 키에 의해 서명되었는지 확인합니다.

서명의 세부 사항에는 매우 많은 유연성이 있으며, SIGHASH 플래그는 트랜잭션의 어떤 필드에 서명할지 결정합니다. SIGHASH 플래그는 BIP 342의 서명 피연산자의 정의에 따라 SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE 및 SIGHASH_ANYONECANPAY로 분류되며, SIGHASH_ANYONECANPAY는 입력을 제어하고 다른 플래그는 출력을 제어합니다.

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

이러한 SIGHASH 플래그는 입력의 효과를 제거하지 않으며, SIGHASH_ANYONECANPAY를 사용하더라도 입력의 커밋이 필요합니다.

따라서 BIP 118은 SIGHASH_ANYPREVOUT을 제안합니다. 소비된 입력 UTXO(PREVOUT이라고 함)에 커밋하는 대신, APO 서명은 단순히 출력에 서명하여 비트코인 제어에 더 큰 유연성을 제공합니다. 계약은 트랜잭션을 미리 제작하고 해당 일회용 서명과 공개 키를 생성하여 구현되며, 해당 공개 키 주소로 전송된 자산은 미리 제작된 트랜잭션을 통해 사용해야 합니다. APO의 유연성은 트랜잭션 복구에도 사용할 수 있으며, 낮은 수수료로 인해 거래가 체인에서 중단되면 새로운 서명 없이도 다른 거래를 쉽게 생성하여 수수료를 높일 수 있습니다. 또한 다중 서명 지갑의 경우 이미 사용한 입력값에 의존하지 않기 때문에 운영이 더 쉬워집니다.

스크립트Pub키와 입력 TXID 사이의 루프를 제거했기 때문에 APO는 출력 데이터를 Witness에 추가하여 인트로스펙션을 수행할 수 있지만, 여전히 추가적인 Witness 공간 소비가 필요합니다.

라이트닝 네트워크와 볼트와 같은 오프체인 프로토콜의 경우, APO는 중간 상태를 저장할 필요성을 줄여 스토리지 요구사항과 복잡성을 크게 줄이며, APO의 가장 즉각적인 사용 사례는 채널 팩토리를 단순화하고, 가볍고 저렴한 워치타워를 구축하고, 오류 상태를 남기지 않고 일방적인 출구를 허용하여 라이트닝 네트워크를 여러 면에서 향상시키는 엘투(Eltoo)입니다. 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 옵코드가 포함되어야 합니다.

이미지 src="https://img.jinse.cn/7260455_watermarknone.png" title="7260455" alt="Mf7FxhyusaxIIxx4THOIai41rQx1I6UN1q5fSrFK.png">< /p>

OP_VAULT는 어떻게 중단 가능한 시간 제한 잠금 인출을 구현하나요? OP_VAULT는 사용된 OP_VAULT 스크립트를 지정된 스크립트로 대체하여 나머지 탭루트 리프 노드는 변경하지 않은 채 효과적으로 MAST의 단일 리프만 업데이트하는 방식으로 이를 수행합니다. 이 설계는 TLUV와 유사하지만 OP_VAULT가 내부 키에 대한 업데이트를 지원하지 않는다는 점이 다릅니다.

스크립트 업데이트 중에 템플릿을 도입하여 결제를 제한할 수 있습니다. 시간 잠금 매개변수는 OP_VAULT로 지정되며, CTV 옵코드용 템플릿은 이 스크립트 경로를 통해 사용할 수 있는 출력 집합을 제한합니다.

볼트용으로 설계된 BIP-345는 OP_VAULT 및 OP_VAULT_RECOVER를 활용하여 사용자에게 보안성이 높은 키(예: 종이 지갑 또는 분산 다중 서명)를 복구 경로로 사용하는 보안 에스크로 방법을 제공하는 동시에 주기적 결제를 위한 특정 대기 시간을 구성합니다. 사용자의 장치는 볼트의 지출을 지속적으로 모니터링하고 예기치 않은 송금이 발생할 경우 사용자가 복구를 시작할 수 있도록 합니다.

BIP-345를 통해 볼트를 구현하려면 특히 복구 거래에 대한 비용 고려가 필요합니다. 가능한 해결책으로는 CPFP(부모 노드에 비용을 지불하는 자식 노드), 임시 앵커, 새로운 SIGHASH_GROUP 서명 해시 플래그가 있습니다.

TLUV (TapleafUpdateVerify)

TLUV 솔루션은 탭루트를 중심으로 구축되었으며, 공유 UTXO 출구를 효율적으로 처리하도록 설계되었습니다. 기본 원칙은 TLUV 스크립트에 설명된 대로 탭루트 출력을 사용할 때 암호화 변환과 탭루트 주소의 내부 구조를 통해 내부 키와 MAST(탭스크립트 시도)를 부분적으로 업데이트할 수 있다는 것입니다. 이를 통해 커버넌트 기능이 가능합니다.

TLUV 체계의 개념은 새로운 옵코드 TAPLEAF_UPDATE_VERIFY를 도입하여 현재 비용 입력을 기반으로 새로운 탭루트 주소를 생성하는 것입니다. 이는 다음 작업 중 하나 이상을 수행하여 달성할 수 있습니다.

• 내부 공개 키 업데이트

• 머클 경로 트림

• 현재 실행 중인 스크립트 삭제

< li>

머클 경로 끝에 새 단계 추가

특히 TLUV는 세 가지 유형의 입력을 허용합니다:

• 내부 공개 키를 업데이트할 방법을 지정합니다.

• 머클 경로의 새 단계를 지정하는 한 가지 방법을 지정합니다.

• 현재 스크립트를 삭제할지 여부 및/또는 정리할 머클 경로의 단계 수를 지정합니다.

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

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

TLUV 옵코드는 기존 탭루트 트라이를 업데이트하여 일부 지출 제한을 구현하지만, 출력 금액에 대한 인트로스펙션은 구현하지 않습니다. 따라서 새로운 옵코드인 IN_OUT_AMOUNT도 필요하며, 이 옵코드는 스택에 두 가지 항목, 즉 이 입력에 대한 UTXO 금액과 출력에 해당하는 금액을 푸시한 다음 TLUV를 사용하는 사용자는 수학 연산자를 사용하여 자금이 업데이트된 scriptPubKey에 적절하게 유지되는지 확인해야 합니다.

사토시 단위의 금액을 표현하려면 최대 51비트가 필요하지만 스크립트에서는 32비트 연산만 허용하기 때문에 출력 금액의 인트로스펙션은 복잡성을 더합니다. 이를 위해서는 스크립트의 연산자를 업그레이드하기 위해 연산자 동작을 재정의하거나 IN_OUT_AMOUNT를 SIGHASH_GROUP으로 대체해야 합니다.

TLUV는 탈중앙화된 레이어 2 풀링을 위한 솔루션이 될 가능성이 있지만, 탭루트 트라이의 튜닝 안정성은 아직 확인이 필요합니다.

MATT

MATT(머클라이즈 올 더 띵스)는 상태의 머클라이즈, 스크립트의 머클라이즈, 연기의 머클라이즈라는 세 가지 목표를 달성하여 범용 스마트 컨트랙트.

• 상태 머클라이징: 각 리프 노드가 상태의 해시를 나타내고 머클 루트가 컨트랙트의 전체 상태를 나타내는 머클 트라이를 구축하는 것이 포함됩니다. .

• 스크립트 머클화: 각 리프 노드가 가능한 상태 전환 경로를 나타내는 탭스크립트를 사용하여 MAST를 구성하는 것을 말합니다.

• 퍼포먼스 머클리라이징: 암호화 약속과 부정 챌린지 메커니즘을 통해 퍼포먼스를 머클리라이징하는 것을 말합니다. 모든 연산 함수에 대해 참여자는 체인에서 계산한 다음 약속 f(x)=y를 발행할 수 있습니다. 다른 참여자가 잘못된 결과 f(x)=z를 발견하면 이의를 제기할 수 있습니다. 중재는 낙관적 롤업의 작동 방식과 유사하게 이진 검색을 통해 이루어집니다.

머서화된 실행

MATT를 구현하려면 비트코인 스크립팅 언어에 다음 기능이 있어야 합니다.

• 출력에 특정 스크립트(및 그 번호)

• 데이터를 출력에 추가

• 현재 입력(또는 다른 입력)에서 데이터 읽기

두 번째 포인트는 동적 데이터는 소비자가 제공한 입력 데이터로부터 상태를 계산할 수 있다는 것을 의미하며, 이는 다음 상태와 추가 데이터를 결정할 수 있는 상태 머신의 시뮬레이션을 허용하기 때문에 MATT 체계는 앞서 제안한 OP_CHECKCONTRACTVERIFY(OP_CCV) 옵코드를 통해 이를 달성합니다. CHECKOUTPUTCONTRACTVERIFY 및 OP_CHECKINPUTCONTRACTVERIFY 옵코드가 결합되어 추가 플래그 파라미터를 사용하여 연산 대상을 지정합니다.

출력량 제어: 가장 간단한 방법은 직접 인트로스펙션이지만, 출력량은 64비트 숫자이고 64비트 연산을 필요로 하므로 비트코인 스크립트에 상당한 복잡성을 초래하며, OP_CCV는 OP_VAULT와 같은 지연 검사 방법을 사용하는데, 이는 CCV에서 동일한 출력량에 대한 모든 입력의 입력량을 합산하여 해당 출력량의 하한으로 사용하는 것입니다. 이 지연은 이 확인이 입력을 평가하는 스크립트가 아니라 트랜잭션 중에 발생하기 때문입니다.

사기 증명의 보편성을 고려할 때, MATT 계약의 일부 변형은 모든 유형의 스마트 콘트랙트 또는 레이어 2 구조에 구현될 수 있어야 하지만, 추가 요구 사항(예: 자금 잠금 및 챌린지 기간 지연)을 정확하게 평가해야 하고, 어떤 애플리케이션이 거래를 수락할 수 있는지 평가하기 위해서는 추가 연구가 필요합니다. 예를 들어, 암호화 약속과 사기 챌린지 메커니즘을 사용하여 OP_ZK_VERIFY 함수를 에뮬레이션하여 비트코인에서 신뢰 없는 롤업을 구현하는 것입니다.

실제로, 이는 이미 일어나고 있으며, 요한 토로스 할세스는 MATT 소프트 포크 제안에서 OP_CHECKCONTRACTVERIFY 옵코드를 사용하여 스마트 콘트랙트에서 OP_CHECKCONTRACTVERIFY 옵코드를 사용할 수 있는 elftrace를 구현했습니다. 엘프트레이스는 RISC-V 컴파일을 지원하는 모든 프로그램이 비트코인 블록체인에서 검증할 수 있도록 하여 계약 당사자가 계약 검증을 통해 자금에 액세스할 수 있도록 함으로써 비트코인 네이티브 검증에 연결합니다.

CSFS (OP_CHECKSIGFROMSTACK)

APO 옵코드 소개에서 우리는 OP_CHECKSIG(및 관련 연산)가 트랜잭션 조립, 해시 계산, 서명 검증을 담당한다는 것을 이해했습니다. 그러나 이러한 연산으로 확인된 메시지는 옵코드를 통해 트랜잭션을 직렬화할 때 나오며, 다른 메시지는 지정할 수 없습니다. 요컨대, OP_CHECKSIG(및 관련 연산)는 서명 메커니즘을 사용해 트랜잭션에 입력으로 사용된 UTXO가 서명 보유자가 사용하도록 승인되었는지 확인함으로써 비트코인을 보호하는 역할을 합니다.

CSFS는 이름에서 알 수 있듯이 스택으로부터의 서명을 확인합니다. CSFS 오퍼코드는 스택으로부터 서명, 메시지, 공개 키의 세 가지 매개변수를 받아 서명의 유효성을 확인합니다. 즉, 어떤 메시지든 증인을 통해 스택에 전달하고 CSFS를 통해 검증할 수 있으며, 이를 통해 비트코인의 혁신 중 일부를 구현할 수 있습니다.

이미지 src="https://img.jinse.cn/7260458_watermarknone.png" title="7260458" alt="ufRclQ8cqnOcgvNybysSPJbGhlmT9GUce1JT79fY.png">< /p>

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

OP_CAT은 트랜잭션의 여러 필드를 연결하여 직렬화를 완료할 수 있으므로 내사에 필요한 트랜잭션 필드를 보다 정밀하게 선택할 수 있기 때문에 CSFS에는 종종 OP_CAT이 함께 제공됩니다. OP_CAT이 없으면 스크립트는 개별적으로 검사할 수 있는 데이터에서 해시를 다시 계산할 수 없으므로 해시가 특정 값에 해당하는지 확인하는 것만 할 수 있으므로 토큰은 하나의 특정 트랜잭션을 통해서만 사용할 수 있습니다.

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

TXHASH (OP_TXHASH)

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

TXHASH와 CTV의 유사성 때문에 커뮤니티에서 두 가지에 대한 많은 논의가 이루어졌습니다.

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

컨트랙팅 관점에서 볼 때, TXHASH는 수정하려는 트랜잭션 데이터의 모든 부분을 스택에 푸시하고 함께 해시한 후 결과 해시가 수정 내용과 일치하는지 검증하는 "덧셈 컨트랙트"를 생성하는 데 더 적합하고, CTV는 수정하려는 트랜잭션 데이터의 모든 부분을 스택에 푸시하고 함께 해시한 후 결과 해시가 수정 내용과 일치하는지 검증하는 "뺄셈 컨트랙트"를 생성하는 데 더 적합합니다. "빼기 계약"은 트랜잭션 데이터의 모든 부분을 스택에 푸시하고, 그 결과 해시가 수정된 것과 일치하는지 검증합니다. 그런 다음 롤링 SHA256 연산 코드를 사용하여 트랜잭션 해시 데이터의 접두사에 커밋된 고정 중간 상태에서 해시 처리가 시작됩니다. 자유 부분은 이 중간 상태로 해시됩니다.

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

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

OP_CAT

OP_CAT은 사토시 나카모토가 보안상의 이유로 처음에 삭제했지만 최근 비트코인 코어 개발자 사이에서 열띤 토론을 불러일으키고 웹에서 밈 문화까지 생겨난 미스터리한 옵코드입니다. 결국 OP_CAT은 BIP-347에 따라 승인되었으며, 최근 메모리에서 통과될 가능성이 가장 높은 BIP 제안으로 묘사되고 있습니다.

실제로 OP_CAT의 동작은 매우 간단합니다. 스택에서 두 요소를 결합하는 것입니다. 어떻게 코버넌트 기능을 구현할 수 있을까요?

이미지 src="https://img.jinse.cn/7260459_watermarknone.png" title="7260459" alt="CurBp6rgoHSQewI7R903DZEdcL9276C3Q8wuqdOc.png">< /p>

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

이미지 src="https://img.jinse.cn/7260460_watermarknone.png" title="7260460" alt="dKEhYQTFMs2mtcaOuUz0gdchcUlx6dZt6gMUcYhV.png">< /p>

앞서 언급했듯이, CSFS는 OP_CAT의 도움으로 일반적인 컨트랙트 체계를 가능하게 합니다. 사실 CSFS 없이도 슈노르 서명 구조를 사용하여 OP_CAT 자체로도 트랜잭션 인트로스펙션이 가능합니다.

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

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

일반적인 암호화에 대한 자세한 내용은 앤드류 포엘스트라의 "CAT와 슈노르 트릭" 문서를 참조하세요.

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

결론

비트코인을 확장하고 프로그래밍 가능성을 향상시키기 위한 다양한 전략을 살펴보면서, 앞으로 나아갈 길에는 네이티브 개선, 오프체인 연산, 복잡한 스크립팅 기능이 혼합되어 있다는 것을 알 수 있었습니다.

유연한 기본 계층 없이 보다 유연한 두 번째 계층을 구축하는 것은 불가능합니다.

오프체인 컴퓨팅 확장은 미래이지만, 이러한 확장을 더 잘 지원하고 진정한 글로벌 통화가 되려면 비트코인의 프로그래밍 기능에 획기적인 발전이 필요합니다.

그러나 비트코인의 연산 특성은 이더리움의 그것과 근본적으로 다릅니다. 비트코인은 계산의 한 형태로서 '검증'만 지원하고 일반적인 계산을 수행할 수 없는 반면, 이더는 본질적으로 계산적이며 검증은 계산의 부산물입니다. 이러한 차이는 한 가지 방식으로 확인할 수 있습니다. 이더는 실행할 수 없는 트랜잭션에 대해 가스 수수료를 부과하지만 비트코인은 그렇지 않습니다.

계약은 계산이 아닌 검증을 기반으로 하는 스마트 컨트랙트의 한 형태입니다. 소수의 사토시 나카모토 근본주의자를 제외하고는 모두가 컨트랙트가 비트코인을 개선하기 위한 좋은 옵션이라는 데 동의하는 것 같습니다. 그러나 커뮤니티는 여전히 어떤 방식으로 콘트랙트를 구현해야 하는지에 대해 치열한 논쟁을 벌이고 있습니다.

APO, OP_VAULT, TLUV는 직접 적용을 선호하며, 이 세 가지 방법 중 하나를 선택하면 특정 애플리케이션에 구현하는 데 더 저렴하고 효율적일 수 있습니다. 라이트닝 네트워크 애호가는 LN-대칭을 구현하기 위해 APO를 선택하고, 볼트를 구현하려는 사용자는 OP_VAULT를 사용하는 것이 더 좋으며, 코인풀 구축에는 TLUV가 더 나은 프라이버시와 효율성을 제공합니다. OP_CAT과 TXHASH는 기능이 더 풍부하고 보안 취약성이 적으며 다른 옵코드와 결합하여 더 많은 것을 구현할 수 있습니다. OP_CAT과 TXHASH는 기능이 더 풍부하고 보안 취약점이 있을 가능성이 높으며 다른 옵코드와 결합하여 더 많은 사용 사례를 구현할 수 있지만 스크립트 복잡성이 증가될 수 있습니다. ctv와 csfs는 블록체인 처리를 적용하여 ctv는 지연된 출력, csfs는 지연된 서명을 가능하게 합니다. matt는 머클 트리 구조를 활용하여 범용 스마트 계약을 가능하게 하는 최적화 실행 및 사기 방지 전략이 돋보이지만 인트로스펙션 기능에는 여전히 새로운 옵코드가 필요합니다.

비트코인 커뮤니티에서 소프트 포크를 통해 커버넌트를 인수할 가능성에 대해 활발히 논의하고 있습니다. 스탁넷은 OP_CAT 합병 후 6개월 이내에 비트코인 네트워크에 정착할 계획으로 비트코인 생태계에 합류한다고 공식 발표했습니다. 차크라는 OP_CAT 소프트 포크 합병을 추진하면서 비트코인 생태계의 최신 상황을 지속적으로 모니터링하고 커버넌트가 비트코인 생태계에 제공하는 프로그래밍 기능을 활용할 것입니다. 차크라는 비트코인 생태계를 지속적으로 모니터링하여 OP_CAT 소프트 포크 합병을 추진하고 커버넌트가 제공하는 프로그래밍 기능을 활용하여 보다 안전하고 효율적인 비트코인 결제 레이어를 구축할 것입니다.