Cómo crear confiabilidad para tu app: la clave del éxito en Web3

Muchos equipos de aplicaciones web3 están condenados al fracaso.

¿Por qué?

Porque las aplicaciones dependen totalmente de los nodos, y los nodos son increíblemente difíciles de mantener. Algunas razones:

1. La confiabilidad de los nodos no puede construirse en el vacío; debe estar acompañada de escalabilidad y precisión de datos
2. Los nodos no están diseñados para ser soluciones de producción a gran escala
3. Se espera que los nodos hagan demasiadas cosas
4. Los nodos requieren mantenimiento de tiempo completo
5. La eficacia de los nodos depende de navegar exitosamente actualizaciones de red o hard forks con horarios impredecibles

Estas complicaciones hacen que los nodos sean difíciles de administrar y mantener.

Pero hay dos dimensiones arquitectónicas que mejoran significativamente la confiabilidad de los nodos, o la capacidad de un usuario de interactuar exitosamente con tu app cuando lo necesite:

• Heterogeneidad: sistemas diversos y complementarios que pueden manejar distintas solicitudes
• Redundancia: sistemas de respaldo, de manera que si un sistema falla, otros sigan funcionando

En web3, la falta de confiabilidad puede tener consecuencias perjudiciales.

Tomemos el caso de un conocido marketplace de NFT que usaba infraestructura poco confiable...

Su plataforma era inestable, lo que generó:

• Una carga de ingeniería pesada
• Una experiencia de usuario degradada
• Más de 190 horas de inactividad en un solo trimestre

¿Cuál fue el impacto? $6M en ingresos perdidos.

No dejes que esto te pase.

En este artículo, explicaremos:

1. Por qué mantener la confiabilidad de los nodos es un desafío
2. Patrones comunes de infraestructura de nodos y por qué fallan
3. Cómo Alchemy aborda los desafíos de confiabilidad y construye para la confiabilidad a escala

Por qué mantener la confiabilidad de los nodos es un desafío

Hay cinco razones principales por las que la confiabilidad es particularmente difícil de mantener en web3:

(1) La confiabilidad de los nodos no puede construirse en el vacío; debe estar acompañada de escalabilidad y precisión de datos

Para crear una aplicación altamente funcional, necesitas confiabilidad, combinada con escalabilidad y precisión de datos.

• Escalabilidad: la capacidad de seguir interactuando con la blockchain a medida que el tráfico de tu app escala 10x, 100x, 1000x o más.
• Precisión de datos: el estado en el que tu app devuelve datos correctos y consistentes a cada usuario.

(2) los nodos no están diseñados para ser soluciones de producción a gran escala‍

Los nodos fueron diseñados inicialmente para ser operados por individuos, para uso personal y casos de uso a pequeña escala. Aunque son costosos ($1000 / mes), para ese caso de uso limitado pueden generar suficiente confiabilidad, y mantener:

• Escalabilidad; el volumen de solicitudes es controlado de forma predecible, limitando cualquier riesgo relacionado con la escalabilidad requerida
• Precisión de datos; dado que hay un solo nodo, no hay oportunidad de inconsistencias de datos entre nodos

Sin embargo, un entorno de desarrollo no es un entorno de producción, y la producción requiere herramientas muy distintas.

(3)** **se espera que los nodos hagan demasiadas cosas

Se espera que los nodos hagan un número ilimitado de cosas, p. ej., ejecutar software peer-to-peer, funcionar como base de datos escalable, ejecutar código arbitrario, etc.

Los nodos tampoco tienen "opinión" sobre lo que deberían o no deberían hacer.

En conjunto, esto tiene dos consecuencias principales:

• Escalabilidad; a medida que escalas con un volumen creciente de solicitudes, necesitas poner en marcha nuevos nodos; y cada nodo nuevo debe construirse incluyendo esa larga lista de funcionalidades, generando ineficiencias engorrosas y costos (de nuevo, en el extremo más barato, operar un nodo costará $1,000/mes).
• Casos extremos; como el nodo carece de protecciones básicas, una sola consulta puede hacer caer el nodo por sí sola.

(4) Los nodos requieren mantenimiento de tiempo completo

En promedio, cada 5 días, los nodos pueden presentar problemas por:

• Fugas de memoria
• Problemas de almacenamiento de datos
• CPUs al máximo
• Peering inconsistente
• Bases de datos internas corruptas
• Problemas de difusión de transacciones
• Bugs y regresiones
• 1 de cada 6 "versiones estables" está rota

Cada problema toma un tiempo considerable para diagnosticarse, resolverse y corregirse, y significa mucho menos tiempo enfocado en la experiencia de usuario de tu front-end.

(5) La eficacia de los nodos depende de navegar exitosamente actualizaciones de red o hard forks con horarios impredecibles

