← 2026-05-16 の一覧へ戻るホーム
O(χ) キャンデル・イン・スペース

2026/05/15 19:55

O(χ) キャンデル・イン・スペース

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Borealis は、世界初の純粋な OCaml による CCSDS プロトコルスタックであり、DPhi Space の ClusterGate-2 に搭載され軌道投入に成功し、関数型プログラミングが衛星ネットワークのセキュリティを確保することを証明しました。OCaml 5 を用い、特定のパフォーマンス注釈を採用することで、このシステムはパケットレイテンシを 29 ナノ秒からわずか 9 ナノ秒に大幅に削減すると同時に、ガベージコレクションによる不安定性を排除します。また、有効な状態遷移をコンパイル時に強制させることでメモリの安全性を確保し、Dirty Frag のような危険な脆弱性を防止しており、これは誤りを実行時の処理ではなくコード記述中に検出するという手法です。5〜10 MB の静的 Docker イメージ内で動作する Arm SoC 上で稼働し、Borealis は厳格な NASA の基準を満たすと同時に、空軌道上で初めてのポスト量子暗号鍵の回転を Over-The-Air Rekeying（OTAR）を用いて実現しており、ハードウェアのリフラッシュなしにセキュリティアップデートが可能です。この成否は、地上試験ツールとしても利用可能な飛行ソフトウェアに対する堅牢な参考事例を提供し、産業分野において脆弱な C/C++ コードを型安全性のある代替案に置き換えることで、宇宙ミッションにおける共有ハードウェアのリスクを軽減するのを支援します。

本文

4 月 23 日、純粋な OCaml で構築された CCSDS プロトコルスタックが低地球軌道上で起動しました！このプロジェクトはコードネーム「Borealis」とされ、ホスト衛星上の DPhi Space の ClusterGate-2 ペイロードモジュール内で動作しています。コマンドおよび制御情報のエンドツーエンド暗号化ならびにポスト量子鍵回転機能もすべて、安全な OCaml を用いて実装されています。

ここで OCaml が重要な理由は何か？ 衛星上では実行される不信任されたコードは膨大なセキュリティリスクとなります。OCaml は、その特性から宇宙環境における「安全な言語」として理想的です。KC Sivaramakrishnan 氏は ICFP 2022 の招待講演において、10 年にわたるエンジニアリング努力を経て完成した OCaml 5（並行処理を可能にする安全かつ高パフォーマンスのマルチスレッド機能を実装したバージョン）について振り返りました。

KC 氏は講演で、OCaml 5.0 が「月に送られる可能性」があると推測していました。それは、必要に応じて C ラングーまたは Rust に匹敵するパフォーマンスを提供しつつ、従来の ML の数学的厳密性を維持する言語機能に支えられたアイデアでした。Parsimoni では、その言葉を少しも真に受けすぎました（笑）。

ホスト衛星は約 90 分周期で地球を周回しています。私と Virgile Robles 氏がクリスマス休暇中にこのプロジェクトに取り組んでから数ヶ月後、この画像を目にした時には私たちも仮想空間で飛び跳ねたように喜びました。

2026-04-23 18:48:06 SpaceOS/Borealis (BPv7, BPSec, OTAR) by Parsimoni
2026-04-23 18:48:06 ClusterGate-2 proxy [single iteration]
2026-04-23 18:48:06 Config: scid=100, tm_vcid=0, tc_vcid=4, tm_spi=1, tc_spi=2, tm_frame_len=1115
2026-04-23 18:48:06 Session keys: EK=0x0100 AK=0x0101 active
2026-04-23 18:48:09 Telemetry health: { ... "status": "healthy" }

実際に動作しているものとは何か？

