Kaspa の Toccata ハードフォーク: コベナント、ZK オペコード、および 6 月の新しいターゲット

カスパの今後のToccataハードフォークでは、ネットワークに2つの新しいプログラマビリティパスが追加されます。ネイティブL1コヴナントプログラミングと、ゼロ知識（zk）ベースのアプリケーションインフラストラクチャです。メインネットのアクティベーションは、当初の5月5日から延期され、2026年6月5日から20日に予定されています。

Kaspa Coreのマイケル・サットンは、 詳細な更新 ハードフォークの内容、日程変更の理由、そして今後数ヶ月の展開予想について。このフォークは元々、Ori Newman氏がKaspaのスクリプトエンジンにコヴナントを導入する試みとして開始したもので、ビットコイン界隈でのOP_CATの議論への対応も一因となっている。その後、かなり大規模なものへと発展した。

Toccataハードフォークとは何ですか？

Toccataは、Kaspaネットワークの計画的なハードフォークであり、新しい機能をベースレイヤーに直接導入するものです。ハードフォークとは、あまり馴染みのない方のために説明すると、後方互換性のないプロトコルのアップグレードのことです。ネットワークへの参加を継続するには、すべてのノードがアップグレードする必要があります。

この名称は、カスパーが主要なアップグレードに音楽的な由来を用いるという伝統に倣ったものです。今回の名称は、鍵盤楽器における高度な演奏技術を披露するために作曲された楽曲である、クラシック音楽の形式であるトッカータに由来しています。

大まかに言うと、トッカータはカスパに2つの要素を追加している。

• ネイティブL1契約プログラミング Silverscriptと呼ばれる新しいコンパイラを介して
• zkアプリケーションインフラストラクチャに基づく同じ契約の土台の上に築かれた

これらは互換性のあるシステムではありません。それぞれ異なる用途に対応し、異なる開発者層を対象としています。

契約とは何か？そして、なぜカスパにとって重要なのか？

コベナンツとは、取引出力に含まれる資金の将来的な使途に関する条件のことです。標準的なビットコインやカスパの取引では、コインが送金されると、受取人は自由に使うことができます。コベナンツは、支出ルールをスクリプトに直接組み込むことで、この状況を変えます。

Kaspaは、ビットコインと同様にUTXOモデルを採用しており、各トランザクションは既存の出力を消費し、新しい出力を生成します。UTXOシステムにおけるコベナンツ（契約条項）により、開発者は驚くほど複雑なステートフルなマルチコントラクトフローを構築できます。ただし、基盤となる計算処理は各UTXO内で行われます。

カスパ・コアは、コヴナント開発をより容易にするため、オリ・ニューマン、マイケル・サットン、イジオデヴ、およびマニーフェストによって開発されたコンパイラであるSilverscriptの最終版を完成させようとしています。Silverscriptは、開発者がスクリプトエンジンの生レベルで作業する必要なく、複雑なコヴナントをカスパL1上で直接、より簡単かつ安全に記述およびデプロイできるように設計されています。

ZKベースのアプリケーションとは？

Toccataで導入された2つ目のプログラマビリティの柱は、zkアプリケーションに基づいています。これは2つのうち技術的に密度が高く、慎重に解説する価値があります。

有望なプロジェクトを発見...

有望なプロジェクト...

（広告）

記事は続きます…

ZKはゼロ知識証明の略で、基となるデータを開示することなく、ある事柄が真実であることを証明できる暗号手法です。ZK証明は、オフチェーンでの計算結果をオンチェーンで低コストかつ安全に検証できるため、ブロックチェーンのスケーリングにおいてますます広く利用されています。

この文脈における「ベース」とは、zkシステムがL1シーケンスに完全に準拠していることを意味します。ベースとなるzkアプリケーションは、トランザクションを独自に追加または削除することはできません。Kaspa独自のトランザクション順序に固定されているため、別途シーケンサーを用意しなくても信頼性が確保されます。

Toccataは、これをサポートするためにいくつかのコンポーネントを導入しています。

• ZK検証オペコード柔軟なGroth16検証器とRISC Zero STARK検証器を含む。
• シーケンスコミットメントアクセスオペコードこれにより、ベースアプリケーションがL1順序付けに自身を固定できるようになります。
• KIP-21分割されたシーケンスコミットメントアーキテクチャにより、zkアプリの証明コストは、DAG全体の活動ではなく、アプリ自身の活動に応じてスケーリングされます。

RISC Zero STARK検証ツールは既にテストネット12に実装され、有効化されています。メインネットでの有効化については現在検討中です。

