Stratum V1

에바는 Bitcoin 채굴 전용 장비인 ASIC을 켜고 풀에 연결했습니다. 풀은 다음 블록을 찾는 채굴자들의 작업을 조율합니다. 블록은 Bitcoin의 기록에 추가할 여러 거래를 묶은 것입니다. 하지만 연산 능력만으로는 충분하지 않습니다. 장비에는 작업 지시가 필요하고 풀은 에바가 기여한 일을 알아야 합니다. Stratum V1이 이 대화를 맡습니다. 풀은 다음 블록을 찾기 위한 작업을 보내고, 장비는 계산한 뒤 중간 결과를 돌려줍니다. 전화 통화의 언어처럼 양쪽이 서로 이해하게 해 주는 규칙입니다. 일의 가격까지 정하지는 않습니다. 보상은 풀의 별도 지급 규칙에 따르고, 발견한 블록이 유효한지는 Bitcoin 노드가 확인합니다. [4] [2]

채굴 장비가 빨라질수록 예전 getwork 방식은 불편해졌습니다. 한 번에 주는 작업량이 적어 장비가 자주 다음 작업을 요청해야 했기 때문입니다. Marek Palatinus는 2012년 9월 11일 새 방안을 발표했습니다. Stratum은 연결을 열어 두므로 풀은 다음 요청을 기다리지 않고 변경된 작업을 보낼 수 있습니다. 그만큼 통신 부담이 줄어듭니다. 채굴의 모든 부분을 대체하는 것은 아닙니다. 풀은 여전히 BIP 22에 설명된 getblocktemplate로 Bitcoin 노드에서 후보 블록을 받을 수 있습니다. [11] [3] [5]

장비의 제어 소프트웨어는 보통 mining.subscribe를 먼저 보내 작업 수신을 요청합니다. 연결 정보와 자신의 계산을 구별할 정보가 돌아옵니다. 이어 mining.authorize가 장비를 계정에 연결합니다. 여기서 worker는 직원이 아니라 장비나 연결의 식별자입니다. 에바는 같은 계정의 여러 장비를 구별할 수 있습니다. 이 메시지에 포함된 비밀번호만으로 서버가 진짜인지 인증하거나 통신을 암호화할 수는 없습니다. 로그인 성공이 안전한 연결을 입증하지는 않는 이유입니다. [2] [13]

mining.notify는 job_id로 구별하는 새 작업을 전달합니다. 이전 블록 참조, 거래 관련 데이터, 시각과 다른 블록 헤더 정보가 들어 있습니다. 헤더는 해당 블록에 관한 정보를 간결하게 모은 데이터입니다. clean_jobs라는 표시가 중요합니다. true면 이전 작업을 버려야 하고, false면 새 작업으로 전환하는 동안 앞선 작업을 계속할 수 있습니다. 따라서 새 메시지가 왔다고 진행 중인 모든 결과가 자동으로 무효가 되는 것은 아닙니다. 전달된 작업도 아직 계산할 후보일 뿐, 이미 유효한 블록은 아닙니다. [2] [13]

이 부분은 기술 설명입니다. 일반적인 연결에 모든 필드의 지식이 필요한 것은 아닙니다. 풀은 블록 보상을 지급하는 coinbase 거래를 두 조각으로 전달합니다. 같은 이름의 거래소와는 다릅니다. 소프트웨어는 그 사이에 풀이 배정한 extranonce1과 자신의 extranonce2를 넣어 더 많은 작업 변형을 만듭니다. 이 거래와 전달받은 Merkle branches, 즉 거래들을 나무 구조로 요약한 중간값으로 Merkle root를 계산합니다. 여기에 이전 블록 참조, 버전, 시각, 인코딩된 hash 상한값을 합쳐 80바이트 헤더의 기초를 만듭니다. ASIC은 추가 시도에 쓰이는 숫자 nonce를 바꾸며 헤더의 숫자 지문인 hash를 반복 계산합니다. [2] [4] [13] [14]

