OP_RETURN: 무엇인가요? 정의, 맥락 및 출처

01OP_RETURN: 무엇인가요?

OP_RETURN은 Bitcoin Script의 명령이며 코드는 0x6a입니다. 출력 스크립트의 맨 앞에 있으면 그 출력은 쓸 수 없다는 것이 증명됩니다. 어떤 서명으로도 잠금을 풀 수 없습니다. 명령 뒤에는 데이터를 넣을 수 있습니다. 결제 주소나 수신자에게 보내는 돈이 아니라 거래에 데이터를 기록하는 방식입니다.

02올바른 서명으로도 쓸 수 없는 이유

Jana는 누군가에게 돈을 더 보내는 대신 거래에 정보를 붙이려 합니다. 그래서 출력을 OP_RETURN으로 시작합니다. 이를 쓰려고 하면 해당 명령을 실행하는 순간 서명과 상관없이 스크립트 검사가 실패합니다. 출력 스크립트의 기술적 이름은 scriptPubKey입니다. 위치와 실행 여부가 중요합니다. 삽입된 데이터 안의 같은 바이트는 실행 중인 명령이 아닙니다. 실행되지 않는 분기 안의 OP_RETURN도 맨 앞에 있는 OP_RETURN과 다릅니다. 따라서 거래 어딘가에서 이름이나 바이트를 찾는 것만으로 판단할 수 없습니다. [1] [5]

03프로그램은 데이터 출력을 어떻게 알아볼까

Bitcoin Core는 일반적인 형태를 NULL_DATA로 분류합니다. 이름이 데이터가 비었다는 뜻은 아닙니다. Solver 함수는 맨 앞의 OP_RETURN과 그 뒤의 IsPushOnly 통과 여부, 즉 데이터를 넣는 명령만 있는지를 확인합니다. 텍스트나 계산된 짧은 지문인 hash, 다른 프로토콜을 위한 기록을 담을 수 있습니다. 이 분류는 메시지의 뜻을 인증하지 않으며 노드의 대기 공간 진입도 보장하지 않습니다. 기록만으로 파일 소유권, 저작자, 법적 효력이 자동으로 성립하지도 않습니다. 그런 주장에는 추가 규칙과 증거가 필요합니다. [3]

04UTXO 관리가 줄어도 저장은 무료가 아니다

노드는 아직 쓰지 않았고 앞으로 쓸 수 있는 출력의 모음인 UTXO 집합을 관리합니다. OP_RETURN으로 시작하는 출력은 아무도 쓸 수 없다는 것을 미리 압니다. IsUnspendable이 이를 알아보고 AddCoin은 UTXO 캐시에 넣지 않습니다. 절약되는 것은 현재 작업 상태의 관리이지 전체 기록의 저장 공간이 아닙니다. 확인된 거래는 블록에 남고 데이터는 전송되며 역사적 사본에 보관됩니다. UTXO에서 제외해도 데이터가 지워지지 않습니다. 이런 출력에 돈을 배정해도 채굴자 보상이 아닙니다. 쓸 수 없게 된 금액은 나중에 서명해도 되찾지 못합니다. [2] [6] [1]

05어떤 노드는 전달하고 다른 노드는 거절하는 이유

합의 규칙은 노드가 어떤 블록을 유효하다고 판단할지 정합니다. 반면 로컬 정책은 미확인 거래의 대기 공간인 mempool에 무엇을 넣고, 전달하고, 채굴에 제안할지를 선택합니다. 자원을 보호하기 위해서입니다. 운영자는 서로 다른 설정을 쓸 수 있습니다. 거래 전달을 거절했다고 그 거래가 든 블록이 합의를 위반하는 것은 아닙니다. Mempool 수락 역시 확인을 약속하지 않습니다. datacarriersize는 로컬 데이터 용량 한도를 정하며, 그 자체로 블록 유효성을 바꾸거나 이미 확인된 내용을 지우지 않습니다. [8]

06크기 제한 숫자가 서로 다른 까닭

흔히 인용되는 예전 기본값은 데이터 출력 1개, 스크립트 최대 83바이트로, 보통 내용 80바이트에 명령이 더해졌습니다. Bitcoin Core 30.0은 기본 datacarriersize를 100000으로 높이고 여러 데이터 출력을 허용했습니다. 코드는 각 출력의 scriptPubKey 전체 길이를 공통 한도에서 차감합니다. 메시지 내용만 세는 것이 아니며, 바깥에서 스크립트 길이를 표시하는 필드는 포함하지 않습니다. 다른 거래 제한은 그대로 적용됩니다. 따라서 83으로 설정하면 용량 한도는 돌아가지만 예전의 단일 출력 규칙은 돌아가지 않습니다. 이는 특정 버전의 변경 사항이지 전체 네트워크의 불변 법칙이 아닙니다. [7] [4] [8]

