OP_RETURN과 최근 토론

저자: 제프리 후

최근 OP_RETURN 출력 전달 제한 해제에 대한 논의와 관련하여, 관련자들은 다양한 채널(메일링 그룹, Github, 포럼, 소셜 미디어 등)에서 많은 열띤 토론을 벌였으며, 기관, 언론, 그리고 KOL(인플루언서)들의 요약 및 해석이 쏟아져 나왔습니다. 각 기관은 필연적으로 찬성 또는 반대 입장을 표명하고 있습니다. 제한 완화를 위한 개정안은 확정되었지만, 안타깝게도 일부 내용은 객관적인 상황을 정확하게 이해하지 못한 것으로 보입니다.

저자는 이 글이 독자들에게 OP_RETURN의 원칙과 비트코인 ​​네트워크의 관련 상황에 대한 가능한 한 정확한 소개를 제공하고, 이 논쟁의 양측 관점 요약하며, 중요하지만 해결되지 않은 몇 가지 문제를 제기하기를 바랍니다.

OP_RETURN이란 무엇인가요?

저를 포함한 많은 사람들이 OP_RETURN을 처음 알았을 것입니다. OP_RETURN은 사용자가 온체인 임의의 데이터를 기록할 수 있도록 해주기 때문입니다. 그렇다면 이 트랜잭션 메모와 유사한 함수는 OP_RETURN 함수 이름과 어떤 관련이 있을까요?

접두사 "OP"를 보면 OP_RETURN 이 비트코인 ​​스크립트의 연산 코드라는 것을 쉽게 알 수 있습니다. 하지만 이 코드가 어떻게 데이터를 전달하는지, 비트코인 ​​스크립트 수준에서 살펴봐야 합니다.

 OP_RETURN <data>

OP_RETURN 은 제어 흐름 종료 명령어입니다. 다른 프로그래밍 언어의 return 키워드가 함수에서 반환하는 것처럼, 비트코인 ​​스크립트가 이 연산에 도달하면 즉시 실행을 중단하고 결과를 false로 태그. 이는 실패를 의미합니다(왜 false로 설계되었는지는 아래에서 설명하겠습니다).

비트코인의 합의 규칙은 입력에서 참조하는 모든 출력 스크립트가 실행 후 true를 반환해야 한다고 규정하고 있으므로 OP_RETURN을 포함하는 모든 출력은 지출을 시도할 때 실패하여 "지출 불가능한 출력"이 됩니다.

중요한 점은 이 검증이 출력을 사용하려고 할 때만 트리거된다는 것 입니다. 트랜잭션을 생성할 때 OP_RETURN 스크립트를 사용하여 출력을 생성하더라도 트랜잭션의 유효성에는 영향을 미치지 않습니다. 또한, 이러한 트랜잭션은 노드의 표준 정책(예: 크기 제한)을 충족하는 한 노드에 의해 전달됩니다. 이러한 출력은 절대 사용할 수 없으므로 UTXO 세트에 저장할 필요가 없으며 , 따라서 전체 노드의 핫 스토리지 부담을 증가시키지 않습니다.

이는 비트코인에 데이터(또는 그래피티)를 쓰는 기능을 제공하는 것과 같습니다.

사토시 나카모토 도 사임할 자격이 있나요?

독자들은 온체인 콘텐츠를 작성하는 것이 자연스럽고 고대부터 이어져 온 일이라고 말할지도 모릅니다. 사토시 사토시 나카모토 않았나요?

안타깝게도 사토시 나카모토 아직 OP_RETURN과 같은 고급 함수를 사용하지 않았습니다. 앞서 언급한 OP_RETURN의 전체 함수는 Bitcoin Core v0.9.0에서 재정의되었습니다.

OP_RETURN은 사토시 나카모토 시대 초기 버전인 v0.3.5 이전에도 존재했지만, 실행되지 않은 스크립트 부분을 건너뛰고 스택의 최상위 요소를 반환하는 역할을 했습니다. 일반적인 의미의 return 문과 비슷할까요? 하지만 이는 심각한 보안 위험을 초래할 수 있습니다. 예를 들어, 공격자는 잠금 해제 스크립트에서 다음과 같은 내용을 생성할 수 있습니다.

 OP_TRUE OP_RETURN

OP_RETURN이 실행되면 스크립트는 스택 최상단에서 OP_TRUE를 반환하고, 잠금 스크립트의 모든 확인 조건을 무시합니다. 이렇게 되면 누구의 비트코인도 도난당할 수 있습니다! 그래서 사토시 나카모토이 문제를 신속하게 수정하여 OP_RETURN의 결과를 항상 실패(false)로 변경했습니다. 이것이 바로 지금 우리가 보는 "데이터를 운반하면 사용할 수 없음"의 근간입니다.

