非技術者からの分散システムに関するよくある質問は、「ブロックチェーン上の TPS は何個ですか?」です。 しかし、答えとして与えられた数字は、質問者が聞きたいこととほとんど共通点がありません。 実際、彼は「あなたのブロックチェーンは私のビジネス要件に適合しますか?」と尋ねたかったのですが、これらの要件は XNUMX つの数字ではなく、多くの条件です。ネットワークのフォールト トレランス、ファイナリティ要件、サイズ、トランザクションの性質、その他多くのパラメーターが含まれます。 したがって、「tps は何秒か」という質問に対する答えは簡単ではなく、完全に答えられることはほとんどありません。 非常に複雑な計算を実行する数十または数百のノードを備えた分散システムは、ネットワークの状態、ブロックチェーンの内容、技術的障害、経済的問題、ネットワークへの攻撃、その他多くの理由に関連して、膨大な数の異なる状態になる可能性があります。 。 パフォーマンスの問題が発生する可能性がある段階は従来のサービスとは異なり、ブロックチェーン ネットワーク サーバーはデータベース、Web サーバー、トレント クライアントの機能を組み合わせたネットワーク サービスであるため、すべてのサブシステムの負荷プロファイルの点で非常に複雑になります。 : プロセッサ、メモリ、ネットワーク、ストレージ

たまたま、分散型ネットワークとブロックチェーンは、集中型ソフトウェア開発者にとって非常に特殊で珍しいソフトウェアです。 したがって、分散型ネットワークのパフォーマンスと持続可能性の重要な側面、それらを測定しボトルネックを見つけるアプローチについて強調したいと思います。 ブロックチェーン ユーザーへのサービス提供速度を制限するさまざまなパフォーマンスの問題を検討し、このタイプのソフトウェアの特徴に注目します。

ブロックチェーンクライアントによるサービスリクエストの段階

多かれ少なかれ複雑なサービスの品質について正直に語るには、平均値だけでなく、最大/最小、中央値、パーセンタイルも考慮する必要があります。 理論的には、一部のブロックチェーンでは 1000 tps について話すことができますが、900 件のトランザクションが非常に高速に完了し、100 件が数秒間「停止」した場合、すべてのトランザクションにわたって収集された平均時間は、クライアントにとって完全に公平な指標とは言えません。数秒以内に取引を完了できませんでした。 コンセンサスラウンドの逃しやネットワークの分割によって一時的な「穴」が生じると、テストベンチで優れたパフォーマンスを示したサービスが大幅に台無しになる可能性があります。

このようなボトルネックを特定するには、実際のブロックチェーンがユーザーへのサービスを提供することが困難になる可能性がある段階をよく理解する必要があります。 トランザクションの配信と処理、およびブロックチェーンの新しい状態の取得のサイクルを説明しましょう。クライアントはそこから、トランザクションが処理され、説明されたことを確認できます。

1. トランザクションはクライアント上で形成されます
2. トランザクションはクライアント上で署名されます
3. クライアントはノードの XNUMX つを選択し、そこにトランザクションを送信します。
4. クライアントはノードの状態データベースの更新をサブスクライブし、トランザクションの結果が表示されるのを待ちます。
5. ノードはトランザクションを p2p ネットワーク上に分散します。
6. 複数または XNUMX つの BP (ブロックプロデューサー) が蓄積されたトランザクションを処理し、状態データベースを更新します
7. BP は必要な数のトランザクションを処理した後、新しいブロックを形成します
8. BP は p2p ネットワーク経由で新しいブロックを配布します
9. 新しいブロックはクライアントがアクセスしているノードに配信されます
10. ノードが状態データベースを更新する
11. ノードはクライアントに関する更新を確認し、トランザクション通知を送信します。

ここで、これらの段階を詳しく見て、各段階で潜在的なパフォーマンスの問題について説明します。 集中型システムとは異なり、ネットワーク クライアントでのコードの実行も考慮します。 多くの場合、TPS を測定する場合、トランザクション処理時間はクライアントからではなくノードから収集されます。これは完全に公平ではありません。 クライアントは、ノードが自分のトランザクションをどれだけ速く処理したかは気にしません; クライアントにとって最も重要なことは、ブロックチェーンに含まれるこのトランザクションに関する信頼できる情報が利用可能になる瞬間です。 このメトリクスは、本質的にはトランザクションの実行時間です。 これは、異なるクライアントは、同じトランザクションを送信したとしても、チャネル、負荷、ノードの近さなどに応じて、まったく異なる時間を受信する可能性があることを意味します。 したがって、これは最適化する必要があるパラメータであるため、クライアント上でこの時間を測定することが絶対に必要です。

