DigiByte：シェアがブロックにならなかった理由

DigiByteのMultiShieldは、5つのアルゴリズムのいずれかでブロックが届くたびに、SHA-256のマイニング目標値を再計算します。平均すると15秒ごとです。エクスプローラー、ダッシュボード、マイニングレポートで見るネットワーク難易度は、すでに古くなったスナップショットです。その値を超えたシェアが有効なブロックになるのは、プールに届いたまさにその秒に有効な目標値を超えた場合だけです。これが、DigiByteのソロマイナーが記録的なシェアを見ながら何も得られない、最もよくある理由です。

要点

• DigiByteでは、SHA-256の目標値は5つのアルゴリズムのいずれかでブロックが届くたびに再計算されます。SHA-256のブロックが見つかったときだけではありません。
• 90分間の窓で、SHA-256ブロックの難易度は4.18億から11.2億まで動きました。2.7倍の幅です。
• わずか2分間の区間で、有効な目標値は7.48億から13.1億へと**75%**上昇しました。
• シェアの価値はそれが届いた秒の目標値で決まります。同じシェアが、ある瞬間には届かず、1〜2分後には勝つこともあります。
• これはブロックが失われたという意味ではありません。有効な目標値を下回るシェアはブロックとして送られることがないので、孤立させるものも、拒否するものも、隠すものもありません。

シェアがネットワーク難易度を超えたのに、なぜブロックが見つからなかったのか？

あるDigiByteのソロマイナーが、丁寧でよく調べられた報告を送ってくれました。その方のマイナーは、難易度約9.97億のシェアを出していました。約1時間後に作成されたマイニングレポートにはネットワーク難易度5.31億と表示されており、シェアは目標値のほぼ2倍ということになります。それでもブロックは現れませんでした。その方はプールのAPIを確認し、シェアが受信・受理されたことを確かめ、拒否や古いシェアの記録が一切ないことも確認していました。見えるすべての数字からすれば、ブロックになっているはずでした。

その方が見ていた数字は本物でした。ただし、見るべき数字ではありませんでした。

私たちはプールのログでそのシェアを追跡しました。シェアが届いたのは2026年10月4日の06:26:31から06:27:31 UTCの間です。その1分間、ネットワークが求めていたのは5.31億ではありませんでした。求めていたのは11.3億〜12.1億です。シェアは必要な値の82.7%〜88.1%に達していました。

5.31億という数字は、急上昇が過ぎ去った1時間後の難易度でした。そして06:28:37以降、つまりシェアが届いてから1〜2分後には、目標値は9.97億を下回りました。同じシェアが1〜2分遅く届いていれば、ブロックになっていたのです。

なぜDigiByteの難易度はこれほど大きく動くのか？

DigiByteはブロック生成を5つの独立したマイニングアルゴリズムに分けています。SHA-256、Scrypt、Skein、Qubit、Odocryptです。それぞれがおよそ5ブロックに1つを採掘し、それぞれが独自の難易度を持ちます。チェーン全体では15秒に1ブロックを目標としているため、SHA-256レーンは平均して75秒に1ブロックとなります。

各レーンの難易度は、DigiByteが2014年に導入したDigiShieldのマルチアルゴリズム拡張であるMultiShieldが管理しています。Bitcoinが2,016ブロックに1回再調整するのに対し、MultiShieldは毎ブロック難易度を再計算します。

マイナーが意表を突かれるのは、MultiShieldが毎ブロック、そのブロックを見つけたレーンだけでなくすべてのレーンを再計算するという点です。DigiByteのコンセンサスコードは、難易度パラメータの上にあるコメントでこれを明言しています。別のアルゴリズムがブロックを解くと、あるアルゴリズムの難易度が下がる場合がある、と。つまりSHA-256の目標値は、SHA-256のブロックとブロックの間でもじっとしていません。Scrypt、Skein、Qubit、Odocryptで見つかったブロックもすべて目標値を動かし、その結果、目標値はおよそ15秒ごとに変わります。完全なアルゴリズムについては、コンセンサスコードから直接読み解いたDigiByte解説で取り上げています。

その1分間、目標値は実際にどう動いたのか？

新しいブロックが届くたびに、プールは新しいマイニングジョブを組み立て、そのジョブが満たすべき目標値を記録します。以下は、そのシェアの前後でプールのログが記録した正確な値です。