OP_RETURN <data> 를 표준화된 스크립트로 정의하여 데이터 크기 제한 내의 OP_RETURN 출력을 네트워크로 전달할 수 있게 한 것은 사토시 나카모토 은퇴한 후인 2014년 Bitcoin Core v0.9.0 버전에 포함되었습니다.

여기서 저자는 OP_RETURN의 수정 내역을 간략하게 요약합니다.

다양한 그래피티 기법

그렇다면 사토시 나카모토 어떻게 그 문장을 썼을까요? 체인에 데이터를 올리는 다른 방법은 무엇일까요?

스크립트시그

사토시 나카모토 scriptSig 필드를 사용했습니다. 성공적으로 지출하려면 scriptSig가 잠금 해제 과정에서 출력 스크립트(공개 키)와 일치해야 하지만, 스크립트를 신중하게 구성한다면(예: OP_DROP을 사용하여 검증 잠금 해제 전에 그래피티 데이터를 삭제하는 등), 정상적으로 지출하는 동안 임의의 데이터를 전달하는 효과를 얻을 수 있습니다.

현재 scriptSig에 직접 데이터를 기록하는 방식은 그다지 널리 사용되지 않지만, 주로 코인베이스 거래에서 여전히 사용되고 있습니다. 코인베이스 거래는 이전 출력을 잠금 해제할 필요가 없고, 블록 높이, 확장된 논스, 채굴자 식별, 신호 등을 기록하기 위해 더 자유롭게 내용을 채울 수 있기 때문일 수 있습니다.

그렇다면 scriptSig가 인기를 얻지 못하게 된 이유는 무엇일까요? 비용 문제도 한 가지 원인일 수 있습니다. scriptSig는 거래 입력에 포함되기 때문에 먼저 출력을 생성해야 하고, 출력이 사용될 때 데이터가 함께 전달됩니다. 따라서 데이터 자체의 크기 외에도 추가 출력과 거래 크기에 대한 수수료를 지불해야 합니다(비트코인 거래 수수료는 크기와 양의 상관관계가 있습니다). 또 다른 이유는 프로그래밍의 복잡성인데, 이 또한 특별한 구조를 가진 출력을 먼저 생성해야 하기 때문에 발생합니다.

P2FK

그래서 나중에 사람들은 이를 단순화하는 방법을 생각해 냈습니다. 출력 자체는 자금 절약/지출을 위해 생성되는 것이 아니라 데이터를 공개하기 위한 연결 고리일 뿐이므로, 작성될 내용은 수신 공개 키, 즉 Pay-to-Fake-Key 로 직접 사용될 수 있습니다. 새로운 지출 거래를 시작할 필요가 없고, 추가 지불 금액도 자연스럽게 줄어들며, 처리 수수료도 절감됩니다.

 OP_PUSHBYTES_65 <fake-pubkey-data> OP_CHECKSIG

이 주소에는 사용할 유효한 개인 키가 없으므로, 이 UTXO는 절대 사용할 수 없으며, 해당 UTXO에 포함된 비트코인은 소각된 것과 같습니다. 하지만 거래는 정상적으로 보이고 노드는 여전히 이를 저장해야 합니다. 결국, 해당 개인 키가 있다면 어떻게 될까요? 따라서 UTXO 세트의 확장과 노드 저장 비용의 증가는 당연한 결과입니다 .

마찬가지로 P2FKH(P2PKH와 유사, 쓰고자 하는 데이터를 스크립트에서 해시값으로 사용), P2FMS(Pay-to-Fake-Multisig, 맨몸의 다중 서명 스크립트에서 공개 키로 위장) 등이 있습니다.

사실, OP_RETURN을 표준화된 스크립트로 재정의하는 주된 목적 중 하나는 사람들이 UTXO 세트를 확장하게 만드는 이러한 가짜 출력을 더 이상 사용하지 않기를 바라는 마음으로 대안을 제공하는 것입니다.

서수/비문

최근 몇 년 동안 비트코인에 대해 알아본 사람이라면 서수(Ordinals)와 그 데이터 기록 방식("비문(inscriptions)")에 더 익숙할 것입니다. 비문은 임의의 파일 데이터를 Taproot 입력의 증인 데이터에 입력합니다.

이 구현의 최종 효과는 OP_RETURN과는 상당히 다릅니다 . OP_RETURN 출력의 데이터는 해당 출력을 생성한 트랜잭션에서 이미 공개됩니다. 반면, 비문(inscription)은 증인 데이터를 공개하기 위해 또 다른 트랜잭션을 필요로 합니다 (scriptSig 방식과 유사하지만 더 경제적입니다). 또한, 비문은 전체 네트워크에서 수용되는 트랜잭션 풀 전달 전략의 적용을 덜 받으며, 대부분의 노드는 데이터 크기가 80바이트를 초과하는 OP_RETURN 출력을 전달하지 않습니다.

