FBLFuture BioCybernetics Lab未来サイバー生命体研究所[ OBSERVATORY ONLINE ]
← 観測ノート一覧

OBSERVATION NOTE / MDFOOB-HU

Cardano Weekly Development Report 2026-09-25 解説：Leios・Plutus V4・High Assurance・Hydra・Lace

EPOCH 6572026.09.30 JSTmiddle

2026-09-25付Cardano週次開発報告を、Leiosのproduction hardening、Plutus V4と形式検証、Hydraの実障害修正、Lace 2.3、Midnight・AI Agent経済との接続という観点から整理した解説。

出典・掲載情報

  • 主出典: Essential Cardano, "Weekly development report as of 2026-09-25"
  • 掲載日: 2026-09-25
  • URL: https://www.essentialcardano.io/development-update/weekly-development-report-2026-09-25
  • 関連出典:
  • Plutus Core Team Update: https://updates.cardano.intersectmbo.org/2026-09-23-plutus-core/
  • Hydra Weekly Update: https://cardano-scaling.github.io/hydra-updates/updates/2026-w38/
  • Lace 2.3: https://www.lace.io/blog/lace-2-3-small-refresh-big-changes
  • Ouroboros Leios repository: https://github.com/input-output-hk/ouroboros-leios
  • Ouroboros Consensus repository: https://github.com/IntersectMBO/ouroboros-consensus
  • Cardano High Assurance testing tutorial: https://github.com/input-output-hk/sc-testing-tools-tutorial
  • 補助資料:
  • Cardano Blockchain Ecosystem Constitution
  • Midnight Tokenomics and Incentives Whitepaper

一文要約

今回の週次報告は、Cardanoが新機能を増やすだけの段階から、Leios・Plutus・Hydra・Lace・形式検証を本番運用レベルへ仕上げる「production hardening」の段階へ深く入っていることを示す更新である。

結論

今回の週次レポートを一言でいうと、

Cardanoは「機能を増やす段階」から、「高スループット化・形式検証・L2・ウォレットを実運用レベルに仕上げる段階」へかなり深く入っている。

特に重要なのは、次の5本である。

  1. Leios
  2. Plutus V4 / Dijkstra
  3. High Assurance
  4. Hydra
  5. Lace + Midnight

公式週報の内容は、Plutusチーム、Hydraチーム、Lace公式の個別更新とも整合している。

CGTAの重要度整理

項目重要度今回の本質
Leios DB再設計★★★★★プロトタイプから実運用Node設計へ
Plutus V4 / CIP-0168 / CIP-0194★★★★★Script実行効率と表現力の底上げ
High Assurance / Z3 / CVC5 / Blaster★★★★★「動く」から「正しいと証明する」へ
Hydra fund-lockout修正★★★★☆実利用で出た資金拘束問題を修正
Lace 2.3★★★★☆DApp・DRep・Hardware Wallet・MidnightのUX改善

1. 今回最大のニュースはLeios

今回のLeios更新は、TPSの数字そのものより重要である。

以前は、

Leios protocol
↓
simulation
↓
prototype

という色合いが強かった。

今回、

rollback可能領域
+
確定済み領域

を別DBへ分離している。

認証済みEndorser Blockをバックグラウンドで確定側へ移し、別ディスク配置も可能にした。Garbage Collectionも、一気に削除してNodeを止める方式から、mark → batch deleteの段階処理へ変更されている。

つまり、

大量のEndorser Blockとtransactionを継続的に扱うNode運用を前提にし始めた

ということである。

Leiosの狙い自体も、Praosのsecurity propertyを保ちながらthroughputを上げることであり、開発リポジトリはR&Dからcardano-nodeを使ったengineering / prototypingへ移行している。

さらに、Leios有効化を想定したNode release candidateでは、次のような要件が重視される。

  • 通常のRanking Blockと巨大なEndorser Blockの同時生成
  • BLS12-381投票
  • Endorser Blockのdisk保存
  • 一般的なSPOが運用可能なhardware要件
  • adversarial testing

ここは重要である。

Leiosの思想は、

高性能なValidatorだけを要求する

ではなく、

余っているbandwidth / CPUを活用
↓
throughput増大
↓
Node要件の急激な上昇は抑える

という方向にある。

Cardano憲法のGuardrailsも、network parameter変更に際して、block propagation、SPO運用可能性、script executionなどのbenchmarkingを要求する。

つまり、

Leiosのengineering philosophyとCardano governanceのGuardrailが噛み合っている。

2. db-synthesizer / db-truncaterがLeios対応した意味

一見地味だが、かなり大事である。

db-synthesizer はbenchmark用のsynthetic chainを高速生成するtoolで、db-truncaterはchain DBを特定地点まで切り戻すtoolである。

今回これがLeios chainに対応した。

つまり、

Leios chainを大量生成
↓
性能測定
↓
reorg / rollbackを人工的に発生
↓
DB consistency確認
↓
stress test

が容易になる。

これは、

「Leiosを作るtool」だけでなく「Leiosを壊して確かめるtool」が整ってきた

という意味である。

成熟したprotocol開発では、この段階が重要である。

