Pay Per Last N Shares

ヤンは採掘機をMining Poolにつなぎます。これはマイナーの作業を調整するサービスです。PPLNSでは、受理した結果一つひとつに固定価格を約束しません。ブロックを見つけたとき、直近の作業記録を使って報酬を分けます。新しい結果が入り、最も古い結果が順に抜けていく一覧を想像すると分かりやすいでしょう。ブロック発見で一覧が消えることはありません。同じ作業が複数の報酬に参加する場合もあれば、報酬を生むブロックが見つかる前に一覧から抜ける場合もあります。 [1]

機械が継続的な作業の証拠として送る結果をsharesと呼びます。ここでいうハッシュは、提案するブロックのデータから計算した数値です。ネットワークが定める目標値以下になる必要があるため、マイナーはデータを変えながら計算を繰り返します。プールの緩やかな条件は満たしていても、通常は新しいBitcoinブロックには届きません。Nは集計対象となる作業の範囲を表します。最も単純なモデルでは、プール全体の直近N個の同じ難易度のshareを指し、直近N人ではありません。難易度が異なるなら、作業を相応に重み付けする必要があります。集計範囲は固定の時間数でもなく、次の作業が届く速さによって対象期間が変わります。 [1]

同じ重みのshareが1000個入った集計範囲を考え、そのうち100個をヤンのものとします。プールはちょうどブロックを発見し、自分の取り分を引いた後に3 BTCを分配できます。この例でヤンの取り分は100 / 1000 × 3 = 0.3 BTCです。ヤンの作業は集計対象の十分の一なので、分配する報酬も十分の一になります。あくまで説明用の数字であり、3 BTCはブロック補助金、つまりブロックごとに新たに発行されるビットコインの額を示しているわけではなく、0.3 BTCは毎日の収入の約束でもありません。次の発見時には集計範囲内の結果も、分配できる金額も変わり得ます。 [1]

ヤンが整備のため採掘機を切断しても、正しく実装されたPPLNSでは受理済みの作業は消えません。新しい作業に押し出されるまで集計範囲に残り、その後のブロック報酬にも参加できます。ヤンが採掘を続けても、新しい作業に押し出される仕組みは同じです。違いは、自分の新しい結果も集計範囲に加わることです。再接続すれば集計範囲内の持ち分が徐々に積み上がります。断続的な稼働は変動を大きくすることがありますが、離脱そのものへの自動的な罰金ではありません。 [1]

PPLNSは実際に見つけたブロックの成果を分けるため、好調な日と発見のない日とでは結果が異なります。Bitcoin利用者が払う取引手数料をどう含めるかも重要です。F2Poolはこの変動を明示しています。一方、Full Pay Per Share (FPPS)はブロック補助金と取引手数料を含む推定値で受理済み作業を評価し、Pay Per Share Plus (PPS+)は手数料部分だけにPPLNSを使う場合があります。サービスの手数料率だけでは、どちらがヤンに良い結果をもたらすか分かりません。その率をどの金額に適用するのかも必要です。 [2] [3]

計算された取り分、口座残高、自分のウォレットでの受領は別々の段階です。ヤンはブロックが認められたか、取り分がどう計算されたか、最低額と日程に従っていつ出金できるかを確認します。報酬方式の切り替えも即時とは限りません。例えばF2Poolは独自の適用時刻を公開しています。公平に比較するには、変更前の作業と、その作業が集計範囲に残っている間に生じ得る後日の報酬も含めます。PPLNSはプールの不払いリスクも電気代も機器費用も取り除きません。 [3] [4]

集計範囲が広いと、作業が分配対象に残る期間も長くなり、将来のより多くのブロック発見に報酬の機会が分散します。狭すぎる集計範囲から生じる変動の一部を和らげる効果がありますが、小さなプールが定期的にブロックを見つけるようになるわけではありません。その代わり、過去の作業の最終結果が分かるまで長く待ちます。管理画面の期待報酬も、将来の発見についての推定であり、すぐ出金できる固定の約束額ではありません。 [1]

PPLNSには、報酬分配の有利な局面だけを狙ってプールを渡り歩くpool-hoppingを抑える目的があります。ブロック発見をまたぐ集計範囲は、新しいラウンドの開始直後に入るという単純な優位性をなくします。ただし、数学的な公平性は方式の詳細次第です。Meni Rosenfeldは単純な固定Nと、より洗練されたunit-PPLNSを区別しています。Unit-PPLNSは、各shareの提出時点のネットワーク難易度とブロック報酬に基づく情報を記録します。後の支払いに、作業を行った時点の条件を反映できる仕組みです。素朴な規則はネットワーク難易度やブロック価値が変わる際に利用され得ます。運営者はパラメータ変更時に、受理済み作業の期待価値を保つべきです。サービス名だけでは、その計算が実際にこれを行っている証明にはなりません。 [1]