본문으로 건너뛰기
buybitcoinsmart

용어집 / 채굴과 합의

블록 sigop 한도

블록 sigop 한도란 무엇입니까?
블록 sigop 한도는 모든 비트코인 블록의 서명 연산 비용을 80,000단위로 제한하는데, 이는 4,000,000 가중치 단위의 크기 예산과 별도로 계산되는 검증 예산입니다.

BIP-141에 명시되어 있습니다.

서명 검증에는 노드의 시간이 들기 때문에, 합의 규칙은 그 작업을 블록 공간에 부과하지 않고 별도의 예산으로 계량합니다. BIP141은 계량기를 80,000단위로 정하고 레거시 서명 연산마다 4단위를 매겼으며, 이는 이전 상한인 20,000을 4배로 늘린 것입니다. 일반적인 단일 키 또는 Taproot 출금은 몇 단위만 쓰기 때문에, 코인을 옮기는 거의 모든 사람에게 이 상한은 보이지 않습니다.

작동 방식

블록 sigop 한도는 누적 합계로, 노드가 블록을 연결할 때 트랜잭션마다 더해지며, 합계가 80,000을 넘는 블록은 무효입니다.

이를 산출하기 위해 실행되는 것은 없습니다. 노드는 스크립트 바이트를 스캔해 오피코드를 집계하므로, 해당 지출이 절대 실행하지 않는 분기에 있는 서명 검증도 전액 부과됩니다. 이런 비관적 태도는 의도된 것입니다. 노드는 무엇이든 검증하기 전에 그 블록을 감당할 수 있는지 알아야 합니다.

세 가지 집계가 합산되는데, 모두 같은 트랜잭션에 귀속되지는 않습니다. 레거시 집계는 트랜잭션 자체의 입력 스크립트와 자체 출력 스크립트를 읽어 4를 곱하므로, scriptPubKey에 기록된 연산은 나중에 그것을 지출하는 사람이 아니라 그 출력을 만드는 사람에게 청구됩니다. pay to script hash 집계는 지출하는 입력이 드러내는 redeem script를 읽으며, 역시 4를 곱합니다. 위트니스 집계는 액면 그대로 셉니다. P2WPKH 입력에는 1단위이고, P2WSH 스크립트는 P2SH 아래에서 부과되었을 것과 정확히 똑같이 부과됩니다.

이 스캔들 사이의 한 가지 차이는 실제 비용을 발생시킵니다. P2SH 및 위트니스 집계는 BIP141의 할인을 적용하는데, OP_1부터 OP_16까지가 앞에 오는 OP_CHECKMULTISIG는 고정된 20이 아니라 1에서 16으로 계산됩니다. 레거시 스캔은 이 할인을 절대 적용하지 않습니다. 베어 2 of 3 멀티시그 출력 하나는 20개 연산 전체, 즉 80단위의 예산으로 부과되며, 생성 시점에 부과됩니다.

Tapscript는 예산에서 완전히 빠졌습니다. BIP342는 tapscript 서명 연산을 블록 전체의 80,000에서 빼내고 각 스크립트에 자체 허용량을 주었습니다: 50단위에 해당 입력 위트니스의 직렬화 크기를 더하고, 실제 서명이 첨부된 상태로 서명 오피코드가 실행될 때마다 50씩 줄어듭니다. 50은 400만 가중치를 8만 sigop으로 나눈 값으로, 두 상한 사이의 비율입니다.

이 한도를 보는 곳

릴레이 정책은 합의 규칙보다 훨씬 먼저 블록 sigop 한도에 부딪히며, 이는 네트워크 규칙보다 더 엄격한 세 가지 Bitcoin Core 상수를 통해서입니다.

트랜잭션 하나는 블록 예산의 5분의 1인 16,000단위를 넘게 청구할 수 없습니다. 표준 pay to script hash 입력은 최대 15개의 서명 연산을 담은 redeem script를 드러낼 수 있습니다. 세 번째 집계는 위트니스가 아닌 연산을 실제로 실행될 수 있는 위치에서 읽고, 단순히 위치한 곳에서 읽지 않으며, 트랜잭션당 2,500을 넘으면 릴레이를 막습니다. 이 집계는 지출되는 scriptPubKey를 읽는데, 이는 블록 전체 집계가 생성 시점에 이미 부과한 것입니다.