コスト証明が重要な理由

ゼロベース知識（zk）アプリケーションが実用的であるためには、証明生成のコストがアプリケーション自体の処理量に比例している必要があります。zkアプリケーションがより広範な有向非巡回グラフ（DAG）上のすべてのアクティビティに関連する処理を証明しなければならない場合、コストは予測不可能で管理不能になります。KIP-21は、シーケンスコミットメントを分割し、各アプリケーションのワークロードを自己完結型に保つことでこの問題を解決します。

既に導入されているものは何ですか？

ハードフォークの大部分は既に実装済みです。以下の機能は既に構築されています。

• KIP-17に基づく拡張スクリプトエンジンオペコードサポート（コアコベナンツのバックボーン）
• KIP-20に基づく、系統管理のための合意およびエンジン機能としてのコベナントID
• アレクサンダー・サフストロム著、KIP-16準拠、zk-verifierプリコンパイルサブシステムを備えたZKオペコード
• シーケンスコミットメントアクセスオペコード
• サットンが作成し、マキシム・ビリュコフが実装したKIP-21は、完全に実装され、レビュー待ちの状態である。

インラインzkコベナントやKASカノニカルブリッジを使用したベースzkコベナントなど、概念実証のマイルストーンもMaximによって完了しており、フォークの最終設計を形成する上で重要な役割を果たしました。

ハードフォークの日程が6月に変更された理由は？

当初のメインネット稼働開始予定日は2026年5月5日でしたが、その後2026年6月5日から20日の間に変更されました。

理由はアーキテクチャ上の問題です。zk回路とランタイムがシーケンスコミットメントハッシュ構造にバインドされると、後から構造的な変更を加えると互換性が損なわれます。設計を誤って後で修正するよりも、今時間をかけて修正する方がはるかに大きな混乱を招くでしょう。

KIP-21は、Kaspaが策定した同期的に構成可能な検証可能プログラムのための長期ロードマップであるvprogsで将来的に必要となるコミットメントスキームとの互換性を既に確保するように設計されています。メインネットのアクティベーション前に適切な構造を確定することで、後々のコストのかかる移行作業を回避できます。

機能の凍結は2026年4月15日に予定されています。

機能凍結からメインネット公開までの間に何が起こるのか？

4月15日の機能凍結後、Kaspa Coreは専用テストネットTN12を、最終版の全機能セットを含めてクリーンな状態で再起動する予定です。これはハードフォーク移行のシミュレーションではなく、最終版の全機能セットをテストするためのクリーンなネットワークです。

そこから、チームは長期間保留されていたブランチで蓄積された数ヶ月分の作業をマスターコードベースに統合します。このプロセスには、最終的な監査、未解決事項の解決、ハードフォークの有効化ロジックの完成、およびデータベースのアップグレード対応が含まれます。

その作業が完了したら、長期テストネットであるTN10上でテスト用のハードフォークを実行し、メインネットへの移行をシミュレートします。メインネットへの移行日は、そのリハーサルがチームの満足のいく結果になった後にのみ確定されます。

ノードオペレーターが期待すべきこと

マイナーやノードオペレーターにとって、今回のアップグレードは簡単に行えるように設計されています。ノードを更新する必要がありますが、既存の機能は引き続き動作します。ディスク容量の必要量は約20～50%増加すると予想されます。インフラの大幅な変更は想定されていません。

トッカータがカスパにもたらすもの

Toccataは、Kaspaのベースレイヤーに2つの動作するプログラマビリティシステムを追加します。1つはSilverscriptによるネイティブL1コヴナントスクリプティング、もう1つはKIP-16、KIP-20、KIP-21によるzkベースのアプリケーションインフラストラクチャです。技術的な作業の大部分は既に完了しています。残っているのは、インターフェースの最終調整、保留中のブランチのmasterブランチへのマージ、そしてメインネットのリリース日が確定する前にTN10でフルリハーサルを実行することです。

2026年6月5日から20日までの期間が設けられているのは、チームが本番環境で後から修正するのではなく、最初からシーケンスコミットメントアーキテクチャを正しく構築することを選択したためです。ノードオペレーターにとって、このアップグレードはディスク容量のわずかな増加以外に大きなインフラストラクチャの変更を必要としないため、非常に簡単に行えるように設計されています。

資料

1. Xのカスパ:投稿（2026年4月）

2. マイケル・サットンによるブログ記事: Kaspa Covenants++ 「Toccata」ハードフォークの見通し