ディスカッション (11件)
2000年代初頭にスタートした私のP2Pプロジェクト「Freenet」を、過去5年ほどかけてゼロから再設計し、新たに「Hyphanet」として生まれ変わらせました。新しいFreenetは昨年12月から稼働しており、分散型グループチャットのRiver[1]や、分散型CMSのDeltaといった初期アプリケーションもすでに動いています。ユーザーコミュニティではゲーム開発なども始まっており、検索・レコメンドエンジンのAtlasといった興味深いプロジェクトも進行中です。技術的な核心部分として、この新しいFreenetはグローバルな分散型キー・バリューストア(KVS)として設計されています。キーに関連付けられたWebAssemblyコントラクトが、どのような状態(値)が妥当か、どのように変更できるか、そしてピア間でどう効率的に同期するかを定義する仕組みです。一貫性の問題に対しては、独自のアプローチを採用しました。各コントラクトは状態をマージする操作を定義する必要があり、これは可換(commutative)である必要があります。つまり、どんな順序で複数の状態をマージしても最終結果は同じになります。この仕組みにより、状態の更新はウイルスのようにネットワーク内に拡散し[2]、数秒以内にグローバルな整合性を保った状態へ収束します。Webアプリの仕組みは従来のWebと似ており、ネットワークから直接ブラウザに読み込んで実行可能です。ただし、データセンター上のAPIではなく、ローカルで動くFreenetピアにWebsocket経由で接続し、コントラクトを操作する構成になっています。主要なデスクトップOS向けのインストーラーを用意しており、すぐに試すことができます[3]。質問があれば何でも聞いてください。FAQ[4]や、3月に行った登壇内容[5]もぜひチェックしてみてください。
すごく面白いプロジェクトですね!
整合性の問題に対して、独自の(私の知る限りですが)解決策を開発しました。すべてのコントラクトは、関連する状態に対する「マージ」操作を定義しなければなりません。この操作は可換である必要があり、つまり複数の状態をどのような順序でマージしても同じ結果が得られるということです。
これについて詳しく学べる場所はありますか?CRDTやCmRDTとはどう違うんでしょうか?
いいですね。WASMで定義されたネットワーク動作のようなものをずっと期待していたんです(任意の整合性アルゴリズムが使えるなんて最高!)。もう少し詳しく調べてみます :)
(私が試したかった主なこと:GraphQLの代わりに、リクエストと一緒にWASMブロブをサーバーに送り、それを実行してレスポンスのフィールドフィルタリング、リクエストのパイプライン化、同時リクエスト時の「エラー発生時の失敗設定やエラーのペアリング」などを行いたいんです。議論の余地はありますが、これを使って呼び出し先内部のリトライ制御なんかもできそうですよね。)
「ゴーストキー」へのより良いアプローチとして、一定量の暗号資産を0x0(バーン用アドレス)へ送ることを必須にするのはどうでしょう。現在の実装(Freenetへの寄付を必須とする)だと、実質的にFreenet財団に無限のレピュテーション(ゴーストキーをアイデンティティとして受け入れる他の潜在的なプロジェクトも含めて)を与えることになり、分散化という側面が少し損なわれている気がします。
非常に興味深いです。イデオロギー的な動機以外に、何が長期的にノードを動かすインセンティブになるのか気になります。
例えばFreenetが拡大した場合、いずれ何らかの経済的な仕組みが必要になるかもしれません。Filecoinが分散ストレージを扱っているのと似たような仕組みですが、それをアプリの状態管理に応用するイメージです。例えば、アプリの状態を保持したり、確実に提供したりすることに対してピアに報酬を支払い、それが実行されていることを証明させるような仕組みが考えられます。
特筆すべき点として、このプロジェクトは本来のFreenet開発チームの成果を切り捨てるという裏での決定によって生まれたものです。
元のチームの誰にも相談することなく、別の開発者による書き直しが優先されました。
これは事前の議論なしにメーリングリストで発表された、独りよがりな決定でした。
旧チームは同意していませんでしたが、「理事会」の決定によって強行されました。
その「理事会」とは、10年以上プロジェクトで活動していなかった人々の集まりです。
https://www.mail-archive.com/devl@freenetproject.org/msg55262.html
既存のオリジナル「Freenet」の資金は、もちろん新しい方に転用されました。
新しい「Freenet」はもはや設計目標として匿名性を掲げていません。
一方で古い方は、「Hyphanet」という新しい名前で存続し、メンテナンスされています:
自然なマージ関数を持たない値(あるいは書くのが面倒な値)の場合、更新ログを同期するほうが合理的ではないでしょうか。つまり:
-
同期される値はクライアントの更新履歴であり、何らかの最終的な整合性順序(例:ハイブリッド論理クロック)でソートされている。マージは更新セットの和集合をとる。
-
ユーザーから見える値は、任意のコントラクトコードを使ってこれらの更新を順番に処理した結果。
単純な「最後に書き込んだ人が勝つ(Last-writer-wins)」値には大げさかもしれませんが、これならかなり一般的なデータ型や任意の更新関数をサポートできますし、アプリケーション固有の不変条件を維持することも可能です。
AutomergeというCRDTライブラリはすでにこのような仕組みになっています[1][2]が、JSONデータに対する特定の更新しか許容していません。あなたのコントラクトを通じてコードを共有できれば、それを任意のデータや更新に一般化するという難しい部分を解決できるはずです。
[1] https://automerge.org/
[2] https://arxiv.org/abs/1805.04263
私たちが使っているサービスに対して、もっと分散型のアプローチを模索すべきだと強く思います。
ローカルファーストなアプローチにも重点を置いてほしいですね。
この実験は、UNIXの精神にならってgitとテキストファイルを構成し、ソーシャルネットワークを構築しています:
とても面白そうですね!数ヶ月前、P2Pの現状について調べていた時にたまたまあなたのWebページを見つけました。P2Pプロジェクトが今も活発なのは嬉しいですね。
すごく興味深いです。ローンチおめでとうございます、成功を祈っています!
https://internetcomputer.org/ もありますよ。