Escribir “nativa de IA” como una lista de características es fácil: unos cuantos opcodes más, una red de GPU y una calcomanía ZK. Una pregunta mejor es qué tareas relacionadas con la IA debería asumir de forma nativa la máquina de estados en cadena, qué debe quedarse fuera de la cadena y por qué el rendimiento de liquidación sigue siendo un requisito previo. Este artículo traza límites de capacidad, no adjetivos de visión.
¿Nativa respecto de qué?
La integración superficial suele significar: un contrato obtiene el resultado de un modelo a través de un oráculo o una API centralizada y lo escribe en el estado. La latencia, los supuestos de confianza y la composabilidad quedan del lado del oráculo; la cadena apenas limita qué modelo se ejecutó o si las entradas fueron sustituidas.
Una ruta más “nativa” suele incluir al menos tres elementos:
- Primitivas relacionadas con la IA expresables por contratos (extensiones, precompilados o interfaces estándar), en lugar de reinventar un puente privado cada vez;
- Ejecución híbrida: pasos ligeros y verificables en la cadena o cerca de ella; entrenamiento pesado e inferencia a gran escala en una red de cómputo, con pruebas o ventanas de impugnación que vuelven a la liquidación;
- Una separación clara respecto de la liquidación: una EVM paralela amplía las transiciones de estado de los contratos; no mete un entrenamiento de cientos de miles de millones de parámetros dentro de la ejecución de un bloque.
Para el mapa de la pila, véase La pila de IA descentralizada; para las brechas de confianza, véase Convergencia de Web3 y la IA.
Extensiones de instrucciones o precompilados: primero la compatibilidad
Si la máquina virtual expone primitivas de tensores o de aprendizaje profundo, las restricciones sensatas son:
- Superconjunto, no bifurcación: las rutas de bytecode estándar de la EVM siguen siendo utilizables, de modo que los contratos DeFi/NFT existentes no se rompan porque la cadena tenga “temática de IA”; las extensiones ocupan un espacio aparte de opcodes o precompilados.
- Mapear a la aceleración por hardware: las primitivas deberían aterrizar en rutas SIMD/GPU, no en una lenta simulación “nativa” puramente de software dentro del intérprete.
- Herramientas reproducibles: la conversión de modelos, la cuantización (por ejemplo, INT8/FP16), los SDK y los perfiladores deben reproducir los mismos resultados; de lo contrario, lo “nativo” solo existe en el documento técnico.
Los materiales públicos suelen citar observaciones de ingeniería, como cesiones moderadas de precisión a cambio de un rendimiento de inferencia varias veces mayor bajo modelos y hardware específicos, no un SLA universal. Los propios límites de compatibilidad se tratan en Qué significa la compatibilidad con EVM.
Conviene desconfiar de las afirmaciones que dan a entender que modelos grandes arbitrarios pueden ejecutar pasadas hacia adelante completas en todo el conjunto de validadores y entrar en el estado canónico. Eso vierte no determinismo, heterogeneidad de hardware y costo de ancho de banda directamente en los supuestos de seguridad del consenso.
Ejecución híbrida: enrutar según la complejidad
No todo el cómputo de IA pertenece a la cadena. Una intuición de enrutamiento más estable:
| Forma de la carga | Ruta más sensata | Qué permanece en cadena |
|---|---|---|
| Verificaciones de restricciones pequeñas y repetibles | En cadena o precompilado | El propio cambio de estado |
| Inferencia mediana / fragmentos de ajuste fino | Fuera de cadena + aceptación ligera | Hash del trabajo, aceptación, pago |
| Entrenamiento a gran escala | Red de cómputo + aceptación robusta (muestreo/ZK/TEE) | Compromisos de trabajo y prueba, pagos |
La selección de nodos puede combinar reputación, stake y aleatoriedad verificable (VRF) para reducir la manipulación; los trabajos críticos pueden usar ejecución independiente multiparte y acuerdo por mayoría. Son opciones de diseño cuya solidez depende del modelo de amenazas, no de cuántos interruptores de características existan.
La ejecución híbrida es el mismo problema cortado de otra manera en Cómputo distribuido con GPU y en el borde y Marco de computación confiable: ciclo de vida frente a supuestos de prueba.
Redes de cómputo distribuidas: reunir capacidad, no mitos
El paralelismo de datos, de modelo y de pipeline son vocabulario maduro del entrenamiento distribuido; el filtrado bizantino de gradientes, los puntos de control y la conmutación por error son bienes comunes de la ingeniería. Cuando entran en una narrativa de cadena, conviene mantener los límites:
- Los límites de interconexión y de VRAM no desaparecen porque algo esté “en cadena”;
- Los incentivos pagados solo por disponibilidad derivan hacia la minería inflacionaria, no hacia un mercado de cómputo auditable;
- La capa de liquidación (EVM paralela optimista) aporta el rendimiento y las expectativas de finalidad para las máquinas de estados de trabajos y los pagos: véanse Panorama de la arquitectura de EVM paralela y Posicionamiento de Bitroot.
La latencia de confirmación y los TPS de testnet describen el sustrato de liquidación; no se traducen en “velocidad de entrenamiento”. Cómo leer las métricas: Glosario de métricas de rendimiento.
Computación confiable y derechos: dos piezas nativas más
La integridad, la confidencialidad y el cómputo conjunto multiparte dependen de combinaciones de ZK/TEE/MPC, no de otro eslogan sobre “seguridad empresarial”. Los ingresos ejecutables de datos y modelos necesitan metadatos en cadena, permisos y máquinas de estados de pago: véase Derechos sobre activos de IA.
Orden de entrega sugerido
Un orden más estable: liquidación predecible → trabajos/pagos con aceptación ligera → TEE/ZK según el modelo de amenazas → derechos/mercados complejos. Divulgar por separado: benchmarks de liquidación (tasa de conflicto), latencia de finalización del cómputo (hardware), tiempo de probar/verificar (circuito/enclave). Un cartel de “TPS de cadena de IA” engaña a todos. Cargas calientes: Hotspots de carga de la EVM paralela.
Para las aplicaciones de Ethereum que migran, lo nativo de IA no debería romper las cadenas de herramientas por defecto. Los precompilados extendidos pueden acelerar la verificación de pruebas, pero la ruta principal debería mantener intactos Hardhat/Foundry y los supuestos de auditoría; de lo contrario, lo “nativo” se convierte en “reescribir”. Compatibilidad: Qué significa la compatibilidad con EVM; mecánica optimista: Mecánica de paralelización optimista.
Las herramientas deciden si lo “nativo” llega a producción
Sin herramientas reproducibles de conversión, cuantización, simulación y depuración, las extensiones de instrucciones se quedan en especificaciones preliminares. Los desarrolladores necesitan repetición determinista local de las transacciones que tocan extensiones; visibilidad en testnet sobre las decisiones de enrutamiento híbrido; y un fallo duro cuando faltan pruebas, no una caída silenciosa a una API centralizada. La madurez de las herramientas debería divulgarse junto con las listas de opcodes.
Las extensiones nativas no deben romper las expectativas de bytecode ni los supuestos de auditoría de los contratos Solidity existentes. La medición de gas, los códigos de error y la gobernanza de actualizaciones de los nuevos precompilados pertenecen a la especificación; de lo contrario, lo “nativo de IA” se convierte en una sorpresa de bifurcación dura. Compatibilidad: Qué significa la compatibilidad con EVM. Paralelismo de liquidación: Paralelización optimista.
La línea roja entre el no determinismo y el estado canónico
Si las extensiones nativas de IA introducen punto flotante dependiente del hardware, el estado canónico se bifurca. Las especificaciones deben decir qué primitivas pueden estar en la ruta crítica del consenso, cuáles deben ejecutarse fuera de cadena y luego comprometerse, si la cuantización/redondeo es obligatoria y cómo verifican o se saltan el paso los nodos sin GPU. Sin eso, lo “nativo” se convierte en confianza implícita en los nodos de gama alta.
Las testnets deberían cubrir la verificación sin aceleradores, la repetición determinista de transacciones con extensiones y un fallo visible ante un enrutamiento híbrido incorrecto. Los objetivos de rendimiento deberían indicar si se incluyen cargas de trabajo con extensiones, para evitar confusiones con líneas base de puras transferencias. Métricas: Glosario de métricas de rendimiento.
Una propuesta “nativa de IA” entregable significa especificaciones, herramientas y enrutamiento híbrido reproducibles de forma independiente; una no entregable significa una degradación honesta a experimentos con precompilados e interfaces de mercado de cómputo. Ambas tienen valor; no deberían compartir un lenguaje absoluto.
La entrega por fases supera a una mega definición
Primero se lanzan experimentos con precompilados, contratos de liquidación de trabajos y mercados de inferencia con comprobaciones puntuales; después se iteran la cobertura de instrucciones y pruebas más sólidas. Atar “ISA de IA completa + red global de entrenamiento + derechos universales” en un solo hito hace que ninguno sea aceptable de forma independiente. Los planes por fases con modelos de amenazas y condiciones de rendimiento son la ruta de ingeniería hacia lo nativo de IA.
Conclusiones
Una cadena de bloques nativa de IA verificable tiene este aspecto: primitivas extendidas reproducibles bajo restricciones de compatibilidad, ejecución híbrida enrutada por costo, redes de cómputo con aceptación y una capa de liquidación lo bastante rápida y predecible para agentes y máquinas de trabajos. Si se quita cualquiera de esos elementos, lo “nativo” vuelve a ser pegamento de oráculos. Esto no es asesoramiento de inversión; conviene tratar las cifras de rendimiento y latencia como objetivos de prueba o de ingeniería hasta que sean reproducibles de forma independiente en condiciones adversas de mainnet.