07문서의 지문은 문서의 사연을 증명하지 않는다

Jana는 문서 대신 그 hash를 OP_RETURN에 넣을 수 있습니다. 나중에 원본을 제시하면 같은 방식으로 지문을 다시 계산해 기록과 비교할 수 있습니다. 정확한 파일 바이트와 계산 방법을 보존해야 하며, 지문이 문서를 대신하지는 않습니다. 일치해도 내용이 사실인지, Jana가 작성했는지, 정확히 언제 만들었는지는 증명되지 않습니다. 공개 기록이 신원을 연결할 수도 있고 해시된 정보라고 자동으로 비공개가 되지도 않습니다. 비용은 메시지 길이만 아니라 전체 거래와 블록 공간 수요에 좌우됩니다. [1] [8]

08OP_RETURN이 합의 규칙에 직접 쓰이는 경우

일반적인 애플리케이션 메시지에는 중요하고 엄밀히 정의된 예외가 있습니다. BIP 141은 블록의 첫 거래인 coinbase에서 OP_RETURN을 witness commitment에 사용합니다. 거래 검증에 필요한 부가 데이터와 암호학적으로 연결하는 구조입니다. 해당 scriptPubKey는 최소 38바이트이며 0x6a24aa21a9ed로 시작합니다. 여러 출력이 일치하면 가장 높은 인덱스, 즉 순서상 마지막으로 일치하는 출력을 선택합니다. 블록에 witness 데이터가 없다면 commitment는 선택 사항입니다. 네트워크가 검사하는 것은 이 특정 구조이며 OP_RETURN 뒤의 임의 문장이 사실인지는 아닙니다. [9]

09허용 크기에 대한 설명을 읽는 법

먼저 어떤 클라이언트와 버전, 설정의 제한인지 확인하세요. 다음에는 실제 거래를 디코딩하고 scriptPubKey와 바이트 인코딩에서 이를 둘러싼 필드를 구분해야 합니다. mempool_datacarrier.py 테스트는 구현의 경계 사례를 보여 주지만 이 글은 실행하지 않습니다. BIP 110은 추가 합의 제한을 제안했으나 종료된 제안이며 datacarriersize로 켜는 규칙이 아닙니다. 예전 버전 설명이 모든 노드나 미래 버전의 동일한 동작을 약속하지도 않습니다. 특정 설정과 실제 거래 확인은 서로 다른 정보입니다. [10] [8] [11]

∑실용 예시

예시 · OP_RET

메시지와 스크립트의 길이가 다른 이유

Jana가 32바이트 데이터를 붙이려 합니다. 단순한 스크립트는 OP_RETURN, 직접 데이터를 넣는 명령, 데이터 자체로 구성됩니다. 1 + 1 + 32 = 34바이트이며 이것이 scriptPubKey 길이입니다. 금액 필드와 스크립트 길이 필드는 출력 인코딩의 다른 부분이므로 이 합에 포함하지 않습니다. 데이터 한도는 스크립트를 측정하지만 수수료는 전체 거래를 기준으로 평가합니다. 예시는 아무것도 전송하지 않으며 특정 노드의 수락을 입증하지 않습니다.

맨 앞의 OP_RETURN은 쓸 수 없는 출력을 만들며 결제 주소가 아닙니다.
NULL_DATA 분류, 로컬 전달 정책, 블록 유효성은 서로 다릅니다.
쓸 수 있는 UTXO 관리 부담은 늘리지 않지만 확인된 데이터는 기록에 남습니다.
한도는 프로그램 버전과 전체 스크립트를 봐야 하며 메시지만 세면 안 됩니다.

맥락과 함께 읽기

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin Script, 트랜잭션, UTXO, Mempool, Transaction Fees, BIP 110. 다음 항목에서도 이 글을 참조합니다 Runes, BRC-20.

?실용 질문

01이 출력에 비트코인을 배정하면 채굴자가 받나요?

아닙니다. 쓸 수 없다고 증명된 출력에 배정한 돈은 쓸 수 없습니다. 수수료는 전체 입력 금액과 모든 출력 금액의 차이입니다. OP_RETURN에 돈을 배정해도 그 돈이 저절로 수수료가 되지 않습니다.

02더 큰 메시지를 허용하면 비트코인 전체 규칙이 바뀌나요?

반드시 그렇지는 않습니다. 노드는 블록 유효성 규칙을 바꾸지 않고 로컬 정책을 조정해 더 많은 거래를 전달할 수 있습니다. 클라이언트 설정과 합의 규칙, 특정 거래의 실제 확인을 구분해야 합니다.