데이터 쓰기를 구현하는 다른 기술도 있지만 저자는 위에서 언급한 인기 있거나 한때 인기 있었던 방법을 요약합니다.

전달 전략 대 합의 규칙

위 표와 이전 표에서 저자는 "트랜잭션 전달 전략"이라는 핵심 단어를 언급했습니다. 최근 OP_RETURN 스톰에 대한 논의의 상당 부분은 트랜잭션 풀 전달 전략에 집중되어 있습니다.

트랜잭션 전달 정책은 비트코인 ​​노드(예: 비트코인 ​​코어)가 확인되지 않은 트랜잭션을 전달하고 수락할 때 실행하는 일련의 비합의 규칙을 말합니다 . 이러한 정책은 일반적으로 서비스 거부 공격(DoS)을 방지하고, 향후 업그레이드를 위한 공간을 확보하며, 더 나은 행동을 유도하고 장려하는 데 사용됩니다. 트랜잭션이 노드의 로컬 전달 정책 규정(입력 및 출력 유형, 크기, 수수료, 스크립트 동작 등)을 충족하는 경우, 노드는 기본적으로 해당 트랜잭션을 수락하고 전달합니다.

"표준 거래"라는 개념도 있는데, 이는 비트코인 ​​코어 소프트웨어에 정의되어 있습니다. 거래가 이 버전의 소프트웨어에서 정의된 표준 거래가 아니면 노드는 해당 거래를 저장하거나 전달하지 않습니다.

반면, 합의 규칙이 있습니다. 합의 규칙은 모든 노드가 블록과 거래의 유효성을 판단하는 엄격한 기준을 의미합니다. 합의 규칙을 위반하는 거래만 전체 네트워크에서 거부됩니다.

전달 전략과 합의 규칙의 중요한 차이점은 트랜잭션이 "비표준"일 수 있지만 여전히 "합법적"일 수 있다는 것입니다. 다시 말해, 트랜잭션이 기본 표준 정책을 충족하지 않으면 노드는 해당 트랜잭션을 전달하지 않거나, 트랜잭션 풀에 포함하지 않거나, 심지어 패키징하지 않기로 선택할 수 있습니다. 하지만 일단 해당 트랜잭션이 (채굴자에 의해 패키징되어) 블록에 나타나면 다른 노드들은 합의 규칙에 따라 해당 블록이 유효하다고 판단합니다.

OP_RETURN 출력을 예로 들면, 이 명령어는 처음부터 끝까지 존재하며, 스크립트에 포함된 데이터 용량이 아무리 크더라도 합의 규칙을 위반하지 않습니다 . 그러나 이 논쟁 이전에는 대부분의 비트코인 ​​노드가 트랜잭션 전달 전략으로 80바이트의 데이터 용량 제한을 채택했습니다. 80바이트 미만의 데이터 용량을 가진 OP_RETURN 출력은 자유롭게 전달되고, 80바이트를 초과하는 출력은 전달되지 않습니다.

따라서 독자들은 이 내용을 통해 일부 언론이 이 수정 사항을 "비트코인 OP_RETURN 업그레이드"라고 부르는 것은 명백히 부적절하다는 점을 알아야 합니다. 또한 저자는 이 OP_RETURN 수정 사항을 기반으로 새로운 프로젝트를 개발하려는 일부 프로젝트에 대해서도 회의적 입니다. 더 많은 양의 데이터를 포함하는 OP_RETURN 트랜잭션을 체인으로 전송하는 다양한 방법이 있으며, 이는 근본적으로 다르지 않기 때문입니다.

하지만 변경 사항이 적용되기 전에 Bitcoin Core는 현재 표준 거래에 대해 다음과 같은 조항을 갖추고 있습니다.

• 표준 스크립트 유형 : P2PKH / P2SH / P2WPKH / P2WSH / P2TR(Taproot) 등 ^1. 정의되지 않은 명령어 등을 사용하지 마세요.
• 서명 스크립트 크기 : 각 입력에 대한 scriptSig 길이는 1,650바이트를 초과할 수 없습니다.
• 총 거래 크기 : 100,000 vByte 이하.
• 출력 금액 : 출력 단위에는 하한이 있습니다. 예를 들어, P2PKH 출력은 최소한 546 sat ² (먼지 한계)보다 커야 하고, OP_RETURN 출력은 0 sat입니다.
• 서명 스크립트 제약 조건
• 수수료율 제약 : 노드가 설정한 최소 수수료를 충족해야 함
• 버전 번호 및 해당 규칙 : v2, v3 등. 이 외에도 RBF, 패킷 릴레이 및 기타 규칙이 있습니다.

