[トーク] Vac, Waku v2 とイーサリアムメッセージング

15 min readJan 3, 2021

以下の投稿は、11月5日開催の台北イーサリアムミートアップで行われた講演の記録です。録画ビデオもあります。

0. イントロダクション

こんにちは！ Vacでプロトコル研究をリードしているオスカル（Oskar）です。今回の話は二部構成になっています。最初に Whisper から Waku v1、そして現在の Waku v2 に至るまでの道のりについてお話しし、次にイーサリアムにおけるメッセージングについてお話しします。この話の後で、Waku v2 とは何か、Waku v2 が解決しようとしている問題点は何か、そしてイーサリアムでのメッセージングはどう役に立つのか、ということを理解する必要があります。

パート1 — VACとWHISPERからWAKU V1、WAKU V2への旅

1. Vacの紹介

まず、Vacとは何か？ VacはStatusをイーサリアムとセキュアメッセンジャーへの入り口にするため我々の努力から生まれました。Vacはp2pセキュアメッセージングのためのモジュール型プロトコルスタックで、リソース制限されたデバイス、プライバシー、検閲耐性に特別な注意を払っています。

今日は主に Waku v2 について話します。これは Vac プロトコルスタックのうちのトランスポートプライバシー/ルーティングの部分です。トランスポートなどを扱う libp2p などの p2p オーバーレイの “上 “にあり、ダブルラチェット等を用いたメッセージング暗号化を担う会話セキュリティ層の “下 “にあります。

2. Whisper から Waku v1 へ

当初はWhisperがありました。Whisperはイーサリアムにおける三種の神器の1つでした。コンセンサスや計算のためのイーサリアム、メッセージングのためのWhisper、ストレージのためのSwarmです。

しかし様々な理由から、Whisper は注目を浴びることができませんでした。開発が段々と衰退し、約束事が多すぎ、非常に効率が悪く、携帯電話などでの動作に適さないなど、多くの問題を抱えていました。にもかかわらず、Statusは2017年頃から2019年までアプリで使用していました。私の知る限り、Whisperをプロダクトとして用いた例は唯一ではないにしても数少ないものの1つでした。

当面の問題を解決するため、Whisper を Waku にフォークして適切なスペックで形式化しました。これによりライトノードの帯域幅の問題を解決し、スパム対策をより効果的にするためにレート制限を導入し、履歴メッセージのサポートを改善しました。

この旅に興味のある方は、今年の初めにパリでディーンと私が行ったEthCCトークをチェックしてみてください。

Status が2020年初頭に Waku v1 へアップグレード。次は何をするのか？

3. Waku v1 から v2 へ

私たちはまだ終わったわけではありませんでした。私たちが行った変更はとても漸進的で、可能な限り早く、目に見える改善を行うためのものでした。そのため、フルノードルーティングのスケーラビリティや、libp2pを使ったより多くのトランスポート、より強固なセキュリティ、より良いスパム対策、インセンティブの向上といった、根本的な問題に取り組むことができませんでした。

この Waku v2 の取り組みに弾みをつけることが、2020年7月から取り組んできたことになります。この作業はいくつかのパーツを中心にしています。

(a) libp2p への移行
(b) より良いルーティング
© アカウンティングとユーザ実行ノード

全体的なテーマは、Waku ネットワークをよりスケーラブルで堅牢なものにすることでした。

またスケーラビリティ調査も行い、 Whisper と Waku v1 の提供するルーティングに本質的な欠如があることで、ネットワークがどういう事象により問題に直面するかを明らかにしました。

これについての詳細はこちらをご覧ください。

3.5 Waku v2 — 設計のゴール

一つ話を戻して、Waku v2 が他のソリューションと比較してどのような問題を解決しようとしているのでしょうか？どのようなタイプのアプリケーションで Waku v2 を使うべきか、そしてその理由は何か？私たちは以下のような設計目標を持っています。

