저자: mutourend & lynndel, Bitlayer Labs

원제: "비트코인 Layer2 확장 기술 분석: 유효성 증명 및 사기 증명"

원본 링크: https://blog.bitlayer.org/Analytic_of_Bitcoin_Layer2_Scaling_Techniques_Validity_Proofs_and_Fraud_Proofs/

특정 알고리즘 f에 대해 서로 신뢰하지 않는 두 참가자 Alice와 Bob은 다음과 같은 방법으로 신뢰를 구축할 수 있습니다.

위의 2,3,4에 대해 x는 Layer2 트랜잭션 및 시작 상태, f는 Layer2 합의 프로그램, y는 블록체인 Layer2 확장 계획에 해당하는 트랜잭션 종료 상태라고 합니다. 안에:

위의 2,3,4에 대해 x는 Layer2 트랜잭션 및 시작 상태, f는 Layer2 합의 프로그램, y는 블록체인 Layer2 확장 계획에 해당하는 트랜잭션 종료 상태라고 합니다. 안에:

표 1: 신뢰를 구축하는 방법

또한 다음 사항에 유의하세요.

현재 견고성 Turing-complete 스마트 계약의 이점을 활용하여 사기 증명 및 유효성 증명 기술이 Ethereum Layer 2 확장에 널리 사용됩니다. 그러나 비트코인 ​​패러다임 하에서 이러한 기술적 응용은 비트코인의 제한된 opcode 기능 및 1,000개의 스택 요소와 같은 제한으로 인해 여전히 탐색 단계에 있습니다. 비트코인 레이어 2 확장 시나리오를 고려하여 이 글에서는 비트코인 ​​패러다임 하의 한계와 획기적인 기술을 요약하고, 유효성 증명 및 사기 방지 기술을 연구하며, 비트코인 ​​패러다임 하의 고유한 스크립트 분할 기술을 정리합니다.

비트코인 패러다임에는 많은 제한 사항이 있지만 이러한 제한 사항을 극복하기 위해 다양하고 영리한 방법이나 기술을 사용할 수 있습니다. 예를 들어, 비트 커밋은 UTXO 상태 비저장 제한을 초과할 수 있고, taproot는 스크립트 공간 제한을 초과할 수 있으며, 커넥터 출력은 UTXO 지출 방법 제한을 초과할 수 있으며, 계약은 사전 서명 제한을 초과할 수 있습니다.

비트코인은 UTXO 모델을 채택하고 각 UTXO는 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에는 현재 두 가지 구현 방법이 있습니다.

현재 BitVM2 라이브러리에서는 Blake3 기반 해시 함수가 Winternitz 서명을 구현합니다. 단일 비트에 해당하는 서명 길이는 약 26바이트입니다. 비트 커밋을 통해 상태를 도입하는 데 드는 비용이 비싸다는 것을 알 수 있습니다. 따라서 BitVM2 프로젝트 구현에서는 메시지의 각 비트에 대해 직접 해시 연산을 수행하는 대신 메시지를 먼저 해시하여 256비트 해시 값을 얻은 다음 해시 값에 대해 비트 커밋을 수행하여 오버헤드를 절약합니다. 원래의 긴 메시지 약속.

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)로 분할하여 배포할 수 있으며, 비트 커밋과 결합하면 각 하위 기능의 입력과 출력 간의 일관성을 제한하여 전체 계산의 무결성과 정확성을 제한할 수 있습니다.

비트코인은 현재 단일 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가 추가로 도입됩니다. 또한 해당 커넥터 출력은 필요에 따라 다양한 지출 전략을 설정할 수도 있습니다. 예를 들어 챌린지 트랜잭션은 누구나 사용할 수 있도록 설정할 수 있지만 응답 트랜잭션은 운영자만 사용할 수 있거나 만료 후 누구나 사용할 수 있도록 설정할 수 있습니다. .

현재 비트코인 ​​스크립트는 주로 잠금 해제 조건을 제한하지만 UTXO를 추가로 사용할 수 있는 방법은 제한하지 않습니다. 그 이유는 비트코인 ​​스크립트가 트랜잭션 자체의 내용을 읽을 수 없기 때문입니다. 즉, 트랜잭션 자체 검사를 구현할 수 없습니다. 비트코인 스크립트가 거래의 모든 내용(출력 포함)을 확인할 수 있다면 계약 기능을 실현할 수 있습니다.

현재 계약 이행 방법은 두 가지 범주로 나눌 수 있습니다.

유효성 증명과 사기 증명 모두 비트코인 ​​L2 확장에 사용될 수 있습니다. 둘 사이의 주요 차이점은 표 2에 나와 있습니다.

유효성 증명과 사기 증명 모두 비트코인 ​​L2 확장에 사용될 수 있습니다. 두 가지의 주요 차이점은 표 2에 나와 있습니다.

표 2: 유효성 증명 및 사기 증명