참고 1: 사용자는 지출 조건을 통해 다양한 유형의 거래를 구성할 수 있으며, 위의 P2FK가 좋은 예입니다. 따라서 표준화는 애플리케이션이 출력의 의미를 이해하는 데 매우 유용합니다.

참고사항 2: 랭 교수는 자신 있게 이렇게 말할 수 있습니다: 당신이 나에게 1비트코인( BIP-177 에 따라)을 주지만, 546비트코인이라는 먼지 한도가 있기 때문에 나는 그것을 원하지 않습니다.

이러한 제한이 왜 중요하고, 심지어 이 논쟁의 초점이 되는 것일까요? 표준 거래의 주요 기능은 다음과 같습니다.

• 남용 방지: 유효하지 않은 데이터, 과도한 거래 또는 가비지 출력의 추가 확산을 제한합니다. 이를 통해 메모리 풀의 거래 형식을 제어하고, 검증 및 저장 공간 부담을 줄이며, 노드가 DDoS 공격을 효과적으로 방지할 수 있습니다.
• 온체인 확장 제어: 주로 UTXO 세트의 크기를 제어합니다. 이론적으로 노드는 모든 UTXO를 보관해야 하며, 이는 향후 언제든 사용될 수 있는 자금을 의미합니다. UTXO 세트의 남용이나 불필요한 확장(예: 먼지 공격)은 노드 성능에 심각한 영향을 미쳐 전체 네트워크의 보안 및 탈중앙화 악영향을 미칩니다.
• 효율성과 예측 가능성 향상: 포워딩 전략은 규칙을 준수하지 않는 거래를 제한할 뿐만 아니라, 규칙을 준수하는 거래도 용이하게 합니다. 채굴자가 기준(수수료율 준수, ​​명확한 출력 구조, 합리적인 서명 등)을 충족하는 거래를 수신하면 블록에 담을 가능성이 높아집니다. 이는 지갑이 수수료 추정 및 RBF(Reverse Blocking Function)를 구현할 수 있는 안정적인 기반을 제공하고, 사용자가 거래 확인 시간을 더 정확하게 예측할 수 있도록 합니다.
• 상호작용성 향상: 비트코인의 서명 및 스크립트 양식을 통해 사용자는 다양한 거래를 생성할 수 있습니다. 하지만 여러 유형의 표준 거래가 명시되면 지갑 및 기타 애플리케이션이 이러한 거래 형식에 맞춰 개발하기가 더 쉬워지고, 다양한 애플리케이션 사용 시 사용자의 이동성과 상호작용성이 향상됩니다.

최근 논란의 타임라인

위의 약간 긴 소개를 통해 이제 OP_RETURN에 대한 최근 논란을 정리할 수 있습니다.

관점

PR 32406이 통합되어 모든 것이 해결된 것처럼 보이지만, 저자는 여전히 양측의 관점 다시 정리하고자 합니다. 한편으로는 이 글 전반부에 있는 대중 과학 서론을 통해 독자들이 이러한 논의와 관점 다시 살펴보기를 바라며, 다른 한편으로는 이러한 관점 를 통해 더 많은 생각과 통찰력을 얻을 수 있기를 바랍니다. 저자의 개인적인 의견은 다음 장에 남겨두겠습니다.

OP_RETURN 관점 완화 지원

• 사용자 요구를 존중하고 확립된 현실을 인정해야 합니다. 지지자들은 전달 정책의 OP_RETURN 관련 제한이 온체인 저장을 막을 수 없다고 지적합니다. 온체인 저장에 대한 실질적인 시장 수요가 존재하고 사용자들이 이를 위해 기꺼이 비용을 지불하기 때문입니다. 오디널 열풍을 예로 들면, 사진과 같은 대량 의 비금융 데이터는 증인 필드를 통해 블록에 기록되며, 표준 정책 제한이 적용되지 않습니다. 통계 에 따르면 오디널은 출시 이후 8,800만 건 이상의 인스크립션 생성했으며, 처리 수수료로 7,000 BTC 이상을 지불했습니다. 이는 많은 사용자가 온체인 저장에 기꺼이 비용을 지불하고 있음을 시사합니다. 명목상의 제한을 계속 고집하기보다는 현실에 따라 제한을 해제하는 것이 더 낫습니다. " 말이 울타리를 벗어났다 "는 말이 있듯이, OP_RETURN이 없더라도 이러한 데이터는 다른 방식으로 체인에 계속 존재할 것입니다.

