용어집 / 프로토콜과 업그레이드
일괄 검증
- 일괄 검증이란 무엇입니까?
- 일괄 검증은 여러 개의 Schnorr 서명을 하나씩 검사하는 대신 단일 타원 곡선 방정식으로 검사하여 전체 집합에 대해 성공 또는 실패 하나의 결과를 반환합니다.
BIP-340에 명시되어 있습니다.
검증자는 u개의 서명을 묶고, 첫 번째를 제외한 모든 서명에 무작위 스칼라를 가중치로 적용한 뒤, u개의 방정식 대신 하나의 방정식으로 그 묶음을 처리합니다. BIP-340은 이를 위해 만들어졌으며 서명 크기를 64바이트로 고정했는데, 표준화된 ECDSA는 추가 증인 데이터를 넣지 않는 한 일괄 처리할 수 없습니다. 일괄 처리는 각 검증자가 선택하는 사항이므로, 노드가 이력을 검사하는 속도만 바뀔 뿐 보유한 코인에는 아무런 영향이 없습니다.
작동 방식
일괄 검증은 BIP-340에서 BatchVerify로 규정되며, u개의 32바이트 공개 키, u개의 메시지, u개의 64바이트 서명을 받아 이들 전체에 대해 한 번에 답합니다.
가중치가 먼저 옵니다. 검증자는 곡선의 위수인 n에 대해 1부터 n-1까지의 범위에서 u-1개의 정수를 생성하며, 이는 묶음에 포함된 모든 입력, 즉 키와 메시지와 서명 모두의 해시로 시드를 만든 생성기에서 결정론적으로 얻습니다. BIP-340은 SHA256을 안전한 시드 해시로, ChaCha20을 이를 256비트 정수로 늘리는 안전한 방법으로 규정하며, 범위를 벗어나는 정수는 건너뜁니다.
그다음 묶음은 하나의 검사로 축약됩니다. s 값들의 가중 합에 생성기 점을 곱한 값이, R 점들과 각 서명의 챌린지에 각자의 공개 키를 곱한 값에 같은 가중치를 적용한 결과와 같아야 합니다. 이렇게 u개의 별도 검사가 하나의 비교가 되며, BIP-340은 여기서 상당한 속도 향상이 있다고 설명합니다.
그 이득의 대가로 서명당 비용이 발생합니다. BatchVerify는 각 r 값을 다시 곡선 위로 올리는데, 단일 검증은 그렇게 하지 않습니다. Verify는 s와 챌린지로 R을 다시 계산한 뒤 그 x 좌표가 r과 같은지만 확인합니다.
보장은 의도적으로 비대칭적입니다. 묶음의 모든 서명이 유효하면 BatchVerify는 항상 성공하며, 하나라도 유효하지 않으면 무시할 수 있는 확률로만 성공합니다. 다만 어느 서명이 문제인지 지목하지는 않으므로, 어느 서명이 깨졌는지 알아야 하는 검증자는 서명을 하나씩 검사합니다.
확인할 수 있는 곳
일괄 검증은 전적으로 네트워크에서 검증자 쪽에만 존재하므로, 지갑 인터페이스나 수수료 추정치에는 결코 나타나지 않습니다.
이득이 되는 경우는 지갑이 결제를 보낼 때가 아니라 노드가 수년치 Taproot 지출을 한꺼번에 처리할 때입니다. BIP-340은 일괄 처리를 어디에서도 의무화하지 않습니다. 단일 서명 검증이 정의이며, 묶음은 검증자가 선택할 수 있는 것입니다. 이 BIP는 바이트 수준에서 규정된 알고리즘을 요구하는데, 이는 BIP-66 전까지 DER 파싱에 없었던 정확성으로, 어떤 검증자에게는 유효하고 다른 검증자에게는 유효하지 않은 서명을 아무도 만들 수 없게 하기 위해서입니다. 검증자가 스스로 묶음을 고르기 때문에, 바로 이 성질이 공격자가 두 방식을 서로 어긋나게 만들려 해도 일괄 검증과 단일 검증이 무시할 수 있는 확률로만 달라지도록 보장합니다.
일괄 처리는 BIP-340 안에서 단독으로 보면 임의적으로 보이는 선택들도 설명합니다. 서명은 더 짧은 형태, 즉 128비트 보안 목표에 16바이트 해시로 충분한 형태를 택할 수도 있었지만 이 BIP는 이를 거부했습니다. 짧은 해시는 서로 신뢰하지 않는 서명자들이 함께 작업할 때 취약하며, R을 담는 더 긴 형태가 일괄 처리를 지원하는 형태입니다. 공개 키는 비트코인의 통상적인 33바이트 압축 인코딩 대신 32바이트를 쓰는데 이는 간결성을 위한 선택이며, 그렇게 빠지는 y 좌표는 모호하게 두지 않고 짝수 쪽으로 고정합니다. 효율적인 검증과 일괄 처리 모두 그것이 모호하지 않아야 하기 때문입니다.
ECDSA는 이 중 아무것도 얻지 못합니다. BIP-340은 이를 서명 방식을 바꾸는 이유 중 하나로 제시합니다. 표준화된 그 방식은 추가 증인 데이터를 넣지 않는 한 일괄 처리가 개별 검증보다 더 효율적일 수 없습니다.
일괄 검증 vs MuSig2
일괄 검증과 MuSig2는 모두 다수의 서명을 더 저렴하게 만들지만, 브로드캐스트되는 내용을 바꾸는 것은 MuSig2뿐입니다.
MuSig2는 트랜잭션이 네트워크에 도달하기 전에 여러 서명자를 하나의 키와 하나의 일반적인 64바이트 서명으로 집계하므로, 그 이득은 프라이버시와 블록 공간에 있습니다. 또한 n-of-n 방식이어서 모든 서명자가 참여해야 합니다. 일괄 검증은 각 서명을 있던 자리에 그대로 두고 검증자가 수행하는 연산만 재배열하며, 누구의 협조나 인지도 필요하지 않습니다. 노드는 서로 무관한 트랜잭션에서 수년의 간격을 두고 낯선 사람들이 만든 서명도 묶음으로 처리할 수 있습니다.