サマリー

Hydraのincremental commit/decommitは、単なる「資金を途中で出し入れできる便利機能」ではない。

本質は、

Hydra Headを短時間の決済セッションから、長時間稼働する流動性レイヤーへ近づけること

にある。

incremental commitによって、Open中のHeadへCardano L1から新しいUTxOを追加できる。

incremental decommitによって、Headを閉じずに一部UTxOだけをCardano L1へ戻せる。

これにより、

• DEX
• CLOB
• payment hub
• gaming
• market making
• enterprise apps
• micropayment

など、長期間稼働しながら資金が増減するサービスが現実的になる。

Hydra v2.4.0ではincremental commit周辺のsecurity correctnessも修正され、snapshotがどのdepositを承認したのかをより厳密に識別し、on-chain validator側でも強制する仕組みが導入された。

また、formal specification、machine-checked proof、mutation testing、differential testingなどを組み合わせることで、単に「動くコード」ではなく、設計上守るべき性質と実装が一致しているかを検証する方向へ進んでいる。

Hydra Headは、複数参加者がCardano L1上のUTxOをHeadへcommitし、その後はL2内で高速に取引する仕組みである。

古典的なイメージは、

Cardano L1
   ↓ commit

┌───────────────┐
│   Hydra Head   │
│ A: 100 ADA     │
│ B: 200 ADA     │
│ C: token X     │
│               │
│ 高速取引       │
└───────────────┘

   ↓ close

Cardano L1へ精算

という構造だった。

このモデルには大きな弱点がある。

一度HeadをOpenした後、資金構成を柔軟に変更しにくい。

資金を増やしたり、一部だけ取り戻したりするためにHeadを閉じて再構築する必要があるなら、

• 常設DEX
• payment hub
• gaming
• merchant network
• trading venue
• liquidity network

などの24時間・長期間稼働サービスには向かない。

2. Incremental commitとは何か

Incremental commitは、

すでにOpenして動いているHydra Headに、Cardano L1から新しいUTxOを追加する

機能である。

最初

Hydra Head
┌─────────────┐
│ 1,000 ADA   │
└─────────────┘

        ↓

Cardano L1から
500 ADA追加

        ↓

Hydra Head
┌─────────────┐
│ 1,500 ADA   │
└─────────────┘

Headを閉じる必要はない。

3. Incremental decommitは逆方向

Incremental decommitは、

Open中のHydra Headから一部UTxOだけをCardano L1へ取り出す

仕組みである。

Hydra Head

1,500 ADA
   ↓

500 ADAだけ取り出す

   ↓

Hydra Head     Cardano L1
1,000 ADA      500 ADA

Head自体は稼働し続ける。

4. なぜこれほど重要なのか

HydraのGitHub Issue #1057では、

Hydra Heads should not need to be closed to remove funds.

という趣旨が示されている。

また、long-living Headsを実現するためにincremental decommitが必要であることが明示されている。

つまり開発チーム自身が、

Hydraを長寿命Headへ進化させる

ことを意図している。

5. 銀行口座に例えると分かりやすい

従来Hydraは極端に言えば、

「入金したら最後に全部精算するまで資金構成を変えにくい共同金庫」

に近かった。

Incremental commit/decommit後は、

営業中の共同口座に追加入金・部分出金できる

ようになる。

6. Incremental commitの内部処理は意外に複雑

Cardano L1

① depositTx
      ↓
Deposit Script
      ↓
Hydra participantsが確認
      ↓
Snapshotで承認
      ↓
② incrementTx
      ↓
Hydra Head state更新
      ↓
L2で利用可能

主な流れは、

1. ユーザーがcommit要求を出す
2. depositTxを作成
3. ユーザーが署名しL1へ送信
4. 資金がdeposit scriptにロック
5. Hydra node群がdepositを観測
6. snapshot leaderがsnapshotへの組み込みを要求
7. 参加者が署名
8. incrementTx
9. HeadのL1状態が更新
10. そのUTxOがL2で利用可能

となる。

7. なぜdepositTxを一度挟むのか

もし、

「L1で入金したように見えた瞬間にL2で使える」

設計なら、Cardano L1のrollbackによって、

L1 deposit消失

しかし

L2では資金が存在

