イーサリアム上で Dapps を開発する際のボトルネックや障壁は何ですか?

区块链大本营

特邀专栏作者

2020-01-07 09:00 (UTC+8)

この記事は約3710文字で、全文を読むには約6分かかります

イーサリアム上でDappを開発する際に避けられない問題は何ですか?

AI要約

イーサリアム上でDappを開発する際に避けられない問題は何ですか?

編集者注: この記事は以下から引用しましたブロックチェーンキャンプ（ID：blockchain_camp）編集者注: この記事は以下から引用しました

ブロックチェーンキャンプ（ID：blockchain_camp）

分散型アプリケーション (Dapps) は、銀行業務 (Di-Fi) やゲームなどの分野で破壊的イノベーションとして広く認識されています。しかし、最も革新的なソリューションであっても、消費者の期待に応えられなければ認められません。

消費者が望んでいるのは、スムーズで成熟したユーザーエクスペリエンスであり、この目標を達成することは、イーサリアム Dapp 開発者にとってのもう 1 つの大きな課題です。

この記事では、典型的な Dapp アーキテクチャの概要を説明し、開発者が説得力のあるユーザーエクスペリエンスを作成することを困難にする、今日の標準イーサリアムスタックに固有の制限のいくつかを指摘します。次に、開発者がこれらの課題を克服するのに役立つ、イーサリアムインフラストラクチャの分野におけるいくつかのイノベーションを紹介します。

副題
クラシックなイーサリアム Dapp アーキテクチャ
一般に、イーサリアム上の Dapp は 3 つの主要な部分で構成されます。

Java で書かれたフロントエンドコード。

バックエンド - 通常は標準の Ethereum ブロックチェーンノード。フロントエンドとバックエンド間の通信には、通常、ノードが提供する JSON-RPC または GraphQL API が使用されます。

副題

自己構築されたバックエンドノード

イーサリアムの初期の頃、開発者は独自のイーサリアムノードを運用する必要がありました。 Dapp のリリース後は、実稼働グレードのノード (またはノードのクラスター) も運用する必要があります。ブロックチェーンノードの運用は大きな作業負荷であり、開発者の効率にも負担がかかります。

サービスとしてのノード (NaaS) プロバイダー

この前述の課題は、Infura などの企業や、Nodesmith、Quiknode、Blockdaemon、Ethernode、Chainstack、Alchemy、CloudFlare などの比較的新しい企業による「サービスとしてのノード」プラットフォームの台頭につながりました。

これらのプラットフォームは開発者にクラウドベースの Ethereum ノードを提供し、開発者がノードを操作する労力を節約します。開発および生産のためのソリューション。これらのプラットフォームは、ベースオペレーティングシステムやノードソフトウェア自体のパッチやアップデートなどのシステム管理を開発者にオフロードします。

副題

イーサリアムノードの固有の制限

たとえノードサービスが開発者をシステム管理者としてうまく置き換えることができたとしても、ノードサービスのアーキテクチャ、JSON-RPC、および GraphQL インターフェイスの固有の制限により、開発者がより優れたユーザーエクスペリエンスを達成してより優れた Dapp を構築することはできません。

主な制限事項は次のとおりです。

1. 観測された状態情報が矛盾している

より高い信頼性を提供しながら単一ノードの容量を超えて拡張するために、サービスプラットフォームとしてのノードは、ロードバランサーを介してノードプールへのアクセスを提供します。
これらのノードはすべてイーサリアムネットワーク内のピアノードとして自律的に動作するため、ある瞬間にネットワークを通じて情報が送信されるとき、異なるノードは異なるブロックの高さ、または異なるフォークに存在する可能性があります。これは、Dapp のリクエストの結果がロードバランサーの背後にある異なるノードによって提供されるため、Dapp がブロックチェーンの状態に関する一貫性のない情報を受け取る可能性があることを意味します。
ノードサービスプラットフォームは通常、ロードバランサー上のセッションスティッキ性を通じてこの問題を解決しようとします。ロードバランサーは常に、指定されたフロントエンドのクエリを同じバックエンドノードに送信しようとしますが、この方法はいくつかの状況で失敗します。