標準化したメッセージングを必要としている ：多くのアプリケーションでは、異なるサブシステムまたは異なるノード間で通信するために、何らかの形式のメッセージングプロトコルを必要とする。このメッセージングは、人間から人間へ、またはマシンからマシンへ、またはそれらをミックスしたものである。
ピアツーピアである ：アプリケーションがピアツーピアソリューションに対応する必要に迫られる場合がある。
リソースが制限されている ：アプリケーションがリソースや利用環境など何らかの形で制限のある環境で実行されることが多い場合。例えば、以下のようなものです。
— 帯域幅、CPU、メモリ、ディスク、バッテリーの制限がある
— 表立って接続がしにくい
— 断続的に接続されており、ほとんどオフラインの状態
プライバシーの要望 ：アプリケーションに、匿名性、通信時のメタデータ保護など、何らかのプライバシーの保証が望まれている場合。

モジュラー型で行うのはそういうことです。つまり正確な要件があればそれ相応のトレードオフが出てきます。例えば、メタデータ保護を得るのなら帯域幅をトレードオフする必要がありますし、その逆もあります。

リソースが制限されたデバイス向けに設計するという概念は、フルノードとライトノードの間に段階性を持たせた環境適応型ノードの概念にもつながります。例えば、携帯電話をモバイルデータからWiFiに切り替えたら、より多くの帯域幅を処理できるようにしてもよいでしょう。

4. Waku v2 — Breakdown

Waku v2は今どこにいて、どのように構成されているのでしょうか？

libp2p 上で動作しており、先週くらいに2回目の内部テストネットを立ち上げました。余談ですが、私たちはテストネットの名前を台北の地下鉄の駅にちなんでつけています。1つ目は南港（Nangang）、もう1つが頂埔（Dingpu）です。

メインの実装は、Ethereum 2 クライアントである Nimbus に装備される nim-libp2p を使って Nim で書かれています。ブラウザで Waku v2 を動かすための PoC もあります。スペックレベルでは、Waku v2 を構成するコンポーネントに対応した以下の仕様があります。

Waku v2 — 標準化したメッセージングを p2p のコンテキストで提供し、プライバシーに焦点を当て、リソースが制限されたデバイス上で実行することを目的とした主な仕様です。
Relay — より優れたルーティングを提供する PubSub の主要な仕様です。GossipSub の上に構築されており、Eth2 も同様に大きく依存しています。
Store — ライトノードがほとんどオフラインの場合に、履歴メッセージを取得するための 1–1 プロトコルです。
Filter — 帯域幅に制限があるライトノードが、気になるメッセージのみ（またはほとんど）を取得するための 1–1 プロトコルです。
メッセージ — いくつかのベーシックな暗号化とコンテンツのトピックを取得するために、ペイロードを定義します。Whisper/Waku v1 のエンベロープにおおよそ対応しています。
ブリッジ — Waku v1 と Waku v2 の互換性を保つためのブリッジングの方法を書いています。

現在、ブリッジを除くすべてのプロトコルがドラフトモードになっており、実装はされているが正式版の水準とは見なされていません。

Waku v2のアップデートの詳細はこちらで詳しく読むことができます（それ以降もいくつかの進展がありましたが）。Waku v2 の主な仕様もあります。

5. Waku v2 — 近日登場

次は何が来るのか？いくつかあります。

Statusで正式プロダクト版として使用するには、Nim Node API を使用してメインアプリに統合する必要があります。ブリッジも実装してテストする必要があります。

その他のユーザにはブラウザからの利用を可能にするため、現在APIの見直しを行っています。例えば、この体験を素晴らしいものにするため、Nim-libp2p には Nim のよりセキュアな HTTP サーバ、Webソケット、WebRTC のサポートなど、いくつかの基礎的なインフラストラクチャが必要です。

また、どのレベルでコンテンツの暗号化を行うかについてもいくつか変更を加え、APIで使いやすくする必要があります。これはノードに鍵を与えずにノードを使用できるということで、環境によってはこれが便利です。

より一般的な話としては、製品としてすぐに使えるもの以外に、現在あるいは近日中に取り組むいくつかの大きなものがあります。それは以下のようなものです。