Borealis はデーモンです。地上および衛星の両方で、標準的なクライアント・サーバープロトコル（ télémétrie クエリ、コマンドとその応答、OTAR の再鍵化要求）を扱っており、実用上のサーバーと同じ形状と構造を持っています。変わったところはその下にある通信経路（ワイヤー）です。このプロトコルスタックは、 spacecraft と地上を結ぶ CCSDS プロトコルファミリの純粋な OCaml 実装であり、無線フレームングから Bundle Protocol、そして上層のセキュリティ拡張まで全てのレイヤーをカバーしています。バイナリ形式については 

ocaml-wire
コーデックスとして記述されています。

ClusterGate-2 においては、このスタックの上層部分のみが実際に行使（活用）されています。衛星は外部とのネットワーク接続を持たないためです。地上との唯一のリンクは、DPhi の API を介したファイルシステムのアップロードとダウンロードです：アプラウプリンクディレクトリに書き込まれたファイルは、DPhi が次の周回時に転送し、ダウンリンクも同様の手順で動作します。Borealis は、このファイルを遅延許容ネットワーク（DTN）として扱います。コマンド、応答、 télémétrie サンプル、画像チャンクの各々はすべて BPv7 バンドル形式にシリアライズされてディスクに書き込まれ、DPhi 是不透明なバイト列として転送します。

BPSec は、各バンドルを 2 つの拡張ブロックで囲みます。一方がペイロードを暗号化し、他方がその認証を行います。シーケンス番号は再送防止（ replay attack）を防ぎ、事前共有鍵（以下に述べる OTAR で回転される）によって経路自体を信頼できない領域から隔離します。衛星オペレーターは不透明なバンドルバイトしか見ることができず、経路の中にある何もかもが内容を読み取ることも変更することも偽造することも置換することもできません。

これは重要です。なぜなら、私たちは他者のハードウェア上のテナントだからです。ホストペイロード衛星では複数のテナントが同一バスの共有を許されます。容器間隔離だけでは不十分です。共有 Linux カーネルを使うと、カーネルレベルの CVE が定期的にテナント境界を突破し、同じプリミティブは常に新たな形で再浮上します：今年発表された普遍的な Linux によるリモートコード実行（LPE）「Dirty Frag」、同ファミリーに近い「Fragnesia」、そして4月末に公開され全ての主要ディストリビューションに影響を与えた「Copy Fail」（Linux カーネルの権限昇格問題）。以前の事例（2022年の Dirty Pipe、2024年の container escape に利用された 

nf_tables
の use-after-free）から、これ以上の問題が浮上していくことが予想されます。地上サーバーであればパッケージマネージャーを実行して再起動できますが、軌道上ではカーネルのパッチ適用はそれ自体の配信課題であり、かつ遅延が生じ、場合によっては不可能なこともあります。各バンドルを囲む暗号封筒だけが、唯一の堅牢な保証となります。

機密性と認証に加え、長期間ミッションの脅威モデルにおいては鍵の回転が必要です。Borealis はポスト量子署名鍵（ML-DSA-65）のための OTAR（Over-The-Air Rekeying）をサポートします。これらの鍵は衛星の寿命にわたって使用されます（10〜15 年間），そのため NASA Space System Protection Standard（NASA-STD-1006A）は、ポスト量子コマンド認証を将来のオプションではなく必須要件として扱っています。OTAR を用いることで、衛星を書き換えることなくポスト量子鍵を回転させることができます。当方の知る限り、これはポスト量子 OTAR の最初の公開軌道上デモとなるでしょう。今後の周回で実際に回転を実行する予定です。

Borealis は DPhi のホストペイロードモジュール上のゲストとして動作します：Linux を実行している Arm SoC（4 つの Cortex-A53 コア、4 GB RAM）です。フライトバイナリは 5〜10 MB、静的リンカ済みで、FROM scratch Docker イメージとして配布されます。バスをポーティングして télémétrie（角度、速度、位置）および機載カメラ（低品質の魚眼レンズ、デモ用のみ）からのデータを取得します。

衛星側のループの中核は以下のようになります：

