Estos son algunos resultados interesantes. Siempre es bueno ver que MegaETH llega a la cima :) Para poner los datos en contexto, la latencia de extremo a extremo de una solicitud RPC consta de tres componentes: (1) latencia de propagación a velocidad de la luz desde/hacia el observador hacia/desde el servidor, (2) tiempo que tarda el servidor en capturar y posprocesar los datos solicitados, (3) tiempo que tarda el observador en descargar la respuesta. Como mencionó, los métodos RPC que se están probando son más ligeros, tanto en términos de costo computacional como en términos de tamaño de datos. Esto significa que los experimentos probaron principalmente (1), es decir, la latencia de propagación entre los observadores y los servidores RPC. No me malinterpretes: los RPC de MegaETH también son bastante fuertes en (2) y (3) y sería interesante ver experimentos que los estresan. Entonces, ¿cómo ajustamos la latencia de propagación? En realidad, no hay demasiadas perillas. En primer lugar, podemos implementar servidores RPC en varias regiones geográficas y enrutar automáticamente la solicitud al servidor más cercano. Esto es como si las cadenas de comida rápida abrieran tiendas por todas partes: ¡siempre hay una sucursal cerca! Más precisamente, tener servidores distribuidos geográficamente reduce la distancia física entre usuarios y servidores. En segundo lugar, podemos optimizar la topología de red. Incluso si es entre el mismo par de emisor y receptor, la latencia de propagación varía en función de la ruta de red real atravesada. Por ejemplo, entre la costa este de EE. UU. y Asia, la latencia puede variar 2 veces dependiendo de si los paquetes de datos pasan por el Pacífico o por Europa. A veces, incluso hay múltiples rutas de red que siguen la misma ruta geográfica; algunos están más congestionados que otros, lo que induce una mayor latencia. Esto es como tener varias autopistas para elegir del punto A al punto B. Las ventajas de latencia que observaste probablemente provinieron de nosotros optimizando la ruta.