Lightning Compute Protocol を作り、実験している

2026-01-07T00:46:29Z

LCP というプロトコルを作り、その参照実装を開発/実験しています。リポジトリとドキュメントは以下で公開しています。

GitHub: https://github.com/YusukeShimizu/lightning-compute-protocol
Docs: https://candy-208aed2d-85.mintlify.app

LCP は Lightning Network の既存トランスポート上で動作するアプリケーション層であり、BOLT #1 の custom message を利用しています。小さな compute job を対象とし、見積もりから支払い、結果の配送までをシームレスにつなげる仕組みです。要するに、open aiやollamaなどの機能を、プラットフォームに依存せず、ライトニングを用いて直接やり取りできます。今後は画像などもターゲットになるでしょう。

実験の背景には、長年 blockstream/PeerSwap の開発に携わる中で、「このレイヤーは他にもできることがあるのではないか」という着想がありました。実際に codex cli や block goose と連携させて動作検証を行ってみて、思ったより動くし面白いな、と感じています。

構成のアプローチ

L402 のように HTTP 上に課金を載せるのではなく、Lightning の peer 接続そのものに課金とデータ転送を載せる構成を採用しました。

HTTP API は扱いやすい反面、利用規約や決済手段、アカウント停止の権限などが運用主体の都合に依存してしまいます。これはオープンな計算市場を構築する上で障害になり得ると考えました（単純に PeerSwap の開発経験から、この構成に慣れているという理由もあります）。

Lightning は元来 P2P の決済ネットワークであり、ノードは公開鍵によって識別されます。この性質は、認証と決済の最小単位として機能します。LCP では「決済とデータ転送を同じ接続に集約する」ことを設計の中心に据えました。一方で、これは direct peering を前提とするため、匿名性と運用性の面ではトレードオフが存在します。

LCP の仕組み

LCP は BOLT #1 custom message を利用するため、BOLT そのものへの変更は不要です。Requester と Provider の直接接続を前提とし、ジョブのフローを「見積もり、支払い、ストリーミング」として定義しています。

互換レイヤとして同梱している openai-serve を利用した場合、以下のような経路となります。

OpenAI SDK / curl
   |
   |  HTTP (OpenAI-compatible)
   v
openai-serve
   |
   |  gRPC (LCPDService)
   v
lcpd-grpcd (Requester)  --- Lightning --- Provider peer (lcpd-grpcd Provider)

Provider 有利な設計と割り切り

現在の仕様は Provider 寄りであることを認識しています。Provider は見積もりの前に入力 stream を受け取って検証でき、支払いが完了した後に実行を開始します。

これは Provider にとっては合理的ですが、Requester には不安が残る構成です。ただ、LLM 推論のような短い単位のジョブであれば、途中で止める判断もしやすく、ジョブ自体が小さいことでこの不安はある程度緩和できると考えています。この割り切りが成立する範囲を、実装と運用を通じて模索している最中です。現状の「ジョブごとに一括払い」から、stream の進捗に応じた段階課金ができれば、より正確な決済に近づくと考えています。

openai-serve の役割

LCP の価値を伝える入り口として、openai-serve は重要な役割を果たします。これはローカルで動作する HTTP サーバで、OpenAI API 互換のエンドポイント（POST /v1/chat/completions など）を提供します。

受け取った request body bytes はそのままローカルの lcpd-grpcd へ転送され、そこから Lightning ネットワークを通じて支払いと通信が行われます。streaming の際は SSE の bytes がそのまま返されます。既存の OpenAI クライアントの向き先を差し替えるだけで、バックエンドを Lightning 上の誰かに置き換えられる体験があります。

技術的な詳細と課題

64 KB 制限と SSE トンネリング

BOLT #1 custom message にはサイズ上限があるため、LCP では chunking によって payload を分割しています。これはServer-Sent Eventsのアプリケーション層での再構築に他なりません。

codex cli から LCP を経由して動作確認をしたところ、SSE をトンネリングしても想像より安定して動作するという感触を得ました。LLM のような時間のかかる処理とは相性が良い可能性がありますが、安定性はネットワーク条件と実装に依存するでしょう。今後は負荷試験等を通じて安定性を検討していきます。

検閲耐性と匿名性

中央集権的な HTTP サーバを必須とせず、アカウントやクレジットカードも前提としないため、検閲耐性は向上します。

一方で、匿名性を過大評価すべきではありません。LCP は direct peering を前提としており、相手の pubkey と接続関係を作るため、リンク可能性（linkability）は残ります。

Tor の利用や用途ごとのノード使い分けは有効ですが、将来的には BOLT12 offers と blinded paths の統合による露出低減がいいだろうと思います。onion message の安定性も含め、もう一段の工夫が必要な段階です。

今後の展望と実験へのお誘い

今後は UX の改善と価格の正確性の向上に取り組む予定です。特に lnd を個人 PC で運用する障壁は高いため、これを簡潔にする補助アプリや、LDK など別スタックの検討も必要になるでしょう。また、現状の「ジョブごとに一括払い」から、stream の進捗に応じた段階課金ができれば、より正確な決済に近づくと考えています。

本プロジェクトは lnd 環境さえあれば手元ですぐに動かすことができます。私が運用している Provider ノードも開放しており、接続方法はドキュメントに記載しています。