クライアント側でのトランザクションの準備

最初の XNUMX つのポイントから始めましょう。トランザクションはクライアントによって形成され、署名されます。 奇妙なことに、これはクライアントの観点からはブロックチェーンのパフォーマンスのボトルネックになる可能性もあります。 これは、すべての計算と操作をデータで引き継ぐ集中型サービスでは異例であり、クライアントは大量のデータまたは計算を要求できる短いリクエストを準備するだけで、既製の結果が得られます。 ブロックチェーンでは、クライアント コードはますます強力になり、ブロックチェーン コアはますます軽量になり、通常、大規模なコンピューティング タスクはクライアント ソフトウェアに転送されます。 ブロックチェーンでは、XNUMX つのトランザクションを非常に長い間準備できるクライアントが存在します (ここで話しているのは、クライアント側でのさまざまなマークル証明、簡潔な証明、しきい値署名、その他の複雑な操作についてです)。 簡単なオンチェーン検証とクライアントでのトランザクションの綿密な準備の良い例は、マークル ツリーに基づくリストのメンバーシップの証明です (ここ)。 記事.

また、クライアント コードは単にトランザクションをブロックチェーンに送信するのではなく、最初にブロックチェーンの状態をクエリすることを忘れないでください。このアクティビティはネットワークとブロックチェーン ノードの輻輳に影響を与える可能性があります。 したがって、測定を行うときは、クライアント コードの動作を可能な限り完全にエミュレートすることが合理的です。 ブロックチェーン内に、資産を転送するための最も単純なトランザクションに通常のデジタル署名を付ける通常のライト クライアントが存在するとしても、クライアント上では年々さらに大規模な計算が行われ、暗号アルゴリズムは強化されており、この部分の処理は将来的に大きなボトルネックになる可能性があります。 したがって、3.5 秒続くトランザクションで、トランザクションの準備と署名に 2.5 秒が費やされ、ネットワークへの送信と応答の待機に 1.0 秒が費やされるという状況を見逃さないように注意してください。 このボトルネックのリスクを評価するには、ブロックチェーン ノードだけでなく、クライアント マシンからもメトリクスを収集する必要があります。

トランザクションの送信とそのステータスの監視

次のステップでは、選択したブロックチェーン ノードにトランザクションを送信し、トランザクション プールへの受け入れステータスを受け取ります。 この段階は通常のデータベース アクセスに似ており、ノードはプール内のトランザクションを記録し、p2p ネットワークを通じてトランザクションに関する情報の配信を開始する必要があります。 ここでのパフォーマンスを評価するアプローチは、従来の Web API マイクロサービスのパフォーマンスを評価することに似ており、ブロックチェーン内のトランザクション自体は更新され、そのステータスをアクティブに変更できます。 一般に、一部のブロックチェーン上のトランザクション情報の更新は、チェーン フォーク間の切り替え時や BP がブロックにトランザクションを含める意図を発表するときなど、複数回発生する可能性があります。 このプールのサイズとその中のトランザクション数の制限は、ブロックチェーンのパフォーマンスに影響を与える可能性があります。 トランザクション プールが可能な最大サイズまで満たされている場合、または RAM に収まらない場合、ネットワーク パフォーマンスが急激に低下する可能性があります。 ブロックチェーンには、大量のジャンク メッセージから保護する一元的な手段がありません。また、ブロックチェーンが大量のトランザクションと低料金をサポートしている場合、トランザクション プールがオーバーフローする可能性があり、これがもう XNUMX つの潜在的なパフォーマンスのボトルネックになります。

ブロックチェーンでは、クライアントは任意のブロックチェーン ノードにトランザクションを送信します。通常、トランザクションのハッシュは送信前にクライアントに知られているため、接続を確立し、送信後はブロックチェーンが変更されるのを待つだけで済みます。その状態により、トランザクションが可能になります。 「tps」を測定すると、ブロックチェーン ノードへの接続方法が異なるとまったく異なる結果が得られることに注意してください。 これは、通常の HTTP RPC または「サブスクライブ」パターンの実装を可能にする WebSocket です。 XNUMX 番目のケースでは、クライアントはより早く通知を受信し、ノードはトランザクション ステータスに関する応答に費やすリソース (主にメモリとトラフィック) が少なくなります。 したがって、「tps」を測定するときは、クライアントがノードに接続する方法を考慮する必要があります。 したがって、このボトルネックのリスクを評価するには、ベンチマーク ブロックチェーンが、実際のネットワークに対応する割合で WebSocket と HTTP RPC リクエストの両方でクライアントをエミュレートでき、トランザクションの性質とそのサイズを変更できなければなりません。