let send_telemetry t ~prefix payload =
  let bundle =
    make_bundle t ~source:Eid.sat_telem
      ~destination:Eid.ground_telem ~payload
  in
  match protect_bundle t bundle with
  | Ok protected ->
      ignore (write_bundle t ~dir:(downlink_dir t.config) ~prefix protected)
  | Error _ -> log t "Failed to protect telemetry bundle"


protect_bundle
は、SDLS セキュリティ協会から取得した鍵を用いて BPSec を適用し、地上と衛星がプロビジョニング時に合意した暗号パラメータを使用します。これらがいずれかの時点で失敗すれば、バンドルは衛星を離れません。

アップリンク経路もダウンリンク経路とは対称的です。衛星は 

/data/uplink/
からバンドルを読み取り、BPSec を用いて各々を保護解除し、バンドルレイヤーで宛先に応じてルーティングを行います：

if dest = Eid.sat_cmd then handle_command t payload
else if dest = Eid.sat_otar then handle_otar t payload
else log t "Unknown destination"

テキストコマンドは短い UTF-8 文字列として解析され、ADT に変換されます。タイプチェッカーが尽くした(dispatch)処理を強制します：

type cmd = Ping | Check | Capture | Halt

let dispatch t = function
  | Ping    -> send_response t ~prefix:"pong" "PONG"
  | Check   -> run_self_check t
  | Capture -> capture_and_send t
  | Halt    -> t.shutdown_requested <- true

新しいコマンドを追加するにはコンストラクタを追加するだけで、コンパイラはそれらがまだ処理されていない箇所を全てフラグ付けします。OTAR の再鍵化メッセージは別の分岐を取ります。ペイロードはテキストではなくバイナリで、統合時に衛星にインストールされたマスター鍵の下で暗号化されており、モジュール内のプロセスメモリ上に存在します（モジュールには TPM やセキュアエレメントがありません。耐放射線性を持つものを構築することはまだオープンなハードウェア問題であるため）。衛星は新しい鍵を解読し、ステージングスロットに保持して活性化させます。現在のフライトループは受け取り時に即座に活性化しますが、プロトコルにはオペレーターがインストールを確認してからコミットする、地上主導の別段階のアクティベーションもサポートしており、その経路への切り替えはフライトループの変更であり、新たなコードではなく設定の変化です。

マスター鍵自体には回転経路がありません。それは衛星をロケットに搭載する前にペイロード上に設置され、軌道上になった後の宇宙船に対してはより信頼性の高いチャネルで新しいものを配信する手段がないためです。マスター鍵が失われた場合、このスタックはアクセス不能になります。ハードウェア支援のキー貯蔵を持たない長期間ミッションにおける正直な失敗モード这便是です。

今後：OxCaml

OxCaml は Jane Street の OCaml 上で実装されたコンパイラブランチです。そのモードシステムは衛星のホットパスにおいて重要です。Locality（局所性）をすることで、割り当てをスタック結合として标记し、これらが никогдаにもヒープに到達せず、GC に到達しないようにします。Uniqueness（唯一性）と capabilities（能力）を用いることで、共有可変状態を型システム上で追跡でき、並行部分のデータ競合compile-time エラーに変換されます。

ホストペイロードモジュール上のホットパスは CCSDS ディスパッチです：各 CFDP セグメント、各 COP-1 フレーム、各カメラパケットがすべてアプリケーションロジックに到達する前に、Space Packet ヘッダーデコードと APID ベースのルーティングステップを通過します。各周回でハードスケジューリング締め切りを持つリアルタイムオンボードディスパッチは、EU ORCHIDE Horizon Europe プロジェクト（このオンボード作業が最初に Tarides 内で行われ、やがて Parsimoni という専用の宇宙ソフトウェア会社として独立したグループ）が設立された課題そのものです。

CCSDS ディスパッチホットパスでの単一パケット遅延： Space Packet プライマリーヘッダーを 3 フィールドのレコードにデコードし、APID でルーティングする処理です。Stock OCaml と、同じコードを 

