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.
Avaworld
Avaworld15/08, 21:38
MegaETH Official RPC vs Thirdweb RPC – Latência do Testnet Queria obter dados diretos do MegaEth sem ter que executar nenhuma infraestrutura e estava à procura da forma mais rápida de fazer isso. Usei "" para executar um benchmark simples para ver como o RPC oficial do MegaETH se compara a um RPC de terceiros (Thirdweb). O objetivo era verificar qual deles puxaria dados frescos do explorador mais rapidamente de diferentes partes do mundo. O teste utilizou a chamada RPC `eth_blockNumber` e `eth_getBalance` na testnet do MegaETH. Ele abrange 27 regiões da AWS em 6 continentes, enviando solicitações uma após a outra com um intervalo de um segundo. Acompanhou a latência média, falhas, erros 429, solicitações bem-sucedidas e a duração total das solicitações. Aqui estão os resultados Todos os resultados mostraram que o RPC oficial do MegaETH foi mais rápido em todos os seis continentes e em todas as 27 regiões. A latência do MegaETH variou de cerca de 126 ms a 238 ms de acordo com este teste. Para o Thirdweb, a latência variou de cerca de 170 ms a 381 ms. Ambos tiveram baixas taxas de falha, mas o MegaETH teve ligeiramente menos, e a duração total das solicitações foi consistentemente menor para o MegaETH. Para contextualizar, normalmente as redes têm pelo menos algumas regiões onde um RPC de terceiros é mais rápido. Avalanche, Optimism e Ethereum têm todos exemplos disso em benchmarks públicos. Veja os - Resultados da Avalanche C-Chain - Resultados da Optimism - Resultados da Ethereum MegaETH superando o Thirdweb em todos os lugares não é típico. Minha tese sobre por que o RPC oficial do MegaETH se destaca é que a rede está bem ajustada arquitetonicamente e utiliza um único sequenciador por vez. Convido @NamikMuduroglu @yangl1996 @0xSami_M a compartilhar seus pensamentos Este é um testnet, então os números podem mudar na mainnet quando o tráfego for mais intenso. No entanto, por agora, se você precisa da forma mais rápida e confiável de obter dados do explorador MegaETH, o RPC oficial é a escolha clara. NB: Não sou um especialista, isto é apenas teórico e pode não ser 100% preciso, pois os dados testados foram chamadas leves; além disso, esses resultados foram capturados, os resultados podem variar se dados maiores estiverem envolvidos em diferentes momentos; por último, usei um RPC público do Thirdweb, pode haver outros mais rápidos.
12,8K