3. Block forgingをNode kernelから分離

これもarchitecture上重要である。

従来、

Node kernel
└ block forging

だったものを、

Node kernel
     ↓
Block forging module
     ├ step A
     ├ step B
     └ step C

という構造へ整理している。

メリットは、

  • instrumentationしやすい
  • benchmarkしやすい
  • unit testしやすい
  • Leios / Praos間で再利用しやすい
  • performance bottleneckを切り分けやすい

という点にある。

これは典型的な、

研究prototype → production software

へのrefactoringである。

4. Plutus V4はかなり大きく変わっている

今回のPlutus更新は単なるbug fixではない。

特に注目すべきは、

  • CIP-0168 keepPolicies
  • CIP-0168 dropPolicies
  • CIP-0194 Builtin Pattern Matching
  • Data.AssocMap
  • Data / List encoding
  • deserializer optimization

である。

以前の更新では keepPolicies / dropPolicies builtin自体はすでに追加され、残っているのはcost modelだった。

これらは将来protocol version、すなわちDijkstra系アップグレードまでon-chainでは有効化されない見込みである。

今回の位置づけは、

機能設計
↓
builtin実装
↓
cost model
↓
protocol upgrade
↓
mainnet利用

の後半戦である。

Cardanoではbuiltinを追加するだけでは足りない。

各operationに、

CPU cost
memory cost

を定量化し、cost modelへ組み込む必要がある。

Cardano憲法Guardrailsでも、新しいPlutus primitiveやlanguage versionを導入する際にcost modelが重要な安全装置として扱われている。

ここでも、

protocol engineeringとgovernance ruleが直接つながっている。

5. High AssuranceはCardanoのかなり特徴的な部分

今回特に注目すべきなのはここである。

High Assurance teamは、

property-based testing
static analysis
formal verification
SMT solver

を並行して強化している。

公式週報ではTransaction Graphとcoverage reportがmergedされ、さらに plu-stan のstatic-analysis rule、Blasterのhigher-order function formalization、Z3 / CVC5 backend改善が進行中である。

構造としては、

Smart Contract
│
├─ Property-based testing
│
├─ Static analysis
│
├─ Symbolic reasoning
│
└─ Formal verification
       ↓
      Z3 / CVC5

となる。

通常のDApp開発では、

testを通った

で終わることが多い。

Cardano High Assuranceは、

この条件では
このpropertyが
数学的に破れないか

まで踏み込もうとしている。

これは、Lean 4 / Z3 / SMT solverの流れとも直結する。

AI時代にはさらに重要になる

LLMがcontractを書く世界では、

AI generates code
↓
compiler
↓
tests
↓
formal / static verification
↓
deployment

というpipelineが自然になる。

今回tutorialに「LLM friends」と書かれているのは象徴的である。

これは単なる表現ではなく、

AI-generated smart contractをformal toolで機械検証する開発モデル

をCardanoが意識している可能性を示す。

これは推測だが、中長期では非常に重要である。

6. Hydraは「実利用で出た危険なedge case」を潰した

今回Hydraでは、ユーザーのdepositが3時間deposit scriptに拘束される問題が実際に発生した。

原因は、coverFee がmin ADAを補充したにもかかわらずdatumの値が更新されず、Node側のvalue-vs-datum checkがtransactionをrejectしたことだった。

今回の修正では、

transaction作成
↓
deposit validation
↓
問題あり
→ submission前にfail

というfail-fast設計へ改善した。

さらに、

DepositTooLow
providedValue
minimumValue

という具体的なerrorを返す。

これは非常に健全である。

Blockchainでは、

失敗することより「失敗したのに成功したように見える」ことの方が危険

である。

Hydraは今回、

silent failure
↓
fail-fast

へ改善した。

これはproduction hardeningとして重要である。

7. Test時間 114秒 → 1.3秒も地味に大きい

13本のslow E2E testを30本のunit testへ置き換え、

約114秒 → 約1.3秒

まで短縮している。

これは単なるCI高速化ではない。

testが速いと、

developer
↓
code
↓
test
↓
修正
↓
test

のcycleが圧倒的に速くなる。

さらにreplacement作業によって、

internal event 39ケースが実は十分testされていなかった

ことも発見された。

つまりtest refactoring自体がbug discovery mechanismになっている。

8. Lace 2.3は「wallet」からplatform frontendへ近づいている

Lace 2.3はかなり中身がある。

特に重要なのは4点である。

DApp connection

background workerがrestartしてもrequestを失わず、すでにconfirmedしたtransactionを失敗扱いしなくなった。

これはbrowser extension型wallet特有の現実的問題への対処である。

Hardware Wallet

Ledger / Trezor / Keystone / SeedSignerでsigningを改善している。

stake registrationとdelegation certificateを分離してdeviceへ渡すようになっている。

Midnight

Midnight account sync reset、DUST fee計算修正などが入っている。

Midnightでは、

NIGHT
↓
DUSTを継続生成
↓
DUSTをtransaction resourceとして消費

という構造を採る。

NIGHTそのものはtransaction時に消費されない。

したがって「spendable DUST」を正しく計算することは、単なるwallet UIではなく、

