這些結果很有趣。看到MegaETH名列前茅總是令人高興 : ) 為了給數據提供一些背景，RPC請求的端到端延遲由三個部分組成：（1）從觀察者到伺服器的光速傳播延遲，（2）伺服器抓取和後處理請求數據所需的時間，（3）觀察者下載響應所需的時間。正如你提到的，正在測試的RPC方法在計算成本和數據大小方面都是較輕的。這意味著實驗主要測試了（1），即觀察者與RPC伺服器之間的傳播延遲。不要誤解我的意思——MegaETH的RPC在（2）和（3）方面也相當強大，看到強調它們的實驗會很有趣！ 那麼，我們如何微調傳播延遲呢？實際上，調節的選項並不多。首先，我們可以在多個地理區域部署RPC伺服器，並自動將請求路由到最近的伺服器。這就像快餐連鎖店在各地開店——總有一家分店在附近！更準確地說，擁有地理分佈的伺服器可以減少用戶與伺服器之間的物理距離。 其次，我們可以優化網絡拓撲。即使是在同一對發送者和接收者之間，傳播延遲也會根據實際經過的網絡路徑而有所不同。例如，在美國東海岸和亞洲之間，延遲可能會因數據包是通過太平洋還是通過歐洲而變化2倍。有時，甚至會有多個網絡路徑遵循相同的地理路線；有些路徑比其他路徑更擁堵，從而導致更高的延遲。這就像從A點到B點有多條高速公路可供選擇。你觀察到的延遲優勢很可能來自於我們優化了路線.