Las actualizaciones de red y los hard forks ocurren según el cronograma del protocolo, no el tuyo. Cada uno requiere una preparación considerable, y hacerlo mal puede significar que los nodos fallen, con un impacto perjudicial.

Patrones comunes de arquitectura de infraestructura y por qué fallan

Operar infraestructura de nodos confiable es intrínsecamente desafiante, y gran parte de la arquitectura común en web3 es ineficaz para lograr confiabilidad:

Operar un solo nodo

Es más simple de configurar, pero está sujeto a un único punto de falla, careciendo tanto de heterogeneidad como de redundancia. El uptime de un solo nodo se ha medido tan bajo como 72%, y escalar un solo nodo es altamente ineficiente.

Operar un nodo con un respaldo

Esto crea algo más de redundancia que un solo nodo, pero sigue sin haber heterogeneidad (sin diversidad de sistemas), y a menudo, una solicitud que tumba al primer nodo también tumbará al segundo. Los problemas de escalabilidad persisten, y además se introducen problemas de precisión de datos, lo que significa que los nodos devolverán respuestas distintas, ya que la mayoría de los sistemas no pueden garantizar que cada nodo esté en el mismo block head (o incluso en la misma cadena).

‍Balanceo de carga entre una flota de nodos

Este modelo crea más redundancia, pero sigue sin haber heterogeneidad. Los problemas de precisión de datos y escalabilidad persisten (una serie de reintentos puede tumbar a toda una flota de nodos).

Los nodos suelen caerse y son realmente, realmente engorrosos de arreglar.

Si aún no quedó claro, muchas "soluciones" para conectarse a la blockchain no ofrecen suficiente heterogeneidad ni redundancia, y por eso, en última instancia, fallan. Las fallas tienen consecuencias severas.

Los nodos pueden requerir días o semanas de tiempo de recuperación para volver a funcionar. Estos problemas son costosos, difíciles de resolver y requieren trabajo dedicado de todo el equipo.

En 2019, BlockCypher intentó navegar el Constantinople Hard Fork de Ethereum. Se toparon con un error de datos faltantes y no pudieron diagnosticar la causa raíz. Sufrieron más de un mes de inactividad, y finalmente tuvieron que prácticamente reiniciar desde cero.

No dejes que esto te pase ;)

Mientras más heterogénea y redundante sea tu infraestructura web3, más confiable será.

Cómo Alchemy construye para la confiabilidad a escala

El motor Cortex de Alchemy combina sistemas personalizados, escalables y distribuidos que permiten confiabilidad y escalabilidad, mientras hacen que nuestra API actúe como un solo nodo, garantizando así la precisión de los datos.

Cortex logra tanto redundancia como heterogeneidad con sistemas escalables y diversos

Sistemas redundantes y heterogéneos para minimizar las solicitudes de datos a los nodos

La infraestructura de web2 genera confiabilidad y escalabilidad al eliminar el almacenamiento de datos de los servidores y crear centros de almacenamiento externos.

Sin embargo, debido a la naturaleza particular de la arquitectura de nodos, eliminar el almacenamiento de datos de los nodos es esencialmente imposible.

Para lograr confiabilidad y escalabilidad, el motor Cortex de Alchemy usa una arquitectura avanzada, llamada infraestructura secundaria, para replicar los datos de los nodos.

Vox Nodi, la capa de coordinación de Cortex, ejecuta verificaciones constantes del sistema para asegurarse de que la infraestructura secundaria tenga los datos más recientes, y por lo tanto, cualquier solicitud de datos, p. ej., número de bloque, logs de transacciones, recibos de transacciones, sea precisa.

Al enrutar las solicitudes primero a la infraestructura secundaria, los nodos quedan protegidos y se reduce su "carga de trabajo".

La mayoría de las solicitudes pueden ser manejadas por la infraestructura secundaria, y solo los casos extremos se enrutarán a los nodos.

Veamos un ejemplo:

Los usuarios quieren información sobre distintos tipos de datos y bloques:

• El Usuario 1 pide datos de Transacciones hasta el Bloque 82
• El Usuario 2 pide datos de Logs desde el Bloque 85
• El Usuario 3 pide datos de Bloques desde el Bloque 92

La solicitud del Usuario 1 puede ser atendida por el sistema de infraestructura secundaria. (Es importante notar que si una solicitud como esta llegara directamente a un nodo, el nodo fallaría, mientras que el sistema de infraestructura secundaria puede manejar esta carga sin problemas).

La solicitud del Usuario 2 también puede ser atendida por la infraestructura secundaria.

La solicitud del Usuario 3 no puede ser atendida por la infraestructura secundaria, porque el sistema aún no tiene los datos más recientes de Bloques del Bloque 92. La solicitud del Usuario 3 será atendida entonces desde los nodos.