という状態になり得る。

これは、

L1とL2で同じ価値を二重利用できるdouble-spend

につながる。

そのためincremental commitでは、depositが十分に安定したことを確認してからL2で利用可能にする。

8. Deposit periodは「確定待ち」

Hydra nodeはdepositを見つけても即座には使わない。

一定期間、

L1 rollbackで消えないことを待つ

設計である。

公式documentationでは、例として、

• deposit period = 1 hour
• mainnetで約180 blocks
• attacker stake 15%想定
• rollback risk 約0.01%

というケースが示されている。

つまり、

L2高速性を保ちつつ、L1から新しく入る資産については慎重にfinalityを確認する

構造である。

9. 入金に失敗してもrecoverできる

depositTx
   ↓
Headが拾わなかった
   ↓
期限経過
   ↓
recoverTx
   ↓
ユーザーへ返却

deposit scriptは、

Headに渡すか、本人へ返すか

のどちらかへ安全に決着するよう設計されている。

10. Incremental decommitの内部処理

Hydra L2

UTxO A
UTxO B
UTxO C

 ↓ Bをdecommit

participants
全員で承認

 ↓

snapshot

 ↓

decrementTx

 ↓

Cardano L1
UTxO B

主な流れは、

1. decommit transactionを作る
2. 各participantが現在のL2 ledger stateに対してvalidityを確認
3. decommit要求をbroadcast
4. snapshot leaderがsnapshot生成
5. 全participantが署名
6. decrementTxをCardano L1にsubmit
7. 指定UTxOがL1へ出る

となる。

11. なぜ「全員のsnapshot署名」が重要なのか

例えばHeadに、

Alice 100 ADA
Bob   100 ADA
Carol 100 ADA

があり、Aliceの100 ADAをL1へ戻すとする。

もし、その100 ADAがL2でも残っていたら、

L1 Alice 100 ADA
+
L2 Alice 100 ADA

となる。

そこで参加者全員が、

「このUTxOはもうL2側の最新stateには含まれない」

というsnapshotへ署名する。

その署名証明を使ってdecrementTxがL1で実行される。

12. 一番重要な性質：他の取引を止めない

Issue #1057では、

Head should be live while decommitting

という要件が示されている。

Bobが100 ADAをL1へwithdraw中

その間

Alice ↔ Carol
取引継続

が可能になる。

13. これがDEXに効く理由

Head liquidity
1,000,000 ADA

↓ LP出金

700,000 ADA
Head継続

↓ 新LP入金

1,500,000 ADA
Head継続

つまりHydraは、

session-based channel

から、

dynamic liquidity venue

へ近づく。

14. Sugar Rush / Gummiworm / CLOBとの関係

高速DEXに必要なのは、

• 低レイテンシ
• 高TPS
• 高頻度order update
• liquidity追加
• liquidity撤去
• deposits
• withdrawals
• settlement

である。

incremental commit/decommitが加わることで、

流動性管理

まで改善する。

Cardano L1
    ↕
Incremental commit/decommit
    ↕
Hydra Head
    ↓
CLOB / matching
    ↓
高速取引

ただし、

HydraだけでCEX級CLOBが完成するわけではない。

matching engine、market maker、oracle、liquidation、UXなど別レイヤーが必要になる。

15. mutation testingとは何を確認しているのか

Mutation testingとは、

わざとコードに間違いを入れ、それをテストが確実に検出できるかを見る方法

である。

通常テスト：

正しいコード
↓
テスト
↓
PASS

Mutation testing：

正しいvalidator
   ↓
わざと条件を壊す
   ↓
テスト
   ↓
FAILするはず

それでもテストが通ってしまうなら、

テストが重要なsecurity constraintを検査していない

ことになる。

16. Specificationとの対応を見る意味

Hydraでは、

研究上の仕様
↓
formal / protocol specification
↓
validator implementation
↓
mutation testing

という対応を重視する。

incremental decommitでは特に、

• 二重払いしない
• decommit中もHeadが動く
• decrementTxが出なくてもclose/fanoutで資金が失われない
• 同じUTxOを二重にfanoutしない

などのpropertiesが重要になる。

17. v2.4.0でincremental commitにセキュリティ修正が入った意味

