OP_EQUAL

0x87 바이트는 비트코인에 정말로 필요한 유일한 비교를 수행합니다. 이 두 덩어리는 동일합니까? 비교는 숫자가 아니라 원시 바이트를 대상으로 하며, 그래서 이 언어에는 산술적 동등성을 위한 별도의 오피코드가 있습니다. 3으로 시작하는 주소로 보낸 모든 결제는 이 명령어 하나로 스크립트를 끝냅니다.

작동 방식

스택에서 항목 두 개가 빠지고 하나가 다시 들어갑니다. 일치하면 0x01 한 바이트가, 일치하지 않으면 빈 항목이 들어갑니다. 비트코인은 빈 항목을 거짓으로 취급하므로, 뒤따르는 어떤 것이든 이 결과를 검사할 수 있습니다.

바이트 비교는 들리는 것보다 엄격합니다. 사람이 같은 숫자라고 부를 두 값이 서로 다른 바이트 문자열일 수 있으며, 이 오피코드는 그 둘을 같지 않다고 판정합니다. 이것은 이 오피코드의 실제 용도, 즉 어떤 차이라도 있으면 실패해야 하는 해시와 프리이미지를 비교하는 데 올바른 동작이며, 산술 결과를 OP_NUMEQUAL로 비교하는 이유이기도 합니다.

흥미로운 성질은 이 오피코드가 하지 않는 일에 있습니다. 결과에 따라 행동하는 대신 결과를 남겨 둡니다. 스크립트는 맨 위에 남은 항목이 참일 때만 성공적으로 끝나므로, 이 오피코드로 끝나는 스크립트는 질문을 던지고 그 결과를 답으로 남기는 것입니다. Bitcoin Core의 클린스택 규칙은 그 밖에 아무것도 남아서는 안 된다고 덧붙이며, 스크립트 해시 지출의 경우 이는 정확히 참 값 하나만 남고 그 밖에는 없어야 한다는 뜻입니다.

이 마지막 세부 사항은 보이는 것보다 중대합니다. Pay-to-script-hash는 해시된 스크립트 전반에 관한 규칙이 아니라, 정확히 23바이트 패턴 하나, 즉 해시 오피코드 하나, 20바이트 푸시 하나, 그리고 끝의 이 오피코드에 관한 규칙입니다. 결합된 verify 형식으로 같은 논리를 작성하면 특별 처리가 적용되지 않고, 리딤 스크립트는 추출되거나 실행되지 않으며, 출력은 프리이미지를 추측하는 누구나 지출할 수 있는 평범한 해시 퍼즐처럼 동작합니다.

확인할 수 있는 곳

3으로 시작하는 주소의 모든 미지출 출력은 블록 탐색기에서 동일한 세 토큰 어셈블리를 보여 주며, 여기서 끝납니다. 거래소가 보낸 모든 래핑된 SegWit 출금도 마찬가지입니다.

해시 잠금 계약에도 나타납니다. 라이트닝 네트워크의 결제 스크립트는 비밀값을 해시하고 그 결과를 고정된 값과 비교하는데, 수신자가 32바이트 프리이미지를 공개하는 순간 결제가 여러 홉을 거쳐 정산될 수 있는 이유가 바로 이것입니다. 체인 간 원자적 스왑도 같은 형태를 사용합니다.

OP_EQUAL vs OP_EQUALVERIFY

OP_EQUALVERIFY는 검사를 내장한 OP_EQUAL입니다. 0x88 바이트는 같은 비교를 수행한 뒤 답이 거짓이면 스크립트를 즉시 중단하고, 성공하면 스택에 아무것도 남기지 않습니다. 둘 중 무엇을 고를지는 다음에 무엇이 오는지의 문제입니다. pay-to-script-hash처럼 비교가 스크립트의 최종 답일 때는 일반 형식을 사용합니다. 레거시 단일 키 템플릿이 서명을 검사하기 전에 하듯, 비교가 여러 조건 중 하나이고 실행이 계속되어야 할 때는 verify 형식을 사용합니다. verify 형식은 또한 비교와 별도의 검증 명령어를 쓰는 것보다 1바이트를 아끼며, 스크립트의 모든 바이트가 가중치 단위 4씩으로 트랜잭션의 위트니스 없는 부분에 있던 시절에는 이 점이 훨씬 더 중요했습니다.