Это довольно интересные результаты. Всегда приятно видеть, что MegaETH на первом месте : ) Чтобы поставить данные в контекст, задержка от конца до конца для RPC-запроса состоит из трех компонентов: (1) задержка распространения со скоростью света от/к наблюдателю к/от сервера, (2) время, необходимое серверу для получения и постобработки запрашиваемых данных, (3) время, необходимое наблюдателю для загрузки ответа. Как вы упомянули, тестируемые методы RPC являются более легкими как с точки зрения вычислительных затрат, так и с точки зрения объема данных. Это означает, что эксперименты в основном тестировали (1), т.е. задержку распространения между наблюдателями и серверами RPC. Не поймите меня неправильно – RPC MegaETH также довольно сильны в (2) и (3), и было бы интересно увидеть эксперименты, которые их нагружают! Итак, как мы можем оптимизировать задержку распространения? На самом деле, не так много настроек. Во-первых, мы можем развернуть серверы RPC в нескольких географических регионах и автоматически направлять запросы к ближайшему серверу. Это похоже на то, как сети быстрого питания открывают магазины повсюду – всегда есть филиал рядом! Более точно, наличие геораспределенных серверов уменьшает физическое расстояние между пользователями и серверами. Во-вторых, мы можем оптимизировать топологию сети. Даже если это между одной и той же парой отправителя и получателя, задержка распространения варьируется в зависимости от фактического сетевого пути. Например, между восточным побережьем США и Азией задержка может варьироваться в 2 раза в зависимости от того, проходят ли пакеты данных через Тихий океан или через Европу. Иногда есть даже несколько сетевых путей, следуя одному и тому же географическому маршруту; некоторые более загружены, чем другие, что вызывает большую задержку. Это похоже на наличие нескольких автомагистралей на выбор от точки A до точки B. Преимущества задержки, которые вы наблюдали, скорее всего, возникли из-за нашей оптимизации маршрута.