비트코인 인스크립션을 '필터링'하는 PR(풀 리퀘스트)에 대해 개발자들 사이에서 제기된 찬반 의견은 무엇인가?
정리: gloria
번역: GaryMa, Wu Shuo Blockchain
배경
2023년 9월, 비트코인 개발자 루크 대시제이알(Luke Dashjr)는 Bitcoin Core GitHub 저장소에 PR을 제출하여 「datacarriersize」를 업데이트해 '인스크립션(Inscriptions)'과 같은 새로운 스크립트 데이터를 담은 거래를 필터링하려 했다. 이는 인스크립션 거래가 버그 공격에 해당하며 금지되어야 한다는 가치관에 기반한 것이다.
기본적으로 Bitcoin Core는 미확정 거래의 OP_RETURN 출력 수와 삽입 가능한 데이터 양을 제한하며, 그 기본값은 80바이트이다. -datacarriersize 옵션을 설정함으로써 사용자는 이 데이터 제한 값을 변경할 수 있다. 그러나 현재 이 옵션은 OP_RETURN 출력에만 적용된다.
이 PR은 -datacarriersize를 설정한 사용자가 OP_RETURN 출력의 데이터량뿐 아니라 위트(witness) 데이터 내 삽입된 데이터량도 제한할 수 있도록 변경한다.
주의할 점은, 이 PR이 위트 데이터 내의 임의 데이터 삽입을 포괄적으로 식별하는 방법을 제공하지는 않는다는 것이다(현재까지는 이를 확실하게 식별할 수 있는 방법이 존재하지 않기 때문). 주로 인스크립션 데이터에 사용되는 OP_FALSE OP_IF ... OP_ENDIF 구조를 검사하는 데 초점을 맞추고 있다.
많은 개발자들이 이 PR에 대해 활발히 논의했지만, 2024년 1월 5일 Bitcoin Core 코드 유지 관리자 achow101이 이 PR을 공식적으로 종료했다. achow101은 최후 의견에서 "(루크가 제안한) 이 PR은 분명히 논란이 있으며, 현재 상태에서는 모두에게 받아들여질 만한 결론에 도달할 가능성 없으며, 더 이상 열어둘 이유가 없고, 계속해서 반복적이고 교착상태에 빠진 논의 알림을 보내는 것은 바람직하지 않다"고 밝혔다.
Bitcoin Core의 또 다른 코드 유지 관리자인 gloria는 이 주제에 대한 개발자들의 찬반 양측 견해를 정리하였으며, 아래는 Wu Shuo의 번역 내용이다.
「인스크립션 금지」를 지지하는 입장
1. 「인스크립션을 금지하라, 이것은 쓰레기 거래다」
오디널(Ordinals), NFT, 데이터 전송 또는 기타 비금융 거래 용도로 사용되는 이러한 유형의 거래들은 「쓰레기 거래」이며, 높은 거래량과 수수료로 인해 비트코인의 결제 목적 사용을 해친다.
● 이러한 쓰레기 거래는 비트코인의 본래 목적을 점점 더 어렵게 만들고 있다.
● 데이터 삽입은 탭루트(taproot) 스크립트를 속이는 행위이며 남용이다.
● 임의 바이트를 삽입할 수 있다는 것은 하나의 「버그」다.
● 만약 비트코인이 화폐라면(그렇다!)... 비화폐 거래는 최대한 줄여야 한다.
● 오디널을 지지하는 사람들은 이더리움/반비트코인 극단주의자들이며, 「비트코인 문화를 바꿔야 한다」고 외치는 이들은 시간 낭비하는 악플러들이다.
● 이는 네트워크의 오용이며, 비트코인은 금융 거래를 위해 설계되었고(백서, 이름, 코드가 이를 가리킨다), 데이터 저장은 예상된 용도가 아니다.
● 이는 「네트워크 혼잡」과 「높은 수수료 혹은 느린 처리 시간」을 초래하며, 일종의 「DDoS 공격」이다.
● 문제는 인스크립션이 아니라 높은 수수료다.
● 비트코인 네트워크는 즉각적으로 쓰레기 거래 공격으로부터 보호되어야 한다.
2. 「인스크립션 및 데이터 삽입은 네트워크에 피해를 준다」
이러한 유형의 거래는 노드 운영자의 비용을 증가시키며, 간접적으로 네트워크에 피해를 준다.
● 이 PR이 목표로 하는 거래는 일반적인 노드 운영자가 감당하기 어려운 중요한 비용 원천 중 하나다.
● 이러한 거래는 노드 운영 비용을 늘려 네트워크의 탈중앙화에 영향을 준다.
● 이는 블록체인 상에 부당하고 과도한 양의 데이터 저장을 초래한다.
3. 「금지는 사용자 요구 사항이다」
분명히 사용자들은 특정 용도와 니즈가 있으므로, Bitcoin Core는 이를 위한 옵션을 제공해야 한다. 그렇지 않으면 사람들이 직접 패치를 작성해 실행하게 되며, 이는 불안전할 수 있다.
● 노드 운영자들은 모든 형태의 현대적 데이터 운반을 무시할 수 있는 내장 옵션이 필요하다. 그래야 수동으로 노드를 수정할 필요가 없다.
● 개발자들이 노드 운영자가 이런 공격으로부터 스스로 보호하도록 돕지 않는다면, 운영자들은 방어를 강화하기 위해 부적절한 수단을 동원할 수 있다.
● 나는 내 메모리풀 정책을 통제하고, 어떤 거래가 쓰레기인지 아닌지를 내가 결정하고 싶다.
● 채굴자들이 비트코인을 단순한 허가 없는 불변 블록체인이 아니라 화폐라고 생각한다면, 화폐 네트워크의 활용성을 위해 쓰레기 거래를 필터링할 것이며, 따라서 이 기능을 원할 것이다.
4. 「이것은 datacarriersize를 정상 작동하게 하기 위한 수정일 뿐이다」
우리는 OP_RETURN 내 데이터 운반을 제한한다. 이것은 모든 형태의 거래 내 임의 데이터 삽입에 동일하게 적용되어야 한다. 이것이 바로 -datacarriersize의 「의도」였으며, 따라서 이것은 「버그 수정」이다.
● 루크-제이알은 segwit와 taproot 도입 이후 다른 형태의 데이터 운반을 포함하도록 -datacarriersize가 업데이트되지 않은 것을 버그로 간주하며, 이를 오류/결함으로 정의한다.
● Bitcoin Core는 83바이트를 초과하는 임의 데이터 및 인스크립션 삽입을 표준화했는데, 이는 기존 제한을 우회하는 변칙적인 방법이므로, 이는 버그 수정이다.
● 쓰레기 거래는 이미 코드의 여러 계층에서 필터링되어 왔으며, 10년 이상 그렇게 해왔다. 이 PR이 하는 일은 기존의 datacarriersize 제한을 다른 형태의 데이터 운반에도 적용하는 것뿐인데, 이는 명백히 예상 밖의 취약점이다.
● 거래 내 임의 데이터 저장에 제한을 두지 않는다면, 데이터 운반 제한의 목적은 무엇인가?
● 이 표준화 규칙의 목적은 단순히 원본 scriptPubKey 내 데이터에 국한되지 않고, 모든 형태의 임의 데이터를 포함하는 것이다.
「인스크립션 금지」에 반대하는 입장
1. 「이 조치는 인스크립션을 막지 못한다」
이 조치는 인스크립션을 막지 못한다. 인센티브 호환성이 없기 때문에, 채굴자(물론 인스크립션 사용자들도)가 이런 정책을 채택할 가능성은 낮아 보이며, 결과적으로 이러한 거래를 막는 효과는 거의 없다.
● Ocean 풀만 사용하고 여전히 상대적으로 작은 마이닝 풀이라면 아무런 효과도 없다. 광범위하게 배포되더라도 우회는 매우 쉽다.
● 장기적으로 채굴자들에게는 인센티브가 맞지 않는다.
● 채굴자들은 그 수익원을 쉽게 포기하지 않을 것이다. 이러한 거래를 검열하면 사설 메모리풀(private mempool) 발전을 오히려 부추길 것이다.
● 오디널 거래는 궁극적으로 메모리풀을 우회하여 블록체인에 들어가므로, 이 PR은 문제 해결이나 완화에 아무런 역할을 하지 못한다.
● 어느 정도 이는 단순히 이런 거래를 모니터링하지 않는 것을 넘어서 사용 자체를 막으려는 시도이며, 이는 최선의 경우 이런 거래가 해당 노드를 우회하거나, 최악의 경우 직접 채굴자에게 제출되는 관행으로 이어져 채굴 중심화에 심각한 위험을 초래할 수 있다.
● 인스크립션 애호가들은 소수의 노드가 인스크립션을 필터링하지 않도록 함으로써 네트워크 상에서 인스크립션의 전파를 유지할 수 있다.
● 명백히, 필터링된 메모리풀로부터 생성된 블록 템플릿의 총 블록 보상은 모든 미확정 거래로부터 생성된 것보다 반드시 낮아질 것이다. 이는 인스크립션을 필터링하는 채굴자가 자신의 수익을 줄임으로써 필터링하지 않는 채굴자에게 이득을 주게 됨을 의미한다.
2. 「모든 임베딩 데이터를 탐지하는 코드를 작성할 수 없다」
일반적으로 임의 데이터를 삽입한 거래를 완전히 막는 것은 불가능하다. 인스크립션은 다양한 데이터 삽입 방식으로 존재하며(완전히 막을 수 없음), 네트워크 자원 비용에 가장 적은 영향을 주는 가장 효율적인 방법만 유지하는 것이 낫다.
● 현재와 미래의 모든 데이터 운반 방식을
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@glozow
