原題: 「Web を理解する 3 — ユーザーが制御するインターネット」
編纂 | ベーズ研究所
編纂 | ベーズ研究所
最初のレベルのタイトル
文章
今日のインターネットには、次の 2 つの重要な特性が欠けています。
- 信頼できるオペレーターから独立した「状態」を保持しません。
- 状態を転送するネイティブメカニズムがありません
状態の欠如は、HTTP や SMTP など、Web が構築されているプロトコルの単純さの結果です。どの時点でも、ノード (インターネットに接続されているデバイス) の履歴または現在の状態をクエリしようとしているかどうかはわかりません。ユーザーの観点から見ると、これは、新しいブラウザー (履歴、お気に入り、保存された設定、オートコンプリートなし) から初めてインターネットを使用するときと、インターネットに接続されているものを使用するたびに同じです。サービスを使用しようとするたびに、またはデバイスの電源を入れるたびにお気に入りのアプリをすべてダウンロードしようとするたびに、ユーザー情報を送信しなければならないことを想像してみてください。インターネットは使用できなくなるか、少なくとも非常に非効率になります。
ただし、状態は価値を表すことができるため、サービスやアプリケーションの開発にとって重要です。したがって、2 つの重要な開発によりギャップが埋められました。まず、Brendan Eich 氏が強調しているように、Cookie は JavaScript で書かれた Web ベースのアプリケーションが各デバイス上でローカルに状態を保存できるようにするために発明されました。ただし、Cookie の問題は、Cookie がユーザーではなくサービス プロバイダーによって作成および制御されることです。ユーザーは、どのプロバイダーが自分の状態を提供するか、どのプロバイダーが自分の状態にアクセスできるかを制御できません。
状態の欠如に対処するための 2 番目の開発は、ユーザーの状態を独自のマシン上に保持する集中型サービス プロバイダーです。今日、Google や Facebook などの大手インターネット企業は、数十億人の国と、それらが生み出す価値を所有しています。ユーザーはすでに同じ会社が生み出すサービスや価値の恩恵を受けているので、それ自体には何の問題もありません。問題は、インターネットが一般大衆よりもこれらの中央集権的な企業にどのような恩恵をもたらすかということです。
インターネットに欠けている 2 番目の重要な特性、つまり状態を転送するためのローカル メカニズムの欠如は、部分的には最初の問題の副産物です。状態 (およびそれによって作成される値) を保持できない場合、それを転送することはできません。価値を簡単かつ効率的に移転する能力は、経済発展と現代の金融の核心です。価値移転の効率を高める改善は、連鎖的にプラスの効果をもたらします。今日のインターネットにより、情報の転送が桁違いに簡単になり、それによって新しいビジネスやサービスの大きな可能性が生まれました。ただし、企業が価値を取引する簡単な方法がない場合は、サービスを収益化する別の方法を見つける必要があります。
これが、長年にわたり、ウェブの既存のビジネス モデルが広告になってきた理由です。広告ビジネスは、何十億ものユーザーの状態を効率的に保存し、送信できる唯一のビジネスだからです。繰り返しますが、広告自体は何も悪いことではありません。しかし、今回の問題は 3 つあります。
- 第三者仲介業者は、各広告取引を促進し、そこから利益を得ます。
- 広告は既存のビジネスを優遇し、新しいビジネスに不利になり、経済の成長の可能性を制限します。
- より豊かな広告経済は、より多くのユーザー データ (広告モデルのフィードに使用される) に依存するため、ユーザーとの一貫性のないインセンティブが生じ、ユーザー エクスペリエンスが低下します。
インターネットの方向性
ウェブ自体はテクノロジーの発展です。それは単なるパイプの束であり、人間がそれを使って何をするかには無関心です。最終的には、それをどこに向けるかは人間が決める必要があります。ネットワークの今後 1 ～ 2 年間は、次のことを推進するのが良い方向です。
- 地域の経済価値を生み出すあらゆる参加者。
- このネイティブ値を任意の参加者に転送します。
最初のレベルのタイトル
Part2: Web3.0の構成
第 1 部で説明したように、今日のインターネットはステートレス インターネットです。参加者は自分自身の状態を維持したり、ある状態から別の状態にローカルに転送したりすることはできません。ビットコインを皮切りに、ブロックチェーンはデジタルネイティブな方法で状態を保存する方法を私たちに提供してきました。暗号通貨とブロックチェーンのエコシステムに携わる私たちは、この新しい基本的な機能を Web 3.0 と呼び始めました。私たちはまだ初期段階にありますが、それがどのようなメリットをもたらすかについてはすでに大まかに把握し始めています。
画像の説明
画像: Web 3.0 のモジュラー アーキテクチャ
上のフレーム内のレイヤーは上から始まり、y 軸に向かって構築されます。色は、異なるレイヤーのモジュール間の互換性を表します。たとえば、上に示した今日の暗号商品 (黄色) は、EVM (青から黄色) と互換性がありますが、ビットコイン スクリプト (緑から赤) とは互換性がありません。次に、EVM はイーサリアム ブロックチェーン (青) と互換性がありますが、ビットコイン ブロックチェーン (緑) とは互換性がありません。これにより、ビットコイン スクリプトと互換性があり、ビットコイン ブロックチェーンに記録される将来の暗号商品をフレームワークに組み込むことができます (ただし、技術的な課題によりこれは可能性が非常に低いです)。このモジュール性は、Web 3.0 の堅牢性にとって非常に重要です。1 つのレイヤーをアップグレードするときに、その下にあるすべてのものを完全に書き直す必要はないからです。
状態層
状態レイヤーは、その下で発生するすべての状態を保持します。これは、ほぼ完全にブロックチェーン インフラストラクチャによって提供され、優先ネットワークのルールに従う限り、あらゆる参加者が参加することができます。成功するネットワークの目標は、今日の DNS プロバイダーと同様に、デフォルトの信頼できるインフラストラクチャになることです。意図したとおりに機能するときは (99% の確率で) 誰もそれを認識しませんが、そうでないときは、私たち全員が苦しみます。
このレイヤーは、パブリックレイヤーまたはプライベート/許可されたレイヤーにすることができます。状態はデフォルトで単一かつ普遍的な真実であり、プライベート レイヤーを作成することは並行世界を作成することに似ていると主張する人もいるでしょう。パブリック層とライセンス層の間には技術的な違いもありますが、それらはこの記事の範囲を超えているため、製品の設計上の選択として開発者に委ねられます。
コンピューティング層
コンピューティング層
ソフトウェアを使用すると、人間はコンピュータに指示を与えることができます。 Web 3.0 の計算層を使用すると、人間は状態層に必要なことを実行するように指示できます。ただし、すべてのコンピューティング レイヤーですべてのことができるわけではありません。たとえば、ビットコインのスクリプトはオーダーブック以外の取引のみを許可するという点で非常に制限されています。もう一方の端のイーサリアム仮想マシン (EVM) は完全なチューリング完全マシンであるため、EVM 対応のステート層によって任意の複雑な計算を実行できます。
アプリケーション開発者 (およびブロックチェーン開発者) にとってコンピューティング層の選択は、特定のアプリケーションを実行できるブロックチェーンを決定するため、重要な要素です。たとえば、EVM にコンパイルされたアプリケーションは現在イーサリアム ブロックチェーン上で実行できますが、ビットコイン ブロックチェーン上では実行できません。イーサリアム財団は、イーサリアムのデフォルトのコンピューティング層を、WebAssembly (WASM) に基づいた eWASM と呼ばれる別のテクノロジーに変更することに取り組んでいます。 Dfinity などの他のステート レイヤー プロジェクトも、WASM と互換性を持つ予定です。これは、eWASM にコンパイルされたアプリケーションは、理論的には Ethereum および Dfinity ブロックチェーンだけでなく、WASM 互換であると判断された他のブロックチェーンでも実行できることを意味します。
コンポーネント層
状態層と計算層を組み合わせると、新しいタイプのデジタル価値 (別名プログラマブルマネー) の設計スペースを 1,000 倍に増やすことができます。その結果、開発者による多くの実験が見られるようになりました。これらの実装の一部には、サブエコノミー全体が特定のコンポーネントの上に構築されると想像できるほどの潜在力があります (以下の例)。 Coinbase の私の同僚である Jacob Horne は、この現象 (プロトコル層とともに) を暗号経済の原始的なものとして説明し、そのうちの 1 つである暗号商品について詳細な研究を行っています。
コンポーネントはコンピューティング層上に構築され、標準化されたスマート コントラクト テンプレートを再利用します。 OpenZeppelin は、そのようなテンプレートにアクセスするための完璧なリソースです。コンポーネントの作成者は、状態レイヤーで新しいスマート コントラクトを公開する必要があります。
これらのコンポーネントの例は次のとおりです。
- ネイティブ通貨: パブリック ブロックチェーンの必須かつ核となる部分。参加者にブロックチェーン料金を支払い、その見返りとして希望するサービスを通常はトランザクションの形で受け取る権利を与える。例: ビットコイン、イーサリアム
- 暗号資産: 基本機能のセットと関連するメタデータを備えた代替資産。誰でも独自の通貨を作成できるため、ICO ブームの火付け役となりました。通貨に加えて、株式、債券、権利など、他の多くの種類の資産をデジタル化できます。最も一般的な規格は ERC-20 です。
- 暗号商品: 基本的な機能セットと、それらに関連付けられたより豊富なメタデータ セットを備えた代替不可能な資産。代替不可能なトークン (NFT) または暗号収集品とも呼ばれます。まずは CryptoPunks を探索し、人気の CryptoKitties を作成します。収集品、ゲームアセット、アクセス権、アートワークなどのユニークなアイテムをデジタル化できるようにします。最も一般的な規格は ERC-721 です。
- ID: ID 情報の自己主権コンテナ。それ自体では、認識した内容に関する貴重な情報を提供することはほとんどありません。ただし、政府やその他の信頼できる関係者 (Google、Coinbase など) など、さまざまなソースから取得できるクレームをコンテナに関連付けることができます。主要な提案は、ERC-725/ERC-735 および uPort のいくつかのプロトコル提案です。イーサリアム ネーミング サービス (ENS) も、別のタイプの識別子として非常に関連性があります。
- ステーブルコイン: 米ドルの価値などのソースに固定された、安定した価値を持つ暗号資産。さまざまなタイプの理論的および実際的な解決策が含まれる非常に複雑な問題。例としては、TrueUSD、Dai、Reserve などがあります。
プロトコル層
コンポーネントが状態レイヤーに作成されたら、アクティブにする必要があります。特定の機能はこれらのコンポーネントのライフサイクルにとって非常に重要かつ共通しているため、標準化されつつあります。これらの機能は同じ言語 (つまりプロトコル層) を話す必要があるためだけでなく、ネットワーク効果により効率が向上するためでもあります。これらのプロトコルは基本的に、物理世界で行うのと同じように、関連コンポーネントの健全な市場を形成することができますが、桁違いに安価で効率的です。
さまざまなプロトコルが注目され始めています。これらは正規のスマート コントラクトの形式をとり、プロトコルを開発しているチームによってデプロイされ、コンポーネントに関連する機能を適用したいすべてのアプリケーションによって呼び出されます。
- トランザクション: コンポーネントに価値がある場合、それは取引可能である必要があります。トランザクション プロトコルにより、トラストレスな方法でのウォレット間の資産トランザクションが可能になります。これらの「中継器」を、スマート コントラクトで資産をホストするほとんどの「分散型取引所」と区別することが重要です。トランザクション プロトコルを通じて促進されるトランザクションでは、トランザクション資産が保管されることはありません。主要なプロジェクトには、0x や Kyber Network などがあります。 0x プロトコルでサポートされる 1 日あたりのトランザクション量の詳細については、ここにアクセスしてください。
- ローン: ローンは、他の方法ではゼロになる可能性のある投資収益率を促進するため、あらゆる資産の効率を高めます。標準的な融資契約により、米国のある人がジンバブエにいる別の人に、スマートフォンからスマートフォンへお金を貸すことができます。現在、Dharma と ETHLend がこの分野の 2 つの主要プロジェクトです。
- デリバティブ: デリバティブ市場は世界最大で、全世界で 1 兆 2,000 億ドルと推定されています。派生物をプロトコルとして構築すると、ステート層にネイティブなコンポーネントのトラストレス マーケットプレイスが可能になります。 dy/dx と Market Protocol は、この分野の 2 つのプロジェクトです。
スケーラビリティ/トランスポート層
ブロックチェーンはスケーラビリティの問題で有名です。ビットコイン ブロックチェーンのトランザクション容量は 1 秒あたり 7 トランザクション、イーサリアムのトランザクション容量は 1 秒あたり 15 トランザクションです。毎秒数千のトランザクションを促進するためにブロックチェーン自体が譲歩すべきかどうかについては多くの議論がありますが、堅牢なトポロジをサポートするには状態転送用の別のレイヤー (レイヤー 2 スケーラビリティとも呼ばれる) が必要であるということで一般的に同意されています。基礎となるブロックチェーンのコンピューティング層と互換性がある必要があります。
これを行う方法についてはさまざまな提案があります。ここではいくつかの例を示します。
支払いチャネル: 指定された国の通貨の送金のみを許可します。これは、状態層に添付されたトランザクションの検証可能な署名を通じて行われます。紛争を促進するには資金を預ける必要があります。例: Bitcoin の Lighting Network、Ethereum の Raiden、Ethereum の SpankChain の Vynos 実装。
状態チャネル: あらゆる状態の転送を許可します。これは、状態層のトランザクションに添付された検証可能な署名を通じて行われます。紛争を促進するには資金を預ける必要があります。例: EVM の Counterfactuals、EVM の Celer Network、EVM の Arcadeum、EVM の FunFair の Fate Channel、EVM の Connext。
サイドチェーン: あらゆる状態の転送を許可します。メインチェーンと互換性のある他のブロックチェーンによって行われます。サイドチェーンは、メインチェーン上のコンピューティング層と通信できる必要があります。紛争を促進するために資金をロックすることも求められます。サイドチェーンは、集中管理またはプライベート管理のインフラストラクチャにすることができます。例: EVM 用の PoA ネットワーク、EVM 用の Loom ネットワーク、EVM 用のプラズマ フレームワーク。ユーザーが自分の資産をコンピューティング層に安全に引き出すことができるという保証を提供するために、追加の要件が Plasma に組み込まれていることに注意してください (さまざまな実装があります)。このように、その価値提案は、国家および決済チャネルにより似ています。
5 番目のレイヤーに到達したので、このモジュール式スタックにより、開発者がどのブロックチェーンに構築するかなど、独立した下位レベルの設計選択を行うことができることがわかります。例として、近い将来の仮想のステーブルコイン スマート コントラクトを考えてみましょう。eWASM にコンパイルされ、イーサリアム上で実行され、反事実状態チャネルと互換性があります (つまり、状態チャネルで送信できます)。前述のステーブルコインの同じコードは、EOS ブロックチェーンと Dfinity ブロックチェーンの両方が WASM を実行するため、理論的には両方と互換性があります。これらのブロックチェーン上で実行されている同様の状態チャネル上で転送することもできます。
ユーザーコントロール層
この層までは、コマンド ライン インターフェイスを介してコンピューティング層と直接対話しない限り、通常のユーザーが作成された機能を使用することはほとんど不可能です。この層の主な機能は、ユーザーの秘密鍵を管理し、状態層でトランザクションに署名できるようにすることです。状態層のトランザクションはユーザー アカウントの状態を変更するため、ユーザーが Web 3 アプリケーションと対話する方法の中心となります。
ウォレットには次の 2 種類があります。
- カストディ ウォレット: Coinbase またはその他の暗号通貨取引所によって普及し、状態レイヤー上の限られた独自の残高セットを制御することで、ユーザーに代わって資金を管理します。これらは、ユーザーの資金を集約されたアカウントにプールし、状態レイヤーの外側で個々のユーザーの状態を管理することができます。このような操作は、金銭的価値だけを考慮すれば実現可能で経済的かもしれませんが、Web 3 アプリケーションによってもたらされる状態の量が増加するにつれて、より複雑になります。
ユーザーごとに専用のブロックチェーンウォレットを管理し、分散型アプリケーションの使用を可能にする、新しいタイプのマネージドウォレットの例もあります。これらは柔軟性のさらなる向上を約束しますが、まだ大規模に実証されていません。
- ユーザー制御ウォレット: Web 3 によって可能になる任意の複雑な操作をすべて使用する、より柔軟で簡単な方法を提供します。ウォレットをユーザー管理のウォレットにするのは、ユーザーの秘密キーと各トランザクションのローカル署名がローカルに保管されることです。これは、ウォレット ソフトウェアが、第三者がユーザーに代わってトランザクションを送信できるような方法でユーザーの秘密キーを複製しないことを意味します。
これはすべて基礎となるエンドユーザーのタッチポイントであるため、利用可能なすべての機能は、この層を介してアクセスされるアプリケーションに公開される必要があります。これは通常、web3.js などのフロントエンド ライブラリを使用して行われます。この記事のパート 3 では、すべてがどのように組み合わされるかを詳しく説明します。
アプリケーション層
従来の Web と同様に、Web 3 上のほとんどのアクティビティは、その下のすべてのレイヤー上に構築されたサードパーティ アプリケーションを通じて行われます。たとえば、すべての機能が cryptokitties.co、kittyrace.com、cryptogoods.com などの CryptoKitties を使用するアプリケーションを通じて提供されるため、ユーザーは CryptoKitties (つまり、cryptogoods) の価値を認識します。 Web 3 上に構築されたアプリケーションには、従来の Web アプリケーションとは異なる特性と要件があるため、分散型アプリケーションまたは DApp と呼ばれることがよくあります。 Matt Condon 氏が明確に述べているように、DApps を何百万ものユーザーが使用するには、既存のアプリと区別がつかないようにする必要があります。
しかし、分散化によって可能になる新しい機能こそが、DApps を非常に強力にするものであり、スタックが成熟するにつれて、おそらく今日の Web を超えて使用されるようになる理由です。私たちは、世界中の開発者がさまざまなカテゴリーの最先端のユースケースを作成し、ユーザーが価値を感じるところに資金を投じてそれに応えるのを見てきました。
-資金調達: 200 億ドルの調達に近づいており、723,000 のユニークなアカウントが参加し、8,000 社以上の企業が投資を受けています。このスペースでは不正行為が見られていますが、この記事の日付時点では、参加しているアカウントの数に基づくと、最も人気のあるアプリ カテゴリです。さらに、規制された ICO を促進する多くの新しい資金調達プラットフォームに見られるように、その魅力は続いています。
- 取引所: 従来の暗号通貨取引所は（保管ウォレットとして機能することにより）ユーザーとステート層の間の仲介者として機能しますが、Web 3 対応アプリケーションとして構築された取引所では、ユーザーはサードパーティのウォレットに入金するのではなく、自分の資金の管理を維持できます。住所。さらに、トランザクション エクスペリエンスには UX 上の潜在的な利点があります。技術的な課題のいくつかを克服するためにさまざまなプロジェクトが取り組んでいますが、この分野での使用量は増加しています。
最初のレベルのタイトル
パート 3: 開発者は Web 3.0 をどのように構築するか?
Web 2.0 および Web 3.0 アーキテクチャ
今日の Web 2.0 アーキテクチャの単純なバージョンは、クライアント ソフトウェア (通常はブラウザまたはスタンドアロン アプリケーション) と、コンテンツとロジックを提供する一連のサーバーで構成され、すべて同じエンティティ (ゲーム会社と呼びます) によって制御されます。このモデルでは、Game Co. は、サーバーのコンテンツとロジックに誰がアクセスできるか、またどのユーザーがそのコンテンツをどのくらいの期間保存するかの実績を持っているかを独占的に制御します。テクノロジーの歴史のページには、インターネット企業がルールを変更したり、自分たちが生み出した価値を維持する権利のないユーザーへのサービスを中止したりした例が数多くあります。
Web 3.0 アーキテクチャは、共通ステート層によってサポートされる機能を活用します。これは、次の 2 つのことを許可することで実現されます。
- アプリケーションがコンテンツとロジックの一部またはすべてをパブリック ブロックチェーン上に配置できるようにします。標準の Web 2.0 とは異なり、このコンテンツとロジックは公開され、誰でもアクセスできます。
- ユーザーがこのコンテンツとロジックを直接制御できるようにします。 Web 2.0 とは異なり、ユーザーはブロックチェーン上のコンテンツを操作するためにアカウントや特権 API キーを必ずしも必要としません。
Web 3 アプリケーションは、次の 2 つの主要なインフラストラクチャ部分を利用してこれを実現します。
ウォレット: Web 3 スタックのユーザー コントロール層であることに加えて、Coinbase Wallet などの最新のウォレットは、シームレスなユーザー エクスペリエンスを実現するためにメイン クライアント フロント エンドとも対話します。これは、アプリケーションが標準ライブラリを使用してウォレット自体にリクエストを送信できるようにすることで実現されており、その中で最も人気があるのは web3.js です。 web3.js 呼び出しの例としては、ウォレットがアプリケーション アドレスに指定された金額を送金できるかどうかをユーザーに確認する支払いリクエストが考えられます。ユーザーが受け入れると、2 つのことが起こります。1) ウォレットは応答することでアプリのフロントエンドに通知し、「支払いが送信されました」画面を表示できるようにします。2) ウォレットはブロックチェーン サーバーに対して RPC 呼び出しを行い、承認されたトランザクションをブロックチェーン サーバーに送信します。ゾーンブロックチェーン。ここで 2 番目のインフラストラクチャ部分が登場します。
ブロックブロックチェーンノードプロバイダー (例:Infuraブロックブロックチェーンノードも同様のことを行います。ウォレットがブロックチェーンにトランザクションを送信したり、ブロックチェーンから状態情報をクエリしたりする場合、ノードプロバイダーを呼び出します。アプリケーションのアプリケーション サーバーは、同様の RPC 呼び出しを実行して、アプリケーションのロジックを最新の状態に保つことにより、ノード プロバイダー自体と対話することもできます。
ツールとフレームワーク
どのツールやフレームワークを使用するかを理解し、それらを上手に使用することは、開発者にとって重要な部分です。 Web 3 分野ではまだ初期段階にありますが、開発者が MVP 段階に到達し、より迅速に反復できるようにするツールが利用可能になり始めています。これはイーサリアムで最も顕著で、コミュニティの多くの人の努力により開発者が集まり始めました。
デザインの選択
- 分散化: これは新しい重要なオプションです。ほとんどの初期開発者の目標は、できる限り分散化してすべてをブロックチェーン上に置くことです。ただし、今日のブロックチェーンは遅くて高価であるため、これを大規模に行うことは不可能です。 CryptoKittiesは、一部の部分を集中管理しようとした最初のDAppかもしれません。たとえば、彼らの繁殖ロジックは公開されていません。これについては批判もあるが、それでもユーザーがこのロジックで飼育された猫に巨額のお金を費やすことは止められなかった。 Gods Unchained は別の例で、ゲーム自体は標準のクラウド インフラストラクチャでホストされますが、アセットの所有権は状態レイヤーで追跡されます。
多くの DApps は分散化に対してさまざまなアプローチをとりますが、この選択に取り組むための第一原理アプローチは、「実行可能な最小限の公共国家」アプローチです。ユーザーがアセットを所有できるゲームを構築している場合、所有権はブロックチェーン上にある必要があります。予測市場を構築している場合、市場のレポートと支払いはブロックチェーン上にある必要があります。結局のところ、ユーザーは、アプリがサポートする主要なアクティビティの実際の所有権を取得できれば、アプリに価値があると感じるでしょう。
- Web アプリとネイティブ アプリ: これは何十年も前の選択ですが、Web 3 アプリでは新しい形になりつつあります。現在のほとんどの DApps は 2 つの単純な理由から Web アプリです。a) ユーザーが毎回新しいアプリをダウンロードする必要がないこと、b) ユーザーは新しいウォレットを毎回作成することなくアプリを使用できることです。いくつかの既存のネイティブ DApp はすべてユーザーに新しいウォレットを作成させることになりますが、これは理想的なユーザー エクスペリエンスではありません。ユーザーは何百ものウォレットのキーを維持しないため、これが実現可能な将来ではないことは簡単にわかります。近い将来、ネイティブ アプリがこの UX の課題を克服するためのよりシームレスな方法が登場するでしょうが、現時点では Web アプリの方が簡単なオンボーディング エクスペリエンスを実現します。
- デスクトップ vs モバイル: この選択の Web 3 バージョンは、2 つのどちらかを選択することではなく、ユーザーが最終的に両方で DApp をどのように使用するかについてです。デスクトップでは、MetaMask などの Chrome 拡張機能が、ほとんどのユーザーが DApps を操作する方法となっています。ユーザーは新しい拡張機能をダウンロードする必要がありますが、ユーザーは使い慣れたブラウザ インターフェイスを引き続き使用できます。
ただし、モバイル デバイスでは、少なくとも iOS では拡張機能は使用できません。これが、Coinbase Wallet などのウォレット アプリケーションがアプリケーション内にブラウザを配置する理由です。ブラウザー ビューに入ると、DApp エクスペリエンスはデスクトップと同じになります。モバイルデバイス向けに開発する際には注意すべき技術的なニュアンスもいくつかあり、Coinbase Wallet のエンジニアリングディレクターである Pete Kim がここでそれらの詳細を説明しています。
これまでのところ解決策が見つかっていないその他の課題:
- ガスの料金を誰が支払うか: 現在、イーサリアム上に構築されたすべての DApp は、ユーザーにイーサリアム ブロックチェーンのガスと呼ばれるトランザクション コストを支払わせます。何百万もの暗号化されていないネイティブユーザーが Web 3 アプリケーションを使用することになる場合、それは長期的には実現不可能です。理論的な解決策は数多くあり、ガス中継器など実用に近いものもありますが、まだ実用化されていません。
- アプリケーション固有のアカウントかどうか: Web 3 の興味深いアプリケーションの 1 つはユニバーサル ID です。現在、機能的な ID ソリューションはそれほど多くないため、一部の DApp では、特定の ID をアプリ上のアクティビティに関連付けるためにユーザーにアカウントの作成を要求しています。これは Web 2.0 のやり方とあまり変わりません。機能的な分散型 ID ソリューションを手に入れたら、DApps はそれをどのように扱い、提示すべきでしょうか?決定的な答えはありませんが、ERC-725 および 735 で構築された Origin デモなど、それを示唆する人もいます。
