• Cardano Development Updates — Ledger Team Update, 2026-09-30

https://updates.cardano.intersectmbo.org/2026-09-30-ledger/

• Cardano Development Updates — Performance & Tracing Update, 2026-09-30

https://updates.cardano.intersectmbo.org/2026-09-30-performance-and-tracing/

• Hydra — Week 39 · 2026

https://cardano-scaling.github.io/hydra-updates/updates/2026-w39/

• Lace — Lace 2.4: We’re moving quickly

https://www.lace.io/blog/lace-2-4-we-re-moving-quickly

• Lace — RealFi, built into Lace

https://www.lace.io/blog/realfi-built-into-lace

• Input Output Research — Reserve Depletion and Security Runway in Proof-of-Stake Systems

https://www.iog.io/papers/reserve-depletion-and-security-runway-in-proof-of-stake-systems

一文要約： 今週のCardanoは目立つ単独機能の追加よりも、Dijkstraを接続点としてLeios・Plutus V4・Hydra・Midnight・RealFiが実装レベルで結び付き始めたことが重要であり、Cardanoの次世代アーキテクチャが「研究」から「統合工程」へ進んでいる。

現在地点

2026年10月2日 JST。Cardanoは Epoch 659 に入っている。

今回の開発報告を一言でまとめるなら、

Cardanoの次世代構成要素が、それぞれ独立した研究テーマではなく、同じLedger・Wallet・Scaling基盤の上で接続され始めた週

と見るのが最も分かりやすい。

Leios、Dijkstra、Plutus V4、Hydra、Lace、Midnight、RealFiは、一見すると別々の開発テーマに見える。

しかし実際には、次のような一本の流れとして読める。

Cardano L1
   ↓
Dijkstra Era
   ↓
Leios / Plutus V4 / Sub-transactions
   ↓
Hydra
   ↓
Lace
   ↓
RealFi / Midnight

つまりCardanoでは、

• L1の処理能力
• Ledger表現
• スマートコントラクト
• L2
• Wallet
• DeFi
• Privacy

が別々に進んでいるのではなく、次世代スタックとして接続されつつある。

重要度一覧

1. Leiosは「研究」から「Ledger統合」に進み始めている

今回最も重要なのはLeiosである。

これまでLeiosは、

研究
↓
プロトタイプ
↓
テストネット

という文脈で語られることが多かった。

しかし今回のLedger Team Updateでは、Leiosに必要な要素がCardano Ledger側へかなり具体的に入り始めている。

主な変更は、

• Epoch境界でLeios committeeを選択
• KES期限切れに合わせてBLS keyを失効
• DijkstraのPOOL ruleでBLS Proof of Possessionを検証
• Leios announcement block headerへの参照を追加
• DijkstraからLeiosをforecastする処理
• Leiosを扱えるblock header abstraction

などである。

これは重要な変化である。

Leiosが単独の実験コードではなく、

Cardano LedgerがLeiosを理解するための構造を持ち始めている

からだ。

ただし、ここは区別が必要である。

Leios mainnet導入が確定したという意味ではない。

現在確認できるのは、

Leiosを将来Cardanoの正式なeraへ接続できるよう、Ledger構造が準備されている

という段階である。

2. BLS Proof of Possessionが入る意味

LeiosではBLS署名が重要になる。

BLS署名には、

• 署名を集約しやすい
• 複数の署名者を効率よく扱える

という利点がある。

Leiosのように、多数のノードが並列的にblockやcertificateへ関与する設計とは相性がよい。

しかしBLSでは、公開鍵を悪用した rogue-key attack のような問題を考慮する必要がある。

そこでProof of Possessionを使い、

この公開鍵を登録した人物が
対応する秘密鍵を本当に保持している

ことを証明する。

今回DijkstraのPOOL ruleにBLS Proof of Possession検証が入ったのは、

Leios用の暗号鍵管理がCardanoのstake pool登録ルールへ接続され始めた

ことを意味する。

さらに、

KES key lifetime
     ↓
BLS key lifetime

を関連付けている点も重要である。

Leios用BLS鍵だけが無期限に残るような設計ではなく、Cardano既存のoperational key lifecycleと整合させようとしている。

3. LeiosはSPOの実機性能を測る段階に入った