フロントエンドが単一のバックエンドノードで処理できる量を超えるリクエストを生成した場合。

ネットワークの問題によりフロントエンドがバックエンドから切断され、再接続する必要がある場合。

複数ノードのサービス提供プラットフォームは、さまざまなタイプのフロントエンドリクエスト (たとえば、トランザクションの送信やチェーン履歴の検索) を、そのクエリタイプに最適化されたさまざまなバックエンドノードのセットにルーティングします。

その場合、フロントエンドは複数のバックエンドノードにアクセスすることが多く、これらのバックエンドノードによって取得されるブロックチェーンの状態が互いに矛盾するため、Dapp がチェーンの再編成を処理することが困難になります。チェーン履歴を逆にたどると、Dapp は探していた親ブロックがもう存在しないことに突然気づくことがあります (別のフォーク上の別のノードと対話しているため)。次に、Dapp 開発者は、この問題を解決するコードを作成する必要があります (通常は、ノードが見つかるまで繰り返し再接続します)。これにより、Dapp に不必要な複雑さが追加され、ユーザーに表示される情報に齟齬が生じる可能性があります。
2. ブロックチェーン上の情報の検索は遅く、制限がある
標準のイーサリアムノードは正確な検索をサポートしたり、リアルタイムデータのフィルタリングされたリスニングを実行したりするのにあまり適していないため、Dapps はトランザクションやオンチェーン履歴を検索する機能が制限されています。これを効率的に行うには、数百万のブロックとトランザクションのインデックス作成を大量に行う必要がありますが、次のとおりです。
Ethereum ノードは、トランザクションの実行によって送信されたログ内の特定のフィールドのみにインデックスを付けます (インデックス付けされるフィールドは、コントラクトをデプロイするときに開発者によってマークされる必要があります)
Ethereum ノードは内部トランザクションのデータにインデックスを付けません (これは、スマートコントラクトが別のコントラクトのメソッドを呼び出すときに発生します)。
開発者はインデックスフィールドを追加することに消極的です。インデックスフィールドが追加されるたびに各トランザクションのコストが増加し、契約ユーザーに追加コストがかかるためです。
Ethereum ノードはブルームフィルターを使用して検索を実行するため、常にあいまい検索となり、誤検出一致が生成されます。完全一致にはフロントエンドによる追加処理が必要であり、フロントエンドはあいまい一致のブロックまたはトランザクション全体を取得し、それを再度取得して完全一致の結果を見つける必要があります。これには開発者の労力が必要なだけでなく、フロントエンドとノード間の帯域幅も無駄になります。

使用可能な検索構文は非常に限られており、基本的な選択と単純な置換のみがサポートされています。

検索結果の取得が遅い - 大きなブロックにわたる検索の実行には数時間かかる場合があります

JSON-RPC は帯域幅を大幅に浪費しており、実際に必要なデータよりもはるかに多くのデータを返します。 GraphQL インターフェイスは使用する帯域幅が少なくなりますが、ストリーミング機能は提供しません (フロントエンドは更新をポーリングする必要があります)。

3. 原子性の欠如

繰り返しになりますが、何が起こったのかを正確に把握するために繰り返しポーリングを行うフロントエンドコードには負担がかかりますが、Dapp のユーザーは、Dapp がこの余分な作業をすべて実行するため、遅延と更新の必要性を経験します。

4. ノードはパッシブです

Ethereum ノードはパッシブです。つまり、イベントやコールバックを生成したり、Webhook を呼び出したりすることはできません。すべての操作はフロントエンドによって開始される必要があり、フロントエンドは更新情報を得るためにノードをポーリングする必要があります。 Ethereum ノードのイベントストリーム読み取り機能は、ほとんどの Dapp のニーズを満たすには限定されており、GraphQL インターフェイスではなく、JSON-RPC インターフェイスでのみ利用可能です。

