Kaspa解説：blockDAG、毎秒10ブロック、そしてマルチシグの仕組み

プルーフ・オブ・ワークのチェーンの多くは、ブロックを1つずつ生成します。マイナーがブロックを見つけると全員がその上に積み上げ、同じ瞬間に見つかった競合ブロックは捨てられます。Kaspaは別の問いから出発しました。並行して生まれたブロックを、まったく無駄にしなかったらどうなるか？

その答えがblockDAGであり、Kaspaがプルーフ・オブ・ワークのまま毎秒10ブロックを生成できる理由でもあります。SSPでのKaspa対応が近づいている今、Kaspaの何が違うのか、そしてその上でマルチシグがどう機能するのかを見ていきましょう。

チェーンからDAGへ

ビットコインでは、2人のマイナーがほぼ同時にブロックを見つけると、ネットワークが一時的に分岐します。最終的に一方のブロックが勝ち、もう一方は孤立ブロック（オーファン）となり、その裏にある計算作業はそのまま失われます。オーファンを稀にするため、ビットコインは10分に1ブロックを目標にしています。これは、各ブロックが次のブロックが見つかる前にネットワーク全体に行き渡るのに十分な長さです。

Kaspaはこの制約を取り払います。新しいブロックはそれぞれ、1つではなく複数の過去のブロックを参照できるため、並行して作られたブロックがすべて台帳の一部になります。構造は単一のチェーンではなくなり、有向非巡回グラフ、つまりDAGになります。

ただし、DAGそれ自体には問題があります。並行する2つのブロックに矛盾する取引が含まれていたら、どちらが有効なのでしょうか？Kaspaのコンセンサスプロトコルである GHOSTDAG は、すべてのブロックを一貫した順序に並べることでこれを解決します。誠実なマイナーが作った、互いによくつながった多数派のブロックを特定し、すべてを合意された単一の順序に並べるため、どのノードも「どの取引が先か」について同じ結論に達します。

その結果、Kaspaは毎秒10ブロック（2025年のCrescendoアップグレード以降の速度）で稼働でき、この速度では普通のチェーンを麻痺させてしまうはずのオーファンによる無駄も生じません。台帳の保護には引き続きプルーフ・オブ・ワークを使っています。

実際にはどういう意味か

• 高速な承認。 取引はおよそ1秒ほどでブロックに取り込まれます。どのチェーンでも同じですが、高額の場合は承認の深さが引き続き重要です。上にブロックが積まれるたびに取引は覆りにくくなりますが、その深さはすぐに積み上がります。
• 口座ではなくコイン。 Kaspaはビットコインと同じくUTXOモデルを採用しています。残高は個々のコインの集まりで、送金時にはその一部を組み合わせ、おつりが自分に戻ってきます。
• プルーニング。 Kaspaのノードは全履歴を永久には保持しません。古いブロックデータはおよそ1日半で削除されます。現在の状態は常に検証できますが、長期的な取引履歴はすべてのノードではなく、インデクサーやエクスプローラーが保持します。
• 小さな単位。 1 KASは100,000,000 sompiで、sompiはKaspaの最小単位です。

手数料は「マス」で測られる

ビットコインはブロックスペースをバイト単位で価格付けします。Kaspaは複数のコストを組み合わせたマス（mass）で価格付けします。

• サイズ：取引が何バイトを占めるか。
• 署名操作：署名の検証1回ごとに一定量が加算されるため、マルチシグの支出は単一鍵の支出より重くなります。
• ストレージ：KIP-9と呼ばれるルールにより、ごく小さな出力を大量に作る取引は高くつきます。台帳がダスト（少額の端数）で埋め尽くされるのを防ぐためです。

日常的な送金では、これを意識することはありません。手数料は小さいからです。ただし、Kaspaのいくつかの癖はこれで説明できます。たとえば、ごく少額のおつりを自分に戻す取引が拒否されることがある理由や、大きな支払いの前にウォレットが多数の小さなコインを統合する必要がある場合がある理由です。

Kaspaでのマルチシグの仕組み

Kaspaは意図的にアドレスの種類を少なくしています。kaspa:q アドレスは単一の鍵で管理されます。kaspa:p アドレスはスクリプトハッシュへの支払い（P2SH）型のアドレスで、あるスクリプトにコミットしており、支出するにはそのスクリプトを公開し、その条件を満たす必要があります。

マルチシグ・ボールトとは、「これらN個の鍵のうちM個が署名しなければならない」と定めたスクリプトを持つ kaspa:p アドレスです。KaspaはSchnorr署名を使い、コンセンサスレベルではスクリプトあたり最大20個の鍵をサポートし、最大15個の鍵を含む標準取引を中継します。扱いやすさにつながる点が2つあります。

• 取引IDに署名が含まれない。 誰かが署名する前から取引の最終的なIDがわかるため、複数デバイス間での署名の調整がシンプルになります。
• SegWitやTaprootのレイヤーがない。 Kaspaの標準出力タイプは、単一鍵、そのECDSA版、スクリプトハッシュへの支払いの3種類だけです。そのため、正しく作るべきマルチシグ・ボールトも1種類だけです。

セキュリティ上、重要な細かい点が1つあります。Kaspaの署名がコミットするのは、署名対象となる特定の入力の金額だけで、すべての入力の金額ではありません。そのため、慎重に設計されたマルチシグ・ウォレットでは、別のデバイスから渡された金額を信用するのではなく、各署名者が支出されるコインを自分で照会します。

SSPにおけるKaspa

SSPは、他のすべてのチェーンと同じ2-of-2モデルでKaspaを追加しようとしています。ボールトは、SSP Walletにある1つの鍵とSSP Keyにある1つの鍵から作られる kaspa:p アドレスで、各デバイスは自分が何に署名しているかを独立して確認します。SSP Enterpriseは、M-of-N承認によるKaspaボールトに対応する予定です。

まだ利用はできません。Kaspa対応は最終テスト段階にあり、リリース時にはリリースノートとともに告知されます。その基盤となるライブラリ @runonflux/kaspa-core はすでにオープンソースとして公開されており、誰でも読んだり再利用したりできます。

率直なまとめ

Kaspaは、プルーフ・オブ・ワークでUTXO台帳を守るという馴染みのある考え方を土台に、ブロックがDAGを形成できるようにすることで「1度に1ブロック」というボトルネックを取り除きました。その結果が、高速なブロック、バイトではなくマスに基づく手数料、そして単一のスクリプトタイプを中心に組み立てられたすっきりしたマルチシグ設計です。

どのチェーンでも同じですが、コインを安全に守るのはブロックの速度ではありません。誰が鍵を管理しているか、そしてマルチシグであれば、そのうちいくつの鍵の同意が必要か、です。