이 한도는 수수료에도 영향을 줍니다. Bitcoin Core의 bytespersigop 설정은 기본값이 20이며, 트랜잭션의 가중치를 실제 가중치와 sigop 비용에 20을 곱한 값 중 더 큰 값으로 대체합니다. 따라서 크기에 비해 서명 연산이 많은 트랜잭션은 실제보다 큰 것으로 가격이 매겨집니다. 베어 멀티시그 출력을 만드는 것이 이에 걸리는 흔한 방법입니다.

채굴업자는 가중치와 함께 두 번째 제약으로 이 예산을 만나며, BIP342는 이것을 tapscript를 빼낸 이유로 제시합니다: 상한이 둘이면 블록 구성이 하나일 때보다 어렵습니다. Core는 템플릿을 채우기 전에 코인베이스 출력을 위해 400단위를 예약합니다.

블록 sigop 한도 vs 블록 가중치

블록 가중치는 데이터를 세고 블록 시곱 한도는 검증 작업을 세며, 블록은 둘 중 하나의 상한에 도달하는 순간 가득 찹니다. 일반적인 블록이 먼저 부딪히는 상한은 가중치입니다. P2WPKH 입력은 1단위이고 Taproot 지출은 전혀 더하지 않기 때문입니다. 따라서 sigop 예산은 구식 스크립트로 가득 찬 블록에서만 결과를 결정합니다. 한 상한을 다른 상한으로 나누면 서명 연산당 50 가중치 단위가 나오는데, 이는 BIP342가 tapscript 예산의 가격을 매길 때 재사용한 비율이며, 프로토콜이 바이트와 서명 검증 사이의 환율에 가장 가까이 가진 것입니다.

혼동하기 쉬운 용어

자주 묻는 질문

블록 sigop 한도가 80,000인 이유는 무엇입니까?

BIP141이 이전 규칙을 대체하지 않고 다시 조정했기 때문입니다. SegWit 이전의 상한은 블록당 20,000개의 서명 연산이었고, BIP141은 집계와 상한을 모두 4배로 늘렸습니다. 이로써 레거시 스크립트로 이루어진 블록은 이전과 정확히 같은 제약을 받게 되며, 이는 이 변경이 소프트 포크로 배포될 수 있었던 이유의 일부입니다.

Taproot 지출은 블록 sigop 한도에 포함됩니까?

아닙니다. BIP342는 tapscript 서명 연산을 블록 전체의 80,000에서 빼내고 대신 각 스크립트에 자체 예산을 주었습니다: 50에 해당 입력 위트니스의 직렬화 크기를 더하고, 비어 있지 않은 서명과 함께 서명 오피코드가 실행될 때마다 50씩 줄어듭니다.

블록 sigop 한도가 제가 비트코인을 옮기는 데 내는 비용에 영향을 줄 수 있습니까?

트랜잭션이 크기에 비해 서명이 유난히 많은 경우에만 해당하며, 대부분의 사람에게는 이는 베어 멀티시그 출력을 지출하는 것이 아니라 그러한 출력을 생성하는 것을 뜻합니다. Bitcoin Core의 20인 bytespersigop 값은 트랜잭션의 실제 가중치와 sigop 비용에 20을 곱한 값 중 더 큰 값으로 트랜잭션 가격을 매기므로, 일반적인 단일 키 지출이나 Taproot 지출은 영향을 받지 않습니다.

오래된 멀티시그 출력을 지출하면 블록 sigop 예산을 소모합니까?

출력이 스크립트 해시로 감싸져 있었던 경우에만 해당합니다. pay-to-script-hash redeem script나 P2WSH 위트니스 스크립트 안의 서명 연산은 해당 연산을 지출하는 트랜잭션에 부과되는 반면, 베어 멀티시그 scriptPubKey에 직접 있는 서명 연산은 이미 해당 출력을 생성한 트랜잭션에 부과되었으므로 그 출력을 지출하는 데는 아무것도 추가되지 않습니다.

다음에 읽을 글

관련 용어

채굴과 합의 분야의 다른 용어

이 페이지를 영어로 읽기