exclave_ stack_
で注釈化した OxCaml の比較。ラップトップ上での測定（フライトモジュールではありません）。

exclave_ stack_
注釈付きの OxCaml に切り替えると、ディスパッチホットパスでの p99.9 レイテンシーは単一パケットあたり 29 ns から 9 ns に改善され、GC プレッシャーは完全に消滅します（2,500 万のパケットに対し、マイナージェニエーション GC はゼロ）。スループットは同等で、勝利はジッターです。数百マイクロ秒のジッター予算を持つホストペイロードモジュールにおいて、それが全ての問題です。

レシピは機械的です：各反復あたりのヒープ割り当て（

{ apid; seq_count; data_len }
）をスタック割り当て（
exclave_ stack_ { apid; seq_count; data_len }
）に変換し、コンシューマーがそれを 
@ local
として受け取るように要求します。型システムはレコードがディスパッチスコープから脱出できないことを証明し、コンパイラはヒープトラフィックを生成せず、GC は収集するものがありません。

セットアップ。 Apple M5 Max, macOS 25.4, Stock OCaml 5.3.0 と 5.2.0+ox（Jane Street の OxCaml フォーク）の比較。ワークロード：各バッチに 256 つの CCSDS Space Packet ヘッダーディスパッチを行う 10 万回のバッチ（合計約 2,560 万パケット）、それぞれ 

[@inline never]
アノテーション付きハンドラを通過させることでレコードが実際に脱出します。10 回の実行の中央値。

なぜ OCaml か？

Microsoft の MSRC 分析（2019）および Chromium の 2020 年研究によると、C/C++ コードベースにおける深刻な CVE の約 70％はメモリエラー（バッファオーバーフロー、use-after-free、整数オーバーフローなど）に起因します。我々のセキュリティ拡張機能（SDLS, BPSec, OTAR）はいずれも暗号テキストと鍵材料を処理しており、メモリエラーが最も有害となるまさにその場所です。この分野における既存の C ベース実装である NASA CryptoLib も同様のエラーを持っており：例えば、人為的に作成されたフレームからトリガーされた整数アンダフローにより引き起こされた TC フレームパーサー内のヒープバッファオーバーフローがあります。OCaml 実装は、アプリケーションロジックからそのような攻撃対象領域を構造的に排除します。ランタイム、その下のカーネル、そしてブートローダーは依然として C であり、依然として TCB（Trusted Computing Base）の一部です。メモリスafety は役立つ場所では助けになりますが、信頼できる計算基盤の監査の代替にはなりません。

OCaml が今日与我たちにもたらす恩恵を超えて、言語自体は進歩し続けています。Jane Street は OxCaml を維持しており、これは OCaml の実験的ブランチです。その設計目標は、プログラムのパフォーマンスクリティカルな部分に対する安全で予測可能な制御を提供することであり、必要な場合にのみオプトイン可能で、依然として OCaml 内（有効なすべての OCaml プログラムも有効な OxCaml プログラムである）にあります。

OxCaml Labs（Cambridge の Anil Madhavapeddy らのグループ）と FP Launchpad（IIT Madras の KC Sivaramakrishnan ラブ）が OCaml を進めており、Tarides は主線にアップストリームで準備された部品を統合しています。

私はある種の不思議な理由で「月」に焦点を当ててしまいました（笑）。軌道上に先行することを優先したのは、誤りよりも正しさを重視したためです。軌道上でのプロトコルバグの修正は高価であるためです。防御はスタックの各レイヤーを通して行われます：型チェック、形式検証された暗号プリミティブ（libcrux, fiat-crypto）、相互運用性テスト、依存関係監査などです。

これら 3 つのレイヤーを具体例として挙げます。ワイヤ形式コーデックスは typed schma から生成され、デコード時に不整合なバイト列を拒否し、Microsoft の EverParse パーサジェネレーターに供給されます（これは F* で形式検証された C バリデーターを生成します）。プロトコル状態機械は GADT としてエンコードされるため、型チェッカーがコンパイル時に無効な遷移を拒否します。相互運用性パイプラインは既存の参照実装に対して実行され、型システムで表現できないものを検出し、アップストリームライブラリの欠陥も浮かび上がらせます。

