この記事の内容はマイナーの皆さんの知識としては必要ありませんが興味があったら読んでみてください。
マイニングプールは24時間稼働でデータのやり取りをしています。全部ではありませんが主要なデータの流れをまとめてみました。こう見ると殆どのやり取りはブロックチェーンとは関係無いのが良く分かります。この投稿はphp-mposと呼ばれるオープンソースに関するものなので、nomp等他のものとは処理が異なりますのでご注意ください。
フロー概略
- minerd は stratum から与えられた difficulty を満たす成果を演算し、stratum に送る
- stratum は受け取った成果をsharesテーブルにインサートする、ブロックを見つけた場合は coind 経由で報告して同レコードの情報を書き換える
- php-mpos は findblockバッチ でプールが発見したブロックを拾い上げてblocksテーブルにインサートする
- php-mpos は xxx_payoutバッチ でアカウント毎のシェアに応じた報酬をtransactionテーブルにインサートし、sharesテーブルからshares_archiveテーブルに移動させる
- php-mpos は payoutsバッチ でアカウント後の有効なtransactionレコードから出金処理を行う
- php-mpos は tables_cleanupバッチ でshares_archiveテーブルの古いデータを削除する
フロー詳細
minerd から stratum に成果を送る
stratumプロトコルで言うところのsubmitイベントの部分です。
mining\interfaces.py ShareManagerInterface::on_submit_share() でシェアデータをキューに溜め込む、DB_LOADER_FORCE_TIME（デフォルト300秒）ごとにキューからsharesテーブルにインサート、コミットは最大DB_LOADER_REC_MAX（デフォルト50件）まとめて行う
mining\interfaces.py ShareManagerInterface::on_submit_block() でキューからsharesテーブルに全件強制インサート、発見者のレコードのupstream_resultカラムを'Y'に更新
気になるのはキューの部分、これはメモリ上に保持されると思われるのでstratumを再起動するとシェアがクリアされるっぽいですね。なのでstratumを落とす際は設定値にもよりますが最大で300秒程度の成果は失われるという事を管理側は知っていた方が良いですね。（DB負荷が気にならないのであれば細かくコミットさせるのが良いでしょう）
php-mposのfindblockバッチ
cronjobs\findblock.php で $bitcoin->listsinceblock($strLastBlockHash); からウォレットに影響を与えたブロックを取得し、blocksテーブルにインサート。
発見者の情報やラウンドの総シェア数などセットする。またconfigでblock_bonusを設定している場合は発見者のアカウントIDに対して発見したブロックIDを付けたレコードをtransactionテーブルにインサートしている。
php-mposのxxx_payoutバッチ（proportionalの場合で書いてます）
cronjobs\proportional_payout.php で未処理のブロックがあったらシェアの割合で type=Credit として、プール手数料は Fee、寄付は Donation として transactionテーブルにインサート。
※この時、報酬を生み出したブロックIDも合わせて記録される
include\classes\share.class.php Share::moveArchive() で処理済みのshareをshares_archiveにインサート、後に Share::deleteAccountedShares() で物理削除。
php-mposのpayoutsバッチ（手動出金、自動出金）
※手動出金の場合は画面から指示を出す事でpayoutsテーブルにレコードが存在している前提
cronjobs\payouts.php で有効な出金依頼データを出して手動なら type=Debit_MP、自動なら Debit_AP として、送金手数料は TXFee として transactionテーブルにインサート。
更にDebit_MPまたはDebit_APのレコードid(=txid)を保持しておき、Transaction::setArchived() でtransactionテーブルにおいて対象アカウントでtxidより小さい有効なレコードのarchivedを1に変更する。
※ここで有効なレコードとは「archivedが0」かつ「関連するブロックが承認済みまたはOrphanまたはtypeが'Credit_PPS','Donation_PPS','Fee_PPS','TXFee','Debit_MP','Debit_AP'のいずれかである」を満たすもの。
php-mposのtables_cleanupバッチ
cronjobs\tables_cleanup.php でshares_archiveテーブルのデータを物理削除している。
条件は次のいずれかで一番過去である時間「実行時の24時間前または最新10ラウンドで最も過去の時間」より過去のデータで、かつ総数の5パーセントに該当するもの。
※各値はコンフィグを参照している。24時間はconfig['archive']['maxage']（設定値は分）、10ラウンドはconfig['archive']['maxrounds']、5パーセントはconfig['archive']['purge']）