Estes são alguns resultados interessantes. É sempre bom ver que o MegaETH está no topo : ) Para colocar os dados em contexto, a latência de ponta a ponta de uma solicitação RPC consiste em três componentes: (1) latência de propagação à velocidade da luz de/para o observador para/de o servidor, (2) o tempo que leva para o servidor capturar e processar os dados solicitados, (3) o tempo que leva para o observador baixar a resposta. Como você mencionou, os métodos RPC que estão sendo testados são mais leves, tanto em termos de custo computacional quanto em termos de tamanho de dados. Isso significa que os experimentos testaram principalmente (1), ou seja, a latência de propagação entre os observadores e os servidores RPC. Não me entenda mal – os RPCs do MegaETH também são bastante fortes em (2) e (3) e seria interessante ver experimentos que os estressassem! Então, como podemos ajustar a latência de propagação? Na verdade, não há muitas opções. Primeiro, podemos implantar servidores RPC em várias regiões geográficas e direcionar automaticamente as solicitações para o servidor mais próximo. Isso é como cadeias de fast food abrindo lojas em todos os lugares – há sempre uma filial por perto! Mais precisamente, ter servidores geo-distribuídos reduz a distância física entre os usuários e os servidores. Em segundo lugar, podemos otimizar a topologia da rede. Mesmo que seja entre o mesmo par de remetente e receptor, a latência de propagação varia com base no caminho real da rede percorrido. Por exemplo, entre a Costa Leste dos EUA e a Ásia, a latência pode variar em 2x dependendo se os pacotes de dados passam pelo Pacífico ou pela Europa. Às vezes, há até vários caminhos de rede seguindo a mesma rota geográfica; alguns estão mais congestionados do que outros, o que induz a uma latência maior. Isso é como ter várias rodovias para escolher do ponto A ao ponto B. As vantagens de latência que você observou provavelmente vieram da nossa otimização da rota.