Precisión de datos: el problema endémico y poco conocido en Web3

Un equipo de NFT reconocido perdió decenas de miles de usuarios porque les mostraba información contradictoria a sus usuarios (ejemplo arriba).

Uno de los protocolos DeFi más grandes perdió $2M al solucionar bugs que generaban errores de frontend para los usuarios. Como el protocolo no pudo identificar la causa raíz, el problema no se resolvió durante semanas.

Ambos escenarios provienen del mismo problema: una falta de precisión en la infraestructura de nodos, algo muy común en Web3.

Como ingeniero, fundador, product manager o incluso usuario, si la precisión de los nodos aún no está en tu radar, necesitas convertirla en una prioridad para que tu app tenga éxito.

Un poco de contexto

Las blockchains funcionan mediante nodos que se comunican en una red peer-to-peer. Este elemento estructural es lo que permite la descentralización, una de las propuestas de valor fundamentales de web3: en lugar de depender de un intermediario central, miles de nodos registran transacciones propagándose información entre sí de forma trustless.

Para ofrecer a los usuarios resultados correctos y consistentes, la red de nodos debe ponerse de acuerdo sobre el estado más reciente de la blockchain. Esto es extremadamente difícil en una red peer-to-peer, porque la información no llega a cada nodo al mismo tiempo.

Esto significa que cuando una persona interactúa con una dApp que depende de nodos para obtener datos:

• Los nodos no siempre entregan los mismos datos ➡️
• El usuario no siempre recibe lo que espera

Con frecuencia, cuando los usuarios reciben información inesperada o contradictoria que no pueden explicarse, es porque hay una falta de precisión entre los nodos que están usando.

En Alchemy, definimos la precisión como el estado en el que una persona interactúa con una dApp y recibe datos correctos y consistentes a cambio.

En este artículo, explicaremos:

• Por qué la precisión es un problema específico de web3
• Las limitaciones de resolver la precisión con un solo nodo
• Las limitaciones de resolver la precisión con un load balancer
• Cómo una falta de precisión puede generar problemas generalizados en una app
• Cómo el motor Cortex de Alchemy resuelve la precisión en blockchain

La precisión existe cuando una persona interactúa con una dapp y recibe datos correctos y consistentes a cambio

