Web3で一元化されたベクトルの分離

1年前に、当時のことだったWeb3スタックについての説明をしました。最近、Multicoinの暗号資産の巨大なテーマを発表し、Web3の投資論文について詳しく説明しました。Web3の重要な意味の1つは、データの所有権とアプリケーションロジックがアンバンドルされることです。

この記事では、このアンバンドリングに本質的な問題について説明します。そして、Web3スタックへの投資をどのように考えているのかです。

データベースとデータはどこでしょうか？

実用的な目的のために、最新のアプリケーションの大部分はデータベースの上にUXとして考えることができます。例外（ビデオストリーミングやビデオゲームなど）がありますが、一般的にこのことは真実です。事実上、Facebook、Reddit、Evernote、Twitter、Google Docs、Gmail、iMessageなど、データベースのUXに簡素化することができます。

Web2モデルでは、ユーザーがユーザーデータを保存し、管理し、ユーザーが必要になるようにします。さらに、Web2アプリケーションプロバイダーは24時間365日、サーバーをオンラインで、ユーザーは頻繁にオフラインで進行します（サブウェイ、接続性、バッテリーの課題など）。Web3モデルでは、中央集権型のアプリケーションプロバイダーが存在し、データの所有のパラダイム全体が変更する必要があります。

これは、いくつかの質問を伴います。

1. ユーザーは、アリスを呼び出すための情報（自分のサーバーを維持していないのでしょうか）、彼女のデータをどこで保存するのでしょうか？
2. そして、アリスがオフラインの場合、コンテンツの送信者がどのようにアリスにコンテンツを送信するのでしょうか？

当然のことながら、常にオンラインでアクセス可能なコンテンツを保存し、アリスが戻ってくると、アリスが戻ってくるとき、彼女に宛てるコンテンツを見つけるために知ることを確認します。このパラダイムには、メッセージングや新聞、ソーシャルメディア、ノートテークアプリなどの伝統的なデータベースアプリケーションをカプセル化します。

これを実現するために、機械的な課題がいくつかあります。

1. アリスではない人は、アリスがそのコンテンツとインデックスを保存して、後でそれをダウンロードできるように、そのコンテンツを見つけ出す必要があります。
2. アリスがそのインデックスを見つけるために知る必要があります。
3. そのインデックスにより、アリスが基礎となるデータ自体を実際に見つかり、ダウンロードする必要があります。
4. データを保存している人は、（プライベートで）コンテンツを読むか、検閲できないはずです。

これらの問題を解決することで、データの所有権とアプリケーションロジックをアンバンドルし、Web3を繁栄させることができます。

最新のWeb3の起業家がこれらの問題を解決する前に、過去のユーザーがこれらの問題をどのように解決しようとしているか考える価値があります。

インターネットを分散化する前の試み

Zeronet、Freenet、Scuttlebuttなど、インターネットを分散するように説明するように、一握りのチームが存在します。彼らは、今日の現代の暗号資産の時代に今日のようにこれをしようとしました。これらの取り組みのほとんどは、たとえば、独裁的な制裁を伴う国のユーザーを対象とした検閲に強いメッセージングや、独裁者を対象としたメッセージボードに焦点を当てています。

興味深い方は、これらのシステムをそれぞれに試すことをお勧めします。UXは、まだまだ不十分だということに気が付くと思います。これらのシステムには多くのUXの問題があり、第一の問題は速度であります。全てが痛いほど遅いのです。

なぜなのでしょうか？なぜ、そんなに遅いのでしょう？

それは論理的に分散しているためです。

これらのシステムは、以下のアーキテクチャのバージョンを採用しています。暗号化されたP2Pメッセージングアプリの文脈で、彼らのアーキテクチャについて説明します。

1. これらのシステムは、誰かがアリスにメッセージを送信し、ボブに代わって、アリスにメッセージを送信するという考えに基づいています。
2. アリスがオンラインで戻ってくると、オフラインで何かを逃したか、ボブに尋ねることになります。
3. 残念ながら、アリスにとっては、1）ボブが現在オンラインで、2）彼がオフラインであった間、オンラインで、3）ボブがオフラインである間、ボブが実際にオフラインであるという保証はありません。これを解決するために、ボブはアリスに宛てたメッセージを気づいているかどうか、彼のピアーに尋ねることができます。しかし、これらのピアーはオフラインで存在する可能性があり、不完全な情報を持っている可能性があります。

