NexaのHard Fork 2は、公式仕様上、2026年11月1日UTCに予定されています。最大の注目点はTailstormですが、「約1秒でサブブロックが現れる」ことと「約1秒で決済が確定する」ことは同じではありません。現行仕様では、取引が次のサマリーブロックに含まれそうかを早く観測できる一方、台帳状態を更新するサマリーブロックの平均間隔は2分です。
| 表示・間隔 | 意味 | 判断 |
|---|---|---|
| 約1秒 | サブブロックによる取引包含の早期シグナル | 決済の不可逆な確定ではない |
| 平均2分 | サマリーブロックによる台帳状態への反映 | 用途により追加サマリーも待つ |
| 不可逆性 | PoWの再編可能性を含む別の論点 | 金額とサービス方針で必要確認数を決める |
執筆・編集：編集部｜技術確認：Nexa現行仕様・リリースノートとの照合｜最終検証：2026年10月20日｜参照仕様：2026年10月20日閲覧版｜activation後に実施結果を再確認予定
この記事では、約1秒と2分がそれぞれ何を意味するのか、旧資料の「40個・約3秒」となぜ数字が違うのか、Full Node 2.2.0.0を入れたことと機能が本番で有効になることをどう区別するのかを整理します。利用者は表示の読み違いを避けられ、ノード、取引所、ウォレット、マイニングプールの運用担当者は移行前の確認点を把握できます。なお、公開予定日時点では起動前であり、日程や互換版は公式情報を再確認してください。
「約1秒」は取引包含のシグナル、「2分」は台帳更新
\n
まなぶ「約1秒で表示されたら、もう支払いは取り消せないと考えていいですか？」
クリプ「約1秒は早い包含シグナルの目安だよ。不可逆な確定時間とは言えないので、サマリーへの収録や追加の確認を用途に応じて待とう。」
現行の本番仕様ではtailstorm_kは120です。平均2分、すなわち120秒のサマリー間隔を120個のPoWサブブロックに分けるため、平均的な到着間隔は概ね1秒になります。ここでの「平均」は毎回きっちり1秒を保証する意味ではありません。PoWの発見は確率的で、短い時間に複数が現れる場合も、間が空く場合もあります。
120個のPoWサブブロックが示す確率的な包含
サブブロックに取引が含まれると、その取引を含む方向へPoWが積み上がり始めたことを早く知れます。その後、同じ取引を含む子孫や関連するサブブロックが増えれば、次のサマリーへ含まれる見込みを判断する材料が増えます。これが「確率的な包含シグナル」という表現の中心です。
シグナルはゼロか一かの最終判定ではありません。競合取引、ネットワーク遅延、DAGの別枝、フォーク比較といった要素が残ります。受取側が最初の一つを見たことだけで商品を不可逆に渡すと、リスクを過小評価する可能性があります。一方、少額で即時性を優先し、損失許容度を明確にした用途なら、早期シグナルを参考情報として使う余地があります。
サマリーブロックが平均2分で台帳へ反映
サマリーブロックが作られる平均間隔は2分のままです。そこで取引が台帳状態へ反映され、サブブロック群が永続的なサマリーチェーンへ要約されます。ただし「1サマリーに入ったらあらゆる状況で絶対に巻き戻らない」とまで言い切ることもできません。PoWチェーンでは、確認後も再編可能性をどう扱うかという問題があり、必要な確認数は取引額、相手、サービスの方針、障害時の損失によって変わります。
金額とリスクで待機水準を変える
待機基準は一律の秒数ではなく、段階で考えると実務的です。第一段階は取引をノードが受信した状態、第二段階はサブブロックに見えた状態、第三段階はサマリーブロックへ収録された状態、第四段階はその後に追加のサマリーが積み上がった状態です。ウォレットや決済画面がどの段階を「確認済み」と表示するかも確認しましょう。
- 低額で時間優先：サブブロックを早期の参考情報にできるが、損失上限を決める。
- 通常の送受信：少なくともサマリー収録を確認し、サービス側の必要確認数に従う。
- 高額・不可逆な引き渡し：追加サマリー、入出金事業者の方針、異常時の停止手順まで確認する。
これは特定のNEXA取引を勧める基準ではありません。高速表示の意味を技術的に区別し、自分や組織のリスク管理へ落とし込むための整理です。
先に押さえる3つの用語
最後に、記事内で使った用語の関係を短く整理します。Hard Fork 2は変更全体の名称、Tailstormはその中核をなすブロック生成・合意構造の一つです。DAGはサブブロック同士の参照関係、サマリーチェーンは正準な状態と長期履歴を担います。似た言葉を同じものとして扱わないことが、仕様を読む第一歩です。
ハードフォーク
ハードフォークは、旧版がそのままでは新規則のブロックを正しいと判断できない種類の変更です。必ず資産が二つに分かれる、あるいは新しいコインが配布されるという意味ではありません。十分な参加者が同じ規則へ協調して移行すれば、利用者からは通常のアップグレードに見える場合もあります。一般的な違いはハードフォークとソフトフォークの解説でも確認できます。
一方、更新しないノードが残れば、旧規則で有効とみなす履歴と新規則で有効とみなす履歴が一致しない可能性があります。このため取引所や決済サービスが前後に入出金を止めるのは、価格を予想しているからではなく、どの履歴を採用するかを安全に確認する運用上の措置と考えられます。
DAG
DAGという言葉は、要素を有向辺で結び、同じ場所へ循環して戻らない構造を表します。しかし「DAGを使う」という一語だけでは、二重支払いをどう解決するか、どの枝を採用するか、報酬をどう分けるかは決まりません。各プロトコルが別途、フォーク選択、検証規則、PoWや投票、保存方法を定めます。
Nexa Tailstormの場合は、複数親のサブブロックDAG、PoW、サマリーブロック、サマリーチェーンが組み合わさります。他のDAG型プロジェクトで得られた性能値や安全性評価を、名前が同じという理由だけでNexaへ移すことはできません。逆に、従来型チェーンと組み合わせているため「DAGならブロックチェーンではない」と切り分けるのも実態を表しません。
PoW・確認・確定
PoWは計算仕事によってブロック生成や履歴選択を支える仕組みです。基礎から確認したい場合はPoW（Proof of Work）の基礎解説が参考になります。Tailstormでは仕事を細かなサブブロックへ分けても、PoWと累積仕事量の考え方がなくなるわけではありません。
「確認」という表示はサービスごとに意味が違うことがあります。取引をメモリプールで見ただけなのか、サブブロックへ入ったのか、サマリーへ入ったのか、さらに何個のサマリーが後続したのかを区別してください。「確定」も日常語として不可逆を連想させますが、PoWネットワークでは再編可能性を含むため、技術文書の定義とサービスの運用基準を確かめる必要があります。
公式情報の確認順
検索で複数の数字が見つかったら、まずコンセンサス仕様、次にリリースノート、最後に開発ブログや広報という順で照合すると整理しやすくなります。仕様は現在の規則、リリースノートは特定バージョンへ入った変更、開発ブログはその時点の背景や進捗を説明する資料だからです。論文は設計の根拠を理解するうえで重要ですが、実装が論文と同一かを必ず確認します。
日付、ネットワーク名、ソフトウェア版、パラメータ名、単位も記録してください。「1秒」という断片だけでは、それが目標値、平均値、テスト値、mainnet値、確定時間のどれか分かりません。今回なら、mainnetのtailstorm_k=120、平均2分のサマリー間隔、そこから導かれる約1秒という関係まで一緒に残すことで、古い40個・約3秒との混同を防げます。
また、公開予定日時点ではHard Fork 2はまだ起動前です。本記事が示すのは入力調査で確認された現行仕様であり、activationの実施結果ではありません。実際の送金やシステム変更の直前には、公式仕様、最新リリース、障害告知を見直し、自分のノードや利用サービスで状態を確認してください。
TailstormはDAGとサマリーチェーンを組み合わせる
\n
まなぶ「DAGになるなら、これまでのブロックチェーンはなくなるんですか？」
クリプ「なくならないんだ。短期的なサブブロックのDAGと、長期保存されるサマリーチェーンを組み合わせる設計だよ。」
Tailstormを理解する鍵は、サブブロックDAGとサマリーチェーンを別々の役割として見ることです。DAGはDirected Acyclic Graphの略で、方向を持ち、循環しないグラフを指します。ブロックチェーンの基本構造のような一本の列に一つずつブロックを置くだけでなく、複数の親を参照できるため、同じ時期に見つかったPoWの成果をより多く構造へ取り込めます。
複数親を持つサブブロックをRAMで処理
Nexa版Tailstormでは、マイナーが作るサブブロックは複数の親を持ち得ます。並行して見つかったサブブロックを単純に一つだけ勝者として残すのではなく、DAGとして関連づける考え方です。これにより、PoWを細かな単位へ分けてネットワーク上で観測できるようにします。
ただし、サブブロックは永続的なブロック履歴と同じ扱いではありません。現行仕様ではRAMに保持され、サマリーブロックの成立後に枝刈りされます。ディスクへ永久保存する対象を際限なく増やさず、高頻度の短期情報を扱うための設計です。この性質は、古いサブブロックを後から要求した際のNOTFOUND応答や、欠落を理由にpeerへ誤った罰則を与えない処理が重要になることも意味します。
正準状態と保存を担うサマリーチェーン
ネットワークが採用する台帳状態を進め、長期的なチェーンの性質を担うのはサマリーブロックです。サブブロックに取引が見えた時点では、その取引が次のサマリーへ入る可能性を仕事量とともに観測している段階です。サマリーが成立すると、採用されたDAGの成果がチェーンへまとめられます。
このハイブリッド構造は「高速な手掛かり」と「保存される台帳」を両立させようとするものです。サブブロックの到着を、銀行振込の最終完了通知のように扱うのは適切ではありません。画面が高速に反応できることと、正準状態が更新されることを分けると、Tailstormの目的が見えやすくなります。
Nexa Hard Fork 2は2026年11月1日UTCに予定
Hard Fork 2は、ネットワーク参加者が同じ時点から新しい合意規則へ切り替えるアップグレードです。公式仕様に記載されたmainnetとtestnetのactivationはUnix時刻1793495471で、2026年11月1日1時11分11秒UTC（日本時間の同日10時11分11秒）に対応します。ただし切り替え判定は時計の瞬間ではなくMTP基準なので、実際に新規則が始まるブロックはこの時刻と単純には一致しません。
MTP到達ブロックはpending、次のブロックから新規則
切り替えは、端末の時計が指定時刻になった瞬間に一斉に起こるという説明では不十分です。仕様では、ブロック時刻の中央値であるMTP（Median Time Past）がactivationへ達したブロックを「pending」とします。そのブロック自体は旧規則で扱われ、次のブロックからHard Fork 2の新規則が強制されます。
MTPを用いる理由は、単一ノードのローカル時計だけに合意境界を依存させないためです。したがって運用者が監視すべきなのはカレンダーだけではありません。自ノードが認識するチェーン先端、MTP、fork状態、接続先の挙動を合わせて確認する必要があります。公開予定日時点では未来のイベントなので、予定どおりに進むと断定せず、直前の仕様変更やリリース告知も確認するのが安全です。
Tailstorm以外にVM・署名・NexaPOWも変更
Hard Fork 2を「ブロックが速くなる更新」とだけ捉えると全体像を見失います。公式ページではTailstormに加え、VM、署名、NexaPOWなど複数のコンセンサス変更がまとめられています。つまり、一部の画面表示だけを変える機能追加ではなく、ブロックや取引を正しいと判断する規則に関わる協調的な移行です。
新規則に対応しないノードは、activation後に新しいブロックを拒否したり、旧規則側のチェーンを追ったりする可能性があります。ウォレット利用者が自分でフルノードを運用していない場合でも、接続先のノード、取引所、決済事業者が対応しているかは利用可能性に影響します。保有資産の値動きとは別に、送受信や入出金が一時停止される運用上の可能性も考えておくべきです。
旧資料の「40個・約3秒」と現行仕様を混同しない
\n
旧広報と初期案は40サブブロック
2026年9月のFull Node 2.2.0.0に関する広報や、開発中の説明には、120秒あたり40サブブロック、約3秒間隔という数字があります。これは当時の計画や説明としては意味がありますが、現在の本番コンセンサス仕様を示す数字としてそのまま引用するべきではありません。
テスト環境ではkを2から120まで変えて試す説明もありました。開発中にパラメータが調整されるのは、性能だけでなく伝播、検証負荷、フォーク時の挙動を確かめるためです。検索結果、SNS投稿、古い解説だけを見ると「3秒」と「1秒」が矛盾して見えますが、資料の時点と性質をそろえれば、旧計画値と現行仕様の違いだと理解できます。
現行仕様は120サブブロックを採用
記事公開予定日時点で優先すべき一次情報は、Hard Fork 2およびTailstormの現行仕様です。そこではmainnetのkは120です。したがって説明上は、平均2分のサマリー間隔に対して約1秒のサブブロック間隔となります。将来、仕様が再更新される可能性はあるため、運用時には文書の最新版と実行バイナリの設定を照合してください。
数字を読む際は「何の時間か」も必ず添えます。約1秒はサブブロック到着の平均的な目安、約2分はサマリーブロックの平均間隔です。どちらもネットワーク遅延を含む利用者の体感時間や、取引所の入金反映時間を保証するものではありません。
運用者・技術読者向けの補足
ここからはノード、取引所、ウォレット基盤、マイニングプールの担当者向けです。一般利用者は次の「11月1日前に確認すること」へ進めます。
Full Node 2.2.0.0の搭載と本番有効化は別
ソフトウェアにTailstormのコードが含まれていることと、mainnetがTailstormの規則で動いていることは別です。Full Node 2.2.0.0は準備コードを含む基準リリースでしたが、Hard Fork 2のゲート下にあり、有効化時点までは休眠する設計でした。
2.2.0.0はTailstorm準備コードの基準リリース
2.2.0.0のリリースノートには、並列検証、DAG再編、二重支払いの勝者選択、孤立したサマリーの保持など、Tailstorm関連の修正が列挙されています。公開リポジトリのタグによってリリース系列も確認できます。これは実装が単なる構想ではなく、配布可能なノードソフトへ組み込まれたことを示します。
ただし「2.2.0.0をインストールしたから移行作業は完了」とは限りません。公開後にも修正や試験が続いているため、activationに対応する推奨版が別に案内されていないか、署名や配布元が正しいかを公式チャネルで確認する必要があります。
Hard Fork 2のゲート下では機能が休眠
2026年8月の開発報告は、コードがHard Fork 2のゲート下で未有効だったことを明記しています。これは移行前に参加者へソフトウェアを配り、同じactivation境界で規則を切り替えるための一般的な考え方です。インストール日をネットワーク有効化日と誤認してはいけません。
stormtestと継続試験で確認された課題
Tailstormはstormtestという専用テスト環境で段階的に検証されました。診断RPCを通じてDAGやフォーク状態を観測でき、開発報告では順不同epoch同期、再編時の検証停止、二重支払い処理、ロック順序、検証キュー、pruned subblockへの応答などが改善対象として挙げられています。
これらは高頻度にサブブロックを扱うだけでなく、同時並行の処理が矛盾なく収束する必要があることを示します。2026年10月13日の技術更新や10月16日の月次報告でも、コンセンサス検査やプロトコル最終化、広範な試験が継続していると説明されています。したがってHard Fork 2は、完成済み機能の単純なスイッチ操作というより、直前まで検証を重ねるコンセンサス移行として捉えるのが適切です。
高速化してもPoWと難易度調整の基準は維持される
ASERTはサマリーチェーンを基準に計算
TailstormはPoWを捨てて別方式へ置き換えるものではありません。Hard Fork 2後も、難易度調整アルゴリズムASERTはサマリーチェーンを基準に計算されます。仕様では基準となるサブブロックtargetをk倍する関係が示され、平均2分ぶんの仕事をより細かなPoWへ分配する構造になっています。
そのため、単純に「従来のブロックを120倍速くした」と理解するのも正確ではありません。高速に現れるサブブロックと、難易度調整や永続状態を担うサマリーチェーンが協調します。平均値と実際の到着間隔がずれる点も従来のPoWと同様に意識が必要です。
フォーク比較はブロック数ではなく累積仕事量
競合する履歴を比較するとき、見えているサブブロックやブロックの個数だけを数えるのは不十分です。NexaPOWの仕様ではchainworkが各ブロックの仕事量を累積します。Tailstormでも、どのDAGやサマリーチェーンを採用するかは、単純な要素数ではなくPoWに裏付けられた比較として扱う必要があります。
この点は利用者の確認表示にも関係します。「サブブロックが何個ついたか」は分かりやすい指標ですが、それだけでフォーク時の優位性や最終性を完全に表せません。ウォレット開発者や基盤事業者は、ノードが提供する合意状態を利用し、独自の単純カウンターだけで確定判定を作らないことが重要です。
k=120に連動して最大サイズ下限は12MB
適応的ブロックサイズの仕様もkに連動します。Hard Fork 2がpendingになった後、最大ブロックサイズの下限はk×100KBとなり、本番のk=120なら12MBです。これは各サブブロックが最大100KBの取引を収容できる設計と整合させる変更です。
下限値が12MBになることを、そのまま常時12MBのデータが2分ごとに生まれるという意味に読み替えてはいけません。規則上の許容量と実際の利用量は別です。一方、負荷試験では、ピーク時の検証、メモリ、帯域、RPC利用、インデックス更新がどの程度になるかを想定する必要があります。
Nexa実装とTailstorm原論文には重要な差がある
まなぶ「論文で安全性が評価されているなら、Nexa版も同じ結果だと考えていいですか？」
クリプ「実装条件が違うので、そのまま移せないよ。構造や報酬ルールの差を確認して、研究結果と本番実績を分けて読もう。」
原論文はツリー構造と報酬割引を前提に評価
Tailstorm原論文は、k個の並列PoW、ツリー状のサブブロック、深さに応じた報酬割引などを前提に、確認速度や公平性、攻撃戦略を分析しています。査読会議版では伝播遅延、強化学習による攻撃探索、試作実装も扱われています。研究として重要な根拠ですが、Nexa固有実装のmainnet運用実績を報告したものではありません。
Nexa版は複数親DAGとPoW付きサマリーを採用
Nexa版は原論文をそのまま複製していません。複数親を持つDAGを用い、最後のサブブロック自体をPoW付きサマリーブロックにする設計や、uncleを回収する仕組みを採用しています。これはサマリー生成の曖昧さや枝刈りを利用する攻撃を意識した実装上の変更です。
実装差があること自体は、良いとも悪いとも直ちには結論できません。重要なのは、どの主張がどの前提に依存するかを追うことです。原論文で示された性質を紹介する場合は「Tailstorm一般」や「論文モデル」の結果とし、Nexa版で同じ条件が成立するかを別途検証する必要があります。
報酬割引なしの攻撃耐性は本番での検証が必要
特に注意したい差が報酬割引です。Nexa実装は原論文の報酬割引を採用しません。並列PoWとDAG投票を分析した別の研究は、報酬割引がない場合、条件によってはBitcoinより攻撃耐性が低くなり得ると指摘しています。これは直ちにNexaが安全でないと証明するものではありませんが、原論文の安全性や公平性評価を自動的に継承したとも言えない理由になります。
評価には、Nexa固有のフォーク選択、複数親、サマリー構造、ネットワーク条件、マイナー行動を含めた分析と、本番移行後の観測が必要です。利用者は「論文があるから保証済み」「違いがあるから危険」と二択にせず、前提と検証範囲を読む姿勢が大切です。
11月1日前に利用者と運用者が確認すること
利用者は約1秒表示と決済確定を分けて扱う
利用者は、使っているウォレットやサービスの「未確認」「サブブロックで観測」「サマリー収録」「追加確認済み」がどう表示されるかを確認してください。約1秒で反応しても、送金相手が同じ段階を確定と扱うとは限りません。取引所の入出金は独自の停止期間や確認数が設定される場合があるため、急ぎの送金をactivation直前へ集中させない判断も有効です。
ノード運用者は互換版とactivation実値を再確認
ノード運用者は公式配布元の最新リリース、チェックサムや署名、Hard Fork 2対応の明記、設定ファイル、ディスク容量、RAM、帯域、監視項目を確認します。2.2.0.0が基準リリースだった事実だけで、公開予定日時点の最終推奨版だとは断定できません。activationのUnix時刻、MTP、pending状態、新規則適用ブロックの関係も運用手順書へ記載すると誤操作を減らせます。
取引所・プール・基盤事業者は停止手順と分岐対策を確認
取引所、プール、ブロックエクスプローラー、ウォレット基盤は、ノード更新だけでなく周辺システムの互換性を検証します。RPCの返却値、確認数の計算、DAG表示、入出金判定、再編時のロールバック、監視アラート、インデクサー同期が対象です。旧規則側へ分岐したノードを検知した場合の隔離と復旧、入出金停止と再開を誰が判断するかも決めておきます。
マイニングプールはテンプレート生成、サブブロック伝播、複数親の選択、報酬処理、フェイルオーバーを本番相当の負荷で確認する必要があります。activation直後は、ブロック高だけでなくMTPとfork状態に基づいて判断し、異常時に旧版へ単純に戻すことが新規則との非互換を生まないかも事前に検討してください。
wallet.datのバックアップと本番負荷への備え
公式広報はノード更新とともにwallet.datの安全なバックアップを勧めています。バックアップは作成しただけで終わらず、保存先へのアクセス、暗号化、復元手順、バックアップ時点以後の鍵管理を確認します。秘密鍵やシードをオンラインの共有場所へ置かず、運用権限を必要最小限にすることも基本です。
本番負荷では、RAM上のDAG、並列検証、順不同の到着、枝刈り済みサブブロックへの要求が同時に起こり得ます。メモリ使用量、peer数、検証待ち、RPC遅延、同期遅延、エラー率を平常時と比較できるようにし、しきい値超過時の縮退運転を用意します。直前の公式告知、既知の問題、推奨peerや設定が更新されていないかも確認しましょう。
まとめ：速いシグナルと台帳更新を分けて判断する
Nexa Hard Fork 2は公式仕様上2026年11月1日UTCに予定され、MTPがactivationへ達したブロックをpendingとし、その次のブロックから新規則を適用します。Tailstormでは本番k=120により、平均2分の間に約1秒間隔でPoWサブブロックが現れる設計です。
- 約1秒は取引包含を早く観測する確率的なシグナルであり、不可逆な決済確定の保証ではない。
- 正準状態と永続保存は平均2分のサマリーブロックが担う。
- 旧資料の40個・約3秒は開発時の値で、現行仕様は120個・約1秒。
- Full Node 2.2.0.0へのコード搭載とmainnetでの有効化は別。
- Nexa版は原論文と構造・報酬ルールが異なり、研究評価をそのまま適用できない。
- 利用者と運用者は、最新互換版、表示段階、バックアップ、停止・復旧手順を公式情報で再確認する。
Tailstormの価値を判断するときは、速さだけを切り出さず、何が観測され、何が台帳へ保存され、どの前提で安全性が評価されたかを確認してください。本記事は技術仕様の整理であり、NEXAその他の金融商品の購入や保有を推奨するものではありません。