En web2, [los sistemas centralizados hacen que la precisión sea un problema fácil de resolver](https://ethereum.org/en/developers/docs/web2-vs-web3/#:~:text=Web2 refers to the version,that run on the blockchain), porque la información solo puede provenir de una fuente. Pero el sistema distribuido de web3 genera una gran cantidad de problemas nuevos y complejos, entre ellos:

• Implementación compleja
• Dificultades para garantizar que la información llegue a los participantes más alejados de la red (literalmente toma más tiempo que la información llegue a nodos más lejanos en una red)
• Dificultades de coordinación de la red

Todos estos desafíos, que pueden generar una falta de precisión entre un grupo de nodos, pueden provocar:

• Experiencias rotas para los usuarios
• Pérdida de clientes
• Pérdida de tiempo y dinero al corregir el problema de forma retroactiva

Los problemas de ejecutar un solo nodo

Si el problema de la precisión de datos proviene de la comunicación entre varios nodos, podrías decidir ejecutar tú mismo un solo nodo.

Supongamos que estás ejecutando tu propio nodo único, y un usuario hace una llamada a tu dApp:

• Pide el último bloque
• Tu nodo le informa que el último bloque es el 4

✅ ¡Esto funciona!

Pero hay un problema.

Solo funcionará hasta cierto punto.

Enrutar todo el tráfico a través de un solo nodo limitará drásticamente la escalabilidad y confiabilidad de tu app:

• Escalabilidad: Si tu dApp tiene 100 usuarios hoy, pero la demanda exige que escale 10x, un solo nodo no podrá manejar eficazmente el aumento de solicitudes
• Confiabilidad: Si dependes de un solo nodo, cuando ese nodo se caiga, tu dApp también se caerá. Y como los nodos son notoriamente poco confiables, con solo uno tendrás mucho menos uptime del que necesitas (hemos medido uptime de un solo nodo tan bajo como 72% en algunos casos).

El tiempo que tu equipo dedicaría al mantenimiento de nodos es tiempo que no pueden dedicar a construir productos y experiencias para tus clientes.

Bien, ya te diste cuenta de que un solo nodo no es suficiente para las necesidades de tu negocio. ¿Qué puedes hacer a continuación?‍

Los problemas de usar un load balancer

Es posible que quieras probar con un proveedor de infraestructura que use un load balancer para gestionar el tráfico entre varios nodos; este es un diseño de infraestructura muy común en web3.

El load balancing es un mecanismo de escalamiento horizontal, originalmente utilizado en web2. Piensa en el load balancing como elegir la fila más corta en el supermercado: el load balancer dirigirá el tráfico de tu dApp al nodo con la fila más corta.‍

Observa el siguiente ejemplo.

Un usuario hace una llamada a tu dApp:

• Pide el último bloque
• A través del Nodo A, tu dApp le informa que el último bloque es el 2

Luego, el usuario pregunta de nuevo para confirmar:

• Esta vez la consulta se enruta al Nodo B
• A través del Nodo B, tu dApp le informa que el último bloque es el 4

Como el sistema sigue enrutando cada solicitud a través de un solo nodo, y en cualquier momento dado ese nodo puede no tener la información más reciente, los resultados suelen ser incorrectos. Tus usuarios recibirán resultados contradictorios que son imposibles de explicar.

El load balancing ofrece más escala y confiabilidad de la que puede mantener un solo nodo, pero esto tiene un costo en precisión.

Cuando el tráfico se enruta a través de un load balancer, los nodos pueden tener información distinta sobre:

• Los últimos bloques
• Las transacciones más recientes
• Las transacciones pendientes

Estos problemas pueden significar que:

• Los desarrolladores experimentan datos inconsistentes
• Las solicitudes fallan
• Las aplicaciones fallan
• Un solo usuario verá resultados contradictorios para la misma solicitud
• Varios usuarios verán resultados contradictorios para la misma solicitud

¿Todavía no estás convencido de que esto es un problema grave? Sigue leyendo.

Cómo una falta de precisión causa problemas graves

Supongamos que Isaac quiere unirse a una DAO, y para hacerlo, necesita comprar su token.

• Isaac le pregunta a un Exchange Descentralizado (DEX): "¿El token de la DAO sigue disponible?"
• El proveedor de infraestructura del DEX enruta la solicitud de Isaac al Nodo A.
• A través del Nodo A, el DEX le responde: "Sí, los tokens siguen disponibles."

✅ ¡Los tokens están disponibles!

Isaac va a hacer su compra.

• El proveedor de infraestructura del DEX enruta la solicitud de Isaac al Nodo B.
• A través del Nodo B, el DEX le responde: "Transacción fallida."

Como el DEX usaba un proveedor de infraestructura que hacía load balancing entre nodos (un mecanismo de escalamiento muy común en web3), cuando Isaac confirmó que el token seguía disponible, el Nodo A devolvió información que, en este caso, estaba desactualizada.

Esto pone de relieve el punto clave: en un momento dado, no se puede depender de la información de un nodo individual, que es de donde siempre proviene la información al usar un load balancer.

Es posible que ese nodo no tenga la información más reciente, y si es el nodo que responde a tu solicitud, tu transacción (o las transacciones posteriores) probablemente fallará o presentará un comportamiento inesperado.

Los problemas de precisión causan una amplia variedad de estados de falla

Lo que le pasó a Isaac es uno de muchos estados de falla causados por una falta de precisión de los nodos.

Veamos algunos otros estados de falla posibles:

1. Las ejecuciones de smart contracts devuelven respuestas contradictorias cuando debería haber un único resultado factual. Por ejemplo:

• El usuario pregunta: "¿Quién es el dueño de este Bored Ape?"
• La API responde: "Alice"
• Luego el usuario pregunta: "Dime qué apes tiene Alice"
• La API responde: "Alice no tiene ninguno"‍

¿Por qué pasa esto? Con una infraestructura que depende de un load balancer, el estado de los smart contracts, y por lo tanto lo que sucede al ejecutarlos, será diferente según qué nodo atienda la solicitud.

2. Una dApp devuelve un "nonce" incorrecto (un identificador único para cada transacción individual desde una dirección de wallet dada), lo que provoca que las transacciones posteriores fallen. Por ejemplo:

• El usuario completa la transacción 1 con nonce 100
• El usuario pregunta: "¿Cuál es el siguiente nonce?"
• La API responde: 100 (esto debería ser imposible, ya que el nonce 100 ya se completó)
• La siguiente transacción será rechazada automáticamente

¿Por qué pasa esto? Con una infraestructura poco precisa, las transacciones pendientes pueden terminar en un solo nodo, así que cuando intentas obtener información sobre el estado de esas transacciones pendientes o de las wallets que las enviaron, muy frecuentemente se devuelven datos faltantes o engañosos.

Estos estados de falla son insidiosos, imposibles de explicar, y afectarán gravemente la salud de tu app

Algunas cosas que pueden ocurrir:

Puedes ingerir datos inexactos que corromperán tus bases de datos, lo que requerirá tiempo y esfuerzo para corregirlos.

Toma el caso de Origin, por ejemplo. Los errores de RPC y la depuración eran algo constante con su primer proveedor de infraestructura, y depurar los errores le tomaba mucho tiempo a su equipo.

Descubrieron que un nodo respondía una solicitud, pero ese nodo estaba varios bloques atrás de otro nodo que había respondido otra solicitud.

Estos problemas de estado eran prácticamente imposibles de resolver, y cuando finalmente identificaron la causa raíz, descubrieron que el problema había corrompido todo su sistema.

Como no existen mensajes de error ni códigos de falla para estos problemas, a) no puedes anticiparlos en tu código de forma proactiva y b) pasarás horas depurándolos cuando ocurran; esto será igual de confuso para tus usuarios:

