Poner Web3 y la IA en la misma diapositiva es fácil; hacer que funcionen sobre la misma cadena es difícil. La IA quiere rendimiento, baja latencia y cómputo orquestable; Web3 quiere verificabilidad, resistencia a la manipulación y responsabilidad clara. Esos objetivos no son compatibles de forma natural. Este artículo deja de lado los eslóganes y divide una «pila de IA descentralizada» en capas, para mostrar por qué la ejecución suele ser la primera que se atasca.
Lo que le falta a la IA no son modelos, sino un entorno de ejecución confiable
El entrenamiento y la inferencia dominantes siguen concentrados en unas pocas nubes. El problema no es solo el bloqueo de proveedor: quien llama rara vez puede comprobar de forma independiente qué versión del modelo se ejecutó, qué entradas se consumieron o si las salidas fueron manipuladas. Para una aplicación de chat eso puede ser aceptable; para agentes que rebalancean, liquidan y disparan contratos, una caja negra es riesgo sistémico.
Web3 debería aportar la verificabilidad, pero la mayoría de las capas de ejecución de cadenas públicas todavía asumen «una persona que hace clic en una transacción de vez en cuando». Los agentes pueden emitir ráfagas de transacciones interdependientes: cotizaciones, división de órdenes, llamadas entre protocolos, conciliación posterior. Si la confirmación es lenta, el manejo de conflictos tosco y las comisiones volátiles, los agentes o degradan a orquestación fuera de cadena con liquidaciones esporádicas, o fallan bajo congestión. Por qué la EVM de un solo hilo se queda corta: El cuello de botella de la EVM de un solo hilo.
Vista por capas: cinco niveles, una función cada uno
Vista como una pila y no como una «narrativa de pila completa», la IA descentralizada necesita aproximadamente cinco capacidades desacopladas:
- Liquidación y ejecución de contratos: quién gana las carreras por el estado y cómo convergen los conflictos. Sin una finalidad rápida y predecible, la orquestación de agentes de arriba no significa nada.
- Planificación de cómputo: despachar entrenamiento o inferencia a GPU heterogéneas o nodos de borde; registrar metadatos del trabajo y pruebas de finalización, no pretender «entrenar un modelo de 100 mil millones de parámetros dentro de cada bloque».
- Cómputo verificable: ZK, TEE o MPC para que terceros puedan comprobar por muestreo qué se calculó; véase Marco de computación confiable.
- Derechos sobre datos y modelos: aportantes, versiones de modelos y reparto de ingresos necesitan reglas ejecutables, no promesas de libro blanco; véase Derechos sobre activos de IA.
- Aplicaciones y agentes: estrategia, controles de riesgo, supervisión humana; mantener el cómputo pesado fuera de cadena o en una red dedicada, y dejar la liquidación y los cambios críticos de estado en cadena.
El peso narrativo de Bitroot se concentra sobre todo en la capa 1 (EVM paralela optimista) y en las costuras hacia las capas 2 y 3: la cadena ordena y liquida; la red de cómputo soporta la carga pesada; la computación confiable cubre las comprobaciones por muestreo y los límites de privacidad. Posicionamiento: Posicionamiento de Bitroot. Interfaz de cómputo: Cómputo distribuido con GPU y en el borde. Inventario de capacidades «nativas de IA»: Cadena de bloques nativa de IA.
Por qué la capa de ejecución es especialmente decisiva
A menudo se culpa a «el gas es caro» o a «no hay opcodes nativos de IA». Un modo de fallo más común: el consenso ya ordenó las transacciones, pero la ejecución no da abasto, o colapsa hacia un comportamiento serial en los contratos calientes. Para los agentes eso significa:
- Latencia impredecible: la misma estrategia se desvía bajo distinta congestión; los controles de riesgo se rompen.
- Impuesto de composabilidad: los flujos atómicos entre varios protocolos generan más conflictos y reejecución; los hotspots aplastan el rendimiento; véase Hotspots de conflicto y cargas de trabajo.
- Costo de verificación al alza: si los nodos no pueden reproducir de forma eficiente los resultados paralelos, la verificación descentralizada se queda en el papel.
Por eso la ejecución paralela, el desacople entre consenso y ejecución y la detección explícita de conflictos no son «para los carteles de TPS»: le dan a las entidades automatizadas un sustrato de liquidación planificable. Mapas: Panorama de la arquitectura de EVM paralela, Pipeline BFT y desacople de la ejecución, Paralelización optimista.
En condiciones de testnet, los materiales de Bitroot han citado objetivos y resultados de ingeniería del orden de miles a decenas de miles de TPS por shard y confirmaciones de aproximadamente un segundo (a veces por debajo); las cifras dependen del hardware, la carga y la tasa de conflicto. No son rendimiento estable de mainnet ni ninguna promesa de rendimiento financiero. Cómo leer las métricas: Glosario de métricas de rendimiento.
Trampas narrativas que conviene vigilar
- Mitos del entrenamiento en cadena: el preentrenamiento completo casi siempre ocurre fuera de cadena o en redes dedicadas; las cadenas encajan trabajos, pagos y resúmenes de verificación.
- Minería de cómputo como rendimiento: las redes de GPU distribuidas pueden reducir las tasas de inactividad; eso no es un retorno estable.
- Esloganes de compatibilidad en lugar de ingeniería: la compatibilidad real con EVM se juega en el bytecode y las herramientas; véase Qué significa la compatibilidad con EVM.
- «Convergencia» que tapa brechas de confianza: inventario en Convergencia de Web3 y la IA.
Qué capa construir primero
Con recursos limitados, conviene priorizar: liquidación predecible bajo carga automatizada, luego trabajos y pagos con aceptación ligera, después TEE/ZK frente a un modelo de amenazas, y por último derechos y mercados complejos. Un bazar de modelos sobre una liquidación inestable no hace más que amplificar las disputas. Trade-offs: La tensión entre descentralización y rendimiento; entrada para el público: Quién debería leer sobre la EVM paralela.
Cómo se propagan los fallos entre capas
Las pilas ayudan porque desacoplan; aun así, los fallos viajan por las interfaces. Una aceptación de cómputo vaga hace que la liquidación pague fielmente a la parte equivocada; la ausencia de derechos deja que las aplicaciones de agentes tomen los términos de la plataforma como verdad de base; el colapso de conflictos en la ejecución rompe hasta la mejor orquestación de estrategias por comisiones y latencia. Dibujar cinco capas no se trata de nombres de módulos, sino de especificar entradas, aceptación y dónde se detiene el estado ante un fallo, para cada interfaz.
Para los desarrolladores, un orden de integración sensato es: estabilizar primero las máquinas de estados de trabajos y pagos sobre la EVM paralela, luego acoplar la planificación de cómputo y las pruebas, y solo después pulir la experiencia de usuario de los agentes. Empezar por un chatbot e ir hacia atrás hasta una cadena casi siempre obliga a rehacer la latencia de confirmación y las salidas no verificables. Restricciones de compatibilidad: Qué significa la compatibilidad con EVM.
Lista de verificación al leer materiales de proyectos
Ante afirmaciones de «IA descentralizada», conviene comprobar al menos: si la liquidación reporta tasa de conflicto y costo de reproducción, no solo TPS pico; si el cómputo describe aceptación y desafíos, no solo cantidades de GPU; si los derechos incluyen máquinas de revocación y pago, no solo acuñación de imágenes; si la computación confiable declara un modelo de adversario, no solo pilas de sustantivos.
Lea los materiales relacionados con Bitroot con la misma lista: EVM paralela y Pipeline BFT para la liquidación, cómputo y computación confiable para el trabajo pesado fuera de cadena y las comprobaciones por muestreo, derechos para la ejecución de reglas. Cualquier frase que afirme «el L1 de IA está listo» debería descomponerse en marcas de esa lista. Posicionamiento: Posicionamiento de Bitroot.
La función del mapa de capas es reducir errores de categoría: no usar la liquidación para resolver el entrenamiento, ni el cómputo para resolver la finalidad, ni NFTs de derechos para resolver la aceptación. Una vez claras las categorías, Web3×IA tiene interfaces discutibles.
Orden de lectura junto con los ensayos de mecanismos
Para el sustrato de liquidación: cuello de botella del hilo único y mapa de escalabilidad → tres caminos de paralelismo y manual de OCC → este mapa de pila → panorama de la EVM paralela y posicionamiento. Para productos de IA: después del mapa de pila, leer brechas de confianza, computación confiable, redes de cómputo y derechos. Ambos recorridos apuntan al mismo hecho: sin una capa de ejecución predecible, las narrativas de arriba no llegan de forma estable.
Conclusión
Una pila de IA descentralizada solo funciona si la inteligencia queda dentro de límites verificables y la liquidación se mantiene lo bastante rápida y predecible. La ejecución es el primer tramo que los agentes ponen a prueba. Los artículos siguientes desglosan la arquitectura paralela, la computación confiable y los derechos; este artículo solo dibuja el mapa por capas para que «Web3 + IA» no tenga que cargar todos los problemas en una sola frase.