Stale Rate

SetNewPrevHash를 받으면 Stratum V2는 새 이전 블록 해시로 전환하도록 요구하며 준비된 작업 중 지정된 job_id만 유효하게 남습니다. 이전 목표보다 낮은 해시를 찾았다는 사실만으로 현재 작업에 쓸 수 있다는 보장은 없습니다. 진단에는 제출 시각뿐 아니라 작업 맥락과 변경도 필요합니다. [Stratum V2 — Mining Protocol]

예를 들어 같은 난이도의 제출 100개 중 98개가 승인되고 1개는 stale, 1개는 다른 이유로 거절되었다면, 거절된 stale 비율은 1%, 전체 rejection rate는 2%입니다. 서로 다른 분자를 설명하는 예시이지 허용 운영 기준이 아닙니다. F2Pool는 모든 제출 shares를 기준으로 rejection rate를 정의합니다. [F2Pool — Rejection and Staled rates]

Braiins는 난이도 d의 share를 d개의 기본 작업 단위로 환산합니다. 난이도 1인 stale share 하나와 난이도 9인 승인 share 하나의 예에서는 개수 비율이 50%지만 가중 비율은 10%입니다. 비교하는 분자와 분모는 같은 단위와 난이도 관례를 사용해야 합니다. [Braiins — Share difficulty accounting]

F2Pool 문서는 보상이 있는 “Staled” shares와 보상이 없는 거절된 stale shares를 구분합니다. 이 정책을 모든 풀에 일반화할 수 없습니다. 백분율을 손실 수입으로 바꾸기 전에 실제 분류, 승인 규칙, 정산을 확인해야 하며 지표 이름만으로는 부족합니다. [F2Pool — Rejection and Staled rates]

Stratum V2는 일괄 SubmitShares.Success를 허용합니다. new_submits_accepted_count는 새로 확인한 제출 수이고 new_shares_sum은 그 난이도 합입니다. 서버 응답 수가 승인 shares 수와 같지는 않습니다. SubmitShares.Error에는 sequence_number와 error_code가 있으며, 이유를 구분하지 않고 모든 오류를 stale라 할 수 없습니다. [Stratum V2 — Mining Protocol]

BIP152는 P2P 노드 사이의 Compact Block Relay를 다루며 풀의 shares 회계는 다루지 않습니다. 전송 데이터 감소는 블록 도착 지연에 영향을 줄 수 있지만 그것만으로 채굴자의 Stale Rate가 나오지는 않습니다. 네트워크의 경쟁 블록 비율을 특정 worker의 늦은 제출 비율로 대체할 수 없습니다. [BIP152 — Compact Block Relay]

Braiins 모니터링은 shares_5m, shares_60m, shares_24h를 구분합니다. 자체 비율의 분자와 분모에 같은 시간 범위와 worker 집합을 사용해야 합니다. 관측 제출이 0개라고 손실 0%를 측정한 것은 아니며 비율은 정의되지 않습니다. 누락 응답이나 모니터링 공백도 자동으로 stale가 되지 않습니다. [Braiins — Worker monitoring windows]

F2Pool는 stale를 네트워크 상태와 연결하지만 다른 거절에는 펌웨어 오류와 오버클록을 언급합니다. Braiins는 서버 도달성 검사와 실제 성능을 구분합니다. 같은 기간의 작업 로그, 거절 이유, 연결을 살펴야 합니다. ping이나 낮아진 종합 백분율만으로 원인 제거가 입증되지는 않습니다. [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]