223 / 736SHARE

Mining Share

채굴자는 풀에 자신의 작업을 어떻게 증명할까

페트르가 채굴기를 풀에 연결했습니다. 풀은 여러 채굴자의 작업을 모으는 서비스입니다. 화면에는 승인된 shares가 쌓이는데 지갑에는 아직 새 입금이 없습니다. 모순이 아닙니다. share는 먼저 작업을 증명하며, 보상 계산과 송금은 그다음 단계입니다. 실제 블록을 찾기까지 오래 걸릴 수 있으므로 이런 지속적인 증명이 없으면 풀은 각자의 기여를 평가하기 어렵습니다.

Mining Share는 특정 작업에 대해 풀이 정한 조건을 만족하는 채굴 계산 결과입니다. 풀은 검증할 수 있는 이런 표본으로 제공된 작업량을 추정합니다. 보통 유효한 Bitcoin 블록의 조건보다 쉬우므로 대부분의 shares는 새 블록이 아닙니다.

페트르의 기계는 엄청나게 많은 시도를 합니다. 풀은 매 시도마다 메시지를 받을 필요가 없습니다. 미리 정한 조건을 만족한 일부 결과만 받습니다. 이를 검증하고 빈도와 난이도로 작업량을 통계적으로 추정합니다. 따라서 Mining Share는 미완성 블록의 일부도, 양도 가능한 비트코인 지분도 아닙니다. 블록체인은 서로 연결된 블록으로 정리된 Bitcoin 거래의 공개 기록입니다. Mining Share는 여기에 기록되는 거래도 아닙니다. 채굴자가 풀에 계산 기여를 증명하는 방법입니다. [1]

채굴은 계산 결과를 숫자로 본 해시가 정해진 목표값 이하가 되도록 찾는 과정입니다. 풀은 보통 네트워크보다 수치상 더 높은 목표를 설정합니다. 더 많은 결과가 통과하므로 조건이 쉽습니다. 풀에는 충분한 결과가 대개 블록에는 부족합니다. 하지만 우연히 더 엄격한 네트워크 목표도 만족하는 결과가 나올 수 있습니다. 블록 전체가 나머지 규칙도 지키면 새 블록으로 이어질 수 있습니다. 풀이 Bitcoin 규칙을 완화하는 것이 아니라 지속적인 작업 증명을 위한 자체 기준을 정하는 것입니다. [1]

페트르가 메시지를 직접 만들지는 않습니다. 채굴 소프트웨어가 처리합니다. Stratum V2는 장비와 풀 사이의 통신 규칙을 정한 프로토콜입니다. SubmitSharesStandard에는 작업을 식별하는 job_id, 탐색 중 바꾸는 값인 nonce, 블록 헤더의 시각을 나타내는 ntime, 블록의 짧은 데이터 부분인 헤더의 버전을 뜻하는 version이 들어 있습니다. 통신 채널도 식별합니다. 풀은 계산을 검증하기 위해 이 맥락이 필요합니다. 올바른 작업에 연결되지 않은 nonce만으로는 독립적인 작업 증명이 되지 않습니다. [2]

페트르가 서로 다른 난이도의 작업을 맡은 기계들을 비교한다고 합시다. 여기서 난이도는 가중치 역할을 합니다. 더 엄격한 조건을 만족하는 결과는 더 많은 작업량으로 인정됩니다. 같은 기준으로 환산하면 난이도 1024인 승인 제출 두 건과 난이도 2048인 한 건의 총가중치는 같습니다. 메시지 수는 달라도 인정된 작업의 가중치는 같습니다. 그렇다고 그 합계가 실제 모든 계산을 정확히 기록한 것도 아닙니다. 개별 성공에는 무작위성이 있기 때문입니다. shares라는 카운터가 승인 결과의 건수인지, 환산된 작업 가중치인지 확인해야 합니다. [3]

풀은 여러 제출을 한 번에 승인하기도 합니다. Stratum V2에서는 SubmitShares.Success 응답을 씁니다. new_submits_accepted_count는 새로 확인된 제출 건수를 세고, new_shares_sum은 해당 작업들의 난이도를 합합니다. 앞의 값은 결과 수이고 뒤의 값은 가중치입니다. 둘 다 현재 확인하는 묶음의 값이지, 자동으로 채굴자의 전체 이력 합계가 되는 것은 아닙니다. 따라서 보낸 결과마다 별도 승인 응답이 올 것이라고 기대할 필요는 없습니다. [2]

페트르의 기계가 결과를 보냈다고 표시해도 풀은 아직 검증 중일 수 있습니다. Stratum V2는 잘못된 제출에 SubmitShares.Error를 사용하며, sequence_number가 오류에 해당하는 제출을 식별합니다. 즉시 검증할 수 없다면 오류 응답이 나중에 올 수도 있습니다. 따라서 전송한 결과와 승인 확인된 결과를 구분하고 거절도 살펴야 합니다. 로컬 전송 카운터가 올랐다는 사실만으로 풀이 전부 반영했다고 볼 수는 없습니다. [2]

확인된 작업은 해당 풀의 보상 규칙에 들어갑니다. 예를 들어 Braiins의 FPPS, Full Pay Per Share는 제출된 작업과 난이도 및 블록 보상 같은 네트워크 데이터로 보상을 계산하며, 거래 수수료에 해당하는 부분도 포함합니다. 풀은 자체 수수료를 공제하고 송금은 지급 설정에 따릅니다. share의 승인 자체가 지갑으로 BTC(비트코인)를 보내지는 않습니다. 그래서 페트르는 승인된 작업, 계산된 보상, 실제 지급을 따로 확인합니다. [4]

share 카운터는 다운로드 진행률처럼 보일 수 있지만 채굴은 그렇게 작동하지 않습니다. shares와 블록은 충분히 낮은 해시를 찾는 과정에서 무작위로 나옵니다. 증명된 작업이 많으면 계산 능력을 추정할 통계적 근거가 좋아질 뿐, 다음 성공이 보장되지는 않습니다. 승인된 shares가 길게 쌓여도 다음 시도에서 블록을 찾는다는 보장은 없습니다. 카운터는 진행 중인 작업과 승인을 보여주지, 블록의 마지막 조각만 남았다는 뜻이 아닙니다. [3]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Mining Pool, Share Difficulty, Proof of Work, Mining Target, Bitcoin. 다음 항목에서도 이 글을 참조합니다 ASIC Miner, Mining Pool, Braiins Pool, Stratum V1.

DOC · 001Bitcoin Developer Guide — Pool mining문서 DOC · 002Stratum V2 — Mining Protocol명세 DOC · 003Braiins Academy — Pool FAQ문서 DOC · 004Braiins Academy — Rewards and payouts문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다