Respuestas>Más información sobre la transmisión de datos en blockchain>Sondeo frente a transmisión de datos de blockchain
Recopilación de datos de la cadena de bloques frente a transmisión en tiempo real
// Tags
Polling frente a streaming WebSocket y blockchain
En resumen: El «polling» es un patrón basado en el «pull», en el que tu aplicación solicita repetidamente nuevos datos a un nodo de la cadena de bloques a intervalos fijos. El «streaming» es un patrón basado en el «push», en el que los nuevos datos se envÃan automáticamente a tu aplicación a medida que se generan en la cadena de bloques. El «polling» es sencillo de implementar, pero desperdicia recursos, introduce latencia y conlleva el riesgo de perder datos. El «streaming» es más eficiente, más rápido y más fiable a gran escala, pero requiere una infraestructura diferente. Para la mayorÃa de las aplicaciones de cadena de bloques en producción, el streaming es el enfoque más adecuado para la ingesta de datos.
La explicación sencilla
Toda aplicación basada en blockchain necesita saber cuándo ocurre algo en la cadena de bloques. Un monedero necesita saber cuándo su usuario recibe una transferencia. Un protocolo DeFi necesita detectar cuándo se actualiza un oráculo de precios. Un bot de trading necesita detectar las nuevas transacciones en el momento en que se incorporan a un bloque. Una plataforma de análisis necesita procesar cada bloque a medida que se genera. La pregunta es: ¿cómo se entera tu aplicación de estos eventos?
Con el sondeo, tu aplicación ejecuta un bucle: llama al RPC endpoint, comprueba si ha habido alguna novedad, procesa los datos nuevos, espera un intervalo fijo y repite. Este es el patrón que la mayorÃa de los desarrolladores aprenden primero, ya que se corresponde de forma natural con el funcionamiento de las API HTTP. Configura un temporizador, realiza una solicitud cada N segundos y gestiona la respuesta. No requiere ninguna infraestructura especial más allá de la capacidad de realizar solicitudes HTTP.
Con el streaming, tu aplicación establece una conexión o configura un canal de datos una sola vez, y los nuevos datos llegan automáticamente. No hay bucles, ni temporizadores, ni solicitudes repetidas. Cuando se genera un nuevo bloque, los datos fluyen hacia tu aplicación sin que esta los solicite. La función de la aplicación consiste simplemente en procesar los datos entrantes a medida que llegan.
Cómo funcionan las encuestas en la práctica
Una implementación tÃpica de sondeo para supervisar los nuevos bloques es la siguiente: tu aplicación llama a «eth_blockNumber» para obtener el último bloque, lo compara con el último bloque que procesó, recupera cualquier bloque nuevo mediante «eth_getBlockByNumber», extrae los datos que necesita y programa el siguiente sondeo. Cada iteración requiere como mÃnimo una llamada RPC (para comprobar el número del último bloque) y, potencialmente, muchas más (para recuperar los datos completos del bloque, los recibos de las transacciones y los registros de eventos de cada nuevo bloque).
En las cadenas de alto rendimiento, el sondeo se vuelve especialmente problemático. Solana genera ranuras cada 400 ms. Arbitrum y Base generan bloques cada 250 ms. Sondear estas cadenas a su ritmo de generación de bloques requiere entre 2 y 4 solicitudes RPC por segundo solo para comprobar los números de bloque, además de solicitudes adicionales para obtener los datos completos de los bloques. A gran escala, con múltiples cadenas, el volumen (y el coste) de las solicitudes RPC crece linealmente con el número de cadenas y el ritmo de generación de bloques de cada una.
Los WebSockets funcionan bien para casos de uso sencillos, pero presentan limitaciones importantes a gran escala. Las conexiones son con estado y pueden interrumpirse debido a problemas de red, reinicios del servidor o tiempos de espera por inactividad. Cuando se interrumpe una conexión, la aplicación pierde cualquier evento que se produzca antes de la reconexión, y debe detectar la desconexión, volver a conectarse y recuperar los datos perdidos. La gestión de múltiples conexiones WebSocket simultáneas en varias cadenas añade complejidad. Las suscripciones a WebSockets tampoco admiten datos históricos. Si necesitas procesar bloques de la semana pasada, los WebSockets no te servirán de ayuda.
Los servicios de streaming diseñados especÃficamente para este fin resuelven estas limitaciones. En lugar de mantener frágiles conexiones WebSocket, tu aplicación configura un canal de datos que el servicio de streaming gestiona de extremo a extremo. El servicio se conecta a los nodos de la cadena de bloques, procesa cada bloque, aplica tus filtros y entrega los resultados a tu destino con entrega garantizada. Si tu destino no está disponible temporalmente, el servicio almacena los datos en el búfer y vuelve a intentarlo. Si se produce una reorganización, el servicio envÃa cargas útiles de corrección. Si necesitas datos históricos, ese mismo canal puede recuperar datos desde cualquier bloque inicial.
Comparación de los dos enfoques
La latencia es la diferencia más evidente. En el mejor de los casos, el sondeo siempre tiene una latencia igual al intervalo de sondeo, aunque en la práctica suele ser mayor debido al tiempo de procesamiento y a la recuperación de errores. La transmisión en continuo proporciona los datos tan pronto como están disponibles, normalmente a los pocos segundos de que se genere un bloque. Para aplicaciones en las que la latencia es un factor crÃtico, como los bots de negociación o los paneles de control en tiempo real, la transmisión en continuo resulta significativamente más rápida.
La eficiencia en el uso de los recursos es la segunda gran diferencia. El sondeo genera un volumen de solicitudes proporcional a la frecuencia del sondeo, independientemente de si existen datos nuevos. Un proceso de sondeo que comprueba si hay nuevos bloques cada segundo realiza 86 400 solicitudes al dÃa, aunque solo le interese un evento especÃfico que se produce una vez a la semana. La transmisión en tiempo real consume recursos proporcionales al volumen real de datos. Si no ocurre nada que se ajuste a tus criterios de filtrado, no se envÃa nada y no se consumen recursos por tu parte.
La complejidad es la contrapartida. El sondeo es más sencillo de implementar al principio. Un bucle básico de sondeo se puede escribir en 20 lÃneas de código. Pero esa simplicidad es engañosa, ya que el sondeo optimizado para producción requiere gestión de errores, lógica de retroceso, gestión de estados, detección de reorganizaciones y supervisión, lo que puede suponer cientos de lÃneas de código. El streaming requiere una configuración inicial de un canal de datos y un sistema de destino capaz de recibir datos enviados (como un servidor de webhooks o una base de datos con la lógica de ingestión adecuada), pero, una vez configurado, requiere mucho menos mantenimiento continuo.
¿Cuál es la diferencia entre la lectura por sondeo y la transmisión en continuo?
El sondeo y la transmisión en tiempo real resuelven el mismo problema: incorporar datos actualizados de la cadena de bloques a tu aplicación, pero invierten el control flow. Con el sondeo, tu código es la parte activa: llama repetidamente a una RPC endpoint y pregunta si ha habido algún cambio. Con la transmisión en tiempo real, el proveedor es la parte activa, y te envÃa cada nuevo bloque o evento correspondiente en el momento en que se produce. La tabla siguiente compara los dos patrones en los aspectos que más importan en producción.
Dimensión
Encuestas
Streaming
Datos flow
Basada en la recuperación de datos: tu aplicación solicita datos
Basado en notificaciones push: los datos se envÃan automáticamente
Latencia
Igual o superior al intervalo de muestreo
En cuestión de segundos tras el inicio de la producción en serie
Uso de recursos
Proporcional a la frecuencia de sondeo, incluso en reposo
Proporcional al volumen real de datos
Fiabilidad a gran escala
Tu aplicación gestiona las lagunas, los reintentos y las reorganizaciones
El proveedor ofrece un flujo de datos ordenado y sin duplicados
Datos históricos
Con el apoyo de nuevas consultas sobre bloques anteriores
Con el respaldo del relleno de la misma tuberÃa
Complejidad de la configuración
Fácil al principio, costoso de reforzar
Se configura una sola vez y requiere poco mantenimiento continuo
Ideal para
Scripts sencillos y comprobaciones poco frecuentes
Aplicaciones en tiempo real y cadenas de alto rendimiento
¿Cómo se elige un intervalo de sondeo?
Si realizas un sondeo, el intervalo debe ajustarse al tiempo de bloque de la cadena que estás leyendo. Realizar sondeos a un ritmo mucho más rápido que el de generación de bloques supone un desperdicio de solicitudes y puede activar la limitación de frecuencia, mientras que hacerlo a un ritmo mucho más lento que el tiempo de bloque añade una latencia evitable y obliga a tu trabajador a procesar varios bloques a la vez. La tabla siguiente recoge los tiempos de bloque habituales y las implicaciones prácticas que esto tiene para el sondeo en cada red.
Blockchain
Duración aproximada del bloque
Implicaciones de las encuestas
Bitcoin
Unos 10 minutos
Un intervalo de entre 1 y 2 minutos es más que suficiente
Ethereum
Unos 12 segundos
Realiza consultas cada 4 a 12 segundos para mantenerte al dÃa sin desperdiciar recursos
BNB Smart Chain
Unos 3 segundos
El sondeo de subbloques supone una carga adicional con escasos beneficios
Base
Unos 250 ms
La recopilación de datos no puede seguir el ritmo con precisión; prefiero el streaming.
Solana
Unos 400 ms
Gran volumen de solicitudes; se recomienda encarecidamente el streaming
Lo más complicado a la hora de consumir datos en tiempo real de una cadena de bloques no es el escenario ideal, sino los casos extremos. Una reorganización de la cadena puede sustituir un bloque que tu aplicación ya haya procesado, y una conexión interrumpida puede dejar un hueco en tus datos. Con el sondeo sin procesar o los WebSockets, debes detectar y solucionar estas situaciones por tu cuenta. Un servicio gestionado como Quicknode Streams se encarga de ello por ti: entrega los datos en orden de finalidad, emite cargas útiles de corrección cuando se produce una reorganización y almacena en búfer y vuelve a intentarlo cuando tu destino no está disponible. Esa diferencia es lo que hace que la entrega basada en notificaciones push sea mucho más fácil de gestionar a gran escala.
Preguntas frecuentes
¿Es el streaming siempre mejor que las encuestas?
¿Cuesta más la recopilación de datos que el streaming?
A menudo ocurre asà a gran escala. El sondeo genera solicitudes según un horario fijo, independientemente de si hay datos nuevos o no, por lo que un proceso de sondeo muy activo puede realizar decenas de miles de llamadas al dÃa para capturar solo unos pocos eventos. El streaming consume recursos en proporción a los datos que realmente cumplen tus filtros, lo que suele traducirse en menos solicitudes innecesarias y un menor coste para las cargas de trabajo continuas.
¿Puedo obtener datos históricos de un servicio de streaming?
SÃ. A diferencia de las suscripciones WebSocket, que solo envÃan nuevos eventos a partir del momento en que te conectas, un canal de streaming completo puede recuperar datos de cualquier bloque anterior utilizando la misma configuración. Esto te permite reproducir el historial y, a continuación, pasar sin interrupciones a los datos en tiempo real sin necesidad de ejecutar dos sistemas independientes.
Cómo « Quicknode » es compatible con ambos patrones