**Los usuarios pueden enviar transacciones basadas en datos desactualizados que, por lo tanto, están destinadas a fallar; como resultado, perderán las tarifas de gas:**‍

Los usuarios pueden ver interfaces contradictorias en tu dApp, que reflejan consecutivamente que una transacción tuvo éxito o no. Atribuirán esta falla a la experiencia de frontend de tu dApp:

Los usuarios pueden pagar de más porque creen que una transacción no se minó con éxito, e intentan de nuevo; en realidad, la transacción original sí se procesó, pero no se reflejó correctamente:

Construyendo para la precisión

Si aún no queda claro, en las redes blockchain, una falta de infraestructura precisa puede tener un impacto muy negativo en tu dApp y tus usuarios.

Necesitas trabajar con un proveedor de infraestructura que:

• Considere la precisión como una prioridad fundamental
• Cuente con un sistema sostenible, distinto del load balancing, para mantener la precisión cuando tu dApp escale

Comparando proveedores de nodos

Hemos recopilado datos que comparan la precisión entre algunos proveedores de infraestructura de nodos conocidos. Usa esta herramienta para comparar la precisión tú también.

La precisión es una parte de la evaluación de un proveedor. También puedes comparar la latencia actual, las tasas de éxito y las solicitudes fallidas en los benchmarks de proveedores de RPC de Alchemy.

En nuestras pruebas, consultamos el método JSON RPC eth_blockNumber un total de ~1,072,000 veces para obtener el número de bloque más reciente de cada proveedor durante un período de 24 horas. Este es un ejemplo simple para medir la inexactitud de los datos. Hay muchos otros que tienden a fallar con más frecuencia, y de forma más catastrófica.

Nota En nuestra captura de muestra del dashboard, consultamos y registramos la precisión de los datos durante un solo día.

*Detalles completos de la metodología en el apéndice.

¿Qué puedes hacer para obtener datos precisos?

