블록 템플릿과 Stratum V2

호기심

1. 전용 하드웨어를 갖춘 채굴자도 왜 블록에 어떤 트랜잭션이 포함될지 결정하는 것을 풀 운영자에게 의존해야 할까요?
2. 풀에 참여한 채굴자가 풀의 보상을 함께 받으면서도 자신의 블록에 들어갈 트랜잭션을 직접 선택할 수 있게 해 주는 것은 무엇일까요?
3. JSON에서 바이너리 프로토콜로의 전환은 고속 채굴 환경에서 보안과 효율을 어떻게 함께 개선할까요?

탐구

1. 프로토콜이 처음 생겨난 이래 모든 유효한 블록에는 트랜잭션 선택이 필요합니다. 초창기에는 풀노드를 운영하는 채굴자들이 이를 직접 선택했습니다. 2012년에 이르러 하드웨어가 특화되고 비싸지자 대부분의 채굴자가 풀에 합류했습니다. 같은 해 Slush가 도입한 Stratum 프로토콜은 풀 서버가 구성원에게 작업을 배분하는 방식을 표준화했습니다. 풀은 2010년부터 블록을 구성해 왔으며, Stratum은 이 방식을 훨씬 효율적으로 만들었고 블록 구성의 중앙화도 그대로 물려받았습니다.
2. Stratum V1에서는 풀 운영자가 각 후보 블록의 유일한 설계자 역할을 합니다. 서버는 자체 멤풀에서 트랜잭션을 모은 뒤 채굴자에게 작업의 구성 요소를 보냅니다. 코인베이스 트랜잭션의 두 부분, 머클 브랜치, 이전 블록 해시, 타깃, 시간입니다. 채굴자는 자신의 엑스트라 논스(extra-nonce)를 넣어 머클 루트를 계산하고 유효한 해시를 탐색하지만, 어떤 트랜잭션을 포함할지에 대해서는 아무런 결정권이 없습니다.
3. 이러한 구조는 풀 운영자에게 트랜잭션 선택에 관한 상당한 권한을 부여합니다. 네트워크 해시레이트의 상당 부분을 차지하는 풀은 특정 트랜잭션을 템플릿에서 빼기만 해도 사실상 검열할 수 있습니다. 실제로 이런 권한이 행사되는 일은 드물지만, 구조적으로는 그럴 능력이 존재합니다. 또한 풀 서버가 다운되거나 서비스 거부(DoS) 공격을 받으면 연결된 모든 채굴자가 유휴 상태가 되므로, 이들의 수익에 단일 장애 지점이 생깁니다.
4. 2012년 BIP22와 BIP23은 `getblocktemplate`을 도입했습니다. 이를 통해 채굴 소프트웨어가 노드에 완전한 블록 템플릿을 요청할 수 있게 되었으며, 풀 구성원이 직접 블록을 구성할 수 있도록 설계되었습니다. 풀들은 내부적으로 getblocktemplate을 사용해 자체 노드에서 템플릿을 가져오지만, 구성원이 직접 블록을 구성하게 하면 검증과 셰어 집계가 복잡해지기 때문에 이를 제공하는 풀은 거의 없었습니다(Eligius는 예외였습니다).
5. 2019년부터 Braiins와 Matt Corallo 등이 개발한 Stratum V2는 이러한 문제를 해결하기 위해 프로토콜을 재설계했습니다. 오버헤드를 줄이는 바이너리 형식과 보안을 위한 암호화를 도입했습니다. 무엇보다 중요한 것은 작업 선언 프로토콜(Job Declaration Protocol)이 포함되었다는 점입니다. 이를 통해 자체 풀노드를 운영하는 채굴자는 자신의 블록 템플릿을 풀 서버에 선언할 수 있습니다. 풀은 이 맞춤형 작업에서 나온 셰어를 받아들여 표준 방식대로 보상을 나누고, 채굴자는 트랜잭션 포함 여부에 대한 통제권을 유지합니다.
6. Ocean의 DATUM 프로토콜(2024)과 같은 대안적인 노력들도 템플릿 생성을 분산화한다는 유사한 목표를 추구합니다. Stratum V2 사양의 Job Declaration 섹션을 읽어보고, 자신이 알고 있는 풀이 어떻게 템플릿을 구축하는지와 비교해 보세요. 이러한 프로토콜들이 도입되면 거래 선택권은 다시 하드웨어 소유자에게로 돌아갑니다.

핵심 사실

연습 아홉, 여섯, 셋, 하나

팩트 체크

날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.

• BIP22: getblocktemplate – Fundamentals (2012)
• BIP23: getblocktemplate – Pooled Mining (2012)
• Stratum V2 Specification (stratumprotocol.org, from 2019)
• OCEAN mining pool, DATUM protocol documentation (2024)