このパラダイムでは、メッセージをどこで配信し、誰がメッセージのインデックスを保存すべきかどうかが明確にされていないため、メッセージ配信を保証することはできません。これにより、受信者がオンラインで帰還した場合、その結果が彼女に宛てたメッセージのリストや、データメッセージ参照の場所が知ることができません。

P2Pソーシャルネットワークの構築に焦点を当てているScuttlebuttは、Facebookのようなダブルオプト・システムを採用することでこれを解決しようとします。つまり、アリスとボブが友達になったとき、アリスと互いに友達のリストを共有し、アリスに代わって、アリスにアリスが出版したコンテンツをインデックスし、保存することができます。これは、ボブがその代わりに、そのようなことをアリスが友人に教える必要があります。そして、アリスの友人がアリスがオフラインである間、更新を公開すると、Aliceの友人がAliceのホストとして、アリスのボブにその更新を送信することができます。

ZeronetとFreenetは、P2Pソーシャルネットワークよりも一般化した同じようなモデルを使います。ただ、友人モデルにダブルオプトが存在しません。これは、システムに複雑なものを数多く追加し、事をさらに遅くします。Scuttlebuttモデルとは異なり、FreenetとZeronetのユーザーは他のユーザーにランダムにピングして、彼らが知っている情報について尋ねる必要があります。これは、これらのシステムが非常に遅いことの要因です。

1. アリスが最終的にオフラインで、彼女が逃したすべてのインデックスを一緒に置いたとします。つまり、Carolが写真を送って、Daveが「dave.com/alicepic1.png」に写真を保存していることを知っています。デイブがオフラインの場合は、アリスがどうやって写真にアクセスできるのでしょうか？

これらの問題は単純なものではありません。インターネットを分散化するのは難しいことです。

論理的かつアーキテクチャ（De）中央集権化

前述のすべての問題の根本的な原因は、論理的に集中型のストレージとインデックスがないことです。論理的に中央集権型のストレージとは何か？それに答えるには、分散型システムの3つのベクトルが理解するのに役立ちます。

1. アーキテクチャ
   • システムのコンピュータの数
2. 政治
   • システムに影響力を与える人の数
3. 論理的 外部エージェントがシステムと相互のインターフェースの数

これらの概念をより強く説明するために、Vitalik Buterinによるこの記事をお勧めします。

Web2の独占は、論理的に中央集権型のストレージに依存しているため、前述の問題のすべてを解決しました。つまり、アリスがオンラインで戻ってくると、中央集権型のストレージを維持する中央集権型のウェブサービスを尋ねることになります。ウェブサービスは、すべてのユーザーメッセージをコントロールし、正しいメッセージを返すデータベースをクエリします。

このモデルの問題は、これらのWeb2システムはあらゆる種類の中央集権型のものをバンドルするということです。論理的に中央集権型のものであり、政治的に中央集権型のものです。（そのような目的を超えては、）アーキテクチャ的に中央集権型のものです。

では、論理的に中央集権型ですが、アーキテクチャと政治的に分散型のストレージシステムはありますか？

幸いなことに、答えは、断然に「はい」です。契約ベースのストレージでは惑星間ファイルシステム（IPFS）、永久ストレージではArweave（契約ベースのストレージ：Z回収可能性保証でX期間、Y期間、データを保存します。AWS、GCP、Azure、Filecoin、Siaはすべて契約ベースのストレージシステムです。

システムが論理的に中央集権型ですが、アーキテクチャと政治的に分散型であることはどういう意味ですか？これを理解する最良の方法は、コンピューターが現在ウェブ上の他のサーバーから基本的なファイルを取得方法を検討し、それをIPFS/Arweaveアプローチ（コンテンツベースアドレス）と比較することです。

Web2アーキテクチャでは、アリスがサーバーから写真をダウンロードしたい場合、アリスが次のようなURLに移動します。website.com/image.pngアリスがそのURLに向かって、どうなるのでしょうか？

DNSを使用すると、アリスはwebサイト.comのサーバーを見つける場所を知り、サーバーに「/image.png」のローカルファイルシステムにホスティングしているイメージをサーバーに求めることになります。サーバーが協調したいと仮定すると、/image.pngのディレクトリをチェックし、存在する場合はそのファイルが送信されるでしょう。

