OP_CHECKSIG

지금까지 사용된 비트코인은 거의 모두 이 하나의 오피코드, 바이트 0xac를 거쳤습니다. 서명 끝에 붙은 sighash 바이트에 따라 트랜잭션의 다이제스트를 만들고, 공개 키로 서명을 검사한 뒤 참 또는 거짓을 푸시합니다. 거짓이 푸시되면 지출은 일어나지 않으며, 비트코인을 소유한다는 것이 코드에서 의미하는 바가 바로 이것입니다.

작동 방식

OP_CHECKSIG는 두 항목을 꺼내는데, 공개 키가 먼저이고 서명이 그 아래에 있습니다. 그런 다음 사람들이 보통 하나로 뭉뚱그리는 세 가지 별개의 작업을 수행합니다.

첫째, 무엇에 서명했는지 결정합니다. 서명의 마지막 바이트는 서명의 일부가 아닙니다. 다이제스트가 트랜잭션의 어느 부분을 다루었는지 알려 주는 플래그입니다. 압도적으로 흔한 값은 0x01이며, 이는 모든 입력과 모든 출력을 뜻하므로 서명한 뒤 트랜잭션의 어느 부분을 바꾸든 서명이 무효가 됩니다. 그 다이제스트를 만드는 방법은 두 번 대체되었는데, SegWit 버전 0 지출에는 BIP-143으로, Taproot에는 다시 BIP-341로 대체되었으며, 두 번 모두 해싱 비용이 트랜잭션 크기의 제곱으로 커지는 것을 막기 위해서였습니다.

둘째, 인코딩을 검사하는데 비트코인은 이 부분에서 유난히 엄격합니다. 레거시 서명은 유효한 DER이어야 하고, 플래그 바이트를 포함해 최대 72바이트여야 하며, S 값은 타원 곡선 차수의 아래쪽 절반에 있어야 합니다. 엄격한 인코딩 규칙은 2015년 7월의 BIP-66으로 도입되었고, 그 전환으로 어느 하루 오후에 블록 여섯 개가 고아가 되었는데, 여러 대형 풀이 검증하지 않은 블록 헤더 위에서 블록을 만들고 있었기 때문입니다. 채굴과 검증이 서로 다른 작업이라는 점을 가장 분명하게 보여 주는 사례로 남아 있습니다.

셋째, 검증합니다. 레거시 지출과 SegWit 버전 0 지출은 secp256k1 위의 ECDSA를 사용합니다. Tapscript는 대신 BIP-340에 따른 64바이트 Schnorr 서명을 사용하고, 검사가 실패하면 다른 무엇이 아니라 빈 항목을 푸시하도록 요구하며, 검사하는 서명마다 스크립트 예산에서 50 가중치 단위를 차감합니다.

확인할 수 있는 곳

OP_CHECKSIG는 현존하는 거의 모든 스크립트를 끝맺습니다. 레거시 출력은 이 오피코드로 끝나고, 네이티브 단일 키 SegWit 지출은 그 바이트가 체인에 나타나지 않더라도 같은 마지막 오피코드로 같은 템플릿을 실행하며, 라이트닝 네트워크의 커미트먼트 스크립트는 타임록과 철회 분기 뒤에 이 오피코드로 끝납니다.

블록 탐색기를 읽을 때는 예외를 알아 둘 만합니다. Taproot 키 경로 지출은 스크립트를 전혀 실행하지 않습니다. 노드가 출력의 32바이트 키에 대해 서명 하나를 직접 검사합니다. 표시할 어셈블리도, 가리킬 오피코드도 없으며, 바로 그 때문에 이 지출 유형이 이용 가능한 지출 유형 가운데 가장 저렴하고 가장 프라이버시가 보호되는 유형이며, 소유자만 지출하는 bc1p 주소가 온체인에서 다른 모든 주소와 똑같아 보이는 이유이기도 합니다.

OP_CHECKSIG vs OP_CHECKSIGADD

OP_CHECKSIGADD가 존재하는 이유는 OP_CHECKSIG를 셀 수 없기 때문입니다. 여러 참여자가 있는 스크립트에서는 제시된 서명 중 몇 개가 유효한지 알아야 하는데, 옛 설계는 키와 서명의 목록 전체를 한꺼번에 삼키는 오피코드 하나로 이에 답했습니다. Tapscript는 서명 하나를 검증하고 스택의 누적 합계에 1을 더하는 오피코드로 이를 대체했으므로, 2-of-3 정책은 2와의 비교로 끝나는 짧은 시퀀스가 됩니다. 이 변화는 겉치레가 아닙니다. 서명을 하나씩 세는 것이 Schnorr 서명의 일괄 검증을 가능하게 하고, Taproot의 검증 속도는 바로 일괄 검증에서 나옵니다.