En este ejemplo, la experiencia para los Usuarios 1, 2 y 3 es exactamente la misma. No hay diferencia en tiempo de inactividad cuando una solicitud se responde a través de la infraestructura secundaria o directamente desde los nodos. Pero al enrutar las solicitudes primero al sistema de infraestructura secundaria, los nodos quedan protegidos y se reduce su "carga de trabajo".

Sistemas redundantes y heterogéneos para ejecutar código

Debido a que la Ethereum Virtual Machine (EVM) es Turing completa, se puede solicitar a los nodos que ejecuten código. Como los nodos no pueden autorregularse, existe un riesgo constante de que una solicitud arbitraria tumbe toda una flota de nodos.

Para protegerse de esto, Alchemy deduplica y almacena todas las solicitudes que nuestro sistema ha respondido previamente.

Esto significa que solo una solicitud verdaderamente nueva se ejecutará en los nodos, y que, de lo contrario, la gran mayoría de las solicitudes puede ejecutarse mediante estos sistemas de almacenamiento.

Nodos heterogéneos, especializados para distintas solicitudes

Además de los sistemas de infraestructura secundaria, Alchemy agrega heterogeneidad con tipos de nodos distintos. En los escenarios atípicos en que la infraestructura secundaria no puede responder a una solicitud, el sistema recurre por defecto al nodo más escalable.

Alchemy opera múltiples tipos de nodos, incluyendo:

• Light: descarga solo los encabezados de bloque, el mínimo de datos necesario para transaccionar en la red. Los nodos light pueden interactuar eficientemente con la red y ahorrar megabytes de ancho de banda y gigabytes de almacenamiento, pero están limitados porque no tienen acceso a los datos completos.
• Full: tiene todo lo necesario para verificar que los bloques en la red sean correctos, y puede interactuar con cualquier smart contract y desplegar el propio. Los nodos full requieren recursos significativos de cómputo y ancho de banda.
• Archive: va un paso más allá que un nodo full. Mientras que un nodo full recorta entradas que ya no necesita para verificar, el nodo archive mantiene todo (terabytes de datos adicionales). Estos detalles son excelentes para consultar información de manera más eficiente y útiles para algunas aplicaciones, pero son excesivos en la mayoría de los casos.
• Debug: los nodos debug van incluso más allá que un nodo archive, almacenando la mayor cantidad de información de cualquier tipo de nodo, de modo que puedas recorrer la ejecución de un smart contract con un nivel de detalle extremo.

Las propiedades distintas de los tipos de nodos los hacen buenos en cosas diferentes, así que si un nodo no puede responder a una solicitud, es probable que los demás sigan sanos y bien preparados para responder.

Por ejemplo, si hay una solicitud de los datos más recientes, que quizás aún no estén registrados en la infraestructura secundaria, esa solicitud puede enrutarse a un nodo fast, y el nodo archive quedará "protegido", ya que revisar los datos del nodo archive sería considerablemente más costoso.

Para facilitar la puesta en marcha de nuevos nodos según se necesite, el motor Cortex toma "snapshots" de los nodos, de modo que, al crear un nuevo nodo, el sistema pueda partir desde el "checkpoint" más reciente, acortando significativamente el proceso de sincronización.

Clientes heterogéneos para mitigar el impacto de los bugs

Por último, Alchemy opera distintas implementaciones del cliente de Ethereum, incluyendo geth, Erigon y Parity. Esto prácticamente triplica el trabajo de mantenimiento de backend requerido, pero es enormemente valioso en función de la heterogeneidad: la probabilidad de que estos clientes tengan el mismo bug es esencialmente cero.

Crear confiabilidad mediante redundancia y heterogeneidad

En Alchemy, hemos invertido cientos de miles de horas en la ingeniería de Cortex, un conjunto complejo de sistemas construidos desde cero para ser heterogéneos y redundantes, aumentando drásticamente nuestra tolerancia a fallos y asegurando que podamos responder de manera confiable a cualquier solicitud de blockchain.

Nos ha tomado años construir los sistemas complejos e interdependientes que hacen posible esta confiabilidad. Construir para controlar la confiabilidad es extremadamente desafiante, pero aprovechar una infraestructura confiable es crucial para el éxito de tu app.

Al explorar opciones de infraestructura, una de las primeras preguntas que deberías hacerle a un proveedor es: "¿Qué tan heterogénea y redundante es tu infraestructura? ¿Y qué evidencia puedes mostrarme que compruebe la confiabilidad de tus sistemas?"

Los benchmarks públicos de proveedores de RPC pueden ayudar a evaluar la latencia, las tasas de éxito y las solicitudes fallidas, junto con las afirmaciones de un proveedor sobre su arquitectura.

El éxito de tu app depende de esta elección. ¡Cuéntanos cómo podemos ayudarte!