このシステムがどのように脆弱なものに注意してください：ファイルが移動した場合、サーバーは忙しい場合、サーバーは忙しいため、何らかの意味でサーバーは協調的でない場合、リクエストは失敗します。

今、これはウェブが構築する基盤です。

IPFSやArweaveで使用されるもののようなコンテンツベースのアドレスシステムでは、アリスのURLが訪れるようなものです。

人間が読めるわけではありませんが、そのコンテンツから決定的に生み出されます。つまり、宇宙に1つのコンテンツが存在し、ハッシュすると、その正確な文字列が生成されます。IPFSとArweaveの魔法は、コンピューターがQmTkzDwWを解決できる複雑性のすべてを処理することです。

（IPFSの機能について詳しく知るなら、この6部、シリーズは素晴らしい出発点です。

IPFSとArweaveネットワークのコンテンツは、多くのマシンに保存されています。コンテンツが保存されているマシンやそのマシンが世界中のどこに配置されているのかに関係なく、これらのプロトコルは、実際のコンテンツが保存されているところに関係なく、QmTkzDwWのようなアドレスが解決します。

これは、コンテンツベースのアドレスの魔法です。単一の論理的なインターフェース（コンテンツベースのアドレス）が、基礎となるデータがアーキテクチャ的および政治的に分散化された広大なネットワークでどこに保存されているかに関わらず、常に正しく解決します。

この記事の冒頭で概説された4つの主要な技術的課題のうち、コンテンツベースのアドレスが#1、#3、#4を解決します（コンテンツを保存し、コンテンツがダウンロードできるようにします。しかし、2番目はどうなりますか？どこでデータを探すのでしょうか？

インデックス

IPFSとArweaveは、論理的に中央集権的なが、アーキテクチャ的かつ政治的な分散型ファイルシステムとして機能しますが、これらのシステムはデータベースではありません。つまり、クエリする方法はないのです。「Preticsは、日付XとYの間でBob氏が送られたすべてのメッセージを提示してくれます。」

幸い、この問題を解決する方法はいくつかあります。

1つのアプローチは、ブロックチェーンに直接保存することです。ブロックチェーン自体は、論理的に中央集権型ですが、アーキテクチャ的かつ政治的に分散型データベースです。The GraphやdFuseのような分散型サービスを使用する場合、アリスはブロックチェーンに保存されたインデックスをクエリすることができます。ブロックチェーンは、基礎となるデータを保存ではなく、データのハッシュにすぎないのです。そのハッシュは、IPFSやArweaveに保存されたコンテンツへのポインターにすぎないのです。GraphとdFuseが現在、両方がライブで存在しており、多くのアプリケーションは、コンテンツアドレス付きシステムに保存されたデータをポイントするチェーンでハッシュを保存するこのモデを採用しています。

2番目のアプローチは、Textileを活用することです。Textileは、IPFS上にあるプライベート、暗号化された個人データベースとして機能するThreadsと呼ばれる独自の技術を構築してきました。このデータベースはIPFS上に構築されているため、論理的に中央集権型が、アーキテクチャ的かつ政治的に分散化されているのです。論理的に中央集権型データベースとして、送信者と受信者は情報をどこから送信し、読むことを知っています。さらに、Textileは最近、CafeをCafeを立ち上げ、ユーザーは（Threadをローカルにホストするのではなく）スレッドをサーバーを確立できるようにします。Textileの次のステップは、他のユーザーにカフェをホストするためにバリデーターにインセンティブを与える経済レイヤーを構築することです。これは、FilecoinがIPFSの経済レイヤーであることに似ています。

3つ目は、OrbitDBを活用することです。OrbitDBはTextileのThreadsに似ています。ただし、OrbitDBは主に公開データ（分散型Twitterの構築など）を主に設計していることを除いて、TextileのThreadsは、プライベート情報のための暗号化と鍵管理をネイティブ的に統合するのに対し、TextileのThreadsはTextileのプライベートな情報（P2Pメッセージングなど）の管理を主にしています。Textileと同様、OrbitDBは現在利用可能で、OrbitDBチームは基盤となる技術の上に経済層に取り組んでいます。

最後に、分散化の異なるベクトルによる、効率的な従来のデータベースであるものを構築している多くのチームがあります：Fluenceの構造は、BFTの保証付きパーミッションレスの設定で操作し、Blueselleは、政治的に一元化された一式のマスターノードと、アーキテクチャー的に分散された一式のレプリカ ノードで2層のシステムを構築しています。