비트 약속, 탭루트, 사전 서명 및 커넥터 출력을 기반으로 비트코인 ​​기반 사기 증명을 구축할 수 있습니다. 탭루트를 기반으로 OP_CAT과 같은 계약 운영 코드를 도입하여 비트코인 ​​기반 유효성 인증서를 구축할 수 있습니다. 또한 Bob이 접근 시스템을 보유하고 있는지 여부에 따라 사기 증명은 허가형 사기 증명과 무허가 사기 증명으로 나눌 수 있습니다. 그 중 허가형 사기 증명에서는 특정 그룹만이 Bob으로 도전할 수 있지만, 허가형 사기 증명에서는 모든 제3자가 Bob으로 도전할 수 있습니다. 무허가형 시스템의 보안은 허가형 시스템보다 우수하므로 허가된 각 참가자가 악의적인 행위를 저지르는 위험을 줄일 수 있습니다.

Alice와 Bob 사이의 시도 응답 상호 작용 수에 따라 사기 증명은 그림 2와 같이 한 라운드의 사기 증명과 여러 라운드의 사기 증명으로 나눌 수 있습니다.

표 3에서 볼 수 있듯이 사기 방지는 일회성 상호작용 모델과 다단계 상호작용 모델을 포함한 다양한 상호작용 모델을 통해 달성될 수 있습니다.

비트코인 레이어 2 확장 패러다임에서 BitVM1은 다중 사기 방지 메커니즘을 사용하고 BitVM2는 1라운드 사기 방지 메커니즘을 사용하며 bitcoincircle stark는 유효성 증명을 사용합니다. 그중 BitVM1과 BitVM2는 비트코인 ​​프로토콜을 수정하지 않고도 구현할 수 있는 반면, 비트코인 ​​서클 스타크는 새로운 opcode OP_CAT의 도입이 필요합니다.

대부분의 컴퓨팅 작업의 경우 비트코인 ​​시그넷, 테스트넷 및 메인넷은 4MB 스크립트로 완전히 표현할 수 없습니다. 스크립트 분할 기술을 사용해야 합니다. 즉, 전체 계산을 표현하는 스크립트를 4MB보다 작은 덩어리로 나누어 각 탭리프에 배포합니다. .

표 3에서 볼 수 있듯이 다중 라운드 사기 증명은 온체인 중재 계산의 양을 줄이고 싶거나 문제가 있는 계산 조각을 한 단계로 찾는 것이 불가능한 시나리오에 적합합니다. 다중 라운드 사기 증명은 이름에서 알 수 있듯이 문제가 있는 계산 조각을 찾은 다음 찾은 계산 조각을 기반으로 중재를 수행하기 위해 증명자와 검증자 간의 여러 라운드 상호 작용이 필요합니다.

표 3에서 볼 수 있듯이 다중 라운드 사기 증명은 온체인 중재 계산의 양을 줄이고 싶거나 문제가 있는 계산 조각을 한 단계로 찾는 것이 불가능한 시나리오에 적합합니다. 다중 라운드 사기 증명은 이름에서 알 수 있듯이 문제가 있는 계산 조각을 찾은 다음 찾은 계산 조각을 기반으로 중재를 수행하기 위해 증명자와 검증자 간의 여러 라운드 상호 작용이 필요합니다.

Robin Linus의 초기 BitVM 백서(BitVM1이라고도 함)에서는 여러 단계의 사기 증명을 사용했습니다. 각 라운드의 챌린지 기간이 1주일이고 바이너리 검색 방법을 사용하여 문제 계산 조각을 찾는다고 가정하면 Groth16 Verifier의 온체인 챌린지 응답 기간은 최대 30주에 달해 적시성이 매우 낮습니다. 현재 바이너리 방법보다 더 효율적인 n항 검색 방법을 개발하는 팀이 있지만 , 사기 증명 라운드의 2주 주기보다 적시성은 여전히 ​​훨씬 낮습니다.

현재 비트코인 ​​패러다임에 따른 여러 라운드의 사기 증명은 모두 허가형 챌린지를 사용하는 반면, 한 라운드의 사기 증명은 참가자 간의 공모 위험을 줄이고 더 높은 보안을 제공하는 무허가형 챌린지 방법을 구현합니다. 이를 위해 Robin Linus는 taproot를 최대한 활용하여 BitVM1을 최적화했습니다. 상호 작용 라운드 수를 1회로 줄일 뿐만 아니라 챌린지 방법을 무허가형으로 확장하지만 대신 온체인 중재 계산량을 늘리는 대가를 치르게 됩니다.

검증 부정 증명은 증명자와 검증자 간의 단 한 번의 상호 작용만으로 완료될 수 있습니다. 이 모델에서 검증자는 한 번만 챌린지를 시작하면 되고 증명자는 한 번만 응답하면 됩니다. 이 응답에서 증명자는 계산이 정확하다고 주장하는 증거를 제공해야 합니다. 검증자가 이 증거에서 불일치를 찾을 수 있으면 챌린지는 성공하고, 그렇지 않으면 챌린지는 실패합니다. 한 라운드의 대화형 사기 증명의 특징은 표 3에 나와 있습니다.