Para garantizar la precisión de tus apps y de tus clientes, Alchemy ha invertido cientos de miles de horas de ingeniería y ha desarrollado cientos de innovaciones únicas para construir el motor Cortex de Alchemy, que garantiza una precisión de datos consistente con los beneficios de escalabilidad y confiabilidad de una infraestructura multi-nodo.

Cortex es mucho más que un conjunto de nodos conectados; de hecho, eso es solo una fracción de lo que es el motor Cortex. Cortex combina sistemas personalizados, escalables y distribuidos que en esencia permiten que nuestra API actúe como un solo nodo, lo que resuelve todos los problemas de precisión que hemos analizado.

¿Cómo funciona esto?

Hemos construido una capa de consistencia explícita llamada Vox Nodi (la voz de los nodos). La responsabilidad de Vox Nodi es garantizar que cualquier solicitud de blockchain que ayudemos a atender devuelva un resultado consistente.

Esto funciona ejecutando, en esencia, un algoritmo de consenso a través de nuestra infraestructura, donde cada parte de la infraestructura puede votar sobre el estado correcto de la blockchain.

Al enrutar y ajustar las consultas correctamente, este sistema garantiza que, a pesar de que distintos nodos tengan visiones diferentes de los datos de transacciones en un momento dado, los resultados siempre sean consistentemente precisos.

En pocas palabras, Vox Nodi garantiza que cualquier solicitud a nuestra API se devuelva de forma rápida, confiable y con datos 100% precisos.

Y Cortex sigue permitiendo a los desarrolladores escalar de forma infinita y confiable, porque en lugar de un nodo individual, hay un motor de blockchain completo y distribuido respondiendo a cada solicitud.

En resumen, no es un load balancer.

Implicaciones y conclusión

Hay muchas dimensiones distintas que considerar al elegir cómo conectar tu dApp a la blockchain: la capacidad de un proveedor para ofrecer precisión debería ser el número uno en tu lista.

En Alchemy, la precisión es una prioridad máxima. Comienza gratis hoy en Alchemy.

Apéndice

Metodología de benchmarking

Al pensar en cómo medir la precisión, partimos de los primeros principios y probamos una de las llamadas RPC más básicas de Ethereum: eth_blockNumber.

Como recordatorio, eth_blockNumber devuelve el número de bloque más reciente de la red Ethereum, y en una red descentralizada, el bloque con el número más alto contiene las transacciones más recientes.

Por esto, en condiciones normales de red, llamar a eth_blockNumber desde un solo nodo/proveedor de nodos solo debería devolver números de bloque que asciendan en valor. Cualquier inconsistencia en el orden ascendente de los datos es indicativa de una reversión o, cuando ocurre con más frecuencia, de una posible inexactitud de datos del proveedor.

Ten en cuenta que esto es distinto de un 'reorg', donde una nueva cadena más larga reemplaza los datos existentes en un nodo. Los 'reorgs' siempre tendrán al menos la misma cantidad de bloques que los datos ya presentes en un nodo, así que si vemos que el número de bloque retrocede, podemos afirmar con certeza que se debe a una infraestructura defectuosa.

Para entender cómo medimos los datos desalineados, supongamos que tenemos la siguiente secuencia de números de bloque después de consultar eth_blockNumber un total de 13 veces.

Dada esta secuencia, encontramos un total de 5 errores en los índices de bloque 6, 7, 9, 10 y 11. Esto significa que en los bloques 6, 7, 9, 10 y 11, los bloques devueltos no siguieron la secuencia esperada de valores ascendentes, lo que evidencia algún problema subyacente de precisión de datos.

NOTA: Una vez que registramos que el proveedor de nodos está en el número de bloque 2, asumimos que cualquier valor posterior de 1 es incorrecto y equivale a que el proveedor viaje en el tiempo y entregue un valor de bloque actual que está 1 bloque atrasado. De manera similar, una vez que registramos que el proveedor de nodos está en el número de bloque 3, cualquier instancia en la que aparezcan los bloques 1 o 2 ahora está desalineada. Para simplificar esta prueba de benchmarking, medimos explícitamente la precisión de datos de proveedores individuales por sí mismos y no comparamos datos de bloques entre distintos proveedores.