Performance & Tracing Teamは、Leios向けtransaction validation benchmarkを自己完結型の実行ファイルとしてSPOへ配布している。

これはかなり重要である。

従来のbenchmarkは、

開発者環境
↓
性能測定

になりやすい。

今回の方式では、

実際のSPO hardware
↓
LedgerDB
↓
transaction validation
↓
disk I/O

を測る。

特にLeiosでは、CPUだけでなくI/Oがボトルネックになる可能性がある。

そのため、

• SSD
• filesystem
• kernel
• mount option
• storage connection
• memory
• CPU

などの差が重要になる。

つまりLeiosは、

「理論上何TPS出るか」

から、

「世界中の実際のSPO環境でどこまで安全に動くか」

という実装フェーズへ進んでいる。

これはmainnet化に向けて避けて通れない工程である。

4. Dijkstraは単なる次回Hard Forkではなくなってきた

今回の更新を追うと、Dijkstraの位置づけがかなり見えてくる。

Dijkstraには、

• Leios
• Plutus V4
• Sub-transactions
• reference input cost
• 新しいblock header abstraction
• Dijkstra-era transaction hashing
• 将来のPeras parameter

などが集まっている。

したがってDijkstraは、

単に新機能を追加するHard Forkではなく、次世代Cardanoを接続するためのLedger世代

と考えた方がよい。

概念的には、

Conway
   ↓
Governance完成
   ↓
Dijkstra
   ↓
次世代execution / scaling / consensus拡張

という流れになる。

VoltaireによってCardanoは「誰が決めるか」を実装した。

Dijkstra以降は、

その統治されたネットワークが、どのような次世代技術構造を採用するか

という段階へ移る。

5. Plutus V4とSub-transactionsが重要な理由

今回Ledger Teamは、

• GuardingPurpose向けPlutus V4 context
• sub-transaction indexをPlutus contextへ追加

を進めている。

これはかなり重要である。

従来のCardano transactionは大きく、

Transaction
 ├ Input
 ├ Output
 ├ Mint
 ├ Withdrawal
 └ Script

という単位で考える。

Sub-transactionが進むと、

Top Transaction
   ├ SubTx 0
   ├ SubTx 1
   ├ SubTx 2
   └ SubTx 3

のように、一つの大きな取引内部へ複数の処理単位を持てる。

そしてPlutus側から、

自分はいま何番目のSubTxなのか

を認識できるようになる。

これにより将来的には、

• batch processing
• complex DeFi
• intent-based transaction
• 複数主体によるtransaction composition
• Account的なUX
• AI Agentによる複合取引

との相性が良くなる。

6. CardanoがAccount Modelになるわけではない

ここは重要な区別である。

Sub-transactionsやCIP系のaccount拡張が増えても、

CardanoがEthereum型Account Modelへ移行する

という意味ではない。

Cardanoの基本思想は依然としてeUTXOである。

つまり、

eUTXO
+
より高度なtransaction abstraction

という方向である。

これはかなり面白い設計である。

Ethereum系は、

Account Model
↓
parallel executionを後から工夫

している。

Cardanoは逆に、

eUTXO
↓
決定論的transaction
↓
必要な抽象機能だけ追加

という方向へ進んでいる。

うまくいけば、

eUTXOの予測可能性を保ちながら、Account Modelに近い使いやすさを上乗せする

という形になる。

7. AI Agentとの相性

ここはBWtakeが以前から追っているテーマともつながる。

AI Agentがblockchainを使う場合、

AI Agent
↓
意図を生成
↓
複数条件を満たすtransactionを構築
↓
署名
↓
実行

となる。

人間ならWallet画面で複数回操作しても問題ない。

AI Agentでは、

一つのtransactionへ複数の操作を安全に束ねられる方が扱いやすい。

そのため、

AI Agent
   ↓
x402 / Masumi
   ↓
Wallet
   ↓
Plutus V4
   ↓
Sub-transactions
   ↓
Hydra / Leios

という組み合わせは非常に興味深い。

現時点でこれがCardano公式の完成済みAI Agent architectureとして宣言されているわけではない。

推測ですが、技術構成を見る限り、この方向との親和性はかなり高い。

8. Hydra delegated headは地味だが重要

