HoskinsonのUmbraプロトタイプはMidnightのリカバリーを目標に、BABEマイグレーションはQA工程を進行中

Charles Hoskinsonは、CardanoとMidnightで用いられるインフラ全体のリカバリーを簡素化することを目的とした実験的な永続データストアUmbraをテストしている。このプロトタイプはCardano Newsが精査した技術的なX Spaceの書き起こしで説明されており、将来のCardanoおよびMidnightのブリッジアーキテクチャに関する彼の作業と結び付いている。別途、Midnightの公開ノードリポジトリには、公式のAuraからBABEへのコンセンサス移行が品質保証段階にあることが示されている。

Midnightの同期はCardano DB Syncを経由して実行される

Midnightは、公開ブロックチェーンによる検証と保護されたデータを組み合わせるアプリケーション向けに構築されたCardanoのパートナーチェーンである。開発者はMidnightを用いて、ゼロ知識証明が選択的開示、プライベート計算、コンプライアンス志向のワークフローを支えるアプリケーションを構築でき、公開トークン層には$NIGHTが含まれる。

Hoskinsonは、Cardanoフルノードから始まり、cardano-db-syncを経て、次にMidnightノード、最後にMidnightインデクサを要するローカルインフラの手順を説明した。この手順はMidnightのオペレーター向けドキュメントと整合している。

Midnight cardano-db-sync ガイドは、前提条件として稼働中のCardanoノードを挙げ、cardano-db-syncがPostgreSQLを用いてブロックチェーンデータをリレーショナルスキーマにインデックス化すると記している。同ガイドはまた、van Rossemアップグレード後は、単純なバイナリの置き換えとして扱うのではなく、データベースをCardano Node 11.0.1に対してリプレイしなければならないとも述べている。

このドキュメントはまた、cardano-db-syncの同期率が少なくとも99パーセントに達するまで待ってから先に進むようオペレーターに指示している。続くMidnight full-node ガイドでは、Midnightノードを起動する前に、アクセス可能なcardano-db-syncインスタンスとPostgreSQLポートを要求している。

この運用モデルは、なぜリカバリーレイヤーが開発者やノード運用者にとって重要になるのかを説明している。ローカルのMidnight環境は単一バイナリの再起動では完結しない。Cardanoのチェーンデータ、データベースの状態、Midnightノードのデータ、インデックス化されたアプリケーションデータがすべて整合したままである必要があり、いくつかの同期サービスに依存している。

Umbraプロトタイプは復元可能な状態に焦点を当てる

Umbraは、リリース済みのMidnight製品としては記載されていない。これは、ウォレット、インデクサ、トランザクション履歴、および関連するインフラコンポーネントに必要な状態を保存し復元するためのHoskinsonのプロトタイプである。

書き起こしによると、このプロトタイプは、保存済みの状態、チェックポイント、ロールバックとロールフォワード処理、シャットダウン後のコールドリカバリー、安全な接続、そして過去に保存した記録からノードおよびインデクサのデータを再構築することを中心に設計されている。Hoskinsonが計画するテストは、環境を同期させ、既存のMidnightノードとインデクサのデータを削除し、その後Umbraから両者を再構築できるか試みるというものだ。

後のバージョンでは、自己検証可能なチェックポイントを追加できる可能性がある。Hoskinsonは、ゼロ知識証明によってチェックポイントが有効な状態を表していることを確認し、スナップショット配布者に求められる信頼の度合いを減らすモデルを説明した。

また、配布レイヤーの候補をMithrilに例えた。CardanoのMithrilドキュメントは、Cardanoノードのより高速な同期と状態検証を支援するために認証済みのブロックチェーンスナップショットを生成する、ステークベースのマルチシグネチャプロトコルを説明している。UmbraはMidnightの状態に関連する概念を適用できるかもしれないが、公的な実装計画や正式なリリーススケジュールは公開されていない。

Hoskinsonは、初期版には、同期とリカバリーテストの完了を条件として、さらに二日から三日の集中的な開発が必要になる可能性があると見積もった。また、このプロジェクトがプロダクションインフラになり得る前に、後続のプロダクト化、監査作業、より広範な開発者の関与が必要になるとも述べた。

AuraからBABEへの移行は引き続きQA中

Midnightはコンセンサスインフラに対する別の変更も準備している。Hoskinsonは、Auraを現在の移行期のブロック生成メカニズム、BABEを分散運用を想定した長期的なモデルと説明し、GRANDPAが引き続きファイナリティを提供すると述べた。

この作業はMidnightの公開ノードリポジトリで確認できる。公開中のAura to BABE のissueは、デュアルエンジン状態機械とAuraからBABEへの自動スイッチを担う新たなpallet-consensus-engineを記述している。このissueは6月23日に作成され、現在は“QA in progress.”とラベル付けされている。

このワークストリームには、AuraまたはBABE用のActiveEngineフラグ、ガバナンスでゲートされたマイグレーション設定、保存された遷移スロット、記録されたBABEのエポック境界での自動切り替えが含まれる。また、このissueは、GRANDPAが少なくとも一つのインジェクトされたブロックをファイナライズするまでスイッチを延期しなければならないこと、さらにユニットテストが状態遷移を網羅しなければならないことも明記している。

公開issueには二つの依存項目が残っている。epoch-boundary bindingとvalidator committee stagingである。同じissueには、公開されたGitHubビューでマイルストーンやリンクされたブランチ、プルリクエストは示されていない。

オペレーターやアプリケーションチームにとって、デプロイ可能なインフラの経路は依然として文書化された順序である。Cardanoノード、cardano-db-sync、Midnightノード、そしてインデクサだ。具体的なエンジニアリング上のチェックポイントは広範なロードマップよりも絞られており、再現可能なUmbraのリカバリーテストと、MidnightノードでBABEがAuraに取って代わる前に必要となるepoch-boundaryとcommitteeの依存関係の完了である。$NIGHTインフラに関しては、両方の取り組みが同じ運用目標を指し示している。すなわち、利用可能なチェーン状態のより迅速な回復と、移行期のブロック生成からネットワークが意図するコンセンサスモデルに向かう管理された道筋である。