완전한 블록을 찾는 일은 드뭅니다. 그래서 풀은 더 쉽게 만족할 수 있는 결과 기준인 target을 정합니다. 이를 만족하는 결과가 mining share이며, 수행한 작업의 증거입니다. 대부분의 shares는 Bitcoin 네트워크의 더 엄격한 기준에 못 미칩니다. 가끔 양쪽 기준을 충족하면 유효한 블록으로 이어질 수 있습니다. mining.set_difficulty와 자동 조정인 vardiff는 결과가 너무 자주 또는 드물게 오지 않도록 shares의 난이도를 바꿉니다. 네트워크 난이도는 바꾸지 않습니다. 더 어려운 조건을 충족하려면 평균적으로 더 많은 계산이 필요하므로, 그런 결과는 작업량을 평가할 때 더 큰 가중치를 갖습니다. 더 어려운 shares의 수가 적다고 보상이 반드시 적어지는 것은 아닙니다. 각 결과의 가중치와 풀의 지급 규칙도 중요합니다. [2] [4] [13]

장비는 mining.submit으로 worker 식별자, job_id, extranonce2, nTime(헤더의 시각), nonce를 보냅니다. 풀은 결과를 재구성해 검사합니다. duplicate는 같은 작업의 중복 제출, low difficulty는 기준 미달, stale은 더 이상 받지 않는 작업을 뜻합니다. 에바는 장비 속도뿐 아니라 거절된 결과의 비율과 연결 지연도 살펴야 합니다. share가 받아들여졌어도 아직 지갑으로 지급된 것은 아닙니다. Stratum은 작업을 전달하고, 보상의 적립과 지급에는 별도 규칙이 적용됩니다. [2] [13]

2018년의 BIP 310은 mining.configure로 추가 기능을 협상하는 방법을 설명합니다. 2026년 10월 17일 확인한 문서는 여전히 초안을 뜻하는 Draft 상태였습니다. Version-rolling은 헤더 버전 중 합의한 비트만 바꾸게 합니다. 협상 후에는 mining.submit에 여섯 번째 필드가 추가됩니다. Bitcoin 규칙을 마음대로 바꿀 권한은 아닙니다. minimum-difficulty와 subscribe-extranonce는 요청하는 최소 share 난이도와 새로운 extranonce 값 알림에 관한 기능입니다. 기능 협상은 프로그램 사이의 오해를 막지만 그 자체로 암호화하지는 않습니다. [6]

V1은 흔히 암호화하지 않은 TCP 연결을 사용합니다. 추가 보호가 없으면 전송 경로에 있는 누군가가 메시지를 읽거나 바꾸고 채굴 작업을 다른 곳으로 돌리려 할 수 있습니다. 2017년 연구 Hardening Stratum은 이런 위험을 실제로 분석했습니다. 장비와 풀 사이 연결의 문제이지 Bitcoin 자체를 깨뜨리는 것은 아닙니다. 일반적인 구성에서는 블록에 넣을 거래도 풀이 고릅니다. 에바가 장비를 소유했다고 그 내용까지 결정하는 것은 아닙니다. 큰 풀이 만든 블록이어도 규칙을 위반하면 Bitcoin 노드는 거부합니다. [7] [4]

Stratum V2는 더 간결한 바이너리 메시지와 암호 기술로 보호된 연결을 제공합니다. 별도의 Job Declaration 구성 요소를 양쪽이 지원하고 사용하면 채굴자가 자신이 고른 거래를 제안할 수 있습니다. V1/V2 변환기나 V2 표시만으로 그 기능의 사용을 입증하지는 못합니다. 에바는 펌웨어 지원, 올바른 서버 주소, 연결 보호, 거절된 결과, 예비 연결을 확인해야 합니다. V1의 핵심은 단순합니다. 작업을 전달하고 계산을 입증하며, 이를 블록 내용 선택이나 보상 지급과 구분하는 것입니다. [8] [12] [10]