シェアが届いたのは06:26:31から06:27:31の間で、そのとき目標値は1,205,245,749、続いて1,130,849,418でした。996,739,624のシェアは、要求値の82.7%〜88.1%に達していました。目標値が初めてシェアを下回ったのは06:28:37です。

この波を生んだものは、同じ窓でチェーンが実際に生成したSHA-256ブロックを加えると明らかになります。

99秒間にSHA-256のブロックが3つ届きました。75秒に1つという想定ペースに対して、33秒に1つです。SHA-256レーンは他の4つを大きく先行しており、MultiShieldはこれに応じて難易度を引き上げ、ピークの13.1億に達しました。その後、4分24秒にわたってSHA-256のブロックは1つも届きませんでした。他のアルゴリズムでブロックが届くにつれ、目標値は一段ずつ下がっていきました。シェアが届いたのは頂点の直後、目標値がまだそこから下降している最中でした。

記録された値は推定ではなく、ネットワークの実際の要求値です。上の4つのSHA-256ブロックはいずれも、プールが直前に記録した目標値とまったく同じ値で、1の位まで一致して採掘されています。4つとも、どのDigiByteエクスプローラーでも公開検証できます。

なぜレポートの難易度は目標値と一致しなかったのか？

レポートが記録したのは1時間後の瞬間であり、DigiByteにとって1時間は長い時間だからです。

エクスプローラー、プールのダッシュボード、マイニングレポート、収益性計算ツールなど、どこで見る難易度の値も、読み取った瞬間の値です。Bitcoinではその値が2週間続きます。DigiByteでは、5つのアルゴリズムのいずれかがブロックを見つけるたびにSHA-256の目標値が再計算されるため、07:34に取った値は06:27に何が求められていたかをほとんど何も語りません。

このシェアの前後90分間で、チェーン上のSHA-256ブロックの難易度は約4.18億から11.2億まで、2.7倍の幅がありました。9.97億のシェアは、その範囲の下の方なら余裕でブロックになり、上の方なら余裕で届きませんでした。

もう一つ落とし穴があります。エクスプローラーが公開するのは、採掘された時点の各ブロックの難易度、つまり勝者に適用された値です。ブロックとブロックの間の数秒に有効だった目標値の公開記録は存在しません。上のログで最も高い目標値である13.1億は、どのエクスプローラーにも表示されません。その値が有効だった間に、SHA-256のブロックが1つも採掘されなかったからです。それでも、惜しい外れが起きるのはまさにそういう瞬間なのです。

なぜ目標値はMultiShieldの8%制限を超えて跳ね上がるのか？

私たちのDigiByte解説では、MultiShieldは再調整を制限しており、難易度は1ステップで最大16%下がる一方、上がるのは最大8%までだと説明しています。ところがこの窓では、3つの高速なSHA-256ブロックの後、そのたびに目標値が20%以上、つまり22.9%、22.7%、21.7%上昇しました。

この2つの事実は矛盾しません。MultiShieldはレーンを2つの別々の方法で動かすからです。8%と16%の制限は、レーン自体の平均化された再調整を縛るものです。それに加えて、アルゴリズムごとに4%の調整があり、レーンが他の4つより遅れているか先行しているかに応じてレーンを動かします。

この窓では、2つ目の仕組みがはっきりとしたのこぎり歯状のパターンを生みました。他のアルゴリズムでブロックが出るたびに、SHA-256の目標値は約4〜5%下がりました。そしてレーンがすでに先行しているときに届いたSHA-256ブロックは、そのたびに目標値を急激に押し上げました。これを念頭に上の目標値ログを読み直すと、パターンは見間違えようがありません。SHA-256ブロックの後ごとに3つの大きな段差で上がり、その後は長い階段を下っていきます。

eCashのReal-Time Targetingとはどう違うのか？

症状は同じです。シェアが公表難易度を超えても何も得られません。しかし仕組みは違います。

eCashでは、シェアの運命は前のブロックがどれだけ前に届いたかで決まります。これはeCash RTT：ソロのシェアがブロックにならなかった理由で詳しく解説しています。DigiByteでは、いずれかのアルゴリズムでの最新ブロックの後にSHA-256の目標値がどこにあったかで決まります。どちらも、マイナーの側から見るとまさにブロックを逃したように見える、惜しい外れを生みます。