スマートコントラクトチームが、Solanaのレプリケーターのような、データ利用可能性の問題を大規模に解決するために行っている作業を考慮すると、私たちは従来のデータベース上にBFTレイヤーを追加するという考え方には懐疑的です。代わりに、The GraphとdFuseの形式でデベロッパーのAPIレイヤーでは、Textileのような「暗号ネイティブ」のデータベースへの投資を選択してきました。

上記のIPFS、Filecoin、Arweave、The Graph、dFuse、Textile、OrbitDBを説明するプロトコルとサービスには、Web3が果実に到達する明確な道があります。これらのサービスはすべて現在存在し、実質的な暗号資産経済で実質的な実質的なものではないが、本格的なウェブスケールの形で実質的なものはありません。しかし、最も重要な問題のソリューションは知られています。政治的およびアーキテクチャ的な分散型システム用に、一つの論理的に一元化されたインターフェイスがあるのです。

他に何かありますか？

もっと高いレベルのロジック

論理的に中央集権型のものです。インデックス、検索は、高位の論理について考えることができます。数例：

1. アリスは、複数のアイデンティティをどのように管理しますか？例えば、アリスはFacebook/Google/Snapchat/Redditで同じ公開のキーを使用したくないかもしれません。そして、公にリンクせずに、単一のインターフェイスでアイデンティティを管理したいと思うなら、どうなるのでしょうか？
2. アリスがボブのプライベート情報を送りたいと思っていますが、定義では公開システムとなっているIPFSまたはArweaveに保存するとします。彼らは、完璧なフォワードキー（PFS）ハンドシェイクを活用する必要があります。PFSは非同期の方法でどのようにセットアップし、関連するキーを管理するのでしょうか？
3. 従来の暗号化スキームが通信するのは2人の当事者にのみであることを考慮すると、システムがメッセージボードや大規模なチャットグループなどの大規模なグループのプライベートコミュニケーションをどのようにサポートすることができます？
4. システムは、グループ発見、ユーザーデータリカバリ、コンテンツの削除など、共通のUXパターンをどのように可能にするのでしょうか？

これらは明確にな技術的な課題ですが、私はこれらすべてが「高レベルのロジック」の問題として広範にバケツします。

Textileのスレッドは、このような問題に正確に取り組んでいます。多くの点で、IPFSのiCloudとして、テキスタイルを考えることができます。この類推は完璧ではありませんが、一般的には機能します。iCloudがアプリケーション用のクロスデバイス同期およびデータバックアップを抽象化するのと同じように（より良いユーザーとデベロッパー経験の両方を提供します）、Textileはデベロッパーのためにアプリケーション開発をシームレスにするために、IPFSの上位に他の高度な論理ツールをすべて提供し、IPFS上のユーザーのシームレスなクロスデバイス同期とバックアップを保証します。

今後の予定

Web3エコシステムは、解決する問題の種類、チーの場所、採用している経済モデルなど、多くの次元で非常に多様です。Web3スタックが集まっていることは、論理的に中央集権型のエンティティが存在しないという事実に驚くべきことです。しかし、システムにエントロピーが多く存在することを意味します。このため、高位のテーマを理解することは困難です。このエッセイで、私は以下のようにそれを抽出しました：

Web2からWeb3への移行において最も大きな課題はシステムからの移行であり、論理的、アーキテクチャ、および政治的の3つすべての一元化のベクトルは、論理的に一元化されていますが、政治的およびアーキテクチャ的に分散化されたシステムにバンドルされています。

Web3スタックでコアインフラやアプリを構築する場合は、TwitterでDMに連絡してください。私たちは、より多くのWeb3投資を予定しています。Web3は、今後10年間何兆ドルもの価値をロックするパラダイムシフトになると考えています。そして、基盤的なWeb3インフラを構築する最高の起業家を支援する予定です。

この記事にフィードバックしてくれたAndrew HillとSam Williamsに感謝を申し上げます。

*開示：Multicoin CapitalはSolana、The Graph、Textile、Arweave、Dfuseに投資しました。Multicoin Capitalは、この記事に挙げられている資産の公開から72時間（「No Trade Period（非取引期間）」）の間、「No Trade Policy（取引を行わない方針）」を順守しています。 役員、取締役または従業員は取引禁止期間中、前述の資産を購入または売却してはいけません。*