Cardanoのブラウザノード実験がTypeScriptとHaskellで前進

Cardanoの開発者は、2つの独立したノード実験から新たな成果を報告した。Harmonic Labsは、空のブロックを超えたGerolamoのテストを拡大し、一方でSeungheon OhはWebAssemblyを通じてHaskellノードスタックのブラウザ実行を実演した。いずれも依然として実験段階であり、いずれもブラウザ内だけで完全に稼働する本番のブロックプロデューサーを確立したわけではない。

GerolamoがCardano Previewで2つ目のブロックを生成

GerolamoはTypeScriptで記述され、Bunランタイム上で動作するCardanoノードの代替実装である。Harmonic Labsが創業者Michele Nuzziの下で開発しており、ソースコードは公開されている。

Gerolamoに帰属する最初のブロックは9月12日にCardano Previewで承認された。これは空のブロックで、代替実装がCardanoのプロトコル規則の下で受け入れられるブロックを生成できるかどうかの初期テストとなった。

9月14日に2つ目のブロックが続き、3件のトランザクションを含んでいた。チームが公開した情報によれば、スマートコントラクトの実行とオンチェーンメッセージが含まれていた。これによりテストは、空のブロックからトランザクション活動を伴うブロックへと進展した。

Gerolamoはチェーンデータを検証しながら、Previewのチェーンをジェネシスから現在の先端まで同期した。サーバー実装は、Cardanoのノード間プロトコル、任意のローカルクライアント通信、Mithrilのブートストラップ、BlockfrostスタイルのAPI機能の一部をサポートしている。

入手可能なドキュメントは、プロジェクトの完了済み部分としての完全なPraosリーダーシップについては記述していない。Harmonic Labsは、2つのPreviewブロックに用いられたフォージングの経路に関する完全な技術的説明を公開していない。ネットワークはこれらのブロックを受け入れ、チームはそれらをGerolamoによるものとしたが、ブロックプロデューサーがウェブブラウザ内で動作していたことを示す公的な証拠は確立されていない。

Cardanoにおける2つの異なるブラウザノードのアプローチ

Gerolamoに加えて、Harmonic LabsはウェブブラウザおよびChrome拡張向けの軽量実装Gerolaminoを開発している。GerolaminoはPreviewブロックを生成したソフトウェア実体と同一ではない。

公開デモでは、ブラウザがOuroboros Handshake、ChainSync、BlockFetchのミニプロトコルを通じてCardanoのリレーと通信できる。ヘッダーとブロックを追跡し、CBORデータを処理し、IndexedDBとWebWorkersをローカルのストレージと計算に利用できる。

現状では、ウェブアプリケーションがCardanoネットワークへの標準のTCP接続を直接開けないため、WebSocketからTCPへのブリッジがブラウザと外部のPreprodリレーを接続している。

計画中の開発には、初期同期を高速化するMithril対応、ローカルのUTxOインデックス化、既存のCardanoウォレット標準に類似した通信インターフェースが含まれる。このモデルにより、ウェブアプリケーションはリモートAPIにあらゆる応答を求めるのではなく、より多くの情報をユーザーのデバイス上で検証できるようになる可能性がある。

Harmonic Labsとは別に、開発者Seungheon OhはGHCのWebAssemblyバックエンドを通じて、ブラウザ内で動作するHaskellのCardanoノードを実演した。デモには、チェーン先端の追従、ADA残高の表示、ブラウザからのトランザクション送信が含まれていた。

Cardano Hard Fork Working Groupは、このデモをノードの多様性に関連する進展として9月15日に記録した。Ohはソースコードを公開しておらず、デモにはブロック生成が含まれていなかった。したがってこのプロトタイプは、まだ独立したレビューや本番のHaskell cardano-nodeソフトウェアとの詳細な比較を行うことができない。

ローカル検証はCardanoのdAppインフラを変える可能性

Cardanoのウォレットや分散型アプリケーションは、ブロックチェーンデータへのアクセス、UTxOの特定、残高確認、トランザクション送信のために、しばしばリモートサービスを利用している。このインフラは開発を簡素化する一方で、APIプロバイダーやインデクサー、その継続的な可用性への依存を生む。

ブラウザノードの機能により、そのプロセスの一部をユーザーのデバイス上に移せる可能性がある。アプリケーションはローカルでCardanoのチェーンを追い、ブロックを処理し、トランザクションを作成または送信する前に使用する情報を検証できる。ローカルアクセスは、集中型APIサービスに送信されるアドレスやデータ要求の件数を減らすことにもつながり得る。

開発者にとって、このアーキテクチャは、個々のインデクサーやバックエンドプロバイダーが利用不能になった場合でも動作し続けるCardanoアプリケーションを支援し得る。複数の独立に開発されたアクセス経路が、同じCardanoのプロトコル規則に従ってデータを検証することで、アプリケーションのレジリエンスを強化できる。

このアプローチはまた、ブロックチェーンの状態の唯一の情報源としてリモートサービスを扱うのではなく、ユーザーにより近い場所でウォレットや分散型アプリケーションがUTxOやADA残高を検証できるようにする可能性がある。Gerolamoは独立に開発されたTypeScript実装を加え、Ohの取り組みは確立されたHaskellスタックがWebAssemblyを通じてどのように動作できるかを探っている。

現在のプロトタイプは外部インフラの必要性をなくすものではない。Gerolaminoは依然としてWebSocketブリッジと外部リレーを使用しており、より広範なローカル同期には、ブラウザのストレージ、メモリ、帯域幅、インデックス化の制約を考慮する必要がある。Mithrilのスナップショット、ネットワークピア、トランザクション送信経路もアーキテクチャの一部として残る。

公開された進展には現在、Previewブロックを生成したTypeScriptノード、Ouroborosミニプロトコルを用いるブラウザのライトノード、チェーン追従とトランザクション送信が可能な別個のHaskellプロトタイプが含まれる。ブラウザ内だけで完全に動作する本番のリレーやブロックプロデューサーはまだ文書化されていない。直近の変化はより限定的で、Cardanoアプリケーションはブロックチェーンの検証の一部をリモートサービスからユーザーのデバイスへ移し始められるようになったという点だ。