今週のCardano開発週報は、ひとつの大型機能が発表された週ではありません。
その代わり、古い基盤を整理し、次世代プロトコルを台帳へ組み込み、ウォレット、開発環境、スケーリング技術を実際に使える状態へ近づける動きが、複数のレイヤーで同時に進みました。
SIPO視点で重要なのは、次の5点です。
- 約11,000行の旧トレーシング基盤を削除し、観測基盤をHermodへ再編
- LeiosCertがDijkstraBlockBodyへ入り、LeiosがCardano本体の台帳へ接続
- Lace 2.1がwallet security checkと幅広いUX改善を導入
- Plutusの形式的保証と、contracts-library・cardano-initの開発者導線が前進
- HydraとMithrilが障害対策・設定・配布を強化し、Voltaireと研究も透明性を高めた
1｜観測基盤の刷新：約11,000行を削除し、Hermodへ再編
Core Technologyで最初に注目したいのは、新機能の追加ではなく、大規模な技術的負債の整理です。
performance and tracingチームは、cardano-nodeから旧iohk-monitoringベースのtracing backendを削除しました。
削除されたのは、15モジュールにまたがる約11,000行の古いコードと、9つの推移的build dependencyです。
さらにcardano-tracerからRTViewを削除しました。RTViewが担っていた機能は、Grafana datasourceとtimeseries serverによってカバーされるようになっています。
trace-dispatcherについても、今後はhermod-tracing-apiとhermod-tracing-coreの2パッケージへ分割する作業が進められています。
狙いは、計測用のinstrumentationだけが必要な下流パッケージに、tracing backend全体を依存させないことです。
また、cardano-tracerのtimeseries HTTP APIとGrafana datasourceがマージされ、メトリクスの時系列データに対してPromQLに似たクエリを使えるようになりました。cardano-recon-frameworkとtrace-resourcesも、Hermod Tracing Systemへ移されています。
ここで重要なのは、Cardano nodeの状態を「動いているかどうか」だけでなく、何が起きているのかを運用者が追跡しやすくすることです。
一方、ベンチマーク結果は慎重に読む必要があります。
最適化版は、システムが完全に飽和した条件でprocess CPU usageを約17%削減しました。しかし、block adoption timeには3〜6%の小幅な増加が見られました。
そのため、現在のPraos nodeでは、引き続きdefault buildが推奨されています。
SIPOとしては、この留保も重要だと考えます。
ベンチマークの一つの数字だけを取り上げて「17%高速化」と評価するのではなく、CPU負荷、ブロック採用時間、実際の稼働条件をまとめて見て、初めて本番設定を判断できるからです。
今週のCore Technologyは、コードを増やすことよりも、古い仕組みを外し、観測基盤を分離し、運用判断に必要なデータを扱いやすくすることに力を使った進捗でした。
2｜LeiosがDijkstra台帳へ：研究からCardano本体の構造へ
ledgerチームでは、Leiosに関する最初の変更が台帳へ入りました。
具体的には、LeiosCert typeがDijkstraBlockBodyのoptional fieldとして追加され、protocol-level codeを収める新しいcardano-protocol packageも導入されました。
これは、Leiosのメインネット実装が完了したという意味ではありません。
しかし、Leiosが研究文書やreference implementationの外側へ出て、次のledger eraであるDijkstraのblock body設計に接続し始めたという意味で、重要な一歩です。
性能面では、StAnnTx memoizationがAlonzoまで拡張され、関連するすべてのledger eraへの統合が完了しました。
トランザクション検証で繰り返し計算する情報を保存・再利用する仕組みを、eraをまたいで整える作業です。
また、長期にわたって進められてきたlegacy Coders machineryの削除も完了しました。
Dijkstra eraでは、withdrawalsとdirect depositsを扱う新しいENTITIES ruleが追加され、ledger ruleの構造整理と、3回目となるDijkstra conformance testingが進んでいます。
利用者に影響する2件の不具合も修正されました。
ひとつはPlutus cost model overrideに関する問題、もうひとつは本来起きるべきではないTxInfo translation failureを引き起こす問題です。
SIPO視点で今週最大の意味を持つのは、LeiosとDijkstraが別々の開発テーマではなくなりつつあることです。
Dijkstraは次の台帳時代を整え、LeiosはCardanoのスループットとブロック処理を進化させる設計です。
その両者が同じblock bodyとprotocol packageの中で接続され始めたことで、Cardanoの次世代設計が少しずつ「本体側の実装順序」へ移っています。
3｜Lace 2.1：セキュリティ確認を利用者の手元へ
Wallets and Servicesでは、Lace browser extension 2.1がリリースされました。
今回の中心は、wallet security checkです。
ウォレットを復元する際、または任意のタイミングでチェックを実行し、そのウォレットが既知のセキュリティインシデントの影響を受けた可能性があるかを確認できます。該当する場合には、状況に応じた案内も表示されます。
これは、ウォレットの安全を無条件に保証する機能ではありません。
未知の攻撃、フィッシング、悪意ある署名要求、端末侵害、シードフレーズの漏えいなど、あらゆるリスクを検出できるわけではないからです。
それでも、既知の事故情報と利用者のウォレット確認を同じ導線に置くことには大きな意味があります。
Cardanoのセキュリティ情報が、SNSや外部告知を探しに行かなければ届かないものではなく、日常的に使うウォレットの中から確認できる方向へ進むためです。
Lace 2.1ではこのほか、token management、send flow、DRep ID support、network resilience、DApp experience、hardware wallet機能、安定性と操作性が幅広く改善されています。
さらに、今後予定されているLace Carbon opt-in betaに向けた土台にもなります。
Lace Carbonはまだ一般公開された完成版ではありません。
今回の2.1は、コミュニティが将来の新しい体験を試し、feedbackによって形を整えるための準備段階です。
SIPOとしては、プロトコルの進歩と同じくらい、「利用者が安全に使える入口」が重要だと考えます。
台帳やスケーリングが高度になっても、利用者がウォレット上で異常に気づけず、送金や署名で迷う状態では、技術は社会的な利用へつながりません。
Lace 2.1は、その最後の接点を強くする更新です。
4｜PlutusとDeveloper Experience：厳密さと始めやすさを同時に
Smart Contractsでは、Plutusチームがperformance、tooling、assuranceを並行して改善しました。
Valueに関する一般的な処理を効率化し、特定のrecursive functionに対する新しいcompiler optimizationを追加。さらに、プログラムの挙動を正しく保つようoptimization passを修正しています。
UPLC executableには軽量benchmark機能が追加され、UPLC scriptの実行時間を手早く確認し、既存のbenchmark infrastructureと比較しやすくなりました。
仕様と形式手法の面では、built-in value typeと関連関数に関するUPLC specificationを更新し、compiler transformationを検証するmetatheoryとcertification infrastructureを改善しています。
ここで大切なのは、単に「速くする」のではなく、最適化後もプログラムの意味が変わっていないことを検証できる基盤を強くしている点です。
同時に、Developer Experience initiativeも本格的に始動しました。
contracts-libraryでは最初のreference contractが用意され、再利用可能なprotocolとpatternとして20項目がresearch・triageの対象になっています。
cardano-initでは、specification、初期proof of concept、plugin architectureが整い、Aiken、MeshJS、必要なinfrastructureを含むシンプルなprojectをすでに作成できる段階に入りました。
Cardano開発では、厳密な台帳モデルやPlutusの形式的保証が強みである一方、最初のプロジェクトを立ち上げるまでの学習コストが課題になりやすい面があります。
SIPOの見方では、今週の進捗はその両側を同時に前へ進めています。
内部では、compiler transformationを正しく証明できる基盤を整える。
外側では、reference contract、再利用可能なpattern、project generatorによって、開発者が正しい出発点を選びやすくする。
Cardanoの開発者体験は、簡単さだけを追うのではなく、「正しく始めやすい」方向へ進もうとしています。
5｜Hydra・Mithril・Voltaire・Research：性能から運用へ
Scalingでは、HydraとMithrilがともに、実運用を意識した改善を進めました。
Hydraは、hydra-nodeをひとつのYAML fileから設定できる仕組みをマージしました。
operatorは設定全体を一か所で管理し、peer間のconfigurationも比較しやすくなります。
また、depositとrecoveryに関するchain observationを、それを生成したheadの範囲に限定しました。これにより、複数headを扱う際に別のheadの情報が混入するcross-head contamination問題を解消しています。
Blockfrost backendは、HTTP errorで停止するのではなくretryし、inline datumもより安定して扱えるようになりました。
さらにevent storeでは、VACUUMとstreaming client historyの競合、そしてnetwork layerのoutbound message queueで発生し、broadcastを気づかないまま停止させる可能性があったdeadlockを修正しています。
これらはTPSのような見栄えのする数字ではありません。
しかし本番運用では、設定を比較できること、外部API障害から回復できること、複数headの状態を混同しないこと、メッセージ配信が静かに止まらないことが不可欠です。
Mithrilでは、recursive SNARK aggregation primitivesに向けたprover inputの準備、unsafe SNARK setupのrefactor、Midnight libraryの分離、回路のdegreeが変化しないことの確認、gadgetを使ったcircuit modularityの改善が進みました。
aggregator state machineにBlocked stateを持たせる作業や、end-to-end execution logをartifactとして保存する作業も続いています。
さらに、Mithril signer node binaryをCardano node bundleに同梱する取り組みも進行中です。
distribution 2628のリリース、Cardano node 11.1、DMQ node 0.7.0.0、midnight-zk library 2.3.3への更新も報告されました。
Mithrilが「別途導入する証明ツール」から、Cardano node運用の中へ自然に組み込まれる構成へ近づいていることが重要です。
Voltaireでは、Constitutional Committee選挙の投票が続いています。
DRepは、立候補した10名の中から希望する4名を選びます。投票期限は2026年7月23日21:45 UTC、日本時間では7月24日6:45です。
Researchチームは、Cardano Vision 26の全workstreamについて進捗と透明性を示すDraft Mid-Year reportを準備しています。コミュニティレビュー用のリンクは、今後Cardano Forumで共有される予定です。
また、Cardano Vision 26 programに関する技術workshopシリーズの第1回が開催され、zero-knowledge verificationが扱われました。
SIPO視点では、Hydra、Mithril、Voltaire、Researchは別々の話題ではありません。
スケーリング技術を安全に動かし、状態を検証し、障害を記録し、nodeと一緒に配布し、その研究計画と進捗をコミュニティへ公開し、ガバナンスを担う人を選ぶ。
技術を「作る」段階から、ネットワーク全体で「運用する」段階へ移すための一連の作業です。
SIPOの見方：「統合」がCardanoの次の進化を現実にする
今週のCardano開発週報をひとことで表すなら、「統合」です。
旧iohk-monitoring基盤を外し、観測機能をHermodへ整理する。
LeiosCertをDijkstraBlockBodyへ入れ、Leiosを次の台帳構造へ接続する。
既知のセキュリティ情報をLaceの利用者導線へ接続する。
Plutusの形式的保証を強くしながら、reference contractとcardano-initによって開発開始までの距離を短くする。
Hydraの設定と障害回復を改善し、Mithril signerをCardano node bundleへ近づける。
そして、Cardano Vision 26の研究進捗を公開し、憲法委員会を選挙によって次の体制へつなぐ。
Cardanoは今週、新しい部品を並べただけではありません。
部品同士の境界を整理し、古い依存関係を外し、利用者、開発者、operator、DRepが実際に扱える形へ変えようとしています。
SIPOとして特に注目するのは、次の3点です。
- LeiosがDijkstra台帳の構造へ入り始めたこと
- Laceがセキュリティ確認を利用者の手元へ持ち込んだこと
- HydraとMithrilが、性能だけでなく設定、障害回復、ログ、配布を含む運用基盤へ進んだこと
大きなプロトコル進化は、論文やCIPだけでは実現しません。
台帳へ組み込み、nodeで観測し、walletから安全に使い、developerが正しく実装し、operatorが障害から回復し、コミュニティが研究とガバナンスを検証できて、初めてネットワークの能力になります。
今回の開発週報は、Cardanoがその「最後の接続」を一つずつ進めていることを示しています。
派手さよりも、統合。
速度だけでなく、実運用。
Cardanoの次の時代は、こうした地道な接続によって現実になっていきます。
参考・出典
- Essential Cardano, “Weekly development report as of 2026-07-10”
https://www.essentialcardano.io/development-update/weekly-development-report-as-of-2026-07-10
透明性メモ
本稿は、Essential Cardanoの「Weekly development report as of 2026-07-10」をもとに、SIPO編集部の視点で要約・整理したものです。固有名詞、数値、開発状況、選挙期限は、同ページに掲載された2026年7月10日時点の情報を基準にしています。
SIPOはCardanoのSPO、DRep、ADA保有者としてCardanoエコシステムに継続参加しています。本稿はCardanoの開発・ガバナンス進捗の解説であり、投資助言、投票助言、ウォレットの安全保証、ノード運用指示ではありません。利用や判断にあたっては、公式サイト、各プロジェクトのリリースノート、ガバナンス情報などの一次情報をご確認ください。
#Cardano #ADA #カルダノ #SIPO #DRep #Voltaire #Leios #Dijkstra #Hydra #Mithril #Lace