これらはいくつかの興味深い結果です。MegaETHがトップになるのを見るのはいつもうれしいことです:) データをある文脈で考えると、RPC リクエストのエンドツーエンドのレイテンシーは、(1) オブザーバーとサーバーとの間での光速伝播レイテンシー、(2) サーバーが要求されたデータを取得して後処理するのにかかる時間、(3) オブザーバーが応答をダウンロードするのにかかる時間の 3 つのコンポーネントで構成されます。 おっしゃったように、テスト対象のRPC手法は、計算コストとデータサイズの両方の点で軽量です。これは、実験が主にテストされた(1)、つまりオブザーバーとRPCサーバー間の伝播レイテンシーを意味します。誤解しないでください – MegaETH の RPC は (2) と (3) でもかなり強力であり、それらにストレスを与える実験を見るのは興味深いでしょう。 では、伝播レイテンシーを微調整するにはどうすればよいでしょうか?実はノブがそれほど多くありません。まず、複数の地理的リージョンに RPC サーバーをデプロイし、リクエストを最も近いサーバーに自動的にルーティングできます。これは、ファーストフードチェーンがあちこちに店をオープンするようなもので、近くには常に支店があります。より正確には、サーバーを地理的に分散させることで、ユーザーとサーバー間の物理的な距離が短くなります。 次に、ネットワークトポロジーを最適化できます。送信者と受信者の同じペア間であっても、伝播遅延は実際に通過するネットワーク パスによって異なります。たとえば、米国東海岸とアジアの間では、データパケットが太平洋を経由するかヨーロッパを経由するかによって、レイテンシーが 2 倍に変わる可能性があります。場合によっては、同じ地理的ルートをたどる複数のネットワーク パスが存在することさえあります。他のものよりも混雑しているものもあり、遅延が高くなります。これは、A 地点から B 地点まで複数の高速道路を選択できるようなものです。あなたが観察したレイテンシーの利点は、おそらくルートを最適化したことによるものです。