这些结果很有趣。看到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.64K