這些結果很有趣。看到MegaETH名列前茅總是令人高興 : ) 為了給數據提供一些背景,RPC請求的端到端延遲由三個部分組成:(1)從觀察者到伺服器的光速傳播延遲,(2)伺服器抓取和後處理請求數據所需的時間,(3)觀察者下載響應所需的時間。正如你提到的,正在測試的RPC方法在計算成本和數據大小方面都是較輕的。這意味著實驗主要測試了(1),即觀察者與RPC伺服器之間的傳播延遲。不要誤解我的意思——MegaETH的RPC在(2)和(3)方面也相當強大,看到強調它們的實驗會很有趣! 那麼,我們如何微調傳播延遲呢?實際上,調節的選項並不多。首先,我們可以在多個地理區域部署RPC伺服器,並自動將請求路由到最近的伺服器。這就像快餐連鎖店在各地開店——總有一家分店在附近!更準確地說,擁有地理分佈的伺服器可以減少用戶與伺服器之間的物理距離。 其次,我們可以優化網絡拓撲。即使是在同一對發送者和接收者之間,傳播延遲也會根據實際經過的網絡路徑而有所不同。例如,在美國東海岸和亞洲之間,延遲可能會因數據包是通過太平洋還是通過歐洲而變化2倍。有時,甚至會有多個網絡路徑遵循相同的地理路線;有些路徑比其他路徑更擁堵,從而導致更高的延遲。這就像從A點到B點有多條高速公路可供選擇。你觀察到的延遲優勢很可能來自於我們優化了路線.
Avaworld
Avaworld8月15日 21:38
MegaETH 官方 RPC 與 Thirdweb RPC – 測試網延遲 我想直接從 MegaEth 獲取數據,而不需要運行任何基礎設施,並尋找最快的方法來做到這一點。 我使用了 "" 來運行一個簡單的基準測試,以查看 MegaETH 的官方 RPC 與第三方 RPC(Thirdweb)相比如何。目標是檢查哪個能更快地從不同地區的區塊瀏覽器中提取新數據。 測試使用了 `eth_blockNumber` 和 `eth_getBalance` RPC 調用在 MegaETH 測試網上進行。它覆蓋了 27 個 AWS 區域,跨越 6 大洲,依次發送請求,間隔一秒。它跟蹤了平均延遲、失敗、429 錯誤、成功請求和總請求持續時間。 以下是結果 所有結果顯示,官方 MegaETH RPC 在所有六大洲和 27 個區域中都更快。根據此測試,MegaETH 的延遲範圍約為 126 毫秒到 238 毫秒。而 Thirdweb 的延遲範圍約為 170 毫秒到 381 毫秒。兩者的失敗率都很低,但 MegaETH 的失敗率略低,總請求持續時間也始終低於 MegaETH。 作為背景,通常網絡至少有幾個區域,第三方 RPC 更快。Avalanche、Optimism 和 Ethereum 在公共基準測試中都有這樣的例子。請參見 - Avalanche C-Chain 結果 - Optimism 結果 - Ethereum 結果 MegaETH 在各地擊敗 Thirdweb 並不典型。 我認為 MegaETH 官方 RPC 能夠脫穎而出的原因是該網絡在架構上經過良好調優,並且一次只使用一個排序器。 我邀請 @NamikMuduroglu @yangl1996 @0xSami_M 分享他們的想法 這是測試網,因此在主網流量更重時,數字可能會有所變化。然而,目前,如果您需要從 MegaETH 區塊瀏覽器中提取數據的最快和最可靠的方法,官方 RPC 是明確的選擇。 注意:我不是專家,這只是理論上的,可能不是 100% 準確,因為測試的數據是輕量級調用,此外這些結果是快照,結果可能會因不同時間涉及更大數據而有所不同,最後我使用的是公共的 Thirdweb RPC,可能還有其他更快的 RPC。
12.79K