これらのレイヤーが捉えることを超えて、関数型コアにより、フライトソフトウェア、地上ソフトウェア、テストオラクルとして同じコードを配送できます。上記の 

protect_bundle
は、この 3 つの役割すべてで同じ関数です。一方の役割から記録したトラフィックを他方へ供給し、バイトごとに出力を比較します。OCaml コードは、他の実装を検証するための参照実装としても機能します。これは nqsb-TLS アプローチ（Kaloper-Mersinjak, Mehnert, Madhavapeddy, Sewell, USENIX Security 2015）であり、TLS 分野で 10 年間維持されてきました。Nitrokey の NetHSM は現在、出荷用ハードウェアセキュリティモジュール内で同一の OCaml TLS スタックを実行しています。

Borealis も例外ではありません。数ヶ月以内にゼロから軌道上デモまでの完全な CCSDS プロトコルスタックを開発したように見えるかもしれませんが、実際にはそうではありませんでした。コアライブラリは MirageOS から由来し、過去 10 年間地上の生産環境で動作しています。ライブラリオスは一義的に言えば、必要な部品を選べる大きなツールセットです。

ASPLOS 2013 のユニクernels ペーパーでは、「封止された単一目的イメージがクラウドインフラを改善できるか」と問われました。10 年後、同じライブラリは数百台のラップトップ（Docker Desktop）で動作し、今や ClusterGate-2 で宇宙空間でも動作しています。ここで Linux プロセスとしてシステムレベルの配管を行い、当初設計した場所とは異なる環境下でも機能しています。

Borealis は軌道上にある単一バイナリです。次の課題はスケールです：地上の Linux における Docker がもたらした「ワンコマンド」と同様の簡便さで、多数の衛星にわたる専用ペイロードバイナリの展開と管理を行うことです。より困難なのはそれを安全に行うこと：地上からの署名された更新、ペイロード間の隔離、実際に実行されているものの証明などです。ハードウェアを軌道へ送るのはすでに例外的なことですが、ますます注目すべき問題は、その上で動作するソフトウェアにあります。これはクラウドコンピューティングで見られるシフトであり、サーバーの上に構築されたスタックがサーバー自体よりも重要になる傾向が見られます。

それが今、Parsimoni で協力者（Cambridge とそれ以外）と共に構築しようとしているものです。私は広範な質問について「衛星上不信任コードを実行するのは良いアイデアか？」という記事でスケッチしました。

ペイロードソフトウェアを開発中、バスのホストペイロードを検討中、あるいは軌道上での OCaml 使用について意見を交換したい場合は、私に連絡するか Parsimoni チームへお書きください。

同じ日のほかのニュース

一覧に戻る →

2026/05/16 1:15

プロジェクト・グテンベルク：良くなるばかりです

## Japanese Translation: Project Gutenberg は 1971 年に設立された先駆的な非営利図書館で、市民向けに 75,000 冊を超える無料の電子書籍を提供しています。その核心的な使命は、米国での著作権が失効した著作物のデジタル版を提供することで歴史を保存することであり、これらの文本は公開前に何千人ものボランティアによって細心の注意をもって校正されています。アーカイブへのアクセスには登録費用や専門ソフトウェアは一切不要であり、ユーザーは Web ブラウザですぐに閲覧でき、epub や Kindle などの一般的な形式でコンテンツをダウンロードできます。メインサイトでは公共の領有権にある古典作品に焦点を当てていますが、self.gutenberg.org という独立したセクションでは World Library Foundation から提供される自己出版タイトルがホストされています。サイトはさらにボランティアによって手が選別された読書リストも提供しています。研究者や企業向けには、著者、タイトル、主題、言語、タイプ、人気度でフィルタリングや検索ができる堅牢な機能があり、アクセスが可能です。Project Gutenberg は新刊のデジタル化を継続するために寄付を受け入れており、この支援がない場合、コレクションの拡大は不可能になります。入るための障壁なく、すべての人々のために知識を民主化する 100% フリーのリソースとして 50 年以上運営されてきたことです—from カジュアルな読者から産業用途まで—。そのリーダーシップに関するリソース、例えば元 CEO で亡くなられた Greg Newby 博士については、サイト上に利用可能です。