このボトルネックのリスクを評価するには、ブロックチェーン ノードだけでなく、クライアント マシンからもメトリクスを収集する必要があります。

p2pネットワークを介したトランザクションとブロックの送信

ブロックチェーンでは、参加者間でトランザクションとブロックを転送するためにピアツーピア (p2p) ネットワーキングが使用されます。 トランザクションは、ノードの 2 つから始まり、ピア ブロック プロデューサーに到達するまでネットワーク全体に広がります。ピア ブロック プロデューサーはトランザクションをブロックにパックし、同じ p2p を使用して新しいブロックをすべてのネットワーク ノードに配布します。 最新の pXNUMXp ネットワークの基礎は、Kademlia プロトコルのさまざまな修正です。 ここで このプロトコルの適切な要約、および ここで - BitTorrent ネットワークのさまざまな測定結果を記載した記事。このタイプのネットワークは、集中型サービスの厳密に構成されたネットワークよりも複雑で予測しにくいことがわかります。 また、 ここで イーサリアムノードのさまざまな興味深いメトリクスの測定に関する記事。

つまり、そのようなネットワーク内の各ピアは、コンテンツによってアドレス指定される情報のブロックを要求する他のピアの独自の動的リストを維持します。 ピアがリクエストを受信すると、必要な情報を提供するか、リスト内の次の疑似ランダム ピアにリクエストを渡し、応答を受信すると、それをリクエスタに渡し、しばらくキャッシュします。次回はもっと早く情報ブロックを。 このように、人気のある情報は多数のピアの多数のキャッシュに残り、人気のない情報は徐々に置き換えられます。 ピアは、誰が誰にどれだけの情報を転送したかを記録しており、ネットワークは、評価を上げてより高いレベルのサービスを提供することで、アクティブなディストリビュータを刺激し、非アクティブな参加者をピア リストから自動的に排除します。

したがって、ブロックプロデューサーがトランザクションを確認してブロックに含めることができるように、トランザクションをネットワーク全体に分散する必要があります。 ノードは新しいトランザクションを全員に積極的に「配布」し、ネットワークをリッスンして、待機中のクライアントに通知するために、必要なトランザクションが出現するブロックがインデックス内に現れるのを待ちます。 p2p ネットワーク内でネットワークが新しいトランザクションとブロックに関する情報を相互に転送するのにかかる時間は、非常に多くの要因に依存します。たとえば、近くで動作する正直なノードの数 (ネットワークの観点から)、「ウォーム ノードの数」などです。これらのノードのキャッシュ、ブロックのサイズ、トランザクション、変更の性質、ネットワークの地理、ノードの数、およびその他の多くの要因。 このようなネットワークにおけるパフォーマンス指標の複雑な測定は複雑な問題であり、クライアントとピア (ブロックチェーン ノード) の両方でリクエストの処理時間を同時に評価する必要があります。 P2P メカニズムのいずれかの問題、不正なデータの削除とキャッシュ、アクティブなピアのリストの非効果的な管理、およびその他の多くの要因により、ネットワーク全体の効率に影響を与える遅延が発生する可能性があり、このボトルネックは分析が最も困難です。 、テストと結果の解釈。

ブロックチェーン処理と状態データベースの更新

ブロックチェーンの最も重要な部分は、コンセンサス アルゴリズム、ネットワークから受信した新しいブロックへのその適用、および結果を状態データベースに記録するトランザクションの処理です。 新しいブロックをチェーンに追加してからメイン チェーンを選択すると、できるだけ早く機能するはずです。 ただし、現実の生活では、「すべき」は「機能する」という意味ではなく、たとえば、2 つの長い競合チェーンが常に相互に切り替わり、各スイッチでプール内の何千ものトランザクションのメタデータが変更される状況を想像することができます。 、状態データベースを常にロールバックします。 ボトルネックを定義するという点では、この段階は pXNUMXp ネットワーク層よりも単純です。 トランザクションの実行とコンセンサスアルゴリズムは厳密に決定的であり、ここで何かを測定する方が簡単です。
重要なことは、このステージのパフォーマンスのランダムな低下とネットワークの問題を混同しないことです。ノードはメインチェーンに関するブロックや情報を配信するのが遅く、外部クライアントにとってはこれが遅いネットワークのように見えるかもしれませんが、問題は次の点にあります。全く違う場所。

