Veilid を学ぶ — プライバシー第一の分散基盤を個人で動かす
なぜ Veilid が注目されているのか
インターネットは元々分散・対等(peer-to-peer)なネットワークとして設計されたものでしたが、現実には Cloudflare、AWS、Google、Meta といった少数の事業者が大半のトラフィックを握る、極めて集中化された構造になっています。
プライバシーの観点から見ると、これは「すべての通信が、少なくとも誰かに見られている」状態であり、検閲・トラッキング・データ収集の温床でもあります。
Veilid （読み方：ヴェイリッド）は、この状況に対する根本的なオルタナティブとして 2023 年 8 月の DEF CON 31 で発表されたプロジェクトです。
Cult of the Dead Cow(cDc)という伝説的なハッカーグループのメンバー、特に Christien “DilDog” Rioux 氏が中心となって開発されました。
同氏は L0pht(Lopht)の元メンバーで、L0phtCrack の作者として知られる人物です。
Veilid の自己定義は 「Tor + IPFS を統合し、より速く、より使いやすくしたもの」。
すべての通信が暗号化され、IP アドレスが秘匿され、その上で分散ハッシュテーブル(DHT)や RPC、pub/sub といったアプリケーション基盤を提供します。
Tor が「匿名で既存のインターネットにアクセスするレイヤ」なのに対し、Veilid は 「その上に直接アプリを書くためのフレームワーク」 という位置づけが大きく違います。
仕組み: Private Routing と Safety Route
Veilid のプライバシーの核心は Private Routing(プライベートルーティング) です。
Tor のオニオンルーティングに着想を得ていますが、より進んだ「両端制御」のモデルを採っています。
Tor では、クライアントが「自分から出口ノードまでの 3 ホップ」を全部選びます。
サーバ側はその経路に関与しません。これは「クライアントは安心だが、サーバを隠す(hidden service)場合にはサーバ側も別途 3 ホップを構築する必要がある」という非対称な構造でした。
Veilid はここを根本から作り直し、Safety Route(発信者側が選ぶ自分→中継ノード列)と Private Route(受信者側が選ぶ中継ノード列→自分)を独立に構築し、それらを連結した Compiled Route(コンパイル済みルート)で通信します。
発想は「自分が知らない側のルートは相手に決めさせる」「どの中継ノードも経路全体を知らない」というもので、デフォルトでは Safety Route 1 ホップ + Private Route 1 ホップ = 合計 3 ホップになります(必要に応じて増やせます)。
この設計の利点は二つあります。
第一に、受信者の身元と位置情報が、発信者にすら隠れる。
受信者は自分の Private Route を発行し、その「ルート ID」だけを公開すれば、相手は実 IP アドレスを知らずに連絡できます。
第二に、中継ノードは隣の 1 ホップしか知らない。
各レイヤは暗号化された封筒(Secure Envelope)に包まれており、自分が経路の何番目かすら知り得ない設計が目指されています。
暗号スイートは現代的で、鍵交換に X25519、対称暗号に XChaCha20-Poly1305、署名に Ed25519、ハッシュに BLAKE3 を使います。
これらは Tor が長年使ってきた古い暗号スタックよりも、性能・安全性ともに進んでいます。
DHT: アプリケーションのデータ層
Veilid のもうひとつの柱が、改良された Distributed Hash Table(DHT) です。
一般的な Kademlia DHT は「キーに対する値の所在を分散して持つ」仕組みですが、Veilid の DHT は次の点が違います。
まず、Subkey(サブキー) の概念があり、ひとつの DHT レコードを複数のサブキーに分割して管理できます。
これはチャットの履歴を効率的に同期する用途などに有用です。
次に、スキーマ付き。
レコードには DFLT(単純なオーナー署名)や SMPL(複数の書き込み権限を別個のキーで分けられる)といったスキーマがあり、共有データの権限管理がプロトコルレベルで組み込まれています。
さらに、人気のあるデータほど自然にレプリケーションされる ような設計で、ノードの参入・離脱に対する耐性が高い。
実用上、これによって「サーバなしのチャットアプリ」「サーバなしのコラボエディタ」「サーバなしのプロフィール共有」のようなものが、Veilid の DHT 上にデータを置くだけで作れます。
データの所有権・暗号鍵は完全にユーザの手元にあります。
Veilid vs Tor vs I2P
似た領域の技術と比較すると、それぞれの位置づけがはっきりします。
Tor は「既存のインターネットへの匿名アクセス」が主目的で、HTTP プロキシとして使うのが基本形です。
出口ノード問題(誰かが出口を運営し、平文を見られる可能性)がついて回り、hidden service(.onion)は遅い。
実装は C 言語。
I2P は Tor よりも「内部完結型」で、ネットワーク内でサービスをホストする方向に設計されています。
Garlic Routing と呼ばれる派生方式を使い、12 ホップ(往復)の経路で強い匿名性を提供しますが、その分遅い。
実装は Java で、API はサービス指向。
Veilid はこの両者の良いところ取りを狙います。
Tor のような汎用プロキシではなく、I2P のようなネットワーク内アプリ向けですが、Rust 実装によって性能を稼ぎ、Flutter / Python / Node.js などモダンな言語バインディングを提供します。
さらに DHT がプロトコルに組み込まれているので、「データの分散保存」までフレームワーク側でカバーされます。
注意点として、Veilid は 完全な匿名性を保証する成熟したシステムではありません。
学術的な検証はまだ少なく、IEEE 論文で「Peer-to-Peer Meets Onion: The Veilid Framework」が 2024 年に発表されたばかりの段階です。「ジャーナリストが命を懸けて使う」ような最高ランクのスレットモデルでは、現時点では Tor の方が枯れていて安全と言えます。
Veilid は「日常使うアプリに、デフォルトでプライバシーを組み込む」という民主化方向に強みがあるツールと捉えるのが妥当です。
VeilidChat: リファレンスアプリ
Veilid Foundation が公式に提供しているリファレンスアプリが VeilidChat です。
Flutter で書かれた 1 対 1 のテキストチャットアプリで、iOS / Android / デスクトップ で動きます。
Google Play では既にベータ版が配布されています。
実装はシンプルで、各ユーザはローカルで Veilid ノードを動かし、自分の Private Route ID を QR コードや文字列として相手に渡します。
相手はその Route ID 宛に暗号化メッセージを送信し、メッセージ自体は Veilid DHT に書き込まれます。
サーバは一切存在せず、メッセージはエンドツーエンドで暗号化されています。
コードは GitLab で公開されており(gitlab.com/veilid/veilidchat)、自分のアプリを作る際の最良の参照になります。
個人で Veilid を動かす
ここからは実践編です。
個人で Veilid を学んで、何か作るまでのステップを順を追って説明します。
ステップ 1: ノードを動かしてみる
Veilid のリポジトリ(gitlab.com/veilid/veilid)をクローンしてビルドするのが最初のステップです。
Rust の toolchain と、いくつかのシステム依存があります。
Copygit clone --recurse-submodules https://gitlab.com/veilid/veilid.git
cd veilid
# セットアップスクリプトが用意されている
./setup_macos.sh # または setup_linux.sh
cargo build --release -p veilid-server -p veilid-cli
これで veilid-server(ノード本体)と veilid-cli(対話的に操作する CLI)が手に入ります。
Copy# 別ターミナルでノードを起動
./target/release/veilid-server
# CLI で接続
./target/release/veilid-cli
デフォルトでは「Veilid 公式の大きなネットワーク」に参加し、用意されたブートストラップノードを経由してネットワークに繋がります。
veilid-cli の中で status を打てば、自分のノードの接続状況、Public Internet 接続性(NAT 越えの可否)、既知のピア数などが見えます。
ステップ 2: Python から触ってみる
ノードが動いたら、外部からプログラマブルに触ってみます。
Veilid ノードは Unix ドメインソケットまたは TCP で JSON-RPC API を公開しており、veilid-python という公式バインディングが使えます。
Copypip install veilid
最小例として「メッセージを受信できる Private Route を作って、その ID を表示する」だけのスクリプトを書いてみます。
Copyimport asyncio
import veilid
async def main():
async def update_callback(update):
# AppMessage や AppCall が来たらここに通知される
if update.kind == "AppMessage":
print(f"received: {update.detail.message}")
api = await veilid.json_api_connect("localhost", 5959, update_callback)
await api.new_private_route_invocation(False)
# ルーティングコンテキストを作る
rc = await api.new_routing_context()
# 自分宛の Private Route を生成
route_id, route_blob = await api.new_private_route()
print(f"share this route blob with the sender:")
print(route_blob.hex())
# メッセージ待ち受け
await asyncio.sleep(3600)
asyncio.run(main())
送信側は受け取った route_blob を import して、app_message で送信します。
これだけで「サーバを一切経由しない、E2E 暗号化された、IP を秘匿した通信」が成立します。
これは普通のソケットプログラミングと比べて、かなり魔法めいて感じられるはずです。
ステップ 3: DHT にデータを置いてみる
Private Route が「リアルタイム通信」なら、DHT は「非同期データ共有」です。
DHT レコードを作って書き込み、相手は同じレコードを読む、という使い方です。
Copy# 書き込み側
rc = await api.new_routing_context()
record = await rc.create_dht_record(veilid.DHTSchema.dflt(1))
print(f"record key: {record.key}")
print(f"owner secret (keep safe): {record.owner_secret}")
await rc.set_dht_value(record.key, 0, b"Hello from the void")
await rc.close_dht_record(record.key)
# 読み取り側(record.key を共有しておく)
rc = await api.new_routing_context()
await rc.open_dht_record(record_key, None)
val = await rc.get_dht_value(record_key, 0, force_refresh=True)
print(val.data)
この record.key を相手に渡せば、サーバなしで「ファイルの共有」「プロフィールの公開」「掲示板的なものの実装」が可能になります。
書き込み権限はオーナー秘密鍵を持つ人だけに限られるので、改竄もできません。
ステップ 4: Rust から直接使う
本格的にアプリを作るなら、Rust から直接 veilid-core クレートを使うのが最も柔軟です。
Copy[dependencies]
veilid-core = { git = "https://gitlab.com/veilid/veilid.git" }
tokio = { version = "1", features = ["full"] }
Veilid ノードを アプリに組み込む こともできますし、外部の veilid-server に JSON-RPC で接続することもできます。組み込み型にすれば、ユーザは別途ノードを起動する必要がなく、アプリ単体で完結します。VeilidChat も Flutter から Rust の veilid-core を FFI で呼び出してノードを内包する形になっています。
Copyuse veilid_core::*;
#[tokio::main]
async fn main() -> Result<(), VeilidAPIError> {
let update_callback = Arc::new(|update: VeilidUpdate| {
// ネットワークイベントを処理
});
let config_callback = Arc::new(|key: String| {
// 設定値を返す
});
let api = veilid_core::api_startup(update_callback, config_callback).await?;
api.attach().await?;
// ネットワーク参加を待つ
// ... ここに Private Route や DHT 操作のコードを書く
api.shutdown().await;
Ok(())
}
ステップ 5: 自分のプライベートネットワークを立てる
Veilid の面白い特徴のひとつは、「公開の大ネットワークに参加する」以外に、「自分専用の小さな Veilid ネットワーク」も立てられる ことです。
ブートストラップノードに特別なものはなく、どのノードでもブートストラップになれるからです。
具体的には、設定ファイル(veilid-server.conf)の bootstrap セクションを自分の VPS に立てたノードに向け、network_key_password を設定すれば、その鍵を知る参加者だけが入れるネットワークが作れます。
社内 P2P、家族間の写真共有、コミュニティ限定の SNS のようなものを、外部のサーバ事業者に一切頼らず構築できます。
最小構成としては、安価な VPS(月数百円)に常時稼働ノードを 1 台立て、これをブートストラップ兼リレーとして使い、各メンバーの端末は普段はノード起動時のみ参加する、というモデルです。
VPS が一台ダウンしてもネットワーク全体は止まりませんが、新規参入者がいなくなるとブートストラップに困るので、複数立てるとより堅牢です。
何を作るとよいか — 個人の学習プロジェクトアイデア
実際に手を動かして学ぶには、小さなプロジェクトを作るのが一番です。難易度別にいくつか提案します。
最初の一歩としては 「Veilid 上で動く擬似 telnet」 が良いです。
Private Route を介してテキストを送受信するだけのもの。
これだけでルートの生成・共有・通信の流れがひととおり体験できます。
次のステップとして 「家族用の写真共有アプリ」。
DHT にメタデータ(ファイル名、ハッシュ、サムネイル)を置き、実体は Private Route 経由でストリーミング転送する。
アクセス権は DHT レコードのオーナー鍵で管理。中央サーバなしに、家族 5 人で写真を共有できます。
もう少し挑戦的なものとしては 「分散型 RSS リーダー / 掲示板」。
著者が DHT に投稿を書き込み、読者は購読してポーリングする。
Veilid の subkey 機能を使えば、新しい投稿を効率的に取得できます。
応用編としては 「VeilidChat の機能拡張」。既存の OSS にコントリビュートするのは最も学びが多い道です。
グループチャット機能、ファイル添付、E2E 暗号化メモの同期など、欲しいものを足していけます。
まとめ
Veilid は「プライバシーをデフォルトにする」という野心的な目標を持った、新しい世代の分散プラットフォームです。
Tor のような匿名通信、IPFS のような分散ストレージ、libp2p のような P2P アプリ基盤の機能を、Rust の安全性と性能の上に統合しています。
個人レベルで学ぶ価値も実用する価値もあり、Python バインディングのおかげで導入のハードルは思ったよりずっと低いです。
最初の数時間で「サーバなしのメッセージ送受信」が動かせるようになります。
そこから DHT、組み込みノード、自分のプライベートネットワーク構築と進めば、現代の Web の集中化に対する具体的な代替を、自分の手で組み立てられるようになります。
ただし注意点として、Veilid はまだ若いプロジェクトです。
プロダクション利用、特に「生命や自由がかかる用途」では、現時点では枯れた Tor を選ぶのが堅実です。
Veilid の真価は「日常のアプリにプライバシーを民主化する」方向にあり、その意味で個人開発者にとって最も創造的に遊べる分散基盤のひとつだと言えます。
参考リンク:
- Veilid 公式: https://veilid.com/
- Developer Book: https://veilid.gitlab.io/developer-book/
- ソースコード(GitLab): https://gitlab.com/veilid/veilid
- VeilidChat: https://gitlab.com/veilid/veilidchat
- Private Routing 解説: https://veilid.com/how-it-works/private-routing/
- DEF CON 31 ローンチスライド: https://veilid.com/Launch-Slides-Veilid.pdf
- IEEE 論文 “Peer-to-Peer Meets Onion: The Veilid Framework” (2024): https://ieeexplore.ieee.org/document/10679374/