Share Difficulty

マイニングではハッシュという計算結果が生まれます。これは数値として読めます。プールに受理されるには、結果が設定されたターゲット以下でなければなりません。ターゲットが低いほど、その範囲に入る結果が減り、条件は厳しくなります。したがって数値のターゲットが下がると Share Difficulty は上がります。通信の仕組みに関心がある人向けに補足すると、プールとの通信規則である Stratum V2 は、SetTarget メッセージの target フィールドで上限を伝えます。形式を知らなくても、数値の上限が低いほどマイナーにとって難しい、という関係は理解できます。 [1]

プールがペトラの難易度を 1024 から 2048 に上げたとします。計算速度と換算方法が同じなら、同じ時間内に条件を満たす結果は平均でおよそ半分になります。機器は同じ速度で試行を続けますが、厳しくなった条件を通過する結果が減るのです。個々の結果の間隔は依然としてランダムです。次の share が毎回きっかり倍の時間で見つかるわけではありません。 [2]

メッセージの数だけを数えると、異なるものを同列に比較してしまいます。そこで Braiins は、難易度に応じて換算した作業単位で集計を説明しています。難易度 1024 の結果が二つ受理された場合、その合計の重みは難易度 2048 の結果一つと同じです。メッセージが少なくても、貢献が小さい証拠にはなりません。また、この集計上の重みは機器が実行した計算回数の正確な記録ではなく、統計的な作業の証明です。実際の報酬額はプールのルールにも左右されます。 [3]

Share Difficulty の変更だけで、マイニング機器の専用チップである ASIC が速くなることはありません。Bitcoin ブロックに必要なネットワークのターゲットも変わりません。独立した試行の回数とネットワーク難易度が同じなら、ブロック発見の確率は同じです。プールは途中で受け取りたい結果の条件を変えているだけです。share の難易度を下げても、Bitcoin ブロックを作りやすくなるわけではありません。 [3]

低速な機器と高速な機器に同じ設定を使うと、送信される結果の数に大きな差が出ます。難易度の自動調整である VarDiff は、この差をならし、不要な通信を減らします。Braiins では最小値を設定することもできます。ただし、それは下限であって固定の割り当て値ではありません。プールは計算速度に応じて、さらに高い難易度を選べます。ペトラは設定と現在の表示を比べる際、最小値を見ているのか、実際の割り当て難易度を見ているのか、まず確認する必要があります。 [2]

ソフトウェアは、変更がどの作業に適用されるかを把握する必要があります。現在の Stratum V2 仕様では、SetTarget はその後に受信したジョブと、受信済みでも ntime_start が空の将来のジョブに適用されます。空であることは、ブロックヘッダーに入れる初期タイムスタンプがまだ決まらず、ジョブが有効化を待っていることを意味します。ブロックヘッダーは、そのブロックの情報を要約した短いデータ部分です。すでに受信し、ntime_start が設定されたジョブのターゲットは維持されます。そのため拒否の原因を調べる際は、最新の上限との比較だけでなく、結果を正しいジョブに対応させる必要があります。通常はマイニングソフトが処理します。 [1]

ペトラは best share という表示にも出会うかもしれません。例えば Braiins Solo は、マイニングのセッション中に見つかった最も難易度の高い share をこう呼びます。割り当て難易度は送信に十分な条件を示し、best share は実際に見つかった結果の珍しさを示します。記録はブロックへ向けて蓄積された進捗ではありません。非常に良い結果でも、次の独立した試行の成功確率は上がりません。 [4]

手動の最小値を高くしすぎると、結果の送信がまばらになり、推定される計算速度が大きく揺れることがあります。ASIC が動いていても、監視システムが警告を出す場合があります。短時間 share がないだけでは故障の証拠になりません。ペトラは割り当て難易度、観測期間、受理された作業、接続状態を見比べます。それらを合わせて初めて、普通の偶然による変動と実際の問題を見分けやすくなります。 [2]