Por qué Web3 no sabe leer - ForkLog

# Por qué Web3 no sabe leer

Hace algunos años, la industria discutía cómo aumentar la capacidad de procesamiento de las blockchains. Hoy, muchas redes ya pueden manejar decenas de miles de operaciones y algunas incluso afirman cientos de miles. Sin embargo, resultó que escribir datos en una blockchain es solo la mitad del problema. También hay que encontrarlos, indexarlos, verificarlos y entregarlos a las aplicaciones.

Por eso, la velocidad de generación de datos en algunos lugares empezó a superar las capacidades de infraestructura para procesarlos. Cómo está cambiando la blockchain en este contexto, lo analizó ForkLog.

Cuanto más rápido, más tarda

Hace diez años, el desarrollo de las blockchains se describía a través de la llamada trilema de la escalabilidad. Según este concepto, las redes tienen que buscar un compromiso entre seguridad, descentralización y rendimiento. Pero en 2026 se hace evidente que, incluso si el problema de la capacidad se puede resolver parcialmente, aparece un nuevo desafío.

La blockchain en sí no tiene interfaces de usuario. Ese papel lo asumen diversas aplicaciones. Y a su vez, deben recibir datos de forma constante:

• saldos de direcciones;
• el historial de transacciones;
• el estado de los smart contracts;
• eventos y logs;
• analítica de mercado;
• datos para la gestión de riesgos;
• mensajes entre redes.

Cuanto más rápido funciona la red, más datos de este tipo hay que procesar.

Entre los usuarios existe un error común: si la información se registra en una blockchain, entonces se puede obtener simplemente. En la práctica es justo lo contrario. Leer los datos “en crudo” directamente desde la blockchain en tiempo real es un proceso lento, caro y técnicamente complejo. En el ecosistema Web3, existe ampliamente una capa intermedia de infraestructura que conecta los monederos con las aplicaciones dapp.

Por ejemplo, una app de monedero, para que el usuario vea su saldo en fracciones de segundo, se dirige a proveedores RPC, indexadores, plataformas analíticas, servidores de caché, bases de datos especializadas, etc.

El proceso funciona así:

1. Recolección de datos: Programas especiales “leen” continuamente la blockchain a medida que aparecen nuevos bloques.
2. Indexación (estructuración): Analizan (descomponen) esos datos y los colocan en bases de datos clásicas, muy rápidas (por ejemplo, PostgreSQL o ClickHouse). Allí están estructurados de forma conveniente: “Dirección — Lista de todos sus tokens”.
3. Respuesta instantánea: El monedero recibe ya una respuesta lista, filtrada, desde la caché en milisegundos.

De hecho, la mayoría de las populares aplicaciones Web3 funcionan a través de un nivel adicional de procesamiento de información. Imagina que la blockchain procesa 50 000 operaciones por segundo y millones de monederos envían al mismo tiempo solicitudes RPC para actualizar las pantallas. Los servidores de los proveedores no pueden manejar esa carga. Leer, indexar y ordenar los datos para el usuario es una tarea computacional extremadamente compleja. Los indexadores y los servicios de acceso a datos a menudo se quedan atrás del estado actual de la red por varios bloques, porque el procesamiento, la estructuración y la entrega de datos requieren tiempo adicional. Y no se trata solo de una “infraestructura desactualizada”, aunque, por supuesto, también existe. Se trata de un conflicto profundo entre arquitecturas Web2 y Web3.

Los usuarios y las aplicaciones interactúan con la blockchain con la misma frecuencia e intensidad que en el internet tradicional con respuesta instantánea. Cuando revisas el feed de una red social, la aplicación hace miles de solicitudes por segundo al servidor para actualizar likes, comentarios e imágenes. Los bots de trading en Web2 pueden interrogar los servidores de las bolsas millones de veces por minuto. Los servidores de Google o Amazon lo soportan fácilmente porque están centralizados: en términos generales, los datos están en una enorme base de datos, desde donde se pueden copiar instantáneamente a miles de servidores espejo en todo el mundo.

La blockchain funciona de otra manera; no está preparada para eso a nivel de hardware. Hasta hace poco, el principal obstáculo de velocidad era la matemática y la criptografía. Había que hacer que miles de computadoras en todo el mundo llegaran rápidamente a un acuerdo (consenso) sobre si la transacción es válida. Los desarrolladores resolvieron este problema “enseñando” a las máquinas a ejecutar en paralelo y separando el consenso de la ejecución. Por ejemplo, Solana, Monad y Aptos soportan la ejecución paralela de transacciones independientes, a diferencia del modelo secuencial clásico de Ethereum. En Monad, además, la aprobación del orden de las transacciones y su ejecución posterior están especialmente separadas, mientras que en Solana y Aptos el paralelismo se implementa a través de la arquitectura runtime y la gestión de conflictos por estado.

