Mining Share

彼得的矿机会进行海量尝试。矿池不需要每次尝试都收到消息，只接收满足预定条件的部分结果。矿池验证它们，并根据出现频率和难度，从统计上估算工作量。因此，Mining Share 不是尚未完成的区块的一部分，也不是可以转让的比特币份额，更不是写入区块链的一笔交易。区块链是比特币交易的公开历史记录，按相互连接的区块排列。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]