---
title: "Precisión de datos: el problema endémico y poco conocido en Web3"
description: "Explora la importancia de la precisión de datos en la infraestructura de Web3, las limitaciones de las soluciones existentes y el enfoque de Alchemy."
---

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

<ExternalVideo
  url="https://vimeo.com/728999085"
  provider="vimeo"
  providerUid="728999085"
/>

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](https://sgrlaw.com/blockchain-decentralized-ledgers/), una de las propuestas de valor fundamentales de web3: en lugar de depender de un intermediario central, [miles de nodos](https://etherscan.io/nodetracker) 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](https://medium.com/coinmonks/what-is-a-peer-to-peer-p2p-network-in-blockchain-3fe4417dfba2), porque la información no llega a cada nodo al mismo tiempo.

<ExternalVideo
  url="https://vimeo.com/729065053"
  provider="vimeo"
  providerUid="729065053"
/>

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

<ImageBlock
  src="https://media.alchemy.com/1704793834-nfts-not-showing-up-in-wallets-on-time.png"
  alt="Los NFTs no aparecen a tiempo en las wallets"
  width={1068}
  height={557}
  caption="Los NFTs no aparecen a tiempo en las wallets"
/>

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

<CalloutBlock>

"[Todos los problemas de estado que se te puedan ocurrir en CryptoKitties](https://www.alchemy.com/case-studies/dapper) ocurrieron. Si los nodos estaban desincronizados, la experiencia del usuario y toda la dApp se veían afectadas."** - Eric Lin, Dapper**

</CalloutBlock>

## 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

<ImageBlock
  src="https://media.alchemy.com/1704794016-the-problems-with-running-a-single-node.png"
  alt="Diagrama de un usuario solicitando el último bloque a una dApp que corre un solo nodo"
  width={1920}
  height={1081}
  caption="Un usuario hace una llamada a tu dApp"
/>

✅ ¡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](https://www.alchemy.com/case-study/zerion) para tus clientes.

<CalloutBlock>

"Trabajar con Alchemy nos ha ayudado a ahorrar el equivalente a tres ingenieros de tiempo completo, que de otro modo estarían dedicados permanentemente al mantenimiento de infraestructura." - **Evgeny Yurtaev, CEO y Co-Fundador de [Zerion](https://www.alchemy.com/dapps/zerion)**

</CalloutBlock>

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.‍

<ExternalVideo
  url="https://vimeo.com/729065065"
  provider="vimeo"
  providerUid="729065065"
/>

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

<ExternalVideo
  url="https://vimeo.com/729065080"
  provider="vimeo"
  providerUid="729065080"
/>

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](https://community.infura.io/t/how-does-the-load-balancer-work/1090)
- 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."

<ExternalVideo
  url="https://vimeo.com/729065088"
  provider="vimeo"
  providerUid="729065088"
/>

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.

<EbookCta
  eyebrow="Guía gratuita"
  title="Build vs. Buy: Infraestructura blockchain"
  description="Antes de contratar un equipo de infraestructura, lee esto: construirla internamente puede costar entre $850K y $1M+ al año antes de atender una sola solicitud en producción. Mira el desglose completo de costos."
  ctaLabel="Descargar la guía"
  ctaHref="/resources/build-vs-buy"
  coverImage={{
    src: "https://media.alchemy.com/ebooks/cta-build-vs-buy.png",
    alt: "Build vs. Buy ebook cover",
  }}
/>

#### 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"‍

<ExternalVideo
  url="https://vimeo.com/728999085"
  provider="vimeo"
  providerUid="728999085"
/>

¿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

<ExternalVideo
  url="https://vimeo.com/729065102"
  provider="vimeo"
  providerUid="729065102"
/>

_¿Por qué pasa esto? Con una infraestructura poco precisa, _[_las transacciones pendientes_](https://www.alchemy.com/docs/ethereum-transactions-pending-mined-dropped-replaced)_ 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](https://www.alchemy.com/case-study/origin), por ejemplo. Los errores de RPC y la depuración eran algo constante con su primer proveedor de infraestructura, y [depurar los errores](https://www.alchemy.com/build) 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:**

<ImageBlock
  src="https://media.alchemy.com/1704794424-error-transferring-nft-from-bakery-swap.png"
  alt="Error al transferir un NFT desde Bakery swap"
  width={942}
  height={359}
  caption="Error al transferir un NFT desde Bakery swap"
/>

**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:**‍

<ImageBlock
  src="https://media.alchemy.com/1704794521-nfts-missing-in-user-wallet.png"
  alt="Reporte de usuario sobre NFTs faltantes en su wallet"
  width={1227}
  height={336}
  caption="NFTs faltantes"
/>

**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:**

<ImageBlock
  src="https://media.alchemy.com/1704794600-nfts-not-showing-up-in-user-wallet.png"
  alt="Los NFTs no aparecen en la wallet del usuario después de 4 horas"
  width={1224}
  height={552}
  caption="Los NFTs no aparecen en la wallet del usuario después de 4 horas"
/>

**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:**

<ImageBlock
  src="https://media.alchemy.com/1704794692-user-paying-gas-fees-twice-for-failed-transaction.png"
  alt="Usuario pagando gas fees dos veces por una transacción fallida"
  width={1232}
  height={399}
  caption="Usuario pagando gas fees dos veces por una transacción fallida"
/>

## 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](https://www.alchemy.com/benchmarks) 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.

<ImageBlock
  src="https://media.alchemy.com/1704794854-benchmarking-node-providers.png"
  alt="Gráfico comparando la precisión de datos entre proveedores de infraestructura de nodos durante 24 horas"
  width={3250}
  height={1500}
  caption="Comparación de proveedores de nodos"
/>

_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?

<CalloutBlock>

"Alchemy resolvió los problemas de consistencia que antes aparecían, eliminando el 98% de las quejas de usuarios y mejorando significativamente la experiencia de usuario y la adopción de [Augur](https://www.alchemy.com/dapps/augur)." - [**Alex Chapman, CTO de Augur**](https://www.alchemy.com/case-studies/augur)

</CalloutBlock>

Para garantizar la precisión de tus [apps](https://www.alchemy.com/dapps/top/defi-dapps) 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](https://www.alchemy.com/rpc-api), 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?

<ExternalVideo
  url="https://vimeo.com/730080026"
  provider="vimeo"
  providerUid="730080026"
/>

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](https://dashboard.alchemy.com/signup/?a=f79ab530c4) 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](https://www.alchemy.com/overviews/what-is-a-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.

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 200, title: "eth_blockNumber", dataType: "object" },
      { key: "2", width: 200, title: "Response Sequence", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 0,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 1,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 2,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 3,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 4,
      },
      {
        "1": { title: "<p>2</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 5,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: false, tooltip: "", icon: "" },
        id: 6,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: false, tooltip: "", icon: "" },
        id: 7,
      },
      {
        "1": { title: "<p>3</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 8,
      },
      {
        "1": { title: "<p>2</p>", tooltip: "", icon: "" },
        "2": { title: false, tooltip: "", icon: "" },
        id: 9,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: false, tooltip: "", icon: "" },
        id: 10,
      },
      {
        "1": { title: "<p>1</p>", tooltip: "", icon: "" },
        "2": { title: false, tooltip: "", icon: "" },
        id: 11,
      },
      {
        "1": { title: "<p>3</p>", tooltip: "", icon: "" },
        "2": { title: true, tooltip: "", icon: "" },
        id: 12,
      },
    ],
  }}
/>

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.