トピックシャーディングを使用したスケーリングの改善
フルノードのアカウントにインセンティブを与えるアカウンティングとユーザ実行ノード
より強力で厳格なプライバシー保証、例えば GossipSub の研究、リンク不可能なパケットフォーマットなど
プライバシーを保護するスパム対策のためのレートリミットヌリファイア（Barry Whitehat が以前発表したようなもの）

Ethereum M2M メッセージングのサポートも強化されます。次はそれについて話しましょう。

パート2 — イーサリアムメッセージング

以下に記載することの多くは、以前 Ubuntu でUXアーキテクチャ責任者を務めた John Lea が Status で行った探索的な作業からヒントを得ています。

6. なぜイーサリアムメッセージングか？

Waku v2 は今のところ Status アプリで主に使用されるため、人間同士のメッセージングだけのためのものと思われがちです。しかしそのゴールとは、機械同士のメッセージングだけでなく、他のタイプの情報を含む標準化されたメッセージングにも使えるようにすることです。

Ethereum M2M メッセージングとは？ Ethereum/Whisper/Swarm の三種の神器にさかのぼると、メッセージングコンポーネントは DApps 間のメッセージを促進し、ビルディングブロックとして機能するものと考えられていました。これは以下のようなことに役立ちます。

オンチェーントランザクションの削減
オペレーションの待ち時間を短縮
中央集権型で管理されるサービスの分散化（WalletConnect のようなもの）
DApps のUXを改善する
ライブ情報を放送
ステートチャネルのためのメッセージトランスポート層

といった感じです。

7. なぜイーサリアムメッセージングか？（続き）

イーサリアムメッセージングで Waku がに使用されることで解決できる実用例は何でしょうか？

マルチシグ転送が1回のオンチェーントランザクションで済む
DAO投票が1つのチェーントランザクションだけで済む
DApps がユーザに直接プッシュ通知することが可能になる
ユーザが DApps からのリクエストに直接応答できるようになる
分散型Wallet Connect

等々。

8. 実現するために必要なことは？

各パートごとに追ってみましょう。

分散型M2Mメッセージングシステム（Waku）
ネイティブウォレット（Argent、Metamask、Statusなど）
DApp が sM2Mメッセージングの恩恵を受けること
ユーザが問題を解決

それぞれ1つ1つに要件群があります。メッセージングシステムには分散化、拡張性、堅牢性などが必要です。ウォレットはメッセージングレイヤーをサポートする必要があり、Dapps はこれを実装する必要があります。

実に多い！普及率を上げるまでの挑戦です。DApps が必要としていないのにウォレットの開発努力を正当化することがパラドックスであり、同様にウォレットが Waku をサポートしていないのに DApps の開発努力を正当化するのがまたパラドックスです。加えて、Waku が必要とされていない時に Waku の利用率が求められます。さあ、どのようにしてこれをより小さなタスクに分けていけばよいのでしょうか？

9. 現状の打開と高次元のロードマップ

私たちは小さいことから始めていきます。重要な機能にいますぐ使われることはなく、その必要もありません。「こんなのができたらいいな」という感覚でハイブリッドなアプローチを取ることができます。

Whisper をフォークして、スケーラビリティやスパムなどの問題を解決する。これは現在進行形の作業です。パート1で話しました。
Dapp開発者のためのメッセージングAPIを公開する
WalletConnect の分散型バージョンを実装する。現在は WalletConnect は中央集権型のサービスで Dapps に接続している。素晴らしいUX。
DAO/マルチシグの連携問題を解決する。例えば、トランザクションに署名する時にウォレットから派生したキーにメッセージを送信する
DApp to ユーザ、ユーザ to DAppの通信をより多くの DApps に拡張。ウォレットやアプリでの採用を促進するため教訓や事例を用いる

そして、そこからさらにビルドアップさせていきます。

10. 採用中です！

多くのウォレットや DApps の主な環境は Javascript とブラウザで行われます。現在、私たちはこの取り組みをさらに推し進めるために、Waku JS Wallet の統合リードを募集しています。

後で話を聞きに来るかここに応募してください。

以上です。Status, Telegram, vac.dev で私たちを見つけることができます。私はツイッターもやっています。