Midnight economic modelそのものをwalletが正確に反映すること

である。

9. DRep browser変更はBWtakeには直接重要

Lace 2.3ではDRep browserのorderingが、

stake weight

中心から、

quality signals

中心へ変更された。

これはDRep ecosystemにとって重要である。

Cardano Constitutionでは、ADA holderがDRep candidateを探索・評価できるtoolの整備をcommunityに期待している。

つまり、

巨大stakeを持つDRep
=
最上位表示

ではなく、

活動
情報開示
投票品質
policy compliance

などのsignalを重視する方向へ進む。

これはliquid democracyのUXとして自然である。

一方で、

quality signalの具体的weightingは透明であるべき

である。

アルゴリズムが不透明だと、wallet vendorがDRep visibilityを事実上左右する可能性がある。

ここはDRepとして今後チェックすべきポイントである。

10. 今回の週報全体をどう読むべきか

今回のupdateを単独で見ると地味である。

しかし、レイヤーを並べるとかなり面白い。

Leios
↓
L1 throughput

Plutus V4 / Dijkstra
↓
Smart Contract efficiency

High Assurance
↓
Contract correctness

Hydra
↓
L2 scalability

Lace
↓
User / DApp interface

Midnight
↓
privacy + resource economy

これらが同時に成熟している。

つまりCardanoは現在、

protocol単体を改善しているのではなく、execution・scaling・verification・wallet・privacyまでstack全体を一斉にproduction化している

段階にある。

AI Agent時代という観点ではもっと面白い

最近の、

x402
Masumi
Midnight
AI Agent

という流れと今回のupdateを重ねると、意味が明確になる。

AI agentが大量にtransactionを発生させる世界では、

Throughput
    → Leios

安いL2 transaction
    → Hydra

Contract safety
    → Formal verification

Agent wallet / identity / signing
    → Lace / wallet infra

Privacy
    → Midnight

Smart contract execution
    → Plutus V4

が全部必要である。

つまり今回のupdateは、

AI Agent economyに必要な基礎部品を、別々のteamが同時に仕上げている

とも読める。

5段階シナリオ分析

今後12〜24か月について、CGTAの現時点推定を示す。

Scenario確率状況
S515%Leios・Dijkstra・Hydra・Midnight・AI agent stackが連動し、Cardanoが高信頼AI transaction infrastructureとして明確な地位を得る
S435%Leios / Dijkstraが順調に実装され、性能と開発UXが大きく改善。実利用も徐々に増える
S335%技術は完成するがDApp / ユーザー増加は漸進的。技術優位が経済活動へ転換するまで時間がかかる
S212%LeiosやDijkstraのproduction移行に遅延し、複雑化によってecosystem成長が鈍る
S13%integration上の重大問題やdeveloper adoption不足で主要roadmapが大幅後退する

最頻シナリオは S3〜S4 と考える。

技術的な進行にはかなり実体がある。

一方で、

技術完成 = 利用増加

ではない。

ここは分けて評価する必要がある。

CGTAの今回の結論

今回一番重要なのはLeiosのTPSそのものではない。

Leiosが「動くprototype」から、「rollback・DB・disk・GC・benchmark・recoveryまで考えたproduction system」へ変わってきたこと

である。

そして同じ週に、

  • Plutusのexecution optimization
  • Z3 / CVC5 formal verification
  • Hydraのreal-world failure修正
  • LaceのDApp / hardware / Midnight UX
  • DRep discovery改善

が並行している。

これはかなり典型的な、

research phase
     ↓
engineering phase
     ↓
production hardening phase

の3段階目へ入りつつあるサインである。

今後追うべき3点

  1. Leiosがいつprototypeからcardano-node release candidateへ昇格するか
  2. DijkstraでPlutus V4 builtin群がmainnet有効化される時期
  3. LaceのDRep quality signalの具体的評価ロジック

この3点は、Cardanoの技術成熟とガバナンス成熟の両方を測る観測点になる。

Epoch情報

2026-09-25は Cardano Epoch 657 に該当する。

  • Epoch 657開始: 2026-09-22 06:44:51 JST
  • Epoch 657終了: 2026-09-27 06:44:51 JST

参考資料

  1. Essential Cardano, Weekly development report as of 2026-09-25

https://www.essentialcardano.io/development-update/weekly-development-report-2026-09-25

  1. Plutus Core Team Update, 2026-09-23

https://updates.cardano.intersectmbo.org/2026-09-23-plutus-core/

  1. Hydra Weekly Update, 2026-W38

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

  1. Lace 2.3 - Small refresh, big changes

https://www.lace.io/blog/lace-2-3-small-refresh-big-changes

  1. Ouroboros Leios

https://github.com/input-output-hk/ouroboros-leios

  1. Ouroboros Consensus

https://github.com/IntersectMBO/ouroboros-consensus

  1. Cardano High Assurance - Smart Contract Testing Tools Tutorial

https://github.com/input-output-hk/sc-testing-tools-tutorial

  1. Cardano Blockchain Ecosystem Constitution
  1. Midnight Tokenomics and Incentives Whitepaper

作成日時: 2026-09-30 23:37 JST