Hydra Week 39ではdelegated-head demoが進んだ。

特に重要なのは、

Hydra operator自身が資金をcommitしなくてもHeadを運用できる

という点である。

ユーザーが、

L1
↓
Hydra Headへdeposit
↓
Head内で取引
↓
L1へwithdraw

できる。

operatorはサービスを提供するが、operator自身の資金をHeadへロックする必要がない。

これはHydraを、

個人が使うL2

から、

service infrastructure

へ近づける。

応用候補としては、

• exchange
• game
• payment service
• micropayment
• AI Agent network
• machine-to-machine settlement

などが考えられる。

9. JavaScriptから直接L1 depositできる意味

今回のdemoでは、JavaScriptでdeposit transactionを構築し、そのままCardano L1へsubmitする例が示された。

ここも重要である。

つまり、

App
↓
hydra-node API
↓
deposit

だけではなく、

App
↓
Cardano transaction
↓
L1
↓
Hydra

という経路も作れる。

これはapplication developerにとって大きい。

Hydra専用APIへ強く依存せず、Cardano transactionとしてdepositを組み込める可能性があるためである。

L2が、

特殊な閉じた環境

ではなく、

Cardano transaction infrastructureの延長

として扱いやすくなる。

10. HydraのBacklogFull改善

Hydra nodeでは以前、

pending message >= 1000

になるとBacklogFullと判定していた。

しかしqueueが1000件あっても高速で処理できていれば、本当に詰まっているとは限らない。

今回、

queue length

だけではなく、

estimated drain time
+
recent completion rate
+
no progress duration

を見る方向へ改善された。

これはnetwork congestion detectionとして合理的である。

たとえば、

1000 messages
処理速度 1000/sec

なら大きな問題ではない。

一方、

200 messages
処理速度 1/min

なら深刻かもしれない。

つまり、

queue sizeではなく「処理可能性」を見る

方向になった。

11. Lace 2.4はWalletから金融OSへ向かっている

Lace 2.4では、

• swap review強化
• DApp signing queue
• signing error表示
• Midnight sync改善
• raw Midnight transaction表示
• Ledger Cardano App V8対応

などが入った。

単体ではWallet改善に見える。

しかしRealFi統合と合わせると意味が変わる。

Laceは、

Wallet

から、

Wallet
+
DeFi
+
Stablecoin
+
Yield
+
Midnight
+
DApp

へ変わりつつある。

つまり、

WalletではなくCardano ecosystemのFinancial OS

に近づいている。

12. RealFiがLaceへ直接入った意味

RealFiはLace内へ統合され、

• stablecoin
• yield
• USDrf
• sUSDrf
• RealFi dashboard

をWalletから扱える。

ここで重要なのはtransaction bundlingである。

従来DeFiでは、

Token approve
↓
deposit
↓
mint
↓
stake

など複数の操作が必要になりやすい。

RealFiでは複数ステップをまとめ、

Lace
↓
review
↓
approve

に近づけようとしている。

これはUX上非常に重要である。

Cardanoの弱点の一つは、技術的には安全でも、

初心者にはtransaction構造が理解しにくい

ことだった。

Laceの方向性は、そのギャップをWallet側で吸収するものと読める。

なおRealFiには地域制限や金融リスクがあるため、利用可能地域・商品リスクについては公式条件を確認する必要がある。

13. Lace × Midnightの統合が進んでいる

Lace 2.4ではMidnight関連もかなり進んだ。

主な変更は、

• wallet stateを個別保存
• sync progressを最も遅い処理に合わせる
• shielded walletを標準Midnight SDK event streamへ
• remote proof server option削除
• raw transaction data表示
• multi-token send修正
• partial success表示改善

である。

さらに近く、

Cardano accountで保有するcNIGHTからDUSTを生成

できる機能が予定されている。

これは非常に重要である。

Cardanoユーザーの視点では、

Cardano account
↓
cNIGHT
↓
DUST generation
↓
Midnight

がWalletの中でつながる。

つまりCardanoとMidnightの関係が、

別chain

から、

同一UX上の複数network

へ変わっていく。

14. DUSTとNIGHTの設計がWallet UXへ入る意味

Midnightの経済構造では、

NIGHT
↓
DUST生成能力
↓
transaction利用