Al final, es posible aprobar decenas de miles de transacciones por segundo (TPS). Pero aquí es donde está la trampa.

Históricamente, la blockchain cumplía cuatro funciones a la vez:

• ejecución de transacciones;
• consenso;
• almacenamiento de datos;
• provisión de acceso a datos.

El aumento del rendimiento incrementa la carga sobre las cuatro funciones simultáneamente. El sistema empezó a generar datos más rápido de lo que la infraestructura puede leerlos, formando lo que se conoce como indexer gap.

En la documentación de Helius —uno de los mayores proveedores de infraestructura del ecosistema Solana— se señala explícitamente que la estructura secuencial de la blockchain encaja bien para garantizar la integridad de los datos y un alto rendimiento, pero vuelve las solicitudes históricas lentas e ineficientes. Por eso, la mayoría de las empresas se ve obligada a construir sus propios indexadores y bases de datos separadas encima de la blockchain.

Los analistas de ChainScore Labs llaman al indexer gap uno de los principales problemas del ecosistema Solana. Según su evaluación, los enfoques tradicionales para indexar no se desempeñan bien con la arquitectura de la red, donde una alta frecuencia de bloques y la ejecución paralela de transacciones crean un flujo enorme de datos.

El resultado es este: la red puede confirmar operaciones casi de inmediato, pero a las aplicaciones les hace falta mucho más tiempo para procesar las consecuencias de esas operaciones.

Las velocidades de Web3 chocaron con una física banal (y no solo)

O más exactamente: con la capacidad de procesamiento de los procesadores, los discos duros y los cables de red. Resultó que la escalabilidad de una blockchain no es igual a la escalabilidad de la infraestructura que la rodea. Y con eso hay que lidiar lo antes posible.

Imaginemos una red con 100 000 TPS. No solo hay que escribir la transacción, sino también:

• guardar el estado;
• actualizar índices;
• responder a solicitudes de monederos;
• atender bots;
• atender analistas;
• atender motores de búsqueda;
• atender agentes de IA.

Por lo tanto, una alta capacidad de procesamiento crea competencia por recursos entre el consenso, la ejecución de transacciones y los servicios de infraestructura encima de la red.

El desarrollo paralelo de algunas de las tecnologías involucradas obliga a resolver este problema ya ahora. Para una persona, una latencia de segundos e incluso minutos puede ser tolerable. Para agentes de IA, sistemas de trading y servicios autónomos, ya no. Si una máquina toma decisiones basadas en datos on-chain, la información desactualizada significa un error, pérdida de capacidad o una pérdida financiera directa.

Al mismo tiempo, la Ethereum Foundation, en su documentación actualizada para 2026, indica que los nodos archivadores requieren de 3 a 12 TB de espacio en disco, y que la sincronización inicial puede tardar hasta un mes incluso con equipos bastante potentes. El límite lo establecen la velocidad de los SSD, el volumen de memoria y el rendimiento del procesador.

Además, los desarrolladores de Geth describen por separado el modelo antiguo de almacenamiento archivado, donde el tamaño de la base de Ethereum podía superar los 20 TB y la sincronización podía tardar meses. Precisamente por eso se tuvo que crear una nueva arquitectura de almacenamiento basada en path-based.

Entonces sí: el “hierro”, los procesadores, el ancho de banda de la red, la CPU —son limitaciones físicas reales en la carrera por el crecimiento de la información. Pero no son las únicas. Los servidores modernos ya pueden procesar enormes volúmenes de datos. La pregunta es otra: ¿cuánto deberían pagar por eso miles de participantes independientes de la red?

Por ejemplo, si para participar plenamente en el ecosistema se necesitan decenas de terabytes de SSD, cientos de gigabytes de RAM, canales de comunicación costosos, entonces el número de operadores de infraestructura inevitablemente se reduce. Así surge una nueva centralización.

Formalmente, se pueden procesar datos, pero no se puede hacerlo barato y descentralizado al mismo tiempo. El costo del procesamiento de información empieza a crecer más rápido que el costo de las propias transacciones.

Cómo reaccionó el mercado

Los participantes de la carrera ya entienden que ganarán aquellas redes que puedan convertir las transacciones en información accesible más rápido, más barato y con mayor confiabilidad. Y durante el año actual, el mercado de manera inesperada desplazó su atención hacia la transición a blockchains modulares.

