Pay Per Last N Shares

扬把矿机连接到 Mining Pool，也就是协调矿工工作的矿池。采用 PPLNS 时，矿池并不承诺为每个认可的结果支付固定价格，而是在找到区块后，依据近期工作记录分配奖励。可以把这份记录想象成不断移动的名单：新结果加入，最旧的结果逐渐移出。找到区块不会清空名单。同一份工作因此可能分享多个区块的奖励，也可能在任何带来奖励的区块出现前就已移出。 [1]

矿机持续提交的工作凭证叫 shares。这里的哈希值是根据候选区块的数据计算出的一个数。网络要求它不大于规定的目标值，因此矿工不断改变数据并重新计算。它们符合矿池较宽松的条件，但通常不足以构成新的比特币区块。N 表示所考察的工作窗口大小。在最简单的模型中，它指整个矿池最近 N 份难度相同的 shares，而不是最近 N 个人。如果 share 难度不同，工作量就必须相应加权。窗口也不代表固定的小时数：它的时长取决于后续工作到来的速度。 [1]

假设一个完整窗口中有 1000 份权重相同的 shares，其中 100 份属于扬。矿池刚找到区块，扣除自身费用后有 3 BTC 可供分配。扬在这个例子中的份额是 100 / 1000 × 3 = 0.3 BTC。扬贡献了计入本次分配的工作量的十分之一，因此分到的也是这笔奖励的十分之一。这些数字仅用于说明：3 BTC 不是在陈述区块补贴金额，也就是每个区块新发行的比特币数量；0.3 BTC 也不是承诺的每日收入。找到下一个区块时，窗口内的结果可能已不同，可分配金额也可能变化。 [1]

扬断开矿机进行维护。在正确实现的 PPLNS 中，这不会抹掉已被认可的工作。它仍留在窗口内，有机会参与之后的区块奖励，直到被更新的工作挤出。即使扬继续挖矿，旧工作也会以同样的方式退出；区别只是他还会不断添加新结果。重新连接后，他在窗口中的份额逐渐累积起来。间歇运行可能带来更大波动，但这本身并不是对离开矿池的自动惩罚。 [1]

PPLNS 分配真实出块的成果，所以矿池顺利出块的一天与毫无发现的一天不同。矿池如何计入比特币用户支付的交易费，也会影响结果。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]