Stale Rate

プールは採掘者に作業を割り振るサービスです。ネットワークで新しいブロックが見つかると、通常はその先に次のブロックを作り始めます。以前の作業条件で計算した結果は、新しい作業には使えません。採掘機の通信プロトコル 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 が収入を失ったかは分かりません。この方針をすべてのプールに当てはめることもできません。必要なのは、そのサービスの規則と実際の精算です。事業者を比べるときは、まず結果の分類を確かめ、その後で収入への影響を見積もります。 [2]

運用ログを読むとき、Stratum V2 では一つの SubmitShares.Success で複数の提出を確認できる点を見落としがちです。new_submits_accepted_count は新たに確認した提出数、new_shares_sum はそれらの難易度の合計を表します。したがって、サーバーの返信数は受理された shares の数ではありません。拒否時の SubmitShares.Error には、提出を識別する sequence_number と、理由を示す error_code が入ります。区別しなければ、Petra はすべてのエラーを遅延によるものと誤解しかねません。 [1]

新しいブロックの情報は、まず Bitcoin を検証するコンピューター間を伝わります。BIP152 が説明する Compact Block Relay は、直接つながった参加者からなる P2P ネットワークのノード間で、少ないデータでブロックを送る仕組みです。データ量の削減は転送の遅れを減らし得ます。しかし、これはブロックの伝播であり、プール内の shares の会計ではありません。主鎖に残らなかったブロックの割合を、Petra の機械から来る古い結果の割合として使うことはできません。 [4]

Braiins は shares_5m (直近5分)、shares_60m (直近60分)、shares_24h (直近24時間) という異なる期間の作業統計を提供しています。短い時間の古い結果を一日分の作業で割り、別の機械の一時間の統計と比べることはできません。計算の両側が同じ期間と同じ機器を対象にする必要があります。提出が一件も観測されなければ割合は未定義であり、損失を 0% と測定できたわけではありません。監視の空白や返信の欠落だけでも、結果が stale だったとは証明できません。 [5]

Petraは同じ期間の作業変更、拒否理由、接続状況から確認します。F2Poolはstaleの原因としてネットワークの状態を挙げています。別の拒否は、機械を制御するソフトウェアであるファームウェアの不具合や、過度なオーバークロックによって起きることがあります。オーバークロックとは、より多くの計算を行うためにチップの動作周波数を上げることです。Braiinsが案内するpingは、サーバーがネットワークからの確認要求に応答するかを調べる簡単なテストです。応答が返ってきても、採掘の正しさや報酬の計上が確認できたわけではありません。全体の割合が下がっただけでは原因の解消は証明できません。何が変わったのかを把握し、同等の条件で具体的なエラーを追うことが大切です。 [2] [6]