Stale Rate는 오래되어 유효하지 않은 것으로 분류된 결과 또는 가중 작업량의 비율입니다. Bitcoin 풀 채굴에서는 보통 현재 작업에 맞지 않게 된 부분적인 계산 증명인 shares를 뜻합니다. 정확한 정의와 보상에 미치는 영향은 측정하는 시스템에 따라 다릅니다.
풀은 채굴자들에게 작업을 나누어 주는 서비스입니다. 네트워크에서 새 블록을 찾으면 보통 그 블록 위에 다음 블록을 쌓기 시작해야 합니다. 이전 작업을 바탕으로 계산한 결과는 새 작업에 맞지 않습니다. 채굴기 통신 프로토콜 Stratum V2는 SetNewPrevHash로 이 전환을 처리합니다. 기기는 새로 지정된 블록에 이어질 블록을 찾기 시작합니다. 미리 준비한 작업 중 작업 식별자인 job_id가 가리키는 것만 유효하게 남습니다. 따라서 Petra는 전송 시각만 볼 것이 아니라 당시 작업이 유효했는지도 확인합니다. [1]
간단한 예로 Petra가 난이도가 같은 결과 100개를 제출했다고 합시다. 풀은 98개를 승인하고, 1개는 stale로, 1개는 다른 이유로 거절합니다. 거절된 stale 결과는 1%, 모든 거절을 합하면 2%입니다. F2Pool은 전체 제출 중 전체 거절의 비율을 rejection rate라고 부릅니다. 이 예에서 stale은 그 일부일 뿐입니다. 이 숫자는 계산을 설명하기 위한 것이지 허용할 만한 운영 기준이 아닙니다. 분류 방식이 다르면 화면의 지표도 다른 뜻일 수 있습니다. [2]
Share 난이도는 기기가 얼마나 까다로운 조건의 결과를 제출해야 하는지 정합니다. Braiins는 난이도 d인 결과를 기본 작업 단위 d개로 계산합니다. 난이도 1인 stale share 하나와 난이도 9인 승인된 share 하나를 생각해 봅시다. 제출 횟수로는 50%지만, 작업 가중치로는 10%입니다. 어느 계산도 그 자체로 틀리지는 않지만 서로 다른 질문에 답합니다. Petra는 비교할 때 분자와 분모의 단위를 맞추고 난이도 산정 기준도 같은지 확인합니다. [3]
F2Pool 문서는 보상이 발생하는 Staled 분류와 보상이 없는 거절된 stale shares를 구분합니다. 따라서 표시된 이름만으로 Petra가 돈을 잃었는지는 알 수 없습니다. 이 정책을 모든 풀에 적용할 수도 없습니다. 해당 서비스의 규칙과 실제 정산이 중요합니다. Petra는 제공자를 비교하기 전에 결과가 어느 분류에 속하는지 먼저 확인합니다. 그다음에야 수입에 미치는 영향을 추정할 수 있습니다. [2]
운영 로그를 읽다 보면 Stratum V2가 SubmitShares.Success 메시지 하나로 여러 제출을 확인할 수 있다는 점을 놓치기 쉽습니다. new_submits_accepted_count는 새로 확인한 제출 수를, new_shares_sum은 그 난이도 합계를 나타냅니다. 따라서 서버 응답 수가 승인된 shares 수와 같지는 않습니다. 거절 시 SubmitShares.Error에는 제출 식별자인 sequence_number와 오류 이유인 error_code가 들어 있습니다. 이를 구별하지 않으면 Petra는 모든 오류를 늦게 도착한 작업으로 오해할 수 있습니다. [1]
새 블록 소식은 먼저 Bitcoin을 검증하는 컴퓨터들 사이로 퍼져야 합니다. BIP152는 직접 연결된 참여자들로 이루어진 P2P 네트워크에서 노드 간 블록 전송량을 줄이는 Compact Block Relay를 설명합니다. 데이터가 줄면 전송 지연도 줄어들 수 있습니다. 그러나 이는 블록 전파에 관한 것이며 풀의 shares 정산 방식이 아닙니다. 주 체인에 남지 않은 블록의 비율을 Petra 채굴기의 늦은 결과 비율로 사용할 수는 없습니다. [4]
Braiins는 기간별 작업 통계인 shares_5m (최근 5분), shares_60m (최근 60분), shares_24h (최근 24시간)를 제공합니다. Petra가 짧은 구간의 늦은 결과를 하루 전체 작업으로 나눈 뒤 다른 채굴기의 한 시간 통계와 비교해서는 안 됩니다. 계산의 양쪽은 같은 기간과 같은 기기를 대상으로 해야 합니다. 제출을 전혀 관측하지 못했다면 비율은 정의되지 않습니다. 손실을 0%로 측정했다는 뜻이 아닙니다. 모니터링 공백이나 응답 누락만으로 결과가 stale이었다고 증명할 수도 없습니다. [5]
Petra는 같은 기간의 작업 변경, 거절 이유, 연결 상태부터 살펴봅니다. F2Pool은 stale 결과를 네트워크 조건과 연결해 설명합니다. 다른 거절은 기기를 제어하는 소프트웨어인 펌웨어의 오류나 과도한 오버클록 때문에 발생할 수 있습니다. 오버클록은 더 많은 계산을 시도하기 위해 칩의 동작 주파수를 높이는 것입니다. Braiins가 권하는 ping은 서버가 네트워크 확인 요청에 응답하는지 알아보는 간단한 테스트입니다. 응답을 받았다고 해서 채굴 계산이나 보상 적립의 정확성까지 확인된 것은 아닙니다. 전체 비율이 낮아졌다는 사실만으로 원인이 해결됐다고 볼 수 없습니다. 무엇이 달라졌는지 이해하고 비교 가능한 조건에서 구체적인 오류를 추적해야 합니다. [2] [6]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Mining Share, Share Difficulty, Mining Latency, Pool Fee, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Stale Block, Mining Latency.