Robin Linus는 사기 증명을 통해 BitVM2 크로스 체인 브리지를 구현하기 위해 그림 3과 유사한 방법을 사용하여 2024년 8월 15일에 BitVM2: 비트코인을 두 번째 레이어에 연결 기술 백서를 발표했습니다.

OP_CAT은 비트코인이 처음 출시되었을 때 스크립팅 언어의 일부였으며 보안 취약점으로 인해 2010년에 비활성화되었습니다. 그러나 비트코인 ​​커뮤니티는 수년 동안 활성화에 대해 논의해 왔습니다. 현재 OP_CAT에는 번호 347이 할당되어 있으며 비트코인 ​​시그넷에서 활성화되어 있습니다.

OP_CAT의 주요 기능은 스택의 두 요소를 결합하고 결합된 결과를 다시 스택에 푸시하는 것입니다. 이 기능을 사용하면 비트코인에서 계약 및 STARK 검증이 가능합니다.

비록 SNARK/STARK에 의해 증명된 후, 증명을 검증하기 위해 해당 검증자 알고리즘을 실행하는 데 필요한 계산량이 원래 계산 f를 직접 실행하는 데 필요한 계산량보다 훨씬 적습니다. 그러나 이를 비트코인 ​​스크립트에서 검증 알고리즘을 구현하는 것으로 변환할 때 필요한 스크립팅 양은 여전히 ​​엄청납니다. 현재 기존 비트코인 ​​opcode를 기반으로 최적화 후 실현된 Groth16 검증자 스크립트 크기와 Fflonk 검증자 스크립트 크기는 여전히 2GB보다 큽니다. 그러나 단일 비트코인 ​​블록의 크기는 4MB에 불과하며 단일 블록에서 전체 검증 스크립트를 실행하는 것은 불가능합니다. 그러나 탭루트 업그레이드 이후 비트코인은 탭리프에 의한 스크립트 실행을 지원합니다. 검증자 스크립트는 여러 청크로 나눌 수 있으며, 각 청크는 탭트리를 구축하는 데 사용됩니다. 각 청크 사이에는 청크 간 값의 일관성을 보장하기 위해 비트 약속이 사용됩니다.

OP_CAT 계약을 통해 STARK 검증자는 400KB 미만의 여러 표준 트랜잭션으로 분할될 수 있으므로 채굴자와 협력할 필요 없이 전체 STARK 유효성 인증서에 대한 검증을 완료할 수 있습니다.

이 섹션에서는 기존 상황을 활성화하기 위해 새로운 opcode를 도입하지 않고 Bitcoin 스크립트에 대한 관련 Split 기술에 중점을 둡니다.

스크립트를 분할할 때 다음 차원 정보의 균형을 맞춰야 합니다.

현재 스크립트 분할 방법은 주로 다음 세 가지 범주로 나뉩니다.

현재 스크립트 분할 방법은 주로 다음 세 가지 범주로 나뉩니다.

예를 들어, 여러 차례의 최적화 후에 Groth16 검증자는 스크립트 크기를 약 7GB에서 약 1.26GB로 줄였습니다. 이러한 전반적인 계산 최적화 외에도 각 청크를 개별적으로 최적화하여 스택 공간을 최대한 활용할 수도 있습니다. 예를 들어 , 조회 테이블을 기반으로 더 나은 알고리즘을 도입하고 조회 테이블을 동적으로 로드 및 언로드함으로써 각 청크의 스크립트 크기를 더욱 줄일 수 있습니다.

web2 프로그래밍 언어의 컴퓨팅 비용 및 실행 환경은 비트코인 ​​스크립트의 비용 및 실행 환경과 완전히 다르기 때문에 다양한 알고리즘의 비트코인 ​​스크립트 구현의 경우 단순히 기존 구현을 번역하는 것만으로는 작동하지 않습니다. 따라서 비트코인 ​​시나리오에서는 다음과 같은 최적화를 고려해야 합니다.

이 기사에서는 먼저 비트코인 ​​스크립트의 한계를 소개하고 비트코인을 사용하여 UTXO 상태 비저장 제한을 극복하는 방법, Taproot를 사용하여 스크립트 공간 제한을 극복하는 방법, 커넥터 출력을 사용하여 UTXO 지출 방법 제한을 극복하는 방법, 사전 서명 제한을 극복하기 위해 계약을 사용합니다. 이어서 사기증명과 유효성증명의 특징, 허가형 사기증명과 무허가형 사기증명의 특징, 1회 사기증명과 다회 사기증명의 특징, 비트코인 ​​스크립트 분할 기술 등을 종합적으로 정리하여 정리하였다.