• 중립성 및 검열 방지 원칙: 비트코인 ​​코어 개발자들은 비트코인 ​​네트워크의 검열 방지 특성이 가장 중요한 특징이며, 노드 소프트웨어는 중립성을 유지해야 하며 거래 내용이나 목적에 따라 차별해서는 안 된다고 강조합니다 . 또한 그들은 쓰레기 데이터나 체인 공간의 오용을 혐오하지만, 거래 수수료 메커니즘이 거래를 필터링하는 궁극적인 수단이라고 생각합니다 . 누군가가 거래에 대해 다른 사람들보다 더 높은 수수료를 기꺼이 지불할 의향이 있는 한, 채굴자들은 이를 패키징할 경제적 유인을 갖게 됩니다. 초기 비트코인 ​​개발자인 에릭 보스킬은 " 검열에 저항할 수 있는 능력은 궁극적으로 거래 수수료에서 비롯된다 "라고 말했습니다. 따라서 포워딩 수준에서 통제하려 하기보다는 수수료 시장이 역할을 하도록 하는 것이 더 낫습니다. 쓰레기 거래가 높은 수수료를 계속 보조할 수 없는 한, 쓰레기 거래는 수익성이 없기 때문에 점차 사라질 것입니다. 이러한 관점 노드의 수동 필터링이 콘텐츠 검열과 도덕적으로는 다르지만 기술적 효과는 유사하며 , 경제적 동기로 맞서 싸우기 어렵다는 것을 보여줍니다.

• 두 가지 악 중 덜한 악: 이 관점은 현재 대량의 데이터를 포함하는 OP_RETURN 출력은 자유롭게 전달될 수 없으며, 이로 인해 개발자와 사용자는 위에서 언급한 P2FK 및 scriptSig와 같은 더욱 "해로운" 네트워크 방식을 사용하여 데이터를 저장하게 되고, 이로 인해 UTXO가 영구적으로 확장된다고 주장합니다. 데이터는 어차피 체인에 존재하므로 노드에 덜 해로운 방식으로 데이터를 유지하는 것이 합리적입니다. OP_RETURN 출력은 UTXO 집합에 포함되지 않으며 , 검증 중에 복잡한 스크립트를 실행할 필요가 없으므로 가짜 출력이 리소스를 점유하는 것보다 훨씬 효율적입니다. 블록 공간이 가득 차면 OP_RETURN을 대량 사용하면 노드의 부담을 줄일 수 있습니다. 증인 할인이 존재하기 때문에 블록이 증인 데이터로 가득 차면 실제 크기는 4MB에 가깝습니다. 하지만 모든 데이터가 OP_RETURN인 경우에는 할인이 적용되지 않으며 블록 바이트 제한은 약 1MB입니다. 동시에 OP_RETURN 데이터는 UTXO 세트에 포함되지 않도록 제거될 수 있으며, 이는 전체 노드의 운영 비용을 절감하는 데 도움이 됩니다. 따라서 OP_RETURN 전달 제한을 해제하면 온체인 데이터 활용도 저하를 방지 하고 전체 네트워크의 리소스 사용을 최적화할 수 있습니다.

• 채굴자의 행동에 발맞춰 네트워크 효율성을 개선하세요. BitMEX의 연구에 따르면 , 노드가 채굴자가 기본적으로 수락하는 거래를 전달하지 않을 경우, 사용자는 채굴 풀의 프라이빗 채널을 통해 거래를 제출해야 합니다. 예를 들어, MARA와 같은 채굴 풀은 비표준 거래를 수락하는 서비스를 제공합니다. 그 결과, 블록의 내용과 공개 거래 풀의 차이가 점점 더 커지고 노드가 블록에 포함된 모든 거래를 적시에 파악하기 어려워집니다. 이는 블록 전파를 가속화하는 컴팩트 블록과 같은 메커니즘을 파괴하여 블록 전파 지연을 증가시킵니다 . 전파 속도가 느려지면 소규모 채굴자가 블록을 생성한 후 고립될 가능성이 높아져 채굴 산업의 중앙 집중화가 더욱 심화됩니다 . 반대로, 노드 정책이 채굴자의 실제 행동과 일치한다면 공개 P2P 네트워크는 모든 유형의 거래를 수용할 수 있고, 채굴자는 프라이빗 채널을 설정할 필요가 없으며, 거래는 더욱 효율적으로 브로드캐스트되고 패키징될 수 있습니다. 동시에, 각 노드의 거래 풀은 확인될 거래를 더욱 정확하게 반영하고, 다음 블록에 대한 전체 네트워크의 기대치를 더욱 일관되게 유지하여 처리 수수료 예측 및 사용자 경험을 개선하는 데 도움이 됩니다. 결론적으로, OP_RETURN 제한을 제거하면 비트코인 ​​네트워크는 대규모 거래를 은밀하게 처리하는 대신 투명성과 효율성 측면에서 탁월한 성과를 낼 수 있습니다.