BitcoinやほかのSHA-256チェーンでも起きるのか？

この形では起きません。ほとんどのSHA-256チェーンでは、目標値はブロック間隔の間ずっと固定されており、そのチェーンが次のブロックを見つけたときにだけ変わります。

BitcoinとBitcoin Cashでは、調べた難易度がそのまま超えるべき値です。DigiByteでは、あなたのシェアの運命を決めた目標値は数秒しか存在せず、どこにも公開されませんでした。

ブロックは失われた、孤立した、あるいは隠されたのか？

いいえ。そもそもブロックは存在しなかったからです。

プールは、シェアがそのジョブのネットワーク目標値に達するたびに、ブロック解決イベントを記録します。このシェアについては、そのイベントは一度もありませんでした。プールはシェアを有効な目標値と照らし合わせ、届いていないと判断し、通常のシェアとして受理しました。ブロックは組み立てられず、submitblockの呼び出しも行われず、ネットワークには何も送られていません。孤立させるもの、拒否するもの、失うものは何もありませんでした。

ノンカストディアルのプールでは、これを外部から確認できます。マイナーの支払いアドレスはハッシュ計算が始まる前にブロックテンプレートのコインベーストランザクションに書き込まれるため、本物のブロックはすべて、マイナー自身の名義で永久にオンチェーンに現れます。ブロックにならなかったシェアはそうした痕跡を残しません。そして本物のブロックが存在していたなら、それを隠すことはできなかったはずです。

DigiByteのソロマイナーは実際に何をすべきか？

ほとんど何もする必要はありません。ただし、数字は正しく読んでください。

• どの難易度の値もスナップショットとして扱う。 ダッシュボードやレポートで難易度を超えるベストシェアがあっても、それはブロックを逃した証拠ではありません。シェアが届いたときに目標値がもっと高かったという証拠です。
• マイナーが表示するベストシェアはローカルで計算される。 マイナーはハッシュを見つけた瞬間、プールの応答より前にその難易度を記録し、多くの場合リセットされない歴代最高値を保持します。それはハードウェアに良い瞬間があったことを示すだけで、その瞬間が勝ちだったかどうかは示しません。
• シェア難易度の管理はvardiffに任せる。 DigiByteは毎ブロック再調整するので、ある1時間に合う固定のシェア難易度が、次の1時間には合わなくなることがあります。設定についてはDigiByteセットアップガイドで説明しています。
• 遅延を低く保つ。 15秒ブロックのチェーンでは、近いサーバーほど、新しいジョブが現れてからマイナーがそれに取りかかるまでの間隔が短くなります。
• カウンターではなくコインベースを確認する。 ブロックを見つけたかどうかを知るには、オンチェーンのコインベーストランザクションで自分のアドレスを探してください。

これらはいずれも、長期的な確率を変えるものではありません。変動は時間とともに平均化されるため、平均難易度に基づく確率、たとえば私たちのソロ確率計算ツールが使うものが、引き続き期待値の正しい基準です。変動が決めるのは、どの惜しい外れがブロックになるかだけです。

出典

• DigiByte Coreのコンセンサスパラメータ — 難易度が毎ブロックすべてのアルゴリズムについて更新されるという注記と、MultiShieldの定数nMaxAdjustUpV4 = 8、nMaxAdjustDownV4 = 16、nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp、MultiShieldの難易度調整（GetNextWorkRequiredV4）
• マイナーのためのDigiByte（DGB）解説 — コンセンサスコードから直接読み解いた、MultiShieldの完全なプロファイル
• Measuring expected block timing for Difficulty Adjustment — MultiShieldと毎ブロックの再調整についてのJosiah Spackmanの記事

この記事の目標値は、2026年10月4日のプールのログから取ったもので、新しいマイニングジョブが組み立てられるたびに記録されたものです。窓の中で採掘された4つのSHA-256ブロック、24,323,739、24,323,740、24,323,742、24,323,752はいずれも、それぞれの直前にプールが記録した目標値と完全に一致しており、記録された値がネットワークの実際の要求値であることを裏付けています。引用したブロック難易度はすべて、どのDigiByteエクスプローラーでも公開検証できます。