2026年9月1日公開のHydra v2.4.0では、incremental commitにsecurity fixが入った。

問題の本質は、

snapshotが「どのdepositを承認したのか」を、より厳密に識別する必要があった

ことである。

v2.4.0では、

snapshotがexactly which deposit it approvesを識別し、on-chain validator側でも強制する

方向へ修正された。

さらにrecoverTxも、

一度にsingle depositのみspendできる

よう制約が強化された。

18. これは「Hydraに重大事故があった」という意味ではない

公開情報から、

• mainnet exploitが実際に発生した
• ユーザー資金が盗まれた

とは確認できない。

したがって現時点では、

protocol-level vulnerability / correctness issueを修正した

と表現するのが適切である。

19. v2.4.0ではformal specificationも強化された

v2.4.0では、

• formal specification
• literate Agda
• Typst
• machine-checked security proofs
• differential testing

などの強化が進んでいる。

Specification
      ↓
machine-checked proof
      ↓
actual implementation
      ↓
differential testing

これは金融インフラを目指すL2として重要である。

20. Incremental commit/decommitはまだ何でも同時にできるわけではない

現在の設計では、

commitとdecommitはsequentialに処理する

方向である。

commit
commit
decommit
commit

を完全並列で処理するのではなく、

一度に一つのstate transitionを確実に合意する

設計である。

21. Decommitにも現時点の制約がある

Issue #1057では、当初のout-of-scopeとして、

• unsettled decommitを複数同時に出す
• closed Headからincremental decommit
• partial fanout

などが挙げられていた。

その後partial fanout等も進展している。

Hydraは、

dynamic liquidity
+
large UTxO state
+
partial fanout
+
formal verification

をまとめて長寿命Head向けインフラへ進化させている。

22. 「長期間Head」とはどれくらいか

v2.4.0では、

long-running nodesがera-history forecast horizonを超えるとL2 transactionsを拒否する問題

も修正されている。

これはHydraが、

日・週・さらに長期間動かすservice infrastructure

を現実に想定していることを示す材料である。

23. Hydra HeadはLightning Networkとは性格が違う

Hydraは、

payment channel

というより、

小さなCardano ledgerを複数参加者で高速に動かす

と理解する方が正確である。

24. Hydraの最終的な価値

Cardano L1
│
│ security / settlement
│
├── commit →
│
│    ┌────────────────────┐
│    │ Long-lived Hydra    │
│    │                    │
│    │ DEX                │
│    │ payment network    │
│    │ games              │
│    │ market making      │
│    │ micropayments      │
│    │ enterprise apps    │
│    └────────────────────┘
│
← decommit
│
Cardano L1

つまり、

L1＝最終決済・資産保全

Hydra＝高速な日常実行層

という役割分担になる。

25. Cardano全体として何が変わるか

本質は、

流動性を閉じ込めずにL2を長期間営業できる

ことである。

26. 今後見るべきKPI

特に、

平均Head寿命

が重要である。

27. 5段階シナリオ：Hydraの2027〜2029年

以下は推測によるシナリオ分析。

中心予想はS4〜S3。

28. CGTAの評価

今回のincremental commit/decommitを一言で言うなら、

Hydraを「高速な一時セッション」から「資金が出入りしながら営業を続ける常設L2」へ変える機能

である。

High TPS
        ↓
だけでは不十分

Dynamic liquidity
        +
Long-lived Head
        +
Safe settlement
        +
Formal verification
        ↓
実用金融インフラ

Sugar Rush × Gummiworm × HydraによるCLOB化を考える場合、TPS以上に重要なのがincremental commit/decommitである。

本当の取引所は速いだけでは成立せず、

流動性が常時追加・退出できなければならない

からである。

出典・情報源

• Hydra公式Protocol documentation

https://hydra.family/head-protocol/unstable/docs/dev/protocol

• Hydra GitHub Issue #1057

https://github.com/cardano-scaling/hydra/issues/1057

• Hydra v2.4.0 Release Notes

https://github.com/cardano-scaling/hydra/releases/tag/2.4.0

• Hydra GitHub Repository

https://github.com/cardano-scaling/hydra

• Hydra Releases

https://github.com/cardano-scaling/hydra/releases

作成日時: 2026-09-02 16:18 JST