副題

Dappインフラストラクチャの再考

dfuse が提供するのは、ブロックチェーンノードによって提供されるネイティブ API よりも簡単に、より多くの作業を実行できる高レベルのブロックチェーン API 用のプラットフォームです。これは、Dapp 開発者が高速でスムーズなインターフェイスを通じて最新のブロックチェーンアプリケーションを構築するために必要な機能を提供することをベースに設計されており、それによって優れたユーザーエクスペリエンスを提供します。

このプラットフォームを通じて、上記のすべての制限が解決され、従来のイーサリアムノードの制限が打ち破られることが期待されています。

1. 一貫した見解

dfuse は統合されたハイパースケールデータプラットフォームであり、ロードバランサー上の複数の Ethereum ノードのコレクションではありません。 dfuse プラットフォームは、すべての接続およびすべての時点でのチェーン状態情報を提供します。ブロックを確認する (チェーンフォークと再構成の両方を検出する) か、ブロックをまったく報告しない (ブロックが急速に再構成され、遠くまで移動していない場合) します。

このようにして、Dapp はチェーン状態の一貫性のないビューに直面することがなくなり、ブロックチェーンの詳細の検証に忙しくする代わりに、その主な機能に集中できます。
2. 高速かつきめ細かい検索
これにより、Dapp 開発者はブロックチェーンの履歴記録を非常に細かい粒度、並外れた速度と効率で検索できるようになり、GraphQL、gRPC、Websocket インターフェイスを介したリアルタイムのフィルタリングとストリーミング読み取りも実現できます。
すべてのログフィールドに完全なインデックスを付けます。ログ内の各トランザクションによって出力されたすべてのデータは、高精度の検索に直接適用できます。
すべての内部トランザクション (送信者、受信者、値、メソッド、入力パラメータ) の完全なインデックス作成により、呼び出し全体のツリー構造でコントラクトの操作を完全に追跡します。
インデックス作成によってユーザーに追加のガスコストが発生することはありません - dfuse のインデックス作成は dfuse プラットフォームの統合機能であり、コントラクト実行のリソースコストが増加することはありません
検索では、あいまい検索ではなく、完全一致が検索されます。検索結果を再確認するために追加のフロントエンドコードを作成する必要がなく、不要なデータをバッチで取得するために帯域幅を無駄にする必要もありません。
Kibana や GitHub のクエリ言語に似た構造化クエリ言語を提供し、完全なブール演算と必要な特定のトランザクションまたはコマンドに直接ドリルダウンする機能を備えています。

優れたパフォーマンスを提供します - 指定された検索条件に従って 1 秒以内にチェーン履歴全体を検索し、完全に一致するセットを見つけます。

GraphQL の両方の長所を生かし、ストリーミング機能を犠牲にすることなく簡潔な応答を提供します - 当社の GraphQL インターフェイスは、完全なリアルタイムのフィルター検索を提供し、ユーザーに動的更新を効率的に提供します。

イーサリアムネットワーク上のトラフィックに関係なく、パフォーマンスは安定しています

3. アトミック操作

トランザクションが入る可能性のあるすべての複雑な状態を理解し、ファイナリティに達したときに通知するストリーム読み取りエンドポイントを提供します。トランザクションのステータスを追跡するために、ポーリングを繰り返したり、複数のデータソースをチェックしたりする代わりに、トランザクションをプッシュアップして接続を維持し、リアルタイムのステータス更新を受信することで、ユーザーにトランザクションのリアルタイムのステータスを提供することもできます。

優れたプラットフォームでは、イベントを開始できるアクティブなバックエンドが提供されます。たとえば、選択したラムダ関数 (またはクラウド関数) は、(前述の検索やその他の機能を介して) 指定した正確な基準に基づいて呼び出すことができます。これにより、Dapps は、複数の通信チャネルを通じてデータ更新をスムーズかつリアルタイムでユーザーにリリースできる非同期アーキテクチャを実装できるようになります。