• 사용자 선택권과 투명한 개발 과정: 지지자들은 "모두가 받아들이도록 강요한다"는 비난에 대해서도 사용자가 여전히 완전한 선택권을 가지고 있다고 강조했습니다 . 비트코인 ​​코어 소프트웨어 자체는 오픈 소스이며 누구나 복사하고 수정할 수 있습니다. "비트코인 코어는 수많은 프로토콜 구현 중 하나일 뿐입니다. 기여자들이 결정을 내리는 방식 때문에 특별한 것입니다." 만약 강하게 반대한다면, 사용자는 자발적으로 투표하여 이전 버전을 계속 사용하거나, 더 엄격한 정책을 유지하는 Bitcoin Knots와 같은 다른 클라이언트로 전환 할 수 있습니다. 반면, 코어 개발자들은 이 제안이 메일링 리스트에서 GitHub, 그리고 6월 공동 성명에 이르기까지 의사 결정 과정 전반에 걸쳐 공개적이고 투명하게 논의되고 전달되었다고 생각합니다. 정보는 공개적으로 검토될 수 있습니다. 이를 바탕으로 지지자들은 이 수정안이 비트코인 ​​개발의 일관된 오픈 소스 협력 정신을 따르고 있으며, "논의 없이 강요된" 것으로 의심되지 않는다고 생각합니다.

OP_RETURN 제한 완화에 대한 관점

• 비트코인의 원래 목적에서 벗어나는 온체인 공간 남용: 많은 반대자들은 비트코인 ​​블록체인의 귀중한 공간이 주로 화폐 거래에 사용되어야 한다고 주장합니다. 비금융 데이터의 과도한 임베딩 허용은 비트코인을 " 데이터 저장 네트워크 "로 전락시켜 P2P 전자 화폐 시스템으로서의 입지를 약화시킬 것입니다. 한 사용자는 "이건 '비트 코인'이지 ' 비트스토어 '가 아닙니다."라고 비꼬는 투로 말했습니다. 블록을 차지하는 사진, 오디오 및 기타 데이터의 대량 정상적인 금융 거래 공간이 부족해지고 화폐 네트워크로서 비트코인의 가치 기반이 손상될 것입니다 . v0.9.0에서 OP_RETURN이 데이터를 저장하도록 수정되었을 때, 비금융 데이터를 블록체인에 기록하는 것은 권장되지 않는다는 점도 명시되었습니다.

• 스팸 거래 유발 및 잠재적 서비스 거부(DoS) 리스크: 제한이 해제된 후, 공격자나 투기꾼은 실제 임계값이 낮아짐에 따라 더 많은 스팸 거래를 전송할 수 있습니다. 이는 일반 사용자의 처리 수수료(스팸 데이터와 저장 공간을 두고 경쟁해야 하기 때문)를 증가시킬 뿐만 아니라, 노드 처리 속도를 저하시키고 네트워크에 서비스 거부(DoS) 공격 위험을 초래할 수 있습니다. 이러한 관점 가진 사람들은 "스팸 ​​데이터는 결국 채굴자에 의해 패키징될 것"이라는 개발자들의 태도를 타협과 패배주의 로 간주하며, 악의적인 행위에 "굴복"해서는 안 된다고 생각합니다. 이들의 관점에서 볼 때, 더 적극적인 접근 방식은 노드 필터링과 커뮤니티 문화를 강화하여 스팸 데이터가 체인에 업로드되는 것을 방지하는 것입니다.

• 거래 풀 전달 전략의 자율성 파괴: 반대론자들은 비트코인의 탈중앙화 화가 컨센서스 레이어 뿐만 아니라 노드가 자체 거래 풀(mempool)과 전달 전략에 대해 자율적으로 제어하는 ​​것 또한 중요하다고 강조합니다. OP_RETURN 제한이 폐지되면 사용자는 자율적인 선택권을 잃게 됩니다 . 과거에는 노드가 -datacarrier 와 같은 매개변수 설정을 통해 특정 크기를 초과하는 거래를 거부할 수 있었지만, 새 버전에서는 이 옵션이 제거되거나 무효화됩니다. 즉, 새 버전의 Core를 실행하는 모든 노드는 대용량 데이터 부하가 있는 거래를 수용하고 전달해야 하며 , 개인은 더 이상 자신의 선호도에 따라 필터링할 수 없습니다. 이러한 변화는 "단일 노드 전략"에 대한 우려와 의구심을 불러일으켰습니다. Core 개발팀이 소프트웨어 업데이트라는 명목으로 네트워크의 목적을 바꾸는 것일까요? Luke Dashjr와 같은 유명 개발자들은 사용자들에게 기존 필터링 전략을 준수할 수 있는 노드 구현(예: 그가 관리하는 Bitcoin Knots 소프트웨어)으로 업그레이드하거나 전환하지 말 것을 공개적으로 촉구했습니다 .