という関係が重要になる。

この仕組みがLaceへ入ると、ユーザーは理論を理解するだけでなく、

NIGHTを保有
↓
DUSTを生成
↓
Midnight transaction

をWallet操作として体験するようになる。

トークノミクスは、Wallet UXへ落ちた時に初めて一般ユーザーへ届く。

したがってLaceのcNIGHT→DUST対応は、単なるWallet機能追加ではなく、

Midnight tokenomicsを利用者の行動へ接続する機能

と見るべきである。

15. Node 11.1.1の性能

Performance & Tracing Teamによると、Node 11.1.1ではCPU使用量改善が維持されている。

一方で、

memory usage increase

は11.1.0より小さくなったものの、まだ測定可能である。

原因候補として、

• ledger snapshotting
• cyclic event

との相関が示されている。

mainnetでも観測されているが、現時点ではoperational riskにはなっていないと報告されている。

ここは、

CPU ↓
Memory ↑

という単純なtrade-offと断定する段階ではない。

原因解析と今後のbenchmarkを継続して見る必要がある。

16. tx-generatorがDijkstra対応した意味

tx-generatorがDijkstra-era transactionを生成できるようになった。

さらにtransaction streamを、

• plain text
• raw CBOR

としてdiskへ保存できる。

これはtest infrastructureとして重要である。

将来的には、

tx-generator
↓
transaction workload file
↓
db-synthesizer
↓
Praos / Leios chain fragment

という形で、大規模benchmark環境を高速に構築できる。

Leiosのような大型変更では、

本番ネットワークで初めて性能問題が分かる

という状態は避けなければならない。

そのため、本番に近いworkloadを人工的に再現する能力が重要になる。

17. Hermod Tracing

Dijkstra Hard Fork以後のnode versionでは、現在のtrace-dispatcherからHermod Tracingへの移行が計画されている。

Hermodでは、

• live trace filter reconfiguration
• tracer定義の一元化
• documentationとの整合
• nested span tracing

などを目指している。

これは一般ユーザーには目立たない。

しかしSPO運用では、

問題発生
↓
trace
↓
原因特定
↓
対応

が非常に重要である。

ネットワークが複雑になるほどobservabilityの価値は増える。

Leios、Hydra、Midnightなど周辺システムが増えるCardanoでは、監視・追跡の基盤強化は不可欠である。

18. Reserve Depletion研究はDRepに重要

今回の研究論文、

Reserve Depletion and Security Runway in Proof-of-Stake Systems

はDRepとしてかなり重要である。

従来PoSのreserve問題は、

Reserveがいつ枯渇するか

という議論になりやすい。

しかし論文の主張は、より重要な点を指摘している。

本当に重要なのは、

Reserve
+
Token price
+
Transaction demand
+
Validator participation
+
Security requirement

である。

同じReserve量でも、

ADA価格が高い
transaction demandが大きい

場合と、

ADA価格が低い
transaction demandが小さい

場合ではsecurity runwayが違う。

19. Reserveはゼロになる前に問題になる可能性がある

論文の重要な考え方は、

Reserve failure ≠ Reserve = 0

という点である。

必要security levelを維持するために必要なvalidator rewardを確保できなくなれば、reserve残高が残っていてもsecurity runwayは終わる可能性がある。

概念的には、

Security Budget
=
Reserve subsidy
+
Fee revenue

であり、

その外貨換算価値にはtoken priceが関わる。

したがってDRepが長期財政を見る時、

Reserve残高

だけを見るのは不十分である。

20. 3つの領域

論文では概念的に、

1. infeasibility
2. reserve-dependent security
3. fee-only security

という3つの領域を考える。

理想は、

Reserve-dependent
↓
Fee revenue成長
↓
Fee-only security

への移行である。

つまりCardanoにとって長期的に重要なのは、

Reserveを長く残すことそのものではなく、Reserveが必要なくなるほど経済利用を増やすこと

である。

この視点では、

• DeFi
• Stablecoin
• RealFi
• Midnight
• AI Agent
• payment
• Hydra
• Leios

は単なるecosystem成長ではない。

最終的には、

Cardano security budgetをfee economyへ移行するための需要形成

という意味も持つ。

21. DRepとして見るべき指標