2026/05/16 4:23

WinCE64 - N64용 Windows CE 2.11

## Japanese Translation: このテキストは、EverDrive-64 X7 リーダーを実際の Nintendo 64 ハードウェアに Microsoft Windows CE 2.11 を成功裏に移植したという重要な技術的達成を文書化しています。エミュレーションとは異なり、この構成は Microsoft のコア `nk.lib` ライブラリを変更することなく、完全なデスクトップ機能—including ウィンドウ管理、N64 AI ハードウェアを用いたオーディオ出力、サードパーティ製 EXEの実行—を提供します。プロジェクトでは、元の CE 2.11 SDK にこれらの要素が含まれていなかったため、外部資源（例：libdragon ライブラリ）を用いてデスクトップシェル（Explorer、タスクバーなど）全体を从头再構築する必要がありました。主要な技術的作業には、RDP アクセラレーション付きの VI フレームバッファ用のカスタムドライバ、Joybus 経由での N64 コントローラ入力デコーディング、インタラプトマスク問題を解決するためのポーリングモードオーディオ処理が含まれます。公式エミュレーションは深いパッチが必要であるため未対応ですが、この概念実証（PoC）により、独自ドライバの実装を通じてレガシーソフトウェアをヴィンテージハードウェア上で動作させる方法が示されました。ただし、プロジェクトソースコードが MIT ライセンス下にあるにもかかわらず、結果生成されたバイナリは制限的な Microsoft SDK ライセンシングのために再配布できません。

2026/05/16 3:37

ツリプル財団。

## Japanese Translation: 2026年5月15日、Zulipの創設者であるTim Abbottはフルタイムでのリーダー職を退き、Anthropicへの参画を果たします。この際、Alya Abbott、Greg Price、Alex Vandiverを含む3名のシニアチームメンバーも一同に立ち寄り、Kandra Labsは新たに設立された独立した非営利法人「Zulip Foundation」へ寄附され、プロジェクトは私的所有から Mozilla や Signal に準じた公共的利益に基づくガバナンスモデルへと移行します。同財団はプロジェクトを管理し、公共団体を中心に活動しつつ、助成金および税金控除可能な寄付を通じて持続可能な資金調達を実現し、投資家による支配を防ぎます。最初の理事会には、創設者である Tim Abbott、共同創設者の Greg Price、製品担当の Alya Abbott、Rust リーダーの Josh Triplett が選任されます。拡大された諮問委員会では、Andrew Sutherland（MIT）、Nick Bergson-Shilcock などの専門家も参加します。運用はすべて継続：Zulip Cloud、モバイルプッシュ通知、サポート契約、Google Summer of Code、オープンソースのスポンサーシップなどがそのまま活性しています。Kim Vandiver が副理事長として加わり、安定期の確保を図ります。開発ペースは次四半期に若干低下しバグ除去を優先する可能性がありますが、12名の平均4年以上の在籍期間を持つ経験豊富な維持管理チームおよび約25,000コミットのコード履歴が、プラットフォームのレジリエンスを支えています。Tim Abbott は時間の許す限りコンテキストと助言を提供し続けています。変更に関する詳細については、5月19日午後4時（UTC）にライブチャットで Q&A を開催しコミュニティと議論を行います。本移行は、オープンソースの価値観とコミュニティによる統御下での長期的持続可能性を最優先とするものです。

O(χ) キャンデル・イン・スペース | そっか～ニュース