• 의사 결정 과정 및 가치 분쟁: 기술적 문제 외에도 많은 반대자들이 이 변경의 의사 결정 과정 에 이의를 제기했습니다. GitHub의 해당 PR에 따르면, 대량 사용자가 👎 이모지를 대량 제공했습니다. 코어 팀은 이 과정이 개방적이고 투명하다고 밝혔지만, 많은 사람들은 여전히 ​​개발자들이 합의에 도달하지 못하고 커뮤니티 내에 명백한 의견 차이가 있는 상황에서 성급하게 코드를 병합했다고 생각합니다. 이는 "분쟁을 신중하게 피한다"는 원칙에 위배됩니다. 일부 댓글에서는 "이러한 관행은 매우 나쁜 선례를 남겼다"라고 단도직입적으로 지적했습니다. 다른 댓글들은 일부 개발자들이 Citrea와 같은 "비트코인 생태계" 프로젝트의 영향을 받았다고 주장하며 이 변경의 동기에 의문을 제기했습니다.

개인적인 관점

위의 논의에 대해 많은 언론이 비트코인이 탈중앙화 있는지, 검열에 저항적인지 등 다양한 해석을 내놓고 있습니다. 하지만 저는 비트코인의 원리를 (적어도 현재 상황에서는) 더 잘 이해한다면, 비트코인이 다른 암호화폐처럼 탈중앙화 에 대한 논쟁에 휘말리지 않을 것이라고 생각합니다. 이번 논쟁은 이러한 우려를 어느 정도 반박하기도 했습니다.

전체 사건을 돌이켜보면, 올라올루와 의 의견 에 전적으로 동의합니다. 누구도 적극적으로 변경을 요청하지 않았고, 요청이 있었다 하더라도 아직 배포되지 않은 것을 기반으로 개발자가 선제적으로 조치를 취한 것이었고, 가까운 미래에 비표준 트랜잭션에 대한 수요가 크지 않았습니다. 하지만 이제 개발자들은 딜레마에 빠졌습니다.

검열 저항 vs 스팸

제한 완화를 지지하는 매우 중요한 관점 은 비트코인에서 수행할 수 있는 거래에 제한을 가해서는 안 되며 시장이 결정하도록 해야 한다는 것입니다. 그렇지 않으면 사실상 거래 검열로 이어질 것입니다.

이 주장의 일부에 동의합니다. 비트코인의 탁월한 경제적 특징 중 하나는 거시적 안정성(발행 한도 2,100만 개)뿐만 아니라 미시적 수준에서도 거래 수수료 정책의 균일성 (항상 거래량을 기준으로 계산)입니다. 반면, 이더 전체 경제 규모(PoS, EIP-1559 등 전체 경제 모델 수정)를 변경할 뿐만 아니라 수수료 정책도 자주 변경합니다(덴쿤 업그레이드는 데이터 연산 작성 비용을 절감합니다). 따라서 "보이지 않는 손"이 작동할 수 있다면, "보이는 손"이 개입하지 않도록 해야 합니다. 보이는 손은 종종 "통제할 수 없는 손"이 되기 때문입니다.

OP_RETURN은 이번에 수수료 정책을 바꾸지 않았지만, 수정 과정은 "글을 직접 쓰는 것"보다는 "코드를 직접 쓰는 것"에 더 중점을 두었습니다.

하지만 제 생각에는 거래 검열 주장은 설득력이 없습니다. 핵심적인 차이점은 그것이 내용과 형식, 그리고 타인과 자신에 관한 것인지의 여부에 있습니다 .

일반적인 거래 검토 행위는 노드가 거래를 시작한 사람(공격자, 자금세탁 방지팀 등)의 신원이나 자금 출처(일부 법적 규정을 준수하지 않는 경우)를 파악하여 체인에 공개하지 않는 것입니다. 다시 말해, 거래의 내용 과 "의미"를 파악한 후 다른 사람에게 적극적으로 영향을 미치는 것입니다 .

노드 정책은 공식 규범에 따라 OP_RETURN을 제한하고, 네트워크 남용을 방지하기 위해 위에서 언급한 규범을 충족하는 표준 거래만 전달합니다. 전형적인 반례는 비트코인 ​​네트워크가 심각한 먼지 공격 을 받았던 블록 전쟁 시기입니다. "누군가 기꺼이 지불할 의향이 있는 한"이라는 개념을 엄격하게 고수한다면, 먼지 공격은 공격이 아니라 합리적인 사용으로 간주될 수 있을까요?

반면, 노드 전략은 네트워크와 스토리지 부담을 줄이기 위해 관심 없는 거래를 걸러내는 등 자체 노드를 처리하는 것에 더 중점을 둡니다.