今後DRepとしては、少なくとも次を継続的に見る価値がある。

特にLeiosではblockspace supplyが増える可能性がある。

これは良いことだが、

供給増
↓
fee単価低下

が起きれば、throughputが増えてもfee revenueが十分増えない可能性もある。

逆に、

供給増
↓
新規需要増
↓
transaction総数増
↓
fee revenue増

ならsecurity budgetにはプラスになる。

したがって、

TPSだけではなく、network economyを見る必要がある。

22. 全体像

今回のdevelopment updateをまとめると、Cardanoの設計は次のように見える。

                Cardano Constitution
                        │
                        ▼
                   Governance
                        │
                        ▼
                   Dijkstra
                ┌───────┴────────┐
                ▼                ▼
             Leios          Plutus V4
                │                │
                └───────┬────────┘
                        ▼
                 Transaction Layer
                        │
                        ▼
                      Hydra
                        │
                        ▼
                      Lace
                ┌───────┴────────┐
                ▼                ▼
             RealFi           Midnight
                                  │
                                  ▼
                            NIGHT / DUST

さらにAI Agentを加えると、

AI Agent
   ↓
x402 / Masumi
   ↓
Wallet
   ↓
Plutus V4 / SubTx
   ↓
Hydra / Leios
   ↓
Cardano
   ↔
Midnight

という構造が見えてくる。

この全体像が重要である。

23. 「憲法 × eUTXO × Midnight」に何が加わったか

BWtakeが以前から重視している、

Cardano Constitution
×
eUTXO
×
Midnight

という三要素に、今回の開発を見ると新たに、

Leios
+
Wallet UX

が加わりつつある。

意味を整理すると、

つまり、

Governance
+
Deterministic execution
+
Privacy
+
Scaling
+
UX

がそろい始める。

これはCardanoの長期設計が、ようやくユーザーが触れる形へ収束し始めていると見ることもできる。

24. シナリオ分析

以下は事実ではなく、2026年10月2日時点の技術進捗をもとにしたCGTAのシナリオ推定である。

現在の中心シナリオは S4〜S3 と考える。

理由は、

• LeiosはprototypeだけでなくLedger統合へ進んでいる
• SPO実機benchmarkが始まっている
• Dijkstraに次世代機能が集約している
• Plutus V4/SubTxが実装段階
• Hydraは運用性改善が続く
• MidnightがLaceへ統合されつつある
• RealFiもLaceへ入った

ためである。

一方で、まだ確認できていない最大のポイントは、

これらの技術進歩が、実際のtransaction demand・developer adoption・fee revenueへどこまで転換されるか

である。

結論

2026年10月2日のCardano Weekly Developmentを見て、一番重要なのは新しい派手な機能ではない。

最大の変化は、

Cardano Ledgerそのものが、Leios・Plutus V4・Sub-transactions・Dijkstraを受け入れる次世代構造へ再編され始めていること

である。

そしてユーザー側では、

Lace
↓
RealFi
↓
Midnight

がつながり始めている。

つまり、

Protocol
↓
Execution
↓
Scaling
↓
Wallet
↓
Financial application
↓
Privacy

という縦のstackが見え始めた。

Cardanoは長い間、

「技術は多いが、それぞれが別々に見える」

という弱点があった。

しかし今回の更新では、それらがDijkstraとLaceを軸に接続され始めている。

BWtakeが以前から見ている

Constitution × eUTXO × Midnight

という構図に、

Leios × Wallet UX

が加わり、Cardanoの設計思想が「制度・実行・privacy・scaling・利用者体験」の一つのstackへ近づいている。

今後見るべき焦点は明確である。

1. LeiosがSPO実機測定を経てどのhardware profileへ収束するか
2. DijkstraのHard Fork時期と仕様確定
3. Plutus V4/Sub-transactionsがDApp設計をどう変えるか
4. Hydra delegated headが実サービスへ採用されるか
5. cNIGHT→DUST生成がLaceで正式提供されるか
6. RealFiがCardanoのstablecoin利用量を増やせるか
7. transaction demandとfee revenueがPoS security runwayを支えられるか

この7点を追えば、Cardanoの「技術開発」が「経済圏の成長」へ転換しているかをかなり正確に判断できる。

作成日時: 2026-10-03 00:01 JST