Estes são alguns resultados interessantes. É sempre bom ver o MegaETH chegar ao topo :) Para colocar os dados em algum contexto, a latência de ponta a ponta de uma solicitação RPC consiste em três componentes: (1) latência de propagação da velocidade da luz de/para o observador de/para o servidor de/para o servidor, (2) tempo que leva para o servidor pegar e pós-processar os dados solicitados, (3) 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 interpretem mal - os RPCs do MegaETH também são muito fortes em (2) e (3) e seria interessante ver experimentos que os estressam! Então, como ajustamos a latência de propagação? Na verdade, não há muitos botões. Primeiro, podemos implantar servidores RPC em várias regiões geográficas e rotear automaticamente a solicitação para o servidor mais próximo. É como cadeias de fast food abrindo lojas em todo o lugar - sempre há uma filial por perto! Mais precisamente, ter servidores distribuídos geograficamente reduz a distância física entre usuários e 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 de acordo com o caminho de rede real 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, existem até vários caminhos de rede seguindo a mesma rota geográfica; alguns são mais congestionados do que outros que induzem maior latência. É como ter várias rodovias para escolher do ponto A ao ponto B. As vantagens de latência que você observou provavelmente vieram de nós otimizando a rota.