작성자: mutourend & lynndel, Bitlayer Labs
1 소개
특정 알고리즘 f에 대해 서로 신뢰하지 않는 두 참가자 Alice와 Bob은 다음과 같은 방법으로 신뢰를 구축할 수 있습니다.
Alice는 x를 입력하고, 알고리즘 f를 실행하여 결과 y를 얻습니다. Bob은 또한 동일한 입력 x를 기반으로 알고리즘 f를 실행하고 결과는 y′입니다. y = y'이면 Bob은 Alice가 제공한 입력 x와 출력 y를 받아들입니다. 이는 블록체인 합의에서 일반적으로 사용되는 특별한 유효성 증명 메커니즘입니다. 그 중 Alice는 블록을 패키징하는 노드이고 Bob은 합의에 참여하는 노드입니다.
Alice는 x를 입력하고, 알고리즘 f에 대해 zk.prove 프로그램을 실행하고, 결과 y와 증명을 얻습니다. Bob은 f, y 및 증명을 기반으로 zk.verify 프로그램을 실행합니다. 결과가 true이면 Bob은 Alice의 결과 y를 승인하고, 결과가 false이면 Bob은 Alice의 결과 y를 승인하지 않습니다. 이는 효율성의 증거입니다. 그 중 Bob은 온체인 계약이 될 수 있습니다.
Alice는 x를 입력하고, 알고리즘 f를 실행하여 결과 y를 얻습니다. Bob은 또한 동일한 입력 x를 기반으로 알고리즘 f를 실행하고 결과는 y′입니다. y = y'이면 아무것도 하지 않고, y ≠ y'이면 Bob은 Alice에게 도전하고 도전받은 프로그램은 f입니다. Alice와 Bob 사이의 상호작용 수는 하나 이상이 될 수 있습니다. 중재는 질문 대응 프로세스를 기반으로 구현됩니다. 이는 사기의 증거입니다. 그중 Bob은 체인 밖에서 모니터링하고 온체인 도전하는 도전자입니다.
Alice는 x를 입력하고, 알고리즘 f에 대해 zk.prove 프로그램을 실행하고, 결과 y와 증명을 얻습니다. Bob은 f, y 및 증명을 기반으로 zk.verify 프로그램을 실행합니다. 결과가 true이면 아무 것도 하지 않습니다. 결과가 false이면 Bob은 Alice에게 도전하고, 도전받는 프로그램은 zk.verify입니다. Alice와 Bob 사이의 상호작용 수는 하나 이상이 될 수 있습니다. Alice와 Bob 사이의 상호작용 수는 하나 이상이 될 수 있습니다. 중재는 질문 대응 프로세스를 기반으로 구현됩니다. 이는 사기의 증거입니다. 그중 Bob은 체인 밖에서 모니터링하고 온체인 도전하는 도전자입니다.
위의 2,3,4에 대해 x는 Layer2 트랜잭션 및 시작 상태, f는 Layer2 합의 프로그램, y는 블록체인 Layer2 확장 계획에 해당하는 트랜잭션 종료 상태라고 합니다. 안에:
타당성 증명(Validity Proof): 비관적인 가정을 바탕으로 승인되기 전에 효과가 입증되어야 하며 즉시 적용됩니다. 타당성 증명에서는 L2 상태 전환이 정확하다는 증거를 제공해야 하며, 이는 세계에 대한 비관적인 관점을 반영합니다. 즉, 상태가 올바른 것으로 입증된 경우에만 상태가 허용됩니다.
사기 증명(Fraud Proof): 낙관적인 가정을 기반으로 하며, 기본적으로 승인되고 잘못된 것으로 입증되지 않는 한 거부됩니다. 챌린지 기간이 있으며, 챌린지 기간이 지나야 적용됩니다. 사기 증명에서는 세계에 대한 낙관적인 관점을 반영하여 L2 상태 전환이 잘못되었다는 증거가 필요합니다. 특정 상태 전환은 잘못된 것으로 입증되지 않는 한 기본적으로 정확합니다.
표 1: 신뢰를 구축하는 방법
또한 다음 사항에 유의하세요.
사기 증명과 유효성 증명을 구별하는 핵심은 SNARK/STARK와 같은 ZK 증명 시스템의 사용 여부를 결정하는 것이 아닙니다. ZK 증명 시스템은 사용된 증명 방법을 나타내고, 사기 또는 유효성은 증명 내용을 나타냅니다. 이것이 표 1의 시나리오 1이 유효성의 증거라고 말하는 이유입니다.
유효성 증명은 적시성이 더 좋지만 온체인 검증의 복잡성은 상대적으로 높습니다. 사기 증명은 온체인 복잡성은 낮지만 적시성이 상대적으로 낮습니다.
표 1의 사례 2와 4의 경우 ZK 재귀 및 조합 기술의 도움으로 여러 f를 계산하고 압축할 수 있어 온체인 오프체인 계산에 대한 검증 비용을 크게 절감하고 절감할 수 있습니다.
현재 견고성 Turing-complete 스마트 계약의 이점을 활용하여 사기 증명 및 유효성 증명 기술이 이더 Layer 2 확장에 널리 사용됩니다. 그러나 비트코인 패러다임 하에서 이러한 기술적 응용은 비트코인의 제한된 opcode 기능 및 1,000개의 스택 요소와 같은 제한으로 인해 여전히 탐색 단계에 있습니다. 비트코인 레이어 2 확장 시나리오를 고려하여 이 글에서는 비트코인 패러다임 하의 한계와 획기적인 기술을 요약하고, 유효성 증명 및 사기 방지 기술을 연구하며, 비트코인 패러다임 하의 고유한 스크립트 분할 기술을 정리합니다.
2 비트코인 패러다임의 한계와 돌파구
비트코인 패러다임에는 많은 제한 사항이 있지만 이러한 제한 사항을 극복하기 위해 다양하고 영리한 방법이나 기술을 사용할 수 있습니다. 예를 들어, 비트 커밋은 UTXO 상태 비저장 제한을 초과할 수 있고, taproot는 스크립트 공간 제한을 초과할 수 있으며, 커넥터 출력은 UTXO 지출 방법 제한을 초과할 수 있으며, 계약은 사전 서명 제한을 초과할 수 있습니다.
2.1 UTXO 모델 및 스크립트 제한사항
비트코인은 UTXO 모델을 채택하고 각 UTXO는 UTXO를 사용하기 위해 충족해야 하는 조건을 정의하는 잠금 스크립트에 잠겨 있습니다. 비트코인 스크립트에는 다음과 같은 제한 사항이 있습니다.
비트코인 스크립트는 상태 비저장입니다.
P2TR 출력 유형의 경우 단일 트랜잭션에 수용할 수 있는 최대 총 opcode 수는 약 400만 개로 전체 블록을 채우는 반면, 다른 출력 유형의 경우 opcode는 10,000개에 불과합니다.
단일 UTXO의 지출 방법은 제한되어 있으며, 결합된 지출 방법에 대한 탐색이 부족합니다.
유연한 계약 기능을 지원하지 않습니다.
스택 크기는 최대 1000개 요소(altstack + 스택)로 제한되며 단일 요소의 최대 크기는 520바이트입니다.
산술 연산(예: 덧셈, 뺄셈)은 4바이트 요소로 제한됩니다. 20바이트 이상과 같은 긴 요소로 수정할 수 없지만 암호화 작업에 필요합니다.
OP_MUL 및 OP_CAT과 같은 Opcode는 비활성화되었습니다. 기존 Opcode를 사용하여 시뮬레이션하는 경우 비용이 매우 높습니다. 예를 들어 1회 BLAKE3 해시를 시뮬레이션하려면 스크립트 크기가 약 75K입니다.
2.2 비트 약속: UTXO 무상태 제한 극복
현재 비트코인 스크립트는 완전히 상태 비저장입니다. 비트코인 스크립트를 실행할 때 각 스크립트 후에 실행 환경이 재설정됩니다. 이로 인해 Bitcoin 스크립트는 기본적으로 제약 조건 스크립트 1과 스크립트 2가 동일한 x 값을 갖도록 지원할 수 없습니다. 그러나 이 문제를 해결할 수 있는 방법이 있습니다. 핵심 아이디어는 어떤 방식으로든 값에 서명하는 것입니다. 값에 대한 서명을 만들 수 있으면 상태 저장 Bitcoin 스크립트를 구현할 수 있습니다. 즉, 스크립트 1과 스크립트 2에서 x 값의 서명을 확인하여 스크립트 1과 스크립트 2에서 동일한 x 값을 강제로 적용할 수 있습니다. 충돌하는 서명이 있는 경우 불이익을 받을 수 있습니다. 즉, 동일한 변수 x가 2개의 다른 값으로 서명됩니다. 해결책은 약간의 헌신입니다.
비트 약속의 원칙은 비교적 간단합니다. 소위 비트는 서명 메시지의 각 비트에 대해 두 개의 서로 다른 해시 값, 즉 hash0과 hash1을 설정하는 것을 의미합니다. 서명해야 하는 비트 값이 0이면 hash0의 preimage0이 표시되고, 서명해야 하는 비트 값이 1이면 hash1의 preimage1이 표시됩니다.
단일 비트 메시지 m ∈ {0,1}을 예로 들면 해당 비트 확약 잠금 해제 스크립트는 사전 이미지일 뿐입니다. 비트 값이 0이면 해당 잠금 해제 스크립트는 preimage0 - "0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"입니다. 1에서 해당 잠금 해제 스크립트는 preimage1 ——"0x47c31e611a3bd2f3a7a42207613046703fa27496"입니다. 따라서 비트 커밋의 도움으로 UTXO의 상태 비저장 제한이 깨질 수 있으며 상태 저장 비트코인 스크립트가 구현되어 다양하고 흥미로운 새 기능이 가능해집니다.
OP_HASH160
OP_DUP
<0xf592e757267b7f307324f1e78b34472f8b6f46f3> // 이것은 hash1입니다
OP_EQUAL
OP_DUP
OP_ROT
<0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // 이것은 hash0
OP_EQUAL
OP_BOOLOR
OP_VERIFY
// 이제 비트 약속의 값은 "0" 또는 "1"입니다.
Bit Commitment에는 현재 두 가지 구현 방법이 있습니다.
Lamport 일회성 서명: 원리는 비교적 간단하고 해시 함수만 사용하면 되므로 비트코인 친화적입니다. 메시지의 각 비트마다 2개의 해시 값을 커밋해야 하므로 상대적으로 큰 서명 데이터가 생성됩니다. 즉, 길이가 v 비트인 메시지의 경우 공개 키 길이는 2v 비트이고 서명 길이는 v 비트입니다.
Winternitz 일회성 서명: Lamport 서명과 비교하여 서명 및 공개 키의 길이를 크게 줄일 수 있지만 서명 및 확인의 복잡성이 증가합니다. 이 솔루션은 다양한 해시 체인 길이 d 값을 유연하게 설정하여 길이와 복잡성 사이의 절충안을 만들 수 있습니다. 예를 들어 d=15로 설정하면 공개키 길이와 서명 길이는 약 4배 짧아지지만 서명 검증 복잡도는 4배 증가한다. 이는 본질적으로 비트코인 스택 공간과 스크립트 크기 간의 균형입니다. Lamport 시그니처는 d=1일 때 Winternitz 시그니처의 특별한 경우로 간주될 수 있습니다.
현재 BitVM2 라이브러리에서는 Blake3 기반 해시 함수가 Winternitz 서명을 구현합니다. 단일 비트에 해당하는 서명 길이는 약 26바이트입니다. 비트 커밋을 통해 상태를 도입하는 데 드는 비용이 비싸다는 것을 알 수 있습니다. 따라서 BitVM2 프로젝트 구현에서는 메시지의 각 비트에 대해 직접 해시 연산을 수행하는 대신 메시지를 먼저 해시하여 256비트 해시 값을 얻은 다음 해시 값에 대해 비트 커밋을 수행하여 오버헤드를 절약합니다. 원래의 긴 메시지 약속.
2.3 Taproot: 스크립트 공간 제한 극복
2021년 11월부터 활성화된 비트코인 Taproot 소프트 포크 업그레이드에는 Schnorr 서명(BIP 340), Taproot(BIP 341) 및 TapScript(BIP 342)의 3가지 제안이 포함되어 있습니다. 새로운 거래 유형인 Pay-to-Taproot(P2TR) 거래가 도입되었습니다. P2TR 트랜잭션은 Taproot, MAST(Merkle Abstract Syntax Tree) 및 Schnorr 서명의 장점을 결합하여 보다 개인적이고 유연하며 확장 가능한 트랜잭션 형식을 만들 수 있습니다.
P2TR은 키 경로 기반 지출 또는 스크립트 경로 기반 지출이라는 두 가지 지출 방법을 지원합니다.
Taproot(BIP 341) 규정에 따르면 스크립트 경로로 지출 시 해당 Merkle 경로의 최대 길이는 128을 초과할 수 없습니다. 이는 탭트리의 탭리프 수가 2128개를 초과하지 않음을 의미합니다. 2017년 세그윗 업그레이드 이후 비트코인 네트워크는 블록 크기를 무게 단위로 측정하며 최대 지원 범위는 400만 무게 단위(즉, 약 4MB)입니다. P2TR 출력이 스크립트 경로를 통해 소비되는 경우 단일 tapleaf 스크립트만 노출되어야 합니다. 즉, 블록은 단일 tapleaf 스크립트로 패키지됩니다. 이는 P2TR 트랜잭션의 경우 각 탭리프에 해당하는 최대 스크립트 크기가 약 4MB임을 의미합니다. 그러나 비트코인의 기본 전략에서는 많은 노드가 400K보다 작은 트랜잭션만 전달합니다. 더 큰 트랜잭션을 패키징하려면 채굴자와 협력해야 합니다.
Taproot가 제공하는 스크립트 공간 프리미엄으로 인해 기존 opcode를 사용하여 곱셈 및 해싱과 같은 암호화 작업을 시뮬레이션하는 것이 더 가치 있습니다.
P2TR을 기반으로 검증 가능한 계산을 구축할 때 해당 스크립트 크기는 더 이상 4MB로 제한되지 않습니다. 대신 계산을 여러 하위 기능으로 나누어 여러 탭리프에 배포할 수 있으므로 4MB 스크립트 크기 공간 제한을 극복할 수 있습니다. 실제로 현재 BitVM2에 구현된 Groth16 검증자 알고리즘의 크기는 2GB에 달한다. 그러나 약 1000개 정도의 탭리프(tapleaf)로 분할하여 배포할 수 있으며, 비트 커밋과 결합하면 각 하위 기능의 입력과 출력 간의 일관성을 제한하여 전체 계산의 무결성과 정확성을 제한할 수 있습니다.
2.4 커넥터 출력: UTXO 소비 방식의 한계 극복
비트코인은 현재 단일 UTXO에 대한 기본 지출 방법(스크립트별 지출 또는 공개 키별 지출)을 제공합니다. 따라서 해당하는 올바른 공개 키 서명이 제공되거나 스크립트 조건이 충족되는 한 UTXO를 사용할 수 있습니다. 두 개의 UTXO는 독립적으로 사용될 수 있으며 두 개의 UTXO를 제한하기 위해 제한 사항을 추가할 수 없으므로 사용하기 전에 몇 가지 추가 조건을 충족해야 합니다.
그러나 Ark 프로토콜의 창시자인 Burak은 SIGHASH 플래그를 교묘하게 사용하여 커넥터 출력을 구현했습니다. 구체적으로, Alice는 서명을 생성하여 자신의 BTC를 Bob에게 보낼 수 있습니다. 그러나 서명은 여러 입력을 커밋할 수 있으므로 Alice는 자신의 서명을 조건부로 설정할 수 있습니다. 서명은 트랜잭션이 두 번째 입력을 소비하는 경우에만 Take_tx 트랜잭션에 유효합니다. 두 번째 입력은 UTXO A와 UTXO B를 연결하는 커넥터라고 합니다. 즉, Take_tx 트랜잭션은 UTXO B가 Challenge_tx에 의해 사용되지 않은 경우에만 유효합니다. 따라서 커넥터 출력을 삭제하면 Take_tx 트랜잭션이 적용되지 않도록 차단될 수 있습니다.
그림 1: 커넥터 출력 다이어그램
BitVM2 프로토콜에서 커넥터 출력은 if...else 기능으로 작동합니다. 커넥터 출력이 트랜잭션에 의해 소비되면 독점성을 보장하기 위해 다른 트랜잭션에 의해 소비될 수 없습니다. 실제 배포에서는 챌린지 응답 기간을 예약하기 위해 타임록이 포함된 UTXO가 추가로 도입됩니다. 또한 해당 커넥터 출력은 필요에 따라 다양한 지출 전략을 설정할 수도 있습니다. 예를 들어 챌린지 트랜잭션은 누구나 사용할 수 있도록 설정할 수 있지만 응답 트랜잭션은 운영자만 사용할 수 있거나 만료 후 누구나 사용할 수 있도록 설정할 수 있습니다. .
2.5 계약: 사전 서명 제한 돌파
현재 비트코인 스크립트는 주로 잠금 해제 조건을 제한하지만 UTXO를 추가로 사용할 수 있는 방법은 제한하지 않습니다. 그 이유는 비트코인 스크립트가 트랜잭션 자체의 내용을 읽을 수 없기 때문입니다. 즉, 트랜잭션 자체 검사를 구현할 수 없습니다. 비트코인 스크립트가 거래의 모든 내용(출력 포함)을 확인할 수 있다면 계약 기능을 실현할 수 있습니다.
현재 계약 구현 방법은 두 가지 범주로 나눌 수 있습니다.
사전 서명: 기존 비트코인 스크립팅 기능을 기반으로 구축된 사전 서명은 제한된 기능으로 미리 결정된 계약을 구축합니다. 즉, 가능한 미래의 모든 거래는 사전에 설계되고 서명되어 참가자를 특정 개인 키와 요율에 고정시킵니다. 일부 계획에서는 당사자가 모든 사전 서명된 거래에 대해 단기 개인 키를 생성하도록 요구하기도 합니다. 사전 서명이 완료되면 이러한 단기 개인키는 안전하게 삭제되므로 공격자가 단기 개인키를 탈취하거나 자금을 탈취할 수 없습니다. 하지만 새로운 참가자가 추가되거나 운영이 업데이트될 때마다 위의 과정을 반복해야 하므로 유지관리 비용이 많이 든다. 예를 들어 라이트닝 네트워크는 사전 서명을 통해 2자 계약을 구현하고, HTLC(Hash Time Lock) 기술을 사용하여 여러 2자 계약의 라우팅 기능을 구현함으로써 신뢰가 최소화된 확장 전략을 달성합니다. 그러나 라이트닝 네트워크는 여러 트랜잭션의 사전 서명이 필요하며 두 당사자로 제한됩니다. 이는 약간 번거롭습니다. BitVM1에서는 초기화될 때마다 수백 개의 트랜잭션을 사전 서명해야 하지만 최적화된 BitVM2에서는 필요합니다. 초기화될 때마다 사전 서명이 이루어지도록 사전 서명된 거래 수도 수십 건에 이르렀습니다. BitVM1이든 BitVM2이든 사전 서명에 참여한 사업자만 환급을 받을 수 있습니다. 사전 서명에 참여하는 n명의 참가자가 있고 각 참가자가 m개의 트랜잭션을 사전 서명해야 하는 경우 각 참가자의 사전 서명 복잡성은 n * m이 됩니다.
계약 opcode 도입: 새로운 계약 기능 opcode의 도입은 계약 참가자 간의 통신 복잡성과 유지 관리 비용을 크게 줄여 비트코인에 보다 유연한 계약 구현 방법을 도입할 수 있습니다. 예를 들어 OP_CAT: 바이트 문자열을 연결하는 데 사용됩니다. 그 기능은 매우 간단하지만 매우 강력하며 OP_TXHASH의 복잡성을 크게 줄일 수 있습니다. 계약 내 작업을 더 세밀하게 제어할 수 있습니다. BitVM에서 사용하면 더 많은 운영자 세트를 지원할 수 있으므로 BitVM의 보안 가정이 크게 향상되고 신뢰가 최소화됩니다. 또한 사전 서명 방식은 운영자가 선지급 환급 프로세스만 사용할 수 있도록 설계되었으며 새로운 계약 운영 코드로 자금 활용 효율성이 낮으므로 현금화 사용자에게 직접 지불이 가능합니다. 페그인 펀드 풀을 통해 자본 효율성을 더욱 향상시킵니다. 따라서 유연한 계약 모델은 기존의 사전 서명 제한을 효과적으로 극복할 수 있습니다.
3 비트코인 레이어 2 스케일링: 유효성 증명 및 사기 증명
유효성 증명과 사기 증명 모두 비트코인 L2 확장에 사용될 수 있습니다. 두 가지의 주요 차이점은 표 2에 나와 있습니다.
표 2: 유효성 증명 및 사기 증명
비트 약속, 탭루트, 사전 서명 및 커넥터 출력을 기반으로 비트코인 기반 사기 증명을 구축할 수 있습니다. 탭루트를 기반으로 OP_CAT과 같은 계약 운영 코드를 도입하여 비트코인 기반 유효성 인증서를 구축할 수 있습니다. 또한 Bob이 접근 시스템을 보유하고 있는지 여부에 따라 사기 증명은 허가형 사기 증명과 무허가 사기 증명으로 나눌 수 있습니다. 그 중 허가형 사기 증명에서는 특정 그룹만이 Bob으로 도전할 수 있지만, 허가형 사기 증명에서는 모든 제3자가 Bob으로 도전할 수 있습니다. 무허가형 시스템의 보안은 허가형 시스템보다 우수하므로 허가된 각 참가자가 악행에 가담할 리스크 줄일 수 있습니다.
Alice와 Bob 사이의 시도 응답 상호 작용 수에 따라 사기 증명은 그림 2와 같이 한 라운드의 사기 증명과 여러 라운드의 사기 증명으로 나눌 수 있습니다.
그림 2: 한 번의 사기 증명과 여러 번의 사기 증명
표 3에서 볼 수 있듯이 사기 방지는 일회성 상호작용 모델과 다단계 상호작용 모델을 포함한 다양한 상호작용 모델을 통해 달성될 수 있습니다.
표 3: 일회성 상호 작용 및 여러 라운드의 상호 작용
비트코인 레이어 2 확장 패러다임에서 BitVM1은 다중 사기 방지 메커니즘을 채택하고 BitVM2는 1라운드 사기 방지 메커니즘을 채택하며 bitcoincircle stark는 유효성 증명을 채택합니다. 그중 BitVM1과 BitVM2는 비트코인 프로토콜을 수정하지 않고도 구현할 수 있는 반면, 비트코인 서클 스타크는 새로운 opcode OP_CAT의 도입이 필요합니다.
대부분의 컴퓨팅 작업의 경우 비트코인 시그넷, 테스트넷 및 메인넷은 4MB 스크립트로 완전히 표현할 수 없습니다. 스크립트 분할 기술을 사용해야 합니다. 즉, 전체 계산을 표현하는 스크립트를 4MB보다 작은 덩어리로 나누어 각 탭리프에 배포합니다. .
3.1 비트코인에 대한 여러 차례의 사기 증명
표 3에서 볼 수 있듯이 다중 라운드 사기 증명은 온체인 중재 계산의 양을 줄이고 싶거나 문제가 있는 계산 조각을 한 단계로 찾는 것이 불가능한 시나리오에 적합합니다. 다중 라운드 사기 증명은 이름에서 알 수 있듯이 문제가 있는 계산 조각을 찾은 다음 찾은 계산 조각을 기반으로 중재를 수행하기 위해 증명자와 검증자 간의 여러 라운드 상호 작용이 필요합니다.
Robin Linus의 초기 BitVM 백서(BitVM1이라고도 함)에서는 여러 단계의 사기 증명을 사용했습니다. 각 라운드의 챌린지 기간이 1주일이고 바이너리 검색 방법을 사용하여 문제 계산 조각을 찾는다고 가정하면 Groth16 Verifier의 온체인 챌린지 응답 기간은 최대 30주에 달해 적시성이 매우 낮습니다. 현재 바이너리 방법보다 더 효율적인 n항 검색 방법을 개발하는 팀이 있지만, 사기 증명 라운드의 2주 주기에 비해 적시성은 여전히 훨씬 낮습니다.
현재 비트코인 패러다임에 따른 여러 라운드의 사기 증명은 모두 허가형 챌린지를 사용하는 반면, 한 라운드의 사기 증명은 참가자 간의 공모 리스크 줄이고 더 높은 보안을 제공하는 무허가형 챌린지 방법을 구현합니다. 이를 위해 Robin Linus는 taproot를 최대한 활용하여 BitVM1을 최적화했습니다. 상호 작용 라운드 수를 1회로 줄일 뿐만 아니라 챌린지 방법을 무허가형으로 확장하지만 대신 온체인 중재 계산량을 늘리는 대가를 치르게 됩니다.
3.2 비트코인에 대한 사기 증명 라운드
검증 부정 증명은 증명자와 검증자 간의 단 한 번의 상호 작용만으로 완료될 수 있습니다. 이 모델에서 검증자는 한 번만 챌린지를 시작하면 되고 증명자는 한 번만 응답하면 됩니다. 이 응답에서 증명자는 계산이 정확하다고 주장하는 증거를 제공해야 합니다. 검증자가 이 증거에서 불일치를 찾을 수 있으면 챌린지는 성공하고, 그렇지 않으면 챌린지는 실패합니다. 한 라운드의 대화형 사기 증명의 특징은 표 3에 나와 있습니다.
그림 3: 사기 증명 1차
Robin Linus는 사기 증명을 통해 BitVM2 크로스 체인 브리지를 구현하기 위해 그림 3과 유사한 방법을 사용하여 2024년 8월 15일에 BitVM2: 비트코인을 두 번째 레이어에 연결 기술 백서 발표했습니다.
3.3 비트코인+OP_CAT는 유효성 증명을 구현합니다.
OP_CAT은 비트코인이 처음 출시되었을 때 스크립팅 언어의 일부였으며 보안 취약점으로 인해 2010년에 비활성화되었습니다. 그러나 비트코인 커뮤니티는 수년 동안 활성화에 대해 논의해 왔습니다. 현재 OP_CAT에는 번호 347이 할당되어 있으며 비트코인 시그넷에서 활성화되어 있습니다.
OP_CAT의 주요 기능은 스택의 두 요소를 결합하고 결합된 결과를 다시 스택에 푸시하는 것입니다. 이 기능을 사용하면 비트코인에서 계약 및 STARK 검증이 가능합니다.
계약: Andrew Poelstra는 비트코인 계약을 구현하기 위해 OP_CAT 및 Schnorr 기술을 사용하는 CAT 및 Schnorr Tricks I을 제안했습니다. 그중 Schnorr 알고리즘은 P2TR 출력 유형의 디지털 서명입니다. 다른 출력 유형의 경우 유사한 ECDSA 기술을 사용할 수 있습니다. CAT 및 ECDSA에 대한 규약을 참조하세요. OP_CAT 계약의 도움으로 STARK Verifier 알고리즘을 여러 트랜잭션으로 분할하고 전체 STARK 증명을 점진적으로 검증하는 데 도움이 될 수 있습니다.
STARK 검증기: STARK 검증기는 기본적으로 데이터를 결합하고 해시합니다. 대수 연산과 달리 해싱은 대량 오버헤드를 절약하는 기본 Bitcoin 스크립트 연산입니다. OP_SHA256을 예로 들면 기본 모드에는 하나의 opcode만 필요한 반면, 시뮬레이션 모드에는 수백 K개의 opcode가 필요합니다. STARK의 주요 해시 작업은 Merkle 경로 확인과 Fiat-Shamir 변환입니다. 따라서 OP_CAT은 STARK Verifier 알고리즘에 매우 친숙합니다.
3.4 비트코인 스크립트 분할 기술
비록 SNARK/STARK에 의해 증명된 후, 증명을 검증하기 위해 해당 검증자 알고리즘을 실행하는 데 필요한 계산량이 원래 계산 f를 직접 실행하는 데 필요한 계산량보다 훨씬 적습니다. 그러나 이를 비트코인 스크립트에서 검증 알고리즘을 구현하는 것으로 변환할 때 필요한 스크립팅 양은 여전히 엄청납니다. 현재 기존 비트코인 opcode를 기반으로 최적화 후 실현된 Groth16 검증자 스크립트 크기와 Fflonk 검증자 스크립트 크기는 여전히 2GB보다 큽니다. 그러나 단일 비트코인 블록의 크기는 4MB에 불과하며 단일 블록에서 전체 검증 스크립트를 실행하는 것은 불가능합니다. 그러나 탭루트 업그레이드 이후 비트코인은 탭리프에 의한 스크립트 실행을 지원합니다. 검증자 스크립트는 여러 청크로 나눌 수 있으며, 각 청크는 탭트리를 구축하는 데 사용됩니다. 각 청크 사이에는 청크 간 값의 일관성을 보장하기 위해 비트 약속이 사용됩니다.
OP_CAT 계약을 통해 STARK 검증자는 400KB 미만의 여러 표준 트랜잭션으로 분할될 수 있으므로 채굴자와 협력할 필요 없이 전체 STARK 유효성 인증서의 검증을 완료할 수 있습니다.
이 섹션에서는 기존 상황을 활성화하기 위해 새로운 opcode를 도입하지 않고 Bitcoin 스크립트의 관련 Split 기술에 중점을 둡니다.
스크립트를 분할할 때 다음 차원 정보의 균형을 맞춰야 합니다.
단일 청크 스크립트의 크기는 4MB를 초과하지 않으며 입력 비트 커밋 스크립트, 트랜잭션 서명 등을 위한 공간을 포함해야 합니다.
단일 청크 스택의 최대 크기는 1,000을 초과하지 않습니다. 따라서 필요한 요소만 각 청크 스택에 유지되어야 하며, 이를 통해 스크립트 크기 최적화를 제공할 수 있는 충분한 스택 공간을 확보해야 합니다. 비트코인 거래 수수료는 사용된 스택 크기에 따라 달라지지 않기 때문입니다.
비트코인의 비트 약속은 비용이 많이 듭니다. 따라서 현재 1비트는 26바이트에 해당하며, 인접한 두 청크 사이의 입출력 비트 수는 최소화되어야 합니다.
감사 용이하게 하려면 각 청크의 기능이 최대한 명확해야 합니다.
현재 스크립트 분할 방법은 주로 다음 세 가지 범주로 나뉩니다.
자동 분할: 스택 크기와 스크립트 크기를 기준으로 약 3MB의 스크립트 크기와 최소 스택 크기로 분할 방법을 찾습니다. 이 접근 방식의 장점은 특정 검증자 알고리즘과 아무 관련이 없으며 계산된 스크립트 분할로 확장될 수 있다는 것입니다. 단점은 다음과 같습니다. (1) 전체 로직을 별도로 태그 해야 합니다. 예를 들어 OP_IF 코드 블록을 분할할 수 없습니다. 그렇지 않으면 분할 스크립트 실행 결과가 올바르지 않습니다. (2) 청크 실행 결과가 여러 개에 해당할 수 있습니다. 실제 계산 논리를 기반으로 비트 커밋을 적용해야 하는 스택 요소 수를 태그 해야 하는 스택 요소 (3) 각 청크 스크립트에 의해 구현된 논리 기능은 읽기가 어렵고 감사 에 도움이 되지 않습니다. ) 스택에는 다음 청크에서 사용되지 않는 요소가 포함되어 스택 공간이 낭비될 수 있습니다.
기능 분할: 계산에서 각 기능 하위 기능에 따라 분할됩니다. 스크립트가 분할되는 동안 각 청크에 필요한 비트 커밋 스크립트도 구현됩니다. 최종 청크 총 스크립트는 크기가 4MB 미만이고 스택 크기가 1000 미만입니다. 장점은 명확한 기능, 단일 청크의 명확한 논리, 우수한 가독성 및 쉬운 감사 입니다. 단점은 원래 계산 논리의 표현이 스크립트 수준 논리의 표현과 일치하지 않는다는 것입니다. 원래 계산 하위 함수가 최적일 수 있지만 이것이 스크립트 수준에서 최적이라는 의미는 아닙니다.
수동 분할: 스크립트 분할 지점은 기능적 하위 기능에 있지 않고 수동으로 설정됩니다. 단일 하위 기능의 크기가 4MB보다 큰 상황에 특히 적합합니다. 장점은 Fq12 관련 계산 하위 기능과 같은 무거운 스크립트 크기 하위 기능을 수동으로 나눌 수 있다는 것입니다. 단일 청크는 명확한 논리, 좋은 가독성을 가지며 감사 하기 쉽습니다. 단점은 수동 조정 기능에 의해 제한되며 전체 스크립트가 최적화될 때 이전에 설정된 수동 분할 지점이 최적이 아닐 수 있으며 다시 조정해야 한다는 것입니다.
예를 들어, 여러 차례의 최적화 후에 Groth16 검증자는 스크립트 크기를 약 7GB에서 약 1.26GB로 줄였습니다. 이러한 전반적인 계산 최적화 외에도 각 청크를 개별적으로 최적화하여 스택 공간을 최대한 활용할 수도 있습니다. 예를 들어, 조회 테이블을 기반으로 더 나은 알고리즘을 도입하고 조회 테이블을 동적으로 로드 및 언로드함으로써 각 청크의 스크립트 크기를 더욱 줄일 수 있습니다.
web2 프로그래밍 언어의 컴퓨팅 비용 및 실행 환경은 비트코인 스크립트의 비용 및 실행 환경과 완전히 다르기 때문에 다양한 알고리즘의 비트코인 스크립트 구현의 경우 단순히 기존 구현을 번역하는 것만으로는 작동하지 않습니다. 따라서 비트코인 시나리오에서는 다음과 같은 최적화를 고려해야 합니다.
계산의 일부가 희생되더라도 최적의 메모리 위치를 갖는 알고리즘을 찾으면 청크 간의 입력 및 출력 비트 수를 줄일 수 있으므로 BitVM2 설계에서 AssertTx 거래소 에 커밋되는 데이터 양을 줄일 수 있습니다.
관련 연산(예: 논리 연산)의 교환성을 활용하여 x&y = y&x로 조회 테이블의 거의 절반을 절약합니다.
현재 Fq12 작업에 해당하는 스크립트의 양이 많습니다. Fq12 확장 도메인 작업의 계산 복잡성을 크게 줄이기 위해 Fiat-Shamir, Schwartz-Zipple 및 다항식 커밋 방식을 사용하는 것이 좋습니다.
4 요약
이 기사에서는 먼저 비트코인 스크립트의 한계를 소개하고 비트코인을 사용하여 UTXO 상태 비저장 제한을 극복하는 방법, Taproot를 사용하여 스크립트 공간 제한을 극복하는 방법, 커넥터 출력을 사용하여 UTXO 지출 방법 제한을 극복하는 방법, 사전 서명 제한을 극복하기 위해 계약을 사용합니다. 이어서 사기증명과 유효성증명의 특징, 허가형 사기증명과 무허가형 사기증명의 특징, 1회 사기증명과 다회 사기증명의 특징, 비트코인 스크립트 분할 기술 등을 종합적으로 정리하여 정리하였다.
