Mining Share

ペトルの機器は膨大な回数の試行を行います。プールにはすべての試行の通知は不要で、決められた条件を満たす結果だけが送られます。それを検証し、頻度と難易度から統計的に仕事量を見積もります。したがって 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]