노드 자율성 대 네트워크 효율성

또 다른 논쟁의 초점은 전달 및 거래 풀 전략을 사용자 정의하기 위해 노드에 더 많은 지원을 제공해야 하는지, 아니면 네트워크 효율성을 개선하기 위해 일관성을 유지하는 것이 더 나은지(광부 인센티브 호환성, 더 빠른 블록 전파, 더 예측 가능한 수수료)에 대한 것입니다.

효율성 측면에서, 더 빠른 블록 전파 효율은 기술적으로 설득력이 있습니다. 통합된 거래 풀은 없지만 , 노드 간 거래 풀 내용이 더 일관적이면 노드 자체가 향후 체인에 포함될 더 많은 거래를 보유하게 됩니다. 컴팩트 블록 메커니즘을 사용하면 네트워크 오버헤드가 감소하여 블록 동기화 속도가 향상됩니다. 동시에, 속도 예측의 정확도가 향상되는데, 이는 속도에 민감한 일부 거래(예: 라이트닝 네트워크의 사전 서명된 거래)에 더욱 중요합니다.

하지만 문제는 OP_RETURN 트랜잭션이 너무 많아서 고밀도 블록의 전파나 비율 추정에 상당한 영향을 미쳤는가 하는 것입니다. 아니면 모든 사람에게 기본 설정을 수정하도록 요청하는 게시글을 올리는 대신, 코드를 작성하는 "보이는 손"을 사용하여 이를 홍보해야 할 정도로 시급한 상황인가요?

네트워크에서 노드 다양성의 중요성에 대해 자세히 설명하고 싶지 않습니다. 노드 운영자로서, 적어도 일시적으로는 노드 자체 구성 옵션을 유지할 수 있다는 점에서 PR #32406이 더 수용 가능합니다.

노드 구현 대 네트워크 공개 정책

위에서 언급했듯이 이 수정 사항을 "비트코인의 OP_RETURN 업그레이드"라고 부를 수는 없습니다. 이는 비트코인 ​​코어 자체 정책의 수정일 뿐입니다. 다른 일부 클라이언트 구현은 동일한 정책 변경을 따르지 않았습니다. 그런데 왜 이렇게 큰 논쟁이 벌어졌을까요? 제가 생각하기에 한 가지 이유는 비트코인 ​​코어가 가장 널리 사용되는 클라이언트이자 사실상의 표준이기 때문입니다.

어쩌면 부적절한 예로 미국 달러가 있습니다. 미국 달러는 미국의 국내 통화이자 사실상의 국제 통화입니다. 미국은 달러를 통해 세계에 영향력을 행사할 수 있지만, 통화 정책을 수립할 때는 당연히 국내 경제 상황을 고려해야 합니다.

Bitcoin Core는 "사실상의 표준" 수준에서 비슷한 모순을 가지고 있습니다.

한편, 비트코인 ​​코어는 이러한 포지셔닝에 제약을 받고 있으며, 자체 전략(트랜잭션 풀 관리, 트랜잭션 전달)은 노드 자체뿐만 아니라 전체 네트워크의 상황까지 고려해야 합니다. v3 트랜잭션 전달 과 같은 새로운 전략은 상당한 영향을 미칠 수 있으며, 라이트닝 네트워크와 같은 다른 애플리케이션 개발에도 큰 영향을 미칠 것입니다.

반면, 이 사실상의 표준은 네트워크 프로토콜을 강제할 수 있는 기능도 가지고 있습니다. 예를 들어, 비트코인 ​​코어는 규칙 에 따라 이전 버전의 취약점을 공개합니다. 따라서 사용자는 이론적으로는 오래전 클라이언트를 실행할 수 있지만 , 이러한 보안 취약점으로 인해 사용자는 새 버전으로 업그레이드하고 새로운 기능을 수용해야 할 수 있습니다. 특히 구성 옵션까지 제거된 경우에는 더욱 그렇습니다.

이번 사건으로 미루어 보아, 비트코인 ​​코어는 앞으로도 두 역할 사이에서 균형을 유지할 것으로 보입니다. 그러나 노드를 운영하는 사용자들이 일부 개발자들이 생각하는 것처럼 자발적으로 투표하는 것은 쉽지 않습니다. 노드를 운영하는 모든 사람이 코드를 수정하기를 기대하는 것은 비현실적이며, 다른 클라이언트로 전환하려면 다른 클라이언트가 개발 및 테스트 리소스가 부족하고 견고성과 보안성이 떨어질 수 있다는 점을 고려해야 합니다. 따라서 반대 의견을 가진 사용자들에게 남겨진 선택은 다소 복잡합니다.

이 문제는 현재까지 해결되지 않았습니다.

(위에)