この段階でパフォーマンスを最適化するには、ノード自体からメトリクスを収集して監視し、ノード上で処理されたブロックの数、サイズ、トランザクションの数など、状態データベースの更新に関連するメトリクスをメトリクスに含めることが役立ちます。チェーンフォーク間のスイッチの数、無効なブロックの数、仮想マシンの動作時間、データコミット時間など。 これにより、ネットワークの問題がチェーン処理アルゴリズムのエラーと混同されるのを防ぐことができます。

トランザクションを処理する仮想マシンは、ブロックチェーンの動作を最適化できる有用な情報源となり得ます。 メモリ割り当ての数、読み取り/書き込み命令の数、およびコントラクト コード実行の効率に関連するその他の指標は、開発者に多くの有益な情報を提供します。 同時に、スマート コントラクトはプログラムであるため、理論的には CPU、メモリ、ネットワーク、ストレージなどのリソースを消費する可能性があるため、トランザクション処理はかなり不確実な段階であり、さらにバージョン間を移動すると大きく変化します。契約コードを変更する場合。 したがって、ブロックチェーンのパフォーマンスを効果的に最適化するには、トランザクション処理に関連するメトリクスも必要です。

ブロックチェーンへのトランザクションの包含に関する通知をクライアントが受信する

これは、ブロックチェーン クライアントがサービスを受け取る最終段階です。他の段階と比較して大きなオーバーヘッド コストはありませんが、クライアントがノードから大量の応答を受け取る可能性 (スマート コントラクトなど) を考慮する価値はあります。データの配列を返します)。 いずれにしても、「ブロックチェーンには TPS がいくつありますか?」という質問をした人にとって、この点が最も重要です。 このとき、サービスを受けた時間が記録されます。

この場所では、クライアントがブロックチェーンからの応答を待つために費やさなければならなかった全時間が常に送信されます。ユーザーがアプリケーションでの確認を待つのはこの時間であり、その最適化こそが重要です。開発者の主なタスク。

まとめ

その結果、ブロックチェーン上で実行される操作の種類を説明し、それらをいくつかのカテゴリに分類することができます。

1. 暗号変換、証明構築
2. ピアツーピア ネットワーキング、トランザクションおよびブロック レプリケーション
3. トランザクション処理、スマートコントラクトの実行
4. ブロックチェーンの変更を状態データベースに適用し、トランザクションとブロックのデータを更新する
5. 状態データベース、ブロックチェーン ノード API、サブスクリプション サービスへの読み取り専用リクエスト

一般に、最新のブロックチェーン ノードの技術要件は非常に深刻です。暗号化用の高速 CPU、状態データベースを保存して迅速にアクセスするための大量の RAM、同時に開いている多数の接続を使用したネットワーク インタラクション、および大容量のストレージです。 このような高い要件と豊富な種類の操作により、必然的にノードに十分なリソースが不足する可能性があり、上で説明したいずれかの段階がネットワーク全体のパフォーマンスの別のボトルネックになる可能性があります。

ブロックチェーンのパフォーマンスを設計および評価するときは、これらすべての点を考慮する必要があります。 これを行うには、クライアントとネットワーク ノードからメトリクスを同時に収集して分析し、それらの間の相関関係を調べ、クライアントにサービスを提供するのにかかる時間を見積もり、すべての主要リソース (CPU/メモリ/ネットワーク/ストレージ) を考慮する必要があります。 、それらがどのように使用され、相互に影響を与えるかを理解します。 これらすべてにより、膨大な数の異なる構成と状態があるため、「TPS の数」という形式でさまざまなブロックチェーンの速度を比較することは、非常にありがたい作業になります。 大規模な集中型システム、数百台のサーバーのクラスターでは、これらの問題も複雑であり、多数の異なるメトリクスの収集も必要になりますが、ブロックチェーンでは、P2P ネットワーク、仮想マシンの処理契約、内部経済、学位の数などにより、自由度がはるかに大きいため、複数のサーバーでテストを行うことができますが、これは指標ではなく、現実とほとんど関係のない非常に近似的な値のみを示します。

したがって、ブロックチェーンコアで開発する場合、パフォーマンスを評価して「前回と比べて改善されましたか?」という質問に答えるために、数十のノードでブロックチェーンの起動を調整し、自動的にベンチマークを起動してメトリクスを収集する非常に複雑なソフトウェアを使用します。 ; この情報がなければ、複数の参加者で動作するプロトコルをデバッグすることは非常に困難です。

したがって、「あなたのブロックチェーンには TPS がいくつありますか?」という質問を受けたときは、対話者にお茶を出し、XNUMX 個のグラフを見て、ブロックチェーンのパフォーマンスの問題に関する XNUMX つのボックスすべてとその提案に耳を傾ける準備ができているかどうかを尋ねてください。それらを解決して...

出所： habr.com