Si la primera generación de redes intentaba resolver todas las tareas simultáneamente, la nueva generación separa responsabilidades entre capas especializadas. En lugar de una sola red, surgieron capas separadas:

• execution layer — nivel de ejecución (o realización);
• settlement layer — nivel de liquidación (resolución);
• consensus layer — nivel de consenso;
• data availability layer — nivel de disponibilidad de datos.

Los desarrolladores comparan este proceso con la evolución de los centros de datos. Antes, un solo servidor realizaba todas las funciones a la vez. Hoy, los cómputos, el almacenamiento de datos y los servicios de red se escalan de forma independiente entre sí.

Uno de los segmentos de más rápido crecimiento en el mercado han sido las redes DA. A primera vista, la idea parece extraña: ¿para qué crear una blockchain separada para el almacenamiento temporal de los datos de otra blockchain? Pero justamente eso es lo que ocurre. En una arquitectura modular, la ejecución de transacciones y el almacenamiento de datos pueden existir por separado. Rollup publica los datos en una capa DA externa, no en la red principal. Esto permite reducir significativamente el costo de escalar y aumentar la capacidad de procesamiento.

Hace unos años, RPC se consideraba un detalle técnico. Hoy, es uno de los elementos más importantes de la criptoinfraestructura. En mayo de 2026, Triton One, junto con Solana Foundation, lanzó un anuncio actualizado de RPC 2.0: es un nuevo enfoque para construir la arquitectura de lectura de datos en la red.

La idea clave consiste en separar el acceso al estado actual de la red y su historial. Para ello se introducen dos módulos independientes: uno indexa el estado de las cuentas en tiempo real, y el segundo optimiza el trabajo con datos históricos. En lugar de un escaneo completo de la blockchain, el sistema crea índices adaptativos para las solicitudes específicas de las aplicaciones, lo que reduce la latencia y el costo del procesamiento.

Así, Triton y Solana intentan eliminar varios límites sistémicos: la arquitectura monolítica de RPC, cara e ineficiente, para nodos; el conjunto limitado de solicitudes estándar JSON-RPC; y la dependencia de los desarrolladores de soluciones propias o propietarias para trabajar con datos. En el nuevo modelo de lectura, la lectura se escala por separado del consenso, y el acceso al historial se vuelve más rápido mediante el uso de almacenes columnares y datos preordenados.

El proyecto se apoya en herramientas ya implementadas en el ecosistema —incluida la transmisión en flujo de datos desde validadores (Geyser, Yellowstone gRPC) y soluciones para procesar el historial. Toda la infraestructura se distribuye con código abierto, y su desarrollo se coordina con la participación de Solana Foundation.

Como resultado, Solana intenta pasar, de forma efectiva, de un “RPC universal” a una infraestructura de datos modular y especializada, que supuestamente debería reducir las barreras para los desarrolladores y hacer el trabajo con datos de blockchain comparable en comodidad con bases de datos tradicionales.

¿La modularidad resuelve el problema?

Si Solana logra estandarizar la capa de lectura, eso puede fortalecer su posición como red con infraestructura aplicada desarrollada, y no solo con alta capacidad. Pero al mismo tiempo, esto intensifica la competencia con proveedores RPC independientes y plataformas de infraestructura, que tendrán que adaptarse al nuevo estándar o ofrecer servicios adicionales encima de él.

La arquitectura modular elimina parte de las limitaciones de infraestructura, pero las traslada a otras capas del sistema. Se entiende el deseo de reducir costos y simplificar el acceso a datos, sin los cuales no funcionan DeFi, NFT, monederos, analítica y herramientas de compliance. Sin embargo, parece que en la propia naturaleza de Web3 está incorporado el efecto de complejidad en cascada: resolver una tarea inevitablemente crea nuevos desafíos.

El nuevo esquema requerirá de manera inequívoca una sobrecapa de infraestructura más compleja: con indexadores, almacenes, caché, canalizaciones separadas y nuevos puntos de fallo. En lugar de una capa única y simple de RPC, el ecosistema podría obtener varias implementaciones paralelas, optimizaciones incompatibles y una dependencia aún mayor de los proveedores de infraestructura. En ese caso, una arquitectura formalmente abierta no necesariamente significa un modelo de acceso realmente abierto y conveniente para todos.

Por ahora, estamos en una etapa en la que el mercado pasó de competir por quién extrae mejor los datos de la red a competir por quién crea primero productos con esos datos. Quién y cuánto pagará por eso, probablemente lo sabremos en un futuro cercano.