Related articles
En 0xArc, necesitamos tener todos los datos, en cada cadena, en cada momento (pasado, presente y futuro). Como resultado, nuestros almacenes de datos tienen un tamaño de cientos de terabytes. Para obtener estos datos, hemos realizado miles de millones de llamadas RPC y seguimos haciendo cientos de millones por mes en muchas redes blockchain. Desafortunadamente, descubrimos que, en promedio, las llamadas RPC a nodos funcionan aproximadamente ~80% del tiempo dependiendo de las condiciones con variaciones de precios 10 veces mayores. Este artículo comparte algunos de nuestros hallazgos y esperamos que sea útil para el resto de la comunidad.
Antes de hablar de números, es importante comprender cómo funciona la industria de los nodos en criptografía para que podamos comprender adecuadamente lo que estamos discutiendo. Si bien sería fantástico si todos ejecutaran sus propios nodos y siguiéramos principios perfectos de descentralización, la realidad es que ejecutar un nodo es complejo y requiere experiencia. Por lo tanto, delegamos esta responsabilidad a un proveedor de nodos. Este diagrama se basa en cómo funcionará la industria de los nodos comerciales en 2024 en cripto.
En un nivel alto, tiene nodos completos o de archivo que se ejecutan en un tipo específico de implementación de nodo (geth/reth/erigon). Estos nodos están alojados por un proveedor como Alchemy o Quicknode para cada purple blockchain que admiten. Usted, como consumidor de RPC, accede a todo esto al last de la línea.
Cuando deconstruyes esta cadena de lógica, tienes 4 dimensiones principales que tendrán un gran impacto en el rendimiento:
La cadena a la que estás realizando solicitudes RPC: la purple de nodos de cada cadena se comporta de manera diferente y tiene diferentes niveles de actividad.
El método al que estás llamando: esto dependerá de si estás realizando llamadas de nodo completo o de archivo y de la implementación del cliente de nodo.
El proveedor que estás utilizando: la entidad que aloja los nodos a los que puedes acceder.
Cuando llama al nodo: el rendimiento del nodo varía en todas las dimensiones anteriores a lo largo del tiempo, no es constante.
Ser capaz de instrumentar y comprender estos datos puede ser un gran desafío. Sin embargo, en 0xArc este es nuestro trabajo, ya que realizamos miles de millones de llamadas RPC y monitoreamos cuidadosamente el rendimiento de todo lo que tocamos. El rendimiento, la confiabilidad y el costo son primordiales para nosotros. Sabemos cuándo una cadena está caída o cuando un proveedor de RPC está caído antes que la mayoría de los participantes del mercado. Aquí está el contexto de los datos que veremos en este artículo:
Para comprender adecuadamente lo que sucede con más de 1b+ filas de datos, tendremos que dividirlos en muchas dimensiones. Afortunadamente, sabemos cuáles son a través de los puntos que mencioné anteriormente.
El resto del artículo mostrará casos únicos de cómo el rendimiento puede variar en cada una de estas dimensiones de forma impredecible.
Suponga que está creando una aplicación de cadena cruzada que se basa en la interfaz con varias redes. El rendimiento de su nodo variará significativamente según la cadena a la que esté llamando y la hora en que la llame.
Este primer gráfico muestra cuál fue la tasa de éxito promedio para cada cadena por día agregada en todos los proveedores y métodos. Como puede ver en el cuadro a continuación, la tasa de éxito promedio que obtiene de las cadenas varía significativamente casi todos los meses. No estamos seguros de por qué puede ser así, pero podemos ver que las llamadas de Polygon tuvieron éxito en promedio el 60% de las veces en agosto, pero luego aumentaron hasta un 80%+ en las semanas más recientes.
Una advertencia clave de estos datos al evaluarlos no es: “Polygon es una mala cadena y las llamadas RPC solo tienen éxito el 70% de las veces en promedio”. Esta es la tasa de éxito promedio combinada en todas las cadenas, todos los proveedores y todos los métodos durante un período de aproximadamente 2,5 meses. A medida que profundizamos en cualquiera de estas dimensiones, los datos cambian significativamente.
Este es el mismo gráfico pero para un período de 17 días y filtrado por un único proveedor. Como puede ver, el gráfico es mucho más fluido y varía del agregado normal.
Si vemos que a un solo proveedor le va bien, ¿qué nos impide duplicar nuestra apuesta todo el tiempo? La siguiente sección aborda esa cuestión con más matices.
El siguiente gráfico lo simplifiqué porque quería evitar tener demasiadas líneas. Cada uno de ellos representa una importante purple de proveedores de RPC y su tasa de éxito se agrega en todas las cadenas y métodos. Como puede ver en el cuadro a continuación, el proveedor naranja es uno de los más confiables en comparación con los demás y ¡la diferencia es bastante asombrosa!
Una vez más, lo obvio podría ser simplemente “usar el proveedor naranja” porque funciona bien. Desafortunadamente, eso tampoco funciona. Cuando observamos el rendimiento del proveedor naranja solo para Ethereum, los métodos del nodo de archivo pueden tener caídas dramáticas en el rendimiento. Como puede ver, durante casi un mes, los nodos de archivo tuvieron un desempeño horrible en lo que se suponía que period “el mejor proveedor” en nuestro ejemplo anterior.
Entonces, si buscamos el mejor rendimiento para ciertos métodos, debemos mirar más de cerca.
Nuestro cuadro last a continuación muestra cómo el éxito de varios métodos cambia considerablemente de un mes a otro. Dependiendo de si realiza llamadas a nodos completos o a nodos de archivo, su rendimiento variará significativamente. Vimos esto brevemente en un ejemplo aislado con el único proveedor en una cadena arriba, pero ahora tenemos una vista más alejada.
Si promediamos estos datos, obtenemos el desglose a continuación de la tasa de éxito promedio por método con el gráfico de áreas adjunto que muestra un desglose de las llamadas a nodos de archivo versus no de archivo. Cuando lo pones así, te das cuenta de lo poco confiables que pueden ser los nodos cuando miras a través de muchas dimensiones. Muchas veces, los proveedores de nodos utilizan brillantes cifras de advertising en períodos de tiempo limitados para promocionar su rendimiento. No es hasta que los analizas a escala que ves las métricas reales.
Entonces, ¿cuál es la mejor manera de seleccionar un nodo? Una línea de argumento para esta complejidad puede ser usar simplemente el proveedor naranja en nuestro ejemplo anterior; sin embargo, cuando sus sistemas comiencen a fallar y experimenten grandes caídas, sus sistemas posteriores fallarán debido a ellos.
Una forma de evitar esto es tener proveedores alternativos en su sistema. Sin embargo, estos proveedores alternativos requieren mantenimiento handbook y aumentan la latencia mediante un enrutamiento subóptimo. Lo ultimate sería tener datos sobre cómo funcionan todas estas rutas de forma dinámica e inteligente, en lugar de cláusulas estáticas if/else en su código base.
Para complicar aún más las cosas, los precios de cada proveedor cambian según la cadena y el método. Estas diferencias pueden llegar a ser hasta 10 veces el costo por método/cadena. ¡De repente, una diferencia del 10 al 20 % en el rendimiento acaba costándote mucho más! Cada proveedor quiere encerrarte en un plan anual o una cuota mensual que tiene costos adicionales. Casi ningún proveedor se basa únicamente en el uso, lo que significa que estás obligado a realizar una apuesta en uno solo, ¡sin ningún dato! Lo que al principio es un “servicio easy”, en realidad tiene una gran variación en el rendimiento cuando se inspecciona de cerca.
Si está pagando por RPC o pensando en la confiabilidad de su infraestructura, exploremos cómo maximizar el rendimiento en todas las cadenas y proveedores. Comuníquese para conversar sobre nuestros hallazgos o para ver cómo podemos ayudar.
Actualmente paga por RPC y desea obtener más información sobre cómo mejorar su confiabilidad.
Es un proveedor de RPC y desea saber cómo funcionan sus nodos.
Está pensando en suscribirse a un servicio RPC y le gustaría recibir algún consejo.
Comuníquese conmigo directamente desde este correo electrónico o enviándome un correo electrónico a okay@0xarc.io para que podamos programar algo de tiempo para charlar.
